In Praise of Buttons
nubero.ch
nubero.ch
The core problem is that people have trouble differentiating between the desire to improve something and the desire to change something.
Scrolling
20 years ago, the complaints were that everything was dumbed down, and the "power users" were being hung out to dry.
Well, now everyone is a power user. The average iOS user has at least 5 years experience with the UI. People don't need as much hand-holding.
When someone hands me their iPhone (eg to show something some page in Safari or asking for help with something) I struggle to navigate anywhere. I have almost none iOS experience, because I never had iPhone. And new users (like kids born after iPhone 1, lol) have zero experience with iOS too.
Yes, skeuomorphism went too far but the pendulum swigged way too far in the opposite direction. Metro, flat, ultra minimalistic design makes user interactions harder when they remove useful visual clues from interfaces.
Yeah, it reminds me of the old graphic text adventure games (e.g. Zak McKracken) where you had to hover the mouse over the entire screen to find the thing you are supposed to click on. If you're luck, the cursor might change shape. I generally prefer UIs to not be puzzles.
Just swipe, shake, tap the corners, try scrolling even if there's scroll bar, until it does something!
In many graphical interfaces that expect a mouse as input, the programmers will make the clickable area of the upper row buttons the same as the lower row ones, although this will be invisible at first. You can hover with your mouse over the buttons and then, magically, a button shape will appear. It’s not going to be a nice 3D-button shape however but just an outline. This serves no functional purpose. For instead of showing the user where all the buttons are from the outset, the whole affair becomes sort of a hide and seek game, where users have to guess which item they might be able to click.
Clearly UI designers are fighting to prove me wrong.
And then the top of their blog has an image that is clickable to go to the home. No information that the image is clickable, no information about where it would go.
Besides that, he's pretty clearly talking about clickable UI elements that stand on their own, or in a group with other related buttons.
Links exist inline in the context of other text.
The author is complaining about nobody would understand to click on Accept in their example without having an outline around it and yet they expect people to understand to click on "eMail" and have it open their default email client.
There is value in differentiating between them.
There is fashion and there is usability, and sometimes the difference is far clearer than this industry wants to make it out to be.
It had just the right amount of skeuomorphism, without going overboard; probably because of hardware limitations.
What I think happened is that as computers and phones got more and more powerful, developers and designers wanted to use the UI to show off a bit. Culuminating in mad animations like a shredder destroying your old boarding pass in Apple Wallet.
Then there was a complete rejection of skeuomorphic design with iOS7, and it's just got more and more extreme since then.
Personally I’m a bit more fond of the Platinum theme from Mac OS 8 up through 9.x, though. Similar color scheme and principles, but it uses rounded corners and soft shading in a few places Win9x/2k doesn’t which makes it feel a bit more warm and accommodating without negatively impacting usability.
I had a Trident 9660 with 1MB VRAM and I never had to use a 4bit mode.
It's a matter of taste and back then, you could change it to whatever color you liked. For me, it that darkish gray was too light and I switched it to an even darker gray.
Its nice to add whimsy to traditionally under-used features of a platform IMO.
Though I suppose if I was deleting passes all the time I might find the delay a little frustrating, but that could be solved by allowing multi select and delete right?
For context, this was in the early 2000s
The example of the touch feedback cuts both ways: those buttons exist in context, and one can certainly provide touch feedback without a border/shadows. Text-only buttons also exist in context and the language can do a lot to explain what happens.
A counter example is a physical button on manufacturing equipment. It’s huge, tactile, and labeled. I know I could press it, but that doesn’t necessarily help me understand what happens when I click it.
Everything on a screen /could/ be clicked or tapped, it’s inherent to the medium, making something “look clickable” doesn’t necessarily help clarify if/when I should click it, or what the result will be
On the other hand, you can be very sure you won't press it unintentionally if you stay away from it, and the difficulty in pressing it provides a hint of how big of a deal it is to press it. Membrane buttons, on the other hand, can very well implement flat or hidden buttons that one might press by accident.
1. The gulf of execution: how do I do something? (i.e. what can be clicked/tapped/pressed?)
2. The gulf of evaluation: how do I know/understand what happened as a result (of clicking/tapping/pressing something?)
It's a robotic voice, but it's pretty great if you want someone to narrate eg daring fireball length posts to you (and you can speed it up to 1.5x+ speed)
We are sometimes told not to use a button when a link will do [1]. Supposedly, links are better for accessibility or for user expectations. You can style links to look like buttons, but I have trouble making them exactly the same if they’re next to each other (for example, the same height) and it seems like doing it the hard way.
So how seriously should I take that advice?
<form> <button formaction="https://your/destination">Clicky!</button> </form>
In real life there are 100 times as many accessibility problems as on any web page – why shouldn't they be sued?
I'll admit, sometimes this makes some sense; you may be building an interaction that doesn't map cleanly onto either "trigger action" or "show information", and you wish to pick and choose the semantics that best fit your needs.
...But then there's the situation you allude to, where you have a button (action) and a link (navigation) and are just trying to make them look the same for consistency. Even if you pull it off visually, the chance that an end-user's client software will misinterpret what you're doing in some way and cause confusion is high.
But I guess the main point is not to use buttons in your nav bar.
1) Can you return things to exactly the state they were before simply by hitting the browser's "back" button once? Then use a link. Otherwise use a button.
2) Will this navigation have side effects (eg, change values in the DB)? If so, then use a button. Otherwise, use a link.
I agree that the terms agree/disagree aren't well differentiated, I don't agree with their solution
I find their photos redesign to be much worse than the original. Buttons are an affordance that you use to instruct users on new or rare behavior. If a user regularly does something or uses something you can strip it down like the back button.
No.
In particular, they say
> One final point. "Implicitness" is often relative to where the language is today, something that seems radical at first—like type inference!—but then quickly disappears into the background, to the point that it no longer feels implicit at all (see Stroustrup's rule).
On, say, a kitchen stove, I find the same minimal design frustrating, because I don't use it enough to be familiar, and I want 100% certainty.
The actual design was not the point of this piece, if anything, it’s an invitation to re-explore the design of the button. By being hung up on the implementation details, you have missed the forest for the trees.
Back in the early 2010s when I was doing freelance web development, I learned very quickly to stop gathering feedback from the client on specific steps because, for example, if I showed them a greyscale wireframe for page to solicit feedback on the layout, they would say, “the text organization looks good, but I wanted it to be these different colors, also I don’t like the Latin text in there, where is the content that we agreed would be in there? Also the logo is missing, also none of the links in the footer work, I don’t like the font, etc etc.” I thought at this point (and especially on this forum) we were past this sort of ill-informed feedback.
To me, this post falls squarely in that bucket. It correctly identifies issues and does not find the correct solution. Unfortunately, that undermines my confidence in the author, and that makes me suspicious of their comments on the photos page or regarding the typeface.
The author says "Apple used a bad font" but I missed it if they explained why, and their replacement didn't feel better to me. That's not convincing! I don't think it's unfair for me to say "yes, you've identified a problem but not the solution" and I don't think that's a meaningless comment.
I like buttons, and since I'm not a designer, I often use obvious affordances or make simple product decisions (this is to my detriment: too many modals or toasts). This includes buttons. But without hearing from Apple's designers (or from any designer defending their decisions), I leave this post feeling unconvinced. Their argument wasn't good enough for me to think it would beat an argument in favor of the designs Apple employees made.
You're correctly describing facts (eg the font apple uses doesn't let me tell the difference between llama and Ilama), but that's mostly not needed when reading their blob of legalese text.
In the extremely subjective world, I find the monotype hard to read in that narrow format because it implies a verticality - like looking at an art deco building. Somehow my eyes are able to scan the font they've selected more easily. This is, of course, possibly because apple has made me read a lot of their typefaces.
The context matters a lot, and so you want the stop sign (or possibly even the simple marketing sign) to be unambiguous. You want good kerning that won't make words bleed together or break at incorrect points.
I tend to like the fonts that are trendy on the web these days though - I find them fairly easy to read (and I read them a lot!)
One thing that surprised me is that comic sans can be easier for someone who is dyslexic to read because b and d are not mirrors. So I would be sympathetic to a lot of typeface choices if I understand why.
- do not provide optical lines to be aligned with other screen elements (look more chaotic on the screen)
- are visually more difficult to find on the screen (enhances stress, makes work mor tiresome)
- are more difficult to aim at with the mouse (requires more precise movement, error prone, leads to frustration)
- are more difficult to be identified a active element (violating rule of discoverability)
In many cases there is no good color choice either. Quite often you have dark grey on light grey or other combination low on contrast.
Things described in the article were part of fundamental knowledge in system ergonomics 20xrs ago. After "UI" or "UX" designers took over usability went downhill on many screen. Today the most elementary rule of good design is commonly ignored ("Form follows function").
As a parent and old person, I can't wait. I really dislike flat UIs and am looking forward to that trend passing.
Clicking on "< Albums" could change the page completely. You navigate to another page. The buttons "Select" and "..." stay on the same page. I think it makes sense of using two distinct styles.
Skeuomorphism is a term most often used in graphical user interface design to describe interface objects that mimic their real-world counterparts in how they appear and/or how the user can interact with them.
https://www.interaction-design.org/literature/topics/skeuomo...
> 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.
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.
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.
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.”
I get that a chunky 3D button probably scores the highest in terms of advertising that it's clickable, but is e.g. the text "agree" and "disagree" in blue when all the text around it is black (from the article) so confusing you'd give it something like 1 out of 10 in comparison? Or is it more like 7 out of 10?
I've haven't found it a huge problem in the apps I use. HN has lots of links on the page that aren't underlined or even a different color to non-clickable text for example.
For what it's worth, WCAG for accessibility says buttons should have a visible border and hyperlinks should be visibly different to the body text (underlined, or a different color/brightness) so there are some standards and guidelines.
since I don't use mobile apps I can't give you an example except to say that I run into this a lot in todays design landscape.
My favorite is when it's not obvious where one window ends and the other begins on my windows box.
There's nothing wrong with form but form over function needs to die.
Just as many programmers ignore aesthetics in lieu of functionality (aka programmer interfaces), many designers ignore ux and functionality while chasing aesthetics.
My lamp and my earphones have 'touch buttons'.
So having clear visual feedback that a touch registered, and showing you where it registered, is huge.
I reserve a special curse for people who implement touch feedback separate from touch processing, though. I've used a couple different apps where it's possible to create a visual 'touch' that doesn't actually trigger a click on the button, and that's infuriating.
Parsing text (eg html) is a bit easier than parsing images, although maybe the difference is going to zero
Fluent Search is a desktop app and this feature is meant to work regardless of which apps are on the screen (browser, Notepad, whatever else) so I think there's a legitimate point here although it might be a niche one not relevant to you.
(I don't know enough about Windows internals to answer with confidence if a better solution is available like examining the OS accessibility tree, but I guess an advantage of Fluent Search's approach is that UIs from toolkits not implementing accessibility standards aren't excluded. The current approach has drawbacks like false positives too though because the ML model isn't 100% accurate.)
- Security testing - Interacting with a device that may have malware on it. You use a robot so that it is 100% unmodified while you study it. For further safety, the device is run inside a Faraday box, and you use the robot to access the device from outside. (Otherwise, you do everything manually in a human-sized Faraday cage.)
- Performance testing - Getting timing data of app performance is more accurate when the device is unmodified and you use an external tool to interact with the UI.
- Testing medical devices - Required to be tested exactly the way a user would interact with the device.
- Point of Sale testing - Some real world end-to-end tests involves inserting or tapping a card and entering a PIN on the screen.
- Or you're interacting with a touchscreen that has no other programmable interface, but you still want to test automate it (like any touchscreen on any device that is not a phone or tablet, e.g. an HVAC or alarm system panel.)
(These are all things I've been paid to make robots for over the last decade.)
Any resources someone can point me towards?