You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »

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 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 and share it with his partner via email, facebook, or 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.

  • No labels