Page MenuHomePhabricator

Convert some MW core special pages to OOUI
Closed, ResolvedPublic

Description

Convert several MW core special pages to OOUI as a demonstration that it's possible now.

Part of "front-end standardisation" Q2 priority project.

Details

Reference
bz72715

Related Objects

StatusAssignedTask
OpenNone
OpenNone
Resolvedmatmarex
Resolved TrevorParscal
Resolved TrevorParscal
Resolvedmatmarex
Resolvedmatmarex
Resolvedmatmarex
Resolvedmatmarex
Resolvedmatmarex
Resolvedcscott
Resolvedmatmarex
Resolvedmatmarex
Resolvedmatmarex
Resolvedmatmarex
Resolvedmatmarex
Resolvedbd808
Resolvedmatmarex
ResolvedJdforrester-WMF
ResolvedPrtksxna
Resolved TrevorParscal
Resolvedmatmarex
ResolvedPrtksxna
Resolved TrevorParscal
Resolved TrevorParscal
Resolved TrevorParscal
ResolvedJdforrester-WMF
Resolved TrevorParscal
Resolved TrevorParscal
Resolvedmatmarex
Resolvedmatmarex
Resolvedmatmarex
Resolved TrevorParscal
Resolved TrevorParscal
Resolved TrevorParscal
Resolved TrevorParscal
Resolvedmatmarex
Resolvedmatmarex
Resolvedmatmarex
ResolvedPrtksxna
Resolvedmatmarex
Resolvedmatmarex
Resolvedmatmarex
Resolvedmatmarex
ResolvedMarkTraceur
Resolvedmatmarex
Resolvedmatmarex
Resolvedmatmarex
Resolvedmatmarex
Resolvedmatmarex
Resolvedmatmarex

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 3:46 AM
bzimport set Reference to bz72715.
bzimport added a subscriber: Unknown Object (MLST).
Jdforrester-WMF renamed this task from Convert MW core login/logout/signup pages to OOUI to Convert MW core login/create/reset password pages to OOUI.Dec 18 2014, 9:11 PM

This would be a lot less unpleasant if somebody did T19312, or maybe even T12317, first.

matmarex updated the task description. (Show Details)Dec 24 2014, 8:41 PM
matmarex removed a subscriber: Unknown Object (MLST).
matmarex renamed this task from Convert MW core login/create/reset password pages to OOUI to Convert some MW core special pages to OOUI.Jan 15 2015, 1:17 AM
matmarex updated the task description. (Show Details)
matmarex lowered the priority of this task from High to Normal.Mar 12 2015, 2:32 PM

Change 208285 had a related patch set uploaded (by Bartosz Dziewoński):
[WIP] Switch some HTMLForms in special pages to OOUI

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

matmarex added a subscriber: MarkTraceur.EditedMay 12 2015, 2:43 PM

Here are some screenshots of the "first iteration", brought to you by @MarkTraceur's work on T85291. These pages were previously using the "VForm" style and switching them over to the new "OOUI" style, once implemented, is a matter of changing a single value.

Special: ChangeEmail

VFormOOUI

Special: ResetPassword

VFormOOUI

Issues:

  • The help icon looks slightly blurry, this will be fixed after T97631.
  • The checkbox is smaller, this is a design decision being discussed on T86003.

Special: PageLanguage

VFormOOUI

Issues:

  • The extremely long dropdown list with languages has usability issues, most importantly T91126.
  • Radio buttons are not OOUI-like yet, we're working on this on T98855.

Also, once the value is changed, we can take out some of the weird special-casing in forms that use OOUI or mwui in part - BetaFeatures comes to mind immediately (so Special:Preferences in general), but OAuth and many other core forms will benefit.

Change 208285 had a related patch set uploaded (by Jforrester):
[WIP] Switch some HTMLForms in special pages to OOUI

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

Change 208285 had a related patch set uploaded (by Mattflaschen):
[WIP] Switch some HTMLForms in special pages to OOUI

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

This is excellent!

Are you going to Cc a designer to review? E.g. the label was intended to sit closer to the field underneath, which is still the case on login form.

These pages were previously using the "VForm" style and switching them over to the new "OOUI" style

vform stood for "vertically-stacked form", everything was intended to be the same width. It was a $displayFormat different from the existing div, table, and raw which also used mediawiki.ui styles. I think clients should be able to request buttons styled as OOUI without getting the vform layout e.g. OOUI buttons in 'table' display format.

When you specify 'vform' as displayFormat, the form width needs to be constrained. (Picking a width for vform was challenging, it ended up being determined by the width of the restyled FancyCaptcha on the login form.).

Are you going to Cc a designer to review? E.g. the label was intended to sit closer to the field underneath, which is still the case on login form.

I don't know who would review these, or if there's anyone willing to at all? If anyone has any feedback to offer, we'll be happy to hear it. Just note that this is the same interface as used in VisualEditor's dialogs and any changes should fit both use cases.

There is about twice as much spacing between the label and widget in OOUI-styled forms than in the old ones, but the widgets are also about twice as big. I agree that the OOUI style might be a bit too whitespacey, though.

vform stood for "vertically-stacked form", everything was intended to be the same width. It was a $displayFormat different from the existing div, table, and raw which also used mediawiki.ui styles. I think clients should be able to request buttons styled as OOUI without getting the vform layout e.g. OOUI buttons in 'table' display format.

It should be possible to use OOUI widgets for existing forms, let's just be cautious about this to avoid breaking interfaces. OOUI integrates seamlessly with HTML, so you can just replace, say, Html::input( $name, $value, 'submit' ) with new OOUI\ButtonInputWidget( array( 'name' => $name, 'value' => $value, 'type' => 'submit' ) ). We could do the same in HTMLFormField subclasses, possibly controlled by some config, if anyone desires. I'm not sure how useful this would be in general, though.

The various display formats of HTMLForm are terribly confused, eh. I think a better naming would be 'horizontal' instead of 'table' and 'vertical' instead of 'div', since that's basically what these two result with. 'vform' would then be 'vertical-mediawikiui' and 'ooui' would be 'vertical-oui'. But this is probably not worth doing.

While we're using a vertical layout in OOUI HTMLForm, and while this is the generally recommended layout for OOUI forms, we do sort of kind of support a more horizontal one too – you can it by setting align: 'left' rather than align: 'top' for individual FieldLayouts. It doesn't exactly behave like 'table' HTMLForm, though, especially for individual checkboxes/toggles. It looks like this:

When you specify 'vform' as displayFormat, the form width needs to be constrained. (Picking a width for vform was challenging, it ended up being determined by the width of the restyled FancyCaptcha on the login form.).

OOUI form widgets' widths are generally limited to 50em (~600px, depending on the skin) for sanity (to avoid input fields stretching across the whole width of 4k display, for example), but this isn't a hard limit.

Elitre added a subscriber: Elitre.Jun 16 2015, 8:22 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 24 2015, 9:03 PM

I think this task, as written ("Convert some MW core special pages to OOUI"), is sufficiently resolved. We have converted some special pages, and then some more (although most of the relevant commits weren't linked to this bug).

Quick tally:

Several more are in progress or waiting for reviews.

matmarex updated the task description. (Show Details)Nov 4 2015, 6:33 PM