a. Low-fidelity Prototype video
b. Description of Prototype
We have chosen to support all three of our task examples mentioned in our blog post update #2. Our prototype covers the following requirements:
- Creation of events: allowing users to add necessary details to an event (time, location, etc.) with the option to let some event details to be TBD (to be determined) so that users can work them out with invitees and reach consensus (refer to point d).
- Editing of an event: event details can be edited by the event creator and these updates are visible to users on their app homepage.
- RSVPing to an event: invitees of events can accept/decline an event and see who else is attending. Once the event has been accepted, the event creator would be notified about it.
- Consensus building: event detail fields that are labelled as TBD would allow for discussion of possible options between event creator and the invitees. Invitees would give their suggestion on the chat page and other invitees are allowed and encouraged to endorse the suggestion. Top suggestions from the chat would be displayed on the event details page.
- Notifying friends of your availability: being able to set your status to be free or busy and other users being able to see this.
While most of these seem pretty standard features for most event planning applications out there (i.e. Facebook events) and were necessary in our prototype to serve as the foundation or backbone of the application, the task of “consensus building” for spontaneous events via the interface is a unique one and intrigues us. In our field study, people fell firmly into one of two camps when making plans: some people were more authoritative while some were open to others’ preferences, usually discussing through text or face-to-face to reach a group decision. To try to better understand how these two approaches affect spontaneous event planning, we opted for two different designs for consensus building – a discussion/suggestion and a simple voting system. The discussion system would be better suited for the latter group; it lets users make suggestions and chat with each other about event details. Each suggestion can be endorsed by other invitees and the top suggestions would be displayed on the event details page. This would be a more collaborative experience but may take too much time or effort for spontaneous event planning. The other design would use a voting system where only the event “admin” can create new polls. He would also be able to create multiple polls about different event details like time or location. This design would give the admin to make the final decision and would appeal to people who are more authoritative when building consensus.
c. Walkthrough Report
While we determined through our cognitive walkthrough that our task examples were reasonably supported through users’ actions on the prototype and users were able to mostly figure out how to fulfill these tasks, there was quite a bit of confusion as to how certain elements were presented. While some of these cases were minor, there was one instance where it affected the performance of a task, with the user ultimately requiring our intervention to successfully resolve the problem. Ultimately we need to implement some changes to our design to clear it up a bit more.
Task 1: Creating an event
The homepage interface was clear enough for the user to assume the events on display were those already happening. The user also understood how to set their availability status to show that they were free and in the process of creating an event, and after making the event, they anticipated a confirmation screen which our interface provided. However, during the actual task the user was unclear what “TBD” meant and that it had to be checked to leave the event open to discussion. Additionally the user thought the TBD label on the event screen afterwards was a button. The user also wasn’t sure what to name the event, and was confused over some of the icons/labeling (for instance, the contact icon seemed to look like a menu icon instead and the user wasn’t sure what making an event “private” entailed, though “public” was straightforward). The user also expected to be able to edit contacts on the confirmation screen but our interface currently doesn’t allow that.
Task 2: Editing an event
The user had no issue with editing an event, as they quickly found the “edit” button and made all necessary changes. However, the user once again was confused by the iconography (the contact icon appearing as a menu icon) and the user was wondering what happens when you change an event from Public to Private later on. This is something we hadn’t considered beforehand.
Task 3: Consensus building
The user understood that top rated suggestions were visible and lower rated suggestions were filtered out on the event screen, however, when moving to the discussion chat they became confused by some of the layout and content. They saw too many numbers and were unsure about whether the “+1” button meant endorsing a suggestion or simply the total number of votes. They also weren’t sure how the chat was organized, and furthermore how to make a final decision from all of the information provided. They also were unclear as to what “suggest” meant.
Task 4: RSVP to an invite
The user was asked to accept an event invite, but struggled at this task as they were confused by the “Accept” and “Decline” buttons as drafted in our prototype. Clarification was required for the user to proceed with the completion of this task.
d. Revised Task Examples
For task example 1, we needed to change the task example as our interface does not afford the ability to rank choices. Our interface allows people to interact with each other and propose suggestions.
No revision was needed for task example 2 and 3.
Old and updated task examples can be found here.
e. Proposed goal(s) of experiment
Our proposed experiment goals are as follows:
- Test the visibility of a group’s suggestions and preferences between the two design alternatives by measuring how long it takes a user to see what the group consensus is. Assuming that there has already been some discussion as to what everyone wants to do, the goal here is to see how fast and easy it is for user to interpret the group’s preferences about the event.
- Test how the two design alternatives for users each affect the amount of time required to reach consensus within a group. This goal is more concerned with how people reach consensus and the benefits and drawbacks of each approach, and how our system can support it.
- How fast do people react based on the time of the event. We want to measure the time between sending an invite and getting a response. The goal is to see the effect of a time constraint on invitation response times. We want the system to promote users to respond quickly due to the nature of our application.
We will address the first goal in our evaluation because it seems to be the most feasible option. It is also more important because it addresses our design goals more closely. We are very interested in seeing how to represent the group’s preferences when consensus building.