Scenario
It's Monday morning and Jack just realized that he has been meaning to have lunch with Kate and Bill for a while and they haven't been able to meet up. Jack and Bill work on the same project team, so their availabilities are similar, but because Bill doesn't respond to email frequently (despite the fact that he always has his smartphone with him), Jack has had trouble trying to schedule lunch the day of with Bill. Jack has also had trouble scheduling a lunch with Kate because he doesn't know her availability. Jack would like to have lunch with Kate and Bill sometime this week, the sooner, the better. Jack is able to take a one hour lunch between noon and 2pm on every day except Thursday when he has a conference call with the San Francisco office that lasts until 1:30pm.
Kate has been out of the office the past few weeks and has fallen out of sync with Jack. She has several meetings over the week, but none during lunchtime. She is excited to catch up with Jack and Bill.
In this scenario, Jack needs to create an event and invite Kate and Bill. Kate and Bill need to respond to the event.
Design 1
Storyboard:
The following image shows the overall walkthrough of the design.
|
Figure 1 |
Figures
|
|
|
|
Figure 2 |
Figure 3 |
Figure 4 |
Figure 5 |
Walkthrough:
When Jack opens his mashcal to create and event he is greeted with the homescreen shown on the Figure 2. It shows him to the events he has created day by day. He can transition to the new event creation window (also on Figure 2) on from the homescreen. He can name the event and choose its type as well as invite others and pick the possible dates for the event. Upon pressing on "Pick possible dates" button he will come to Pick Dates window shown on Figure 3. The structure of the picking dates window is similar to theiphone default alarm clock interface. The Month Week and Day can be set with scrollable selectors that move up and down with a flick (Similar to alarm choosing interface). The time slots can be marked available and unavailable and after selection clicking done button brings Jack back to the event creation window. He can then select the invitees from his contact list (Shown on Figure 4). This interface is similar to iphone contact interface. He can add import contacts as well as search for them in the autocomplete search input box. He selects Bill from his contact list, however he did not previously have Kate's contact and he adds her as a new contact. By pressing the Done button he sends invitation to Kate and Bill. When Kate and Bill receive invitations, push notification will appear on their phone as shown on figure 5. They can just simply reply "I can not go" or they can choose the dates appropriate for them via the Pick Dates interface and send the reply back.
Analysis:
Learnability
Good: Couple of affordances are used in the interface to improve usability. Traditional affordances like arrows and buttons are natural to the user. Their behavior is consistent with way people think about them. The "Percentage of People RSVP-d " icon communicates whether the event was for a group or just for Jack by showing many human figures or just one. That icon is filled up according to how many people reply to the invitations. The thumb icon on the Pick Date window on Figure 3 tells the user that the time slot can be selected with a touch; this communicates the model of the interface to the user effectively. Another thing that helps with the usability is that everything that user can interact with is labeled accordingly. Therefore, a user will not be wondering which part of the interface corresponds to what task.
Bad: The Pick Date interface might be initially unfamiliar to users. 2 or 3 slide walk through to show how to select dates and time slots might be necessary.
Efficiency
Good: Searching for contacts and autocomplete box helps user invite people efficiently. Also the Scrollable selector for the dates is more efficient than traditional text input methods. For users who want to link their mashcal to their calendars like gcal "Linking calendar" option is available. They can also import contacts from other contacts lists. Additionally, history of previous events which would be incorporated to inviting people window will allow people to choose invitees from the list of previously invited people, making it efficient to reinvite people.
Bad: Due to the limited screen size of phone, the time slow selection can not show all the time slots in one window. A user has to scroll down and make a selection if he wants to choose 8pm for example.
Safety
Good: The fact that things are selectable with a one single touch makes it easy to recover from errors. Say a user choose a wrong time slot when picking a date. She can then just simply press on that time slot again to unselect. Another thing that helps with safety is that the autocomplete in the search box. The user can easily select invitees from the list without making spelling errors. The history features which would be incorporated to inviting people window will allow people to choose invitees from the list of previously invited people. Therefore, reinviting people to an event is almost error-free.
Other
We can play with Typography ( different fonts, sizes etc.) to solve the problem of not being able to see many time slots in one window. The use of green for available slot ( red for unavailale ) will help user easily pick the appropriate dates.
Design 2
Storyboard
Overall Design
Figures
|
|
|
|
|
Figure 1: Initial event creation |
Figure 2: Scheduling event |
Figure 3: Inviting people |
Figure 4: Overall events |
Figure 5: Accept/Decline event |
Walkthrough
The first panel (figure 1) shows the initial step of creating an event. The application has two input textboxes. The first textbox allows the user to input the title of the event. In our case Jack wants to create a lunch event with his two friends. So he enters the title Lunch and puts in a little description in the next textbox so his friends can get a better description of what the event is. After Jack is done entering the initial details of the events, he can press the lower arrow or swipe the screen to get to the next page.
The next screen (figure 2) allows Jack to schedule the event. He has the option to choose the date and length of the time by manipulating the scroll wheels that allow you to quickly change numbers. After finding an appropriate date, the schedule of that date is displayed horizontally. The events that are already confirmed and scheduled by Jack will show up as boxes with the title name of it. He can click on any of the boxes to see a modal popup with more details of the event. The horizontal calendar will also shade in areas that can fit the length of the current event trying to be scheduled. Jack can then simply press anywhere on the map and drag that press to highlight acceptable ranges for the event. The dragging start and stop positions will be the range that he chose. He can highlight multiple ranges throughout the calendar. Jack can also zoom in and out or move the calendar left/right by pinching the calendar with two fingers. If Jack wants to add special settings to the event (like make the event recurse every Tuesday) then he can press the advanced settings option in the top right corner. After selecting appropriate ranges then he can go to the next page by swiping or selecting the button.
The next screen (figure 3) shows the invitation page. In this page Jack searches for users to invite by typing a name in the autocomplete textbox. As soon as you choose a name it gets added to the list. The list of contacts can come from the phonebook or some other predefined list. Jack is now done and the invitations will be sent Kate and Bill.
Kate now gets a push notification from the application stating that someone has invited her to an event. She can see an overview of the events she hasn't replied to and those that she has (figure 4). From the push notification she goes straight to the event page (figure 5). In here she sees her own schedule on the horizontal calendar as well as the shaded areas of proposed times from Bill. She can click on the shaded area to highlight it and say that she can attend the event at that proposed time. If she can't attend any or doesn't want to reply to it, she can press any of the buttons below.
Analysis
Learnability - This interface is very minimal and compact. It uses less pages and makes it easier for the user to understand what is going on. There are several affordances that allows a user to figure out how to maneuver through pages; the buttons allow the user to switch from page to page. It is easy for a user to understand how to change the numbers in the dates and time range because they show up as a scrollable wheel, which is a nice affordance. Understanding how to select ranges in the scheduling page can be difficult for someone creating an event. As a first time user, it might not be that clear and we will probably have to find a way to make it more obvious. Maybe some help text or an initial tour of the design.
Efficiency - The minimalistic design of the interface allows users to quickly create an event by only going through 3 pages. We also use an autocomplete feature to allow users to find people faster. The slowest part of the interface is the scheduling page for the creator. It is fairly difficult to select ranges from the horizontal calendar because it requires certain manipulation of the schedule.
Safety - The interface makes sure that you can go back and forth between pages to fix any types of errors. We will also try to make sure that there is a way to edit events that a user has already created. We also give a good amount of feedback on the schedule for users selecting certain ranges (both the creator and invitee) because we highlight selections thoroughly to ensure that a user knows what they did.
Other - We try to maintain consistency between pages by using the same header and gestures throughout pages. We also try to condense all tasks into their own unique page in order to not confuse users or redirect them to multiple pages for one task.
Design 3
Storyboard
Figures
|
|
|
|
|
Figure 1: Initial event creation |
Figure 2: Scheduling event |
Figure 3: Inviting people |
Figure 4: RSVP to an event |
Figure 5: Confirmation of RSVP |
Walkthrough
In figure 1, Jack visits MashCal and is presented with two options. Because he is trying to schedule something new, he clicks "Create new event." The next screen Jack sees asks him to pick the time horizon in which his event needs to occur. Because he wants to have lunch with Kate and Bill this week, he chooses "This Week."
In figure 2, Jack has to select the times during the week that his event can take place during. The interface presents times in 1-hour blocks. Because today is Monday, the first day he sees on this screen is Monday (even though Sunday is the first day of the week). Jack can scroll up and down to view more times during a particular day and swipe to the left or right to reveal more days. Pressing a time range selects it, as he has done for 12pm and 1pm on Monday.
Once Jack is done setting his availability for all the days in his time horizon, he is presented with the screen in figure 3. This screen allows Jack to enter in the name of the event and choose who to invite. The "what are you doing" field is a text box. "Who is invited" is an autocomplete field for a list of people that hooks into the address book on Jack's phone. Once Jack
has selected Bill and Kate, he creates the event.
After Jack creates the event, Kate receives a push notification on her phone informing her that Jack has invited her to lunch (shown in figure 4). Once she clicks respond (the only way to dismiss the dialog), she is presented with a list of times that Jack has selected. She can select any number of them via checkboxes. Once she is done selecting times that work for her, she RSVPs to lunch.
Finally, in figure 5, Jack receives a push notification informing him that Kate has RSVPed.
Analysis
Learnability: All of the decisions (actions) Jack and Kate have to make are presented as buttons on the page. Buttons offer the affordance of needing to be pressed to submit information.
In figure 2, our interface takes advantage of multitouch touchscreens to allow two-fingered scrolling with a day and swiping between pages; however, this behavior is not very discoverable. To aid learnability, there are arrows that look and behave like the arrows on a scrollbar. These arrows grey out when the user can't scroll anymore.
In figure 3, the autocomplete contacts field helps Jack know who he has the capability of inviting. In figure 4, the checkboxes Kate sees afford selection of multiple items, indicating that she may choose all times that are good for her.
Efficiency: The time selection screen in figure 2 has smart defaults by starting Jack out on Monday instead of Sunday. It is unlikely that a user would want to schedule an event in the past, so MashCal doesn't allow it.
In figure 3, the autocomplete field helps efficiency by allowing Jack to only type a prefix of his contacts' names.
Across all panels, this design tries to keep the user's fingers in the middle of the screen as much as possible (buttons in figure 1, time selection in figure 2 and figure 4). Since the mobiule device is smaller and the middle of the screen is easiest to reach, this helps with locality of the user's pointing device, their fingers.
This design also doesn't rely on pinch-to-zoom like gestures that are easy to overshoot. Clicking on a range to (de)select it is qucicker and less error prone.
Safety: The interface in figure 1 and 2 offers no obvious way of backing up through the various panels; however by swiping to the left, Jack can back up through previous screens to correct a wrong choice.
In figure 3, the autocomplete field helps Jack by autofilling in the right contact's email. The bubbles around autocompleted contacts allow easy deletion of any contact (not just the last one entered). This makes error recovery easy.
Other: The touch controls (swiping, scrolling, selection) are meant to be externally consistent with other applications and conventions on iOS and Android opertating systems.
Alternative Design directions
Inviting people: Aside from using an autocomplete field, it is possible to instead present a user with a list of all of their contacts as a combobox that allows multiple selection. We dislike this widget because it is not efficient for the case where users know whom to invite already. Some contacts lists my take 10s of screens on a mobile phone. It also would force the user into our mental model of presenting all contacts alphabetically where they may be thinking of them in other ways. Because of these drawbacks, we did not incorporate the combobox into our designs.