[cpburns2009]

Half of this advice hinders usability.

#2.1: Reducing the opacity of your text makes it harder to read.

#4: Borders help logically separate areas of an interface. Throwing in more white-space is wasteful.

#4.3: Gratuitous white-space is wasteful, especially if you have limited screen real-estate (i.e., mobile).

#7 is a major pet-peeve of mine which I cannot agree with. If it's a button, make it look like a button. Nothing is more confusing than a button that just looks like some text label.

[sameji]

I have to disagree. In an absolute sense you are correct, however you're missing the relative benefit of each point.

#2.1: Yes, this would be an issue if overused, especially in paragraph lengths of text. However, inconsistent font sizes are worse.

#4: Why are you worried about white-space? If you have space, you can use it. If you run out, then you have to start rationing and using other visual tools. Borders have their place, but white-space should be preferred as the most neutral and inobtrusive strategy.

#4.3: So create a responsive layout for mobile that uses more borders where necessary.

#7: This is a major (and valid) criticism of flat UX, but slightly adjacent to the point in the article. The article says you don't need a background colour for every button, which is good advice.

[Nadya]

I actually just got done running an A/B analytics test on a large website (>100k viewers/day). Statistics say you're right, least about the buttons. ;)

The client wanted a "button" without a background color because it looked bad to have two buttons side by side. My company told them that was a bad idea based on data, so we added tracking to their site and A/B tested their home page. Button with a background color had 40% more conversions than the "button" they wanted without the background color.

Several pieces of the advice given on that article are proven to be bad ideas for most websites if you track your users. What "feels" right and what is right are often two different things.

If you're ever making a change because you think it will perform better you better be tracking the statistics. Often times you'll find out you were wrong. Another, similar, example is that a client had a button they wanted to "draw attention to" so wanted to inverse the :hover background color with the normal background color so that it would stand out from other buttons. It looked different - but hurt engagement because it no longer looked like every other button on the site.

E:

This was meant to be a response to cpburns2009, the parent of the comment I responded to. Thanks to metalliqaz for pointing that out.

[hammock]

>The client wanted a "button" without a background color because it looked bad to have two buttons side by side. My company told them that was a bad idea based on data, so we added tracking to their site and A/B tested their home page. Button with a background color had 40% more conversions than the "button" they wanted without the background color.

Of course it did, it looked more like a button! But at what cost? It sounds like this button was not the primary action. So how many clicks were lost from the primary action - how much usability was lost from the page?

[Nadya]

It was a primary button on the hero image in the standard "Header/Subheader/Call to Action" format. It was basically the only thing they wanted users to interact with.

>Of course it did, it looked more like a button!

And buttons without the look of a button are just called links. Links without visual distinction may as well be invisible. Like the infamous "black text link with no underline in the body of a paragraph of black text".

https://codepen.io/anon/pen/GQdeBO

[madeofpalk]

Designing is just like coding. You've got to be pragmatic about knowing when and where to use the tools in your belt.

You might have your little favourite programming trick, but a good programmer will know when and where to use it - you don't want to use a map function everywhere.

Note that the article's point about buttons isn't prescriptive and doesn't say "always do buttons like this". Instead, it talks about a common specific use case and talks about how you can improve the situation. It's up to you to take that information inboard and judge where to use it. It sounds like the specific example you cited was a good time to not follow this approach.

[Nadya]

It's form over function and I'd be shocked if anyone ever shares statistics where making the button more difficult to see increased user interaction with it or made it easier for users to do other tasks by "getting the button out of the way".

The only time I'd use a 'button' without a background color is something I don't actually want the user to use. For example, a 'delete' option on their profile or the 'unsubscribe' link in a newsletter.

But I'm not user hostile so I'd still make those options easy to find for users who wish to use them instead of trying to pad my "user retention rate" or whatever numbers the marketers are trying to make look good.

[hammock]

>It was basically the only thing they wanted users to interact with.

Then why did they put another button side-by-side of it?

[Nadya]

My bad, I misread and thought you had referenced my first example (button/no background) but you had referenced the button/button example.

The button/button was for a search. They wanted to draw attention to the 2nd button that sorted the results alphabetically. Why wasn't the alphabetical sort the default? Well... doctors are all very bothered about who gets shown above who - so the list of doctors has to be sorted randomly to please the doctors. The hospital doesn't want to piss off the doctors but also wanted to make it easier for users to search. They wanted to draw attention to the button that would sort the list alphabetically by changing the color of the button to stand out more.

I'm positive doctor names would look like Yellowbook pages back in the day with "AAAble AAApplebottoms" just so they could be the first shown. You'd think users being able to find their doctor would take priority over the order the doctors are shown in, but apparently not.

I work in Healthcare. The only thing that irritates doctors more than listing them alphabetically is forgetting one of their various titles. Dropping the "MD" after their name is a cardinal sin.

[wuliwong]

"Primary actions should be obvious. Solid, high contrast background colors work great here."

If you made the primary action a button without a background than you did not do what was suggested in this article.

[metalliqaz]

Replied to the wrong comment?

[Nadya]

Yes, this was meant to be a response to cpburns2009, woops. Was in a rush and originally posted it as a parent level comment, deleted, then reposted under what I thought was the right thread. Looks like I still need more coffee.

[cpburns2009]

> Yes, this would be an issue if overused, especially in paragraph lengths of text. However, inconsistent font sizes are worse.

I should have clarified this better. I dislike low contrast text because it makes it hard to read which is popular with the flat UI trends. Opacity isn't used so much from my experience, but light grey text on white is which has the same effect. I agree that inconsistent font sizes are bad too.

> Borders have their place, but white-space should be preferred as the most neutral and inobtrusive strategy.

In the example from the article I think the bordered version is much more concise and clearly delimits the search box and list. White-space seems to be used too carelessly in an attempt to avoid any clearly defined borders.

> The article says you don't need a background colour for every button, which is good advice.

You don't need to give every button a colorful background. But each button should have at least a border or background to distinguish it from standard text. The background can be just a boring grey like the classic Windows dialog buttons.

[kemitche]

I disagree on #4. For me at least, a page with no borders and just whitespace looks like a jumble of elements. Not that everything should have a border, but plenty of websites could go for a couple more lines.

[hammock]

>#2.1: Reducing the opacity of your text makes it harder to read.

That's the point, to take away focus from something lower in the hierarchy.

>#4: Borders help logically separate areas of an interface. Throwing in more white-space is wasteful.

You're defining waste from a screen-space point of view, not a usability point of view. Who cares if the screen's pixels are at maximum utility, I want my user at maximum utility!

>#4.3: Gratuitous white-space is wasteful, especially if you have limited screen real-estate (i.e., mobile).

See above

>#7 is a major pet-peeve of mine which I cannot agree with. If it's a button, make it look like a button. Nothing is more confusing than a button that just looks like some text label.

Again, hierarchy.

[Silhouette]

That's the point, to take away focus from something lower in the hierarchy.

But there is a difference between merely moving something further down in your information hierarchy and making it hard to read. Low contrast text, like very small text, is hard to read for a large part of many markets. If it doesn't need to be read, why not go to the next stage and remove it entirely?

You're defining waste from a screen-space point of view, not a usability point of view.

There is precious little evidence that the trendy, overly spaced-out look of flat design and its derivatives has any usability advantage at all.

On the other hand, it is self-evident that if you're trying to show some sort of dashboard and spacing it out like that means you can only get 75% of your data onto a single screen instead of 100%, then your design is less practical.

There is also ample evidence that mystery meat navigation impairs usability, which is particularly relevant to the discussion of button styles here.

[Benjammer]

>But there is a difference between merely moving something further down in your information hierarchy and making it hard to read.

If you change "hard" to "harder", would you agree that there is no longer a difference? It seems you are just placing your bar for "too hard to read at all, in any context" somewhere different than the author of the article. The author is definitely making things lower in hierarchy harder to read on purpose, that's the whole point.

>There is precious little evidence that the trendy, overly spaced-out look of flat design and its derivatives has any usability advantage at all.

Honest question, is there any evidence that shows the usability is _worse_? How about evidence that reducing spacing or adding more options/data to a page _increases_ usability?

>if you're trying to show some sort of dashboard and spacing it out like that means you can only get 75% of your data onto a single screen instead of 100%, then your design is less practical.

A dashboard is a very specific design case. Most pages in general are more geared towards specific actions or specific "detail views" of data, where you have clear hierarchy of both data and actions. Aggregate data pages like dashboards are a whole different beast, and it seems weird to bring them up in a general UI design discussion. I would think dashboards are also more often internal than even a feature shown to real users. The days of dashboard-style pages like "web portals" are long gone.

[majewsky]

> Honest question, is there any evidence that shows the usability is _worse_?

It is obvious that usability will suffer when you cannot fit all the required functions into the screen real estate. Now, since we're talking about websites, which usually have a rather low function density, that's not necessarily a problem. But try to apply this design advice to more complex web applications, or to professional software like Photoshop or Blender.

[Silhouette]

If you change "hard" to "harder", would you agree that there is no longer a difference?

No, I wouldn't. Of course variations in contrast or colour can be used up to a point without significantly affecting readability, and dogmatically taking any design guideline too far is usually not helpful. But when you really do get to the point of making things significantly harder to read, I think you've crossed into dangerous territory, with the usual caveats about readability depending on your expected audience.

Let's not muddy the issue with terms like "hard" vs. "harder". Let's look at the actual examples the author gave to illustrate the suggestion.

In the "Amsterdam walking tour" example, the light grey text is #737373 on #f7f7f7. That's already past the WCAG threshold at AAA level for normal (i.e., body size) text. It's used for legally significant material, while describing an activity that could easily be of interest to an older clientele.

In the later "Steve Schoger" example, the job title in the left pane is #929292 on #f7f7f7. That would be past the WCAG threshold even for large text and even at AA level. Maybe the job title isn't intended to be so important in that example, but again, if it doesn't need to be readable, why have it there at all?

The author is definitely making things lower in hierarchy harder to read on purpose, that's the whole point.

I understand that. I claim that doing so is measurably bad for usability in many situations, and that there is ample research to demonstrate this, upon which guidelines such as the WCAG's are based. The W3C pages about the guidelines provide extensive explanations of the reasons behind them, if you're interested.

Honest question, is there any evidence that shows the usability is _worse_?

In the sense of reduced data density, isn't it self-evident that some information is then harder to access?

A dashboard may be a somewhat specialised example, but the same argument applies to anything else with a lot of data to show: tables, lists, even the menu example in the article, where the more spaced out version has lost an entire menu entry off the bottom compared to the original.

A related argument also applies anywhere that space is at a premium, even if there is only a modest amount of data to present. That includes almost all UIs to be used on smartphones, and it includes many types of UI where you have different screen areas for different purposes and so the space within any given area can be quite limited.

In more specific cases, for example removing clear demarcation of search controls in favour of a generic background colour as also demonstrated in the article, there is plenty of research to show that the mystery meat approach to controls and navigation doesn't work well.

If someone is going to advocate for the fewer borders and more spacing approach, and if there are multiple well-established arguments for how doing so can harm usability in at least some cases, then I think the burden initially falls on the advocate to argue/demonstrate that their way doesn't fall into those traps.

[Benjammer]

You never mentioned WCAG guidelines before, you just said "making it hard to read." If you had said "the author doesn't respect WCAG guidelines, even lower-hierarchy text should meet WCAG guidelines," I think that would have been a very, very fair criticism.

This is "cheating at design" though, not "how to meet the full AAA WCAG thresholds."

I'm still not sure I really follow your line of thinking here. When the author says (paraphrasing) "make low priority text less readable, in order to highlight the important stuff comparatively," and you say "less readability is bad for usability," I think 'yeah... that's the point'. You take something that isn't as important and you make it less readable so that the important stuff is more readable by comparison. It helps users to differentiate between expected/primary data/actions and secondary/tertiary data/actions.

Do you just completely disagree with this philosophy? Do you think the author is mis-applying this, and you think some text that the author has made less readable is actually more important to users than the author thinks it is? Something else entirely?

Honestly I'm struggling to figure out where you actually disagree with the author, it seems to me you are both saying "lower contrast ==> less readability/usability." What am I still missing here?

[Silhouette]

You never mentioned WCAG guidelines before, you just said "making it hard to read."

The WCAG are just one authoritative source that happens to be readily available and therefore seemed a useful objective reference for the discussion.

The point I've been trying to make is that there is a very important difference between simply de-emphasizing text (which is often useful, and which a moderate change in contrast might indeed achieve) and making it hard to read (so that even someone who wants to read that information will find it more difficult). What the author is advocating in this case doesn't just do the former, which would be fine; it also potentially does the latter if taken too far, as several of the author's own examples have been, and at that point the presentation certainly is undermining usability in that respect.

Perhaps my point would be clearer if we consider the opposite effect. In a magazine or textbook, a key definition that is shown in boldface is readily picked out when scanning the page, thanks to the contrast of its darker appearance compared to the main text. Likewise, a heading in a different colour is readily located, or a pull quote set in a large, italic font. All of these typographical techniques show some form of priority in the information hierarchy and guide the reader's focus, yet none requires that any of the text, including the less emphasized main body text, be at all difficult to read.

The reason I am trying to make this point so forcefully is that this is also a classic case of a mistake where young designers with good eyesight and high-end display equipment frequently fail to realise they are doing anything wrong, and as such I agree with others commenting today that the advice in the article could be counterproductive without additional qualification. Ironically, the author did flag up the related bad practice of using lighter font weights at body sizes, which is another common usability problem with some modern UI styles for much the same reasons. It's a little hard to reconcile awareness and avoidance of one danger with actively promoting another that is so closely related.

[PeterisP]

It would be reasonable to lower the contrast a bit, accepting that it would be slightly less readable (just as it would be if it would be with a smaller font) but still not actually hard to read.

I.e. the main text would be at maximum contrast, the tertiary text would be the contrast at the WCAG guideline threshold, and the secondary text would be somewhere in between.

[JoshMnem]

I like borders too. They often help make it easier to understand the layout from a quick glance.

[wlesieutre]

Especially in contexts where there’s more then one hierarchy along more than one axis. UIs where you have content in the middle with multiple columns and sidebars and toolbars turns into a mess with the no borders flat design approach.

[dorkwood]

I think white space is often misunderstood.

People tend to see it as a void that could be put to better use. We shouldn’t think of it as a void, though. We should think of it as a separator. It’s gestalt theory: objects that are close to each other appear connected. When you remove too much white space, groups of elements become less distinct, and cognitive load increases.

[marcosdumay]

About #7, the article is not advocating making things not look like a button¹, it's advocating making secondary buttons lighter.

1 - In fact, the buttons there don't look like buttons. But that's because it uses a normal design, and nobody creates buttons that look like buttons anymore. Could we please standardize the "button look" with a small, fuzzy outset?

[Silhouette]

Well, the examples of tertiary buttons under #7 are plain text or plain text with an underline, and the article text specifically mentions styling tertiary actions like links as being "usually the best approach". It pretty much does exactly advocate making things not look like a button.