Add helpful text when user hovers over lang abbrv in search box
Closed, DeclinedPublic

Description

Let's add in some helpful text when a user hovers over the language selection in the search box (that we recently A/B tested). The helpful text would indicate what language the user will be searching in.

See attached image.

debt created this task.Jan 21 2016, 10:26 PM
debt updated the task description. (Show Details)
debt raised the priority of this task from to Needs Triage.
debt added subscribers: debt, Deskana, JGirault.
Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald TranscriptJan 21 2016, 10:26 PM

Technical question:
I'm assuming the helpful text should be in the selected language? Where would we pull these labels from?

Functional concern:
This design (show on hover) is not helpful for mobile users. I'd rather take a mobile first approach.

Technical question:
I'm assuming the helpful text should be in the selected language? Where would we pull these labels from?

translatewiki.net is the standard way to do this. It has a lot of translators that translate messages for projects like this. We'd need to figure out the mechanism by which the portal can hook into that workflow. Although that's an open question for us specifically, there are plenty of examples of non-MediaWiki projects integrating the workflow; for example, the apps have their own i18n directories, and a script which syncs with translatewiki, uploading new messages in English for translation into other languages, and downloading new translations. You can take a look at an example of what that script does. Perhaps we could have a similar setup here.

Functional concern:
This design (show on hover) is not helpful for mobile users. I'd rather take a mobile first approach.

Good point. What do you suggest? Long press?

Deskana moved this task from Needs triage to UX on the Discovery board.Jan 25 2016, 11:30 PM

Technical question:
I'm assuming the helpful text should be in the selected language? Where would we pull these labels from?

translatewiki.net is the standard way to do this. It has a lot of translators that translate messages for projects like this. We'd need to figure out the mechanism by which the portal can hook into that workflow. Although that's an open question for us specifically, there are plenty of examples of non-MediaWiki projects integrating the workflow; for example, the apps have their own i18n directories, and a script which syncs with translatewiki, uploading new messages in English for translation into other languages, and downloading new translations. You can take a look at an example of what that script does. Perhaps we could have a similar setup here.

Sounds like something to explore.

Functional concern:
This design (show on hover) is not helpful for mobile users. I'd rather take a mobile first approach.

Good point. What do you suggest? Long press?

There is no good answer to this unfortunately.
Tooltips don't work very well on a touch screen, they are purely designed for desktop apps.

There are few ways to make them acceptable on mobile:

  • Displaying some text underlined with dots usually means it is not a link but there's something interesting when you tap on the text.
  • Put a (i) icon next to some text and the user knows there is helpful information when you tap on the icon.
  • + there must be other work arounds...

In our case, the text that needs informative help is a dropdown. I don't see how we can display informative text "on demand" on touch devices.
That's why the mobile first approach is best to avoid design mistakes (@MSyed). And when you design for mobile, you don't focus on a feature on screen (search language) but on the screen itself (site language) - because you have to leverage the entire screen space.

This raises questions to the language meta itself:

  • is the user's story to select the language of search results?
  • is the user's story to select the language of the screen (and an admitted consequence is: search results come in the language of the screen)?
    • or instead, should the screen be entirely language-agnostic? Kind of the current situation (we barely have 5 labels - in english - on the page) , but this obviously is a huge product decision that limits the capacity for further improvements)
  • is the user's story to select a language and never change it? (use the language selector - only one)
  • is the user's story to regularly query several wikis? (use the language selector - a lot)

Depending on these answers, you may design totally different UIs (@MSyed).
For instance, you can move the language picker out of the search input to have a more explicit:

  • Language: English (that represents the language of the page)
  • A settings link/icon that would open a configuration screen (full size) where you can more easily display "Language of Search Results" and a language picker (Google like).
    • In this case, you can even think of selecting 1-n languages, and get results from 1-n wikis? (Google like)
debt added a comment.Jan 28 2016, 5:45 PM

Hi @MSyed - can you take a look at the comments above and let us know if you think it's ok to have a desktop "only" solution to this or can you recommend one that will accommodate mobile and desktop helpful text for the language selection?

debt added a comment.Feb 2 2016, 11:08 PM

Moving to Design work column...

I think for now a desktop only solution to this is fine. I can't think how we can accommodate this better on mobile without taking more space. And on mobile, space is even more precious.

debt triaged this task as Normal priority.
debt set Security to None.
debt closed this task as Declined.Feb 9 2016, 4:51 PM

I'm declining this story - we'll do a better implementation here: https://phabricator.wikimedia.org/T124427