3 ms·
I should preface this by saying that I am a fan of buttons in general. Mostly for aesthetic reasons. For most users and most cases, the usability impact is prob
by tobr 3y ago
I should preface this by saying that I am a fan of buttons in general. Mostly for aesthetic reasons. For most users and most cases, the usability impact is probably insignificant though. That said, this article doesn’t do a good job arguing for buttons.
> In the first row we see a series of icons that are supposed to be buttons. The only way you could potentially recognise them as such, however, would be if they were implemented in a user interface. So it is in fact only the context that lets you recognise them as buttons, not their appearance by themselves.
So what is the problem? If you can recognize they are buttons in context, that sounds like a successful design.
> In touch interfaces however, that is often not the case. There, the actual outline of the graphic – let’s say the minus – is often the only thing that can be touched.
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.
> Apple is using lazy button shapes for “Select” and the ellipsis character (…) on the right. On the left however, the button for going to your albums is just the word “Albums” and a little arrow shape. Why those two different concepts on the same screen? In the redesign, everything that works like a button also looks like one.
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 should be consistent with the same pattern on other screens and in other apps. The design should be deferential because it is so ubiquitous. On the other hand, the two buttons in the right are specific to this screen. It would be a mistake to make them so similar when their scope and purpose is fundamentally different.
- nubero 3y ago> 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.
- tobr 3y agoAgain, 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.
- nubero 3y ago> 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.”