R6 : User Testing

Design

Overall, we finished our design and implementation since GR4.

Below is a brief design document expressed by way of annotated screenshots.

Image Added

We are proud of our Journal view, and feel that our mapping between items in a list and items on a map is innovative.

The animated arrow makes it look good, so we show off the animation as a gif.

Overall, we decided to focus on presentation of the timeline. The view and edit functions are functional, but we have not innovated in that area.

We decided to disable selection of the map markers - It is a little practical because the touch screen has so many markers, and the arrow partially obscures them.

We chose to use a perfect triad of colors (leaf green - purple -blue) in our application for aesthetic reasons, but these colors also offer great contrast with the map and with each other. The colors perform fairly well from the point of view of color blindness, though this was not our main focus, and any triad will have diminished color blindness safety between one of the three pairs of color.

The arrow is shown tapered because it emphasizes its fluidity and direction, but mostly helps keep the map markers (which are more important) uncluttered.

...

We made the following design changes in response to user feedback:

...

(We incorporated almost all suggestions and points of criticism, except the few explicitly stated at the end of this section).

Journal view (map) mode:

• Map is now interactive
• Map icons are now positioned at the center of locations, not right above them
• There is now a direct mapping between entries in the list and entries on the map, using colors
• When creating multiple entries, the list automatically scrolls to the end to keep the add button and the most recent entries on screen.

View Mode:

• View now displays a location hint ("near <city>")

• User can make swipe gestures to navigate between consecutive entries

Edit Mode:

• When exiting the edit mode with unsaved changes, user is asked to save or discard the entry. Entries are no longer automatically saved.

We also incorporated all other (and more minor) feedback into our final design EXCEPT:

• We chose not to reverse the order of items in the list. The suggestion was made because the "add" button and the most recent entries disappeared from view when adding multiple entries. We remedied the problem by automatically scrolling to the end of the list to keep the add button and most recent items on screen by default.
• We chose not to add individual delete buttons to photos in the edit mode. Doing this would be more consistent with iOS, but not with our target platform (Android).
• We chose not to allow the user to share multiple entries simultaneously. The only good example of this functionality is Google's Gmail app, and we felt that their use of check boxes are more annoying than useful. We kept the view simple.

Implementation

We have two main "Activities" in our code implementation. One is "JournalMapActivity", which corresponds to the journal/timeline screen. It is in charge of presenting the map, recalculating the arrow positions, and plotting the star markers. It also keeps track of the scrollable list of entries.

Once you tap to view or edit and entry, you enter "ViewEditActivity". This is the second activity that deals with both view and edit modes. We decided to keep both view and edit modes in the same activity, because these modes share a lot of the same information. It would also be slower if we had to navigate between different activities so often. The activity keeps track of which mode (view or edit) should be active, through the use of a Boolean value. It is in charge of displaying the appropriate "+ Photo" and "+ Contact" buttons, the photos and contacts themselves, and the textual descriptions.The menu items are also different for each mode.

We implemented an Entry class, which stores everything that can be part of an entry. This includes the timestamp/location of when/where the entry was made, its photos, text, and contacts. These entries are all stored in our database. Whenever a user views a previous entry, the system will look it up in the database, and retrieve and display the appropriate information.

We ditched a persistent database due to implementation issues (we likely did something wrong) if favor of non-persistent application state. All entries are deleted when the application is force-closed. We feel that persistent state is not an important factor in the UI design of this application.

The map utilizes the Google maps API which is actually very different from whatever is used by the Google maps app: instead of drawing vector graphics at arbitrary zoom levels, the API fetches pre-rendered images of the map at powers-of-two levels of zoom. This makes automatic zoom-to-fit operations very awkward (the one provided by the API does not guarantee that all points of interest are actually on screen, so we wrote our own).

Other than that, the map is easy to work with: we draw the map points and arrow in a separate canvas layer by manually translating geographic coordinates to appropriate locations within the map container. One important note regarding the Google API is that it requires an API key given to a specific key pair associated with an installation of Eclipse. This means that only one member of the team may work with the API unless the same key pair is shared by all developers - not something that would be acceptable in a diverse development environment.

...

What we omitted

...

We moved away from using undo functionality for our app because we did not come up with a clean, reliable way to incorporate it into the design. We felt that doing a good job of everything else is more important, and most Android app do not feature any undo anyway.

Evaluation

User Test Scenario

First, we told users about the purpose of our application. We also explained that it will be on an Android device, and mentioned that using the back button, menu button, and the context menus are standard for Android applications.

Our tasks have not changed since the paper prototyping phase. We asked users to perform the following:

GR3

Prototype Photos

We used index cards to represent the Android phone and long strips of paper for our scrollable areas on screen. We also used transparencies and dry erase markers for the editable parts of the UI.

Refer to GR2 for an explanation of what each screen is for. Refer to the end of this document for a summary of design choices from GR2 incorporated into this prototype.

These photos are of Version 2 of our prototype.

Timeline

Two elements of the UI: a chronological list of journal entries, with the "new entry" button always positioned as the most recent entry, and a map that automatically re-sizes and moves to include all posts currently visible in the entry list. A prominent arrow is loosely fit to the entry points on the map to indicate a rough direction of travel. The arrow is animated as the user scrolls the entry list. Entries in the list accept right clicks (click & hold) to share, edit, or delete the entry.

The prototype is limited to horizontal scrolling only for the map (of made-up Siberia or something like that), and is limited to about 20 journal entries. The arrow is fixed, not animated, and only roughly corresponds to the users' direction of travel through the made-up landscape. The prototype is otherwise accurate.

Image Removed

Edit Mode

More or less identical to the View mode, except for added affordances for editing consistent with other Android apps (outlined white background for editable text, cursor, and buttons for editable fields such as time and location). A save button is also present in the lower right corner. Scrollable and accepts right clicks (click&hold) for inserting data such as photographs or contact info. Photographs or contact info accept right clicks (click & hold) allowing them to be deleted.

Image Removed

Image Removed

Image Removed

View Mode

More or less identical to the Edit mode, but omits all affordances for data entry. Scrollable and accepts right clicks (click&hold) to share, edit, or delete the post. To inform the user that the post can be edited, deleted, or shared, buttons for this content (also accessible via click&hold) appear at the lower edge of the screen initially, and whenever the screen is scrolled. The buttons fade out of view when the user is idle.

Image Removed
Image Removed
Image Removed

Briefing

This paper prototype represents a design for our mobile application, The Travel Book. The Travel Book can be used to maintain a timeline, or a timed journal, of all your traveling experiences. Every journal entry can contain textual descriptions, photos, and/or contact information.

A few things a user should know before testing:

• This is designed for an Android phone-- Holding down on a screen is similar to right-clicking on a computer. Also, the four buttons below the screen are a part of our interface.

• Please let us know whenever you want to tap/scroll a screen-- we'll show you what happens (or what doesn't happen).

• For all text inputs, assume that a virtual keyboard will pop up. In the actual testing, however, you will be using a pen, and write by hand over the "editable" transparency.

• For all inputs, the cursor is, by default, located at the end of the last piece of input provided by the user.

...

Task 1 - View a previous entry on your timeline.
Task 2 - You are traveling in Siberia. You see a beautiful view of some snow-capped mountains. Create a new entry that includes 1) a small textual description, and 2) a photo (that you will be taking).
Task 3 - You realize that your photo is blurry. Edit the post to replace the photo with a new one.
Task 4 - Share your entry online.

Finally, we asked each user to explore the app and give general feedback.

Observations

Version 1

Timeline:

• Users tried to accomplish some tasks (mostly sharing a post) using the "Menu" button at the bottom of the phone; however, these tasks are specific to a single post and cannot be accessed through the menu of the Timeline screen. No one tried to accomplish post-specific tasks by pressing and holding on a post, which we expected people to do, as this is a standard Android right-click analog. Perhaps this is due to the paper nature of our prototype.

• Users generally ignored the top part of the screen - likely because we chose to set our fake posts in Siberia (to reduce the necessary complexity of the map and pictures we create) and the users could not really connect the post locations to the map. We expect this not to be a problem with real users, as they will be creating posts at locations which they are familiar with.

Edit Mode:

• Users were confused as to how to add items that were not text (in particular, photos). Because there were no visual cues for adding photos and contacts, it is possible that users would not know about those features at all. Since we included "add a photo" in our tasks, users generally did so with the "Menu" button at the bottom. However, no users tried to do so by pressing and holding in the text box.

• Users were also confused as to how to delete non-text items (in particular, photos). The most common way people tried to delete photos was just by tapping on the photo, but that does nothing. What we intended was for people to delete the photo by moving the cursor to right after the photo and pressing backspace. We did not implement an Android keyboard into our prototype (they just wrote text with a pen on the transparencies), which likely affected people's actions. Users also tried to delete photos by pressing and holding on photos, which also did nothing in Version 1.

• Some users tried to move photos around by clicking and dragging on them. We did not think to implement this in our design, but we will add it to our list of features as it is a convenient way to edit posts.

• Users did not attempt to change the time or location of posts. This is likely because we did not include that in any of our tasks.

View Mode:

• Users took a bit of time to figure out how to do things (share, edit, or delete) to a particular post while in View Mode. They all ended up using the "Menu" button at the bottom, but they also could have pressed and held the screen. Although we thought pressing and holding was intuitive for most Android users, it is possible that this is not the case. However, all options that are accessible through pressing and holding are also accessible through other means (like the "Menu" button), and it is possible that the paper nature of the prototype is affecting people's Android usage intuitions.

Version 2

Timeline:

• Users were confused by the arrow on the map, likely because the posts were located in an unfamiliar place. One user suggested that we change the arrow from a solid line to a dotted line to look more like a path on a map.

Edit Mode:

• Users added photos using the new "(+ camera)" button, which was much faster than trying to figure out how to add a picture. The small buttons for adding items seemed to improve both learnability and efficiency significantly.

• Users were still confused about how to delete photos. Some just had no idea what to do, most just tried tapping on the photo. We decided that since everyone just tried tapping once on the photo, we would move the cursor to right after the photo when they tap it so all they have to do to remove it is press backspace. In addition, we added the ability to delete photos by pressing and holding on them, which helped a little but not as much as we would have liked. One user suggested adding the ability to delete photos by double tapping on them.

View Mode:

• Users were a little confused by the disappearance of the share/edit/delete buttons after a few seconds. However, when they needed to perform those functions it was more intuitive to use those buttons than the "Menu" button or pressing and holding the screen. Also the disappearance on screen will be less obvious and distracting when it does not involve someone physically moving the buttons away from the user.

• One user recommended that we toggle the share/edit/delete buttons by tapping on the screen. After they disappear, the user can tap once on the screen to get them back, and again to make them disappear. This seemed more useful than having them appear when the user scrolls, since the user may want to view the entire post cleanly while they are scrolling.

Prototype Iteration

Testing Version 1

Our first prototype was the Timeline screen of the second design mixed with the View/Edit screen of the first design. After the first round of testing, we made a few big changes to improve the visibility of some features and to improve the learnability of our UI:

Edit Mode:

• We added buttons above the text box for adding photos and contacts, with little icons to represent each. This visual cue not only informed users of the ability to add items other than text, it also made it much simpler for them to do so.

• We made it easier to delete photos by allowing the user to press and hold on a photo to have the option of deleting it.

View Mode:

• We added a set of buttons at the bottom of the screen (share/edit/delete) to allow users to interact with the post they are looking at. So as not to clutter the view screen, we decided to make these buttons disappear after a few seconds. They would reappear for a few seconds when the user scrolls then disappear again. We decided to make them temporary because if the user wanted to perform any of those tasks, they likely came to the view screen with that task in mind, so would press the button for that task right when they enter the view screen.

Testing Version 2

After testing with the second prototype, we decided to make a few more changes to our UI:

Timeline:

• We will change the arrow from solid to dotted or dashed to better convey that it is a path on a map.

Edit Mode:

• When a photo is tapped once, we will move the cursor to right after the photo so that the user can more easily edit or delete the photo they tapped on.

• When a photo is double-tapped, we will give the user the option to delete it.

• We will attempt to implement drag-and-drop for photos to improve usability.

View Mode:

User Test Feedback and Observations

All our users are in their early 20s and are very technologically capable. They like to travel and experience new things. Although they are usually quite busy, they find time to make occasional weekend trips. Because of these traits, they are good representatives of our target user population.

User 1

The only difficulty User 1 had was with deleting a photo. Although it was possible to delete a photo by holding down and triggering the context menu, this was not obvious to User 1. She claims that it is because she is an iPhone user. We can fix this by adding a small "Edit" button to the entry view mode, as this is more similar to how edits are done on iPhones.

Other Feedback:

• User 1 would like the star map markers to be tappable - she thinks it would be cool if tapping a specific star will bring you to the corresponding entry.
• User 1 also suggests to start the user testing with a few pre-made entries in the journal view. This is make it more obvious to the user that the stars/arrow will change as you scroll through the entries list.

User 2

User 2 had no problems with the assigned tasks. A very possible reason is that she is a regular Android phone user. However, she did not understand the star markers on the map, even though we had pre-added some entries to the journal.

Other Feedback:

• User 2 really liked the aesthetic design of the application, and commented that the map markers would be much more understandable if she were actually traveling and if the application actually tracked down her true locations for the entries. 
• User 2 also suggests that we add little left and right arrows for the entries in View Mode. These arrows will help inform the user that he/she can actually swipe through different entries.

User 3

User 3 knew that she was supposed to hold down on a photo to delete it, but she tried to do it in View Mode. It took her a little time to try the menu button and press "Edit". Right after that, though, she had no difficulty with the deletion. The same fix we mentioned for User 1 can also be applied here. An "Edit" button in a corner of the View Mode will make it more obvious, especially to iPhone users, about how to edit the entry.

Other Feedback:

• User 3 suggested a different way of editing the text of an entry. She believes that simply tapping the text in View Mode should make the text editable. She also wants photos and contacts to be editable in both View Mode and Edit Mode. Basically, she wants a single mode for both viewing and editing.

Reflection

We learned many things about UI design. One of the major lessons is that it is very important to consider who your target user population is. An interface can seem very easy to use to developers, but it can be difficult to use for the general public. We realize that we should first think in terms of what our users need and aim to do, and then design accordingly.

When we started our paper prototype, we had three potential designs. One design seemed fairly simple to implement, but also seemed pretty ordinary. Another design seemed very difficult to implement, but we all knew that it would be absolutely awesome if it worked. We finally decided on the latter design, because the idea was just too awesome. We were prepared to give it our all. And it turned out great!

There was one issue, though, with the paper prototyping. It was very difficult to make a paper prototype of the map markers, arrow, and their changes as the entries are being scrolled. Therefore, none of our users were able to provide good feedback for the feature. However, they thought it was a great feature once we explained it to them. If we were to do this a second time, we would probably rely a bit more on the computer prototype, on which it is easier to express complicated features like this one

...

.