In this task, findings from @dchen’s usability tests for image tags / depicts are being processed from a design perspective.

---

TL;DR: Summary

• Continue with tag approach; “Yes/No” designs appeared to create more confusion than expected.
• Review/confirmation: Back functionality (to check if tags have been published, and a well thought out publish confirmation (T239698) will counteract the need of a separate review screen. Back functionality is essential in order to give users additional certainty that tags for previous images have been published. We should definitely investigate on how to make it happen (T240475).
• The general interaction model of navigating back and forth has been understood, additional labels for previous/next aren’t needed.
• Include onboarding screen, as it didn’t hinder participants to complete the tasks. It might have helped users in grasping the concept of adding tags more quickly.
• Incorporate “pinch to zoom“ into workflow, ideally as demonstrated in this example. Alternative if it’s a technical nightmare: support “pinch“ and “tap” gesture on image and lead them to a separate gallery like view, where images can be zoomed further.
• Highly demanded by participants: enhance current tagging system with the ability to add custom tags.
• As observed in previous usability tests: contribution history is one of the features that should be on top of our list in a future release. It has been explicitly mentioned in the tests, plus the need for it can be read between lines.
• Design for all themes (which has been planned), some participants perceived the interface as too dark or requested a light view.
• To consider in regards to strategy: Continuing with Suggested edits as a home for small tasks or could it be the “cockpit” for all edit related activities on Wikipedia in the future?

---

Comments on Findings

Language/onboarding

A few participants experienced initial uncertainty based on the initial description and onboarding screen, but upon seeing the task screen itself, quickly grasped both the task and the related task outcomes.

Does the onboarding screen really help users in getting started? Especially when reading “(...) but upon seeing the task screen itself, quickly grasped both the task (...)”, I’m not entirely sure. Regardless of this doubt, I think we should include it for the new task. We might learn things in terms of engagement and retention. This would a great case for a future A/B tests as well.

Publish process

All 10 participants understood that they could select more than one tag and the tag published confirmation was clear.

Great to see that this was understood by participants as this was an initial concern. Onboarding and addition label might have helped to convey it.

Confirmation screen 6 of 10 expected to see the photo with the selected tags or an ‘are you sure’ screen in addition to a confirmation message. However, none were deeply offended and a couple mentioned the status quo offered a minimalist interface and may mean quicker processing.

This is interesting. The goal with the proposed interaction model was to reduce steps to publish and make editing more direct (from *edit → review → publish* to *edit → publish*).

We’re currently investigating (T240475) if we can provide a feature that lets users go back to a previous published set of tags. IMO, an action item to create review screen depends on the outcome of it, as it adds an additional layer of “security” to check tags have been submitted.

An advantage of an additional review screen would be to show a legal disclaimer after tags have been added.

In summary, I think back functionality and a future contribution history page could solve the uncertaintities that participants have after publishing.

Left/Right arrows

6 of 10 participants described the correct expectations for the left and right arrows next to the Publish button. The remaining 4 more ore less had the same expectations, but some distortions in understanding include answers like ‘I’m not sure’ or thinking that the arrows would lead to more ‘options for tags’ in addition to navigating amongst image options.

Looks like the general model navigating through suggestions is understood by users. Including explicit labels for the left/and right indicators are not needed at this point.

Information provided

8 of 10 participants indicated they felt the information provided on the tagging screen is satisfactory/sufficient.

Great to see, no action items needed to improve the tagging interface at this point.

Participant concerns:

• Why are there so few tags (1)
• Layout not good to look at (1)

Valid personal opinions, but no action items needed at this point as it’s feedback of a minority.

Images provided

7 of 10 were positive on the images they saw using this prototype.

Great to see that the image size and format worked.

Negative commentary includes:

• Poor layout/overlay look
• dark/dull’ image
• ‘a bit blurry’

Re: “dark/dull image”: could be related to the prototype beeing designed in black mode. There are going to be designs for light, sepia and dark as well based on user preference.

Re “a bit blurry”: might have been related to the prototype not beeing as responsive/fluid as the final implementation.

Image Zoom

All 10 participants defaulted to the ‘pinch’ to zoom/interact with the images.

Most (6) mentioned they didn’t feel a need to zoom was necessary.

Interesting that participants choose “pinch to zoom“ over tapping the image. I would be great to incorporate the gesture in the final version. Also, we can roll it out to image caption editing.

Prototype Multi-tag select view or Static Single-tag rate view (Yes/No)

Prototype (5)

Static (3 - researcher note: would discount these votes. participants had real issues of understanding with the static view, like missing the ‘bridge’ tag altogether, and not understanding the ‘vote’ action. Additionally, 2 votes were for vague aesthetic reason; my hunch is because the overlay did not slightly cover the bridge image on the static page.)

Tech difficulties, no answer (2)

Suprised by the confusion around the “vote“ action in the Yes/No approach. Overall quite confirming to continue to go with the tag approach.

What did participants do/want to do next?

Publish another set of tags (6)

Indicator for retention? ;) To be processed with caution though, real usage stats (numbers) won’t lie at the end of the day.

Search for image to confirm publish (1)

See all images to which participant contributed tags (1)

Yes, we need a contribution history feature.

Explore other tasks on SE screen (1)

Alright, at least one participant is interested in exploring other tasks.

Suggested Edits main

3 of 10 participants described the SE main screen as if it were the ‘administrative’ center for all app editing/management of editing capabilities.

This is exciting as we’re thinking about making Suggested edits a home for all edit activities in the app.

---

Comments on Recommendations

Participant suggestions

Evaluate and address the following as is needed/valuable/worthwhile:

Add own tags (7 participants)

Search other existing tags to add (1)

Definitely planned as an enhancement for a future release.

Add own photos (1)

I guess this belongs more into the domain of Commons, as they’re already offering it.

Add photo credits (1)

We could think about including credits in the zoomed view.

Add button to bookmark image link (1)

Similar to randomizer? Even better to include a contribution history page.

Add day/night view (1 - researcher note: uncertain how this look will work with the light/dark views on Android. Will this override user settings or vice versa?)

Image tagging in light, sepia and dark mode will be part of the release. It will adapt to the user’s theme settings.

Publish process

Consider the utility of including a link to the image or a visual confirmation for users to see their added tags against the quick/clean current.

See comment in Publish process earlier in the doc.

Image zoom

Allow for users to zoom (if it's not much trouble, so they can do so if they'd like) on the image with the pinching gesture (most intuitive)

Yes, let’s support the pinch gesture.

Prototype Multi-tag select view or Static Single-tag rate view (Yes/No)

Stick to the former for clarity and efficiency’s sakes. The static version in practice will not necessarily always look ‘cleaner’ and it appears to create more confusion than expected.

Interesting, I expected that the “Yes/No" approach is going to be perceived as the simpler version but it obviously lead to confusion.

Suggested Edits main

Consider the macro-level goals around user participation and type/extent of editing on Android app with regard to the evolution of the SE main screen. Some participants’ impressions of it as an app editing administrative hub could be a positive, a diversion, or a combination of both.

This is a great remark. We will have consider it for the app edit strategy in the future. Do we want to continue with Suggested edits as a home for small tasks or could it be the “cockpit” for all edit related activities on Wikipedia? IMO, we should try to tie in Suggested edits with “regular“ Wikipedia editing more and more with every release, until artificial categorization/boundaries of editing via app disappear.