Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Design #2
Lunch Browsing Interface

Learnability: This interface does pretty well in the learnability category.  The user is greeted with a list of obviously-clickable events in chronological order on the front page.  These are the events they have been invited to attend.  There is no searching or information required by the site before the list of events can be displayed.  Upon clicking an event, they will see all necessary details such as location, time, and who is attending the event.  Upon clicking the button to create a new lunch event, they will see an easy form that asks them for the relevant information.  

Efficiency: The efficiency for this interface is pretty positive as well.  The user can quickly find events for the current day (because they are at the top of the list) and click them and edit them and get back to the list with the “My Lunches” button at the top right of every page.  The event creation screen is also very streamlined and efficient, with a calendar widget for setting date, a scroll bar with checkboxes for inviting friends (and added search functionality to this scrollbar).  One drawback in efficiency we envision for this design is that it may be difficult for users to find events that are far off in time if they are not initially seen in the scroll bar.  The events are organized by time, but the density of times may not be uniform so it may take some time for the user to locate a particular event in their list.

Safety: Potential errors users can make are in setting event details incorrectly, inviting the wrong people, failing to notice that they have been invited to an event, or creating a duplicate event.  The first error is easily correctable by the admin of the event, as they can edit what they have input simply by clicking on the event.  Events can be deleted for the purpose of inviting the wrong people, which is slightly more of a pain to correct but is possible to do.  In theory, if users check the list of events they have been invited to before creating a new one, so duplicate events should not be a common occurrence. If they were, however, it would be very obvious because the two events would be next to each other in the chronological list after the event is created. The user could identify this mistake, and correct it.  The error we find most difficult to correct is the one in which a user does not notice that they have been invited to an event.  They could fail to check the site regularly, or it could be hidden in a sea of events that are all scheduled for similar times.

Design #3: Map User Interface

...