Tasks

Creating a Timer
Sharing a Timer
Viewing All Timers

Scenario

John is working on the second problem set for UI.  He wants to create a timer to remind him of the deadline.  One of his friends always turns her assignments in late, so he wants to be able to send her the timer to remind her of her deadline.  Both he and his friend (Nicole Shaw, Pat Marx) then want to be able to view the timer, along with timers for other deadlines.

Design 1

Summary

In this design, the user primarily interacts with two pages--a “Timers List” page and “View/Create/Edit A Timer” page.  The collapsing of the viewing, creating, and editing actions into one view is done for internal consistency.

Timers Have One User-Specific Boolean States:

  • Proposed By Another User/Accepted/Ignored

And Two Global States:* Completed/Not Completed

  • Expiring/Upcoming

On the “Timers List” page, users can filter timers based on these states.  Users share timers by providing email addresses of other users.  If a user with that email address exists, the timer will be added to their “Timers List” in the “proposed by another user” state.

Storyboard

Going to the website takes John to the “Timers List” page.  Here, John wants to create a new timer, so he clicks on the “Create New Timer” button.  

This takes him to the “View/Create/Edit A Timer” page, where John fills out the details of the event and clicks Done,” which takes him back to the “Timers List” page.

Now, John’s group members see the proposed timer on their “Timers List” page.  By clicking the question mark icon to the right of the timer name, they can change the timer’s state from “proposed” to “upcoming.”

Analysis

This design has positive and negative aspects.  One positive aspect with regard to learnability is that it is very heavy on immediate feedback.  Upon selecting different states, the list of timers can immediately change to show the new filter criteria.  Since upon creating a new event, the user is taken back to the "Timers List" page, the "Timers List" can be automatically scrolled to show the new event in its location.  We are given the constraint that users must input certain amounts of information about each timer--a somewhat tedious process.  However, given this, the user interface is quite efficient.  Finally, the design has a high degree of safety in most regards.  Users can filter timers based on all states, so state selections (i.e. changing a timer to completed) can easily be undone.  Also, users can remove unshare a timer by removing users on the "View/Create/Edit a Timer" page.

There are also negative attributes of the design.  One such aspect is the learnability of the different timer states.  It may not be immediately obvious to users what each state in the "Show" list means, and the states smorgasbord  does not have a natural mapping to something the user is already familiar with.  Also, with regard to efficiency, if the user has a lot of timers, he may have to scroll through a large number of timers in order to find the timer that he wants. 

Design 2:

Summary:

This design attempts to emphasize sharing timers with your friends and coworkers as well as displaying your timers in a chronological order by giving these tasks the majority of the screen real estate in a single page web app.

In the creation of a new timer, a user can choose a list of facebook friends, emails and geographic locations to share the timer with as well as creating default groups of people (such as coworkers) so that they don't have to constantly type in a list of emails or Facebook friends.

The sidebar of the application provides a list of timers that a user's friends, coworkers, custom groups, and nearby people have created. They have the option either added these timers to their personal timer list, or ignoring the timer forever. 

The main view of the app contains a list of all of a users currently tracked timers sorted in chronological order by deadline. Upon clicking a timer, it expands revealing more detailed information about the timer. This information includes a checkbox to indicate that the user has completed the task prior to the deadline, a notifications settings button that allows a user to change how frequently they are notified about the deadline, and a participants button that displays how many of the other participants in the countdown timer have completed their task.

 A user should also be given a public profile that displays how frequently they complete their tasks prior to the deadline and their average busyness during the week.

Storyboard

The drawing above illustrates the information provided in the summary of this design. The main view and sidebar make heavy use of an accordion effect to display relevant information to the user. By navigating the sidebar on the right the user can find events that are relevant to them. In the scenario John would create a new timer by clicking the "+ new timer button" in the top right corner and a modal dialog like the following would appear.


In the new timer dialog John has a few options about how he can share his new timer. He must first enter when the timer is set to expire, then decide who to explicitly invite via Facebook or email. The where box is optional but allows John to share his timer with people who are withen a certain radius of that location. When his partner logs on they would see a new invite in the sidebar if John invited them via email or facebook, or could find nearby timers using the local tab. Once John's partner accepts the timer, they both can see when the other completes the task. The creator of the timer is given editing and deleting privileges of their timers. So if the due date of the users assignment changes, John can edit the timer to reflect the change. On the same page of the application, John and his partner can scroll through other timers and mark them as complete.

Analysis

Being a single page app, this app should be extremely easy to learn. There are very few options and as such it is simple to learn. This simplicity also makes the application extremely efficient because you don't have to click through many menus to do what you need. Every timer is visible from the main page and is one mouse click away from being expanded. Because only the creator of a timer can edit or delete it, it is very safe for the creator of a timer. A safety issue that could come up is when a creator deletes a timer that other people rely on.

Design 3:

Summary

This design involves two pages: managing/viewing all timers and working with individual timers.

Storyboard

John arrives at the timer creation page after clicking the link from the main page. He can enter the date by typing into an input field or by clicking a calendar icon which displays a calendar from which the date can be selected. The time can also be set via another input field. A title and description can be entered, and there is a formatting toolbar for the description. Sharing can also be specified here and is discussed in the next section. After creating a timer, its specific details are shown in a timer view window.
[figure 1: create]

To share, John can directly share from the timer creation page or at a later time. Let's suppose he shares it upon creation. A new window is displayed, and he can either add names from an autocomplete form, or by selecting from his entire list of contacts.
[figure 2: sharing]

To view timers, John goes to the main page, which has a list of timers that he has created or that have been shared with him by other users. Timers created by others are italicized, and the timer's creator is shown underneath. They are ordered chronologically with the nearest events at the top and later events below. A countdown is displayed next to the time for a particular timer. Pending timers that another user has shared with John appear in red text in his timeline. They are also displayed in a list of pending timers which can be found in the upper right corner. From either location, John can add the timer or ignore the sharing action. Clicking on a timer title goes to a new page showing details for that specific timer.
[figure 3: viewing]

Analysis

In terms of learnability, this design is fairly good. The links for the main tasks are immediately visible, and the links for other tasks are visible on a specific timer's page or accessible from an arrow next to a timer's title on the main page. However, the sharing system is not probably great for learnability. Because there are two possible methods to select users to share a timer with, there is some inconsistency in how the same information is displayed across these two methods. Futhermore, it might not be obvious that a red timer in the viewing page is a pending timer share from another user. The pending timers button on the upper right helps the user eventually learn the notation unless he reads the instructions.

In terms of efficiency, the simplicity of the design makes a tradeoff for efficiency. In the current scheme, a user views the specific timer he just created instead of the main page with all timers. There is also no notion of grouping users in one's user list, so sharing with a subset of people for several different timers requires manual entry each time. The view mode is limited to chronological order; there is no way to filter out timers or change the sorting order. A feature included on the "view all timers" page is a prominent line along the timeline, indicating the current time. This allows a user to gauge at a glance the relative duration of timers.

This design is mostly safe. The sharing interface is fairly flexible, and timers can be modified or deleted after creation. Delete actions, such as removing a timer or denying a pending share, require an additional confirmation step, after which point the timer cannot be recovered.

  • No labels