similarly to T433019#12208238 we went through a process of "codex-ification":

1. to start we "converted" the existing module variants to use only codex tokens and components
   
2. then we tried to use the codex card component to display the mentor
   
3. we removed borders to reduce visual noise
   
4. brough the button to the main view so that it's not needed to "open" the module to ask a question to the mentor
   
5. then we turned ephemeral informational text to a dismissable element (thou we're unsure if this text is really needed. from 2 usability tests, we've observed participants understanding that the system assigned them a mentor without the explanatory text)
   
6. and swapped the arrow icon with a contextual menu to give immediate access to opt-out features, and info materials
   
7. and finally we brought over some of the changes that we've originally suggested as part of a mentorship-related design sprint (more on T397119)
   

sharing an update to inquire feedback! as a first step we took the existing mobile web module and went through a "codex-ification" process:

1. first, we looked at the suggested edits module in production
   
2. then we rebuild the same exact module with the same exact content with codex tokens and stock components
   
3. and we started to think how to remove potential elements to lighten the experience
   
4. then we wondered how we could expose more suggestions, like 3 instead of one
   
5. we tried removing the background and the border to reduce visual noise, especially as we plann to add more content to this page
   
6. swapped the robot icon with a lightbulb icon to standardize how suggestions are presented to people (building off 'suggestion mode' from the editing team)
   
7. and swapped the arrow icon with a contextual menu to give immediate access to interests, types of edits, and info materials
   
8. and those menu items open either a dialog (building off our 'account setup' work T430058) or a popover
   
   
   

originally i've used the 1 / 3 format to indicate the number of account setup steps but i remembered that for the revise tone onboarding we've used the 1 of 5 format (if i recally correctly for translation reasons).

In T432923#12188482, @KStoller-WMF wrote:

We will move in this direction as part of the broader epic: T419358: [EPIC] Personal Dashboard + Homepage [FY26-27, Deepen Engagement 1.3] as we shift to Home / Personal Dashboard. However as a team we have decided to NOT include this in the DE1.3.1 A/B test.

and here's the task from Reader Experience Team: T434156: Popover: make it possible to always show a bottom sheet

there is our mobile design using the current popover

just learned via slack that the Reader Experience Team is planning to push a patch to codex in the upcoming weeks. they're going to ping us once they're actively working on this!

given that the codex popover needs an anchor on desktop, we've indetified two options:

1. we anchor the popover to the user menu or temp user name
   
2. we make a change to codex so that the mobile popover works also on desktop (it's not hidden above 640px)
   
3. something else

2 options for review:

1. rely on the codex field optional prop
   
2. restore the previous label "Email address (recommended)" + description
   

sharing all the designs (figma file too) in this comment so that we can look through everything and address any remaning open question!

to get things started lemme share (hopefully) all the different variants of the suggested edits module as of today!

while playing around this is the current UX if there are now suggestions avaiable for the newcomer selected topics.

those are great prompts, @Isaac!

In T432812#12161330, @KStoller-WMF wrote:

when there are no 'suggested edits' based on the expressed interests we could (A) show no suggestions or (B) prompt newcomers to add more interests.

I wonder if we should also consider (C) show random suggestions along with a prompt to add more interests to receive more personalized suggestions.

In T432811#12160201, @KStoller-WMF wrote:

4. people add new interests/articles the 'related articles' keep updating.

Is that mockup correct, shouldn't the "Go to your Home" button be active after 3 interests are added?

some more notes to hopefully make the task description more actionable, and open questions in bold:

before updating the task description, i wanted to share a few thoughts in a comment to understand if this is enough to make things actionable, and listing open questions in bold.

@Samwalton9-WMF FYI i've just realized that i posted my comment on the wrong task, sorry! this task is about bringing the 'interests' selector inside the 'suggested edits' module so that people can access their interests from their Newcomer Homepage too, and not only during account setup.

closing summary

thanks @JScherer-WMF. looks good on my end, only two minor notes:

In T430697#12127650, @EMcFarland-WMF wrote:

@EMcFarland-WMF - a super minor issue: when the warning about invalid password is displayed, the eye icon is still visible (and functioning). Do you think it's worth to address it? I did not find any other instances of that issue, i.e. "Confirm password" field seems ok.

Thank you for pointing out this minor issue. I will defer to design on whether we should address this. @AAlhazwani-WMF what do you think?

On blur - password field

• AC1: Given the user leaves the password field, when the password meets all requirements, then clear any existing password warning.
  

@AnneT JFYI we also had a convo on slack where we discussed whether the bottom sheet should span across viewports.

after an internal consulation, this is where we landed:

• text "Avoid using your real name."
• add a codex icon-only small quiet button next to the codex field description
• set the icon of the button to cdxHelpNoticeFilled
• on tap the button opens a codex popover

@JFernandez-WMF my 2 cents is that "event discovery" is internal lingo more than something memorable that people can connect between

resolving this out. these explorations built on the directions opened in T420862 and moved several of them from "possible" to "concrete enough to test". what is presented below is exploratory: these design directions need to be validated via usability testing and community consultation, before anything converges.

looks great. thanks @Etonkovidova for the ping!

ok @Sgs here how to address the problems mentioned above.

yesterday (june 9, 2026) @Lwilson-ctr and i presented a first round of ideas (internal google doc) during the growth team discussion meeting. we started to collect feedback, and act on those suggestions.

In T419395#12000323, @Etonkovidova wrote:

The red links are fixed.

@Michael - cdx-popover__header__title (<div class="cdx-popover__header__title">Username policy</div>) seems still having the same font-size as the text.

enwiki beta	Figma design

In T424205#11989484, @Sgs wrote:

[...]

• For wikis without temporary account auto-creation (mostly third party) we should keep at least the Your edit was published toast. The cheapest/easiest is to keep it as it is accepting some inconsistency in the UIs in one case or the other. Codex popover for temp users vs MW toast for IP-logged users. With a bit more of work we could make it consistent for both to work with the Codex popover which is probably better for long-term maintenance. cc @AAlhazwani-WMF

In T423741#11985390, @bmartinezcalvo wrote:

El T423741#11983301, @JFernandez-WMF escribió:

designs added, moving to ready for dev cc @ifried :)

Just review the updated designs and commenting some feedback about the button's copy. As recommended in the Codex content guidelines, we should avoid language that implies visual skills to make the content accessible for everyone. So I recommend rephrasing the See event page button to View event page or Navigate to event page.

here's my proposal cc @KStoller-WMF

looks good to me - thank you both!

@DMburugu FYI ux copy is still in flux - related slack thread

forgot to move the task out of design review, sorry!

@Lwilson-ctr and i drafted a early exploration doc and we started publicize the document internally to collect feedback.

just wrapped the usability test (full report) - the one with the pre-filled username variant, where we auto-generate a username and drop it directly into the field on page load.

a few others external and semi-external entry points to account creation:

• donor flow
  
  
• event flow
  

In T426194#11917374, @AnneT wrote:

@AAlhazwani-WMF per the acceptance criteria, I'd like to show the ReadingLists onboarding popover when the user is actually reading an article. If they're doing a suggested edit, I'm assuming the workflow would be:

1. User goes to Homepage, clicks on a suggested edit (may be a revise tone task)
2. User goes to the article's edit page and does not see the ReadingLists popover
3. User finishes and saves the edit
4. User goes to the article and sees the ReadingLists popover

Would step 4 be problematic for any reason? I know for normal edits the user sees a notification noting that the edit was saved, but I'm wondering if there are any special notifications after saving a suggested edit that could interfere with the ReadingLists popover.

i've met with @Michael and we've decided to simplify color management for the endIcon prop. we'll always use cdxIconEye as the icon, passed directly to the CSS-only CdxTextInput nested inside CdxField. for color, we're going to let the component's built-in opacity/fill definitions handle it rather than overriding anything ourselves.

ok - i tested this on beta and the "taken username" does display as a warning

@Sgs i tested things on a real device - a iphone 13 mini running ios/safari 24.6.2 and this is what i've found

In T419401#11908185, @Etonkovidova wrote:

Checked on enwiki beta - all ACs are in place.

Checking availability	Username available	Username not available	Username not available - red warning
{F80902162}

Special cases:

• not a valid user name
  • empty username field

• not valid format

In T419413#11879648, @Awesome_Aasim wrote:

I really like this idea, and hope it gets implemented and expanded to desktop, but I do have a general question about this. Some mobile browsers add their own version of this button (even without this change, i.e. Microsoft Edge on Android), how can we make sure that we hide the version provided by the mobile web browser? I have seen some poorly designed websites not hide the one injected by the browser which can lead to some weird design quirks regarding the password field.

we've now launched a new study to test this variant - which prefills a generated username on page load and displayes the reload button (to generate another username) as a endIcon prop

we've explored a few options in the past weeks!

while testing this patch (https://auth.wikimedia.beta.wmcloud.org/enwiki/w/index.php?title=Special:CreateAccount&mpo=we-1-8-account-creation-form-v2%3Atreatment&mobileaction=toggle_view_mobile) from @Michael i've noticed 2 things:

some other feedback, per AC1 and AC2 we should use the cdxIconEye for both reveal and hide. what changes is the fill color:

In T419413#11869268, @KStoller-WMF wrote:

AC7 - Password helper text removed

I think this acceptance criteria was missed? But otherwise I tested and other acceptance criteria is met.