In T415659#11590777, @Sgs wrote:

9. Remove the "Wikipedia is made by people like you." section with statistics below the main button

There's at least one Growth feature that depends on the existence of the so-called benefits block, see Extension:GrowthExperiments/Technical_documentation#Campaigns. What should we do about this? cc @KStoller-WMF @Michael

we don't have (yet!) a mobile varian for the codex popover - see T386144 and slack convo - but it could work well here!

building off a past convo on "designing for curios people" i'd like to suggest another small change @KStoller-WMF. instead of adding a "learn more" link at the end for the username field description we could directly link the word "public".

curious about the rational here.. why not simply say that is not available?

@Michael found another one!

after chatting with the editing team (peter and nico) we've confirmed that we'd like to open links within the quiz-style onboarding in a new tab instead of in the same tab.

@Sgs two small details:

• from your screenshots i can see that they styling is all codex (which is great!) but i've noticed that the button are missing the 2px rounded corners / border-radius-base, is that an easy fix?
• would it be possible to align the content of the page to the center?

In T415160#11570046, @Sgs wrote:

In T415160#11569203, @AAlhazwani-WMF wrote:

@KStoller-WMF is this what you're suggesting? @Sgs do we have control over the bolden words like "Warning" "log in" "create an account"? i support keeping things simple - i'm only afraid that the current combination is subpar.

Not sure what you mean by control here. I'm assuming the subpar is the highlighted text with bold font. I opted for overriding the styles with CSS and re-use the same message for both groups in the spirit of keeping things simple and not adding additional messages that would require translation but are identical to existing ones. I we finally rollout the treatment group status quo, we should update the message and strip the bold markup from there after the experiment ends.

(5) Tags Newcomer task Suggested: revise tone are added for non-Revise Tone edits
Ex. https://test.wikipedia.org/w/index.php?title=Lorem_ipsum&diff=704421&oldid=643573

mostly as food for thoughts, when the growth team tested surfacing add-a-link to readers - a much simpler task compared to adding an infobox - we did observe statistically significant difference in constructive activation between treatment and control

In T415899#11568479, @KStoller-WMF wrote:

Curious if @AAlhazwani-WMF has thoughts on fixing vs. removing this logic?

My sense is that they should either be removed if we don't think they are actually helpful or necessary, or we should reconsider the styling. Do they really need to be ⚠ warnings?

@KStoller-WMF is this what you're suggesting? @Sgs do we have control over the bolden words like "Warning" "log in" "create an account"? i support keeping things simple - i'm only afraid that the current combination is subpar.

@Sgs after chatting with kirsten, and nico/peter from the editing team, we decided to remove the "Learn more"[1] link, and include that as part of the message itself.

In T400550#11561976, @Cyndymediawiksim wrote:

@AAlhazwani-WMF , just a quick clarification: for declined suggestions, what’s the intended behavior on both mobile and desktop? Should it display a success toast message, or a notice toast message? cc: @Michael

another lightweight idea that we've exploring is a general clean up of the form following the latest codex recommendations[1]. mostly moving things around, and removing redundant ones - more specifically we're suggesting to:

sharing some updates, and first design explorations that we could experiment with...

just checked https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/1230279, and realized we're actually updating growthexperiments-help-panel-postedit-success-message-notsaved to also be aligned with the other messages. ignore my message above @Cyndymediawiksim, thank you!

In T400550#11549851, @Etonkovidova wrote:

In T400550#11544372, @Cyndymediawiksim wrote:

@Etonkovidova, I’m not sure if it’s just me, but the attached images aren’t displaying on my end. I also tested this on enwiki beta, and the desktop message still says “**//Thanks for reviewing suggestions.

Is something like that you're looking for? All Homepage messages:
https://gerrit.wikimedia.org/g/mediawiki/extensions/GrowthExperiments/+/97c049b5d168a3129b06ce1c6c2b6c39f8cf1819/i18n/homepage/en.json#282

The message
"growthexperiments-help-panel-postedit-success-message-notsaved": "Thanks for reviewing suggestions. Keep going!"
is here: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/GrowthExperiments/+/97c049b5d168a3129b06ce1c6c2b6c39f8cf1819/i18n/help/en.json

In T400550#11544372, @Cyndymediawiksim wrote:

@Etonkovidova, I’m not sure if it’s just me, but the attached images aren’t displaying on my end. I also tested this on enwiki beta, and the desktop message still says “Thanks for reviewing suggestions. Keep going!” which doesn’t match the A/C for the task: “You’ve reviewed a suggestion. Thanks and keep going!” On mobile, the message is “You’ve published an edit. Thanks and keep going.” I think both views need updates?

In T413368#11506981, @Sgs wrote:

In T413368#11506315, @Cyndymediawiksim wrote:

This patch only addresses the checkbox removal, not the help panel integration.

I think the description of this task is missing some relevant information about the acceptance criteria, which is mentioned in a subtle way in the quoted sentence If we made it less likely to show up every time. Maybe an acceptance criteria bullet list can be clarifying, eg:

• Remove the checkbox
• Only show the revise tone quiz the first time a user starts, (finishes?) a Revise tone task. cc @AAlhazwani-WMF can you confirm this or elaborate your proposal.

In T413368#11502760, @Sgs wrote:

Regarding the adding the quiz in the help panel, there's a substantial amount of work because: (1) The existing quiz is not re-usable straight forward because it is implemented with Vue and the help panel is OOUI. (2) The help panel content presented in structured tasks is prepared to work with the concept of a quick tip, which is what is presented on each of the slides. Supporting presenting a quiz there will need some re-work on the help panel content handling, be it ad-hoc or extending what already exists.

a-ha, thanks @DLynch! i didn't refresh the page hence didn't see your answer!

In T411880#11476335, @Sgs wrote:

In T411880#11464331, @AAlhazwani-WMF wrote:

Will the popup pre-save be shown before or after the pre-save edit checks?

after chatting with @nayoub and @bmartinezcalvo we suggest to display the pre-save dialog at the very last stage, so after pre-save edit checks. the goal is to have a stronger separation of concerns between the editing activity (and addressing editing-related checks) and publishing (either with a temp account or via a permanent account).

Could someone clarify or give examples of what checks are we talking about here.

Will the popup pre-save be shown before or after the pre-save edit checks?

we've finalized the comp review, and put the findings together in a slide deck (internal google slides).

In T396155#11456353, @Jonesey95 wrote:

"Your Wikipedia account is almost complete" seems like it is missing a word or two. One does not "complete" a Wikipedia account. How about "Creation of your Wikipedia account is almost complete"?

we've looked at the top 20 services across web[1], ios[2], and android[3] to build off jakob's law[4], and we've started to compile a comp review[5]. the figma file takes a while to load, be patient :)

In T411526#11442110, @Etonkovidova wrote:

• The logo (gmail desktop) looks rather small.
• non-gmail email shows "Confirm your email" as a link

@KStoller-WMF feel free to revert changes if this is not the case.

last week, we've tested 3 variants of the logged-out warning message with 15 participants (5 per variant). the unmoderated test observed participants’ reactions to different timings and visual treatments of the authentication prompt when logged-out users attempt to edit (full report)

In T411559#11431566, @Mathglot wrote:

In T411559#11427873, @Urbanecm_WMF wrote:

. . . From my perspective, I understand how the labels can be misleading, especially in edge cases.

Internally, we have a mentor pool, which contains usernames of registered mentors. By default (when on the "Average" setting), everyone is in the pool twice. If someone changes their settings to "twice the average", their username will be in the pool four times. In case they set themselves to "half the average", their username will be in the pool only once. Whenever a new account registers, a random username is taken from the pool, which is the mentor we're assigning to that user. The number of times a mentor's username is in the pool is called the mentor's weight.

So what I understand now, is that you are assuring mentor load only proportionally relative to other mentors, and not absolutely based on any number of mentees. Am I correct in concluding that in this scheme there is no upper bound on possible mentor load: they might get 10 mentees, or 100, or 10,000 mentees. Without knowing the details of the number of mentors and the total number of mentees in the future, it would be impossible for a prospective mentor upon signing up to estimate load or to set a threshold on the number of mentees they might be assigned.

we've reviewed the first round of changes and confirmed that they've been addressed. we've followed up internally on few other issues that will be addressed separately from this task/patch.

In T407359#11409474, @DMburugu wrote:

Assuming we instrument the locations of the origin of edits as "lead_section" or "non_lead_section", and find that "lead_section" edits are higher over X months, would the next step be to find a way to bring more focus to the other sections by making newcomers aware of the fact that they can edit at a section level?

w've addressed this by coding an alternative prototype instead of relying on patchdemo.

In T409937#11388987, @EMcFarland-WMF wrote:

Hi @AAlhazwani-WMF, I made the requested change and it was straightforward. Here are screenshots of the change on desktop, in the mobile view, and zoomed in. After this I'll upload my changes to Gerrit. Thanks, let me know if anything looks off.

Desktop	Mobile	Zoomed In View

In T409937#11387500, @Sgs wrote:

Reviewing the Figma spec, we've noticed that the border radius is not rounded for the rest of modules in the Mentor Dashboard. Is it intentional? From an engineering pov we would prefer a consistent solution where all of the borders have the same aspect. cc @AAlhazwani-WMF

i've also created the eng task T410386: Prompt user to create a regular account after temp account creation rate limit trip

Should we disclose additional information inside as an accordion or styled as caption and visible at all times?

Should we should the modal once or twice?

posted update on https://phabricator.wikimedia.org/T357802#11383116

while working on T408011: Design Research: Prompt user to create a regular account after temp account creation rate limit trip we landed on this design and copy proposal..

some more food for thoughts from the en community https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(idea_lab)/Archive_66#c-Mikeycdiamond-20250520195500-An_official_achievement_system

after reading https://www.intechopen.com/online-first/1221745 we started a thought experiment/brainstorming with @TAndic where we tried to map those different progression systems (skill-based, item-based, narrative, etc) to the current ux on the wikis (internal miro board)

In T407362#11374144, @Sgs wrote:

In T407362#11358478, @AAlhazwani-WMF wrote:

Is this screenshot from Figma or one of our sites?

In T407362#11358478, @AAlhazwani-WMF wrote:

In T407362#11358326, @Sgs wrote:

In T407362#11358224, @AAlhazwani-WMF wrote:

+1! @Sgs would it be possible to display the button and the checkbox only on step 1?

We can, but it is the opposite design decision DST made in T332767 when proposing the Multi-step dialog pattern and turning it into a Codex example https://doc.wikimedia.org/codex/main/components/demos/dialog.html#multi-step-dialog

understood! lemme double check with them.. especially how they'd like to address this situation

In T408011#11368444, @EMill-WMF wrote:

For the message, I would remove the "Why do I need an account?" subheader and expander/collapser, and say something in active voice. (Also, we don't like to say "anonymous editing", as registering a user account, is, if anything, more privacy-protective.)

What do you think about something smaller like:

To prevent spam, we limit editing without an account.
Creating a free account is quick, and lets you edit any time.

In T407362#11358224, @AAlhazwani-WMF wrote:

i've also started to optimize spacing and layout, while testing things on beta.. here's a summary of the changes that i did with the stylus browser extension [1]

.ext-growthExperiments-OnboardingDialog__header__top_row {
    height: auto;
    padding: 1rem .75rem 0 1.5rem;
}

.ext-growthExperiments-OnboardingDialog__header__title {
    padding: 1rem 1.5rem .75rem;
}

.ext-growthExperiments-QuizGame__introduction {
    padding: .75rem 2.75rem;
}

.ext-growthExperiments-QuizGame__pills {
    align-items: flex-start;
    padding: .75rem 1.5rem;
}

.ext-growthExperiments-ReviseTone-QuizPill {
    margin: 0;
    width: 100%; /* @size-full */
}

.ext-growthExperiments-ReviseTone-QuizPill-Pill {
    width: auto;
    min-width: auto;
}

.ext-growthExperiments-OnboardingDialog.cdx-dialog .cdx-dialog__footer {
    padding: 1rem 1.5rem;
}

.ext-growthExperiments-OnboardingDialog__footer__navigation {
    margin-bottom: 0;   
}

.cdx-checkbox:not(.cdx-checkbox--inline) {
    margin-bottom: 0;
}

.ext-growthExperiments-ReviseTone-QuizPill-Description {
    width: auto;
    padding-left: 0;
    margin-bottom: 0;
    line-height: 1.25rem; /* @line-height-x-small */
}

.ext-growthExperiments-ReviseTone-QuizPill-Pill--success {
    color: #177860; /* @color-success */
    border-color: #099979; /* @border-color-success */
}

.ext-growthExperiments-ReviseTone-QuizPill-Pill--error {
    color: #bf3c2c; /* @color-error */
    border-color: #f54739; /* @border-color-error */
}

In T407362#11358326, @Sgs wrote:

In T407362#11358224, @AAlhazwani-WMF wrote:

+1! @Sgs would it be possible to display the button and the checkbox only on step 1?

We can, but it is the opposite design decision DST made in T332767 when proposing the Multi-step dialog pattern and turning it into a Codex example https://doc.wikimedia.org/codex/main/components/demos/dialog.html#multi-step-dialog

In T407362#11347212, @KStoller-WMF wrote:

I tested in patch demo. (Note that you will need to login, enable Growth features, and then visit your Homepage to view a Revise Tone suggestion).
And a minor difference from designs: the "I already know this" and "Don't show again" options are available from every onboarding screen, rather than just from the first.

I don't see that as a release blocker, but maybe that's a follow-up task we should log if @AAlhazwani-WMF thinks we should adjust this to match other Structured Task onboarding?

@kostajh we started to explore a few early ideas, and would love your feedback.. feel free to ping/add other folks to this task as needed, thank you!

thanks @EMcFarland-WMF! i might have missed something here.. what's stopping us from positioning the info button as desired? basically position the button 8px from the top edge of the module, and 8px from the right edge of the module

In T397966#10958022, @bmartinezcalvo wrote:

• Op.2: Use a call to action in the title to push users to complete the action
  • Revise tone
  • Add a citation
  • Revise pasted content

we've created an internal miro board, and prompted a few stakeholders across P+T to share async feedback ideally by this wed, nov 5 end of their day..

In T293454#11331998, @EMcFarland-WMF wrote:

When I added the top margin of 12px for “Your mentees,” plus the 8px top margin for the i button, it looks a bit different than the design. The i button is quite a bit lower than the heading text. Am I missing something?

@kostajh we listed in this google doc a series of recommendations/requirements to kick off the design exploration.. let us know what you think, and leave comments if there is anything else that should be considered as we start exploring designs and copy of this (temp account rate limit) message.. and please feel free share this doc with anyone who might have valuable feedback/input. thank you!

we've started a design review (internal google doc) of the current ux, and identified a few recommendations. we shared this with the growth team, and after this internal review we will share this with other stakeholders too.

un-assigning because i'm working on the smaller task first T408011: Design Research: Prompt user to create a regular account after temp account creation rate limit trip

eng task created T408544: Display unstructured Suggested Edits onboarding on first use only

we' started to explore a few ideas (internal figma file), and initiated a group conversation around the main benefits connected to account creation (internal slack thread)

we've not completed the study, and drafted a first report (internal google doc)

In T284927#11303427, @matmarex wrote:

I didn't want to add a dialog (or anything you have to click through), because Special:CreateAccount is also used by people who actually want to create another account, e.g. https://en.wikipedia.org/wiki/Wikipedia:Account_creator. I'm aiming for something that would be reasonable for both groups, even if it isn't ideal for either. Like @Tgr says, maybe the problem is that we have too many workflows that all happen through the same login/signup forms, and maybe we could split off things like Special:CreateAnotherAccount, Special:SwitchAccounts and so on – but that feels like a quarter-long project to me.

we've got the results (4 out of 5), and we've started to watch recordings and synthesizing findings... for 1 participant the test didn't work properly and we've requested a new participant

we completed the pilot study, refined the protocol with input from product and design research, and launched an unmoderated study with 5 participants.

thanks @Tgr! the table is super helpful, thank you for doing that. thou now i'm confused. is this task trying to find a solution for all of these workflows or only for: