5 ms·

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 info

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 9y ago
>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.
- Silhouette 9y 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.

Benjammer 9y ago

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

Silhouette 9y 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.