Page MenuHomePhabricator

Improve process dialog appearance – simplify actions
Closed, ResolvedPublic

Assigned To
Authored By
Volker_E
Jun 18 2019, 7:14 PM
Referenced Files
F29673388: image.png
Jul 1 2019, 12:59 PM
F29662193: Screenshot 2019-06-28 14.59.11.png
Jun 28 2019, 1:00 PM
F29660113: Screenshot from 2019-06-27 16-32-30.png
Jun 28 2019, 1:00 PM
F29640353: image.png
Jun 25 2019, 2:19 PM
F29640345: applybutton@2x.png
Jun 25 2019, 2:11 PM
F29637939: image.png
Jun 25 2019, 1:16 AM
F29635641: image.png
Jun 24 2019, 10:09 PM
F29605331: image.png
Jun 19 2019, 4:22 PM
Tokens
"Like" token, awarded by Trizek-WMF."Like" token, awarded by iamjessklein."Like" token, awarded by cmadeo.

Description

The top actions in dialogs are very verbose and in the case of the “Cancel” action it seems out of proportion in contrast to its function.
The title dialog receives less visual importance while the user's interest is more on the primary action and/or the dialog title.

CurrentProposed
image.png (788×1 px, 81 KB)
image.png (788×1 px, 79 KB)
TemplateDialog VE

Current mobile appearance (as of v0.32.1):

image.png (352×1 px, 24 KB)

Proposals

  • Converge mobile and desktop appearance…
    • “Cancel” default action in process dialog to change using 'close' (“x”) icon instead
    • Primary buttons should have same primary button appearance everywhere (Accent50 background, Base100 text color)
    • Evaluate increasing font-size of title slightly
    • Make buttons full height similar to a toolbar appearance
    • Bottom (other) action buttons should receive button interaction treatment, hover, active etc.
  • Mobile: Left align title

Proposed ProcessDialog (medium) from demos:

image.png (334×1 px, 23 KB)

Improvements by proposal

  • “x” is one of the most common window GUI elements and also used in other contexts. There's no reason to be overly verbose for such simple, secondary action. This would also increase focus on other, primary action and help with the reading direction sequence to improve user guidance
  • Making the primary action full height would improve consistency between toolbars and dialog title bars, which latter were derived from former

Related tasks

…where the current behavior is challenged (or should be challenged)

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Volker_E renamed this task from Evaluate process dialog appearance and simplify top bar to Evaluate process dialog appearance – simplify actions.Jun 19 2019, 3:08 AM

Change 517788 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[oojs/ui@master] ProcessDialog: Use frameless actions and icons on desktop

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

Volker_E moved this task from Backlog to Next-up on the OOUI board.

@Volker_E:

  • I like the update for the close button.
  • Regarding the primary button — I like the way it currently is on desktop. The full-height button feels more like a mobile pattern to me, though I don't have a specific rationale in mind.
  • Regarding the modal title — perhaps on mobile we could left-align the modal title, since there is less space and it can often look awkward to have a centered title, particularly if the text of the primary button is longer. But leave it centered on desktop?

image.png (1×2 px, 62 KB)

@alexhollender

  • Primary button: I'd recommend settling on mobile for now (with correct primary blue treatment), we can revisit later. Reason is, we've got a consistency with toolbar treatment which is very similar in default appearance, also the close button could remain frameless.
  • Left alignment of title is fine for me, will update in a follow-up patch.

There has also been a few inconsistencies uncovered in the current dialog's button treatments in WikimediaUI & Apex theme:

  • WikimediaUI: Primary button doesn't receive primary treatment
  • WikimediaUI: Buttons in the bottom action bar don't receive hover treatment
  • WikimediaUI: Unnecessary CSS code duplication of bold treatment, which is button default anyways
  • Apex: Close icon is vertically misaligned.

Change 518856 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[oojs/ui@master] WikimediaUI theme: Converge appearance of mobile & desktop ProcessDialog

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

@Esanders and I were just discussing T225725 where we have a label input dialog. I mocked this up for the narrow screen size (320px). We realized that when the title bar has buttons multiple actions and a title, it becomes unnecessarily complex. To account for this, we have been exploring the principle that when we have a dialog title, we should be doing icon-only actions. This is what it will look like for us:

applybutton@2x.png (1×1 px, 87 KB)

To add to what Jess has said, I think it is a good principle to avoid having more that one labelled element per line. Phone screens can be very narrow (e.g. iPhone 5), and messages can be very long (e.g. German).

If we were going to with this approach we would need to ensure that the "done" action label was always short, which is not currently the case. Current examples in VE: "Apply changes", "Use this image", which in German are "Änderungen speichern" & "Dieses Bild weiterverwenden".

Enforcing this across all of our work is going to be very difficult. Developers will often test on desktop only, or in English only, so using an icon only approach will make it harder for this sorts of issues to arise:

image.png (80×378 px, 6 KB)

If we feel that removing labels for the sake of some long-label-narrow-screen edge cases is not worth it, we could also consider a responsive approach (toggling between icon/label) but we haven't implemented such a layout in OOUI yet so it would be a first.

Enforcing this across all of our work is going to be very difficult. Developers will often test on desktop only, or in English only, so using an icon only approach will make it harder for this sorts of issues to arise:

That sounds like a mandatory checklist item for product managers/designers/developers in our environment.

Enforcing this across all of our work is going to be very difficult. Developers will often test on desktop only, or in English only, so using an icon only approach will make it harder for this sorts of issues to arise:

That sounds like a mandatory checklist item for product managers/designers/developers in our environment.

To test every community-contributed translation? My point is not what should be done in an ideal world, but what is actually done in practice, and realistically will be done in future.

I agree with using frameless close/back icons, but I'm not sure how I feel about the other proposed changes. Especially the secondary actions at the bottom look weird with the proposed styling.

Volker_E renamed this task from Evaluate process dialog appearance – simplify actions to improve process dialog appearance – simplify actions.Jun 26 2019, 11:39 PM

Change 519317 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[oojs/ui@master] themes: Align ProcessDialog title to left on mobile and increase size

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

Change 517788 merged by jenkins-bot:
[oojs/ui@master] ProcessDialog: Use frameless actions and icons on desktop

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

Change 518856 merged by jenkins-bot:
[oojs/ui@master] WikimediaUI theme: Converge appearance of mobile & desktop ProcessDialog

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

Change 519317 merged by jenkins-bot:
[oojs/ui@master] ProcessDialog: Increase title size, and align to left on mobile

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

I agree with using frameless close/back icons, but I'm not sure how I feel about the other proposed changes. Especially the secondary actions at the bottom look weird with the proposed styling.

They are an issue, specifically when only normal (unflagged) ButtonWidgets. We have to revisit them – my first proposal would be to apply a similar treatment as MessageDialog buttons.

Volker_E renamed this task from improve process dialog appearance – simplify actions to Improve process dialog appearance – simplify actions.Jun 27 2019, 1:59 AM

@alexhollender Additional comment to your point on full-height button: @Jdforrester-WMF have been discussing the back and forth of the different possibilities (frameless, full-height, mobile in all dialog bars vs current framed buttons everywhere vs a mix) and came up with a solution that seems like a reasonable step forward for the time being:
Having desktop follow MessageDialog button height of 40px as a middle ground of further de-emphasizing interaction buttons and close consistency gap to other usages like VE toolbar.
On mobile the bar remains our Style Guide touch target size of 44px.

Frameless as it clearly gives more focus to dialog title. The title receives slightly bigger font-size too.

Happy to get into follow-up tasks with your inputs and @Cntlsn or @iamjessklein's. Still excited for this current treatment improvement as it clearly increases usability and user task flow abilities in my conviction.

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

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

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

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

I've opened 4 bugs as result of this patch. T226821 and T226822 should be blockers. The former could potentially be fixed, but I think T226822 is going to require us to delay this feature while we work out what the new API is going to be, and examine which use cases this breaking change might effect.

I think implementing the new buttons as frameless+primary was a mistake. For the toolbar we mostly copied styles from framed+primary with a tweak. This would have avoided T226821 and T226780. It also would've left Apex unchanged (so fixing T226819) and matching the behaviour or toolbars in Apex (which use framed buttons).

As said by others in this conversation before, we do have a bit of a problem with the top bar on mobile.
For instance, looking at a scenario like the one below

Screenshot from 2019-06-27 16-32-30.png (436×247 px, 41 KB)

A couple of issues arise:

  • The title can't be read in full. It could eventually get impossible to understand what the title is about if the trigger to open the modal didn't mirror the same or similar copy as the title.
  • The back arrow with the left aligned title could be interpreted as one same action, creating confusion in whether the user is currently in the "Ask the h..." screen or should actually tap go back to get to it.

The icon button solution could solve the issue in some cases, but would also mean we will need to create more icons for more special actions, some of them being harder to represent or differentiate.

I understand having all the actions in the top bar is a current standard mobile pattern, but maybe we could consider the old school treatment of moving the progressive action to the bottom of the screen?

Screenshot 2019-06-28 14.59.11.png (1×752 px, 151 KB)

I understand having all the actions in the top bar is a current standard mobile pattern, but maybe we could consider the old school treatment of moving the progressive action to the bottom of the screen?

The reason for this is that actions will be hidden by the virtual keyboard, and on iOS you can't even get around this by using position:fixed;bottom:0; as it doesn't report the correct viewport dimensions.

@Cntlsn Thanks for sharing your inputs.

A couple of issues arise

We should file separate tasks to discuss those issues. The readability issue was already happening outside the intended scope of this task (simplifying, reducing noise of desktop ProcessDialog while also fixing code issues on the way).
Specifically second one is more connected to the new approach (although I'm not convinced if the before state was any clearer, as the title also moved to the left on small screens), this should receive wider designers' awareness.

I think implementing the new buttons as frameless+primary was a mistake. For the toolbar we mostly copied styles from framed+primary with a tweak. This would have avoided T226821 and T226780. It also would've left Apex unchanged (so fixing T226819) and matching the behaviour or toolbars in Apex (which use framed buttons).

As shared on IRC, the main reason was to spare client output code. It's also not, that folks couldn't have used frameless+primary combination already, even though we haven't master styled them yet.

Also it uncovers more code shortcomings like the not limited to enabled
.oo-ui-processDialog-actions-primary .oo-ui-actionWidget.oo-ui-buttonElement-frameless.oo-ui-flaggedElement-progressive:hover, .oo-ui-processDialog-actions-safe .oo-ui-actionWidget.oo-ui-buttonElement-frameless.oo-ui-flaggedElement-progressive:hover

It may have been quicker in the short term, but using frameless buttons is wrong. In Apex there is no frameless design that works in a toolbar or dialog bar which is why we use framed:

image.png (176×608 px, 45 KB)

It would be simpler to use framed buttons and restyle them in WMUI to reach to the edges.

So simplicity (in terms of code overrides I guess) is the key from your POV, correct?

We didn't stop users of OOUI to make frameless buttons primary so far, also I could imagine that there's use cases for exactly that as well.
So it comes down to either
a) make frameless buttons work in dialogs with all it's current issues or
b) override framed buttons appearance (for all dialog buttons: primary, safe actions) to get closer to mobile
b1) still remove distinction between mobile (framed) and desktop (frameless). Apex didn't support the mobile appearance accordingly either before this change
b2) decide if we want to prevent frameless primary actions at all

We didn't stop users of OOUI to make frameless buttons primary so far, also I could imagine that there's use cases for exactly that as well.

Adding primary to a frameless button previously did nothing. It didn't thrown an exception, but it was essentially not allowed.

b1) still remove distinction between mobile (framed) and desktop (frameless). Apex didn't support the mobile appearance accordingly either before this change

I'm not sure I understand this. We should use restyled framed buttons on desktop and mobile. At this point I am assuming that Apex is not really supported on mobile, as MobileFrontend only ever uses WMUI.

The patch didn't switch all 'back' buttons to use an icon on desktop, which we may want to address is a future release?

Change 521929 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[oojs/ui@master] ProcessDialog: Make "back" buttons icon-only on desktop too

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

Change 521929 merged by jenkins-bot:
[oojs/ui@master] ProcessDialog: Make "back" buttons icon-only on desktop too

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

This comment was removed by SerDIDG.

Is this done now?

Change 521929 merged by jenkins-bot:
[oojs/ui@master] ProcessDialog: Make "back" buttons icon-only on desktop too

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

Okay, so is this done now? ;)

Volker_E claimed this task.
Volker_E updated the task description. (Show Details)

Indeed.

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

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

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

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