> So what is the problem? If you can recognize they are buttons in context, that sounds like a successful design.
Then you didn’t get my point about cognitive load or I wasn’t explicit enough. Sure you can recognize the icon-only buttons in context (mostly) but if they work worse in a sterile (or call it academic) example when compared to buttons with shapes, how are they better when in an UI? The UI will help but the cognitive load will still be higher than if they looked like buttons by themselves.
> If you implement your touchscreen buttons like this, I’m not sure what to say. It’s not a problem with the style of button, but a bug in your implementation. I can’t say I’ve ever come across it in the wild in anything that is remotely competently made, as it would basically be unusable.
I had this in several apps across the years. If it happens often enough, you develop an itch in the back of your head that makes you ever so slightly distrust buttons in that shape. Something that can be completely remedied by the solution I proposed.
> There’s a perfectly good reason why they look different. The back arrow is a navigation pattern that is used across the entire OS.
It’s a bad pattern, made by people who confuse website content with native GUIs. I can’t go as far as to explain all the reasoning behind this but just this much: The back arrow I proposed is something that – and believe me or not, I realised after I wrote the piece – had already existed in iOS before the flat nonsense.
Again, I love a good button, and I’m not arguing against them. But I also recognize that using a simple icon or word as a touch target has its benefits in many contexts. There are reasons beyond numb-headed fashion that lead to their use. The context thing is crucial - if context is already communicating something, that is usually way more powerful. After all, it’s not enough to understand that something is a button, you also have to understand what it does (or more specifically, people who have a use for it need to understand what it does, and people who don’t have a use for it need to recognize it is irrelevant to their situation). This can only be done with context.
I think the problem with your article is that you are not taking the style you’re arguing against seriously. If you think it’s always wrong and can’t see any good reason why it’s used, you will not be able to make a good argument for why to use more traditional buttons instead.
> But I also recognize that using a simple icon or word as a touch target has its benefits in many contexts.
Yes. Sometimes. I said so in the afterword of the piece. Maybe you missed it: “Does every virtual button – every button in a graphical user interface – have to look like a pressable, physical 3D button? Of course not. They also don’t need to look exactly like my redesigns either. On a case-to-case basis it might even be better to do something else entirely.
The whole idea is to reduce cognitive load. And since the brain works by recognising patterns and dividing the environment up into areas, this reduction is best done by making elements with different functions appear markedly distinct from one another. It is, in other words, a fallacy to believe, that the brain has an easier time if everything looks “simplified” in the way which happens with the flat design doctrine. The opposite is the case.”
> There are reasons beyond numb-headed fashion that lead to their use.
Certainly not where buttons that used to have button shapes were replaced with only icons or text.
> After all, it’s not enough to understand that something is a button, you also have to understand what it does (or more specifically, people who have a use for it need to understand what it does, and people who don’t have a use for it need to recognize it is irrelevant to their situation). This can only be done with context.
That is correct but it also wasn’t the scope of the article at all. It was simply about the importance of understanding which element on a bitmapped screen is a button in the first place.
How to make a button – no matter what it looks like – communicate what its function is would be more than enough scope for another article.
> I think the problem with your article is that you are not taking the style you’re arguing against seriously.
In what sense am I supposed to take seriously a UI decision that was detrimental to usability?
> If you think it’s always wrong and can’t see any good reason why it’s used, you will not be able to make a good argument for why to use more traditional buttons instead.
That is not a logical statement. I can, for example, say that National Socialism is always wrong and still make a good case against it.
All that being said, I’m actually a great fan of reduced aesthetics. The torn-off paper in the various notes app and leather stitching were horrible. But as I said in the piece, They are still to be preferred if the only other option is a reduction that makes the UI unusable. My exact words were: “Just because a user interface uses 3D-buttons and some shading doesn’t mean that it has to look tacky. In fact, if you have to make the choice between tacky-but-usable and minimalistic-but-hard-to-use, tacky is the way to go. You don’t have to make that choice though: It’s perfectly possible to create something that is both good-looking and easy to use.”
Then you didn’t get my point about cognitive load or I wasn’t explicit enough. Sure you can recognize the icon-only buttons in context (mostly) but if they work worse in a sterile (or call it academic) example when compared to buttons with shapes, how are they better when in an UI? The UI will help but the cognitive load will still be higher than if they looked like buttons by themselves.
> If you implement your touchscreen buttons like this, I’m not sure what to say. It’s not a problem with the style of button, but a bug in your implementation. I can’t say I’ve ever come across it in the wild in anything that is remotely competently made, as it would basically be unusable.
I had this in several apps across the years. If it happens often enough, you develop an itch in the back of your head that makes you ever so slightly distrust buttons in that shape. Something that can be completely remedied by the solution I proposed.
> There’s a perfectly good reason why they look different. The back arrow is a navigation pattern that is used across the entire OS.
It’s a bad pattern, made by people who confuse website content with native GUIs. I can’t go as far as to explain all the reasoning behind this but just this much: The back arrow I proposed is something that – and believe me or not, I realised after I wrote the piece – had already existed in iOS before the flat nonsense.