| Subject | Author | Repo | Branch | Lines +/- | |
|---|---|---|---|---|---|
| welcomesurvey: Skip on display=popup | Gergő Tisza | mediawiki/extensions/GrowthExperiments | master | +25 -1 |
Details
Details
Related Changes in Gerrit:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T396400 [Epic] Improvements to Authentication workflows | |||
| Open | ArielGlenn | T395459 Use OAuth rather than password-based login for Wikimedia mobile apps | |||
| Open | Tgr | T423608 Ensure OAuth flows don’t trigger new user onboarding |
Event Timeline
Comment Actions
I tested locally with GrowthExperiments and the workflow went through the new user onboarding (survey), but choosing to skip or completing it returned to the OAuth flow and allowed authorizing the app. I don't know if that's okay?
(We may still want to review other extensions for anything that interrupts the login workflow.)
Comment Actions
Change #1293082 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):
[mediawiki/extensions/GrowthExperiments@master] welcomesurvey: Skip on display=popup
Comment Actions
We could expose the fact that the login is part of OAuth (via a preserved parameter and/or an AuthenticationRequest like the one used by the Campaigns extension) to other extensions but I'm not sure whether we always want to skip onboarding.
What we definitely want to do is skip it in display=popup mode.
Comment Actions
Change #1293082 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] welcomesurvey: Skip on display=popup
Comment Actions
Works as expected.
Should we also skip the welcome survey on normal (not display=popup) OAuth flows? It's not relevant to the mobile use case, but it does seem like an unhelpful distraction even on full screen, even if it has a "skip" button.
Comment Actions
I can think of three ways to do that:
- Use the Campaigns extension's campaign parameter with something like oauth. Pro: gives metrics for free; GrowthExperiments can already fine-tune behavior for campaigns (including skipping onboarding). Con: prevents the use of other campaigns with OAuth (which probably wouldn't work right now anyway, but seems like a sensible thing to add), wouldn't work when Campaigns is not installed.
- Use wpprov (which is being moved to core). Pro: reuses an existing, well-understood parameter. Con: wpprov would have to be added to the preserved parameter list, maybe that messes with analytics somewhere. Like with campaign, it's conceivable someone would want to use provenance normally during an OAuth flow.
- Use a new query parameter (fromoauth=1?)
I think I'd go with the third option.