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
T136790 Special_Active_users – MediaWiki_2015 2016-06-01.png (590×954 px, 113 KB)
After (proposal)
T136790 Special_Active_users_fast_mockup – MediaWiki_2015 2016-06-01.png (515×955 px, 107 KB)

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

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

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

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

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
T136790 Form layout before - OOjs UI Demos 2016-10-23.png (566×661 px, 48 KB)
T136790 Form layout after - OOjs UI Demos 2016-10-23.png (549×658 px, 47 KB)

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.

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 edited projects, added OOUI; removed OOUI (OOjs-UI-0.18.2).

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 raised the priority of this task from High to Needs Triage.Dec 13 2016, 7:05 PM
Volker_E moved this task from Review to Doing… on the UI-Standardization-Kanban board.

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

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

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

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

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

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 raised the priority of this task from High to Needs Triage.
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.

Change 335601 abandoned by VolkerE:
FieldLayout: Remove need for extra fieldLayout-header element

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