Page MenuHomePhabricator

[IP Masking] Temporary account to registered account creation flow
Closed, ResolvedPublic4 Estimated Story Points

Assigned To
Authored By
sdkim
Jan 27 2022, 4:58 PM
Referenced Files
F45276565: Screen Shot 2024-04-08 at 4.03.10 PM.png
Apr 8 2024, 11:16 PM
F45276554: Screen Shot 2024-04-08 at 4.02.49 PM.png
Apr 8 2024, 11:16 PM
F45276917: Screen Shot 2024-04-08 at 4.13.53 PM.png
Apr 8 2024, 11:16 PM
F45276310: Screen Shot 2024-04-08 at 4.00.57 PM.png
Apr 8 2024, 11:16 PM
F45276254: Screen Shot 2024-04-08 at 4.00.12 PM.png
Apr 8 2024, 11:16 PM
F41474378: Screen Shot 2023-11-08 at 1.40.31 PM.png
Nov 8 2023, 11:02 PM
F41474373: Screen Shot 2023-11-08 at 2.56.34 PM.png
Nov 8 2023, 11:02 PM
F41474308: Screen Shot 2023-11-08 at 2.32.25 PM.png
Nov 8 2023, 10:52 PM

Description

User Story

As someone who is using a temporary account,
When I decide to Create an account or Log in,
I want to know if the temporary account edits will be associated with the user account,
So that I can proceed to account creation/log in being assured temporary edits will be separate.

Figma MVP mocks here: https://www.figma.com/file/xECM2hD7vEemP91M9YAQBC/IP-Masking?type=design&node-id=1020-26694&mode=design&t=sKS7HcUAXz97VCel-4


Currently, when a temp user clicks on Create account or Login, the following banner is displayed, which uses the incorrect warning style message and also outdated copy:

Screen Shot 2023-07-26 at 8.58.41 AM.png (1×2 px, 314 KB)

Acceptance Criteria:

Given I'm logged into a temporary account,
When I navigate to create an account or Login,
Then the create account form displays a message as shown in the designs below

  • Updated styling of the notice (The edits made with this temporary account .... will not be connected to your new account)
  • Updated styling of the benefits block (Thank you for contributing to Wikipedia. Create an account to access more features...)
  • Instrumentation: ensure we can track impressions, success, and abandonment rate on this form tracked in T346327
Create accountDesktop
image.png (2×2 px, 380 KB)
Mobile
image.png (1×720 px, 112 KB)
Log inDesktop
image.png (2×2 px, 193 KB)
Mobile
image.png (1×720 px, 112 KB)

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

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

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?

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?

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.

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?

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.

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.

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

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:
Screen Shot 2023-11-08 at 2.41.40 PM.png (1×3 px, 383 KB)
Screen Shot 2023-11-08 at 2.26.55 PM.png (1×3 px, 566 KB)
  • 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:

Screen Shot 2023-11-08 at 2.30.37 PM.png (1×1 px, 258 KB)

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

Screen Shot 2023-11-08 at 2.32.25 PM.png (1×854 px, 149 KB)

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)

Screen Shot 2023-11-08 at 2.56.34 PM.png (1×3 px, 371 KB)

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

Screen Shot 2023-11-08 at 1.40.31 PM.png (1×3 px, 342 KB)

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

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:
Screen Shot 2023-11-08 at 2.41.40 PM.png (1×3 px, 383 KB)
Screen Shot 2023-11-08 at 2.26.55 PM.png (1×3 px, 566 KB)
  • 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:

Screen Shot 2023-11-08 at 2.30.37 PM.png (1×1 px, 258 KB)

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

Thanks for the thorough testing, @Etonkovidova !

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

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:
Screen Shot 2023-11-08 at 2.41.40 PM.png (1×3 px, 383 KB)
Screen Shot 2023-11-08 at 2.26.55 PM.png (1×3 px, 566 KB)
  • 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:

Screen Shot 2023-11-08 at 2.30.37 PM.png (1×1 px, 258 KB)

@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

Urbanecm_WMF set the point value for this task to 4.Nov 28 2023, 11:56 AM
Cyndymediawiksim raised the priority of this task from Medium to High.Nov 29 2023, 2:38 PM
Cyndymediawiksim lowered the priority of this task from High to Medium.

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

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

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

Code for this task is all merged already. The remaining portion is instrumentation, which is tracked as T346327: Track impressions, success and abandonment rate on the signup form.

Code for this task is all merged already. The remaining portion is instrumentation, which is tracked as T346327: Track impressions, success and abandonment rate on the signup form.

I re-check the functionality on cswiki beta - the updated screenshots are below. I repeated the testing scenarios listed in my comment - https://phabricator.wikimedia.org/T300273#9317984. No issues are found.
Since instrumentation is tracked down in T346327, I'm closing this task as Resolved; the task is added for reference to T341839: [QA task] IP masking - temp users testing in production

Test scenarioDesktopMobile
A temp user clicks on Login
Screen Shot 2024-04-08 at 4.00.12 PM.png (1×2 px, 248 KB)
Screen Shot 2024-04-08 at 4.00.57 PM.png (1×882 px, 168 KB)
A temp user clicks on Create account
Screen Shot 2024-04-08 at 4.13.53 PM.png (1×3 px, 487 KB)
Two-part screenshot:
Screen Shot 2024-04-08 at 4.02.49 PM.png (1×866 px, 199 KB)
Screen Shot 2024-04-08 at 4.03.10 PM.png (1×858 px, 214 KB)

Change #962569 merged by jenkins-bot:

[schemas/event/secondary@master] Add analytics for Impressions, Success and Abandonment of account creation

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

Change #989216 had a related patch set uploaded (by Urbanecm; author: Cyndywikime):

[operations/mediawiki-config@master] Add account_conversion event streams.

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