Google+ Interaction Design – Auto Backup & Sharing (Part 2)

Part 1 of this Google+ Interaction Design looked into the user interaction for moving some Auto Backup photos into a new Album. The post went through the process, looked at some possible issues with the flow, and proposed some slight changes that hopefully could make the process a little more logical for the user.

Part 2 was going to extend this analysis to the Sharing part of the process. However during the actual investigation, the playing around with Google+, it seemed that a more holistic reworking of the interaction was really what was needed. In general the Google+ interface was found to be non-minimalist, and to use a coding term, was a little spaghetti like. It was also a struggle to fully understand the logic underpinning some of the UI behavior.

This post starts off the reworking process. This is very much a work in progress. Hope it ends well :-).

Overall Use Cases

The following is a list of the basic use cases that seem relevant to the Google+ Photos section. These use cases will be the general scope for the reworking.

  • Create Albums
  • Import Photos
  • Add/Remove Photos from an Album
  • Manage an Album (Organise)
  • Comment on Photos
  • “Like” Photos and Albums
  • Edit Photos (crop, enhance, etc)
  • Auto Awesome Photos
  • Share Photos
  • Add Album to an Event
  • View Photos (with various groupings, i.e. Albums, Highlights, Recents, etc)
  • Delete a Photo
  • Tag People

Concepts/Objects

After playing around with the current Google+ Photos site, using the set of identified use cases above, the following is a first-cut view on the kinds of Concepts or Objects that the UI needs to represent. The user does not necessarily need to be aware of these concepts, but they should form the main basis of how the site is designed.

  • Photo:

A photo is the basic standard definition of a photo. It is the digital image taken by the users camera and uploaded. You can equate this with the photo print (ignoring photo negatives, for you older people).
If you edit a photo, or crop or enhance it, you create a new photo.
There needs to be some kind of relationship between these edited/enhanced photos.

  • Related Photos Concept:

As mentioned, there needs to be some kind of concept collecting together edited photos, i.e. the photos that are all related to the initial original image. Metaphor wise you could view this as a stack of photos, which are basically the same image with different crops, enhancements, filters, etc applied. Or as a carousel, where by you can swipe between these different edited photos.

Carousel

 

This concept can remain vague for the current analysis. It is probably a separate topic in itself. :-)

  • Album:

An album is a specific collection of photos, with an additional cover image, and probably some other additional data.
A single photo can be in multiple albums. An album can have multiple photos. An Album is just a aggregated view of different photos. The actual photo instances do not exist within the Album – the Album is just a view.

  • Multiple Selected Photos:

A concept is needed for a group of photos that the user selected. This is done now in Google+ using the check boxes that appear on the photos.

  • General Photo Group:

The current Google+ interface groups photos by things such as dates, AutoBackup status, etc. This grouping concept is probably needed to help provide some structure to the photo interaction.
In this analysis, we can consider that the grouping is mainly automated, based on some meta data from the photos.
Note that the concepts of ‘Album’, ‘Multiple Selected Photos’ and ‘General Photo Group’ are somewhat overlapping… However they probably need to be considered as separate at this stage. The may be the chance to aggregate later-on in the design process.

  • Other Concepts:

There are various other concepts, such as the Shared Recipient (the user that the photos are shared with), Comments, Likes (+1), etc. There is no need to consider these finer details at this initial stage.

User Interface High Level Flow

The use cases identify the various flows that the user is to achieve by interacting with the various objects/concepts discussed. Considering both these artifacts we can build an overall flow for the interface. The following figure outlines a possible high level flow.

HighLevelFlow

At the top level, we have the main landing point where the user is able to look through the various views of the photos. Views such as Highlights, Recent, Albums, etc.
From the top level, the user generally would navigate down into the groupings of photos (i.e. the Album or General Photo Group concepts).
The individual photos would be directly accessible at the lowest level. Here the user is able to manipulate the photos, as well as being able to select groups of photos on which to perform actions (Multiple Selected Photos).

This layering of the access, from high level views, through groups, to individual photos, differs from how it is currently done in Google+ Photos. With the current Google+ solution, you can directly access in some instances the individual photos from the top level views. Hopefully a more rigorous layered structure can help users better navigate through the site.

Using this generic high level flow, we can propose a general structure for the various user interface structures.

High Level Views

At the highest level, users are able to select from different sets of views of the photos. These views typically show grouped photos where the user can drill down through to access the individual photos. This high level view also provides some direct access to some key generic actions, such as ‘Upload’ing new photos, or ‘New Album’.

HighlightsUIStructure

Figure #1 shows the initial view displayed on launch to the user. It shows the ‘Highlights’ view of the photos. Across the top is a ‘tabbed’ selector for switching between views. Direct access is also included to some key functionality such as Upload/New Album in the top right corner.

The main view content pane shows the various ‘Highlights’ groups. As mentioned in the Concepts/Objects section, each ‘Highlights’ group is what we would classify as a ‘General Photo Group’. It is typically a grouping of photos based on some photo meta data.
You can interact with a ‘Highlights’ group by selecting one of the Group Actions available on the group. You CANNOT select or interact directly with the photos within the group. The idea is to have a clear hierarchy for how the user interacts. At the group level, you can only interact with the group as a whole, performing the Group Actions.

Note that currently in Google+ the Highlights tab also shows Albums. Here we need to consider in more detail to determine what actions to show on the Albums... Are they the Group Actions, or the Album Actions, or are they actually one and the same set of actions?

If you select a ‘Highlights’ group, you will move to the Groups screen as shown in figure #2 above. This screen contains the individual photos that the user can interact with.
The set of Group Actions displayed at the top of the Groups screen EXACTLY matches the Group Actions available on each Group in the highest level view in figure #1. It is important that these are consistent.

Within the Groups screen you can directly perform actions on individual photos, such as +1, adding a comment, and possible other actions available in the overflow on the photo.

If you perform a photo selection via the checkbox, then the Group Actions are replaced by a set of Actions relevant to ‘Multiple Selected Photos’ (see figure #3). This behaviour needs to be consistent across the different user interfaces, wherever you are able to select images, the action bar must become the ‘Multiple Selected Photos’ Actions.

Now going back to the highest level views, and looking at the ‘Albums’ view. The ‘Albums’ view displays a list of the defined Albums. See figure #5.

AlbumsUIStructure

On each Album, there would be a set of Album Actions that can be performed. At this level, actions are performed on the Album itself and/or the total set of photos in the Album. You do not perform actions selectively on the individual photos in the album. At this level, actions are performed on the group.

Selecting an Album will show the detailed album view with all the individual photos. The collective Album Actions appear at the top of this detailed view, allowing the user to still perform the set of actions on the Album as a whole. At this detailed level, users can also perform actions on individual photos as required.

On selecting a photo (or multiple photos) in the Album via the photo checkboxes, the Album Actions are replaced by the ‘Multiple Selected Photos’ Actions. This is the same behaviour as for the previously discussed ‘Highlights’ groups.

Back at the highest level, and looking at the ‘All Photos’ view. The ‘All Photos’ view is slightly different in that it skips the step of showing a Group view, and goes directly to a list of individual photos (figure #4). Users can manipulate an individual photo, or can select multiple photos to work with. As with the other detailed views, when selecting a photo (or multiple photos) via the checkboxes, the ‘Multiple Selected Photos’ Actions will become visible.

AllPhotosUIStructure

Concept/Object & Actions

With the overall UI flow strategy defined, the focus can move on to the details of the various Actions that can be performed from each Concept/Object that the user deals with. Consider firstly the Photo concept/Object and the available actions.

  • Photo:

The user should be able to directly interact with the photo for performing relevant actions. From the use case list above, the suggested actions that a user should be able to perform on a photo include:

    • Select/Unselect. Use the existing checkbox mechanism.
    • Comment. Probably directly accessible from a comment bubble on the photo.
    • Like. Probably directly accessible from a +1 on the photo. (unclear the scenario when a user would +1 their own photo?)
    • Add/Remove from Album. Probably accessible via the overflow. Allows user to create a new Album, or add/remove from other Albums.
    • Share. Probably overflow. Share the photo with a recipient.
    • Auto Awesome. Probably overflow checkbox/selector.
    • Edit. Probably overflow, launching a dedicated edit dialog.
    • Delete. Note need to better understand the concept of how/when/if a user can delete a photo. Possibly can only delete when no longer shown in any album?
    • Scroll Versions. Overflow. Allows user to view of edited, processed versions of the photo. This is the ‘Related Photos Concept’ that needs further fleshing out.
    • Tag People. Overflow. Tag people in the photo.

IndividualPhotoActions

  • Multiple Selected Photos:

When the user has visibility of individual photos, they are able to select one or more photos for action-ing. Typically the actions are similar that those that can be performed on a single image, however there will some difference due to the possible multiplicity.
When the user selects a photo, a new set of ‘Multiple Selected Photo’ Actions will be displayed.

Note, probably we need to alter this behaviour based on the type of group that it is launched from, is it an Album, or All Photos, or a General Photo Group?
    • Comment. NO. Commenting is not a group action.
    • Like. YES. Can like multiple photos, probably from the overflow menu.
    • Add/Remove from Album. YES. Probably direct access. Allows user to create a new Album, or add/remove from other Albums. Needs to be able to display the concepts of a) All photos in an Album, b) none of the photos in an Album, c) partial photos in Album.
    • Share. YES. Probably direct access. Share the selected photo(s) with a recipient.
    • Auto Awesome. YES. Probably overflow checkbox.
    • Edit. NO. You cant edit multiple photos.
    • Delete. YES. Probably in overflow. Possibly can only delete when photos are not shown in any albums? Note. Maybe this should be a ‘Remove Photo’ action, removing it from the group/Album in which it exists. More thinking needed.
    • Scroll Versions. NO. Doesnt make sense.
    • Tag People. YES.

MultipleSelect

  • Album:

The album provides an aggregate level of photos, and needs to support suitable aggregate level actions.

    • Tag People. YES. Probably direct access.
    • Share. YES. Probably direct access.
    • Organise. YES. Probably direct access.
    • Add Photos. YES. Probably direct access.
    • Delete (or Remove) Album. YES. Probably in Overflow.
    • Add to Event. YES. Probably in Overflow.
    • Auto Awesome. YES. Probably in Overflow.

Album

  • General Photo Group:

The General Photo Group provides a general grouping of photos, based on photo meta data such as upload time, Auto Backup status, etc. The grouping similar, but less strict that the Album concept. The available actions are similar to those available for an Album.

    • Add/Remove from Album. YES. Probably direct access. Allows user to create a new Album, or add/remove from other Albums.
    • Tag People. YES. Probably direct access.
    • Share. YES. Probably direct access. Share the selected image(s) with a recipient.
    • Delete (or Remove) Grouping. YES. Probably in Overflow.
    • Auto Awesome. YES. Probably overflow checkbox.
    • Add Photos. NO. The General Photo Group is created via automated background processes (in general), so probably doesnt make sense to allow users to include photos. Note: Should we make this distinction clearer, that the General Photo Group is created via the system, and not within user control?
    • Organise. NO. This is a concept specific to Albums.
  • Related Photos Concept:

Users are likely to interact with the group of related photos through a separate UI/View, where they can browse and view the photos. Users will probably be able to perform the standard set of actions available on a Photo.
A lot more thinking required on this concept and the actions, affordances.

    • Browse Photos. The browse will probably be integrated into the UI itself, with the photos displayed in a carousel or similar, allowing the user to quickly view through the related photos.
    • Select Photo. The user should be able to select, probably a single photo, and then exit from the view.
    • Photo Actions. When the user is viewing a single photo in the ‘carousel’, it should be possible to perform the same standard set of Photo actions.

A new thought for related photos could be to combine them together with the editing function, as the relationship between photos is brought about by the actual editing process.
I.e. when viewing a photo in the editor, the user can readily navigate to related photos, which can all be traced back to the original photo parent. The photo also shows an indication of the Album(s) in which it appears. See below for an example.

EditingView

When editing the actual photo, the user has the option to ‘Save & Replace’; which updates the existing photo and also how it appears in the existing Albums; or the user can ‘Save as New’, which creates a new related photo, which the user can then place in any relevant Album(s). See below.

EditingCrop

 

Sharing Behaviour / Functionality

One area of the Google+ Photos interaction that stood out as being rather less than minimalist, and a little inconsistent, was the Photo sharing dialogs. There appeared to be three different versions of the dialog, with differing levels of additional supporting functionality. The ability to add the photo(s) to an Album, add additional photos, Edit, Auto Enhance, Organise an Album, which are somewhat peripheral activities in relation to sharing were included sometimes in prominent positions, whilst the ability to share via a link was not. See the images below.

ExistingGooglePShareDialogs

An alternative strategy would be to use a simplified, standardised dialog with only the relevant sharing capability readily visible. If the additional supporting actions are essential flow, then they could be included in some overflow functionality. The overflow needs to be relevant to the Photo Group or Photo that is being shared. See below for some examples.

GooglePlusShareAlbum

 

GooglePlusSharePhoto

Tying Things All Together – An Example Use Case Scenario

The above discussion walks through some redesign thinking on the Google+ Photos interactions. This section will put those thoughts into a practical use case scenario to see how it all hangs together.

The selected end-to-end Use Case Scenario covers the following steps:

  1. Select Google+ Photos.
  2. Select the ‘Recent’ view, which provides a date based grouping of Photos.
  3. Select the required date group, revealing the individual photos view.
  4. Apply the Group Action, Auto Awesome. The action is applied to all photos in the group.
  5. Perform an edit on a single photo, accessed via the photos overflow action. Select a CROP Action.
  6. Perform a Save & Replace, which will associate the edited photo with the current group.
  7. Apply the Group Action, Share.
  8. From the Share Dialog, create a New Album, and share it using the Share via Link option, and copy the link.
  9. Paste the copied share link into an email to share.

Now working through these steps with representative figures.

Steps 1., 2. and 3.

Selecting ‘Photos’ displays the ‘Highlights’ view. Selecting the ‘Recent’ tab shows the recent photos grouped by date. Select the group with the date of April 9, 2014.

NewGooglePlusUseCaseScenarioStepsA

Step 4.

From the April 9, 2014 Group View, select the Group Action Auto Awesome contained in the overflow. This will Auto Awesome all photos within the group.

NewGooglePlusUseCaseScenarioStepsB

Step 5.

Chose a photo to edit. From the individual photo, from the overflow menu, select the Edit/Enhance action. This launches a photo edit view, from where the CROP action can be initiated.

NewGooglePlusUseCaseScenarioStepsC

Step 6.

Select the CROP region, and perform a Save & Replace. This will save the editing image, updating it in any existing groups or Albums in which it exists. Note that the Original image will always remain. Select the Done Editing to complete the edit.

NewGooglePlusUseCaseScenarioStepsD

Steps 7. and 8.

Having performed the required photo editing, select the Share Group Action to launch the Share dialog. Google+ only supports Sharing via Link for Albums, so as part of the sharing action, create an album by entering an album name, ‘New Album Name’.

Select the ‘Share via Link’ option to expose the share link for the album. The copy button allows easy copying for pasting into an email. Select the Share button to create the Album and sharing link.

NewGooglePlusUseCaseScenarioStepsE

Step 9. Paste the Share link into an email to share.

Conclusion

This post walked through a quick redesign of some of the Google+ Photos user interface.

Working from a set of high level use cases, and a ‘simple’ set of Objects/Concepts, an overall user interface flow was defined. The flow presented users with an initial set of views showing photo groups. From the groups, the user could access detailed views for managing the individual photos. This consistent, structured flow may help users quickly form a mental model for interacting with the site.

The redesign proposed sets of actions for the various views and Objects/Concepts. It is recommended to provide consistent sets of actions against the Objects/Concepts across all possible views.

The Google+ Share dialogs were also reworked to remove unrelated actions, and include all main actions relating to the actual sharing process.

This entry was posted in Interaction Design. Bookmark the permalink.

Leave a Reply