Since showing only relevant content was central to the stakeholders, we implemented the concept of user pools. There were three different user pools created in the app, one each for each of the geographical locations where the app was to be functional. The sign ups of the app were on an invite only basis where the system administrator would be generating invite codes for users to join and would also mention in which user pool would the invited user be put in.
There are two types of users in the app, viz. Hosts and Guests. Hosts will be the content creators in the platform; the ones who will be creating and uploading videos and Guests will only be able to stream and consume the content posted by the Hosts. Users placed in a specific pool will only be able to see the content posted by the Hosts of that pool. In the real world, this would mean that an invited student of NYU (guest) would only be able to see the videos posted by NYU professors (hosts) as both fall in the NYU pool of users. This keeps the content in the app relevant to the users as it only has information from their specific pool.
Either the system administrator can send out invitations to users by creating invitation codes for them to use. Each code will have a user role (guest/host) and a user pool associated with it, so that any user signing up to the platform will have the predefined user roles and be put in the predefined pool of users. Functionality of logging into the platform via Touch ID/Face ID or fingerprint unlock is also provided.
Hosts would create channels about a certain topic, such as a specific academic program or a specific animated movie (for example Physics 203 or Toy Story). Hosts can then create multiple threads in those channels and each thread can contain multiple videos all about a certain sub topic which corresponds to the channel topic. Threads can either be temporary (ones that only last for 24 hours and then would be deleted, similar Instagram Stories) or permanent (ones that last indefinitely till the user deletes them, like TikToks or Instagram Reels).
Hosts can also add co-hosts for a specific thread wherein they can add any other host, even from another pool, to collaborate with them on a specific thread. By adding another host as a co-host, both the users can add their own recordings to a particular video or videos falling under the same thread. Hosts can also send out invitations if the said user is not on the platform yet. This would generate an invitation code for that specific user and who will be a guest user by default and will be added to the same pool where the host sent the invitation from.
To keep the platform more relevant, the option to upload videos from the user’s device was not provided. Hosts can only record videos in the app and upload it in the app. Hosts cannot upload pre-recorded videos. Users can also add responses to uploaded videos. Responses are kept to be only videos to increase the engagement among the users of the platform, and responses are tagged to a particular timestamp of the video, indicating that the response was for that specific time segment of the uploaded video.
The video viewing screen is the central part of the mobile application from a UI and functional perspective. In any video or active loop screen, if there are more than one video, all of them will be auto played. Users can also scrub through the video. It is from this screen that they can record their video responses at a specific time interval.
Video content is at the heart of Totim mobile app. To ensure a seamless user experience, we had to load video data on the user’s devices as fast as possible even on slow networks. To tackle this, we used AWS GraphQL. It allowed us to query and retrieve multiple pieces of information across different sources in a single network request, ensuring faster response times even on slow connections, resulting in shorter video load time aiding in providing a wonderful user experience.