You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Design

Remember to include images!!!!!

Our final design is composed of 4 main tasks:

  • Setting Preferences (Figures...)
  • Betting on Preferences (Figures...)
  • Deciding Restaurant (Figures...)
  • Exploring Restaurant Choices (Figures...)

Below, we provide screenshots of the final design, highlight notable design problems, and explain how they were resolved.

Setting Preferences

Problems:

  • Inefficient
  • Lack of learnability
  • Lack of flexibility
  • User model unclear

Originally in GR4, we implemented the preferences screen as two separate lists of location and cuisine selections. This made the process of adding and removing location/cuisine preferences rather lengthy. For example, to add a location preference, the user had to tap on the list, select "Add" from the "Edit Locations" context menu, and choose a location preference from a list on another screen. To remove a preference, the user had to tap on the item they wanted to remove from the list and then click "Remove" from the "Edit Locations" context menu. The system model supported exactly 3 selections each for location and cuisine preferences -- no more, no less. However, users (who did not read the "How To Play" instructions on the home screen) would not know about this limitation until they tried to advance to the actual game, in which case they'd be instructed to go back to the preferences screen to provide more or fewer selections. While the error feedback was helpful for first time users, this made the task of setting preferences rather inefficient, due to the likely trial and error process.

Solution:

In GR5, the list implementation was replaced by drop-down menus (as suggested by one of our heuristic evaluators). 6 menus were displayed -- 3 for location preferences and 3 for cuisine preferences, with each menu set to a default value of "Random". This made the system model more transparent to the user, allowing them to select up to 3 preferences for each category without having to provide error feedback for unsupported tasks. With the drop-down menu, the task of adding preferences was made simpler and the task of removing preferences no longer became an issue. The drop-down menus clearly provided more flexibility for selecting preferences and clarified the user model for players.

Betting on Preferences

Problems:

  • Inefficient (3 betting screens per category)
  • Unclear transitions between players
  • No affordances for undoing bets

During the paper prototyping session (GR3), the betting task was designed as 3 separate screens for each category of location, price, and cuisine. That meant that each player had to navigate through 3 screens to place their bets, lengthening the betting process. Furthermore, because the preferences were split up across 3 screens, it was hard for the user to visualize the distribution of their coins among the 3 categories, so they would often have to move back and forth between the screens to recall their earlier bets.

Solution (in GR5):

Deciding Restaurant

Problems (in GR4):

  • Lack of user control
  • Lack of visibility for decisions

Solution (in GR5):

Exploring Restaurant Choices

  • Difficult to go home

Problems (in GR4):

Solution (in GR5)

Implementation

Setting Preferences

Betting Activity

Spinner

Restaurant Details

Evaluation

Reflection

  • No labels