Shahyar Ghobadpour
2014-03-25 22:43:57 UTC
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/design/attachments/20140325/00132566/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Quiet---Exhibit-A.png
Type: image/png
Size: 19093 bytes
Desc: not available
URL: <Loading Image...
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Quiet---Exhibit-B.png
Type: image/png
Size: 36562 bytes
Desc: not available
URL: <Loading Image...
>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/design/attachments/20140325/00132566/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Quiet---Exhibit-A.png
Type: image/png
Size: 19093 bytes
Desc: not available
URL: <Loading Image...
>-------------- next part --------------
A non-text attachment was scrubbed...
Name: Quiet---Exhibit-B.png
Type: image/png
Size: 36562 bytes
Desc: not available
URL: <Loading Image...
>
