...
The second most important part of timer creation is the inviting of other users to your timerview 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 a 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.
...
Two models, Timer and User, represent all of the data in the application, and allow a users 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 simplicities sake . For the sake of simplicity, we solved this problem by automatically populating a user's contacts.
...
When a user registers with an email and password, they are automatically accepted and logged in, the down side . 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 Gmail account, but this proved to too difficult to implement. This would have made registration much simpler and would have removed the need to verify a user's email.
...
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, that 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.
...
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
...
The primary motivation behind choosing these users is that we wanted to test our user interface among non-technical users that we 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.
...
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. HoweverHowever, 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 paper prototype that is more consistent with other interfaces that with which these users usesare 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 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.
...
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 Our original design had a lot of aspects, for instance, a confusing sidebar dedicated solely to "Pending" timers , that which we realized could be improved significantly during the paper prototyping session. Had 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 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 It’s easy to forget about a large chunk of principles and only apply the first ones that come to mind. Some 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.