...
- Two of our three first-iteration users had trouble moving from task 2 (opening Photo view) to task 3 (searching for photos) because the search field was not visible in Photo view. Eventually, both users decided to try pressing the Back button (“Well, I can’t find a search field, so I guess I have to go back to something else”). After they clicked “Back,” both users were quickly able to find the search field and start typing.
- In our first iteration, one user tried to tap on the name of a person in the “Tagged” section of the Photo view to try to search for photos of that person. Since these names were simply text rather than buttons in our first iteration, nothing happened. The user commented that he expected to be able to click on names.
- In our first iteration, our users were confused as to the purpose of the search filter buttons (“People,” “Title,” and “Uploader.”). One user did not immediately understand what “Uploader” meant, which caused him to be confused as to whether “People” would search photos the person took, or photos the person was tagged in. Another user did not seem to notice these buttons at all. A third user understood the buttons, but commented after the test that she thought we could eliminate them and automatically search all metadata related to photos.
- One user commented that it would be nice to be able to search to find photos taken at a specific location, in addition to our existing search options.
- This is a separator bullet.
- When an album drawer was opened, the user was unsure what would happen when he tapped a photo in the drawer. In our paper prototype, there was no visual distinction between an album and a single photo.
- When the album drawer was still open, the user tried to open a different album by tapping it. This tap was used to close the drawer, but not open the second album. The user had to try tapping the second album again to open it.
- Our last test user mentioned his reasoning for navigating to “friends” instead of “search.” He said that he would go to the “friends” view to browse through photos casually, or if he only had a few friends on facebook. He would go to “search” if there was a specific photo to find, or if there were a lot of friends on facebook to browse through.
- When typing people’s names into the search field, our users took different approaches to separating those names. One user typed a comma, another user typed a space, and the rest of the users simply started typing another name after the first name was auto-completed by tapping the completed name in the popover. We allowed users to use all three approaches in our test.
- There is a redundancy in that viewing photos in the friend view and searching for a single friend has the same effect (showing all photos of that friend), but is presented in a different way (the opened drawer view vs the search result view). One user opted to search for “Brian” instead of opening his photos in the friends view.
Prototype iteration
| Wiki Markup |
|---|
One the second iteration, a few minor changes were made. We noticed that users expected the “Tagged” area on the photo-viewer to be interactive. We changed the prototype to have a token field containing the names, so that each person’s name was clickable. When a name was tapped a popover containing the option to “Search for photos of \[name\]” appeared, which brings the user directly into the search interface.
Some users didn’t notice the different search categories (above the keyboard), and some users didn’t know how to use them. In the second iteration, we removed the search categories completely. Any text that was typed into the search box would search by all terms.
As discussed above, we also changed the tasks to be performed in the second iteration.
We did not address the issue where the user had to press “Back” in Photo view to find the search field. We considered adding a search field to Photo view, but felt that this raised several more serious issues:
It would not be clear what the photos the field would search over, since only one photo was visible.
It would add more UI elements to the view, which would distract from its main purpose, namely to see a photo in a presentable manner that utilized all available screen real-estate (which is already very limited on iPad).
We expect that this will be less of an issue in higher-fidelity prototypes, since the search field will be more prominent, and it will be clearer that the Photo view appears on top of the exiting controls (perhaps by utilizing an animation that shows the photo view expanding from the photo thumbnail). Thus, we expect that users will be familiar with the location of the search field, and know they have to exit Photo view to reach it.
One the second iteration, a few minor changes were made. We noticed that users expected the “Tagged” area on the photo-viewer to be interactive. We changed the prototype to have a token field containing the names, so that each person’s name was clickable. When a name was tapped a popover containing the option to “Search for photos of \[name\]” appeared, which brings the user directly into the search interface. |
Some users didn’t notice the different search categories (above the keyboard), and some users didn’t know how to use them. In the second iteration, we removed the search categories completely. Any text that was typed into the search box would search by all terms.
As discussed above, we also changed the tasks to be performed in the second iteration.
We did not address the issue where the user had to press “Back” in Photo view to find the search field. We considered adding a search field to Photo view, but felt that this raised several more serious issues:
- It would not be clear what the photos the field would search over, since only one photo was visible.
- It would add more UI elements to the view, which would distract from its main purpose, namely to see a photo in a presentable manner that utilized all available screen real-estate (which is already very limited on iPad).
We expect that this will be less of an issue in higher-fidelity prototypes, since the search field will be more prominent, and it will be clearer that the Photo view appears on top of the exiting controls (perhaps by utilizing an animation that shows the photo view expanding from the photo thumbnail). Thus, we expect that users will be familiar with the location of the search field, and know they have to exit Photo view to reach it.