Page MenuHomePhabricator

Invite to access Contributions for users that reached Content translation through other invites
Closed, ResolvedPublic

Description

Content translation has different entry points. Some are persistent (e.g., Contributions page/menu), and users can always rely on them to access the tool. Other entry points are only available in specific circumstances such as the one-time invite when creating an article (T216032) or the grey interlanguage links.

Non-persistent entry points are great to discover the tool in relevant circumstances, but users that do so may not be able to return to the tool later, which is problematic. In order to alleviate this issue the following is proposed:

  • For users that access Content translation the first time through other entry points that are not the Contributions page or menu, an invite will be shown next to the contributions page option.
  • The invite will use the pulsing-dot pattern that is used on VisualEditor education features (e.g., to teach about links and references).
    • In this case, a popup with information is shown when the user clicks on the "contributions" link. While the pulsing dot is present, both clicking the "contributions" link or the pulsing dot next to it will open the popup, as an intermediate extra explanatory step in the way towards the contributions page.
  • Once the user clicks on the contributions invite:
    • the pulsing dot will disappear and won't be shown for the user again
    • a popup will be shown.
Pulsing dot inviting to click the contributions optionPopup explaining that translations can be accessed from Contributions

The popup will include the following information:

Translate anytime
You can start or continue translating anytime from the Contributions page.
[Ok, got it]

  • The "Ok, got it" action will direct the user to the Contributions page, and will make the invite not to show again.
  • The illustration used is linked below:

In this way, a user that follows a link to Content translation can later discover that the Contribution page/menu allows them to access their translations anytime.

Details

Related Gerrit Patches:
mediawiki/extensions/ContentTranslation : masterFeature discovery for contribution menu

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 19 2019, 12:01 PM
Pginer-WMF triaged this task as Normal priority.Feb 19 2019, 12:02 PM
Pginer-WMF updated the task description. (Show Details)
cmadeo added a subscriber: cmadeo.Feb 19 2019, 6:11 PM
Pginer-WMF updated the task description. (Show Details)

The blue dot is implemented in VE using ve.ui.MWEducationPopupTool, but does not look like a reusable compoent. Will try to build something generic out of it

@Pginer-WMF, did you consider that fact that the dropdown from Contribution link and the blue dot will play hide and seek when mouse pointer approach it?

@Pginer-WMF, did you consider that fact that the dropdown from Contribution link and the blue dot will play hide and seek when mouse pointer approach it?

Good consideration. One way to prevent the conflict is for the dot to take precedence. That is, if the dot is showing, the "Translate anytime" popup can be shown on both click or hover, but not the contributions menu. Once the dot goes away, the usual behaviour applies (hover for the menu, click to access Contributions).

santhosh added a comment.EditedMay 22 2019, 11:08 AM

One way to prevent the conflict is for the dot to take precedence. That is, if the dot is showing, the "Translate anytime" popup can be shown on both click or hover, but not the contributions menu. Once the dot goes away, the usual behaviour applies (hover for the menu, click to access Contributions).

Can you please define a generic pattern here? If I do what you suggested, it will be usable only for the Contribution link. Or it will be a bloated component.

Consider a UI element(button, link etc) and we need to add a feature discovery without altering the behavior of that UI element. The UI element should not know the presence of feature discovery.

When feature discovery alters the behavior of the component, we are communicating a fake bahavior to user. Next time user comes here, they see a different behavior. This is what I meant by "Not altering the component"

The idea of the educational element is to add a step of explanation between the usual user action and the usual resulting behaviour. This is consistent with the way it works for Visual Editor education: you click on the link button a popup appears, and the link menu is shown after you confirm the popup. The behaviour the user follows to get the popup is the same that later will do for the action because that is what we want to train via muscle memory:

Based on the above, the generic behaviour would be to suppress the click and hover event propagation of the component with the dot attached.

If this is too complex, we can explore an alternative design where the pulsing dot has no effect and the information is shown once you land on the Contributions page. That makes it more disconnected (the dot and info being on a separate page) and less aligned with other uses, but it may work for our purposes. I can explore that if needed.

Change 511865 had a related patch set uploaded (by Santhosh; owner: Santhosh):
[mediawiki/extensions/ContentTranslation@master] WIP: Feature discovery for contribution menu

https://gerrit.wikimedia.org/r/511865

@Pginer-WMF, do we need this feature as general enhancement irrespective of CX is beta or not?

@Pginer-WMF, do we need this feature as general enhancement irrespective of CX is beta or not?

Good question. This is a general improvement for the discoverability of the main entry point to the tool. If it requires no extra efforts, it would be preferred to apply it in general (for beta and out-of-beta). If that makes it more complex, it is ok to focus only on the out-of-beta case.

I got some questions for @Pginer-WMF:

  • Do you plan to use pulsating dot in other places as well? Does it need to be a generic element? I have seen us creating generic solutions for which the full potential was never fully utilized. If this is one-off element, we can remove some of the code shipped on every page view.
  • Can the size of the SVG be reduced? It's 18.5KB, while most OOUI SVGs are in hundreds of bytes.
  • You say "Once the user clicks on the contributions invite, the pulsing dot will disappear and won't be shown for the user again". Current behavior is that pulsating dot is shown once regardless of user clicking on it or not. I think you expected the dot to be shown until the invite is seen by the used. Also, local storage is used to remember that dot was shown once, which means the dot can appear if using other browsers. Do we need to use global preferences or local storage is fine? New article invite (T216032) uses global preferences.
  • When dot is shown, contributions menu isn't. Clicking on dot opens invite from this ticket. Clicking on link opens Special:Contributions. Is this acceptable?
Pginer-WMF updated the task description. (Show Details)May 31 2019, 11:21 AM

I got some questions for @Pginer-WMF:

  • Do you plan to use pulsating dot in other places as well? Does it need to be a generic element? I have seen us creating generic solutions for which the full potential was never fully utilized. If this is one-off element, we can remove some of the code shipped on every page view.

Yes. The pulsing dot is an interaction pattern that is already used in other places such as Visual Editor education features. The usecase of introducing a new feature to users seem generic enough, so I expect to be used in other situations and products that may end up reinventing the wheel otherwise.

  • Can the size of the SVG be reduced? It's 18.5KB, while most OOUI SVGs are in hundreds of bytes.

I simplified the elements and applied svgo. I got a 7KB SVG:

I'm not sure it can be reduced further. We need to consider this is not anicon (single shape, single color), but an illustration with a higher number of shapes. For comparison, a 1x PNG export results in a 5KB image.

  • You say "Once the user clicks on the contributions invite, the pulsing dot will disappear and won't be shown for the user again". Current behavior is that pulsating dot is shown once regardless of user clicking on it or not. I think you expected the dot to be shown until the invite is seen by the used.

Yes, the intended behaviour is for the dot to be present until the user confirms the popup message.

Also, local storage is used to remember that dot was shown once, which means the dot can appear if using other browsers. Do we need to use global preferences or local storage is fine? New article invite (T216032) uses global preferences.

The dot appearing again for a user can be confusing/annoying. Using global preferences seems a more solid solution, I think we can try that unless there are other tradeoffs we have not considered.

  • When dot is shown, contributions menu isn't.

That's ok. We want to avoid both popups to collide. While we are teaching the user about the contributions entry point, the menu could be distracting.

Clicking on dot opens invite from this ticket. Clicking on link opens Special:Contributions. Is this acceptable?

That's not the intended behaviour. While the pulsing dot is present, both clicking the "contributions" link or the pulsing dot will open the popup. This represents an intermediate extra explanatory step in the way towards the contributions page. I updated the description above to make it more clear.

The pulsing dot is attracting user attention to the contributions link, and injecting one additional educational info step. The publish dot is not intended to be the main active area (is small). For example, in the Visual Editor example below you can notice that the popup appears after clicking the link button, not the dot:

through other entry points that are not the Contributions page or menu,

@Pginer-WMF, Do you consider interlanguage link as persistant entrypoint?

through other entry points that are not the Contributions page or menu,

@Pginer-WMF, Do you consider interlanguage link as persistant entrypoint?

No. You can not rely on it as a place where you can always start a translation. For example, a user going to an article present in many languages may not find grey language links there.

I've further optimized the SVG manually and aligned it to SVG coding conventions

. I'm pretty sure that @thiemowmde could add some additional magic (and remove valuable bytes) here :)

There you go:


The most obvious thing was to not duplicate the code that makes up the two sheets of paper, but reuse it.

T226719: Upstream pulsating dot widget may be relevant to this ticket.

Yes, that is relevant. Code that we essentially copied is now being changed and the element may become reusable, possibly through OOUI.
No patches are merged yet (our patch for this ticket or change in VE) and code changes in VE are not that significant that they must be updated in our mirror, but if element becomes reusable, we can remove our copy.

Change 511865 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] Feature discovery for contribution menu

https://gerrit.wikimedia.org/r/511865

Pginer-WMF renamed this task from Invite to access Contributions for users that reached Content translation through other invites to .Jul 1 2019, 12:22 PM
Jpita added a subscriber: Jpita.Jul 17 2019, 3:34 PM

@santhosh did you end up doing it only with localStorage or with global preferences as well?

This one uses localstorage.

Jpita closed this task as Resolved.Jul 18 2019, 8:49 AM
Jpita moved this task from Needs QA to Done on the Language-Team (Language-2019-July-September) board.
Pginer-WMF renamed this task from Contributions for users that reached Content translation through other invites to Invite to access Contributions for users that reached Content translation through other invites.Jul 18 2019, 9:00 AM

This one uses localstorage.

Ok. Based on the previous discussion (T216498#5225874) and the feedback from QA, I created a follow-up ticket to iterate on this and support a more consistent approach across wikis and devices: T228390: Use global preferences for the Contributions "blue dot" invite