I find that I semi-regularly use the Google+/Android Auto Backup of photos, and then share via a private Google+ link that I email around to family/friends.
The Android/mobile side of things is simple… basically just take the photo, and then when back on Wifi and charging, the images will be uploaded to Google+. However each time I go through the Google+ process of adding the files to an album and sharing, I find myself getting confused, and hitting dead-ends each time :-(.
So I thought it was time to try and understand where I was having problems, with inspiration being drawn from the lecture series on Human-Computer Interaction.
To simplify the write up, I was going to break the process in two, firstly adding the Auto Backup files to an Album (Part 1), and then the subsequent sharing of the Album (Part 2). However after starting on Part 2, I decided that I needed to broaden the scope a little, and consider more of a general reworking of the Google+ Photos interaction. If you want to jump ahead, you can go directly to Part 2 (work in progress though).
(Part 1) Adding Auto Backup Photos to an Album
Successful Use Case Flow
First step in the process was to document a successful use case flow. A simple UML type use case diagram was used.
Walking through the flow in words:
- The User (me) is represented by the left hand actor. Google+ by the system actor on the right.
- Preconditions: Photos taken on the Android device, and images Backed Up to Google+.
- Step 1. Login to Google+. No issues here.
- Step 2. Use the LeftHandSide menu to navigate to the Photos.
Photos is launched showing Highlights photos. Unfortunately, the Auto Backup photos do not appear in the highlights, at least not initially. One needs to navigate to either the All Photos view, or the Auto Backup view available in the More dropdown.
All Photos is the logical place for accessing the photos, and you are able to see the Backed-up photos there, however there is no menu action for adding the files to an Album. After digging around, the closest action seemed to be a ‘Move’, for ‘Move’ing the photo to an Album. More on this later.
The Auto Backup path was the chosen route. From this view you could get access to a Move Action.
- Step 3. Select the Auto Backup view, which basically shows a photo search result, looking for the tag #AutoBackup. We can see the desired photos in the search.
From the search results, you can select the required photo(s), which shows up a selection of Action options, including Share, Copy, Delete and More. Based on my Mental Model of the required photo processing, I was looking to Move the photo to an Album. So I kept looking. After much backwards and forwards, I discovered that selecting the photo date would allow me to eventually find the ‘Move’ Action I was looking for.
- Step 4. Select the backup date on the required photo. This takes you to a date based view of the photos, where you can select the required photo for moving to an Album.
- Step 5. Select the desired photo(s) via the checkbox. Selecting the photos unveils the Action Menu, including the Share, Copy, Move, Delete and More Actions. I was looking for the Move action, as this is how I envisioned I needed to move photos into an Album.
- Step 6. Select the Move Action, which shows a move dialog. Cool. Getting there :-).
- Step 7. Enter the new album name.
- Step 8. Push the Move button. A dialog box appears confirming that you have successfully moved the selected photo(s) to the required album.
- Post Condition: Photo moved to the desired Album.
Overall the interaction is not what I would call smooth or efficient… So I turned to some Heuristic Evaluation to see what/where the issues were.
Heuristic Evaluation gives you a set of heuristic principles against which you can evaluate the design of the user interface. For the Google+ flow just traversed:
- Visibility of System Status: Overall the interactions provide relevant and timely indications of what is going on. No real issue here.
- Match between System and Real World: The goal of the interaction was to add the required photo(s) to an Album with a view to sharing. The terminology to achieve this is to Move (or Copy) the photo. Move/Copy are reasonable choices, as user can relate to moving/copying photos to Albums. It can however lead to some confusion, as mentioned later in the Consistency & Standards point below. Copy also implies that you are storing multiple copies of a photo which can concern more technical users. Other app terminology appears suitable, including the photo/album metaphor, etc.
- User Control and Freedom: Allows users to undo selections, step back, etc.
- Consistency & Standards: This is one possible area of weakness in the interaction. Example being that on some image selection views, image selection would support the Share, Copy, Delete, More actions. Whilst other image selection views allowed Share, Copy, Move, Delete, More actions. Based on my Mental Model of the solution, I was not able to determine clearly as to why the Move functionality is available in some views and not in others.
- Error Prevention: No error conditions were encountered.
- Recognition rather than Recall: The interface provided a suitable level of details on the current location, context, of the activity. Having said that however, the data displayed did not help me in understanding the appearance, or lack of, of the Move Action. Mental Model problem?
- Flexibility and Efficient of Use: Definitely flexible, however not what I would class as Efficient. My final success path for moving the photos was rather inefficient.
- Aesthetic and Minimalist Design: Aesthetics are in keeping with the spirit of Google+. The design however is probably not minimalist. There are many different actions, such as cropping/rotating/selection additional photos/etc that occur in multiple places in the flow. And it appears that there are many difference possible flow paths through the application for achieving the same outcome.
- Recognize, Diagnose, Recover from Errors: No error situations were encountered.
- Help and Documentation: There is limited additional help or documentation. Not really a key issue, as it is relatively easy to self discover the functionality as you move through the app, if you can build a good consistent mental model.
Flow Analysis Summary
In summary, the selected flow for moving the Auto Backup photo to an Album was not very efficient. The set of user interfaces were not minimalist, and there was little help/documentation to guide through the best path.
However, I believe that the biggest issue encountered related to my Mental Model of how the interaction should work. There is missing information on how the model functions:
- The interface supports both a Move and a Copy action for a Photo. However the Move action is accessible only from some photo views (the Copy action is accessible from all views). It is unclear why the Move action is not accessible everywhere that the Copy action is?
- The goal of my task was to create and Album, and include the Photo in it. The Move and Copy terminology are suitable actions, if you assume that the Move/Copy is in relation to Albums. After searching through the available options, my mental model had associated the Move action with my goal. Not being able to access Move from some views caused me to have to backtrack.
- The existence of a Move and Copy implies that you can have multiple instances of a photo, which from the end users perspective is or should be irrelevant? (Note that in the copy dialog box there is a note stating that the copy does not count towards your storage, so the terminology has probably caused some concern with users in the past).
- The Google+ conceptual model appears to support both Albums, and the tagging of photos (could display photos by upload batch date, by tag #AutoBackup). It was not very clear if these were separate concepts, or related, or actually one and the same thing.
Disclaimer: These thoughts are not necessarily suitable for other use case flows supporting photos in Google+. Thoughts are purely based on the placement of photos in Albums.
It may be possible to simplify the users Mental Model by removing the need for two distinct concepts of Move and Copy. Instead, the user simply needs the concept of the Photo, and whether or not it is visible in a given Album. From a Photo you can see and control which Albums it is visible in.
From the user interface perspective, you can replace the current Copy and Move Actions, with a single Albums action that shows an Albums dialog identifying the Albums that the photo(s) are currently visible in. For example:
Which launches the following Albums dialog:
The Albums dialog shows:
- A field for creating a new Album into which the photo(s) can be added.
- Check marks against all other albums showing whether or not the photo(s) are visible.
- Note that as multiple photos may be selected, the check boxes need to be able to show: Zero photos in Album; At least one photo in Album; All photos in Album (i.e. similar to how it is done in MS Excel).
- An Update button to execute the change.
Using the Albums Action and Dialog, the initial Use Case flow could be achieved as follows:
Whist the flow is only marginally shorter than the original flow, a possible advantage is in simplifying the users Mental Model for understanding the interaction.
Part 1 Conclusion
The interaction flow required for moving an Auto Backup Google+ photo to an Album was analysed.
Overall the flow appeared to be somewhat inefficient, with a non-minimalist interface and limited help/documentation. The main underlying issue however related to a lack of clarity associated with the Move and Copy actions, and why the Move action was not always available like the Copy action. There seems to be some disconnect between the conceptual model, and the users Mental Model.
An alternative ‘Albums’ Action was discussed, which may improve understand-ability of the interaction, and possibly simplify the users Mental Model. The ‘Albums’ Action had with little impact on the number of flow steps.
Authors note to self: Do some further research to better understand how Google+ manages/models photos, albums, tags, groupings, etc.