Design
final design is composed of 3 main tasks:
- Setting Preferences (Figures...)
- Betting on Preferences (Figures...)
- Deciding on Restaurant (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 va
lue 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)
- No error handling for incorrect bets
- Unclear transitions between players and groups
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 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 chips among the 3 categories, so they would often have to move back and forth bet
ween the screens to recall their earlier bets. In GR5, users were not allowed to undo their bets if they changed their minds or accidentally dragged the chips to the wrong preferences. As a result, players had to start over with the entire betting process if they made one small slip.
To transition between players, a "Done" button was placed at the bottom of the betting screen (GR3), and a player label was displayed at the top of the screen, indicating which player's turn it was. However, these visual cues were insufficiently visible, as most users had to be verbally instructed to pass the phone to the next player in the group.
Solution (in GR5):
To make the betting task more efficient and visually informative, we consolidated three screens, allowing users to bet on the three categories of location, price, and cuisine all on one screen. Each section of the wheel corresponds to a preference that was bet on in the previous betting round and resized to reflect the total number of chips that were placed on it This gave users a better visualization of their bets and allowed them to complete the task more efficiently. To aid them with the task, we provided a contextual help menu that graphically displayed what the screens should look like, as well as written instructions about how to distribute the chips through dragging.
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. Furthermo
re, 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 spe
ed of the user's flick.
Implementation
Setting Preferences
Betting Activity
- The betting screen was implemented by drawing texts, numbers and figures on an Android canvas. The content of texts, values of numbers and the position of figures are decided by user’s actions, which are detected by tracking the position and behavior of user’s finger.
- The whole screen is divided into different rectangular areas (I call them boxes) that represent different alternatives in each category(location, price, cuisine) as well as the three piles of chips(5, 10 and 25). Each box keeps 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 record of each box.
- OnTouch event 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 current 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 user’s finger leaves the screen, the position is checked and we decide based on the position whether or not it’s a effective action to put the chip in a new location(box). Then all the numbers and status are updated and redrawn.
- To make th e 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, removing from the betting table.
- To make clearer feedback of wrong actions, vibration is added when the user fails to put a chip in an effective place.
- Making it more realistic by making a chip pile empty when the chips left is smaller than the face value of a pile.The betting screen was implemented by drawing texts, numbers and figures on an Android canvas. The content of texts, values of numbers and the position of figures are decided by user’s actions, which are detected by tracking the position and behavior of user’s finger.
Spinner
- The spinner is implemented using Android's drawing APIs to draw wedges of a circle on a canvas, and draw text on top. The backend keeps track of the amount of rotation applied so far, and drawing is done relative to that amount of rotation. The spin animation is achieved by increasing or decreasing the degree rotation at timed intervals, and redrawing the wheel. A swipe gesture is detected by dividing the screen into quadrants and waiting for a finger-swipe that starts and ends in adjacent quadrants.
- The victor is determined by precomputing the final wheel spin once the user starts spinning the wheel, and computing which wedge is under the pointer drawn on the screen when the wheel is in its final location. The winner is predetermined so that a user can't game the system by trying to stop the wheel in a particular position.