Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Corrected links that should have been relative instead of absolute.

...

To transition between players, a transition screen (showing a huge player flag) was displayed between turns. We used to to provide a more direct, obvious cue to users to switch turns in the game.

Deciding on Restaurant

Problems:

  • Lack of user control and efficiency (spinning the wheel)
  • Lack of visibility for decisions
  • Lack of responsiveness of spinner

The decision round generates a location, price, and cuisine based on a weighted randomness of each player's individual bets in the preferences round. The goal of designing the spinner was to make the decision process fair and fun. We decided to implement the decision process with a custom designed spinner because it is consistent with the gambling metaphor, simulates randomness, and is fun to manipulate. We also used the spinner as a powerful visualization tool for the distribution of preferences among the group, with each section of the spinner corresponding to a different preference and resized to reflect the amount of bets it received.

However, there were some usability issues that users noticed. In HW2, some noted the lack of user control over the spinner. They suggested that impatient users be allowed to stop the wheel at any point through a tap on the spinner. In GR4, some users commented that the decisions generated by the spinner for location, price, and cuisine were not very visible, as users were focused on the center of the spinning wheel rather than the top of the screen, where the decision results were displayed.

In GR3, users flicked the spinner at different speeds, expecting the spinner to respond accordingly. 

Solution (in GR5):

To make the process more efficient while still preserving the element of fun, we allowed users to tap the wheel to stop the spinning at any point. Furthermore, a pop-up message was displayed at the center of the screen (where the user's attention was focused) to display the decision for each category at the end of each spin. We also designed the wheel to be more responsive to the orientation and speed of the user's flick.

...

  • The betting screen was implemented by drawing text, numbers and images on an Android canvas. The text, numbers, and position of images are decided by user’s actions, which are detected by tracking the position of the user’s finger.
  • The whole screen is divided into different rectangular areas (boxes) that represent different options in each category (location, price, cuisine) as well as the three piles of chips (5, 10 and 25). Each box keeps a record of the number of each type of chips currently inside the box. The numbers (chips left, total points for a category) are updated based on the chips in each box.
  • An event listener is used to capture user’s actions. When the user taps the screen, the app checks if the position is inside any box and changes the value of a status variable to record the starting box of the action. If the starting box has chips, when the user moves his finger, there is going to be a chip following his/her finger. At the same time, each box recalculates the number of chips in it or the total points of chips left to decide the updated number of chips to show in the box. When the user’s finger leaves the screen, the position is checked and we decide based on the position whether or not the action results in the chip moving to a new box. Then all the numbers and status are updated and redrawn.
  • To make the app more playable and enable all the direct manipulations that a user can expect, the betting screen enables users to “drag” chips instead of just clicking the chip and clicking one destination. Also, it enables users to move chips freely, including moving from chip piles to betting table, moving within the betting table, and removing from the betting table.
  • To clearly indicate wrong alert users in the case of incorrect actions, vibration is added when the user fails to put a chip in a correct place.
  • The betting screen is made more realistic by not displaying chip piles of denominations greater than what the user has available for betting.

...

  • Restaurant choices and details are gathered by searching the Yelp API. Each search starts with one call to the Yelp API, with the parameters for location and cuisine. The API does not directly return price information, so restaurants are filtered by price by scraping their Yelp info pages for price information.
  • We use a die (instead of the generic star representation) to show the restaurant ratings and location, which are widely like liked by users (“It’s so cute!”).
  • We use the standard style and style color of a hyperlink to suggest that the texts for phone number and address are tappable.
  • We use the standard dial activity of Android to place phone calls and Google map Android API to pinpoint locations.

...

Our users generally liked the concept of the application, but found a few minor usability problems and possible enhancements. One suggestion from a user is an auto-fill option for the betting screen, to not require each user to use all 100 chips in some way. On the other hand, users did comment on the usefulness of the built-in help functions.

Reflection

These are things that we learned during the course of this project:

  • Early stage design is crucial to the success of a UI project, including the design of tasks, paper prototyping, and early stage user testing. The cost of time to correct a bug or an improper design in the early stage is much smaller than that in the implementation stage or even in the user test stage after the implementation. The spiral model rocks!
  • Sometimes the problem appearing in the paper prototype will no longer be a problem in the computer prototype or for the final implementation. For example, the users enjoyed the app more when playing with the implemented betting screen and spinner than they did when we simulated those parts in the paper prototype.
  • It is important for the app to be useful, and being fun and playable is a plus.
  • The first few stages were the most difficult. Once we identified the right ideas and figured out how to make them into a game, the implementation was straightforward. Implementing the interface was time-consuming, but we had a clear goal in mind at that point.