Scenario

Anjali is working at Microsoft. She wants to organize a group of coworkers to go to lunch at her favorite restaurant, Taco Time. She logs onto LunchBunch and decides to create a  Lunch Event at Taco Time later that day. She plans the lunch for 1:00pm and invites her teammates, her best friend at work Pallavi, and her boss Mike. 

Pallavi wants to go to lunch, but hates eating in the cafeteria alone. Through LunchBunch, she finds out that Anjali is planning a lunch at Taco Time that day. She joins the Lunch Event and now has people to eat lunch with!

It's getting close to lunch time. Mike sees that he got a notification from LunchBunch reminding him of his commitment to attend lunch at Taco Time that day. He is also asked to re-confirm that he is attending the lunch so that Anjali can get a final head count. He confirms his attendance, wraps up his work, and heads for Taco Time. 

Design #1 : Email Interface

...

These are the emails that are sent to the event creator and invitees upon creation of a new lunch event. The invitee email contains a hyperlink from the word "here" to a details page (8), in this case sent to Pallavi and Michael, and the admin email contains a hyperlink from the words "admin page" to a similar details page (9), in this case sent to Anjali.

Picture

...

8 and

...

9:

These are the emails that are sent to the event creator and invitees upon creation of a new lunch event. The invitee email contains a hyperlink from the word "here" to a details page (8) and the admin email contains a hyperlink from the words "admin page" to a similar details page (9).

Picture 8 and 9:

The Invitee and Admin links contain all details about the event as specified by the creator of the event. In the case that more than one location has been suggested, a poll is displayed for each attendee to participate in once they have committed to going to the event by clicking "Join". It is assumed that the admin is attending the event.

The Invitee and Admin links contain all details about the event as specified by the creator of the event. In the case that more than one location has been suggested, a poll is displayed for each attendee to participate in once they have committed to going to the event by clicking "Join". It is assumed that the admin is attending the event.

Invitees may choose to "Join" a lunch, after which the user may vote and the details page will display a "Remove Myself" button. If a user chooses to leave the event by clicking this button, Invitees may choose to "Join" a lunch, after which the user may vote and the details page will display a "Remove Myself" button. If a user chooses to leave the event by clicking this button, their vote becomes void. Admins may choose to edit and event, delete it, or confirm a location. If any of these options are selected, the updated information is emailed to the other invitees.

...

Design #1 Analysis:

Learnability:

Efficiency:

...

The biggest benefit to using this design is that all users, whether they are invitees or event admins, need not have an account or manage contacts or other personal information. This design provides all event communication through email and hyperlinks which are an already familiar tool to most people. This is particularly convenient for our user group, working adults, because email and internet access is typically something that is at hand. For this design, one will only need to visit the site when he/she wants to create a new lunch event.

Efficiency:

For the learnability benefits that come with no accounts or user contacts, the price is paid in efficiency. Although one does save the time required to maintain and organize contacts as well as the time it takes to check an outside webpage, the application keeps no information for repeat users. Specifically, when an event creator needs to send invitations, every time he/she creates a new event, he/she will be required to type his/her own name and email as well as the names and emails of all invitees.  Secondly, this design does not provide any central browsing, meaning that all interaction with created events is done through hyperlinks in emails. The problem here is that invitees and admins depend on the organization of their emails for quick access to the link that goes to the details page. This link could quickly get buried in emails.

Safety:

A big safety risk with this design is in the means by which the admin invites other people. On the 'invite guests' page, the creator is required to input email addresses for invitees. If any of these addresses are mistyped, the application has no way of indicating this to the user before attempting to send the invitation and then receiving a failure notice(which takes time). Because this is done through email, the the users of this design don't have to worry about losing a password, or having an account hacked, but do run the risk of misplacing an event link. This is the only way an admin or invitee can access the page, so if it is lost, it is difficult to recover.

Design #2 : Lunch List Browsing Interface

...