In Praise of Buttons

https://www.nubero.ch/blog/009/

by thm • 2 years ago

134 103 2 years ago

silveira• 2 years ago

Yes! Please, give me big fat buttons. The thing I hate the most in the UI nowadays is to be randomly touching/clicking around to find what is touchable/clickable.

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.

jwells892• 2 years ago

I think there’s places for extreme skeuomorphism even if it’s not suitable everywhere. Nothing wrong with letting the designer have fun with absurdly detailed buttons for a game UI for example.

dunham• 2 years ago

The thing I hate the most in the UI nowadays is to be randomly touching/clicking around to find what is touchable/clickable.

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.

AlienRobot2• 2 years ago

Yeah, if you think of terminal programs like old text adventure games that you have to keep typing stuff until something works, they're literally trying to make GUIs as unintuitive as terminals now.

Just swipe, shake, tap the corners, try scrolling even if there's scroll bar, until it does something!

nubero14• 2 years ago

Did you read the first footnote I wrote in the piece? It’s actually about this exact thing you are talking about:

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.

AlienRobot2• 2 years ago

I've always said that GUIs are better than terminal programs because having the functions visible grants discoverability.

Clearly UI designers are fighting to prove me wrong.

Tempour• 2 years ago

What do you mean by skeuomorphism went too far? Wouldn't that imply that it's as intuitive as interacting with an actual tangible object.

M95D3• 2 years ago

No! Please give me small, mouse-only buttons with no padding.

kevingadd• 2 years ago

I think the point about visual feedback when a tap registers is really important. On touch devices it is pretty much standard that some % of your taps will fail to register, either registering on some other screen element (because mobile UI designers love to make REALLY TINY buttons right next to other touchable elements) or just not registering, perhaps because your finger shifted too much before you lifted it up, or you were off by a couple pixels.

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.

masfuerte• 2 years ago

This problem exists in physical buttons too. My thermostat has buttons that can make the mechanical click without actually activating the button, and I've experienced them elsewhere. It is infuriating.

nubero14• 2 years ago

You are both correct. That’s one of the reasons I mentioned multi-sensory feedback. Every little bit helps. Now, sound can of course be annoying, but it’s up to the discretion (and taste) of the designer to make that call or not – as always, depending on the context.

twobitshifter3• 2 years ago

Along the same lines as this, I miss links being underlined and in blue. Sometimes we are too quick to drop conventions in order to be different.

xnx• 2 years ago

Also disabling the color change when they've been clicked

lhamil64• 2 years ago

I remember in elementary school having a class once where we went to the computer lab and learned about the Internet. I distinctly remember the teacher saying that links were always blue and underlined, and we even had a demo site with a grid of links and had to click the right one (some were different colors, some weren't underlined, etc). The funny thing is, I remember thinking at the time that clearly they didn't HAVE to be blue & underlined because otherwise how would the wrong links work on the page!

For context, this was in the early 2000s

hugs3• 2 years ago

Another reason to use buttons: if you wanted to automate the button pushing, it's easier to create a computer vision function to look for round rectangles vs going full-blown machine learning trying to identify things that could be buttons. (Source: I make software and robots for pushing buttons.)

dewey• 2 years ago

Sounds like a reason why people would not use buttons as more often than not people actively have something against UI automation for mostly no good reason.

dylan6042• 2 years ago

I'm assuming that if you're trying to automate with UI automation that there was no API provided? Automating UI interaction just seems like last resort for pro users and an act of desperation, or screen scrapers.

wrsh076• 2 years ago

For websites (eg UI testing) you normally annotate things to be clicked, so I don't find this super compelling

Parsing text (eg html) is a bit easier than parsing images, although maybe the difference is going to zero

hugs3• 2 years ago

Generally, I agree, if you can get access to the underlying structure/source, then you should use that. But I've been making UI test automation tools for 20 years. There are some cases where adding annotations is not possible or not feasible at low-cost, but the feature still needs to be automated.

zogrodea• 2 years ago

Fluent Search for Windows has a feature where typing a letter combination can click any element on the screen. I appreciate it for the same reason people like shortcuts.

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

dylan6042• 2 years ago

Why are robots needed for software button pressing?

hugs3• 2 years ago

- Device provisioning - Automating a device right after power-on to do initial set-up, add to Wi-Fi, install apps, etc. (Other methods, like ADB, have to be enabled first. Who does the enabling?)

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

twobitshifter3• 2 years ago

example, I have to enter my information on a form every day but the form has no accessible api. I am just copying content from when place to another. Perfect use for a robot.

barelyauser• 2 years ago

If you're testing said buttons with a custom machine, don't you already know where the buttons are beforehand? Why would one need to analyze single frames and look for buttons using machine vision?

wrsh076• 2 years ago

I like a lot of what they're saying, but I actually find all of their redesigns to look worse than the original. I don't prefer the typeface they've selected, and their boxy buttons look two decades old.

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.

nerdponx• 2 years ago

You're entitled to your opinion of course, but not everybody has the same sense of aesthetics as you do, and the whole point of the article is to prioritize usability over any one person's opinion about what looks pretty.

nubero14• 2 years ago

Exactly. I thought I was rather explicit in my afterword that a redesign doesn’t have to look like my redesign.

rayiner• 2 years ago

If a user regularly does something or uses something you can strip it down like the back button.

No.

wrsh076• 2 years ago

Yes! My counterargument will reference the rust language ergonomics initiative post (which imo is seminal)

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

https://blog.rust-lang.org/2017/03/02/lang-ergonomics.html

sdwr2• 2 years ago

Yeah, the apple ghost buttons are a dialog with the user. They say "you have seen this situation 1000s of times, and are tired and bored". They slip into the background as your finger autopilots to the same spot it always goes. When the action becomes rote, the button becomes tacky.

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.

samtho• 2 years ago

I like a lot of what they're saying, but I actually find all of their redesigns to look worse than the original. I don't prefer the typeface they've selected, and their boxy buttons look two decades old.

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.

wrsh076• 2 years ago

There's the classic "when someone tells you there's a problem here, they're usually right. When they propose a fix, it's usually wrong"

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.

nubero14• 2 years ago

You understood the point I was trying to make in that piece, congratulations!

aleign• 2 years ago

I actually have the opposite opinion. I think the Apple version looks 10 years old (which is about the age it actually is. IOS 7 came out around 2013 iirc.) The rounded rectangles looks 20 years old. But is more usable so is superior in my opinion. I agree that the font the author chose is less aesthetic but it is much easier for someone with dyslexia or adhd to read, making it more functional as well.

cmrx642• 2 years ago

in the accessibility settings of iOS one can enable “button shapes” which renders hyperlink-style underlines on buttons masquerading as text. very handy for me. also appreciate differentiate without color, on/off labels, and high contrast: it is much faster for my ADHD brain to navigate iOS with these affordances, relevant details are more salient and my brain has more chance to build a visual hierarchy.

wrsh076• 2 years ago

There are some great options hidden there! There's a zoom (I use 3 finger double tap to trigger) and you can have it read the text on a page for you.

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)

cmrx642• 2 years ago

my favorite is under audio you can play some basic background noises like white noise or water, macOS supports this too, surprisingly effective and builtin, no shady app store needed :)

datadrivenangel• 2 years ago

"That is a problem if you’re a dishonest designer. After all, how do you tell your client that you’ve just reinvented the wheel? You can’t just use boring old buttons in your shiny new product."

The core problem is that people have trouble differentiating between the desire to improve something and the desire to change something.

smallmancontrov• 2 years ago

Also the desire to copy vs innovate. How many "1 button + proprietary dialect of morse code" monstrosities happened because someone heard Johnny Ive brag about reducing the number of buttons on the apple remote?

mnky9800n• 2 years ago

i used an apple remote recently in an airbnb, i don't know what generation, but it was an atrocious experience. Why would buttons also be a touch interface that perform the same function as the underlying buttons? It was very confusing.

sdwr2• 2 years ago

What about flipping it on its head? The problem with being a designer is you want people to notice your buttons. You can't just let them disappear into the background.

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.

justsomehnguy• 2 years ago

Ahem. I'm old enough to have a hands-on experience with DOS and Win3.1.

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.

zilti2• 2 years ago

lol, no, even less people are power users now than 20 years ago.

antisthenes• 2 years ago

A problem that extends into vast political ideologies as well, and just about any sphere of human activity.

pmontra• 2 years ago

Some kind of more button like UI element will inevitably come back. Wait for 5 or 10 years and new designers will look at flat UIs as something that their parents and old people used. They'll want something different as a statement of being new and hot, them and the products they'll be working on. It happens in fashion with colors, shapes and even with full clothes. It's going to happen with UIs too.

JohnFen• 2 years ago

Wait for 5 or 10 years and new designers will look at flat UIs as something that their parents and old people used.

As a parent and old person, I can't wait. I really dislike flat UIs and am looking forward to that trend passing.

skerit• 2 years ago

I hate flat design so much and I can't believe even Gnome Shell switched to it only last year. With the added "benefit" of making it extra hard to change the theme.

butz• 2 years ago

I wonder who thought that removing button outlines from headerbar will somehow improve things? Now it looks like a strange title with icons mixed with text. Still hoping that GNOME accessibility initiative might result in some sane improvements to GNOME UI.

zilti2• 2 years ago

yet another reason to use Plasma, I suppose

waldothedog• 2 years ago

There was a time when I agreed with this idea 100%, and I do think there are still many antipatterns of interface and interaction design that come up quite commonly (tight spacing, undersized click targets, etc)… But I’ve come to think of these posts as harmful oversimplification.

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

cwillu• 2 years ago

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.

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.

disqard• 2 years ago

Relevant to your insight (see "The Design of Everyday Things" by Don Norman):

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?)

sksksk• 2 years ago

I genuinely think that Windows 2000 was the perfect aesthetic.

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.

hiatus• 2 years ago

I fully agree. Even in the XP days and after 2k was EOL-ed I would regularly opt for 2000. XP started a trend of "shiny" UI, for lack of a better description.

jwells892• 2 years ago

Win2k is pretty good, fixing the one big problem with Win9x, which was its dreary darkish gray base color.

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.

mcosta• 2 years ago

Windows 95 ran on a lot of systems with 4 bit colour displays. It was 320x200x256 or 640x480x16 back then. Gray was great with that limitation.

M95D3• 2 years ago

dreary darkish gray base color

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.

no_wizard• 2 years ago

I didn't delete old passbook entries enough in Passbook (now called Wallet) that I ever minded the animation, I kinda miss stuff like that!

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?

jrm4• 2 years ago

The fact that you have to actually say this out loud, with a metaphorical straight-face, is a near perfect example of the immaturity of UX/UI.

There is fashion and there is usability, and sometimes the difference is far clearer than this industry wants to make it out to be.

vel0city3• 2 years ago

What I don't get is the complaint about clickable text without outlines to make them look like buttons on a blog that has tons of hyperlinks for text not embedded into paragraphs. If an outline is required to understand those things can be clicked, why do they drop them on their own blog? Those are just as much buttons as the "Agree" example.

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.

TehShrike3• 2 years ago

Buttons !== links. If anything, the confusion between the two is another reason to go with distinct button styles.

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.

vel0city3• 2 years ago

The links at the bottom of their blog aren't inline in any other text. They're "clickable UI elements that stand on their own", "in a group with other related [links]". One could easily argue they're more button like, especially the email and call links at the very bottom of the page.

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.

nubero14• 2 years ago

You got it.

matthewfelgate• 2 years ago

We need design standards.

TehShrike3• 2 years ago

But the current premier existing design standards (he calls them out in the post) are examples of what not to do. More of those isn't going to fix anything

JR1427• 2 years ago

For those who didn't know the term (like me):

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

nubero14• 2 years ago

Unfortunately, one of the many pieces, where the term affordance is confused with what should be the term signifier. When people talk about the former, they usually mean the latter.

skybrian2• 2 years ago

For HTML, the main alternative to a button is a link, which does have some affordances (often underlined, changes color on hover.)

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?

[1] https://www.a11y-101.com/design/button-vs-link

nevir• 2 years ago

Consider this approach:

<form> <button formaction="https://your/destination">Clicky!</button> </form>

spcebar2• 2 years ago

Take it fairly seriously. Using the wrong elements and markup messes with screen readers, which makes the web harder to use for people with visual impairments and makes your websites vulnerable to ADA lawsuits. If you need CSS help, there's a lot of free resources for that. Some pitfalls you might run into when styling links and buttons to look alike are font faces, display properties, widths, borders/outlines, and paddings, so check those as your first culprits. You can use aria-roles in a pinch, but really you should use the right tool for the right job.

carlosjobim2• 2 years ago

Total fear mongering. Then you can be sued as well for writing your comment in a too small font.

Shog9• 2 years ago

You may be misunderstanding the concern expressed on that page. A button communicates action when activated; a link communicates navigation (not necessarily "load new page", perhaps just "show new information on current screen"). Using a button for navigation or a link styled like a button for action has potential to thwart these expectations in various ways.

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.

skybrian2• 2 years ago

The distinction between navigation and action seems rather blurry. Two pages often have often different views of the same entity. You’re not really “going somewhere,” particularly if it’s not a full page reload.

But I guess the main point is not to use buttons in your nav bar.

aethertron• 2 years ago

Even better: physical buttons that feel like buttons.

My lamp and my earphones have 'touch buttons'.

omoikane• 2 years ago

From the title alone, I thought the article was going to be about "in praise of physical buttons as a better interface than touchscreen".

nubero14• 2 years ago

Wait for Part Two…

nubero14• 2 years ago

I’m writing Part Two of the article right now and I have a feeling you’ll like it…

Yhippa• 2 years ago

Did skeuomorphism go too far in the wrong direction? I think it's gone too far in the wrong direction. I don't mind my notes app resembling an actual notebook that I would use. Compare Notes.app to say, OneNote. Having floating text and iconography everywhere is disorienting. Bring back buttons (and in cars, too)!

conaclos• 2 years ago

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?

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.

nubero14• 2 years ago

If I had been a real stickler when writing my piece, I could have pointed to the “Select” button missing an ellipsis (…), making it “Select…”. Since the first Macintosh, when choosing a command from a drop down menu that would present you with a modal dialog, the command in the menu would have the ellipsis. This would tell you that you would get asked something after selecting the command. So “Save” but “Save as…”. Since “Select” presents you with a mode to select things before you do anything with them, it would technically need the ellipsis. However, I suspect it isn’t there (amongst other things) because the round button next to it is already an ellipsis. That would have to be changes as well. So you see, I could probably write a whole piece just about that… :-)

menotyou• 2 years ago

Buttons without any visible frames

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

nubero14• 2 years ago

Amen to that. You seem to have completely gotten the point I was trying to make. Thank you!

seanwilson• 2 years ago

Can anyone give an example of a popular app where they've been consistently very confused by what's a clickable button/link?

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.

PH95VuimJjqBqy• 2 years ago

Can anyone give an example of a popular app where they've been consistently very confused by what's a clickable button/link?

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.

twobitshifter3• 2 years ago

I use a web app at work that is iconified links all over the place and drop down arrows with palettes of clickable bold text. If I go a week without using it, I have such a hard time finding things because there’s not a menu bar like desktop apps. It’s all a multi step process and discovering the clickable elements in each component.

nubero14• 2 years ago

Blackmagic Camera, Filmic Pro and Halide. All iOS. Their problems are not exactly the same across but the button shapes are a great part of it. The other problem is, that people invent abstract icons for abstract ideas and then expect people to remember every one of those. Whatever happened to text labels beneath buttons?

sgarrity• 2 years ago

I have a dehumidifier that I'd like this author to redesign please.

tobr2• 2 years 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.

nubero14• 2 years 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.

tobr2• 2 years ago

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.

Gentil• 2 years ago

OK. Now where do I learn all these functional aspect of UI/UX? I was thinking of following Human Interface Guidelines. But reading from people here, it just means the UI will look more uniform and fancy. The functionality aspect is not guaranteed.

Any resources someone can point me towards?

In Praise of Buttons

Related Stories