

Discussion summary
Discussions centered on the design and functionality of buttons in apps, emphasizing simplicity and user experience. Participants debated whether buttons should perform multiple tasks or focus on a single, clear function.
What the discussion says
- Some argue buttons should have a single, clear purpose to improve UX.
- Others believe buttons can have multiple functions if well-designed.
- There is concern about overcomplicating button design and user confusion.
- Auto features like auto-straightening could reduce user effort.
“Every button has two jobs: to convey and to do.”
“Design should prioritize simplicity over multifunctionality.”
Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- One job doesn't really fit the button thing because a button has to do many things, only one of which is being clickable.
Having feedback when clicked, feedback when hovered. A loading state, a disabled state, a mix of everything. That's also something I found very frustrating. Like if you take the example of a button that is tied to a service on the back end, clicking this button without any visual feedback doesn't tell you if that button was clicked or not. And if it doesn't have a loading state, you wouldn't know that. something is working behind the scene when you click this button so you would click at multiple times not knowing that it's still working behind the scenes.
by othmanosx - This is literally the type of thing that caused the THERAC-25 disaster (https://en.wikipedia.org/wiki/Therac-25). Experienced users hitting keys faster than the app could process them, resulting in safety features being inadvertantly bypassed.by QuercusMax
- Looking at the first comparison, I will admit, I thought the issue was with the iPhones example. The button and slider below the image disappear, then fade back in after each press of the rotate button, a behaviour I have seen on iOS across many applications that irks me to no end. The Screenshot app being a particular bug bear of mine.
If you have a UX element that I will be able to interact with before and after an interaction, then keep it visible during the transformation, process, whatever. What UX gain is there in hiding these buttons during the rotation on the iPhone? It doesn't even look better, though appearance has been the altar that recent Apple software has sacrificed actual UX gains.
Will agree with the author though that these taps need to be processed independent of animation.
by Topfi - I used to have a device with a physical button which, when you pressed it, would beep and add 30 seconds to the time. However, sometimes it would beep and not add 30 seconds, and sometimes it would add 30 seconds without beeping, so you always had to squint at the dim display to discover whether it had worked or not. I thought this must be a peculiarly bad design ... but since then I have lost count of the number of purely software buttons that somehow seem to replicate this broken behaviour: whether the button changes colour on the screen is somehow only loosely correlated with whether the action requested will take place. Why? How, even, have they implemented this?by bloak
- People often forget that animations serve purely a supportive role and do not exist for the purpose of having animations.
They are there to mask loading times and ease from one state into the other. That's why we have them.
This knowledge eventually got lost (figuratively speaking) and now we have code that needs to wait on the animation to finish.
Another amazing example of cargo culting.
by hypfer - I want to support the "what about debouncing" argument mentioned elsewhere; the author shouldn't just ignore this.
But I also hate the "you had one job" meme and want to argue against its mindless usage. Most of the time, when people do the "you had one job" thing, it's false. And that's true most of the time in the case of buttons, too. In a typical user interface, a given button has some combination of these jobs:
* Communicate what action will occur should the button be pushed.
* (Sometimes) communicate the current status of some aspect of the system (e.g., often a button is used to enable/disable a mode, and the button itself visually conveys what the current mode is).
* Execute the intended action upon clicking.
* (Sometimes) communicate that the command has been received and is being executed (e.g., in the OP, the button might disable itself while animating the rotation in order to avoid the confusion the OP complains of).
by CWuestefeld - The author suggests they want three clicks at any pace to always == the same functionality, so they can whiz through their photos and rotate each predictably. Fair.
> And it would be so much more predictable and pleasant if you could just tap the button three times at any pace you wanted without thinking, without paying attention, without getting your UI blocked by an animation that no longer helps you.
They cite accessibility.
The thing is, I can imagine the complete opposite side of the argument, where someone with motor impairments or parkinson's, for example, ideally liking if their over-clicks were ignored if they'd already locked-in their intention.
It's tricky to get this stuff right.
by padolsey - How about when users accidentally click too much, or they believe the first click didn’t register?
I am still reminded of a keynote where Steve Jobs was demoing how much faster PDF documents would display on the newer macOS. So he had engineers put a button in for him to click that would scroll through the PDF on the screen, and he accidentally clicked it more than once. Steve wondered aloud if it would scroll all the way through twice… and sure enough, it buffered the process! He had to wait for it go all the way back up and scroll through a second time!
Steve saved grace by telling the audience that, even with moving through the document a second time, altogether it was still faster than PDFs had been in the last version of the OS.
by mproud