Page MenuHomePhabricator

Improve form layouts in OOUI MW core forms for better user experience
Closed, ResolvedPublic

Description

When we are looking through forms on their way of being converted to OOjs UI, there are a few recurring shortcomings / glitches so far:

  • People are criticizing the space needs in contrast to the old forms
  • form elements don't seem to follow a grid or a pattern in distance to each other, to their labels. We're neglecting gestalt principle of proximity.
  • usage of oo-ui-panelLayout-padded oo-ui-panelLayout-framed classes with it's 3D shadow disturb the connection to the rest of the forms

Related to those issues are

White-space if implemented appropriately helps orientation in forms and getting tasks done quicker for users. Some of the criticism might come from familiarity with the old layout and having to re-learn. Listening carefully and adding side-by-side examples helps to clarify.
My proposals furthermore:

  • To the second question, one promising way seems to be making all form elements just having applied margin-top / margin-right and override for :first-child instances to support back to IE 7+. With this and clear consistent values, a bit higher for in-between elements (1em) and lower for in between elements of a group (0.5em), like CheckboxMultiselectWidget or label for inputs, the proximity issue get's solved.
  • We should also get rid of the oo-ui-panel-* classes and go instead for styling mw-htmlform-ooui-wrapper.
  • Replacing paddings with margins as it's a weird use of property to create margins.
Before
After (proposal)

Update 2018-04-02

  • Aligning spacings to newly unified base font-size calculations

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Volker_E updated the task description. (Show Details)Jun 2 2016, 2:47 AM
TheDJ added a subscriber: TheDJ.Jun 6 2016, 8:15 PM

PS. I note that MediaWiki.UI also ran into this problem and is providing mw-ui-input-inline

Volker_E updated the task description. (Show Details)Jul 27 2016, 2:34 PM
Jdforrester-WMF moved this task from Backlog to Next-up on the OOUI board.Sep 12 2016, 6:23 PM
Jdforrester-WMF triaged this task as High priority.
Volker_E added a comment.EditedSep 29 2016, 4:05 AM

Also replacing usage of padding with margin as it is a weird (from specification point wrong) use, as already pointed out at https://phabricator.wikimedia.org/T117762#1834175 in T117762: There's still too much whitespace between FieldLayouts in a FieldsetLayout

Volker_E updated the task description. (Show Details)Sep 29 2016, 4:06 AM

Change 317456 had a related patch set uploaded (by VolkerE):
MediaWiki theme: Unify and align margin and padding of form elements

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

From OOjs UI demo

Before change 317456After

The ToggleSwitchWidget is an exceptional widget, that is not part of the big majority of forms and included here just for demo purposes. On the same demo another extra widget fits into the canvas with the patch applied and the correlation between labels and inputs becomes clearer.

Volker_E moved this task from Next-up to Doing on the OOUI board.Oct 24 2016, 8:38 AM

Change 317456 merged by jenkins-bot:
MediaWiki theme: Reduce, align margin and padding of form elements

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

@matmarex @Esanders In order to get checkboxes/radios aside of each other: We've got .oo-ui-fieldLayout-align-inline – was this intended to allow those as shown in the screenshot above (as easier option outside of HorizontalLayout)? In the demo I just see it on the checkboxes/radios and the ”ActionFieldLayout aligned inline“.
From my perspective it would make a lot of sense to use the class and make it visually follow the semantics, but I want to make sure not to interfere with anything already in-use, especially in VE.

Volker_E updated the task description. (Show Details)
Volker_E moved this task from OOjs-UI-0.18.2 to Doing on the OOUI board.Dec 7 2016, 12:30 AM
Volker_E edited projects, added OOUI; removed OOUI (OOjs-UI-0.18.2).
Jdforrester-WMF moved this task from Doing to OOjs-UI-0.18.3 on the OOUI board.Dec 7 2016, 12:31 AM
Jdforrester-WMF edited projects, added OOUI (OOjs-UI-0.18.3); removed OOUI.

It would be amazing to have inline class. I experimented with "flatlist" on multiselect and it's not nice (mostly because of backward compatibility).

Simply with the large number of options and checkboxes on for example the watchlist panel, an OOUI version risks taking up all of my screen (in landscape mode). I couldn't find a document describing the design vision for this, and so I don't know if this has already been considered, but I would suggest making an option to have smaller checkboxes and other widgets. This would help combat the bloat seen in e.g. T117790: Convert Special:EditWatchlist to OOUI and complained about re T134525: Convert Special:DeletedContributions to OOUI.

@BethNaught Not necessarily as general rule, but in specific cases, like in the form above providing screenshots of this task, horizontal aligning of checkboxes makes sense. That's exactly what my question above is targeting at.

@matmarex @Esanders In order to get checkboxes/radios aside of each other: We've got .oo-ui-fieldLayout-align-inline – was this intended to allow those as shown in the screenshot above (as easier option outside of HorizontalLayout)? In the demo I just see it on the checkboxes/radios and the ”ActionFieldLayout aligned inline“.
From my perspective it would make a lot of sense to use the class and make it visually follow the semantics, but I want to make sure not to interfere with anything already in-use, especially in VE.

No, contrary to the name, the 'inline' align of FieldLayout doesn't display inline (it means that the label and widget will be shown on a single line, which is usually appropriate for checkboxes and other small widgets).

In MediaWiki core, there's some styling for displaying multiple checkboxes on a single line in HTMLForm, it's the 'flatlist' option that @Ladsgroup mentions above. But personally, I think its effect is reasonably nice… code is hacky though. You can see it in action in the form on Special:BlockList.

Volker_E updated the task description. (Show Details)Dec 13 2016, 6:53 PM
Volker_E raised the priority of this task from High to Needs Triage.
Volker_E triaged this task as High priority.Dec 13 2016, 7:07 PM
Volker_E added a comment.EditedDec 13 2016, 7:13 PM

@matmarex That means, you either mix HTMLForm flatlist with widgets or –by OOjs UI only measurements– go for HorizontalLayout option, correct?

Volker_E updated the task description. (Show Details)Dec 20 2016, 10:30 PM
Volker_E updated the task description. (Show Details)Jan 15 2017, 5:33 AM

Change 335601 had a related patch set uploaded (by VolkerE):
FieldLayout: Remove need for extra fieldLayout-header element

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

Volker_E moved this task from OOjs-UI-0.19.1 to Reviewing on the OOUI board.Feb 8 2017, 12:25 AM
Volker_E edited projects, added OOUI; removed OOUI (OOjs-UI-0.19.1).
Huji added a subscriber: Huji.Feb 15 2017, 2:23 AM

I think it should; it is yet another example of ignoring the principle of proximity, IMHO.

kaldari removed a subscriber: kaldari.Feb 15 2017, 5:51 PM

Change 423598 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[oojs/ui@master] WikimediaUI theme: Replace fixed spacing values with vars

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

Volker_E updated the task description. (Show Details)Apr 3 2018, 5:33 AM

Change 423598 merged by jenkins-bot:
[oojs/ui@master] WikimediaUI theme: Replace fixed spacing values with vars

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

Volker_E closed this task as Resolved.Apr 3 2018, 8:36 PM
Volker_E removed a project: Patch-For-Review.
Volker_E updated the task description. (Show Details)
Volker_E moved this task from Doing… to Done on the UI-Standardization-Kanban board.
Volker_E raised the priority of this task from High to Needs Triage.