JxRath
commented
10 years ago Will Review by Jan 31
Open rubinahaddad opened 10 years ago
JxRath
commented
10 years ago Will Review by Jan 31
JxRath
commented
10 years ago Buttons: http://wet-boew.github.io/wet-boew-styleguide/new/design/buttons-en.html
A. Please indicate which devices were tested (Desktop/Mobile/Tablet): IE Windows 8.0.7601.17514, HP Desktop, Dell widescreen monitor (1920x1080) Apple iPhone 4, latest iOS 7
B. Provide status feedback
Default Appearance IE 8: In IE 8 the Default appearance renders a much nicer button, especially the first example.
IE 8 Oddness: When the Browser window is not the active window, the button appearance changes on the page. (See: “Not Active Window” & “Active Window” below)
Not Active Window: There is a light gradient with a 1px black border, with a 1px white inset line. The button does have slightly rounded corners which help make it apparent that this is a button.
Active Window: When the Browser page is selected and is in use, the button is the same as above but the Border is a 1px Black border with a 1px CYAN inset line.
On Roll-over the cursor changes from a pointer arrow to a hand with index finger extended, and the color of the box changes from the grey gradient to a light blue gradient with a 1px mid-blue border with a 1px white inset line which indicates the roll-over state.
On-Click the button changes color to a darker blue gradient, and a 1px mid-grey inset border. The text style remains the same but moves down and to the right by 1px
Default Appearance iOS 7: In iOS 7 the Default buttons are identical lozenge shaped buttons with a light gradient. While they look good they do not function…Bug?
Button Basics IE 8: In IE 8 the button style does not render “nicely”. The “Button Basics” shows a plain white box surrounded by a 1px light grey line with square corners. At first glance there is nothing about the appearance that looks like a button. It is a word in a box.
On Roll-over the cursor changes from a pointer arrow to a hand with index finger extended, and the color of the box changes from white to light grey and the 1px border becomes a darker grey. The change in roll-over state is a web convention.
On Click the border of the button becomes a 1px black line with a 1px grey line inside it. The color of the button does not change from the roll-over state. The text size and style remains consistent, but moves down and to the right by 1px indicating the down or “pressed” state.
After clicking a button in IE 8 sometimes the black border remains instead of reverting to grey. This may be by design; indicating a pressed state? … Bug?
Button Basics iOS 7: The button shape in iOS7 is a flat white box with slightly rounded corners. There is no roll-over effect, and the button remains grey (looks greyed-out) after it has been clicked. … Bug?
This style in iOS will cause accessibility issues as it blends into the background too much and will not be apparent to people with mild forms of visual impairment. The 1px grey border is also much lighter than the darker grey border used in iOS 7 (see example of white button in App Store application)
IE 8: If the user knows that the object is a button, and interacts with it, the roll-over and on-click states provide immediate and standard button behavior feedback.
iOS 7: The “Basic” Default style is conforming well with the new flat UI for iOS7, but the white treatment should not be used. At the smaller sizes on the iPhone screen the button blends into the background too much. Also if anything other than the “Large” size is used in iOS7 the target is too small for the finger press, unless the user zooms in substantially.
IE 8: No. The button in its normal state does not give the natural appearance of a button. There is currently a visual trend towards “flatness” of UI elements. There are a number of other elements in the WET which can be confused with buttons (alert boxes, headers, notes) due to the lack of gradient in the button style. We can still have a clean and simple button style that would not look out of place in the WET, but would have the appearance of being more of a “clickable” object.
iOS 7: Yes – Except for the white on white button with the light grey 1px border. iOS 7 has adopted a very flat-looking UI so that the colored buttons more or less match that style, with size of the button possibly being the only issue. iOS 7 also uses a darker grey line that helps to better define the button border.
IE 8 Button element: Yes & No. Roll over and on click visual treatments appear when the user interacts with the button. If the user does not interact with the button there in no indication that it is clickable.
IE 8 Anchor element: No. No roll-over or on-click visual treatments appear when the user interacts with the anchor. It also does not appear to be a clickable element.
IE 8 Nesting – Dropdown: Yes. There is a small black downward pointing triangle on this button type to indicate that more elements/selections may appear if the button is clicked. The example show does not expand in IE 8…not sure if this is lack of information in the coding example or Bug?
IE 8 Vertical Variation: Yes & No. This is shown as a series of white horizontal bars, some with the word “Button” and some with the word “Dropdown” accompanied by a small black downward pointing triangle. The Button does not appear to be clickable unless the user rolls over it with the cursor. The Dropdown with arrow hints at more data to display, but does not do anything in IE 8…not sure if this is lack of information in the coding example or Bug? Also in IE 8 the “buttons” span the full width of the page and look more like accordions. In iOS 7 the buttons remain a reasonable size and do not span the page so this is likely an IE 8 Bug.
IE 8 Justified Link Variation: Yes & No. Roll over and on click visual treatments appear when the user interacts with the button. If the user does not interact with the button there in no indication that it is clickable. In IE 8 the word exceeds the size of the button, bleeding out to the right of the button this is likely a Bug as is renders differently in iOS 7.
IE 8 Single Button Dropdowns: Yes. There is a small black or white downward pointing triangle on this button type to indicate that more elements/selections may appear if the button is clicked. The example shown does not expand in IE 8…not sure if this is lack of information in the coding example or Bug? There may be an issue with the code here as in IE 8 the 6 buttons in the example are stacked vertically, while in iOS 7 the buttons are arranged in 1 horizontal row.
IE 8 Split Button Dropdowns: Yes. There is a small black or white downward pointing triangle on this button type to indicate that more elements/selections may appear if the button is clicked. The example shown does not expand in IE 8…not sure if this is lack of information in the coding example or Bug? There may be an issue with the code here as in IE 8 the 6 buttons in the example are stacked vertically, while in iOS 7 the buttons are arranged in 1 horizontal row. Also the buttons do not render correctly. The “split” part of the button with the arrow is not the same height as the button next to it and it looks bad.
IE 8 Dropup variation: Yes. There is a small black or white downward pointing triangle on this button type to indicate that more elements/selections may appear if the button is clicked. The example shown does not expand in I E8…not sure if this is lack of information in the coding example or Bug? Also the buttons do not render correctly. The “split” part of the button with the arrow is not the same height as the button next to it and it looks bad.
C. Match real world conventions
IE 8: No. it is not necessarily easily recognizable. Due to the flat-looking button style we are currently using, the Button may be confused with a header or alert. There may not be enough to distinguish them visually. IE 8 does not render the rounded corners on the buttons, so there is little difference (other than possibly length) between a Button, an Alert or a section header except when you roll-over it.
iOS 7: No. The button is too flat to match “real-world” conventions. In the “real-world” buttons, even if they are flat, have some sort of edge treatment, shadow or visual gradient caused by being 3D that separates them from the background and makes them look clickable. The rounded corners and treatment we are using does match the flat UI direction taken by iOS 7, if the sizing of the buttons is large enough to make a good fingertip target area without having to zoom in.
IE 8 Button Element: Yes. There are roll-over and on-click styles that conform to expectations of button behaviour on the web.
iOS 7 Button Element: Yes. There is an “on-click” state change but the more subtle “on-touch” behaviors are not there. This is not a large concern and is generally consistent with iOS buttons.
IE 8 & iOS 7 Anchor Element: No. It looks like a button but the interaction is different. See note in #D1.
IE 8 & iOS 7 Nesting Element: Yes. There are roll-over and on-click styles that conform to expectations of button behaviour on the web. However, the Dropdown button does not work in IE 8 or iOS 7…Bug or lack of coding in the example?
IE 8 & iOS 7 Vertical Variation: Yes. There are roll-over (IE 8) and on-click (IE 8 & iOS 7) styles that conform to expectations of button behaviour on the web. However, the Dropdown button does not work in IE 8 or iOS 7…Bug or lack of coding in the example?
IE 8 Justified Link Variation: No. Bug in IE 8. Roll-over works, On-Click does not, and sizing of buttons is broken. Buttons render as square instead of rectangular and the words in the button bleed out to the right of the element.
iOS 7 Justified Link Variation: No. On-Click effect does not work, but unlike IE 8 the sizing of buttons seems to be as intended.
IE 8 & iOS 7 Single Button Dropdowns: Yes. There are roll-over and on-click styles that conform to expectations of button behaviour on the web. However, the Dropdown button does not work in IE 8 or iOS 7…Bug or lack of coding in the example?
IE 8 & iOS 7 Split Button Dropdowns: Yes. There are roll-over (IE 8) and on-click styles (IE 8 & iOS 7) that conform to expectations of button behaviour on the web. However, the Dropdown button does not work in IE 8 or iOS 7…Bug or lack of coding in the example? Also there is a bug in IE 8 as the part of the button with the arrow in it does not match the height of the button body. This is fine in iOS 7
IE 8 & iOS 7 Dropup Variation: Yes. There are roll-over (IE 8) and on-click styles (IE 8 & iOS 7) that conform to expectations of button behaviour on the web. However, the Dropdown button does not work in IE 8 or in iOS 7…Bug or lack of coding in the example? Also there is a bug in IE 8 as the part of the button with the arrow in it does not match the height of the button body. Also in IE 8 the size of the arrow in the button is much smaller than the arrow size used in the other dropdown examples. The Arrow size renders fine in iOS 8.
D. Apply standards and ensure consistency
IE 8 Basic Example: No. While there is a visual trend towards “flatness” in UI design, the current Basic button style has gone too far in this direction and has lost all appearance of being a button, especially in IE 8 since it does not render the rounded corners on the button.
IE 8 Anchor Element: No. This usage that looks like a button but acts as a link should be removed. There is no roll-over on on-click states. The user might think that the button is broken as it does not conform to other button behavior. A button is a button; a link should look like a link.
Not really; there are currently 4 sizes of buttons being proposed, with 6 color options which can lead to 24 different button styles. Also see the note in #D1 concerning the “Anchor element”
The “Default” button is a white button with a 1pxlight grey border used on a white background. This default style will cause accessibility issues as there is not enough of a difference between the button and the background it sits within. If you squint at this button style, the grey border practically disappears from view. Buttons are generally required to complete or initiate an action or process. They are important elements and should stand out on a page and not completely blend in. See Squint test details at: http://blog.usabilla.com/the-squint-test-how-quick-exposure-to-design-can-reveal-its-flaws/
The mid-blue “Primary” button has enough contrast from the background, but again, is so flat that it does not look like a button. Also Default and Primary are synonyms – when should each style be appropriately used?
The color options (Green/Success, Cyan/Info, Orange/Warning Red/Danger) should be dropped for the sake of consistency, unless compelling examples can be shown where these styles would be necessary and the Primary button style would be insufficient.
The “Full width buttons” That span the width of the parent are definitely going to be confused with other elements in WET like headers and alerts which can span the width of the parent. They may be appropriate in some mobile applications where the button text is long, but should not be used on normal web pages.
In IE 8 the “Disabled state” for the button element does (as noted) “render text gray with a nasty text-shadow that we cannot fix” In addition to this issue the interaction when the user mouses over the button is inconsistent with the Disabled Anchor element.
IE 8 Disabled Button Behavior: When the user mouses over the disabled Button text the cursor changes to an “I” beam text editing cursor, and does not change from an arrow when over the body of the button. iOS 7 Disabled Button Behavior: Button just acts disabled – no effects occur when clicked.
IE 8 Disabled Anchor Behavior: When the user mouses over any part of the disabled Anchor, the cursor changes to a red circle with a diagonal line through it.
iOS 7 Disabled Anchor Behavior: Button just acts disabled – no effects occur when clicked.
Button text should follow a writing style, with an approved list of standard button names.
No; In the examples provided the button size varies; it can be a “normal” size that is dependant on the text length in the button – or it can span the full page. There is also the behavior where a horizontal button row can turn into a vertical stack of buttons as the page width decreases. This may cause some confusion depending on the page content or application.
E. Help users recognize, prevent and recover from errors
No; the white button on a white background may cause errors and acessibility issues. The buttons should also have some sort of style that makes it look more like a button.
If the Button is not coded or linked correctly it will not work. There is no recovery from this other than perhaps logging the issue through a “Feedback” mechanism.
No.
F. Design for human interaction
a. Is the layout/style intuitive?
The layout of the text in the button is intuitive (as long as the text is short and descriptive of the function) In IE 8 the style of the button is not intuitive, as it does not look like a button.
Groups and Toolbars The layout of groups and toolbars do not format well on narrow pages. Instead of remaining in a horizontal line the elements are bumped to the next line and “Stack up” vertically instead of remaining horizontal. The advantage is that the element remains on the screen and is still actionable. The disadvantage is that the stacking is ugly, and if the order of the buttons in the group is important, that order is now mixed.
b. Are the interactions intuitive?
Yes; for the button element. There are roll-over and on-click styles that conform to expectations of button behaviour on the web.
No; for the Anchor element. It looks like a button but the interaction is different. See note in #D1.
Yes.
N/A
G. Keep it simple
Yes; the button message provides feedback or instruction which would guide the actions of the user if written correctly following writing style guides and a standard set of common button names.
Yes; Normal button state, roll-over state, on-click state, disabled state.
See #G1
LXP122
commented
10 years ago CRA will review.
rubinahaddad
commented
10 years ago @LXP122 are you able to complete this by Friday?
LXP122
commented
10 years ago Yes. Targeting this Friday.
From: Rubina Haddad [mailto:notifications@github.com] Sent: January-27-14 2:23 PM To: wet-boew/wet-boew-styleguide Cc: Patterson, Lowell Subject: Re: [wet-boew-styleguide] Heuristic evaluation - Buttons (#26)
@LXP122https://github.com/LXP122 are you able to complete this by Friday?
— Reply to this email directly or view it on GitHubhttps://github.com/wet-boew/wet-boew-styleguide/issues/26#issuecomment-33410681.
LXP122
commented
10 years ago Yes
Thank you / Merci! Nathalie Savard Tel.: 613-941-9363 NEW | Fax: 613-954-9222 Visit the Usability Resource Center sitehttp://infozone/english/r2424161/solutions/bpagol-peagel/dc-ce/org2/urc-e.asp Learn about Usability and User Interface Designhttp://infozone/english/r2424161/solutions/bpagol-peagel/dc-ce/org2/uidu-e.asp Design & Development Centre - Centre de la conception et du développement System Engineering and Development Support Division - former Development Center Solutions Architecture and Integration Directorate - former BPA and GOL directorate Solutions, ITB, CRA / DGI, ARC From: Jakob Nielsen’s Alertbox: February 17, 2013 “It’s much better to bake-in usability from the very start—before you’ve even begun to design anything—than it is to wait until there’s a near-final design and then subject it to “validation” in user testing. Early focus on usability also vastly boosts ROI http://www.nngroup.com/articles/usability-roi-declining-but-still-strong/ ; it’s 100 times cheaper to fix a design flaw on the drawing board than after product launch.”
From: Rubina Haddad [mailto:notifications@github.com] Sent: January 27, 2014 2:23 PM To: wet-boew/wet-boew-styleguide Cc: Patterson, Lowell Subject: Re: [wet-boew-styleguide] Heuristic evaluation - Buttons (#26)
@LXP122https://github.com/LXP122 are you able to complete this by Friday?
— Reply to this email directly or view it on GitHubhttps://github.com/wet-boew/wet-boew-styleguide/issues/26#issuecomment-33410681.
matyeo
commented
10 years ago Mike Atyeo (Neo Insight) will review: Buttons - Android - Mobile - Firefox Target date: 5Mar14
ballantr
commented
10 years ago Roy Ballantine (Neo Insight) will review: Buttons - Android - Tablet - Chrome Target date: 5Mar14
matyeo
commented
10 years ago Samsung Galaxy S2 Android 2.3.3 Firefox 27.0
No.
The basic button design does not give enough cues that the widget is an active component, focused on actions (e.g. ‘Buy now’) rather than navigation. It may be that the widget names in WET do not bear a relationship to usage requirements, but it would seem that distinctions relating to usage (as opposed to technical implementation) are critical for usability. This may only be resolved in usage guidance, but the existence of certain technical capabilities (nesting, vertical stacking etc) suggests that the ‘button’-like behaviour may be over-extended. It may be more powerful for usability of the WET library if certain classes of components have restricted variants. For example, buttons may be restricted to constrain nesting and stacking.
The current design for buttons will be difficult to distinguish from CSS variants on navigation components such as links, menu-bars, tabs and pills, and may also be confused with inactive components such as headers, separators, alerts and other block colours in authored page content.
A ‘primary’ button in its inactive state has its colour 50% faded back. This may still be mistaken for an active button, especially if there are ‘secondary’ disabled buttons nearby. Recommend: Even if a button is ‘primary’, use a greyed-out state when disabled.
Mostly, in that buttons have all required states, and respond appropriately to user actions. However, on mobile devices, active items under the user’s finger-tips will often not be visible, or may only be partially visible. There is also no ‘hover’ functionality for touch devices. The current ‘active’ highlighting may easily be missed on a mobile device, and should be clearer. Highlighting should also stay on longer so that it may be seen when the user removes their finger-tip, until the action takes place.
Yes, with caveats as described above.
N/A
Buttons as described do not match their physical world counterparts. While this is not always desirable, in the case of ‘buttons’, there may be more value gained from a real-world-like visual representation – i.e. shading, etc., configuration and behaviour, than from non-button like behaviour that can be met with other navigational elements.
Certain capabilities as described will reduce the stimulus-response power of a ‘button’. For example, extending buttons to the full width of a block or a page will make them less likely to be immediately recognized as ‘buttons’, and more likely to be confused with static page content.
Yes.
To some extent. It may be too early to say to what extent there are industry standards just yet.
Yes.
Yes.
No. Button sizes do not scale well as touch targets on mobile devices. Note that the Bootstrap original documentation seems more successful in this respect.
There seems to be a display problem with Samsung Galaxy S2, Android 2.3.3, Firefox 27.0 – see first button below:
This may be the Firefox bug referred to in the documentation.
The touch target size is too small for smaller button sizes; this will generate user errors.
N/A
N/A
Yes, insofar as it implements industry and de facto standards and meets users’ expectations.
Yes, insofar as it implements industry and de facto standards and meets users’ expectations.
Yes, except for touch target size.
N/A
Yes.
Yes.
Yes.
matyeo
commented
10 years ago Image for: There seems to be a display problem with Samsung Galaxy S2, Android 2.3.3, Firefox 27.0 – see first button below... This may be the Firefox bug referred to in the documentation.
ballantr
commented
10 years ago https://github.com/wet-boew/wet-boew-styleguide/issues/26
| Device | OS | Browsers |
|---|---|---|
| Windows 8.1 | Laptop (24 inch Monitor) | Chrome 33.0.1750.117 m |
| Android 4.3 | Nexus 7 | Chrome 33.0.1750.136 |
Yes, except that some buttons in some states are not distinct enough. See below.
For the most part yes.
The Nexus tablet buttons highlight quickly when you click them, but the highlighting from other active buttons is removed rather slowly. This delay is very noticeable.
Viewed in isolation, buttons in the active state could be confused with buttons in the inactive state. Increased shading at the top and/or to the left side of the bottom may help this problem. This is particularly true for the colored buttons.
On the small screen, disabled buttons with white background are not easy to distinguish from white background buttons in the enabled state.
I recommend adding some more space between the caption and the drop down arrow on drop down buttons to create more visual separation.
The split line is not at all obvious on the colored Split button dropdowns. Particularly on small screens. Darker lines would help.
Not applicable.
Yes, except that mixing drop-down buttons with other buttons in button groups seems into this reviewer to be a little strange and unusual.
Yes.
That drop-up buttons are highly unusual and I recommend against their use.
The huge number of options, however, is a problem for an enterprise solution. It would be much better to limit the options for colors or dropdown styling etc., or to provide very clear guidance of how and when to use each.
No. The rendering of active buttons in button groups is different from that specified for active state buttons. Note the shading differences on the “4” and the “Button” buttons.
Button groups:
Active state specification:
Yes.
No. When viewed in isolation it is hard to tell that a white background button is disabled.
When viewed on the 7 inch Nexus screen line above some of the buttons in button groups is not visible. The image below is a rendering of what I see on the Nexus screen at standard size.
Not applicable.
Not applicable
Not applicable
Yes
Yes
yes
N/A
Yes
Yes
N/A
ballantr
commented
10 years ago | Device | OS | Browsers |
|---|---|---|
| Laptop (24 inch Monitor) | Windows 8.1 | FF 27.0.1 |
| Nexus 7 | Android 4.3 | Chrome 33.0.1750.136 |
| HP Desktop, Dell widescreen monitor (1920x1080) | Windows 8.0.7601.17514 | IE |
| Apple iPhone 4 | latest iOS 7 | |
| Samsung Galaxy S2 | Android 2.3.3 | Firefox 27.0 |
dravas-nat
commented
10 years ago FYI: we (CRA-ITB) tested for contrast the proposed button colours in WET4 using a Colour Contrast Analyser tool and only the Default button passed the contrast test. All the other colours failed the test – even the Primary blue action button with white text.
all other colored command buttons did NOT pass the contrast test either.
CRA-ITB
ballantr
commented
10 years ago @dravas-nat Wow! Interesting test.
Another consideration, however, is the contrast of the button background to the page background. If you know something is a button (and if you are looking for a button) then you might be willing to struggle with poor contrast for a word or two. However the "Default" button does not "pop" out of the background - particularly on small screens and low contrast screens. You may not know it is a button!
JxRath
commented
10 years ago Actually the "Default Button" failed the test. It may be internally OK when you test the text as 315173 and the button color as EFEBEF. When you test it against the background that it will be sitting on - ususally a white page - then you have to test EFEBEF (grey button) against FFFFFF (white backgrond) and it fails.
JxRath
commented
10 years ago Just as an FYI there is an online equivalent of the color contrast tool at: http://snook.ca/technical/colour_contrast/colour.html
rubinahaddad
commented
10 years ago Thanks @dravas-nat . As discussed @thomasgohard is looking to change those.
@JxRath @ballantr Does the background of the button and the background page colour really need a sufficient contrast colour in order for user's to see it? I agree that the white bg was very odd, and that user's might not think it’s a button, but I don’t think users would miss grey buttons. The grey button has been a default standard for as long as I remember...
JxRath
commented
10 years ago @rubinahaddad As a best practice the button should be very visually distinct from the background and it should look like a button, not a flat shape. There have been many studies done on this topic. Grey buttons have indeed been around a long time, and were born in the era of greyscale monitors. We can do better; technology and countless button studies have advanced UX significantly since then.
The new problem introduced by making the white button grey is that people now consider some grey buttons to be non-functional (greyed-out) especially if used in conjunction with colored buttons. That’s why the Twitter Bootstrap people are refusing to adopt the grey button as a default.
The grey or white button should be removed entirely from the options available. White would only work on a dark background. As an aside, I’ve found a useful color contrast tool that will help choose color combinations that will work, instead of just telling you what won’t. http://contrast-a.dasplankton.com/
pjackson28
commented
10 years ago @JxRath That is not why Twitter Bootstrap is not making the change, it is because the lead guy prefers the look of white and because he's trying to make it design neutral to avoid imposing CSS that requires overrides (despite the fact that the white is imposing CSS which needs to be overridden). Don't read into it any more than that as they are often are not swayed by accessibility and usability arguments as the reason they still have contrast issues with the buttons is because the lead guy doesn't like the look of the buttons when there is sufficient contrast (which is his choice as lead of the framework).
As for outlawing grey buttons, grey is the browser default, and will continue to be the browser default for a long time to come. You put in <input type="submit" /"> or <button>Default button</button> then you get a grey button, even in the most modern browsers. If you add the disabled attribute, then the browser makes it look and behave disabled. Considering how widely grey buttons are used across the Web, I,m finding it hard to believe that people are not able to tell when a grey button is not disabled. Do you have any data that supports your suggestions?
Thank you for the link by the way, that is an interesting tool.
dravas-nat
commented
10 years ago @pjackson28 @JxRath @rubinahaddad : Consider the following color contrast for the Default command button: it is much easier on the eyes, still works well on a white page background and could be grayed out to indicate a disabled command. It passes the color contrast well.
JxRath
commented
10 years ago @pjackson28 The Twitter Bootstrap lead @mdo? There were some exchanges on coding but he specifically said: "Yeah I hear all that. A gray button will solve this particular problem, but introduce another—the button will always look disabled. There's no magic solution here that solves everything for the "default" button. I don't see much to act on here." And also "Thanks, but we won't be changing it. Making it gray just causes another problem that folks will complain about. We'll leave it as-is."
I just happen to agree with him; I'm a contributor not a lead - do what you'd like.
I'm aware that the "input submit" button is grey, but if it was so great why do most sites go out of their way not to use it and design custom buttons? In fact the tool I recommended at http://contrast-a.dasplankton.com/ uses grey buttons in their UI. I'm not saying all grey buttons are bad; it depends on context, audience, application standards - and a host of other factors. Sometimes you want the buttons to fade into the application chrome, and sometimes you don’t. On that page you'll also notice the button that he really wants people to use (the "Donate" button) has the most color and contrast on the dark grey background he uses.
The data on whether the grey (or white) button is a good one comes from the Accessible Color Contrast tool. Light buttons on light backgrounds do not work well. If the light grey button was on a black background it would definitely stand out, in the proper context it may not be perceived as greyed out. For Data to support good button design look at the recommendations made by Neilson/Norman or use google; there are hundreds of articles on good button design.
The colors suggested by @dravas-net work, but I’m surprised that the color combination of the Canada.ca header bar wasn’t considered as a good combination for buttons as well. Ideally well designed websites choose a color palette for the site and the controls and try to stick with it. If you’re trying to design a framework for many different sites to use, for other WET releases you might want to consider various color themes and combinations for people to choose from.
pjackson28
commented
10 years ago @JxRath We're happy to have you as a contributor and welcome the discussion, its just it is a really major shift to tell people to stop using grey buttons when they are still widely used and are the default buttons for all browsers.
On the contrast front, one thing to consider is that the default buttons normally have much darker borders (almost black) and even a darker grey for the background allowing it work well across multiple backgrounds (dark or light) since there is significant contrast through either the border, the button colour, or both. One of the weaknesses we have with the current buttons is the lack of a strong border colour making it easier to lose a grey button on a white background as the border and button background bleed together which then bleed into the white background. Should we be making are borders a more pronounced colour (in comparison to the button colour) like with true default buttons to help address the issue? Even with the colour scheme proposed by @dravas-nat, it can be vulnerable to certain backgrounds due to the border and button colours being relatively close.
JxRath
commented
10 years ago @pjackson28 Darker borders and divider lines were one of the recommendations in the heuristic evaluations above and it would help improve the button style.
pjackson28
commented
10 years ago @JxRath What border colours would you recommend for each of the buttons? Even with the current coloured buttons, they are very vulnerable to variations in the background colour so would benefit contrast-wise with better borders. Ideally we can find border/button combinations that are still visually attractive while achieving the required contrast.
rubinahaddad
commented
10 years ago Regardless of the button colour, if the border colours were changed to create better contrast levels, do you guys think this would satisfy the # 2 recommendation?:
"All reviewers reported that many of the buttons, particularly the Basic buttons, are not sufficiently clearly buttons (particularly in IE 8 and iOS 7) which may result in general usability problems and accessibility problems. This came up in all reviews, repeatedly. “…” The reviewers were congnisant of the fact that there is a trend to flat UIs – but the consensus was that many of these buttons have gone too far, and look like simple alert boxes."
thomasgohard
commented
10 years ago How's this?
Default 5% borders
Darker 20% border (except for default style which isn't implemented like the other buttons and will require more work)
ballantr
commented
10 years ago I find the darker border helps - but the default button is the real problem. A darker border would help it a whole lot in my opinion.
There has been quite a lot of discussion to the effect that 'grey buttons are the default color in the browsers today, and so why is it a problem all of a sudden?' I have a few thoughts:
thomasgohard
commented
10 years ago What about something like this?
JxRath
commented
10 years ago @thomasgohard They are starting to look more like buttons. I agree with @ballantr about adding some texture/gradient to the body of the button as well. The edge treatment you added does help raise them off the background thereby adding some button affordance. I'm not advocating a return to the glowing glossy plastic look of a few years ago, but would you think the treatment of apple's header bar is too 'glossy' or is it understated enough? Also take a look at the gradient in Apple's blue button on their "Store" page. Enough so the buttons don't look flat. Not enough so they look like they're plastic or glowing.
pcwsmith
commented
10 years ago @thomasgohard I think I prefer the darker 20% border from the previous. Achieves the effect in a simpler way. I did notice in a quick search that many buttons are using effects like these to get the raised look: http://patterntap.com/pattern/payment-smartcar
pcwsmith
commented
10 years ago @JxRath @thomasgohard Apple's menu bar is too shiny IMO - we don't have any of that on Canada.ca.
pcwsmith
commented
10 years ago menu choice buttons on the www.canada.ca language choice page have a raised effect. funny never noticed before. maybe too subtle.
pjackson28
commented
10 years ago We'll need to be very careful about what extra CSS effects we add to buttons as some of them, especially gradients, can be very expensive performance-wise, especially on mobile devices. It is important to strike a balance to ensure we don't inadvertently make the experience sluggish when trying to make the buttons more button-like.
As for grey buttons, there may be more colour variety nowadays to accommodate branding requirements, to help identify primary actions and such but grey buttons are still common in various locations including:
So I agree that we are no longer awash in a sea of grey buttons but at the same time we haven't moved on from them either.
pjackson28
commented
10 years ago I should also mention that in all the grey buttons I saw, it was far more common to see black or dark grey text than blue text. I didn't see grey buttons with blue text in any of the operating systems or browsers I looked at and rarely saw them on websites (only a small percentage of grey buttons had blue text). So I recommend switching the grey button blue text to black or dark grey to match the common convention for grey buttons.
thomasgohard
commented
10 years ago @pcwsmith You're right. I hadn't noticed either.
It's using a box shadow. I'll try doing the same with our buttons to see what it looks like when I'm back at the office.
thomasgohard
commented
10 years ago I've PR'd the last solution I proposed to have something in 4.0 final. Further improvements or changes can be made in point releases.
pcwsmith
commented
10 years ago thx @thomasgohard, sounds good.
Please perform a heuristic review of the following component: Buttons example. _For the button dropdowns please see the working examples from bootstrap: http://getbootstrap.com/components/#btn-dropdowns_
Performing a heuristic evaluation