GR6: User Testing

Design

In the end, we decided that the white pane layout best illustrated our step-by-step food ordering process. We grouped together all of the pre-order steps on one page to really show how few steps the user needs to take in order to get begin a food order. Lastly, we decided to put food in the background, because not only will it spark an unsure user's appetite, but if this were a small business, we could use this as advertising space for restaurants in the area (they could send us high-resolution photographs of their menu items, pay a small sum of money, and we could "feature" these food items). 

For this panel, we knew we had to implement some sort of search and ordering, as there are many restaurants in a given delivery area. However, our computer prototype exposed some design problems that had gone unnoticed. For example, we wanted to highlight the background of selected restaurants, as well as dynamically highlight restaurants when the user hovered over them. However, we never made a distinction between hovering over a selected restaurant or hovering over an unselected restaurant. So, in our final product, we chose two distinct highlighting values. In addition, we also noticed that on the food-ordering sites we were using, restaurants were often listed under multiple categories. Therefore, we made the decision that if a user selected, for example, "Chicago Pizza" under the pizza category, the corresponding "Chicago Pizza" in the American category was also selected.

For this panel, we wanted give the users the flexibility of either inviting Facebook friends or sending a mass e-mail out to a list (or inviting non-Facebook friends). Who is logged in is prominently displayed so there is little chance for a mistake. In addition, the "Add Friends" box for Facebook utilizes the exact Facebook way of filtering/choosing friends, so this offers users a familiar experience. We direct people to enter friends' emails with a grayed out cue in the correct box.

Though there were suggestions to cut this panel and merge it with the add friends panel, we decided to keep this panel both to avoid clustering and to provide the users with a fairly large and obvious continue button. In addition, the third panel was more aesthetically pleasing with regards to the overall layout.

If the initial user didn't narrow down restaurant selection to one restaurant, this page is the next one that comes up. We debated a lot over how the site would behave depending on how many restaurants the organizer selected. In the end, we decided that if the user selected only one restaurant, then they would be taken directly to the ordering page. Otherwise, they would be brought to this voting page setup.

We initially had two radically different ideas regarding the voting system. One was very similar to how Doodle operates, with a binary voting system (the one we ended up choosing). The other was a "up-vote" "down-vote" system similar to reddit. We eventually decided to incorporate the Doodle system, as it was the most straight forward for the users. In addition, this part was the most difficult to display using our layout. During our computer prototype, we only showed two restaurant possibilities. As one of our classmates pointed out, this design wasn't feasible for scaling. In the end, we decided to implement a scrolling display. Unfortunately, this does cause a significant decrease in visibility. However, we want to give our users the most flexibility in restaurant selection (ie, not limit to only 5), and given this, a user can ultimately select all 30+ restaurants, we needed to have some sort of scrolling display. Lastly, only the organizer can see the "choose" buttons, so there is little in the way of confusion.

This was also another box that we had some trouble designing, as there wasn't enough room on the screen for both aspects. We wanted the social aspect of the chat box, but at the same time, the organization aspect of the order box was also necessary. However, we realized that people probably wouldn't be analyzing their total cost and talking to people at the same time for the most part. Therefore, we combined the two into one tabbed box that defaults to the chat. In addition, we also send order messages to the chat box ("foo has ordered bar") to alert others that there are orders taking place, as during the paper prototype testing we found that some people didn't quite understand that everything about this site is social (including the ordering), so we wanted to take no chances with someone not seeing who has ordered what.

...

In addition, during paper prototyping, users were having trouble figuring out when their friends were done ordering, and many often pushed the order before their friends had finished ordering. Therefore, we decided that we needed a means to make it very visible when someone is done ordering. Therefore, we added this bottom paned with icons for each person. Initially for the computer prototype, the bar was subtle and contained all of the Facebook photos of the people in the order and grayed out text that turned white when the person finished. However, users of this prototype pointed out that there was nothing to draw their eyes down to that part of the screen, and that the change was far too subtle. Therefore, we changed it to the current red X/green checkmark.  Even this, though, seems not to be effective enough.

Implementation

Because of the large backend and the necessity to communicate between multiple computers, we decided to use Ruby on Rails as our back end. Though it took a long time to convert our computer prototype to Ruby on Rails (as we had not yet made a final back end decision regarding final implementation as of GR4), it was very worth it to implement the change. To communicate over multiple computers, we used a message system where the back front-end would post messages to our server, as well as look for updates every couple of seconds. That way, we could implement an entire message hierarchy that included chat messages, ordering food messages, restaurant selections messages, etc. , and react to them client- and server-side.

Unfortunately, we had many problems meeting our initial goals with our back end. First, we were counting on getting some sort of API from Campus Foods or Foodler. However, neither company responded to our e-mail with anything useful (we got a "I'll forward this on" sort of response from Foodler). This meant that there was no simple way to hook up our interface so that people could actually order food. Therefore, we had to spend extra time gathering menus from Campus Foods and didn't end up hacking our way into either site to send orders, as we felt that doing so would detract from the large amount of other work that we needed to get done.

In addition, we had problems synchronizing our system to handle multiple users. In the end, we got a lot of simple things working, but there were still some large visibility issues that arose. For example, there were times that messages would just get dropped. However, we had the most issues when it came to adding people to orders. Sometimes the already present users would have to refresh their screen to see the new person added. However, since we never got around to the process of storing data through refreshes, orders would be lost upon refreshing. In addition, for the same reason, when a user would join the order , they wouldn't see all any of the previous activity, as we only did the "live" portion of the backendfood orders placed by other users.  Chat activity, though, was persisted through sessions.

Lastly, some things just didn't quite get finished the way we wanted. Voting never actually got counted, as we couldn't quite figure out how to trigger the proper handlers with multiple users. Also, though we made an affordance for users being done, we didn't quite finish that implementation to change the status to "not done" if the person were to try to change their order after they click done.

Multi-user syncing problems

Consistency problems

Evaluation

Briefing

Hungr is a way to order food with friends. It allows you to arrange a group order collaboratively, giving your friends input into choosing the restaurant and allowing them to order their own food.

...

Issues (in mostly chronological order)

Problem: User wanted to enter more than one email at once on the invite screen.
Severity: Cosmetic
Solution: Allow entering multiple e-mails at once, separated by spaces or semicolons.  Indicate as such on the interface.

Problem: On the first, organizational page, the current restaurant selections are hidden by scrolling or searching.
Severity: Major
Solution: Allocate (dynamically) a box beneath the search section that displays current restaurant selections at all times.

Problem: A user was unsure that their votes on the restaurant selection page were being propagated to the other users (and didn't notice the other users' votes appearing).  "How do I vote?" she said, after clicking a few of the checkboxen. The other users were able to identify the process, though, so this is possibly due to unfamiliarity with "web 2.0" interfaces. 
Severity: Minor
Solution: Indicate other users' votes through color changes and on the voting panel and the count on the bottom.  Do the same thing for your votes.  Hope that this conveys the information.

Problem: Users are unable to indicate that they are done with voting.
Severity: Minor
Solution: Add a button to allow users to show that they are done (more on this later).

Problem: Users are sometimes unsure what happened when the screen transitions from one section (e.g. voting) to the next (e.g. ordering) through an event outside their control.  This happens when the organizer chooses a restaurant.
Severity: Minor
Solution: Add a modal div explaining to users why they are transitioning.  Announce the restaurant choice in that div.

Problem: There is minimal feedback when ordering items. This increases the chance of mistakes.
Severity: Major
Solution: Provide an "active" style for the menu items such that it is obvious when one has purchased them.  Also indicate it on the order/chat tabs, possibly with a number indicator on the order tab.

Problem: The name for the current user (the one you are, e.g. "cmerrill") is displayed when ordering items, but "You:" is displayed when chatting.  This is inconsistent and possibly confusing.
Severity: Cosmetic
Solution: Either show the username for both actions, or show "You" for both. Just be consistent.

Problem: It wasn't obvious to most of the users what the icons in the bottom left (the "done icons") were meant to indicate until they noticed one of them change to a check mark.
Severity: Major
Solution: Possibly place a user list on the right, rather than the bottom, and make the icons higher-contrast so that the X's and check marks are more clear.

Problem: Organizers were unsure as to how they could indicate that they were done.
Severity: Cosmetic
Solution: Replace the organizer's done icon with a different one, e.g. an "O" or a crown, to make it distinct that they have control over the whole thing and don't need to indicate when they're done.

Reflection

From this project, we learned a great deal about the design process. Initially, we had many problems adhering to the prescribed process. We often found ourselves arguing about later details in the earlier assignments. For example, we were discussing implementation during GR1, and fonts and aesthetics during GR2 (as well as GR3). In addition, we were often reluctant to scrap already made ideas early on (though in the end, we did change our entire project idea after GR1, which was honestly one of the best design decisions we made). Once we focused on the current tasks, however, the design process ran smoothly and there were far less tensions among the group. 

...