TigerChat seeks to simplify the way Princeton undergraduates communicate. Whenever Princeton students want to chat with one another online, they currently have two options: Facebook Messenger and Google Talk. The problem with both of these services is that they require some form of advance preparation, which college students are notoriously bad at. In the case of Facebook, chatting with anyone else requires having “friended” them previously, and only some people are constantly logged in to Facebook Messenger. Google Talk, on the other hand, requires both knowledge of their email addresses and adding them to one’s own chat list. Within the Princeton network, however, these problems are easily solvable. All students already have a netID that serves as a publicly-searchable unique identifier, providing a simple solution to our problem.
TigerChat is a web-based chat application tailored to the Princeton community. In particular, there are several key features that optimize the experience for Princeton undergraduates. First, TigerChat functions like any of the other TigerApps, for which the only barrier to use is a valid NetID. As a result, students can still chat with those who choose not to use Google or Facebook, use them infrequently, or are difficult to find. With the ability to create and join chat rooms specific to various student organizations, students can extend their extracurricular experiences by adding an online dimension to these relationships.
At its core, TigerChat will be powered by a browser-based XMPP Ajax client that communicates with an ejabberd XMPP server framework and a webserver based on Django running on Apache. Future work will explore the possibility of extending these capabilities with dedicated Android or iOS mobile applications.
To prioritize goals, we divide the user scenarios into three sets: Critical, Desired, and Optional.
User navigates to TigerChat homepage and is prompted to log in via the Princeton Central Authentication Service. After authentication with the CAS database, the user is redirected to the home screen. The home screen contains UX elements for completing the scenarios described below. An invalid NetID or password prints an error message and prompts the user to try again.
User has logged in and now wants to chat with friends. To facilitate this, a search bar at the top of the page allows search by netID, first name, last name, and potentially other information (such as residential college). Once the search has returned its results, the user must elect to “add” the friend to their buddy list. The friend will receive a request from the user (by email and an in-app interface), which may be accepted or declined. Given that he or she is facing inevitable rejection, the user will not be informed when his/her request is rejected. In the rare event of acceptance, the friends will then appear in each other’s lists and can begin chatting. Any buddy from the list may be selected to chat with at any time, provided that he or she is online.
The user logs in and sees the buddy list, which is permanently anchored to the right side of the screen. After authentication, the user will want to chat with any buddies added. Buddies who have already been added and have confirmed friend requests will appear in the list alphabetically by first and last name. When the user selects a buddy, a chat window opens in the main portion of the page. Each chat window opens as a tab inside the chat space, which is kept permanently separate from the buddy list. Any number of chat windows may be open at a given time. If a buddy initiates a chat with the user, a tab on the main page opens with that chat.
All friend requests are made immediately visible at the top of the buddy list, and remain there until an action is taken. Once the user has logged in, he or she may choose to accept or decline any pending friend requests. If accepted, the friends are added to each other’s buddy lists. No actions are taken if friend requests are declined.
User representing some student group logs in. User may choose to create a chat group and designate it as either public or private. The user then assigns admins to the group as desired; the creator is automatically given administrative privileges. These chat rooms are then always open to any member of the chat room. In order to join a private chat room, the user must receive an invitation first. Public chat rooms appear in search under the name of the room. Any chats within the group are visible to all members of the group.
Users can add any information they believe is pertinent. This may include nicknames or preferred names, birthdays, profile pictures, etc. Preferred names and pictures will both be present on all buddy lists, while all other information will be isolated to a user profile page.
User may wish to pop out a specific instance of a chat window. In this case, a button in the top right corner of each tab will allow the tab to be popped out and moved within the screen independently of the main page. In the event that the user wishes to move the buddy list to the left side of the page, that option will also be presented.
User wishes to integrate this account with Google Talk or other XMPP chat client. User will be able to directly interface the two so that all buddy lists are merged and appear in TigerChat. This exchange occurs in both directions - allowing users to chat with TigerChat users from Google Talk or with Google Talk users from TigerChat. User will then be able to chat with all buddies from one XMPP client.
There are three fundamental components to TigerChat: (1) an XMPP Server, (2) an HTTP Server, and (3) the Javascript browser client.
All chat between two users occurs in the following process:
The basic UX design is based on the model used by Meebo. The core UI will include a blank canvas with two features: a buddy list and a search bar. The search bar will be used for adding new friends, while the buddy list enables the initiation of conversations with existing friends by clicking on their name. Aside from the creation of frames for the chat windows themselves, this comprises the bulk of the minimalist UI. If we decide to add user profiles to the system, we will incorporate an additional pane for viewing these profiles.
Princeton CAS provides an API for authenticating a Princeton NetID, so this in and of itself does not require us to store any NetIDs. When a user first logs into the system, we can use that opportunity to create the associated metadata for that user in our MySQL database. However, because it is necessary to be able to search for individuals who might never have logged into TigerChat, we also must obtain a database of valid names and NetIDs. This information can be obtained from the university using LDAP as demonstrated in COS 333 lecture. All other stored data is necessary for representing (1) the connection between NetIDs and JabberIDs and (2) the structure of the social graph.
We will define the following schema using Django’s Object Relational Mapper (ORM). Jabber IDs are unique strings which identify a user within a Jabber chat environment. Note that while ejabberd should handle the details of managing whether or not two students are friends, it is necessary to duplicate this information in MySQL so that Django can access this information, which will be critical for certain UI elements.
March 30 - Set up GitHub repository, install all components on personal computers, begin UI design, and configure landing page with welcome message.
April 6 - Successfully complete CAS authentication, enable sending/receiving messages between two browsers, and create base-level database schema.
April 13 - Enable search by NetID/names, finalize logo and color scheme, and implement basic UI/database support for buddy list.
April 16 - Prototype Due
April 19 - Create Rooms table in database, and add ability to send chats back and forth with room successfully. Create Team TigerChat room for testing.
April 27 - Add chat room administration and public/private setting. Alpha testing. UI complete.
May 2 - Beta testing with friends.
Additionally, each of us will construct two mockups of parts of the UI each week so that we can progress with the front end while the server side and database work is being done.
Our main issue is that we currently lack experience in many core components. The chat framework we plan on using, ejabberd, is built in erlang, and only one of us has programmed in erlang before. Additionally, our experience with HTML, CSS, and Ajax technologies in general is very limited, so generating a good-looking front-end will have a steep learning curve. However, all of the technologies we are using are well-documented, so it should be possible to find help easily regarding any issues we encounter.