@RHo I added a new requirement, and would appreciate your feedback. Your Figma file included the following requirement:

Sent to newcomers with Growth features who have made less than $(10) suggested edits AND have not made a suggested edit for more than $(120) hours.

This notification is for newcomers who have made >0 but <10 suggested edits, correct?
Would the count down start after a suggested edit was completed? So potentially a newcomer could only ever get a maximum of 9 of these notifications, correct?
I certainly don't want a newcomer who has completed 1 suggested edit to get this notification after 120 hours, then again at 240 hours, etc.

I added this requirement to make sure we aren't sending too many of these notifications:

A newcomer should only receive this notification once. In other words, this is a one-time prompt to keep going.

But I'm not attached to that idea. Do you have a better suggestion for how we can ensure the logic doesn't accidentally overwhelm newcomers with these notifications?

In T322435#8524892, @KStoller-WMF wrote:

@RHo I added a new requirement, and would appreciate your feedback. Your Figma file included the following requirement:

Sent to newcomers with Growth features who have made less than $(10) suggested edits AND have not made a suggested edit for more than $(120) hours.

This notification is for newcomers who have made >0 but <10 suggested edits, correct?
Would the count down start after a suggested edit was completed? So potentially a newcomer could only ever get a maximum of 9 of these notifications, correct?
I certainly don't want a newcomer who has completed 1 suggested edit to get this notification after 120 hours, then again at 240 hours, etc.

I added this requirement to make sure we aren't sending too many of these notifications:

A newcomer should only receive this notification once. In other words, this is a one-time prompt to keep going.

But I'm not attached to that idea. Do you have a better suggestion for how we can ensure the logic doesn't accidentally overwhelm newcomers with these notifications?

Yes, that's a great point! Agree it makes sense to limit these Levelling up notifications to once per user.

I split the second notification type out into T328288: Leveling up: "Keep going" notification, so it can be worked on and QA'ed independently from this one.

Change 892614 had a related patch set uploaded (by KMorgan; author: KMorgan):

[mediawiki/extensions/GrowthExperiments@master] Leveling Up: Get Started Notification

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

I was just thinking about this one with relation to T328288#8656008, and it seems like similarly, perhaps we could get away with avoiding another maintenance script. We could enqueue a delayed job on account creation, and when the job runs, we can check to see if the user has made any suggested edits; if so, don't send the notification.

You can do that with a jobReleaseTimestamp parameter, e.g. this is how we do it for the NewcomerTaskCacheRefreshJob:

new NewcomerTasksCacheRefreshJob(
  'userId' => $user->getId(),
'jobReleaseTimestamp' => (int)wfTimestamp() +
// Process the job the day before the cache expires.
( $this->cache::TTL_WEEK - $this->cache::TTL_DAY ),
] )

Change 894699 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[schemas/event/secondary@master] homepagevisit: Add new referer routes

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

In T322435#8670215, @gerritbot wrote:

Change 894699 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[schemas/event/secondary@master] homepagevisit: Add new referer routes

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

^ adds referrer routes for links back to Special:Homepage from the notification, see https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/894043 for how it is used in the "keep going" notification.

@RHo if it's easy to do, can you please update the mock here along the lines of the update you made in T328288#8669075, to remove the bold from the secondary links and from the header?

In T322435#8670226, @kostajh wrote:

@RHo if it's easy to do, can you please update the mock here along the lines of the update you made in T328288#8669075, to remove the bold from the secondary links and from the header?

No worries, done!

Change 894699 merged by jenkins-bot:

[schemas/event/secondary@master] homepagevisit: Add new referer routes

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

Change 895134 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/GrowthExperiments@master] i18n: Add strings for get started notification

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

Change 895134 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] i18n: Add strings for get started notification

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

Does anybody (@RHo ?) have the URL for the "learn more" link? I realized that Figma doesn't actually specify, it just says "a specific help page."

@KMorgan-WMF
I presume we should be linking to this page:
https://www.mediawiki.org/wiki/Help:Growth/Tools/Suggested_edits

Although @RHo should correct me if I'm mistaken.

But I'm not sure how to that is managed with localization, so make sure you check with the Engineers in Slack if you need help with that. Thank you!

In T322435#8689170, @KStoller-WMF wrote:

@KMorgan-WMF
I presume we should be linking to this page:
https://www.mediawiki.org/wiki/Help:Growth/Tools/Suggested_edits

Although @RHo should correct me if I'm mistaken.

But I'm not sure how to that is managed with localization, so make sure you check with the Engineers in Slack if you need help with that. Thank you!

This should be covered as part of the copy task T324315 where it says the destination for the help text as well as the label. However, I had a quick check and it seems that this has not been included so would defer to wherever it is @KStoller-WMF you and @Trizek_WMF think it makes sense to link to, and then guessing the copy and QQQ should be updated, along with marking the page for translation?

In T322435#8689176, @RHo wrote:

In T322435#8689170, @KStoller-WMF wrote:

@KMorgan-WMF
I presume we should be linking to this page:
https://www.mediawiki.org/wiki/Help:Growth/Tools/Suggested_edits

Although @RHo should correct me if I'm mistaken.

But I'm not sure how to that is managed with localization, so make sure you check with the Engineers in Slack if you need help with that. Thank you!

This should be covered as part of the copy task T324315 where it says the destination for the help text as well as the label. However, I had a quick check and it seems that this has not been included so would defer to wherever it is @KStoller-WMF you and @Trizek_WMF think it makes sense to link to, and then guessing the copy and QQQ should be updated, along with marking the page for translation?

Does the copy book specify the destination for the "Learn more" label? I am not seeing that. The string "Learn more" is in growthexperiments-levelingup-getstarted-notification-learnmore-label which was added in rEGRE8a21e8f0a11b: i18n: Add strings for get started notification.

In T322435#8689206, @kostajh wrote:

In T322435#8689176, @RHo wrote:

In T322435#8689170, @KStoller-WMF wrote:

@KMorgan-WMF
I presume we should be linking to this page:
https://www.mediawiki.org/wiki/Help:Growth/Tools/Suggested_edits

Although @RHo should correct me if I'm mistaken.

But I'm not sure how to that is managed with localization, so make sure you check with the Engineers in Slack if you need help with that. Thank you!

This should be covered as part of the copy task T324315 where it says the destination for the help text as well as the label. However, I had a quick check and it seems that this has not been included so would defer to wherever it is @KStoller-WMF you and @Trizek_WMF think it makes sense to link to, and then guessing the copy and QQQ should be updated, along with marking the page for translation?

Does the copy book specify the destination for the "Learn more" label? I am not seeing that. The string "Learn more" is in growthexperiments-levelingup-getstarted-notification-learnmore-label which was added in rEGRE8a21e8f0a11b: i18n: Add strings for get started notification.

Yes, sorry I was unclear, but imo the copy task *should* have specified the link, but it doesn't. My point is that pending decision of where the link should be (and if there needs to be a second link at all to learn more), that should be reflected in T324315.

Change 897973 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/GrowthExperiments@master] LevelingUp: Make "Learn more" label link to help page

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

Change 897973 abandoned by Kosta Harlan:

[mediawiki/extensions/GrowthExperiments@master] LevelingUp: Make "Learn more" label link to help page

Reason:

On second thought, the link should be specified in the Echo presentation model, not in the message.

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

In T322435#8689170, @KStoller-WMF wrote:

I presume we should be linking to this page:
https://www.mediawiki.org/wiki/Help:Growth/Tools/Suggested_edits

Linking to another wiki seems confusing to me. The user will have to figure out that they are on a different wiki (especially on mobile not that easy to notice), the user interface will be in English, the user might not be logged in anymore (because cross-wiki authentication is unreliable) which would further the confusion, and the brand recognition for mediawiki.org is approximately zero. Once we roll this feature out to many wikis, the chances of the page being translated to the user's language will be pretty low. And I wonder if users will even notice there is a main clickable area (IMO this is a design flaw of Echo).

Change 892614 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Leveling Up: Get Started Notification

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

In T322435#8690373, @Tgr wrote:

Linking to another wiki seems confusing to me. The user will have to figure out that they are on a different wiki (especially on mobile not that easy to notice), the user interface will be in English, the user might not be logged in anymore (because cross-wiki authentication is unreliable) which would further the confusion, and the brand recognition for mediawiki.org is approximately zero. Once we roll this feature out to many wikis, the chances of the page being translated to the user's language will be pretty low. And I wonder if users will even notice there is a main clickable area (IMO this is a design flaw of Echo).

Fair enough, but I don't know where else the "Learn more" link could lead. (Sorry I didn't notice this missing requirement earlier!)
Should we just remove that secondary call to action since users can quickly tap into “Try suggested edits” and learn more from there?

In T322435#8690492, @KStoller-WMF wrote:

In T322435#8690373, @Tgr wrote:

Linking to another wiki seems confusing to me. The user will have to figure out that they are on a different wiki (especially on mobile not that easy to notice), the user interface will be in English, the user might not be logged in anymore (because cross-wiki authentication is unreliable) which would further the confusion, and the brand recognition for mediawiki.org is approximately zero. Once we roll this feature out to many wikis, the chances of the page being translated to the user's language will be pretty low. And I wonder if users will even notice there is a main clickable area (IMO this is a design flaw of Echo).

Fair enough, but I don't know where else the "Learn more" link could lead. (Sorry I didn't notice this missing requirement earlier!)
Should we just remove that secondary call to action since users can quickly tap into “Try suggested edits” and learn more from there?

We could perhaps have it go to Special:Homepage and then automatically open the "Help" dialog for suggested edits module:

But arguably that should happen for the primary link action as well, as part of onboarding the user to the suggested edits concept. And in that case, we wouldn't need a secondary link.

I guess the easiest thing for now is to remove the secondary link entirely until we decide on how we want to handle this.

In T322435#8690492, @KStoller-WMF wrote:

In T322435#8690373, @Tgr wrote:

Linking to another wiki seems confusing to me. The user will have to figure out that they are on a different wiki (especially on mobile not that easy to notice), the user interface will be in English, the user might not be logged in anymore (because cross-wiki authentication is unreliable) which would further the confusion, and the brand recognition for mediawiki.org is approximately zero. Once we roll this feature out to many wikis, the chances of the page being translated to the user's language will be pretty low. And I wonder if users will even notice there is a main clickable area (IMO this is a design flaw of Echo).

This is a typical pattern for notifications (mobile devices, email inboxes) where the main part is the primary interaction area, and secondary actions go elsewhere. But agree the presence of secondary elements can lead to people not remembering the main bit is interactive because they tend to associate the verbs and actions in these areas as being actionable.
This suits the argument to remove the learn more link.

Fair enough, but I don't know where else the "Learn more" link could lead. (Sorry I didn't notice this missing requirement earlier!)
Should we just remove that secondary call to action since users can quickly tap into “Try suggested edits” and learn more from there?

+1 to removing for now if there's no good place for it to link.

For T328288: Leveling up: "Keep going" notification we use a secondary link that points to the same place as a the primary (for easier discoverability I imagine); we could do that here as well, for consistency. Or remove it there as well.

(A minor annoyance with secondary links is that they don't automatically mark the notification as read. Although we could fix that easily, it's just an extra query parameter.)

In T322435#8694080, @Tgr wrote:

For T328288: Leveling up: "Keep going" notification we use a secondary link that points to the same place as a the primary (for easier discoverability I imagine); we could do that here as well, for consistency. Or remove it there as well.

I thought the secondary link wasn't added?

In T328288#8669018, @kostajh wrote:

Sorry, I belatedly realized that we can alter the output as we wish for email notifications, so I have just excluded secondary links for email distribution type.

My understanding is that notification didn't have a secondary action because there is only one call to action and the user shouldn't need to "Learn more" because they have already completed Suggested edits previously.

It's only omitted for emails (where the primary link is a blue button and the secondary links are "quiet" backgroundless grey links, as can be seen e.g. at https://phabricator.wikimedia.org/T135574). This is how the two notifications look now on web (where the primary link is the entire notification area and the secondary links are "quiet" buttons at the bottom):

In T322435#8695089, @Tgr wrote:

It's only omitted for emails (where the primary link is a blue button and the secondary links are "quiet" backgroundless grey links, as can be seen e.g. at https://phabricator.wikimedia.org/T135574). This is how the two notifications look now on web (where the primary link is the entire notification area and the secondary links are "quiet" buttons at the bottom):

Ah, thank you so much for the clarification!
In my opinion, having a clear "Try suggested edits" secondary link / "quite" button is more likely to prompt an action, so I'm in favor of that approach. (And I think that's most in-line with the original designs).

In T322435#8695426, @KStoller-WMF wrote:

In T322435#8695089, @Tgr wrote:

It's only omitted for emails (where the primary link is a blue button and the secondary links are "quiet" backgroundless grey links, as can be seen e.g. at https://phabricator.wikimedia.org/T135574). This is how the two notifications look now on web (where the primary link is the entire notification area and the secondary links are "quiet" buttons at the bottom):

Ah, thank you so much for the clarification!
In my opinion, having a clear "Try a suggested edit" secondary link / "quite" button is more likely to prompt an action, so I'm in favor of that approach. (And I think that's most in-line with the original designs).

Then should we change the secondary link label to be "Make a suggested edit", or "Try suggested edits"? And to clarify, should the target for the URL be Special:Homepage or should it be the mediawiki.org help page? (IMO it would make sense for it to be Special:Homepage)

! In T322435#8697837, @kostajh wrote:
Then should we change the secondary link label to be "Make a suggested edit", or "Try suggested edits"? And to clarify, should the target for the URL be Special:Homepage or should it be the mediawiki.org help page? (IMO it would make sense for it to be Special:Homepage)

The secondary link should be "Try suggested edits".
The target for the URL will be Special:Homepage on Desktop.
The target for the URL will be the Homepage's Suggested edits module on Mobile.

In T322435#8699199, @KStoller-WMF wrote:

! In T322435#8697837, @kostajh wrote:
Then should we change the secondary link label to be "Make a suggested edit", or "Try suggested edits"? And to clarify, should the target for the URL be Special:Homepage or should it be the mediawiki.org help page? (IMO it would make sense for it to be Special:Homepage)

The secondary link should be "Try suggested edits".
The target for the URL will be Special:Homepage on Desktop.
The target for the URL will be the Homepage's Suggested edits module on Mobile.

Sounds good. I also changed the icon to the edit pencil, I assume that is preferred?

Change 899727 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/GrowthExperiments@master] EchoGetStartedPresentationModel: Adjust secondary link

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

In T322435#8699363, @kostajh wrote:

In T322435#8699199, @KStoller-WMF wrote:

! In T322435#8697837, @kostajh wrote:
Then should we change the secondary link label to be "Make a suggested edit", or "Try suggested edits"? And to clarify, should the target for the URL be Special:Homepage or should it be the mediawiki.org help page? (IMO it would make sense for it to be Special:Homepage)

The secondary link should be "Try suggested edits".
The target for the URL will be Special:Homepage on Desktop.
The target for the URL will be the Homepage's Suggested edits module on Mobile.

Sounds good. I also changed the icon to the edit pencil, I assume that is preferred?

Email:

Change 899727 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] EchoGetStartedPresentationModel: Adjust secondary link

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

In T322435#8699363, @kostajh wrote:
Sounds good. I also changed the icon to the edit pencil, I assume that is preferred?

Yes, thank you! And thank you for the example screenshots!

Is there anything special I should know when testing? For example, when testing on Betawiki, will these notifications get triggered about 48 hours after an account is created?

Sent to newcomers with Growth features who have not made a suggested edit within $(48) hours of opening an account.

In T322435#8700358, @KStoller-WMF wrote:

Is there anything special I should know when testing? For example, when testing on Betawiki, will these notifications get triggered about 48 hours after an account is created?

We have configured beta to send the notifications five minutes after registration.

In T322435#8700475, @Tgr wrote:

In T322435#8700358, @KStoller-WMF wrote:

Is there anything special I should know when testing? For example, when testing on Betawiki, will these notifications get triggered about 48 hours after an account is created?

We have configured beta to send the notifications five minutes after registration.

FWIW it looks like job running was broken on beta cluster (T332211: deployment-docker-changeprop01: `worker died, restarting`) but should now be working again.

In T322435#8726243, @Etonkovidova wrote:

Tested on betacluster (testwiki wmf.1 is not configured for the get started notificaiton?).

The wrapping issue is filed as T332744

@Etonkovidova Testwiki is configured for the Get Started notification, so if you are not seeing the notification and you followed the steps to trigger it (new user account, no suggested edits) there might be a bug...

In T322435#8728237, @kostajh wrote:

@Etonkovidova Testwiki is configured for the Get Started notification, so if you are not seeing the notification and you followed the steps to trigger it (new user account, no suggested edits) there might be a bug...

We are not reducing the notification delay like we do on beta, though.

In T322435#8729290, @Tgr wrote:

In T322435#8728237, @kostajh wrote:

@Etonkovidova Testwiki is configured for the Get Started notification, so if you are not seeing the notification and you followed the steps to trigger it (new user account, no suggested edits) there might be a bug...

We are not reducing the notification delay like we do on beta, though.

Thanks, @kostah and @Tgr - the both notifications are in place (the screenshot are from testwiki wmf.2):