Screenshots
Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7
Figure 8 Figure 9 Figure 10 Figure 11 Figure 12 Figure 13
Design
The
Design
Remember to include images!!!!!
Our final design is composed of 4 3 main tasks:
- Setting Preferences (Figures...Figure 1)
- Betting on Preferences (Figures ...6, 7)
- Deciding on Restaurant (Figures ...)
- Exploring Restaurant Choices (Figures...)
- 8 - 11)
Below, we provide screenshots of the final design, highlight notable design problems, and explain how they were resolved.
...
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 between 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 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 (in GR4):
- Lack of user control and efficiency (spinning the wheel)
- Lack of visibility 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
...
- 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.
Implementation
Setting Preferences
- The preferences screen was implemented using the Android spinner widget for the drop-down menus.
- The app uses the phone's persistent storage for saving preferences across usages of the app.
Betting Activity
- 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 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.
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.
Restaurant Details
- 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 liked by users (“It’s so cute!”).
- We use the standard style and color of a hyperlink to suggest that the 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.
Evaluation
We briefed our users with a short description of the application and its purpose, and left it to them to figure out how to use the application. Our users started by looking at the “how to play” screen. After reading the instructions, our first user went to the preference-setting screen, and commented declaratively that that was for setting her (individual) preferences. We did point out that the preference-setting screen was intended for the whole group, but that point may still have been lost; another user (playing the game with the first) never saw the preference screen, and was not aware that there were other options for cuisine and location beyond the three that were presented in the betting screen. We realized that the main “how to play” screen did not indicate that the preference-setting screen was for the whole group; we could add that fact in the text on the “how to play” screen, and/or provide a screen similar to those for transitions between players indicating that this screen is for groups.
One player used the betting screen without reading the help and seemed to figure out how to use it without aid; another player did search for instructions, and we had to point out the help button. The help button is out of the way and not visually distinct; we could attempt to make the help button more noticeable.
It was not entirely clear to our users what to do at the end if they do like the restaurant that was chosen; one user wondered if there was some way to save that restaurant as a good choice, to enhance decision-making in the future.
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.