[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.

[ryandrake]

Jeez, folks, just put both designs out there in a 50/50 A/B test and use the one that converts better, results in fewer user mistakes, or whatever your business measurement is!

[Silhouette]

Many people have. Text with insufficient contrast is a frequent cause of observed usability problems. That's the point.

[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.