Design
Responsive
A primary goal of the design of this application was for it to be responsive, it should be equally as usable on mobile as it is on desktop. We spent significant time testing it on the iPhone and adjusting the front-end to achieve this goal. This device compatibility was achieved by stacking columns on the mobile app and scaling font-sizes proportionately with screen size as is shown in figure 1 below. 
Figure 1: Desktop layout on the left, mobile on the right.
Timer Creation
The single most important action a user can perform is the creation of a timer. In order to facilitate this, we created a very simple yet powerful timer creation dialog. In the date dialog, the user is able to enter a vast array of date terms which are fuzzily matched to an output date. They can enter terms such as "5 min", "today at 6pm", "10/26/1990" and they will all be converted to a date. The user is also given instant feedback as to whether or not the date is valid. This streamlining of the date input was a result of the input to our first round of user testing. We originally had a calendar and clock widget to input time, but it was inefficient and difficult to use. The instant feedback of the date input is illustrated in figure 2 below.
Figure 2: Notice the instant feedback provided by the date input.
The second most important part of timer creation is inviting other users to view timers. Users in our paper prototype were unaware of how to invite multiple users to a timer, so we attempted to make it abundantly clear in our first implementation by using a multi select check box. Unfortunately an array of checkboxes is not very user friendly on mobile, so instead we implemented a multi-select using text input. See Figure 3 below.
Figure 3: The text input for sharing a timer with contacts.
User Feedback
All of the timers on the page get updated in realtime. This means the user gets constant feed back about the state of a timer as the seconds digits count down, and if a user is invited to a timer by another user, it instantly appears in their invited timers. This realtime aspect was important to our test users, because they wanted to be able to leave the application open on their desktop without ever refreshing the page. Also when a timer expires, the user is notified and it is filed in the category of expired timers.
User Sign In
Our users were not enthusiastic about a difficult login and sign in experience, so we kept these pages very simple, as illustrated in Figure 4 below.
Figure 4: From left to right, homepage, registration, login
Learnablity
We choose to highlight timers in order to visually indicated how soon they are going to expire. In user testing we realized that this fact was not readily apparent to the user, so we implemented a tutorial page that appears the first time the user logs in. This page does not interfere with the user's actions and disappears when he/she creates his/her first timer. See the tutorial below in Figure 5.
Figure 5: The tutorial screen
Implementation
The TeamTimer application consists of an html5 client written using jade, coffee-script and less that communicates with an API server written in python with flask that exposes a mongodb database. The modular separation of the client and server allowed us too quickly mock and test the front-end design with our test users before investing the time to developing the backend.
Models
Two models, Timer and User, represent all of the data in the application, and allow a user's information to be persisted in mongodb. Having only two models greatly simplifies the implementation of the app. Each User can have many timers and each Timer can have many users. To prevent unwanted edits to a Timer, each timer has one special user, denoted as "owner", that is the only person who can edit it. One down side of this architecture is that it is difficult to capture relationships between Users. For the sake of simplicity, we solved this problem by automatically populating a user's contacts.
Authentication
When a user registers with an email and password, they are automatically accepted and logged in. The downside of this is that we don't verify the user's email. We use our own authentication service that stores passwords securely using bcrypt. The original idea was to use Google's GitKit to allow users to login using their Gmail account, but this proved too difficult to implement. This would have made registration much simpler and would have removed the need to verify a user's email.
Front-End
The client uses responsive css media queries to dynamically restructure the document to account for different sized displays. We started with a multi column layout for the desktop experience, which stacks to a thin single column layout for the mobile site. The app is updated in realtime using web-sockets, or suitable fallbacks from the socket.io library, to allow a user to see new invitations and contact requests as they occur, with no page reload. On mobile, the realtime updating unfortunately uses a large amount of data because it is constantly sending.
You can see the source here
Evaluation
Briefing:
When working in teams, it is often difficult to make sure that everyone is aware of deadlines. Typically it is the job of a group leader to harass team members, reminding them about impending deadlines. Most likely these reminders annoyingly occur too frequently for some team members and not frequently enough for others. TeamTimer lets you create timers that countdown to certain times. You can then share them with other people.
Scenario:
Your team has an important report that must be submitted by May 30th at 11:00PM. You are working with one other person. His name is Paul Woods, and his email is pwoods@mit.edu.
Tasks:
Register an account
Create a timer for the report
Share timer with pwoods@mit.edu
Accept invite to “New Report Deadline” timer
Delete timer you created
Users:
We tested three users:
- A manager managing a non-technical group at IBM
- A non-technical former manager
- An MIT undergraduate
The primary motivation behind choosing these users is that we wanted to test our user interface among non-technical users that were used to working in a business setting. We decided to test with an MIT student because we wanted to make sure our interface was still efficient to learn and use for more technically-capable users. Together, these users are very representative of our target user population.
We found them through our friends and networks.
How We Conducted the User Tests:
The user tests were conducted over Skype using the “Share Screen” capability.
Usability Problems We Found and Possible Solutions:
Minor (consistency and standards): We had taken out our original date-input interface and replaced it with a much more efficient design that allows users to input date and time into the same box. However, less technical users seemed confused by the fact that they were inputting both date and time at the same time. One solution is to go back to the old design we had in our paper prototype that is more consistent with other interfaces with which these users are familiar.
Cosmetic (visibility of system status): Another usability issue is also on the “Create New Timer” screen. The “Create” button always looks the same, regardless of whether it is enabled or disabled. We didn’t think this would be an issue since the forms themselves each provide their own form of feedback. However, one user did not notice the field-specific feedback after he had entered invalid input until after he had hit the “Create” button multiple times to no effect. Two possible solutions are making the field-specific feedback more noticeable and giving the “Create” button a less-clickable looking appearance when its functionality is disabled.
Reflections
Probably the single biggest thing we learned was the benefits of using an iterative design process and developing inexpensive prototypes before investing resources on code and then on a backend. Our original design had a lot of aspects, for instance, a confusing sidebar dedicated solely to "Pending" timers which we realized could be improved significantly during the paper prototyping session. Had we not done prototyping first, we would have only realized this after spending a lot of time coding the sidebar.
What we would probably do differently is spend more time at the beginning of the project thinking about our design goals and who we were designing for. Some of our major decisions (for instance, adding an additional interface for the iPhone) came later in our process, and we missed out on some of the feedback we would have had, had we been clear on our focus from the start.
We would also spend more time earlier in our process going one-by-one through each of the class slides and seeing how they could be applied to our design. It’s easy to forget about a large chunk of principles and only apply the first ones that come to mind. Some of our better design decisions (such as getting rid of the unnecessary “Description” box and using just email addresses instead of creating an entirely new idea of ‘Contacts”) came as a result of considering all of the course material. However, these ideas came somewhat later in our process.