Hey everyone,
There's no list for this, so I am assuming that if you've been invited to a MediaWiki UI Hack Day, then you are interested, so you've been CCed. In addition, the Design list is on this, so, please make sure to reply all.
Our team (Core Features) has been implementing MW UI as the basis of our design with the new Flow extension. I think we're the first team to really do that to this extent, and so I have some preliminary feedback to give regarding this.
Design mockups have frequently called for the use of the "mw-ui-quiet" class. Unfortunately, we've been running into problems with it. Often, the use case is one of two scenarios:
1. In a *form*, next to a regular mw-ui-button. 2. Outside of a form, as a *link* with hover/focus context color.
Both of these scenarios have presented us with a serious problem: having a content element with padding, but no discernible borders, makes aligning these buttons impossible semantically. You are essentially forced to override mw-ui-quiet CSS locally to have no padding for it to look "normal", and then in that case, they are no longer button-like, but are instead simple links.
Problems:
- *Exhibit A* - in a form: note the excessive whitespace between the Cancel button and the others. Increasing the margin between buttons only makes matters worse, and causes the button to look even further away than intended.
* Solution:* We are now using a bordered-button for all form buttons in Flow. We shouldn't be trying to hide buttons from the end user.
[image: Inline image 1]
- *Exhibit B* - independent links: they do not align to edges, and they cannot match up to other inline-block or inline elements (we also lack a mw-ui-spacer or such class to apply to other elements so that they may inherit its padding and simulate it to even things out).
* Originally, we were using a CSS override to 0 the padding, but we shouldn't have to do that for mw-ui elements in core if we want to maintain a coherent style moving forward. Solution: *I've since changed these to simple anchors with no special classes.
[image: Inline image 2]
Given these issues, I can't see any real semantic usage for mw-ui-quiet. Can anyone give me a current usage that necessitates keeping it around?
In fact, I'm advocating that we remove it entirely from core, and instead use a different quiet button that is somewhere between the current quiet and the current regular buttons. I've been calling them "mw-ui-sleeper" for now. Here is an example of it in action (on topic Reply, Preview, and Cancel). http://area51.yar.gs/wmf/flow1/
Thoughts and concerns?
Thanks, Shahyar
Shahyar and I discussed, action is, that the "in-line" are no longer quiet state, and the quiet buttons get special padding rules, Shahyar can expand on technical bits if he chooses
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Tue, Mar 25, 2014 at 3:43 PM, Shahyar Ghobadpour < sghobadpour@wikimedia.org> wrote:
Hey everyone,
There's no list for this, so I am assuming that if you've been invited to a MediaWiki UI Hack Day, then you are interested, so you've been CCed. In addition, the Design list is on this, so, please make sure to reply all.
Our team (Core Features) has been implementing MW UI as the basis of our design with the new Flow extension. I think we're the first team to really do that to this extent, and so I have some preliminary feedback to give regarding this.
Design mockups have frequently called for the use of the "mw-ui-quiet" class. Unfortunately, we've been running into problems with it. Often, the use case is one of two scenarios:
- In a *form*, next to a regular mw-ui-button.
- Outside of a form, as a *link* with hover/focus context color.
Both of these scenarios have presented us with a serious problem: having a content element with padding, but no discernible borders, makes aligning these buttons impossible semantically. You are essentially forced to override mw-ui-quiet CSS locally to have no padding for it to look "normal", and then in that case, they are no longer button-like, but are instead simple links.
Problems:
- *Exhibit A* - in a form: note the excessive whitespace between the
Cancel button and the others. Increasing the margin between buttons only makes matters worse, and causes the button to look even further away than intended.
Solution:* We are now using a bordered-button for all form buttons in Flow. We shouldn't be trying to hide buttons from the end user.
[image: Inline image 1]
- *Exhibit B* - independent links: they do not align to edges, and
they cannot match up to other inline-block or inline elements (we also lack a mw-ui-spacer or such class to apply to other elements so that they may inherit its padding and simulate it to even things out).
Originally, we were using a CSS override to 0 the padding, but we shouldn't have to do that for mw-ui elements in core if we want to maintain a coherent style moving forward. Solution: *I've since changed these to simple anchors with no special classes.
[image: Inline image 2]
Given these issues, I can't see any real semantic usage for mw-ui-quiet. Can anyone give me a current usage that necessitates keeping it around?
In fact, I'm advocating that we remove it entirely from core, and instead use a different quiet button that is somewhere between the current quiet and the current regular buttons. I've been calling them "mw-ui-sleeper" for now. Here is an example of it in action (on topic Reply, Preview, and Cancel). http://area51.yar.gs/wmf/flow1/
Thoughts and concerns?
Thanks, Shahyar
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Shahyar, thanks for noticing the details. Now I've seen the ragged spacing of Cancel [ Preview ] [ Reply ] it can't be unseen!
TL;DR : 1. I think having consistent bordered buttons in a form is worthwhile, and mw-ui-sleeper for the secondary ones is a good solution to avoid the multi-colored Skittles problem. 2. We should be able to apply the coloring behavior on hover & click of constructive/destructive/progressive/neutral to any text, including Reply * Edit * Thank. 3. What about your mw-ui-thin for the button in the topic titlebar ?
Talking about these things is hard because we're imagining what button states will be and how they'll combine. It would be great if you could build a new Living Style Guide with many example buttons and text explaining the CSS usage. Change mediawiki.ui in core, cd resources , type make kss.
On Tue, Mar 25, 2014 at 3:43 PM, Shahyar Ghobadpour < sghobadpour@wikimedia.org> wrote:
You are essentially forced to override mw-ui-quiet CSS locally to have no padding for it to look "normal", and then in that case, they are no longer button-like, but are instead simple links.
(There is another approach, which is to draw a border around mw-ui-quiet buttons like Cancel upon hover and click. "Why is this alignment ugly? Oh,it's a button." I'm not crazy about that solution.)
- Solution:* We are now using a bordered-button for all form buttons in Flow. We shouldn't be trying to hide buttons from the end user.
OK, but then we do hide buttons with Reply * Edit * Thanks . I think the
current mix of borderless and bordered in Cancel [ Preview ] [Reply] can be defended, though I prefer your approach.
- Solution: *I've since changed [ Reply * Edit * Thanks ] to simple anchors with no special classes.
Noooo. These should have the constructive/progressive/destructive coloring
that mw-ui-quiet buttons get on hover and click. Try it at http://tools.wmflabs.org/styleguide/desktop/section-2.html . Button colors communicate meaning, they're not just some arbitrary Agora color palette, we need to use them.
A simple anchor with underline has problems for me because I right-click on anchors to copy URLs, to open in new tabs and windows, etc.
So I think mw-ui-constructive/progressive/destructive and mw-ui-neutral should be decoupled from mw-ui-button's border and padding, so that you can apply them anywhere to get the state highlighting.
In fact, I'm advocating that we remove [mw-ui-quiet] entirely from core, and instead use a different quiet button that is somewhere between the current quiet and the current regular buttons. I've been calling them " mw-ui-sleeper" for now. Here is an example of it in action (on topic Reply, Preview, and Cancel). http://area51.yar.gs/wmf/flow1/
(Note: click in a textarea to see the buttons appear, and enter something to see them activate.) I like it. Your mockup also introduces a mw-ui-thin [Reply] inside the topic titlebar. When would people use that instead of your inline Reply button or a full button? Is it a Flow-only design?
