Would make the styling consistent with the other toolbar, for example the custom dropdown:
and the button styling in Apex
are both inconsistent.
Would make the styling consistent with the other toolbar, for example the custom dropdown:
and the button styling in Apex
are both inconsistent.
Project | Branch | Lines +/- | Subject | |
---|---|---|---|---|
mediawiki/extensions/ContentTranslation | master | +139 -53 | Convert publishSettings widget to a toolbar group |
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | Esanders | T192081 CX2: Toolbar menu appears underneath column | |||
Resolved | Pginer-WMF | T193255 Make publish/draft settings toolbar an OOUI toolbar |
Change 429450 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/ContentTranslation@master] Convert publishSettings widget to a toolbar group
We may want to consider some of the aspects that we plan to include in the publish settings panel in the future (T133862 provides an overview, although designs may need to be iterated):
Would it be possible to support the above making the publish settings menu a toolbar? I'm not concerned about the purely styling changes, although I think there is value in making the selections more explicit with the use of radio buttons and checkboxes (maybe @Volker_E has some thoughts on that). I shared a mockup illustrating the initial design idea below:
Change 429450 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] Convert publishSettings widget to a toolbar group
@Pginer-WMF What is the reason for it being a menu? Such rich menu seem counter-intuitive from our current UI library and most in-production combinations. This should rather be in a dialog from the example options given.
This was intended to be a flyout panel: more detailed than a menu where you just select an option, but lighter that a modal dialog that blocks the user flow. Here is an example of the documentation of Windows platform guidelines where similar components are compared.
One question is whether we want to include such components as part of our guidelines. I think they bring the value to be more in-context, but I also understand the advantage of keeping the number of different components low, and a dialog can be a good solution for this case. I'll explore how this would work as a dialog. I'll continue such work on the main design ticket (T133862) where we can discuss the idea further.
I think this got solved in the new version of Content Translation. The custom drop-down was replaced with a ooui dialog: