Hi,
Today I worked on finishing the new buttons styles. They're mostly done but I would like to clarify a few things. You can preview the current version by downloading https://www.dropbox.com/s/b1sn1x4slkwgqs9/buttons.zip
Every button variant has 4 subvariants: * normal * disabled * quiet * quiet disabled
Doubts:
1. The colors. I took them from https://www.mediawiki.org/wiki/File:Guide_Color.png but blue looks kind of dim. Blue, green an red also don't seem to have the same level of perceived lightness. Is that OK?
2. Quiet buttons. I remember clearly from talking to May that we wanted them to be colored in their default state and make them slightly darker in hover. I don't remember what they were supposed to look like when disabled. Right now they're slightly lighter but maybe they should be all gray?
3. Focus state. Right now it's the same as hover state, but I'm afraid it might not be enough for people with poor vision or color-blind who use keyboard for navigation. Opinions?
Thanks,
Overall they look good, a few notes and answers to your questions.
- The outer shadows seem to be missing, you can see them on http://33cc77.com/wikipedia/
- The colors. I took them from https://www.mediawiki.org/
wiki/File:Guide_Color.png but blue looks kind of dim. Blue, green an red also don't seem to have the same level of perceived lightness. Is that OK?
I just checked the colors from Guide_Color.png and the button blue isn't there it should be #347BFF The other colors are spot on.
- Quiet buttons. I remember clearly from talking to May that we wanted
them to be colored in their default state and make them slightly darker in hover. I don't remember what they were supposed to look like when disabled. Right now they're slightly lighter but maybe they should be all gray?
Thats not quite right, unless May changes it the quite buttons should be black normally, their action color on hover, and the action color click state (darker version) on click. https://www.dropbox.com/s/amh0gfgc1p2i6c6/Screenshot%202014-01-03%2010.24.45... for the neutral state which is normal:black -> hover:#747474 -> click:black
All of the disabled quiet state buttons should have the same text color as the background color of the primary disable buttons which i'm pretty sure is #BFBFBF
- Focus state. Right now it's the same as hover state, but I'm afraid it
might not be enough for people with poor vision or color-blind who use keyboard for navigation. Opinions?
I think we should use the hover state for focus state (which is what you're doing) and suppress any browsers highlighting or borders (which is seems like you're also doing) So I think we're good to go there.
All in all, these look awesome, I can't wait to get them out in the world.
Thanks,
Juliusz
A few more small issues…
https://www.dropbox.com/s/7szqg98esa39ogd/Screenshot%202014-01-03%2010.38.45...
The button height is a bit off, should be 72px (is currently 75px) (not including exterior drop shadow)
hard drop shadow is missing from the primary button text in states, normal, hover, click, doesn't exist in disabled state. (2 px, black, 10% alpha, downwards)
https://www.dropbox.com/s/xf6jebz9a6v6khb/Screenshot%202014-01-03%2010.44.14...
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Fri, Jan 3, 2014 at 10:31 AM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
Overall they look good, a few notes and answers to your questions.
- The outer shadows seem to be missing, you can see them on
- The colors. I took them from https://www.mediawiki.org/
wiki/File:Guide_Color.png but blue looks kind of dim. Blue, green an red also don't seem to have the same level of perceived lightness. Is that OK?
I just checked the colors from Guide_Color.png and the button blue isn't there it should be #347BFF The other colors are spot on.
- Quiet buttons. I remember clearly from talking to May that we wanted
them to be colored in their default state and make them slightly darker in hover. I don't remember what they were supposed to look like when disabled. Right now they're slightly lighter but maybe they should be all gray?
Thats not quite right, unless May changes it the quite buttons should be black normally, their action color on hover, and the action color click state (darker version) on click. https://www.dropbox.com/s/amh0gfgc1p2i6c6/Screenshot%202014-01-03%2010.24.45... for the neutral state which is normal:black -> hover:#747474 -> click:black
All of the disabled quiet state buttons should have the same text color as the background color of the primary disable buttons which i'm pretty sure is #BFBFBF
- Focus state. Right now it's the same as hover state, but I'm afraid it
might not be enough for people with poor vision or color-blind who use keyboard for navigation. Opinions?
I think we should use the hover state for focus state (which is what you're doing) and suppress any browsers highlighting or borders (which is seems like you're also doing) So I think we're good to go there.
All in all, these look awesome, I can't wait to get them out in the world.
Thanks,
Juliusz
On 01/03/2014 07:44 PM, Jared Zimmerman wrote:
A few more small issues…
https://www.dropbox.com/s/7szqg98esa39ogd/Screenshot%202014-01-03%2010.38.45...
The button height is a bit off, should be 72px (is currently 75px) (not including exterior drop shadow)
Button height is defined by padding and font size. I guess they are taller in the living style guide than in MW, not sure why.
hard drop shadow is missing from the primary button text in states, normal, hover, click, doesn't exist in disabled state. (2 px, black, 10% alpha, downwards)
https://www.dropbox.com/s/xf6jebz9a6v6khb/Screenshot%202014-01-03%2010.44.14...
The shadow is not here: https://upload.wikimedia.org/wikipedia/mediawiki/f/fe/Agora_specs_Buttons_an... and I'm pretty sure May said there shouldn't be any shadow. This can be changed anytime though, so let's reach some agreement on Monday when she's back.
Its there just not called out, in the spec, Lets sync up monday.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Fri, Jan 3, 2014 at 12:20 PM, Juliusz Gonera jgonera@wikimedia.orgwrote:
On 01/03/2014 07:44 PM, Jared Zimmerman wrote:
A few more small issues…
https://www.dropbox.com/s/7szqg98esa39ogd/Screenshot%202014-01-03%2010.38.45...
The button height is a bit off, should be 72px (is currently 75px) (not including exterior drop shadow)
Button height is defined by padding and font size. I guess they are taller in the living style guide than in MW, not sure why.
hard drop shadow is missing from the primary button text in states, normal, hover, click, doesn't exist in disabled state. (2 px, black, 10% alpha, downwards)
https://www.dropbox.com/s/xf6jebz9a6v6khb/Screenshot%202014-01-03%2010.44.14...
The shadow is not here:
https://upload.wikimedia.org/wikipedia/mediawiki/f/fe/Agora_specs_Buttons_an... and I'm pretty sure May said there shouldn't be any shadow. This can be changed anytime though, so let's reach some agreement on Monday when she's back.
-- Juliusz
On 01/03/2014 07:31 PM, Jared Zimmerman wrote:
Overall they look good, a few notes and answers to your questions.
- The outer shadows seem to be missing, you can see them on http://33cc77.com/wikipedia/
Oh, OK. I thought it was a glitch.
1. The colors. I took them from https://www.mediawiki.org/wiki/File:Guide_Color.png but blue looks kind of dim. Blue, green an red also don't seem to have the same level of perceived lightness. Is that OK?I just checked the colors from Guide_Color.png and the button blue isn't there it should be #347BFF The other colors are spot on.
Will change.
2. Quiet buttons. I remember clearly from talking to May that we wanted them to be colored in their default state and make them slightly darker in hover. I don't remember what they were supposed to look like when disabled. Right now they're slightly lighter but maybe they should be all gray?Thats not quite right, unless May changes it the quite buttons should be black normally, their action color on hover, and the action color click state (darker version) on click. https://www.dropbox.com/s/amh0gfgc1p2i6c6/Screenshot%202014-01-03%2010.24.45... except for the neutral state which is normal:black -> hover:#747474 -> click:black
The change in colors is not documented anywhere, unfortunately. But I'm pretty sure they were meant to have color without hovering, at least because there is no hover state on mobile. Let's double check on Monday.
All of the disabled quiet state buttons should have the same text color as the background color of the primary disable buttons which i'm pretty sure is #BFBFBF
Quite possible, will change.
3. Focus state. Right now it's the same as hover state, but I'm afraid it might not be enough for people with poor vision or color-blind who use keyboard for navigation. Opinions?I think we should use the hover state for focus state (which is what you're doing) and suppress any browsers highlighting or borders (which is seems like you're also doing) So I think we're good to go there.
As I said, I'm not sure if this is accessible enough. But time will show.
- Quiet buttons. I remember clearly from talking to May that we wanted
them to be colored in their default state and make them slightly darker in hover. I don't remember what they were supposed to look like when disabled. Right now they're slightly lighter but maybe they should be all gray?
Thats not quite right, unless May changes it the quite buttons should be black normally, their action color on hover, and the action color click state (darker version) on click. https://www.dropbox.com/s/amh0gfgc1p2i6c6/Screenshot%202014-01-03%2010.24.45... for the neutral state which is normal:black -> hover:#747474 -> click:black
The change in colors is not documented anywhere, unfortunately. But I'm pretty sure they were meant to have color without hovering, at least because there is no hover state on mobile. Let's double check on Monday.
••
The only times when quiet buttons have color by default is when it's an action we want to emphasize. For example.. "Thank," or when going through a certain workflow, highlighting the next progressive action like "Next", especially when it's destructive like "Overwrite edit". These examples don't exist currently because we don't have a "Thank" action on Flow or do we use quiet buttons for progressive actions within workflows. But when we do, they will be colored. All other instances will be black.
Hope that made sense. Hope everyone had a great start to the year!
mm
On Mon, Jan 6, 2014 at 1:36 PM, May Tee-Galloway mgalloway@wikimedia.orgwrote:
- Quiet buttons. I remember clearly from talking to May that we wanted
them to be colored in their default state and make them slightly darker in hover. I don't remember what they were supposed to look like when disabled. Right now they're slightly lighter but maybe they should be all gray?
Thats not quite right, unless May changes it the quite buttons should be black normally, their action color on hover, and the action color click state (darker version) on click. https://www.dropbox.com/s/amh0gfgc1p2i6c6/Screenshot%202014-01-03%2010.24.45... for the neutral state which is normal:black -> hover:#747474 -> click:black
The change in colors is not documented anywhere, unfortunately. But I'm pretty sure they were meant to have color without hovering, at least because there is no hover state on mobile. Let's double check on Monday.
••
The only times when quiet buttons have color by default is when it's an action we want to emphasize. For example.. "Thank," or when going through a certain workflow, highlighting the next progressive action like "Next", especially when it's destructive like "Overwrite edit". These examples don't exist currently because we don't have a "Thank" action on Flow or do we use quiet buttons for progressive actions within workflows. But when we do, they will be colored. All other instances will be black.
When quiet buttons are colored by default, what color is it? If it's the same as the second row of https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Agora_Control_Lib..., then the button has no mouseover state, so we've improved mobile and degraded desktop.
Please add this to https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Agora_Control_Lib..., thanks. [1]
We have to name this new kind, is it mw-ui-quiet-colored instead of mw-ui-quiet, or another modifier style? class="mw-ui-button mw-ui-progressive mw-ui-quiet mw-colored-default" is getting a bit long.
Cheers.
[1] We have a big problem with out-of-date design documents, cf. * https://www.mediawiki.org/wiki/File:Agora_specs.pdf * https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Patterns_and_comp... * https://www.mediawiki.org/wiki/Style_guide If people won't update them we need to rename them all "2013 NN Design Proposal", and let the code comments that produce the living style guide be authoritative.
On 01/06/2014 11:01 PM, S Page wrote:
When quiet buttons are colored by default, what color is it? If it's the same as the second row of https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Agora_Control_Lib... , then the button has no mouseover state, so we've improved mobile and degraded desktop.
May didn't mention it here, but I remember her saying that the hover state color of quiet links should be like the active background color of normal buttons. Is this correct, May?
Please add this to https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Agora_Control_Lib... , thanks. [1]
We have to name this new kind, is it mw-ui-quiet-colored instead of mw-ui-quiet, or another modifier style? class="mw-ui-button mw-ui-progressive mw-ui-quiet mw-colored-default" is getting a bit long.
I think it's just mw-ui-quiet + mw-ui-progressive/constructive/destructive, right?
Just to be clear, default colored buttons aren't for every single destructive, progressive, and constructive actions. They are for buttons we want to emphasize especially in a workflow, for example, replying to a thread or editing articles. When quiet buttons are colored by default, it depends on the kind of action it takes. If destructive, red. Progressive is blue, constructive is green, which the colors are taken from the buttons' background colors.
On Mon, Jan 6, 2014 at 2:22 PM, Juliusz Gonera jgonera@wikimedia.orgwrote:
On 01/06/2014 11:01 PM, S Page wrote:
When quiet buttons are colored by default, what color is it? If it's the same as the second row of https://www.mediawiki.org/ wiki/Wikimedia_Foundation_Design/Agora_Control_Library#Buttons , then the button has no mouseover state, so we've improved mobile and degraded desktop.
May didn't mention it here, but I remember her saying that the hover state color of quiet links should be like the active background color of normal buttons. Is this correct, May?
Please add this to https://www.mediawiki.org/wiki/Wikimedia_Foundation_
Design/Agora_Control_Library , thanks. [1]
We have to name this new kind, is it mw-ui-quiet-colored instead of mw-ui-quiet, or another modifier style? class="mw-ui-button mw-ui-progressive mw-ui-quiet mw-colored-default" is getting a bit long.
I think it's just mw-ui-quiet + mw-ui-progressive/constructive/destructive, right?
-- Juliusz
On 01/06/2014 11:26 PM, May Tee-Galloway wrote:
Just to be clear, default colored buttons aren't for every single destructive, progressive, and constructive actions. They are for buttons we want to emphasize especially in a workflow, for example, replying to a thread or editing articles. When quiet buttons are colored by default, it depends on the kind of action it takes. If destructive, red. Progressive is blue, constructive is green, which the colors are taken from the buttons' background colors.
So we have a third kind of buttons as S said?
* normal * quiet * quiet with colors <- new
On 01/06/2014 05:26 PM, May Tee-Galloway wrote:
Just to be clear, default colored buttons aren't for every single destructive, progressive, and constructive actions.
When you say "default colored buttons", are you referring to "mw-ui-progressive/mw-ui-constructive/mw-ui-destructive" buttons in general, or are we exclusively talking about mw-ui-quiet here?
They are for buttons we want to emphasize especially in a workflow, for example, replying to a thread or editing articles. When quiet buttons are colored by default, it depends on the kind of action it takes. If destructive, red. Progressive is blue, constructive is green, which the colors are taken from the buttons' background colors.
As Juliusz and S said, we need to try to make the classes concise and relatively simple to remember. That ensures developers can easily use them, which helps consistency.
Matt Flaschen
On Mon, Jan 6, 2014 at 2:22 PM, Juliusz Gonera jgonera@wikimedia.orgwrote:
On 01/06/2014 11:01 PM, S Page wrote:
When quiet buttons are colored by default, what color is it? If it's the same as the second row of https://www.mediawiki.org/ wiki/Wikimedia_Foundation_Design/Agora_Control_Library#Buttons , then the button has no mouseover state, so we've improved mobile and degraded desktop.
May didn't mention it here, but I remember her saying that the hover state color of quiet links should be like the active background color of normal buttons. Is this correct, May?
But the active color is already using the active background color. If you make the hover use it too then we have a hover state but nothing happens on click. There's a best-selling book about distinguishing hover/active/disabled/toggled, "50 Shades of Grey" :)
So we have a third kind of buttons as S said?
- normal
- quiet
- quiet with colors <- new --
I'm confused too. May, are there quiet buttons that start gray and change color when you mouseover-click them, as shown in https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Agora_Control_Lib...
On Mon, Jan 6, 2014 at 2:47 PM, S Page spage@wikimedia.org wrote:
On Mon, Jan 6, 2014 at 2:22 PM, Juliusz Gonera jgonera@wikimedia.orgwrote:
On 01/06/2014 11:01 PM, S Page wrote:
When quiet buttons are colored by default, what color is it? If it's the same as the second row of https://www.mediawiki.org/ wiki/Wikimedia_Foundation_Design/Agora_Control_Library#Buttons , then the button has no mouseover state, so we've improved mobile and degraded desktop.
May didn't mention it here, but I remember her saying that the hover state color of quiet links should be like the active background color of normal buttons. Is this correct, May?
But the active color is already using the active background color. If you make the hover use it too then we have a hover state but nothing happens on click. There's a best-selling book about distinguishing hover/active/disabled/toggled, "50 Shades of Grey" :)
The bevel color when you hover over a button will be the hover state color of the quiet buttons. I have software issues on my side the entire day, hopefully it gets fixed next day so I can give you exact values of the bevel colors (or if Jared has it at hand) and then make changes to https://www.mediawiki.org/wiki/Wikimedia_Foundation_ Design/Agora_Control_Library#Buttons
So we have a third kind of buttons as S said?
- normal
- quiet
- quiet with colors <- new --
I'm confused too. May, are there quiet buttons that start gray and change color when you mouseover-click them, as shown in https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Agora_Control_Lib...
Let me get my software running again so I can ease your confusion here.
-- =S Page Features engineer
I see this in Chrome 31.0 and Safari 7, but not Firefox.
I see the same issue. I recall that a similar issue was due to a problem with CSSJanus. CSS Janus automatically swaps left and right values for some properties, but had problems on some rules such as box-shadow where the values provided do not correspond to "top right bottom left" but was interpreted by CSSJanus as such. Something similar could be happening here, but I have not found the specific rule that may cause the problem in this case.
Regarding button groups, the border between buttons seems too thick since it becomes the border of two buttons. A solution could be to make buttons inside the group to lack the left border (making the fist of them an exception). Similar to what it has been done with border-radius.
Pau
On Tue, Jan 7, 2014 at 7:46 AM, May Tee-Galloway mgalloway@wikimedia.orgwrote:
On Mon, Jan 6, 2014 at 2:47 PM, S Page spage@wikimedia.org wrote:
On Mon, Jan 6, 2014 at 2:22 PM, Juliusz Gonera jgonera@wikimedia.orgwrote:
On 01/06/2014 11:01 PM, S Page wrote:
When quiet buttons are colored by default, what color is it? If it's the same as the second row of https://www.mediawiki.org/ wiki/Wikimedia_Foundation_Design/Agora_Control_Library#Buttons , then the button has no mouseover state, so we've improved mobile and degraded desktop.
May didn't mention it here, but I remember her saying that the hover state color of quiet links should be like the active background color of normal buttons. Is this correct, May?
But the active color is already using the active background color. If you make the hover use it too then we have a hover state but nothing happens on click. There's a best-selling book about distinguishing hover/active/disabled/toggled, "50 Shades of Grey" :)
The bevel color when you hover over a button will be the hover state color of the quiet buttons. I have software issues on my side the entire day, hopefully it gets fixed next day so I can give you exact values of the bevel colors (or if Jared has it at hand) and then make changes to https://www.mediawiki.org/wiki/Wikimedia_Foundation_ Design/Agora_Control_Library#Buttons
So we have a third kind of buttons as S said?
- normal
- quiet
- quiet with colors <- new --
I'm confused too. May, are there quiet buttons that start gray and change color when you mouseover-click them, as shown in https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Agora_Control_Lib...
Let me get my software running again so I can ease your confusion here.
-- =S Page Features engineer
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
I don't think I can see the message to which you replied...
On 01/07/2014 12:06 PM, Pau Giner wrote:
I see this in Chrome 31.0 and Safari 7, but not Firefox.I see the same issue. I recall that a similar issue was due to a problem with CSSJanus. CSS Janus automatically swaps left and right values for some properties, but had problems on some rules such as box-shadow where the values provided do not correspond to "top right bottom left" but was interpreted by CSSJanus as such. Something similar could be happening here, but I have not found the specific rule that may cause the problem in this case.
Regarding button groups, the border between buttons seems too thick since it becomes the border of two buttons. A solution could be to make buttons inside the group to lack the left border (making the fist of them an exception). Similar to what it has been done with border-radius.
Pau
On Tue, Jan 7, 2014 at 7:46 AM, May Tee-Galloway <mgalloway@wikimedia.org mailto:mgalloway@wikimedia.org> wrote:
On Mon, Jan 6, 2014 at 2:47 PM, S Page <spage@wikimedia.org <mailto:spage@wikimedia.org>> wrote: On Mon, Jan 6, 2014 at 2:22 PM, Juliusz Gonera <jgonera@wikimedia.org <mailto:jgonera@wikimedia.org>> wrote: On 01/06/2014 11:01 PM, S Page wrote: When quiet buttons are colored by default, what color is it? If it's the same as the second row of https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Agora_Control_Library#Buttons , then the button has no mouseover state, so we've improved mobile and degraded desktop. May didn't mention it here, but I remember her saying that the hover state color of quiet links should be like the active background color of normal buttons. Is this correct, May? But the active color is already using the active background color. If you make the hover use it too then we have a hover state but nothing happens on click. There's a best-selling book about distinguishing hover/active/disabled/toggled, "50 Shades of Grey" :) The bevel color when you hover over a button will be the hover state color of the quiet buttons. I have software issues on my side the entire day, hopefully it gets fixed next day so I can give you exact values of the bevel colors (or if Jared has it at hand) and then make changes to https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Agora_Control_Library#Buttons So we have a third kind of buttons as S said? * normal * quiet * quiet with colors <- new -- I'm confused too. May, are there quiet buttons that start gray and change color when you mouseover-click them, as shown in https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Agora_Control_Library#Buttons ? Let me get my software running again so I can ease your confusion here. -- =S Page Features engineer _______________________________________________ Design mailing list Design@lists.wikimedia.org <mailto:Design@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/design-- Pau Giner Interaction Designer Wikimedia Foundation
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On 01/06/2014 10:36 PM, May Tee-Galloway wrote:
The only times when quiet buttons have color by default is when it's an action we want to emphasize. For example.. "Thank," or when going through a certain workflow, highlighting the next progressive action like "Next", especially when it's destructive like "Overwrite edit". These examples don't exist currently because we don't have a "Thank" action on Flow or do we use quiet buttons for progressive actions within workflows. But when we do, they will be colored. All other instances will be black.
Hope that made sense. Hope everyone had a great start to the year!
Thanks. One more though. Jared said that there should be shadow under the text, I recall that you told me not to add any shadow:
"The shadow is not here: https://upload.wikimedia.org/wikipedia/mediawiki/f/fe/Agora_specs_Buttons_an... and I'm pretty sure May said there shouldn't be any shadow. This can be changed anytime though, so let's reach some agreement on Monday when she's back."
It's not harder one way or the other, so it's up to you.
tl; dr: see core forms using new buttons at http://ee-flow-extra.instance-proxy.wmflabs.org/wiki/Special:UserLogin !
On Fri, Jan 3, 2014 at 10:00 AM, Juliusz Gonera jgonera@wikimedia.orgwrote:
Today I worked on finishing the new buttons styles. They're mostly done but I would like to clarify a few things. You can preview the current version by downloading https://www.dropbox.com/s/b1sn1x4slkwgqs9/buttons.zip
Excellent! I put patch 7 of Juliusz' https://gerrit.wikimedia.org/r/#/c/103494 on our labs instance, together with:
* A WIP patch that uses the new styles in Login, CreateAccount, and Special:PasswordReset (https://gerrit.wikimedia.org/r/#/c/104011/ )
* Latest Flow, try replying at < http://ee-flow-extra.instance-proxy.wmflabs.org/wiki/Talk:Sandbox%3E and compare its buttons.
* The living style guide, < http://ee-flow-extra.instance-proxy.wmflabs.org/w/resources/mediawiki.ui/doc...
* My left-hand nav hack that builds all the buttons, go to a non-special page like http://ee-flow-extra.instance-proxy.wmflabs.org/wiki/Main_Page , check mediawiki.ui, and then [Insert Agora buttons]
If you use .mw-ui-button on an <a href> hyperlink, it gets an unwanted underline; add .mw-ui-quiet and you see this underline on hover, e.g. http://ee-flow-extra.instance-proxy.wmflabs.org/wiki/Special:UserLogin
The existing mediawiki.ui/components/default/buttons.less has:
// This overrides an underline declaration on a:hover and a:focus in commonElements.css, which the // class alone isn't specific enough to do a.mw-ui-button { text-decoration: none; }
On Fri, Jan 3, 2014 at 10:00 AM, Juliusz Gonera <jgonera@wikimedia.org>wrote:
- Quiet buttons. I remember clearly from talking to May that we wanted
them to be colored in their default state and make them slightly darker in hover.
Yes, and I added that to < https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Agora_Control_Library#Buttons
but May's thinking was never put in the Flow mockups, or the Flow code. It's tricky because a row of Cancel Preview [Save] would turn into gray-blue-green multicolor, but without it there's no indication of the button type on mobile.
BTW latest Flow mockups have an "even quieter" design for Reply *·* Edit actions before you get a textarea with a quiet Cancel button and a CTA [Reply] button.
I think I kept this rule, didn't I? I'll double check. What browser was it?
On 01/04/2014 12:11 AM, S Page wrote:
If you use .mw-ui-button on an <a href> hyperlink, it gets an unwanted underline; add .mw-ui-quiet and you see this underline on hover, e.g. http://ee-flow-extra.instance-proxy.wmflabs.org/wiki/Special:UserLogin
The existing mediawiki.ui/components/default/buttons.less has:
// This overrides an underline declaration on a:hover and a:focus in commonElements.css, which the // class alone isn't specific enough to do a.mw-ui-button { text-decoration: none; }
On Fri, Jan 3, 2014 at 10:00 AM, Juliusz Gonera <jgonera@wikimedia.org <mailto:jgonera@wikimedia.org>> wrote:
2. Quiet buttons. I remember clearly from talking to May that we wanted them to be colored in their default state and make them slightly darker in hover.Yes, and I added that to <https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Agora_Control_Library#Buttons> but May's thinking was never put in the Flow mockups, or the Flow code. It's tricky because a row of Cancel Preview [Save] would turn into gray-blue-green multicolor, but without it there's no indication of the button type on mobile.
BTW latest Flow mockups have an "even quieter" design for Reply *·* Edit actions before you get a textarea with a quiet Cancel button and a CTA [Reply] button.
-- =S Page Features engineer
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Mon, Jan 6, 2014 at 11:11 AM, Juliusz Gonera jgonera@wikimedia.orgwrote:
I think I kept this rule, didn't I? I'll double check. What browser was it?
http://ee-flow-extra.instance-proxy.wmflabs.org/wiki/Special:UserLogin in Firefox and Chromium. But the kss.doc is fine, so it's some interaction with ResourceLoader and/or the CSS in other modules. I just noticed the background color doesn't darken on active, as if &:active { background: shade(@bgColor, 20%); } isn't working. According to my [Insert Agora buttons] generator a page like http://ee-flow-extra.instance-proxy.wmflabs.org/wiki/Main_Page doesn't load other UI classes, so I'm not sure what's going on. I'll look at it some more tonight.
I noticed that the new styles get messed up if I load them together with Flow styles so something probably clashes there.
On 01/06/2014 10:08 PM, S Page wrote:
On Mon, Jan 6, 2014 at 11:11 AM, Juliusz Gonera <jgonera@wikimedia.org mailto:jgonera@wikimedia.org> wrote:
I think I kept this rule, didn't I? I'll double check. What browser was it?http://ee-flow-extra.instance-proxy.wmflabs.org/wiki/Special:UserLogin in Firefox and Chromium. But the kss.doc is fine, so it's some interaction with ResourceLoader and/or the CSS in other modules. I just noticed the background color doesn't darken on active, as if &:active { background: shade(@bgColor, 20%); } isn't working. According to my [Insert Agora buttons] generator a page like http://ee-flow-extra.instance-proxy.wmflabs.org/wiki/Main_Page doesn't load other UI classes, so I'm not sure what's going on. I'll look at it some more tonight.
-- =S Page Features engineer
On Mon, Jan 6, 2014 at 1:08 PM, S Page spage@wikimedia.org wrote:
http://ee-flow-extra.instance-proxy.wmflabs.org/wiki/Special:UserLogin in Firefox and Chromium. But the kss.doc is fine, so it's some interaction with ResourceLoader and/or the CSS in other modules. I just noticed the background color doesn't darken on active, as if &:active { background: shade(@bgColor, 20%); } isn't working. According to my [Insert Agora buttons] generator a page like http://ee-flow-extra.instance-proxy.wmflabs.org/wiki/Main_Page doesn't load other UI classes, so I'm not sure what's going on. I'll look at it some more tonight.
Yeaaah. This definitely needs work. Some like Special:PasswordReset look usable, but I would not release login or create account as-is.
Issues I can see:
- On login, when using a RTL language like Hebrew or Arabic, the right button border is messed up somehow. See http://ee-flow-extra.instance-proxy.wmflabs.org/wiki/Special:UserLogin?usela... else see this? - The login form now has a mix of center-aligned and right-aligned elements. - On login secondary "Join" link is placed to left hand of the main submit button. That makes no sense considering I read left-right in English. Also, it needs to be an actual button, preferably a call to action, not a plain link. This is probably going to require a bit of a redesign to incorporate well. - The main submit buttons seems a bit small. Probably should apply mw-ui-big or something. Applying this in my console to create account seems to work fine across languages.
Thanks for sharing on Labs S. You're the best.
One other thing I notice: this style for mw.ui really begs use of placeholders instead of labels. Forms like Password reset etc. would look so much cleaner.
On 01/06/2014 05:28 PM, Steven Walling wrote:
- On login, when using a RTL language like Hebrew or Arabic, the right
button border is messed up somehow. See http://ee-flow-extra.instance-proxy.wmflabs.org/wiki/Special:UserLogin?usela... Anyone else see this?
No. Can you do a screenshot, and note the browser and version?
Matt Flaschen
On Mon, Jan 6, 2014 at 7:21 PM, Matthew Flaschen mflaschen@wikimedia.orgwrote:
On 01/06/2014 05:28 PM, Steven Walling wrote:
- On login, when using a RTL language like Hebrew or Arabic, the right
button border is messed up somehow. See http://ee-flow-extra.instance-proxy.wmflabs.org/wiki/ Special:UserLogin?uselang=he Anyone else see this?
No. Can you do a screenshot, and note the browser and version?
I see this in Chrome 31.0 and Safari 7, but not Firefox.
Screenshots: http://i.imgur.com/ON14sRM.png and http://i.imgur.com/yVEeYXM.png
Hm, funny. I was checking KSS in Chrome, so maybe that's another conflict with some other CSS. I'll investigate.
On 01/07/2014 05:05 AM, Steven Walling wrote:
On Mon, Jan 6, 2014 at 7:21 PM, Matthew Flaschen <mflaschen@wikimedia.org mailto:mflaschen@wikimedia.org> wrote:
On 01/06/2014 05:28 PM, Steven Walling wrote: - On login, when using a RTL language like Hebrew or Arabic, the right button border is messed up somehow. See http://ee-flow-extra.instance-proxy.wmflabs.org/wiki/Special:UserLogin?uselang=he Anyone else see this? No. Can you do a screenshot, and note the browser and version?I see this in Chrome 31.0 and Safari 7, but not Firefox.
Screenshots: http://i.imgur.com/ON14sRM.png and http://i.imgur.com/yVEeYXM.png
-- Steven Walling, Product Manager https://wikimediafoundation.org/
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On 01/07/2014 05:05 AM, Steven Walling wrote:
On Mon, Jan 6, 2014 at 7:21 PM, Matthew Flaschen <mflaschen@wikimedia.org mailto:mflaschen@wikimedia.org> wrote:
On 01/06/2014 05:28 PM, Steven Walling wrote: - On login, when using a RTL language like Hebrew or Arabic, the right button border is messed up somehow. See http://ee-flow-extra.instance-proxy.wmflabs.org/wiki/Special:UserLogin?uselang=he Anyone else see this? No. Can you do a screenshot, and note the browser and version?I see this in Chrome 31.0 and Safari 7, but not Firefox.
Screenshots: http://i.imgur.com/ON14sRM.png and http://i.imgur.com/yVEeYXM.png
Fix in: https://gerrit.wikimedia.org/r/105982 At least some custom styles for the login form are not needed with the updated button styles (white shadow is caused by the create account link).
tl;dr: Juliusz has improved button styles. Try them all on ee-flow-extra. Still some issues. One more hack day should do it!
Juliusz and May clarified a lot of stuff and he has a new patch that's closer. * The quiet buttons get lighter on mouseover (hover) and darker on click (active) * It adds a slight text shadow, other tweaks.
It's all on http://ee-flow-extra.instance-proxy.wmflabs.org/wiki/Special:UserLogin , together with the new living style guide, my button generator, and login forms using it, and latest Flow for comparison. The links are the same, repeated at the bottom.
*Still problems:*
* There's still some kind of glitch where on MediaWiki pages the background color doesn't darken on click.
* An <a href> with mw-ui-button mw-ui-quiet still gets a hyperlink underline on mouseover and click.
* The living style guide doesn't match what you see in MediaWiki, because Vector sets #bodyContent to 0.8em (This is why the separate living style guide doesn't work for desktop!)
*My comments:* Play with "A row of actions" in the living style guide[2] and the login form[3] as you read this.
* The text-shadow on colored quiet buttons makes them look fuzzy.
* In MediaWiki pages the form buttons are pretty small, just 12.8px. The login buttons in Flow are 14px tall.
* We need a class for a right-aligned row of buttons, "mw-ui-button-row" ?
* Buttons need some spacing when in a row. Flow gives its buttons a margin-left: 8px; , assuming they'll be in a right-aligned row; this could be applied to buttons that are children of the right-aligned mw-ui-button-row.
* The new styles implement white text on gray for the disabled colored (constructive, progressive, destructive) CTA buttons. This has been in the spec for months, and Flow never implemented it! I think it's confusing and jarring when you have two disabled buttons next to each other.
* In some thread Jared asked that the input focus indicator look like the mouseover state. I don't like that, and you can't find the input focus when it's on a quiet button because their mouseover state is a subtle change.
*Responses to Steven*: On Mon, Jan 6, 2014 at 2:28 PM, Steven Walling <swalling@wikimedia.org>wrote:
- On login, when using a RTL language like Hebrew or Arabic, the right
button border is messed up somehow. See http://ee-flow-extra.instance-proxy.wmflabs.org/wiki/Special:UserLogin?uselang=heAnyone else see this?
Seems OK now.
- The login form now has a mix of center-aligned and right-aligned
elements.
Yes in 2014 Agora, buttons are right-aligned and the main CTA is on the right. (I added this guideline to the living style guide.)
- On login secondary "Join" link is placed to left hand of the main submit
button. That makes no sense considering I read left-right in English.
Yup, that is an issue with quiet buttons.
Also, it needs to be an actual button, preferably a call to action, not a
plain link. This is probably going to require a bit of a redesign to incorporate well.
I think you're right. When should we use color and when should we use quiet buttons? In Flow when you type something into a reply box, you get Cancel [Preview] [Reply] quiet neutral - CTA neutral - CTA constructive Only the main call to action has a color even though Cancel is destructive and [Preview] is progressive. If we let the button colors match their semantics then the buttons would appear Cancel [Preview] [Reply]
In bug 57695 "Apply intuitive Agora styles to Flow buttons", Eduard Braun (is he on this list?) asked for the colorful look, saying all the gray buttons look alike. We have the option to be more colorful, just need to choose wisely.
- The main submit buttons seems a bit small. Probably should apply
mw-ui-big or something.
See my comment above, the buttons are smaller than in Flow. mw-ui-big is still around and I agree it would be nice to make the buttons stand out more.
I made these two changes to Login on ee-flow-extra[3]. When you're already logged in, the other button becomes [Create another account] and then the two buttons don't fit on one line, and because [Login] comes after it is pushed below the less important button.
Thanks for sharing on Labs S. You're the best.
One other thing I notice: this style for mw.ui really begs use of placeholders instead of labels. Forms like Password reset etc. would look so much cleaner.
There were technical issues with placeholder-only in 2013 (Matt Flaschen had a patch), and there's the concern that if you return to a form or your browser auto-fills a form field with previous data, then you have no idea what the field is for unless you blank it out.
*Links* As before ee-flow-extra labs instance has:
* Juliusz' patch updating mw-ui-button in core, https://gerrit.wikimedia.org/r/#/c/103494
* The patch that uses the new styles in Login, CreateAccount, and Special:PasswordReset (https://gerrit.wikimedia.org/r/#/c/104011/ )
* Latest Flow, try replying at < http://ee-flow-extra.instance-proxy.wmflabs.org/wiki/Talk:Sandbox> and compare its buttons.
* The living style guide, < http://ee-flow-extra.instance-proxy.wmflabs.org/w/resources/mediawiki.ui/docs/section-2.html
* My left-hand nav hack that builds all the buttons, go to a non-special page like http://ee-flow-extra.instance-proxy.wmflabs.org/wiki/Main_Page , check mediawiki.ui, and then [Insert Agora buttons]
[2] http://ee-flow-extra.instance-proxy.wmflabs.org/w/resources/mediawiki.ui/docs/section-2.html [3] http://ee-flow-extra.instance-proxy.wmflabs.org/wiki/Special:UserLogin
I think Jared and May concluded that quiet buttons start out gray and reveal any constructive/progressive/destructive color on hover and active. This is implemented in patch set 10, installed on http://ee-flow-extra.instance-proxy.wmflabs.org/wiki/Special:UserLogin(plus all the other URLs on that instance).
I also hacked in the darken behavior on MediaWiki (lessphp doesn't implement shade and tint!), and removed the hyperlink underline on mouseover and click.
I think that's it for technical issues. If so we're ready for a FINAL button meeting where we agree on this button set for Login/Create account, PasswordReset, Flow, and the few other extensions using it. No extraneous topics, no new ideas, just sign off on what we have and +2 the two gerrit patches.
Cheers, -- =S Page Features engineer
one last tweak for the quiet state buttons, the text should NOT have a shadow in this state. it looks like on http://ee-flow-extra.instance-proxy.wmflabs.org/wiki/Special:UserLogin the quiet state button has a shadow which make the text not look sharp.
What is the best way to see all of the states of the mediawiki.ui buttons in all of their states?
Otherwise I think we are really close.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Fri, Jan 17, 2014 at 10:55 PM, S Page spage@wikimedia.org wrote:
I think Jared and May concluded that quiet buttons start out gray and reveal any constructive/progressive/destructive color on hover and active. This is implemented in patch set 10, installed on http://ee-flow-extra.instance-proxy.wmflabs.org/wiki/Special:UserLogin(plus all the other URLs on that instance).
I also hacked in the darken behavior on MediaWiki (lessphp doesn't implement shade and tint!), and removed the hyperlink underline on mouseover and click.
I think that's it for technical issues. If so we're ready for a FINAL button meeting where we agree on this button set for Login/Create account, PasswordReset, Flow, and the few other extensions using it. No extraneous topics, no new ideas, just sign off on what we have and +2 the two gerrit patches.
Cheers,
=S Page Features engineer
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Fri, Jan 17, 2014 at 11:14 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
one last tweak for the quiet state buttons, the text should NOT have a shadow in this state.
Yup, fixed in patch set 12.
What is the best way to see all of the states of the mediawiki.ui buttons
in all of their states?
Use my jQuery button inserter. Visit http://ee-flow-extra.instance-proxy.wmflabs.org/wiki/Main_Page , in the left-hand nav check 'mediawiki.ui.button' to load the CSS, then click [Insert Agora buttons].
Because the vertical form stack and Flow (and Typography refresh?) adjust the font size, there's no substitute for trying every page using Agora.
Cheers,