Design
The purpose of our application is to allow users to browse lunch invites, respond to lunch invites and create new lunches. For simplicity, we chose to limit the main navigation to two main tabs: "Lunch Invites" and "Lunches I'm Attending". Lunch Invites have 4 states: declined, accepted, confirmed(if it has been requested by the creator), and unknown(for those invites to which you have not responded. Accepted invites and subsequently confirmed invites appear on the "Lunches I'm Attending" page. Invites to which the user has not respond or has declined appear on the "Lunch Invites" page. Both these pages are set up as browseable lists. The user may click on a particular lunch to view its details. For this general design, the biggest gain from user testing was in the wording in our application. We went through multiple iterations of labels for the tabs and labels, eg. "joined", "my lunches", "unjoined", etc. before deciding on the set that made the most sense to the most users.
Figure 1: Image of the application when first Figure 2: Image of the Lunch Details page. Initially,
...
top right hand corner will be modified accordingly.
A notable feature of our design are event reminders and notifications. If, in creating a lunch event, the creator chooses to send reminders to invitees and optionally also request confirmation, a push notification will appear on all invitee phones at the pre-determined time. We chose to implement notifications in this fashion to be externally consistent with other android applications. Similarly, other features of our application, such as the hardware back button and the text and calendar forms, perform operations identical to those in other android widgets for better learnability.
Figure 3: An android push notification. These notifications alert
...
Clicking on this notification will take the user to the appropriate
event details page.
From either the "Lunch Invites" or "Lunches I'm Attending" page, the user may choose to create an lunch invite of his/her own. Creating a lunch invite involves a two step process which, through our user testing, we refined to be as simple as possible. Conciseness and clarity were particularly important to ensure that all the necessary information was gathered from the users, and that the small amount of UI real estate on the phone was used as efficiently as possible. Multiple backend checks were built into the create lunch forms to avoid errors (such as lunches set to times that have passed) and some parts of the UI adapted as the users inputted information (for example, if no reminder was requested, further prompts about reminder and confirmation settings were hidden).
Figure 4: The create lunch form requests Figure 5: After the user clicks "Done" on the create
...