In T225288#5254200, @JTannerWMF wrote:
@Cntlsn will interlock with @Volker_E . @Catrope and @MMiller_WMF will strategize how to ensure modals align technically, which may include needing to meet with VE and/or Readers Web.

In T225288#5254213, @JTannerWMF wrote:
It was recommended by @SBisson revisiting work on the Help Panel on desktop in interest of standardization during the Growth team Grooming session.

After talking about this in retro today, we've decided to continue to use the current standardized component, but to modify it to reflect the desired design in spirit as best we can.

Next step is for @kostajh, @Catrope, @SBisson to propose what changes they can make using the standardized component and which they can't. Then we'll come to agreement and this will be ready for development.

@MMiller_WMF @SBisson I've broadened up the conversation upstream in the task above, as I think we're not doing the users' a favor continuing with the current design on desktop and should adopt the good parts of mobile.

Also on a side note: I'd consider changing CTA label from “Post my question” to “Post question”

Change 519575 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/GrowthExperiments@master] Use frameless buttons for ProcessDialogs

https://gerrit.wikimedia.org/r/519575

The patch above, along with the changes Volker made to OOUI as part of T226045, address the requests in this task to some extent. Below is a before and after of the help panel (asking a question from the editor or a page view) and the question dialog (asking a question through the help desk or mentor buttons on the homepage) on desktop and mobile.

@Cntlsn please let me know what you think, and what other changes you'd like to see.

The main differences are:

• Dialog actions (the buttons in the top bar) were framed, are now frameless
• "Close" actions is represented with an X instead of a label (both desktop and mobile)
• "Back" actions are represented with a < on mobile, but with a label on desktop
• Dialog titles are left-aligned on mobile (they were centered), but still centered on desktop
• Note that the buttons at the bottom of the help panel (except for the Done button at the end) are still framed, because they're not dialog actions. We can easily make these frameless too, if desired.

Question dialog (desktop)

Before	After

Question dialog (mobile)

Before	After

Help panel (desktop)

Before	After

Help panel (mobile)

Before	After

(Mobile screenshots made using Chrome's emulator, set to iPhone 5/SE.)

To get ahead of one potential question: fully left-aligning the title of the question dialog in the completed state is hard. OOUI doesn't want to do that, because it expects you to have an action in the "safe action" space on the left, and reserves space for it. Some of our options are listed below. My patch proposes the second one (safe, close).

Flags	Desktop	Mobile
safe
safe, close
safe, progressive
primary
primary, close
primary, progressive

What these flags mean, in my understanding (some but not all of these flags are also documented here):

• safe: Displayed on the left. Intended for actions that abandon what you were about to do and do nothing instead.
• close: Label is ignored, X icon displayed instead. Intended for actions that close the dialog.
• back (not shown here, appears in the question dialog): Label is displayed on desktop, but replaced with a left caret on mobile. Intended for actions that navigate back to the previous pane.
• primary: Displayed on the right. Intended for the main action we want you to take.
• progressive: Displayed in blue. Intended for actions that proceed forwards in a flow.

Thanks @Catrope for highlighting the new changes with all the details.
They look ok to me.

I would only make two changes:

• Question dialog
  • The success screen on both desktop and mobile should feature a primary action, not a safe, close action
    
    • That is because, as per documentation in your last comment, "Done" is the action we want the user to take to complete the question asking process, by closing the modal. We don't want the user to "abandon" the question asking process as the safe treatment would suggest instead. The latter scenario could create confusion, would the safe, close action make me abandon the question asking process and revert my successfully posted question?
• Help panel
  • The success screen on both desktop and mobile should only feature a primary action in the footer
    • Featuring both a safe, close action in the top bar and a primary action in the footer will result in redundancy and misleading UX. Which one will you click? Do they trigger the same action? If yes, why are they displayed differently? If they do trigger different actions, how are they different then?
    • "Done" is the action we want the user to take to complete the question asking process, by closing the modal. We don't want the user to "abandon" the question asking process as the safe treatment would suggest instead. The latter scenario could create confusion, would the safe, close action make me abandon the question asking process and revert my successfully posted question?

I see other issues in the top bar that I will address in T226045 directly.

Patch updated to make the changes requested above.

In the help panel, I had to hide the cog icon when moving to the success screen, because it's in the same place where the "Done" action should go, and that caused the top bar layout to get all messed up.

New appearance of the success screens:

	Desktop	Mobile
Help panel
Question poster dialog

@Catrope looks good, thanks!

Short comment on the desktop “after” screenshots in T225669#5291139: They should feature an “x” icon instead of a “Cancel” label now with OOUI v0.33.1 out, similar helping T227602 sizing issue.

Reviewing here since gerrit doesn't do screenshots. My screenshots don't match what you've posted (and I'm on latest HEAD of core, with composer update run, along with latest HEAD of Vector, MinervaNeue, and MobileFrontend.)

1. [Desktop/Mobile] Homepage mentor and help modules, done should not have frame

2. [Desktop] Help panel settings cog

Dropdown should shift a pixel or two to the right. (Not a regression with this patch so we can ignore it now if you want.)

3. [Desktop] Help panel border around X

4. [Desktop] Help panel done should not have frame

5. [Mobile] Help panel X has frame

6. [Mobile] Help panel Done has frame

Ugh, it looks like there were more OOUI changes in the two weeks between me submitting this patch for review and getting it reviewed. I probably have to explicitly pass framed: false now? Unless these frames are intentional?

In T225669#5322050, @Catrope wrote:

Ugh, it looks like there were more OOUI changes in the two weeks between me submitting this patch for review and getting it reviewed. I probably have to explicitly pass framed: false now? Unless these frames are intentional?

Yes, and yes.

Since it appears that it's intentional that these close/done buttons are framed, I would suggest that we err on the side of not overriding standardized behavior here. In other words, let's keep the patch as is and keep the frame.

@Cntlsn @kostajh: Thoughts?

@Catrope Honestly I'm feeling a bit lost here. The framed buttons posted by @kostajh look wrong, and some have positioning issues.

@Volker_E what is the state of the art of modals buttons, and how should we proceed here?

@Cntlsn The positioning issues are wrong from my POV too (when looking at the provided screenshots). They seem originated in custom overrides.
You can have a look of the master state out of box at ProcessDialog in demos.

What is a semi-regression are usages of non-primary ButtonWidgets in primary actions as seen in 1. at T225669#5320868 above.
The borders are not taken into account appropriately. Filed as T227761.

@Volker_E thanks for your input!
The reason why a non-primary ButtonWidget was chosen in the screenshot above, is that the button is not necessarily a primary action, even though I understand that it's placed in a primary action position.

By looking at the mockups below you could see how the user goes through submitting a question (where the primary action is clearly highlighted), to a success screen, where multiple actions are proposed, and closing the modal (through the "Done" button) is not necessarily the preferred action we want the user to take. The "Done" button is placed in a primary action position because it makes sense it terms of progression (that's were you would expect to find a button to complete the process).

Thoughts about it? Do you think it would be preferable to be consistent anyway, or it's a plausible exception?

Change 525164 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/GrowthExperiments@master] Help panel: Fix cog popup alignment

https://gerrit.wikimedia.org/r/525164

Sorry for the late response on this task.

In T225669#5324751, @Volker_E wrote:

@Cntlsn The positioning issues are wrong from my POV too (when looking at the provided screenshots). They seem originated in custom overrides.
You can have a look of the master state out of box at ProcessDialog in demos.

What is a semi-regression are usages of non-primary ButtonWidgets in primary actions as seen in 1. at T225669#5320868 above.
The borders are not taken into account appropriately. Filed as T227761.

• #1 is a semi-regression as Volker said; the bug is in OOUI, but OOUI did not foresee people trying to use non-primary actions there
• #2 is a custom UI element in the help panel, which the attached patch fixes
• #3 is expected behavior, OOUI ProcessDialogs turn grey and have a border on hover; you can see this in the OOUI demo Volker linked too
• #4 is the same issue as #1
• #5 I cannot reproduce in master (anymore?)
• #6 is the same issue as #1

Thanks @Catrope.
@Volker_E what do you think would be the best way to proceed with #1? In my previous comment T225669#5325228 I motivated the choice for not featuring a primary ButtonWidget in the last screen of the question asking process. I think it is a scenario that would possibly be encountered in other instances, hence it would be good for OOUI to support it, what do you think?

Change 525164 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Help panel: Fix cog popup alignment

https://gerrit.wikimedia.org/r/525164

@Cntlsn #1 needs to be and will be tackled upstream. Will put @kostajh and @Catrope as co-reviewers on upcoming task and tag it with this task.

Change 525522 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[oojs/ui@master] WikimediaUI theme: Ensure styling of non-primary ActionWidgets

https://gerrit.wikimedia.org/r/525522

@Cntlsn - for your review. I copied the task description screenshot and added the third column for the most current state on beta. Some decision should be made whether the task specs should be done or changed, or some issues that are still present should be filed as separate task(s)?

(The specs are quoted in bold).

(1) The ask a question modals should feature the an "X" icon to be dismissed, instead of the current "Cancel" button

• 'Cancel' button is still there
• on the 'Cancel' button there is a gap at the buttom

Current	Desired	Current (betalabs)

(2) The buttons in the header of the ask a question modal don't support the mobile styling
Except for the same issues as above

• the label should read 'Post question' ? it was mentioned somewhere in the omments

Current (old)	Desired	Current (betalabs)

(3) The button to complete the ask a modal flow and go back to the module is placed on the wrong side of the header

• the button 'Done' is still on the left side

Current	Desired	Current (betalabs)

(4) The title of the ask a question modals (eg. "Ask your mentor") needs to be left aligned"

• 'Ask your mentor' is more left aligned than before, but is it enough?

Current	Desired	Current (betalabs)

In T225669#5320868, @kostajh wrote:

5. [Mobile] Help panel X has frame

In T225669#5359394, @Catrope wrote:

• #5 I cannot reproduce in master (anymore?)

Yes, the issue is not present anymore (and consequently resolve T227545).

Change 525522 merged by jenkins-bot:
[oojs/ui@master] WikimediaUI theme: Ensure styling of non-primary ActionWidgets

https://gerrit.wikimedia.org/r/525522

Note that until a new OOUI release happens that includes T225669, issues 1, 4 and 6 in T225669#5359394 will still be present.

Change 519575 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Use frameless buttons for ProcessDialogs

https://gerrit.wikimedia.org/r/519575

@Cntlsn Added the screenshots after the above patch was merged:

Thanks @Etonkovidova.
As said by @kostajh in a previous comment, some of those issues will be fixed by a newer OOUI release.

About number 2, I think we should change the copy to "Post question". Here is my rationale:

• it is a more direct action
• in the scenario of a translation being truncated (or a narrower button), it would convey a more comprehensible message

It's not a big change, but happy for @MMiller_WMF to review it + sorry @kostajh, this should really be the last change on this task!

We quickly reviewed this task during grooming and proposed to change the copy to "Post" to be as translation friendly as possible.

So next, and hopefully final, issue would be to just change the copy to "Post".

Change 530557 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Change wording to "Post question"

https://gerrit.wikimedia.org/r/530557

Change 530557 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Help Panel: Change submit wording to "Post"

https://gerrit.wikimedia.org/r/530557

Checked in betalabs - the 'Post' label is present on both 'Ask mentor' and 'Ask the help desk':

Compare with testwiki:

Change 534517 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/core@master] Update OOUI to v0.34.0

https://gerrit.wikimedia.org/r/534517

Change 534517 merged by jenkins-bot:
[mediawiki/core@master] Update OOUI to v0.34.0

https://gerrit.wikimedia.org/r/534517

There may have been a bug introduced related to this update to the Done button:

Issues:

• The background color Base90 is not extending all the way to the RHS edge of the screen
• There should not be an inset bottom border on the button

The background color issue is also present in the Desktop version of the help panel and relevant mentor asking dialog:

Moving back to Q2 because this is not necessary for Newcomer Tasks v1.0.