...
Figure 11: Composing Messages
Implementation
In our final implementation, we decided to focus on developing the front-end using HTML, CSS and JavaScript, as opposed to implementing a persistent backend using PHP and SQL. Using JavaScript, we implemented a single session for a single client. The only place where we used PHP was in logging in through certificates, as we felt it was important to implement this for user testing.
Our implementation strictly followed our domain analysis. The main entities in our system include a user session, user, post and messages. The session maintains the current user of the session, the list of messages, posts, users, posts the user has created and posts the user is following.
Each time a user logs in, a session is created for him using some preloaded posts, and messages. The model is consistent between tabs; for example, if a user follows a post through the browse tab, it is reflected in the “Posts I’m Following” on the “My Posts” tab. Similarly, if he/she creates a post, it is reflected both on the browse page and on the “My Posts” page.
There were several implementation constraints which could possibly affect the usability of the interface.
- Our implementation placed the posts that a user decides to follow on a different tab from the browsing tab. As such, when a user decided to follow a post they could not tell that we had a list of “followed posts” in a separate tab that was dynamically changing based on which posts they decide to follow or unfollow. We tried to alleviate this lack of information by offering some affordance by changing the color of the button from blue to red, and the text inside the button from “follow” to “unfollow”.
- In our implementation, some users can only post jobs but not browse or follow posts (company recruiters). Other users can both browse and post jobs/starups/UROP etc (MIT affiliates). Separation of these two categories could be easy if all MIT affiliates could use certificates to sign in because we could associate a certificate sign-in with some sort of master login that allows both posting and browsing, while non certificate login can be associated with only browsing. This would just be a hack because we still should ideally allow an MIT affiliate to sign in with a username-password combination if they feel reluctant to use certificates.
There are still some issues when a user tries to message a post in the “Browse” tab. Other problem is in the ‘Posts” tab under “My Posts”, the total number of posts that were created by the user is shown, and there is a link to possibly showing different posts, but this link does not work. The same feature was added to the posts under the “Browse” tab, but it’s working the way we wanted.