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.

Since we developed an Android application, we made some unconventional design choices. We assume user has a basic overview of what the application does before they open it for the first time. Since Android applications must be downloaded to a user’s phone manually, they couldn’t stumble across our product by accident. We designed our application under the assumption that anyone that has our product downloaded it from the Android app store, and has thus already seen the screenshots, videos, summary of the application’s functionality, and user reviews that are on the download page. Since we’re assuming that a user has a basic understanding of what our application does before downloading it, we don’t differentiate between a first time user’s experience and a returning user’s experience; upon opening the application, the user is presented with their first suggestion and dropped right into the application.

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 created a server in Node.JS that communicated with the Yelp, Rotten Tomatoes, and New York Times Bestseller List APIs.  We could query the server with standard HTTP requests to get suggestions. Our number of suggestions of each category was limited by how many we could quickly get from each of the APIs in a single request, as dynamically requesting more would have been a significant amount of additional backend work. This might impact the user experience if they continued swiping for an extended duration, especially in a single category.

Reliance on these external APIs restricted the features we were able to provide to some extent. Yelp’s API, for example, was not able to provide complete descriptions of the locations we were suggesting, and the NYT API had no available ratings, and using a fourth API to get them seemed beyond the scope of this project.

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.

In conducting our user tests, we wrote up a briefing that described our application. We gave each user the briefing and our four tasks on paper, then asked them to narrate their thoughts and actions as they went through the tasks. We decided on this method of briefing in order to be as close as possible to the expected user introduction to our application; namely, that they would read a description on the Android Market, then download and launch the app.

Briefing:
Name: Suggestible

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:

1. You’re looking for something fun to do, but you just came from lunch, so you don’t want food.
2. You’re a picky eater. Find somewhere to eat that has at least a four-star rating.
3. Find a book you would like to read.
4. You used to be a horrible person, so you deleted Harry Potter from your suggestion pool. Add it back now.

Our users still had momentary trouble with the filtering system in our application. Two of them figured out the filters very quickly, tapping one of them and then realizing how they worked. One user took a minute or two to figure out how the filters worked, and could not easily and intuitively tell the state of the filters at a glance. Our strategy going forward is to change the design of the filter buttons slightly to make the state of the system more obvious by adding a green light on each of the buttons that will be on when that category is enabled and off when it is not.

Another problem, potentially one which arose because the user was reading too much into the tasks and which would not be significant in actual usage, was that one user wanted to filter by star rating in task 2. They tried out long-pressing on the “food” category and hitting the menu button before realizing that there was no way to filter. We could add a long-press action to filter by stars for advanced users, but this behavior would be unlikely to be discovered. Instead, it probably makes more sense to just include the stars on the front card view instead of just in the details screen.

A couple of users brought up the question of whether or not the library or bookstore that we directed them to did, in fact, have the book they were looking at in stock. Ideally we would have access to an API for this information, but this is not readily available. We could instead direct them to the search functionality of the location’s web site.

One user attempted to see more info about the suggestions by tapping on their image. We should make the images link to the details screens.

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.

Having both the computer and the paper prototypes was very useful because new errors were created by increasing the level of detail as well as some old problems resolved (in part). We were convinced during the paper prototype round that our users weren’t understanding the filters at first because the paper buttons were not detailed enough to show state.  By doing a computer prototype we were able to assert that the users had less trouble figuring out the state of the filters when color and computer graphics were involved but that it still remained a slight usability problem that was usually figure out by trial and error.  Both the computer and paper rounds were crucial for our design process.  Since the paper prototypes were so cheap, we were able to test two different designs of our prototype and get feedback as to which was better.  The computer prototype was also crucial for figuring out which little design details were liked and accepted by our users and which were confusing.  From the feedback from these two rounds we were able to settle on our most recent design which fared well in user tests.

Choosing a relatively self-contained project allowed us to focus on the design and implementation and build something that was actually functional, and so if we were to do it again we would choose something of similar scope again. However, the strong reliance of our application on external APIs meant that for a design project, there was a significant amount of backend work required, and due to the limitations of these APIs we were also unable to provide a few features that we wanted that would have increased the usability of our design. As such, we might choose a project that required less integration with outside services in the future.