GR2 - Designs

Scenario

Charles has downloaded PhotoBook and wants to browse through Facebook photos. He opens the app, and logs into his Facebook account. After browsing around a bit, he sees his friend Jennifer. Charles has a crush on Jennifer. He opens photos of her to see what she has been up to. He finds a romantic photo of Jennifer and Brian. Charles is shocked. Brian used to be Charles’ best friend. Is this why they haven’t talked lately? Charles opens the search page on PhotoBook, to investigate this betrayal. Sure enough, he finds plenty of photos with Brian and Jennifer. Charles finds a particularly incriminating sledding photo, and emails it to Donovan, to see if he has any explanation.

Designs

General Features

These are views that are quite straightforward and will all be used in the different designs.

Login Page

The first window that is shown when opening PhotoBook. The user enters his/her Facebook email and password so that PhotoBook can obtain the photos and start the viewing process.

Full Screen Photo View

This view displays a single photo at full screen. The top bar contains a “Back” button to navigate back to Photo Grid view. It also contains a title indicating the position of the photo within the album, and a share button. The bottom bar displays the caption of the photo, the name of the friend who uploaded the photo, the date the photo was uploaded, and the names of the people who are tagged in the photo. Tapping on the photo, or waiting several seconds hides the top and bottom bars so the only element on the screen is the photo. Swiping left or right navigates to the previous and next photo, respectively, and pinching zooms the photo in or out.

Due to the limited screen real-estate on the iPad, we wanted to use the entire screen to display a single photo; the user should be able to view the photo as large as he or she would like. Thus, the natural design is to present the photo such that it fills the screen, and provide minimal information that appears when tapped, and disappears automatically. Thus, aside from minor layout details regarding how the additional information is positioned, little can be changed in the Photo view design. Thus, we chose to only present one design for the Photo view, and focus our work on alternate designs for the album, photo list, and sharing views, which are presented in the sections below.

Design 1 - Traditional

This design closely follows the traditional “album” metaphor to explore, find, and share photos. The user first sees a grid of albums with a chosen photo on the cover. Then, the user can open an album, which hides the other albums and shows only the photos in the chosen album, laid out as a grid. The user can choose a photo to pull it out of the album and view it closely (at a size that fills the screen).

Thus, there are three main views in this design: an Album view that shows all the albums the user and her friends’ have posted, a Photo Grid view that shows thumbnails of the photos in a particular album, and a Photo view that shows a particular photo at full screen. The photo view is the same across all three designs, so it is shown above. A standard paged navigation interface is used to move through these views; a “Back” button is placed at the top left corner of the Photo Grid and Photo views to move back to the last view the user saw. Additionally, there are tabs to switch among viewing all albums, the user’s albums, and albums containing photos of each of the user’s friends.

Overall, this design follows the approach used by most photo organizing applications, including iPhoto, the iPad’s “Photos” app, and Facebook’s website.

Albums View

This view displays albums as a grid, with a thumbnail of a photo within the album and the name of the album. Tapping or pinching an album displays it in the Photo Grid view. Different albums are shown depending on the selected tab; currently the “All Albums” tab is selected, which displays both the albums the user has uploaded, and the albums all of the users’ friends have uploaded. The “My Albums” tab displays only albums the user has uploaded, and the “Friends” tab displays an album for each friend, containing only photos in which the friend is tagged.

Search

Tapping the “Search” field at the top right brings up the keyboard and a filter bar. The albums view does not change, but albums not matching the search terms are hidden as the user types. The filter bar presents four ways to search: by the name of the album, by the creator of the album (the friend who uploaded it), by the people tagged in the album (in which case the filter field autocompletes the names of friends, and multiple friends can be entered), and by all of the above properties at the same time. Note that searching for people tagged in the album displays albums with at least one photo with the entered people tagged; the user has to open the album and either scroll through the photos or re-enter the search to see just the photos of the chosen people. Also note that Search in the Photo Grid view behaves in the same manner as Search in the Albums view.

Photo Grid View

This view displays photos in a particular album as a grid, with a thumbnail of each photo and its caption (if available). Tapping or pinching on a photo displays that photo in Photo view. The user can search in this view just as in Albums view, and the user can choose to share the entire album via a button in the toolbar (tapping the button pops up the menu shown in this sketch). The user can go back to the Albums view by either tapping the “Back” button, or choosing a new tab at the bottom.

Storyboard

Advantages

Learnability: Overall, this design presents a very learnable interface. First, it follows the metaphor of the physical album quite closely; PhotoBook initially displays many albums. Then, the user can tap or pinch on an album to open it. Finally, the user can tap or pinch on a photo to pull it out of the album to take a closer look. It is also externally consistent; it is similar to the interfaces of many other photo organizing applications with which users are likely familiar, including iPhoto, the iPad’s “Photos” app, and Facebook’s website. Additionally, it uses standard interface widgets found throughout other iPad applications. Finally, although the photo browsing and searching experience is divided into two views - Album view and Photo List view - these views behave in the same a similar manner. Specifically, the user can tap and pinch on thumbnails to open them in either view, and the user can filter the displayed thumbnails using the same filter interface.

Visibility: The state of the interface is generally quite visible. Almost the entire screen is occupied by content, namely thumbnails of photos, and thus there is little “chrome” that gets in the users way. Every thumbnail is tappable or pinchable, and is thus directly manipulable. Additionally, every view has a title that indicates what is being displayed.

Efficiency: The grid design of this interface allows many thumbnails (about 9-12) to be displayed on the screen at a time. Thus, the user can quickly scan the screen to find interesting albums and photos, without excessive scrolling.

Error prevention and correction: Since PhotoBook focuses on content consumption, rather than content creation, many classes of errors found in other applications are not applicable in our designs. It is, for example, impossible to accidentally delete a photo or tag the wrong person in a photo, since deleting and tagging are not supported features. Thus, this design prevents users from making serious errors. There are, however, several minor errors that can occur. For example, if the user enters the wrong search term in the filter field, she can simply use the standard backspace key to correct the error and observe the new results appear live, confirming that she has entered the correct terms. Additionally, in this design, if the user is searching for a particular photo, she has to open albums that she thinks might contain that photo. However, if she chooses the wrong album, then this interface offers a “Back” button to return to the Album view, with her scroll position maintained, so she can try another album.

Disadvantages

Learnability: This design’s greatest strength lies in its learnability. However, as expected, the primary instances where the design’s learnability breaks down is where the design breaks the physical album metaphor. For example, the “Friends” tab displays an album for each friend containing the photos that friend is in. This provides a powerful organizational and searching tool, but most people would not copy all of their photos and make an album for each of their friends. Thus it may be unclear what these albums actually contain.

Visibility: The paginated nature of this design poses visibility issues. Tapping on an album completely hides the rest of the albums, and tapping on a photo completely hides the rest of the photos. Thus, the interface introduces a “Back” button to restore the previous state, but the user users must recall the last thing they were doing to know what to expect when she hits they hit the back button.

Efficiency: Although this design allows a maximal amount of content to be displayed on the screen at a time, it exhibits poor efficiency for many tasks. First, when exploring many albums, the user users must close the album they are currently viewing before she they can open another one. This involves hitting the back button (which provides a small target area that may be distant from the user’s finger if she is scrolling through photos), then visually searching through the album thumbnails to find the next interesting album.

Second, this interface makes some searches difficult. It is easy to search for an album by its name simply by typing the name in the filter field in “All Albums” view, and it is easy to find, for example, photos in a particular album in which a friend is tagged by opening the album then using the filter field. But, as the scenario made apparent, it is much more difficult to find all photos containing two or more people together. The user must search for those two people in “All Albums” view (since “Friends” view will only contains albums only for a single friend), then open each resulting  album to see the photos in that album, then find the specific photos that contain the two desired people. Since the interface for exploring and searching is the same in this design, other types of complex searches are difficult and time consuming.

Error prevention and correction: As noted above, it is rare for users to be able to make a serious error in PhotoBook. Navigation errors, however, may be common when the user is searching for a particular photo and has to look through several albums. While it is easy to correct this error by using the “Back” button, the other designs mentioned below make the error less likely to occur and faster to recover from. Specifically, the user does not need to “open” albums in the Side-scroll design (Design 2), and thus will not open the wrong album by mistake. In dDesign 3, opening an album is less of a commitment than in this design, since instead of being moved to an entirely separate page, some other albums remain visible when an album is opened, and an album can be closed by simply tapping anywhere outside the album.

Design 2 - Side-scroll View

The basic feature of this design is that the photos are displayed horizontally by groups, and the user can scroll horizontally to view the pictures in that group. There are four main views for this design: albums view, friends view, search view, and search result view. The user uses the tabs at the top of the window to switch between the various views.

Albums View

Albums view is reached by pressing the “Albums” button in the tabs. In this view, the photos are displayed by albums. For example, in the sketch below, there is an album called MIT Fall 2010, that was uploaded by Andrew Smith, on the 01/10/2011. Four photos from that album are displayed, and the other ones can be seen be scrolling horizontally. The user can enter the full screen mode by tapping a picture.

Friends View 

Friend's view is reached by pressing the “Friends” button in the tabs. The photos are displayed by friends, meaning that for each Facebook friend, we show the pictures in which he/she is tagged. For example, we can see someone called Itai Turban, and four pictures in which he is tagged. Similarly to the Albums view, the user can scroll horizontally to see more pictures.

Search View

Search view is reached by tapping the “Search” button and consists of a search page in which the user can search by people tagged in the album, name of the album, creator of the album, or all of the above, as described earlier. In the sketch below, the user would be searching for all pictures in which Jennifer and Brian are tagged (not all search possibilities are shown in the sketch below)

Search Results View

Search Results view is reached after entering the desired search. The results are displayed by album. For example, if the user searches for photos in which X and Y are tagged, then it will display all the albums that contain at least one picture in which they are both tagged, and it will display all such pictures in that album (which again can be viewed by scrolling horizontally).

Storyboard

Advantages

Learnability: This design is very learnable. The idea of scrolling horizontally follows the metaphor of a photo book in which you would turn pages to see more pictures.
Also, in this design, searching is done in a separate page. The user clicks the Search tab, which opens up a search page. This makes it easier for the user to understand how to search, compared to Design 1.

Visibility: The state of the model is clear to the user. The tabs at the top of the window clearly show in which view the user currently is. The arrows at the start and end of each row are shown if there are more pictures to view in the respective direction, which allows the user to know if it is possible to scroll to view more pictures. Furthermore, this design does not have the visibility issue of Design 1 of not being able to see other albums while browsing through photos in a particular album.

Efficiency: The use of a separate page allows more flexibility for the search, so that a user could fill out multiple criteria for the search. For example, he could look for friends X and Y being tagged and albums with the name “MIT”. This would make it more powerful and faster for the user to find the picture he/she is looking for.

This design would also be very efficient for going through pictures after a search result looking for multiple tagged friends since, on average, there would be relatively few albums to scroll down through, and few pictures in each album that contain all the friends. Hence, the user would have to do very little scrolling, and would be able to find a specific picture very quickly.

Error prevention and correction: Overall, the interface is not prone to errors. The horizontal scrolling would feel very natural to the user and make it simple for him/her to navigate back and forth between albums in pictures.

Disadvantages

Learnability: This design is not externally consistent as, through our research, we have not found a single app that displays photos in such a manner. Hence, although it’s a natural interface, it might feel unfamiliar and take a little time to learn how to use it.

Visibility: As in Design 1, there is the problem that viewing a single picture in full screen hides all the other photos in that album, and all the albums in other rows.

Efficiency: We have discussed above that this design has an efficient Search Result View, but the efficiency of exploring photos and albums is terrible. Assuming that the user has the average of 300 friends, each with the average 20 photo albums, he would have to scroll through 6000 albums in the Album view. Assuming that the window would have at most 5 rows, that means that he would have to scroll through 1200 pages! This would make the album view rather useless. 

The Friends view would contain an average of 300 rows (one row for each friend), which is very reasonable. However, on average, a Facebook user is tagged in 400 photos, so displaying about 5 in each row would mean that the user would have to scroll horizontally through 80 pages. This would be slow compared to Design 3. 

Having search in a separate page makes it slower than search in Design 1. The user would have to tap the Search tab, then move his finger through the various fields and enter the information. Furthermore, having an extra page makes the search process more tedious and less smooth, and gives a immediate feeling to the user that it would take longer.

Error prevention and correction: Let’s say that a user is scrolling through friends in the Friends View. It would be relatively easy for a user to scroll too quickly while going though rows, and lose the previous position. The only way for him/her to find it again would be to scroll back and read the descriptions or be caught by a picture that he/she has just seen. The same could happen when scrolling horizontally through pictures, and in this case, the only way to recover would be to remember the last few pictures seen. This could be very frustrating for the user.

Design 3 - Folders + Combination

This design presents a powerful combination between designs 1 and 2. Overall, we thought design 1 works very well for exploring, so this design uses a grid view similar to that used in design 1 to display albums. We thought design 2 works very well for searching, especially when the user is looking for a particular photo, so this design uses a side-scroll view for displaying search results. This design also uses a different metaphor for opening albums, and makes several other important changes, as explained next.

Albums/Friends View

On this interface, a grid of albums (or friends) is shown. Clicking on a photoset opens it in the same style that the iPad uses for folders on the home screen. Close the photoset by tapping outside of the opened portion.

This interface should be easily learned, because it uses metaphors the user is already familiar with, namely opening an album to see the photos in that album. By using an interface similar to that found on the iPad home screen, it gains learnability by being externally consistant.

The state of the interface is also very visible, because there is a single tab control at the top that indicates what types of albums are being shown. Additionally, tapping on an album displays the photos in the album in a boxed-off region with a clear title, so photos should not be easily confused with albums.

It is efficient for browsing through large sets of albums, which each contains a large set of photos. The grid formation allows as many photosets or photos to be displayed as possible. You can quickly open and close a photoset without navigating screens. Note that, unlike design 1, the user cannot search from the Albums/Friends view, which makes the interface slightly less efficient. However, making search a fundamentally different task in the user interface has many advantages, as noted below.

Because the user is not creating data, there aren’t many errors they can make. If the user accidentally taps on a photoset or photo that they don’t want to browse, they can quickly go back, since tapping anywhere outside of the album closes the album.

Search View

Search is the other main mode of PhotoBook (besides browsing).

Switching to search is highly visible. The familiar search field is at the top of every page. Tapping it opens the search field, with three search modes shown above the keyboard.

The three search modes are “Tags”, “Title”, and “Uploader”. They can only search by one term at a time. This is a feature limitation, but makes the interface less complicated and easier to learn.

When "Tags" or "Uploader" are selected, the user is searching for a friend's name. A popover appears that shows possible matches from the friends list, to make the interface more efficient.

The search interface is similar to the Album interface used in design 2, which we believe is heavily optimized for making search efficient and powerful since it displays only photos that match the search terms, rather than entire albums.

However, since this design uses two very different ways of viewing albums - tapping on a thumbnail of an album to open it like a folder in Albums/Friends view and scrolling horizontally through an album in Search view - the learnability suffers, as the user needs to learn how to use both interfaces.

Photo Viewer

The PhotoViewer appears and covers the rest of the interface. This is so that the image gets as much screen real estate as possible. There are also translucent overlays for accessing features and displaying photo information. Tapping the photo makes the overlays appear and disappear, as is common in many iPad apps. The photo information is displayed at the bottom (an optional caption, who is tagged, the uploader, and the upload date). At the top is a button to exit the photo viewer. There is also a button to share the photo. A popover appears to show the sharing options (either download, email, or post the photo to Twitter). Otherwise, each option couldn't fit on the interface and symbols would be used instead (which are harder to learn). The popover adds another tap to each share, which sacrifices efficiency. If a user wants to download all photos in an album, they can do that from the album view.

Storyboard