Design
Our design has two main types of pages. The first main layout is of the suggestion cards. They are displayed in a window that has filters along the bottom and transparent arrow buttons to suggest swiping (that are also clickable). Each card displays a name of a suggestion, an image of that suggestion, an icon on the upper left corner that says what type of suggestion it is, as well as a “find it” button. We chose this card layout after doing the paper prototype phase where we had a scroll list version of the prototype as well as the card display. A majority of the users prefered the card display, saying that display was more fun and that they liked having images.
Our other type of main page is the information page that the user is sent to after pressing “find it”. There are four different types of these pages, one for each type of suggestion. The food and place info pages display a map with your and your location’s destination on it. It also provides you links to google maps, yelp, and a star rating. The book info page displays the title and author of the book as well as a description. It has three buttons on it: one for the library, one for a bookstore, and one for the kindle store. The movie info page provides the title of the movie, the star rating, the MPAA rating, the runtime, and a description. The page also has two buttons: one for theatre listings and one for IMDB. The types of buttons on the info pages were tailored to fit user input after the paper prototype round.
Our design also has two layouts brought up by selecting the menu. The first is a list of all of the suggestions a user has deleted (by pressing the X button) and the second is an about page that displays a short summary of the goal of our application (in case the user didn’t read the Android marketplace description)
In our final design, one main change we made was just to have one main button on each card (the “find it!” button). Previously we had a “find it!” and a “this sucks!” or “never” button. The negative button confused our users in the paper prototype as well as in the heuristic evaluations. We wanted to keep the feature of being able to permanently remove suggestions from a pool so we did this by putting a little (X) button on the top of each card. We believed that since this was externally consistent with other applications it would be easier for the users to identify its function. When doing user testing, User 3 said “I never want to go to Fenway” and then used the delete button which suggested at least one of our three users understood the function of this new button.
...
We also assumed that our users are familiar with the basic conventions of operating an Android device. Each Android device has back and menu buttons built into the hardware and we decided to use these buttons according to standard Android convention. Our application requires our users to navigate forward through a series of screens to find more information about the suggestions that they receive. Since the built in back button conventionally brings up the previously visited screen, we decided to use it to allow the user to retrace their steps for the sake of consistency. When a user doesn’t know what to do next when operating an application, they typically turn to the menu to find out what options are available to them. Therefore, we added our applications additional options to a pop up menu that rises whenever the user presses the menu button on the Android device.
Implementation
Our application was created for Android 2.3.3 and as such we did all of the coding for the application in Java using the Android library. We also used third-party libraries to hold the cards and swipe between them and for parsing JSON responses from our server.
...
We stored almost none of the data locally, and the only persistence provided by the app is currently purely due to Android’s multitasking capabilities. That is, if the user leaves the app and comes back soon, they pick up where they left off, as expected, but it does not currently avoid showing the user the same suggestions repeatedly if they close the app and come back some time later. This was fine in the testing case, but would be less than ideal in real-world use.
Evaluation
We found our users around the Burton Conner dorm. Our target user population is college students who are bored and looking for something to do, so these procrastinators were a perfect fit. We had two guys and one girl, including one freshman, one sophomore, and one junior.
...
Description: This application will use the power of suggestion to help a person decide how to spend their free time by recommending food, books, movies, and places to go.
Tasks:#
- You’re looking for something fun to do, but you just came from lunch, so you don’t want food.
- You’re a picky eater. Find somewhere to eat that has at least a four-star rating.
- Find a book you would like to read.
- You used to be a horrible person, so you deleted Harry Potter from your suggestion pool. Add it back now.
...
Our final problem was just that one user, lacking experience with Android, did not know to try hitting the menu button to reach the list of deleted items. This would not be a problem in real usage, but we could also implement the brand-new Android 4.0 standard of also having an on-screen contextual menu button.
Reflection
The main thing we learned from the iterative design process is that we are not our users; design decisions that seemed obvious and intuitive to us completely baffled some of our users in the paper prototype round. It was hard for us, after spending so much time looking at our own design, to look at our prototypes with fresh eyes. The paper prototypes and the heuristic evaluations both helped us to step back and look at our design anew.
...