Page MenuHomePhabricator

[Epic] Guidance for discovery of IP Reveal feature
Open, HighPublic

Description

User stories

As an active editor patrolling the wikis...
I want to easily find and enable the IP Reveal feature, in order to continue to fight vandalism and abuse.
I want to understand what temporary accounts are and how to work with them, in order to continue to fight vandalism and abuse.

Motivation

After temporary accounts go into effect, a significant number of active editors will want to turn on the IP Reveal feature to assist them in their patrolling efforts. Currently, this feature is buried in the Preferences page and is hard to discover. We want to make it easier for editors looking for this feature to find it and enable it.

We do something similar for IP Info where we show a dialog box on Special:Contributions after a user visits it that asks the user to accept the terms of use.

An example of this is how RecentChanges Filters were introduced to editors with a popover invite that allowed them to enable them on the spot. Ticket: T144457: Invite users to opt in to the RC Filters beta from the RC page, and educate them about its features

Specifications
  • Onboarding dialog will only display to logged-in editors who meet access requirements.
  • The dialog will display when users encounter temporary accounts for the first time on Recent Changes, Watchlist and History pages (i.e. these pages contain edits made by a temp account).
  • The dialog will not be shown if CheckUser is not enabled (i.e. it won't be shown for IPInfo alone).
  • There are no plans to remove the onboarding dialog.
  • Onboarding dialog consists of three screens:
  • Users who meet access requirements can enable IP Info via a checkbox on second screen. (If they have already enabled the preference, they won't see the checkbox.)
  • Users who meet access requirements can enable IP Reveal by following a link to Special:Preferences from third screen.
  • Users can choose not to see onboarding dialog again by clicking "don't show again" checkbox, from any panel. This will set a hidden preference. There won't be any UI to change the preference back.

Subtasks: We are splitting up the engineering work because the IP Reveal panel has a dependency on the thresholds for IP address access. We should not build that out before we finalize any changes needed to the thresholds. This is pending a Legal conversation.

Design

Figma file

25 Oct - Onboarding temp accounts.png (3×3 px, 760 KB)

Illustrations

Copy

Copy doc here

Event Timeline

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

@KColeman-WMF I like the designs! We could probably wordsmith the text a bit and run it by Legal.

@Niharika I believe we want to encourage use of IP Info rather than IP Reveal as it's more sensitive (PII)?

I agree with encouraging IP Info over IP Reveal. IP Info should provide a lot of the information that is needed for day-to-day patrolling. IP Reveal should be used for advanced patrolling use cases.

Would like to hear your thoughts on this! I am wondering if we want to show the IP Reveal step to all users, or whether that should only display to logged in users with the permission?

I guess before we answer this I want to understand when/how the initial (Temporary Accounts) dialog be triggered and which users will see it. What are you thinking?

For comparison, this is the onboarding dialog with opt-in checkboxes for IP Info and IP Reveal. It does seem like a lot of text but on the plus side it means users can enable the setting quickly. Interested to hear feedback.

15 Oct - Onboarding dialog with opt-in.png (1×2 px, 216 KB)

Can we adjust the text in step 1 to be more generic (it uses "you" a lot) so that it is more readily applicable to existing users who would want to read this to understand what a temporary account is? Otherwise, we could keep the existing wording in step 1 but only show it to not-yet-logged-in users who open the editor; logged-in, named users would see different wording in step 1.

@KColeman-WMF I like the designs! We could probably wordsmith the text a bit and run it by Legal.

@Niharika I believe we want to encourage use of IP Info rather than IP Reveal as it's more sensitive (PII)?

I agree with encouraging IP Info over IP Reveal. IP Info should provide a lot of the information that is needed for day-to-day patrolling. IP Reveal should be used for advanced patrolling use cases.

Would like to hear your thoughts on this! I am wondering if we want to show the IP Reveal step to all users, or whether that should only display to logged in users with the permission?

I guess before we answer this I want to understand when/how the initial (Temporary Accounts) dialog be triggered and which users will see it. What are you thinking?

Just noting what the existing UX looks like for anons:

image.png (1×1 px, 155 KB)

image.png (1×2 px, 176 KB)

image.png (1×2 px, 251 KB)

Adding a popup dialog in this place might have an effect of deterring new edits. So maybe it would make to show immediately after the user has edited for the first time?

For existing, named users, it would probably be easiest to show on their next page view after the feature has been enabled. I'm wondering how someone would get back to this dialog, though, if they close it. (And wondering if "don't show again" is needed?)

I'm not sure it makes sense to show the guidance to temp account holders. They will have links to find out what temporary accounts are (as evident from screenshots @kostajh added plus the grey bar) and they probably won't care very much.

For registered users, I think we could show them this dialog the first time they are on a page where they will encounter temp accounts (log, history, recentchanges, a talk page etc) so they understand what they are seeing. Some logged in editors may only care about editing pages and not so much about temp accounts/IP addresses.

@KColeman-WMF what do you think?

We could probably wordsmith the text a bit and run it by Legal.

Sounds good. I lifted the copy for the first screen from this wiki page but it would be good to run all the copy by Legal and be as concise as possible.

I'm not sure it makes sense to show the guidance to temp account holders. They will have links to find out what temporary accounts are (as evident from screenshots @kostajh added plus the grey bar) and they probably won't care very much.

For registered users, I think we could show them this dialog the first time they are on a page where they will encounter temp accounts (log, history, recentchanges, a talk page etc) so they understand what they are seeing. Some logged in editors may only care about editing pages and not so much about temp accounts/IP addresses.

@KColeman-WMF what do you think?

Yes this was my thinking too. Although I had thought it could display to all users who encounter a temp account for the first time, not just registered users, because someone might be reading recent changes logged-out and want to know about temp accounts. If we only show the dialog once then we could remove the 'don't show again' checkbox.

Also wondering if we should only show the final IP Reveal screen to registered users who meet the access requirements.

Can we adjust the text in step 1 to be more generic (it uses "you" a lot) so that it is more readily applicable to existing users who would want to read this to understand what a temporary account is? Otherwise, we could keep the existing wording in step 1 but only show it to not-yet-logged-in users who open the editor; logged-in, named users would see different wording in step 1.

Yes good idea. Ideally we have generic copy that makes sense to all users.

Yes this was my thinking too. Although I had thought it could display to all users who encounter a temp account for the first time, not just registered users, because someone might be reading recent changes logged-out and want to know about temp accounts. If we only show the dialog once then we could remove the 'don't show again' checkbox.

That sounds fine to me. I think it would be good to also highlight what's changed in the first panel to say that we we longer publish IP addresses of logged out editors (again we can wordsmith this separately).

Also wondering if we should only show the final IP Reveal screen to registered users who meet the access requirements.

IP Info and IP Reveal will have the same access requirements after T375086: Bring IP Info access permissions to parity with the IP Reveal feature is done. I think it makes sense to show both of those only to users who have access. For IP Info, ability to turn it on from the guidance panel is a great idea.

Also wondering if we should only show the final IP Reveal screen to registered users who meet the access requirements.

IP Info and IP Reveal will have the same access requirements after T375086: Bring IP Info access permissions to parity with the IP Reveal feature is done. I think it makes sense to show both of those only to users who have access. For IP Info, ability to turn it on from the guidance panel is a great idea.

Do we want to include the ability to turn on IP Reveal in the dialog, or only IP Info?

Also wondering if we should only show the final IP Reveal screen to registered users who meet the access requirements.

IP Info and IP Reveal will have the same access requirements after T375086: Bring IP Info access permissions to parity with the IP Reveal feature is done. I think it makes sense to show both of those only to users who have access. For IP Info, ability to turn it on from the guidance panel is a great idea.

Do we want to include the ability to turn on IP Reveal in the dialog, or only IP Info?

I'd lean towards "only IP Info" but link to Special:Preferences for those who want to turn on IP Reveal.

I'd lean towards "only IP Info" but link to Special:Preferences for those who want to turn on IP Reveal.

Thanks! Here are a few illustration options that I'll review with the design team this week. I'm leaning towards the zoomed interface illustration (option B).

22 Oct - Onboarding temp accounts.png (1×4 px, 469 KB)

This is the final design and illustrations (it's been through design team review). Note that I will create a set of illustrations for RTL languages.

24 Oct - Onboarding temp accounts.png (2×3 px, 737 KB)

Outstanding questions:
  1. Do we include "don't show again" checkbox?
  2. If so, do we want to limit how many times a user sees the dialog (perhaps 3 times unless they select 'don't show again')?
  3. How long do we imagine the onboarding dialog will be available/any thoughts on sunsetting plan (this was raised in design review)?
  4. Who can we work with from Legal on the copy?

@KColeman-WMF Thanks. I see that the designs say 'onboarding dialog displays to all users (logged-in and logged-out)'. Did the impact of this get discussed in the design review?
It feels a bit too much to me and I'd prefer showing the dialog to people who might find this information useful/relevant.

@KColeman-WMF Thanks. I see that the designs say 'onboarding dialog displays to all users (logged-in and logged-out)'. Did the impact of this get discussed in the design review?
It feels a bit too much to me and I'd prefer showing the dialog to people who might find this information useful/relevant.

We didn't discuss this in review. Happy to change it though!

Would you suggest we only show the dialog to logged-out users (who could end up as temp accounts) and logged-in users who meet access requirements for IP Info and IP Reveal?

@KColeman-WMF Thanks. I see that the designs say 'onboarding dialog displays to all users (logged-in and logged-out)'. Did the impact of this get discussed in the design review?
It feels a bit too much to me and I'd prefer showing the dialog to people who might find this information useful/relevant.

We didn't discuss this in review. Happy to change it though!

Would you suggest we only show the dialog to logged-out users (who could end up as temp accounts) and logged-in users who meet access requirements for IP Info and IP Reveal?

I think it would be good to discuss this with design.

Perhaps we could show this dialog to logged-out users who open the editor -- vast majority of logged-out people are just editors and we shouldn't disrupt their experience with a dialog that doesn't concern them.
Happy with showing the dialog to logged-in editors who meet access requirements.

CC @MMiller_WMF who had some thoughts on this one.

I think we should bring in folks from Editing/Web to review this.

I think it would be good to discuss this with design.

Perhaps we could show this dialog to logged-out users who open the editor -- vast majority of logged-out people are just editors and we shouldn't disrupt their experience with a dialog that doesn't concern them.
Happy with showing the dialog to logged-in editors who meet access requirements.

CC @MMiller_WMF who had some thoughts on this one.

I think we should bring in folks from Editing/Web to review this.

Thanks @Niharika - I'll bring this to design review. I like your idea to show it to logged-out users who open the editor as it means we won't miss out on the people who may become temp accounts.

I think it would be good to discuss this with design.

Perhaps we could show this dialog to logged-out users who open the editor -- vast majority of logged-out people are just editors and we shouldn't disrupt their experience with a dialog that doesn't concern them.
Happy with showing the dialog to logged-in editors who meet access requirements.

CC @MMiller_WMF who had some thoughts on this one.

I think we should bring in folks from Editing/Web to review this.

Thanks @Niharika - I'll bring this to design review. I like your idea to show it to logged-out users who open the editor as it means we won't miss out on the people who may become temp accounts.

We should check with Growth team about this (cc @KStoller-WMF). I'd be worried about the potential for this dialog having an impact on the rate of completion of first edits (e.g. user sees the banner, and that stops some percentage of good faith people from going through with the edit). Perhaps we could show it after the first edit?

I'd be worried about the potential for this dialog having an impact on the rate of completion of first edits (e.g. user sees the banner, and that stops some percentage of good faith people from going through with the edit).

I agree; I share the same concern. Displaying this dialog to logged-out users seems beyond the scope of the user story and the intended goals of this task.

@Niharika given the concerns noted, I think we should go with your suggestion and only show the dialog to logged-in editors who meet access requirements.

KColeman-WMF changed the task status from Stalled to In Progress.Mon, Nov 18, 1:22 PM
KColeman-WMF updated the task description. (Show Details)

Copy has been reviewed and approved by Legal. @Niharika can you confirm that we will only show this dialog to logged-in editors who meet access requirements?

KColeman-WMF changed the task status from In Progress to Open.EditedWed, Nov 20, 3:18 PM

Design and copy are now confirmed, this task is ready for engineering.

We intend to split this task into two subtasks so that screens 1 and 2 can be built first, while we await updated eligibility criteria for IP Reveal.

KColeman-WMF updated the task description. (Show Details)
KColeman-WMF subscribed.

@Urbanecm please can you review this onboarding dialog when you get a moment? Thanks!

Niharika changed the status of subtask T380955: Build the IP Reveal guidance panel from Open to Stalled.
Niharika renamed this task from Guidance for discovery of IP Reveal feature to [Epic] Guidance for discovery of IP Reveal feature.Wed, Nov 27, 6:46 AM
Niharika updated the task description. (Show Details)

Thank you for the ping, @KColeman-WMF! Generally, the design seem like a step towards the right direction. I am wondering about a couple of things:

  • The first screen uses the word "you" to label an anonymous editor. However, from this task's description, this guidance is intended towards established users (with a registered account). On the other hand, second screen talks about admins/patrollers/experienced users using the third person (even though an experienced user is likely the one behind the screen). This feels potentially misleading.
  • The Figma screenshots mentions the dialog would be shown to logged out editors as well. That feels redundant, and it also contradicts the task's description. What behavior is the desired one here, please?
  • In general, I don't understand when would the guidance appear, and to who. The description mentions it would display at RC, watchlist and history. Would it appear to any user on those pages (including Temporary accounts themselves and including readers)? Or would it only show to named users (or perhaps a subset of them)?
    • It does also say they need to meet access requirements, which clarifies.
  • (This might not be related to the design phase) When would the dialog become visible to users? The guidance would likely increase the number of users who enable their accesses (IP Info or IP Reveal). At the same time, we hear back from communities that the threshold (which are the same for both access rights). The description says building the IP Reveal panel is blocked by the threshold conversations, but given the thresholds are equal for both, the argument seems to apply for both panels?

Thanks @Urbanecm! I realise now that the design in the task description hadn't been updated with the copy that was signed off by Legal. Apologies about that! The updated copy addresses a number of your points.

  • The first screen uses the word "you" to label an anonymous editor. However, from this task's description, this guidance is intended towards established users (with a registered account). On the other hand, second screen talks about admins/patrollers/experienced users using the third person (even though an experienced user is likely the one behind the screen). This feels potentially misleading.

The copy has been updated to remove any mention of "you". It is now consistent and applicable to registered logged-in users.

  • The Figma screenshots mentions the dialog would be shown to logged out editors as well. That feels redundant, and it also contradicts the task's description. What behavior is the desired one here, please?

This was out-of-date information. The dialog will only appear to logged-in editors who meet access requirements.

  • In general, I don't understand when would the guidance appear, and to who. The description mentions it would display at RC, watchlist and history. Would it appear to any user on those pages (including Temporary accounts themselves and including readers)? Or would it only show to named users (or perhaps a subset of them)?

It would only appear on RC, watchlist and history if there are temporary account edits on the page, and only registered users who meet the access requirements would see the dialog.

  • (This might not be related to the design phase) When would the dialog become visible to users? The guidance would likely increase the number of users who enable their accesses (IP Info or IP Reveal). At the same time, we hear back from communities that the threshold (which are the same for both access rights). The description says building the IP Reveal panel is blocked by the threshold conversations, but given the thresholds are equal for both, the argument seems to apply for both panels?

This is a good point. My understanding is that we want to encourage use of IP Info, whereas we want to be more cautious about the uptake of IP Reveal. But I'll wait for @Niharika to clarify further.

(This might not be related to the design phase) When would the dialog become visible to users? The guidance would likely increase the number of users who enable their accesses (IP Info or IP Reveal). At the same time, we hear back from communities that the threshold (which are the same for both access rights). The description says building the IP Reveal panel is blocked by the threshold conversations, but given the thresholds are equal for both, the argument seems to apply for both panels?

That's a good point. I do think it would be better to channel users towards IP Info more widely than to IP Reveal. @Urbanecm to clarify, we want to launch all of the guidance together so even if the IP Reveal panel is built later we will wait on it to release. We split up the work just so engineering could get started on a piece of it.
I think one way to do this would be to build out all the panels and let the thresholds be configurable so we can change them after the fact as needed. Another possibility is to wait on the legal conversations needed about thresholds to build the IP Info and IP Reveal panels.
@Tchanders do you have any thoughts on this?

@Niharika I think configurable thresholds is a good idea.

I'm just working on a technical plan now. One thing that makes this more complicated than initially thought is that the onboarding dialogue component doesn't yet exist in Codex. I believe @KColeman-WMF is going to ask DST for it, but I wouldn't expect it to be ready in time for us, given that we only have a few sprints left. If we can essentially copy what GrowthExperiments does, that could make things a bit simpler.

Here are some thoughts on implementation. @KColeman-WMF @Niharika There are a few product questions marked in bold below.

How to add the dialog to the Special:RecentChanges, Special:Watchlist and history pages

  • Write a JS module that adds a multi-step dialog:
    • Technical question: would this use Codex?
      • There are some tasks suggesting this kind of component is still under development: T336270, T315535
      • If we need a quick, safe option, this kind of dialog has been tried and tested in OOUI (a ProcessDialog with a StackLayout, e.g. GrowthExperiments' MultiPaneDialog)
  • Onboarding to IPInfo and CheckUser's IP reveal
    • The IPInfo panel could either be added by IPInfo itself responding to a hook, or from CheckUser gated behind a check for IPInfo being loaded
    • Product question: if a wiki has IPInfo but not CheckUser, would we need this onboarding dialog?
      • From a technical perspective, I'm hoping not since it would be more to implement/maintain for what seems like an unlikely scenario
  • Add the module via the BeforePageDisplay hook
    • CheckUser already handles this hook to add modules/ext.checkUser
    • The existing handler already checks for the IP reveal rights
    • dispatcher.js works out exactly which scripts to add to which pages
    • dispatcher.js would add the onboarding dialog if:
      • we're on Special:RecentChanges, Special:Watchlist or history page
      • any temp user links exist on the page (checking for mw-tempuserlink class)
      • the user hasn't clicked on "Don't show again" (see below)

How to add the preferences checkbox

  • We do something similar in ext.ipInfo./infobox/init.js
  • Product question: would we show this if the preference had already been checked?

How to handle "Don't show again"

  • Product question: would clicking this on any panel mean don't show any part of the dialog again, or just don't show that panel again?
  • We could make "Don't show again" permanent, by setting a user preference
    • This would be difficult for the user to undo (they'd need to make an API call to change the preference)
    • Product question Should we provide some UI to allow them to see the dialog again?
  • We could make this less permanent, by storing a setting in localStorage, but...
    • Con: this would not be shared across domains, so the user would encounter the dialog again on a different project
    • Con: we're encouraged to set an expiry (MW garbage collects expired items), to avoid taking up space. We wouldn't be setting an expiry here.

Having spoken with @KColeman-WMF, here are answers to a couple of the product questions above:

Product question: would we show this if the preference had already been checked?

No

Product question: would clicking this on any panel mean don't show any part of the dialog again, or just don't show that panel again?

Don't show any part again

@Tchanders Having discussed the remaining product questions with @Niharika, here are the answers:

Product question: if a wiki has IPInfo but not CheckUser, would we need this onboarding dialog?

No, we think this only applies to third-party wikis and is an unlikely edge case.

Product question Should we provide some UI to allow them to see the dialog again?

No. Given that this isn't a feature (like Special:Investigate) the logical place to add a link to see the dialog again is with the IP Info and IP Reveal preferences. There is already a link to IP tool information alongside IP Info preferences, therefore we don't feel it's necessary to add a link to the dialog. We will monitor feedback and can add later if needed.

Additional question: How long should the feature remain live for?

It can remain indefinitely as users may cross the access rights threshold at an unknown later date and will need to see the guidance.

Niharika claimed this task.

Reopening this since it is the epic. My bad.

  • Technical question: would this use Codex?

I think it would be fine for the engineer who picks this up to decide this.

  NODES
admin 2
Idea 8
idea 8
Note 3
Project 6
USERS 63