More specifics will be added on where to put the blue dot for wikis that have separate edit tabs for VE and wikitext.

@MMiller_WMF @RHo are there updated requirements for this scenario?

In T244435#5911858, @kostajh wrote:

More specifics will be added on where to put the blue dot for wikis that have separate edit tabs for VE and wikitext.

@MMiller_WMF @RHo are there updated requirements for this scenario?

Hi @kostajh @MMiller_WMF - my proposal and preference would be to have the pulse on the VE edit action only in cases where there are different tabs.

When the user arrives on a suggested edit article,

Can you please clarify if the rule should be: "The user arrives on a suggested edit article by clicking on the card in the module" or "The user arrives on a suggested edit article by any means" (e.g. the user organically arrived at the page while reading content on the wiki)

@MMiller_WMF @RHo ^

Oops, my answer is in the parent task:

The guidance experience described below should occur after a user arrives on a suggested edit, whether from the homepage or from the post-edit dialog of a previous suggested edit. It should only happen if the user arrives from clicking on a suggestion in one of those locations -- not if they navigate to the article some other way, or are returning to the article after leaving.

Change 574744 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Guidance: Add pulsing blue dot on desktop and mobile

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

Do we plan to display this every time someone clicks a suggested edit card? Seems like it would be mildly annoying after a while.

The patch is a bit different from the prototype:

prototype	patch	patch with long tab

The positioning in the prototype feels more natural, IMO. Also, relative positioning means the dot will be over the text if the text is long enough, so using the same absolute length as the tab might be a better option.

For mobile, the button looks differently on wide screens:

prototype	patch	patch on wide screen

Should the dot be on the pencil or the "edit" text in that case?

@RHo can answer about the positioning and visual look of the dot.

@Tgr -- regarding your question about whether the dot will be annoying after a user does several suggested edits, we should include that as part of T246015: Newcomer tasks: opt out of guidance, in which users can opt-out of guidance being pushed to them. I'll add this there.

In T244435#5918488, @MMiller_WMF wrote:

@RHo can answer about the positioning and visual look of the dot.

• Hi, apologies if this was not explicit but we should be using the existing pulse that shows on VE and not creating something new - can @Catrope comment on this?

@Tgr -- regarding your question about whether the dot will be annoying after a user does several suggested edits, we should include that as part of T246015: Newcomer tasks: opt out of guidance, in which users can opt-out of guidance being pushed to them. I'll add this there.

• hi @MMiller_WMF - actually, like the VE pulse, this is a first time only feature that appears the first time a user opens a suggested edit type and not every time. So we do not need to add a config here.

Hi, apologies if this was not explicit but we should be using the existing pulse that shows on VE and not creating something new - can @Catrope comment on this?

The VE pulse adds mw-pulsating-dot class and styles to a button (in VE's case, the Citation button IIRC). We are reusing the same code and styles but the exact placement of the dot is up to us.

actually, like the VE pulse, this is a first time only feature that appears the first time a user opens a suggested edit type and not every time. So we do not need to add a config here.

OK, I'll work that into the patch.

actually, like the VE pulse, this is a first time only feature that appears the first time a user opens a suggested edit type and not every time.

To clarify, the visibility of the dot varies by suggested edit type? Also a question about mobile/desktop:

1. User is on desktop
2. User clicks on "Copyedit" task, they see the blue dot
3. User goes back to homepage and clicks on another "Copyedit" task, no blue dot shown
4. User goes back to homepage and clicks on "References" task, blue dot is shown or not shown?
5. User is on mobile, and clicks on a "Copyedit" task -- blue dot is shown or not shown?

In T244435#5919377, @kostajh wrote:

Hi, apologies if this was not explicit but we should be using the existing pulse that shows on VE and not creating something new - can @Catrope comment on this?

The VE pulse adds mw-pulsating-dot class and styles to a button (in VE's case, the Citation button IIRC). We are reusing the same code and styles but the exact placement of the dot is up to us.

Thanks that's good to confirm.

Looking at it now, it looks a bit off at the moment because the dot i larger than the prototype, and the 85% position left and top is causing the solid dot to awkwardly hit the bottom and right hand side edges of the tab. I propose we adjust it so that the pulse dot is in the centre and a bit further down in the tab by adjusting the positioning to left: 50%; bottom:0;
This gives the following effect:

And matches the positioning when in shown on VE toolbar items:

In T244435#5919453, @kostajh wrote:

actually, like the VE pulse, this is a first time only feature that appears the first time a user opens a suggested edit type and not every time.

To clarify, the visibility of the dot varies by suggested edit type? Also a question about mobile/desktop:

1. User is on desktop
2. User clicks on "Copyedit" task, they see the blue dot
3. User goes back to homepage and clicks on another "Copyedit" task, no blue dot shown
4. User goes back to homepage and clicks on "References" task, blue dot is shown or not shown?
5. User is on mobile, and clicks on a "Copyedit" task -- blue dot is shown or not shown?

My expectation/hope is that the pulsing blue dot is shown on 4 and 5.

I propose we adjust it so that the pulse dot is in the centre and a bit further down in the tab by adjusting the positioning to left: 50%; bottom:0;

Sounds good for desktop; do you want the existing rules adjusted for mobile as well?

My expectation/hope is that the pulsing blue dot is shown on 4 and 5.

Got it, will update the patch.

In T244435#5919490, @kostajh wrote:

I propose we adjust it so that the pulse dot is in the centre and a bit further down in the tab by adjusting the positioning to left: 50%; bottom:0;

Sounds good for desktop; do you want the existing rules adjusted for mobile as well?

Yes please!

My expectation/hope is that the pulsing blue dot is shown on 4 and 5.

Got it, will update the patch.

Sorry I just had a realization I was wrong about showing it once only. The rule should be Show the dot until the edit action is clicked for the particular task type and skin - this is in line with the behaviour of existing pulsing dots on VE citation and link buttons.

@RHo OK, I think my last business rule question is: when there are two tabs (Edit and Edit Source), the blue dot is on "Edit" -- if the user clicks "Edit source" does that count as an edit action for the purposes of showing the blue dot the next time that the user looks at an article with the same task type and skin?

In T244435#5920004, @kostajh wrote:

@RHo OK, I think my last business rule question is: when there are two tabs (Edit and Edit Source), the blue dot is on "Edit" -- if the user clicks "Edit source" does that count as an edit action for the purposes of showing the blue dot the next time that the user looks at an article with the same task type and skin?

Hmmm, my conjecture is that a user would click "Edit source" here because they either (a) want to edit in wikitext as their preferred type of editor; or (b) they accidentally clicked on 'Edit source' not realizing the difference.
Based on this, my preference is to still keep the blue dot until Edit is clicked since we want to err on helping the scenario (b) user, since the a user who is savvy enough to click on Edit source is going to ignore the blue dot anyway. Plus, we are likely tailoring guidance content for editing using VE so it makes sense to keep the highlight on this until it is clicked.
Having said that, please comment @MMiller_WMF if you disagree.

Change 574744 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Guidance: Add pulsing blue dot on desktop and mobile

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

@RHo @kostajh -- I have updated the task description to try to succinctly summarize the business rule you've been discussing about when the dot appears and doesn't:

For each platform and task type, the user should see the dot until they click it -- even if that is not their first visit to a suggested edit article.

@MMiller_WMF @nettrom_WMF do we want instrumentation for the presence of the blue dot? (If so I assume it would be part of the helppanel schema.)

@kostajh -- yes, I will be working on instrumentation needs today.

Everything here has been reviewed, although there's a potential tech debt followup in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/575128#message-bf48aaf54f65767ec4f80b2cbf0c0e98d0a83c43.

@MMiller_WMF - moved for your review; I've added it to my list of tasks to check after deployment.

Checked in betalabs - the functionality and the UI layout seems to be fine, just one thing to be confirmed - see the red triangle below.

Summary: The blue dot appears when

• a user is a new user (a user who creates an account, not an old user who enables Homepage or activates SE); new users for whom Homepage is not enabled upon account creation, won't have the blue dot when they enable Homepage via Preferences
• a new difficulty level is selected (according to the specs)
• s skin is changed (according to the specs)
• if a user clicks 'Edit source' first and, without saving any edits, clicks 'Cancel' - the blue dot is still present on 'Edit' tab (seems ok to me).

On mobile arwiki the blue dot is not under the pencil as it's for LTR, it's on the other side of the pencil.

The screenshots are for illustrations, no problems were found.
(click to see an animated gif)

Thanks for assigning this back to Rita. @RHo -- this is now with you.

Thanks @Etonkovidova - I can confirm that the issue you've noticed on arwiki is not expected and the blue dot should still be in the middle of the icon as with the other languages, so popping back into ready for dev.

@MMiller_WMF - I also find it unexpected that only completely new users on a language wiki should see the guidance. When I created a new account on arwiki, I saw the blue pulsing dot on an 'easy' task, then when I switched to kowiki and cswiki on the same account and activated, it was unexpected that the blue dot and guidance does not show up on any tasks whatsoever.

In T244435#5943828, @Etonkovidova wrote:

@MMiller_WMF - moved for your review; I've added it to my list of tasks to check after deployment.

Checked in betalabs - the functionality and the UI layout seems to be fine, just one thing to be confirmed - see the red triangle below.

Summary: The blue dot appears when

• a user is a new user (a user who creates an account, not an old user who enables Homepage or activates SE); new users for whom Homepage is not enabled upon account creation, won't have the blue dot when they enable Homepage via Preferences
• a new difficulty level is selected (according to the specs)
• s skin is changed (according to the specs)
• if a user clicks 'Edit source' first and, without saving any edits, clicks 'Cancel' - the blue dot is still present on 'Edit' tab (seems ok to me).

On mobile arwiki the blue dot is not under the pencil as it's for LTR, on the other side of the pencil.

The screenshots are for illustrations, no problems were found.
(click to see an animated gif)

(this screenshot is not animated)

Change 579225 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/GrowthExperiments@master] Adjust the guidance blue dot on Minerva

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

@kostajh @Tgr -- would it be easy to alter the business rules to go along the lines of what @RHo says in her comment? Which would show the blue dot for accounts seeing a new task type for the first time, regardless of whether it's a new account on that wiki?

Which would show the blue dot for accounts seeing a new task type for the first time, regardless of whether it's a new account on that wiki?

That's how it should work. I just tested by creating an account on https://ar.m.wikipedia.beta.wmflabs.org, enabling the homepage and help panel in preferences, then going to https://cs.m.wikipedia.beta.wmflabs.org and enabling the homepage and help panel in preferences. Then I went to https://ar.m.wikipedia.beta.wmflabs.org and switched to the mobile site, and clicked on a suggested edit card and saw the blue dot and mobile peek, then I went to https://cs.m.wikipedia.beta.wmflabs.org and clicked on a suggested edit card and saw the blue dot and mobile peek.

@RHo is it possible you didn't have help panel preference enabled when you visited kowiki/cswiki beta sites?

In T244435#5972301, @kostajh wrote:

Which would show the blue dot for accounts seeing a new task type for the first time, regardless of whether it's a new account on that wiki?

That's how it should work. I just tested by creating an account on https://ar.m.wikipedia.beta.wmflabs.org, enabling the homepage and help panel in preferences, then going to https://cs.m.wikipedia.beta.wmflabs.org and enabling the homepage and help panel in preferences. Then I went to https://ar.m.wikipedia.beta.wmflabs.org and switched to the mobile site, and clicked on a suggested edit card and saw the blue dot and mobile peek, then I went to https://cs.m.wikipedia.beta.wmflabs.org and clicked on a suggested edit card and saw the blue dot and mobile peek.

@RHo is it possible you didn't have help panel preference enabled when you visited kowiki/cswiki beta sites?

I had newcomer homepage enabled and expected help pabel to be enabled by default as well. Where should I go to enable Help panel? (I cannot seem to locate it in Preferences in betalabs)

Also, the tweak for showing the blue dot on the centre on RTL @kostajh made looks good to me:

I had newcomer homepage enabled and expected help pabel to be enabled by default as well. Where should I go to enable Help panel? (I cannot seem to locate it in Preferences in betalabs)

@RHo you have to go to Special:Preferences#mw-prefsection-editing and then it should be the last checkbox in the second section (Editor).

We could consider making each language wiki (cs/vi/ko/ar) use 100% opt-in settings for the various GrowthExperiments features so there is less setup time to test stuff. But it's a shared environment for lots of projects so not sure if it would be OK for us to do that.

Change 579225 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Adjust the guidance blue dot on Minerva

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

In T244435#5973671, @kostajh wrote:

I had newcomer homepage enabled and expected help pabel to be enabled by default as well. Where should I go to enable Help panel? (I cannot seem to locate it in Preferences in betalabs)

@RHo you have to go to Special:Preferences#mw-prefsection-editing and then it should be the last checkbox in the second section (Editor).

• Ah thank you, the dots are showing up in the new language now after I activate the help panel.

We could consider making each language wiki (cs/vi/ko/ar) use 100% opt-in settings for the various GrowthExperiments features so there is less setup time to test stuff. But it's a shared environment for lots of projects so not sure if it would be OK for us to do that.

• I think I forgot that help panel opt-in is independent from homepage preference because I expected them both to be in the same place. I think it makes sense to keep the separate prefs but maybe we could consider moving to one location in preferences?

In T244435#5973753, @RHo wrote:

• I think I forgot that help panel opt-in is independent from homepage preference because I expected them both to be in the same place. I think it makes sense to keep the separate prefs but maybe we could consider moving to one location in preferences?

Enabling Homepage (and Help panel) form User Preferences by users has been viewed as the options that out of the reach for newcomers. But maybe it's time to reconsider that view - there might be quite few use cases when newcomers being proficient in several languages switch between different language wikis and may need Help panel or Homepage to be easier discoverable?

For Design Review:

• The RTL blue dot position is corrected
  

LGTM as well, thanks!

CS Mobile	CS wider mobile	CS Desktop
AR Mobile	AR wider mobile	AR Desktop

@kostajh -- I updated the requirements to say that on two-tab wikis, the blue dot should be on the VE on tab. Is that already how you engineered it? Just double-checking.