Page MenuHomePhabricator

Tag images feed experience
Closed, ResolvedPublic5 Estimated Story Points

Assigned To
Authored By
scblr
Dec 9 2019, 12:12 PM
Referenced Files
F31628761: sev4-07-light-worst-case.png
Feb 24 2020, 9:56 AM
F31628758: Screenshot_20200224-094247.png
Feb 24 2020, 9:56 AM
F31625357: Screenshot_20200221-115921.png
Feb 21 2020, 11:36 AM
F31625396: image.png
Feb 21 2020, 11:36 AM
F31625390: Screenshot 2020-02-21 at 12.31.33.png
Feb 21 2020, 11:36 AM
F31625374: Screenshot_20200221-121551.png
Feb 21 2020, 11:36 AM
F31622472: sev4-07-dark.png
Feb 19 2020, 11:42 AM
F31622468: sev4-07-light.png
Feb 19 2020, 11:42 AM

Description

Flow

1.2.3.4.5.6.7.8.
sev4-05.png (1×720 px, 744 KB)
sev4-06.png (1×720 px, 1 MB)
sev4-07.png (1×720 px, 753 KB)
sev4-08.png (1×720 px, 601 KB)
sev4-09.png (1×720 px, 602 KB)
sev4-10.png (1×720 px, 666 KB)
sev4-34-back-behavior.png (1×720 px, 745 KB)
sev4-05-reject-all.png (1×720 px, 223 KB)
  1. Confirm tags by tapping chips
  2. T242138
  3. After tapping a tag, chips turn into enabled state (blue background, check icon and this animation), a disclaimer appears and publish button is enabled
  4. T242139
  5. "
  6. "
  7. T242140
  8. A confirmation dialog is shown when no tag has been chosen and users tap publish. Copy:
    • Title: You haven’t selected any tags for this image
    • Description: Only tags that you choose will be added to images. Tags that are not selected will be marked as rejected. Are you sure that you want to mark all tags as rejected?
    • Button labels: Cancel, Publish

👉 Visuals on Zeplin


Conceptual additions

  • Interaction model known from V1 and V2 lets users swipe through suggestions.
  • Tags
    • 5 tags are retrieved from Google Cloud Vision AI. We should experiment with the number of tags in the actual implementation. Real data and various languages will influence the “right amount of tags”. We expect this value to be between 3-6 tags per image.
    • Tags that haven’t been selected are marked as rejected when publishing.
  • Image cropping
    • The concept respects the variety of image formats on Commons.
    • The idea is to keep as much of the image as possible, landscape stays landscape – portrait stays portrait.
    • Images are not cropped, should be fully visible from the start and are zoomable.

Event Timeline

scblr updated the task description. (Show Details)
Charlotte set the point value for this task to 5.Jan 7 2020, 5:42 PM

Hey @Charlotte, added specs for a confirmation dialog when no tag has been selected. Could you review the copy below, please? Thanks.

sev4-05-reject-all.png (1×720 px, 223 KB)

  1. A confirmation dialog is shown when no tag has been chosen and users tap publish. Copy:
    • Title: You haven’t selected any tags for this image
    • Description: Only tags that you choose will be added to images. Tags that are not selected will be marked as rejected. Are you sure that you want to publish all tags as rejected?
    • Button labels: Cancel, Publish

@schoenbaechler - Looks good, with the following tweak to the copy: Only tags that you choose will be added to images. Tags that are not selected will be marked as rejected. Are you sure that you want to mark all tags as rejected?

Updated the task’s description @Charlotte 👍

This comment was removed by scblr.

Wow, it’s already an experience @Dbrant 👏Spotted a few things yet to optimize! 👇

01) Borrowing a pattern from Commons to avoid reflowing / repositioning of tags:

  • The trick is to add the width of the checkmark to the inital (loading) size of the tag so it won’t change its size when it’s enabled.
  • A big plus would be a subtle animation (text animates to the right when tick is added, as seen on the video above)
  • (keep the position of the tick as it is on Android, as it’s more Common in Material Design)

02) Adapt output to 5 tags with the highest confidence score. I guess you’re already aware as we’ve been discussing this a few times.

Screenshot_20200210-170031.png (2×1 px, 1 MB)

03) Transition when publish animation is complete / tags are published is not ideal yet:

  • Add haptic feedback when publish animation is complete.
  • Increase delay to next suggestion a few hundert ms to let users process what just happened. What is the current value here (in ms)? My guess is it’s around 300ms currently, how about increasing it to at least 600ms?
  • Also, slow down animation time the slide left animation of the next suggestion to a few 100ms. It’s too fast currently (Same guess here, it’s around 300ms, how about increasing it to 600ms.

sev4-09-light.png (1×720 px, 454 KB)

04) Link info i button at top right to: https://www.mediawiki.org/wiki/Wikimedia_Apps/Suggested_edits#Image_tags. Also a reminder to @Charlotte and myself to create the image tags FAQ section 😉...

Screenshot_20200210-171402.png (2×1 px, 1 MB)

05) Choose matching tags label should reappear after enabling and disabling tags. Currently, it still shows the legal disclaimer. The legal disclaimer should only appear when a tag’s been selected.

Screenshot_20200210-172021.png (2×1 px, 1 MB)

06) What’s the current status on the back functionality? My understanding per our last conversation (@Dbrant) is, that it won’t be possible, correct? However, we discussed to incorporate back anyway to let users see their contributions. Currently it’s possible to de-select (green) tags in a previously published set of tags. We should disable that functionality in order to not confuse users. In short:

  • It should not be possible to de-select green tags
  • Remove legal copy from this view

Screenshot_20200210-172649.png (2×1 px, 1 MB)

07) Use same icons as for Portrait (back and forward use old iconography). And change checkmark icon color to the same color as the label in Portrait (PUBLISH).

Screenshot_20200210-173246.png (1×2 px, 379 KB)

@schoenbaechler

The trick is to add the width of the checkmark to the inital (loading) size of the tag so it won’t change its size when it’s enabled.
A big plus would be a subtle animation (text animates to the right when tick is added, as seen on the video above)

I'm afraid this is not how the Material Chip component works. We could potentially show a different icon when it's unchecked versus when it's checked, but not this kind of manipulation.

Add haptic feedback when publish animation is complete.

I assume you mean a vibration? For how long? Should it have any kind of pattern, or a single pulse?

Also, slow down animation time the slide left animation of the next suggestion to a few 100ms. It’s too fast currently (Same guess here, it’s around 300ms, how about increasing it to 600ms.

This animation time is hard-coded into the ViewPager component, and cannot be modified.

@Dbrant

The trick is to add the width of the checkmark to the inital (loading) size of the tag so it won’t change its size when it’s enabled.
A big plus would be a subtle animation (text animates to the right when tick is added, as seen on the video above)

I'm afraid this is not how the Material Chip component works. We could potentially show a different icon when it's unchecked versus when it's checked, but not this kind of manipulation.

Ok, how much additional effort would it take to realize this and deviate from standard Material Design behavior? Reflowing tags once selected, as it is now is too much of an interface change and messes with the user’s orientation (“What has just happened?“). If this is really not feasible, we have two options:

  • a) Make checkmark icon transparent in disabled state. We would also have to move the checkmark to the right side to optimize scannability of tags for users. Pro: We’d not solely rely on a background color change to indicate that a tag is enabled (better accessibility). Contra: Tag interface is likely to look/feel imbalanced due to additional space on the right side.
  • b) Remove checkmarks completely. Pro: No reflow of tags. Contra: Accessibility issues, as we only rely on background color (contrast) to indicate that a tag is enabled.

Additional remark: I don’t recommend to use another icon (such as the “x"), it would lead to additional complexity of the interface.

Add haptic feedback when publish animation is complete.

I assume you mean a vibration? For how long? Should it have any kind of pattern, or a single pulse?

Yes! I’d say 2 single and short vibration sequences, simultaneous with the appearance of the checkmark – excited about this.

Also, slow down animation time the slide left animation of the next suggestion to a few 100ms. It’s too fast currently (Same guess here, it’s around 300ms, how about increasing it to 600ms.

This animation time is hard-coded into the ViewPager component, and cannot be modified.

I see! Do I understand correctly that the other animation tweak mentioned in 03) is feasible? 👇

  • Increase delay to next suggestion a few hundert ms to let users process what just happened. What is the current value here (in ms)? My guess is it’s around 300ms currently, how about increasing it to at least 600ms?

Thanks!

b) Remove checkmarks completely. Pro: No reflow of tags. Contra: Accessibility issues, as we only rely on background color (contrast) to indicate that a tag is enabled.

^ I would be in support of that. (i.e. no check mark, just a simple color change). Since the feature involves visually examining images and determining what they represent, we can assume that the user is not visually challenged, and that the strictest rules of visual accessibility need not apply here.

Yes! I’d say 2 single and short vibration sequences, simultaneous with the appearance of the checkmark – excited about this.

👍🏻 👍🏼 👍🏽

Increase delay to next suggestion a few hundert ms to let users process what just happened.

👍🏽 👍🏼 👍🏻

Hey @Dbrant, currently design reviewing two possible solutions for the tags:

https://docs.google.com/presentation/d/1lzjZNrIqMH0BS-nrihK7VSzjYAHjsqsXcl6oDjAmL8I/edit?ts=5e4a9b61#slide=id.g6f1354a3ca_0_0

Will report back soon if I have some opinions / feedback from other designers from the team.

@Dbrant: During a session with @Amire80, we noticed a few things in regards to RTL and beyond (T240194). The things we noticed are mostly related to ongoing work in this task, so I thought I’ll list them here.


01) “Publish button“ flashes when accessing Suggested edits, can we set it to de-emphasized state on load to avoid it? Check out this video to see what I’m referring to: https://www.dropbox.com/s/i246fleon5ujphu/20200217_173754.mp4?dl=0


02) Image zooming:

Image zooming, hold with one finger should be optimized (Robin).

Zooming is actually needed for functionality: to understand which tags are more appropriate. I can zoom, but then it immediately goes back to the usual size. So please make it stick.

The problem is, that the zoom state is lost once one finger is removed from screen. It’s a small tweak but makes a huge difference in usability.

How to reproduce

  • Zoom an image within the feed by pinching
  • Release one finger when the image is zommed

Current behavior
Image is defaulting to initial state (100%) when releasing one finger.

Expected behavior
Image should stay in zoomed mode until second finger is released from the image

If this is not clear enough, let’s talk about it in our 1:1.


03) Reliability issues:

Loading of images takes a long time, outputs an error.

Yes, that's how it was the first time. After I retried, it was OK. I'm quite sure that my network connection was OK, though.

Experienced the same issues as Amir, I get this error relatively often:

Screenshot_20200217-174938.png (2×1 px, 51 KB)


04) Invert swipe gestures/animation and functionality of “Next" and “Previous” buttons in RTL. They currently feel odd/wrong in RTL.

Yes, this was indeed quite odd. Here's a detailed summary:

  • The appearance and the general functionality of the arrows at the bottom of the screen makes sense.
  • The animation that happens when you tap the arrows at the bottom of the screen is weird. The current photo should slide to the right. Currently, it slides to the left.
  • Swiping the screen gets the next or the previous photo. Swiping from left to right should get the next photo.

05) Strangely, Amir gets a mix of languages in the suggested tags, e.g. 7 of the tags are in Hebrew one is in Russian, has happened multiple times in different combinations. Mentions that the Russian tags use very weird language.

The numbers are different on each screen. Usually it's mostly Hebrew, and sometimes exclusively Hebrew. But often, one, two, or three tags are in Russian.

I have Hebrew, Russian, Catalan, and English defined as my phone's language and my app languages. I don't get any tags in Catalan or in English.

Sometimes the Russian and the Hebrew tags appear to be the same (translations of each other), but sometimes they are different.


06) Center text in tags if word is short. They’re oddly aligned to the right if word’s too short (RTL). In LTR, they’re sometimes oddly aligned to the left.

Yes. Two-letter tags look a little ugly ;)


07) What do you think about Amir’s comment here?

Not all languages are probably supported by Google Cloud Vision AI, suggests to test it with a language that is not supported by Google Cloud Vision AI and see what happens.

Yes, I strongly, strongly recommend it, even if it's challenging. We are Wikimedia, and according to our vision and guiding principles, and we are supposed to go the extra mile when it comes to language support. I'll be happy to help you find people who can test in more challenging languages.


08) Are the tags stored yet on Commons? We were checking out the Commons file page but haven’t noticed a change in the “Structured data“ tab?

Where are the tags stored?! Does not see it on Commons. Not implemented yet? Would love to see where it goes / it’s stored.

Yes, it's REALLY important. If it was published at all, I have no idea where. It's not a very big deal if it's not available in the app itself, but editors of Wikimedia projects are used to seeing all their contributions in the Contributions list (available by clicking the Contributions link at the top of the page on the desktop).


Thanks!

@Dbrant, here’s the promised update in regards to:

Hey @Dbrant, currently design reviewing two possible solutions for the tags:

https://docs.google.com/presentation/d/1lzjZNrIqMH0BS-nrihK7VSzjYAHjsqsXcl6oDjAmL8I/edit?ts=5e4a9b61#slide=id.g6f1354a3ca_0_0

Will report back soon if I have some opinions / feedback from other designers from the team.


01) Update chips style with the following specs:

Default

ElementTheme
LightSepiaDarkBlackColor group name
sev4-05-light.png (1×720 px, 746 KB)
sev4-05-sepia.png (1×720 px, 746 KB)
sev4-05-dark.png (1×720 px, 746 KB)
sev4-05-black.png (1×720 px, 746 KB)
Chip backgroundbase80 / #EAECF0amate / #E1DAD1base20 / #54595Dbase14 / #2E3136color_group_18
Chip border
Icon (add)black38black38white50white50color_group_28
Font colorblack87black87whitewhitecolor_group_40

Enabled

ElementTheme
LightSepiaDarkBlackColor group name
sev4-07-light.png (1×720 px, 756 KB)
sev4-07-sepia.png (1×720 px, 756 KB)
sev4-07-dark.png (1×720 px, 755 KB)
sev4-07-black.png (1×720 px, 754 KB)
Chip backgroundaccent90 / #EAF3FFaccent90 / #EAF3FFaccent20 / #223966accent20 / #223966color_group_55 *new*
Chip borderaccent30 / #2a4b8daccent30 / #2a4b8daccent50 / #3366CCaccent50 / #3366CCcolor_group_56 *new*
Icon (checkmark)black87black87whitewhitecolor_group_40
Font colorblack87black87whitewhitecolor_group_40

Published

ElementTheme
LightSepiaDarkBlackColor group name
sev4-34-light.png (1×720 px, 741 KB)
sev4-34-sepia.png (1×720 px, 741 KB)
sev4-34-dark.png (1×720 px, 740 KB)
sev4-34-black.png (1×720 px, 740 KB)
Chip backgroundgreen90 / #D5FDF4green90 / #D5FDF4green30 / #14866Dgreen30 / #14866Dcolor_group_57 *new*
Chip bordergreen30 / #14866Dgreen30 / #14866Dgreen50 / #00AF89green50 / #00AF89color_group_58 *new*
Icon (checkmark)black87black87whitewhitecolor_group_40
Font colorblack87black87whitewhitecolor_group_40

02) Update font-style for Choose matching tags to Roboto Italic (Regular), font-weight: normal;, font-size: 14sp;, line-height: 16sp and color_group_59 *new*

03) Update font-style for Williamsburg bridge (image caption) to: color_group_59 *new*

04) Change thickness of PUBLISH button border in de-emphasized state to 1.5dp.

👉Zeplin and theme guidelines are updated to reflect these changes.

01) “Publish button“ flashes when accessing Suggested edits, can we set it to de-emphasized state on load to avoid it?

👍

02) Image zooming:
The problem is, that the zoom state is lost once one finger is removed from screen. It’s a small tweak but makes a huge difference in usability.

I'm afraid this is not how this component works, and would not be a small tweak. (see Instagram.)

03) Reliability issues

The Product Infrastructure team is aware of the timeout issue, and is investigating solutions.

04) Invert swipe gestures/animation and functionality of “Next" and “Previous” buttons in RTL. They currently feel odd/wrong in RTL.

👍 👍

05) Strangely, Amir gets a mix of languages in the suggested tags, e.g. 7 of the tags are in Hebrew one is in Russian, has happened multiple times in different combinations. Mentions that the Russian tags use very weird language.
07) Not all languages are probably supported by Google Cloud Vision AI, suggests to test it with a language that is not supported by Google Cloud Vision AI and see what happens.

The Google Vision API actually gives us Wikidata items (Q1234), and then we get the "label" for each item from Wikidata. Therefore the quality and/or correctness of the labels simply depends on what's currently in Wikidata for that item. It's possible that someone entered a Russian label in the field for the Hebrew language.

06) Center text in tags if word is short. They’re oddly aligned to the right if word’s too short (RTL). In LTR, they’re sometimes oddly aligned to the left.

👍

08) Are the tags stored yet on Commons? We were checking out the Commons file page but haven’t noticed a change in the “Structured data“ tab?

👍 This was a breaking change in the API that we have fixed, and should work now.

01) Update chips style with the following specs
02) Update font-style for Choose matching tags to Roboto Italic (Regular), font-weight: normal;, font-size: 14sp;, line-height: 16sp and color_group_59 *new*
03) Update font-style for Williamsburg bridge (image caption) to: color_group_59 *new*
04) Change thickness of PUBLISH button border in de-emphasized state to 1.5dp.

👍 👍 👍

Thanks @Dbrant for your hard work on this. The updated tags/colors for all themes are perfectly implemented!

Summarizing the things that are left to do for this and found a few additional inconsistencies that need improvements.


01) Reliability issues:

Loading of images takes a long time, outputs an error.

Screenshot_20200217-174938.png (2×1 px, 51 KB)


02) We need to output the unstructred description or the structured caption in the user’s primary language, if available. This file was suggested within image tagging in German:

Screenshot_20200221-115921.png (2×1 px, 1 MB)

On Commons, this file would have an unstructured description in German, but it hasn’t been outputted.

https://commons.wikimedia.org/wiki/File:Unterleiterbach_Valentinikapelle_1530_-HDR.jpg

The priorization of the caption/description output at the top should be:

  1. Structured caption in primary language of the app
  2. Unstructured description in primary language of the app
  3. Structured caption in n language of the app
  4. Unstructured description in n language of the app
  5. Structured caption in language that is available (on Commons)
  6. Unstructured description in language that is available (on Commons)

03) Hide tab indicator from Suggested edits home view:

Screenshot_20200221-121551.png (2×1 px, 235 KB)


04) Progress indicator for publish animation should represent the actual upload state for image tags. Currently, it leads to a situation where the progress indicator is at 100% but the checkmark would not appear for 1 or 2 seconds. This could confuse users. See this video and screenshot:

Screenshot 2020-02-21 at 12.31.33.png (478×524 px, 260 KB)

https://www.dropbox.com/s/7nc64vbpai7u58c/circle-animation-not-in-sync.mp4?dl=0

Can we sync the progress indicator circle with the checkmark appearance?


05) Change “Publish“ vibration to just 1 impulse instead of 2, see our Slack convo:

image.png (338×1 px, 78 KB)


06)

@Amire80, Would it be possible for you to download the latest Android Alpha and check if the two issues that you found last time (see below) are fixed now? 👇

  • Invert swipe gestures/animation and functionality of “Next" and “Previous” buttons in RTL. They currently feel odd/wrong in RTL.
  • Center text in tags if word is short. They’re oddly aligned to the right if word’s too short (RTL).

TY!

01) Reliability issues

👍 This is being investigated by Product Infrastructure, and should not block this task. I've created a temporary workaround that should make it more performant for now, while they solidify their API.

02) We need to output the unstructred description or the structured caption in the user’s primary language, if available.

I've managed to improve the language handling of the unstructured captions, but this is not guaranteed to work every time. For unstructured captions it's not always possible to parse the different languages correctly.

03) Hide tab indicator from Suggested edits home view

👍

04) Progress indicator for publish animation should represent the actual upload state for image tags. Currently, it leads to a situation where the progress indicator is at 100% but the checkmark would not appear for 1 or 2 seconds.

I'm afraid I don't see a way of making this possible.

05) Change “Publish“ vibration to just 1 impulse instead of 2

👍

05) Strangely, Amir gets a mix of languages in the suggested tags, e.g. 7 of the tags are in Hebrew one is in Russian, has happened multiple times in different combinations. Mentions that the Russian tags use very weird language.
07) Not all languages are probably supported by Google Cloud Vision AI, suggests to test it with a language that is not supported by Google Cloud Vision AI and see what happens.

The Google Vision API actually gives us Wikidata items (Q1234), and then we get the "label" for each item from Wikidata. Therefore the quality and/or correctness of the labels simply depends on what's currently in Wikidata for that item. It's possible that someone entered a Russian label in the field for the Hebrew language.

If this is indeed the case, it sounds like a fabulous opportunity to let the community fix the tags! It may not be the best thing for beginners, but plenty of experienced Wikipedia/Wikidata editors will love it. Doing it straight from the same screen in the app could be cool for advanced editors, but it would probably be scope creep. However, at least informing editors about the source of the tags' names will give them a chance to fix them.

I had no idea that they come from Wikidata—I was sure they were written by Google's staff or crowdsourcing volunteers, and not by Wikimedia volunteers.

@Amire80, how about the comment below? Thx.


06)

@Amire80, Would it be possible for you to download the latest Android Alpha and check if the two issues that you found last time (see below) are fixed now? 👇

  • Invert swipe gestures/animation and functionality of “Next" and “Previous” buttons in RTL. They currently feel odd/wrong in RTL.
  • Center text in tags if word is short. They’re oddly aligned to the right if word’s too short (RTL).
In T240196#5910192, @schoenbaechler wrote:

@Amire80, how about the comment below? Thx.


06)

@Amire80, Would it be possible for you to download the latest Android Alpha and check if the two issues that you found last time (see below) are fixed now? 👇

  • Invert swipe gestures/animation and functionality of “Next" and “Previous” buttons in RTL. They currently feel odd/wrong in RTL.
  • Center text in tags if word is short. They’re oddly aligned to the right if word’s too short (RTL).

Both are fixed!

This comment was removed by scblr.

Thanks @Dbrant for all the tweaks and @Amire80 for the confirmation that the bugs are ironed out! 👏

The last last round before QA signoff (promise!):


01)

Progress indicator for publish animation should represent the actual upload state for image tags. Currently, it leads to a situation where the progress indicator is at 100% but the checkmark would not appear for 1 or 2 seconds.
{F3162539}

I'm afraid I don't see a way of making this possible.

The current “in between state“ is suboptimal, we need to indicate that the upload is still in progress. How about this: Usie an indeterminate circular progress indicator instead of a determinate – see Progress indicators - Material Design. Rest stays the same (turns into “full” circle once uploaded). I manipulated an existing Codepen and prototyped it:

https://codepen.io/schoenbaechler/pen/XWbpKOw


02)

“Publish button“ flashes when accessing Suggested edits, can we set it to de-emphasized state on load to avoid it?

It seems like the “Publish” label is still showing up with a delay. It does not seem to happen for image captions and descriptions, see this video: https://www.dropbox.com/s/2zezoz2wpd9qsyh/publish-button-flash.mp4?dl=0.


03) I added a screen to Zeplin that defines padding-top/bottom for the overlays: https://app.zeplin.io/project/57a120b91998d8977642a238/screen/5e539b4b6be802745d7265a0/

ImplementationvsDesign
Screenshot_20200224-094247.png (2×1 px, 914 KB)
sev4-07-light-worst-case.png (1×720 px, 744 KB)

Sorry that I didn’t specify these until now...

How about this: Usie an indeterminate circular progress indicator instead of a determinate

ok.

It seems like the “Publish” label is still showing up with a delay.

👍 (Since we made the behavior of the Publish button inconsistent with the Add Description button, it's much more difficult to get it to behave seamlessly.)

padding-top/bottom for the overlays

👍

@Dbrant and I just talked about optimizing the publish animation (vibration should happen a tad earlier). After these last tweaks, we’ll move it to QA signoff.