User stories:
Primary user story:
As a Temporary Account holder who has just published an edit, I want to clearly understand the benefits of creating a full account so that I can decide whether it is worth taking the extra step.
Secondary user story:
As a Temporary Account holder who is starting to contribute repeatedly, I want to understand how creating a full account helps me connect with other editors and be part of the community, so that my contributions feel more meaningful and recognized.
Background & research:
This task is a implementation task filed under T416418, which focuses on improving account creation conversion among Temporary Account users on mobile web.
Temporary Accounts lower the barrier to starting an edit, but they also limit our ability to support and retain contributors over time. Temporary Account users cannot receive email, and experienced editors have fewer ways to teach, mentor, or follow up with them. We do not consistently communicate the benefits of creating a full account, nor do we guide Temporary Account users toward registration at moments when motivation is likely to be highest.
The current post-publish experience on mobile web displays two separate floating messages after a Temporary Account user publishes an edit: one confirming the edit was published, and one notifying the user that a temporary account was created. These are MediaWiki Core system messages - not Codex components - and they are not optimized for conversion. Early data from the Temporary Accounts banner suggests there are opportunities to better align messaging, timing, and presentation with user intent and readiness.
Current UX reference (post-publish state for Temporary Account users):
The current flow is as follows:
- User taps the edit pencil on an article in read mode
- Editor begins loading
- System displays the logged-out warning message - user selects "Edit without logging in"
- Editor fully loads; user makes their edit and taps "Publish"
- The publish dialog is displayed
- After publish, the system briefly shows a white page with two overlapping floating banners simultaneously
- The page reloads with the same two banners still visible, plus a red dot notification in the header
- The "your edit was published" banner auto-dismisses after a timeout; the Temporary Account banner does not
This task proposes four concepts to explore as controlled experiments. All concepts are scoped to mobile web.
Design:
We will move forward with testing Concept 3:
Concept 3 - Persistent bottom sheet with account creation benefits
Replace the two existing post-publish floating messages with a persistent mobile Codex Popover. The bottom sheet confirms the edit was published and lists the benefits of creating an account, with a "Create account" CTA button.
| Before | After |
|---|---|
 |  |
Design amend: the popover will always show the backdrop/scrim
Acceptance Criteria:
- Given I am a Temp Account on mobile web
- When I publish an edit
- Then the two existing MediaWiki Core floating messages are suppressed
- And a bottom sheet is displayed confirming the edit was published, listing account creation benefits, and showing a "Create account" CTA button
- Given the bottom sheet is displayed
- When I tap "Create account"
- Then I am navigated to the account creation page
- Given the bottom sheet is displayed
- When I tap the dismiss control
- Then the bottom sheet is dismissed
Reduce calls to action:
- Given I have created a Temp Account on mobile web
- When I publish my first edit
- Then I do NOT get a notification
Consider the edge case for third party wikis that still use IP editing. We don't want to change that experience.
