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?

In T216498#5203686, @santhosh wrote:

@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).

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?

In T216498#5207161, @santhosh wrote:

@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.

ok, it is done as general improvement in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ContentTranslation/+/511865

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?

In T216498#5223810, @Petar.petkovic wrote:

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?

In T216498#5229289, @santhosh wrote:

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

There you go:

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

In T216498#5289480, @Pginer-WMF wrote:

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

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

This one uses localstorage.

In T216498#5344560, @santhosh wrote:

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