Change 957675 had a related patch set uploaded (by Cyndywikime; author: Cyndywikime):

[mediawiki/core@master] Update styling of account creation flow for temporary accounts

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

Change 957250 abandoned by Cyndywikime:

[mediawiki/core@master] Update styling for temporary account to registered account flow

Reason:

This patch has been abandoned in favour of this one : https://gerrit.wikimedia.org/r/c/mediawiki/core/+/957675

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

Change 960646 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/core@master] Html: allow to pass a custom icon to noticeBox

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

A concern in regards using the standard notice vs warning has been brought in this Slack thread per @Jdlrobson:

One concern I would have about this is that on-wiki this happened leading to hundreds of boxes that have nothing to do with warnings/errors/notices and make the things that actually are warnings/errors/notices more prone to being ignored.
In this case why exactly would a temporary user icon be preferred over a more standard icon?
FWIW this seems like a warning to me - and I was surprised it wasn’t yellow - I tend to personally ignore all the gray boxes

Should we stick to the warning message?

...and also about overriding the default information icon by the temporary user icon, apparently it goes against our Design Style Guide, see Messages > Types > Neutral or notice message:

Neutral or notice block messages provide general user feedback. Accompany the message by the 'infoFilled' icon.

Should we use the default 'i'?

cc @RHo @JFernandez-WMF

In T300273#9198610, @Sgs wrote:

A concern in regards using the standard notice vs warning has been brought in this Slack thread per @Jdlrobson:

One concern I would have about this is that on-wiki this happened leading to hundreds of boxes that have nothing to do with warnings/errors/notices and make the things that actually are warnings/errors/notices more prone to being ignored.
In this case why exactly would a temporary user icon be preferred over a more standard icon?
FWIW this seems like a warning to me - and I was surprised it wasn’t yellow - I tend to personally ignore all the gray boxes

Should we stick to the warning message?

No, the decision to use the neutral notice is because we do not wish to suggest that there is something wrong with editing with a temp account, especially once they have come to this point of creating a permanent account it would likely be confusing to show a warning here.

...and also about overriding the default information icon by the temporary user icon, apparently it goes against our Design Style Guide, see Messages > Types > Neutral or notice message:

Neutral or notice block messages provide general user feedback. Accompany the message by the 'infoFilled' icon.

Should we use the default 'i'?

I'm a little unclear why this is an issue here since there is a variant of the message component in Codex and OOUI for that matter that allows for a custom icon. Can we use the "notice" type with the temp account icon?

• https://doc.wikimedia.org/codex/main/components/demos/message.html

• https://doc.wikimedia.org/oojs-ui/master/demos/?page=widgets&theme=wikimediaui&direction=ltr&platform=desktop

In T300273#9198685, @RHo wrote:

In T300273#9198610, @Sgs wrote:

A concern in regards using the standard notice vs warning has been brought in this Slack thread per @Jdlrobson:

One concern I would have about this is that on-wiki this happened leading to hundreds of boxes that have nothing to do with warnings/errors/notices and make the things that actually are warnings/errors/notices more prone to being ignored.
In this case why exactly would a temporary user icon be preferred over a more standard icon?
FWIW this seems like a warning to me - and I was surprised it wasn’t yellow - I tend to personally ignore all the gray boxes

Should we stick to the warning message?

No, the decision to use the neutral notice is because we do not wish to suggest that there is something wrong with editing with a temp account, especially once they have come to this point of creating a permanent account it would likely be confusing to show a warning here.

If there is no problem with editing with the temporary account, maybe we could update the copy to make it less warning and more neutral/notice. We could rephrase it to something like "Keep in mind that you are editing with a temporary account, so the edits made here will not be connected to your new account".

...and also about overriding the default information icon by the temporary user icon, apparently it goes against our Design Style Guide, see Messages > Types > Neutral or notice message:

Neutral or notice block messages provide general user feedback. Accompany the message by the 'infoFilled' icon.

Should we use the default 'i'?

I'm a little unclear why this is an issue here since there is a variant of the message component in Codex and OOUI for that matter that allows for a custom icon. Can we use the "notice" type with the temp account icon?

• https://doc.wikimedia.org/codex/main/components/demos/message.html

• https://doc.wikimedia.org/oojs-ui/master/demos/?page=widgets&theme=wikimediaui&direction=ltr&platform=desktop

Although the notice icon can be customizable, I recommend in this case to use the info icon since it reinforce the informative intention if the notice message.

In T300273#9199024, @bmartinezcalvo wrote:

In T300273#9198685, @RHo wrote:

In T300273#9198610, @Sgs wrote:

A concern in regards using the standard notice vs warning has been brought in this Slack thread per @Jdlrobson:

One concern I would have about this is that on-wiki this happened leading to hundreds of boxes that have nothing to do with warnings/errors/notices and make the things that actually are warnings/errors/notices more prone to being ignored.
In this case why exactly would a temporary user icon be preferred over a more standard icon?
FWIW this seems like a warning to me - and I was surprised it wasn’t yellow - I tend to personally ignore all the gray boxes

Should we stick to the warning message?

No, the decision to use the neutral notice is because we do not wish to suggest that there is something wrong with editing with a temp account, especially once they have come to this point of creating a permanent account it would likely be confusing to show a warning here.

If there is no problem with editing with the temporary account, maybe we could update the copy to make it less warning and more neutral/notice. We could rephrase it to something like "Keep in mind that you are editing with a temporary account, so the edits made here will not be connected to your new account".

Thanks @bmartinezcalvo for the suggestion, however IMO using the phrase "Keep in mind" is making it more warning-like than the current message, and secondly part of the intention of the copy is to include the temp user name in the message. Let's keep as proposed text in the task for now.

...and also about overriding the default information icon by the temporary user icon, apparently it goes against our Design Style Guide, see Messages > Types > Neutral or notice message:

Neutral or notice block messages provide general user feedback. Accompany the message by the 'infoFilled' icon.

Should we use the default 'i'?

I'm a little unclear why this is an issue here since there is a variant of the message component in Codex and OOUI for that matter that allows for a custom icon. Can we use the "notice" type with the temp account icon?

• https://doc.wikimedia.org/codex/main/components/demos/message.html

• https://doc.wikimedia.org/oojs-ui/master/demos/?page=widgets&theme=wikimediaui&direction=ltr&platform=desktop

Although the notice icon can be customizable, I recommend in this case to use the info icon since it reinforce the informative intention if the notice message.

The purpose of using the temp account icon is to again emphasise that the person is currently using a temp account, and to draw attention to this as a specific message relating to user status rather than a more generic "info" message. My preference and recommendation remains to implement with this cdxIconUserTemporary icon please.

In T300273#9199090, @RHo wrote:

Thanks @bmartinezcalvo for the suggestion, however IMO using the phrase "Keep in mind" is making it more warning-like than the current message, and secondly part of the intention of the copy is to include the temp user name in the message. Let's keep as proposed text in the task for now.

In T300273#9199090, @RHo wrote:

The purpose of using the temp account icon is to again emphasise that the person is currently using a temp account, and to draw attention to this as a specific message relating to user status rather than a more generic "info" message. My preference and recommendation remains to implement with this cdxIconUserTemporary icon please.

Thanks for the clarifications. Moving forward with current design. I think we should update DSG Message adding some note about custom icons to reflect the discussion here. eg: Custom icons can be used on notice message boxes. They are rarely needed and should only be used when a particular aspect of the message needs to be emphasized.

Change 962569 had a related patch set uploaded (by Cyndywikime; author: Cyndywikime):

[schemas/event/secondary@master] Add analytics for Impressions, Success and Abandonment rate for temporary Users

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

Change 960646 merged by jenkins-bot:

[mediawiki/core@master] Html: allow to pass a custom icon to noticeBox

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

Blocked based by: T348232

In T300273#9295245, @KStoller-WMF wrote:

Blocked based by: T348232

Sergio and me discussed this, and decided T348232 is not a blocker. While it would be nice to complete T348232 at some point, but not necessarily as part of this task. I've approved the patch associated to this task. The last step are instrumentations, which are tracked separately in T346327. Moving to QA!

Change 957675 merged by jenkins-bot:

[mediawiki/core@master] Update styling of account creation flow for temporary accounts

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

Change 970874 had a related patch set uploaded (by Urbanecm; author: Amire80):

[mediawiki/core@master] Replace "Wikipedia" with {{SITENAME}} in benefit block messages

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

Change 970874 merged by jenkins-bot:

[mediawiki/core@master] Replace "Wikipedia" with {{SITENAME}} in benefit block messages

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

Change 971321 had a related patch set uploaded (by Urbanecm; author: Jon Harald Søby):

[mediawiki/core@master] Add period to message and remove unnecessary whitespace

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

Change 971321 merged by jenkins-bot:

[mediawiki/core@master] Add period to message and remove unnecessary whitespace

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

Checked in betalabs - looks as expected.
@KStoller-WMF - I listed below two issues (probably it makes sense to keep them as part of this task's scope since they are directly related to the re-designed Create account page for temp users).
(1) The benefit block is obscured by the tools side menu

• a temp user clicks on Create account and gets redirected to the Login page where the benefits block is not presented:

• since uncollapsed side menus are present by default, users will not discover the benefits block

(2) The benefits block on mobile (as @Tgr mentioned in https://phabricator.wikimedia.org/T300273#9052228) is visible and it has some display issues:

Note: the regular Create account side block text is presented reasonably well:

Testing notes (for checking after deployment as part of T341839: [QA task] IP masking - temp users testing in production:

• a temp user clicks on Login (the benefits block should not be present)

• a temp user attempts to reach Special:Watchlist or other named user page:

• a non-logged user goes to Create account page after the warning in VE (not making any edits): a normal login page is displayed (no benefits block)

Thanks for the thorough testing, @Etonkovidova !

I'll move this back to Ready as I agree these are both issues that should be resolved.

In T300273#9317972, @Etonkovidova wrote:

Checked in betalabs - looks as expected.
@KStoller-WMF - I listed below two issues (probably it makes sense to keep them as part of this task's scope since they are directly related to the re-designed Create account page for temp users).
(1) The benefit block is obscured by the tools side menu

• a temp user clicks on Create account and gets redirected to the Login page where the benefits block is not presented:

• since uncollapsed side menus are present by default, users will not discover the benefits block

(2) The benefits block on mobile (as @Tgr mentioned in https://phabricator.wikimedia.org/T300273#9052228) is visible and it has some display issues:

@Cyndymediawiksim - let me know if you prefer we track the follow-up work in a different task. Thanks!

In T300273#9318062, @KStoller-WMF wrote:

Thanks for the thorough testing, @Etonkovidova !

I'll move this back to Ready as I agree these are both issues that should be resolved.

In T300273#9317972, @Etonkovidova wrote:

Checked in betalabs - looks as expected.
@KStoller-WMF - I listed below two issues (probably it makes sense to keep them as part of this task's scope since they are directly related to the re-designed Create account page for temp users).
(1) The benefit block is obscured by the tools side menu

• a temp user clicks on Create account and gets redirected to the Login page where the benefits block is not presented:

• since uncollapsed side menus are present by default, users will not discover the benefits block

(2) The benefits block on mobile (as @Tgr mentioned in https://phabricator.wikimedia.org/T300273#9052228) is visible and it has some display issues:

@Cyndymediawiksim - let me know if you prefer we track the follow-up work in a different task. Thanks!

Thanks @Etonkovidova ! for the thorough testing. @KStoller-WMF, yes , we can track the follow-up work in a different task.

Change 962569 had a related patch set uploaded (by Cyndywikime; author: Cyndywikime):

[schemas/event/secondary@master] Add analytics for Impressions, Success and Abandonment rate for temporary Users

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

Schema change LGTM now (@nettrom_WMF fyi, in case you disagree with how https://gerrit.wikimedia.org/r/c/schemas/event/secondary/+/962569 looks like now). Not merging until the WikimediaEvents patch is ready, so that any last-time changes as the MW patch is being written are easy to do. Moving back to Doing for now.

Change 974540 had a related patch set uploaded (by Cyndywikime; author: Cyndywikime):

[mediawiki/core@master] Track Impressions, Success, Failure on the login and sign up form.

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

This is blocked on T346327.

Change 989205 had a related patch set uploaded (by Cyndywikime; author: Cyndywikime):

[schemas/event/primary@master] Add UserIsTemp property

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

Change 989487 had a related patch set uploaded (by Cyndywikime; author: Cyndywikime):

[schemas/event/primary@master] Add UserIsTemp property

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

Change 989205 abandoned by Cyndywikime:

[schemas/event/primary@master] Add UserIsTemp property

Reason:

Abandoned in favour of https://gerrit.wikimedia.org/r/c/schemas/event/primary/+/989487/

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

Change 989487 abandoned by Cyndywikime:

[schemas/event/primary@master] Add user_is_temp property

Reason:

Abandoned in favour of using mediawiki/state/entity/user instead.

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

@nettrom_WMF , with regards to the temporary account conversion schema: https://gerrit.wikimedia.org/r/c/schemas/event/secondary/+/962569 , what kind of data are you expecting in a success or failed login? In the scenario where we have user *Unregistered56:

 { 
id: 100, 
temp: true
 }

and that becomes Registered56

{
  page_title: "Special:UserLogin",
  event_type: "success",
  performer: {
    user_id: 100 or 101?
    temp: true or false
    name: Unregistered56 or Registered56?
  }
}

cc:@Sgs, @Urbanecm_WMF

In T300273#9571096, @Cyndymediawiksim wrote:

@nettrom_WMF , with regards to the temporary account conversion schema: https://gerrit.wikimedia.org/r/c/schemas/event/secondary/+/962569 , what kind of data are you expecting in a success or failed login? In the scenario where we have user *Unregistered56:

 { 
id: 100, 
temp: true
 }

and that becomes Registered56

{
  page_title: "Special:UserLogin",
  event_type: "success",
  performer: {
    user_id: 100 or 101?
    temp: true or false
    name: Unregistered56 or Registered56?
  }
}

cc:@Sgs, @Urbanecm_WMF

I think we'd want the performer of the Special:UserLogin to be the new, fully registered user account, and to modify the account_conversion schema to have a field where you can specify the ID of the temp account that was linked to the new account.

In T300273#9575941, @kostajh wrote:

I think we'd want the performer of the Special:UserLogin to be the new, fully registered user account, and to modify the account_conversion schema to have a field where you can specify the ID of the temp account that was linked to the new account.

How would that work when logging in a failed login attempt? Would the performer be null, the temporary account (which the user actually used) or the specified username (even if it is a typo, rather than a real connection)?

In other words: Do we want the performer field to have a different meaning based on whether the attempt succeeded or not (as in: performer would be the account one logged in as for successful attempts and the temporary account or null for everything else)? Would the difference reasonable to deal with for @nettrom_WMF as the analyst? Or would it be more meaningful

IMO the performer is always the current user (ie. anon or the temp user), and the username provided is the target (which should be its own field if you care about recording it). Especially for a failed login, there is no guarantee the person performing the login is the same as the target user, it might be a bruteforcing attempt or a user confusing what name they are using or whatever.

I agree with what's being said here. The performer values would reflect what the current user is, and if that user successfully logs in it'll reflect their logged in status. If the login attempt fails, it'll reflect their either anon or temp user status.

From an analytics point of view it would be convenient to have data that maps the change upon a successful login, but I don't think that's necessary if we have a session identifier that lets us rebuild it. And even then, I'm not sure we'd want to dig deeper as I think their behaviour once logged in is more important.

Change #974540 abandoned by Cyndywikime:

[mediawiki/core@master] Track Impressions, Success, Failure on the login and sign up form.

Reason:

Abandoned in favour of this patch : https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaEvents/+/979997

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