|Open||None||T49145 Formally deprecate jQuery UI after we've stopped using jQuery UI in extensions and core (replacing it with OOUI).|
|Open||None||T100270 Replace use of jQuery UI and MW UI with OOUI across all Wikimedia-deployed extensions and core|
|Open||None||T122014 Convert all extensions/skins to OOUI|
|Open||None||T192099 Convert Extension:EmailAuthorization to use OOUI|
- Mentioned In
- T203839: Convert Extension:Cargo to OOUI
rEEAUa678fa21c161: Convert Special:EmailAuthorizationConfig to use OOUI
rEEAU76f486ed5ca2: Convert Special:EmailAuthorizationConfig to use OOUI
rEEAU1106413189b3: Convert Special:EmailAuthorizationConfig to use OOUI
rEEAU16a3bc0b194d: Convert Special:EmailAuthorizationConfig to use OOUI
Sorry to belated response, but above resulted screenshots are wrong on several levels from an UI Standardization standpoint and we should follow-up quickly or revert the merged change and introduce a new.
The primary button appearance is meant to be limited to one action per view.
The buttons in the three different fieldsets should be quiet progressive buttons with the “Revoke” one considered to be a quiet destructive?
Without having the interface at my fingertips is there even a primary action from all the ones? If unsure, it's better to also turn both “Show…” buttons at the end of the form into quiet progressive buttons.
Yes, the "before" UI above is one I built in a hurry to serve a purpose. It is not beautiful nor does it conform to good UI practices. The OOUI conversion was no worse than the original :-)
@cicalese Just to voice it, I value and appreciate @Jayprakash12345's recent work on OOUIfication of interfaces and you reviewing it. There's a good number done in little time.
The case here is, that we're turning all “normal” buttons into “primary action” buttons, which is an issue from a user-experience point of view. Understanding the uses cases of all forms is sometimes hard. In this specific case, where I've seen this form for the first time in the screenshots above, I'd agree with you, a real design process invoked wouldn't end up in such form representation. Nevertheless let's achieve what we can achieve while we're at changing it over to OOUI and amending the buttons falls for me into necessary and possible achievements category. :)
@Jayprakash12345 “Show authorized email addresses and domains” and “Show all wiki users” buttons need to be “quiet progressive” buttons as they are both same priority and higher priority than other non-destructive buttons on the view. Keeping “Revoke” quiet destructive is a fine compromise here.
If possible the two form submitting buttons should be in a HorizontalLayout as well.
@Jayprakash12345 As one of our principles is top-to-bottom alignment for simpler orientation (not having both, eye movement top-to-bottom, interchanging with left-right for accomplishing task), I suggest button alignment on the starting side (left in LTR languages, right in RTL languages, accomplished automatically).