In T373818#10274931, @KColeman-WMF wrote:

In T373818#10266991, @Niharika wrote:

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?

In T373818#10275914, @kostajh wrote:

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.

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?

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

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.

Thanks @KColeman-WMF and @Niharika.

I'd be happy to consider this done, and bring T380954: Build the first two panels for the temp accounts guidance into the next sprint.

In T373818#10368698, @Tchanders wrote:

• Technical question: would this use Codex?

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

@Niharika In December we briefly discussed instrumenting the dialog to track usage for the following reason: if we know how many users are setting a preference via the dialog, we can evaluate the success of explaining temporary accounts features and know if the onboarding dialog is an effective way to reach people.

Do we still want to go ahead with this?