Code and Design Specification
(1) Requirements
We want to facilitate seamless, non-verbal communication between users and digitally replicate the feeling of being in the same room together.
Functional Requirements:
Primary:
- User will be able to sign up and login
- User will be able to create a virtual room, join/leave a room
- Users will be able to share their activity information to other users in the same room (current app, keyboard activity, etc.)
Secondary:
- User will be able to add an avatar
- Users can decide which information they want to share
- Users can open and close the application overlay
Technical Requirements:
Primary:
- User information must persist throughout different instances of the app
- Virtual rooms should remain private
- A data collection system should be used to collect information
- An interactive overlay on the browser window will be the primary UI for the application.
- Semi-real-time visualizations of user behavior (e.g. typing)
- Code generation for virtual rooms
Secondary:
- User Authentication (options in 'Architectural Design' section)
- 'Friending' others (needs additional book-keeping for maintaining friend lists)
Usability Requirements:
Primary:
- The system will function in one or more popular browsers (most likely Chrome)
- The UI should be intuitive, simple, and interactive
- The application overlay will be present across tabs and should be minimally invasive
Secondary:
- User able to 'poke' friends
(2) Storyboard
Creating a room and inviting friends
Viewing what people in your room are doing!
####
(3) Architectural design: Subsystems and components of the project
- Server
- Django
- Room API
/create_room
: Creates a new room, and the calling user becomes the owner of the room. Returns a unique room id/get_room_status/<room_id>
: Returns statuses of users currently in room \<room_id_\>_/delete_room/<room_id>
: Deletes the room (if the calling user owns the room)/join_room/<room_id>
: Join the room \<room_id\> (and add it to your previously joined rooms)
- Status API
/update_current_tab
: Update the "current tab" for the calling user/update_keyboard_activity
: Update the keyboard activity for the calling user
- Preferences API
/update_show_current_tab/<true/false>
: Update whether the calling user is sharing what tab they are on/update_show_keyboard_activity/<true/false>
: Update whether the calling user is sharing their keyboard activity
- Database
- SQL DB ( SQLite included with Django )
- ER diagram
- Client application (browser extension)
- Overlay on each tab
- React.js (JavaScript/TypeScript) components for UI, ant design UI components
- React components for buttons, overlays, rooms, etc.
- Ant design will take care of style and template functionality for lots of components
- Potential middleware for managing application state: Redux
- Semi-realtime updates via HTTP requests
- Shared data:
- Keyboard activity: Periodically make a request to the server with the latest keyboard activity recorded as a list of keystrokes and timestamps
- Current tab: Use browser API to detect when a user changes their current tab, and make an update request to the server
- Branding and graphic design: for later, but likely similar to Material UI style for simplicity
High-level system overview: Users install browser extension, and create an account with the server. A user can make a request to the server to create a room, and receive a room ID. They are now the "owner" of that room (having an owner might be relevant later). They can share the room ID with other users externally. These other users can then join the room by using the room ID. Users in a room now share their "statuses" with each other in real-time, passively. The server persists information about users and rooms in the database.
(4) Summary
The primary requirements in (1) and (2) necessitate a workflow for users to share snippets of (primarily browser-related) data with others in each room. In particular, this requires that we can effectively store and share data, i.e.:
- The application must manage the data of multiple users, their details, and the rooms they are in/own
- The sharing process must occur passively and with low latency
Having a hosted server with a database will enable the persistence of various types of data. The server will have APIs that will allow user authentication and creating/joining rooms, as well as sharing status data, and adjusting data-sharing preferences. For the UI/UX, we decided on a browser extension overlay since it will be able to capture some of the relevant browser activity to share within rooms, while being easy to install and not be too obtrusive. We decided to use React.JS for familiarity and nice integration of existing component libraries.