Hacker News new | ask | show | jobs
by Silhouette 3045 days ago
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.

1 comments

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?

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.

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!
Many people have. Text with insufficient contrast is a frequent cause of observed usability problems. That's the point.
Cool! Shouldn’t that be the end of the discussion then? If you can measure that one design converts or otherwise performs better then that’s the right one. What other considerations are needed?
A/B tests and their statistical brethren are useful in some contexts, but as you (almost) said, they come towards the end of a discussion. First you have to identify some variations that you want to test. And of course in some cases, particularly more complex UI designs, there might be no simple success metric to measure for an A/B test, and indeed there is probably no simple set of changes you can isolate from their context either.

In short, A/B tests are great, but they're not a substitute for design skills, they're a way of refining what you already have in some situations.

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.