GR6 : User Testing
Design
Overall, we finished our design and implementation since GR4.
Below is a brief design document expressed by way of annotated screenshots.
Screenshot |
Description |
 |
Our journal view. Note the color correspondences between the
map markers and their entries. The markers appear and disappear
you scroll through the entries in the list so that only the entries
visible in the list are shown on the map. The color of entries changes
as well: color corresponds to the list position of an entry on the screen.
We chose our colors according to aesthetics, good contrast, and to a
lesser extent (but still considering) color blindness. The three main colors
used are a perfect triad of purple, green, and blue.
The map is animated when scrolling to keep the zoom and positioning of
the map consistent with the visible entries. The map is also interactive,
with the expected drag controls (zoom controls also appear when the
map is touched).
Shorthand icons highlight entries with photographs.
Swiping the list down causes the scrolling to build momentum and
continue for a short while after the finger is lifted. This causes a super cool
animation of the arrow |
 |
An entry example in view mode. You can add multiple pictures
and textual descriptions. There is also a prediction for your
location.
All photographs taken in the simulator result in the android icon. When
testing on a real phone, real photographs are taken and inserted instead. |
 |
An entry example in edit mode. You can add/delete photos (via long press,
consistent with everything else in android) and change the text.
You can also add/delete contacts imported from the address book.
The text field automatically expands to accommodate multiple lines or
word-wrapped text. |
 |
To delete a photo, user can hold down on the photo to trigger
the displayed context menu.
|
 |
The save button is accessible from the android context menu.
|
 |
You can also hold down on any entry in the journal view to
trigger the context menu for sharing, viewing, editing, or
deleting the entry.
|
 |
Pressing the menu button in view mode will open the menu
for editing, sharing, and deleting the entry.
|
 |
This is the menu that shows up when you select "Share".
This is consistent with sharing functionality elsewhere in Android (for
example in the photo album).
All applications that can send messages of one form or another (facebook,
gmail, Goggles, etc) work with our app. |
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).
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 the class Entry, 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.
TODO: Talk about database
TODO: Talk about map
TODO: talk about what is missing from a complete app.
TODO: talk about the main challenges.
TODO: ??
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:
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.
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.