Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If you're a button, you have one job

unsung.aresluna.org

Post reply on HN
Print view View original

291–300 of 308 posts

Re: If you're a button, you have one job

#291

Post by bshacklett »

amelius wrote: post #156
embedding-shape wrote: post #53

Earlier quoted context omitted.

I'm no longer the Apple/Mac/Jobs fan-boy I once was in my earlier days, but I do miss the Apple presentations that felt like they were run by a human being wanting to show off cool stuff. I couldn't even finish the last Apple presentations as it all feels so stiff, inhuman and run by suits, they all seem like robots scared of diverging from the holy script who will get fired if they display emotions and humanity. Off…

Apple keeps solving the same old problems. Why are we still talking about how well their buttons behave?

Point to another source that does it as well or better. The problems might have been solved, but it seems the majority of the industry continues to ignore them.

That said, I’ve been using Niri with Noctalia for months now, and I’m continuously delighted by the lack of astonishing behavior.

Re: If you're a button, you have one job

#292

Post by account42 »

mcv wrote: post #94
mproud wrote: post #35

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 th…

Debouncing exists for a reason. Sometimes when a button is clicked twice, you want it executed twice, sometimes you don't. Distinguishing which is better in which situation is not trivial. At the very least, you should consider which is appropriate for which situation, what if, in your UI, for some buttons one is the obvious choice, for others it's the other, but for some it's not so clear, and both behaviours are de…

Debouncing also has nothing to do with the animation shown on the screen so tying the debounce time to the animation is almost certainly wrong no matter what those tradeoffs are.

Re: If you're a button, you have one job

#293

Post by Timwi »

RossBencina wrote: post #131
Timwi wrote: post #99

Earlier quoted context omitted.

It seems somewhat clear to me. You want it executed twice if and only if the operation isn't idempotent. Can you give an example where you think both behaviors are equally defensible?

I guess the downvotes signal disagreement, but I value the conversation in spite of disagreeing with you. I'm not sure idempotence is the only concept in play. If the operation is idempotent, well, clicking twice doesn't do anything. I'd still want to see the button light up to signal that the UI is alive, or the button could grey out or enter a "latched" state like a radio button if there is nothing to be done. Behi…

The button to place an order should 100% be idempotent. There's one order you're constructing in your shopping cart, perhaps with an internal ID, and the irreversible “commit” button should place that order, not create two separate orders.

Re: If you're a button, you have one job

#294

Post by functionmouse »

nsyne wrote: post #240
functionmouse wrote: post #234

Earlier quoted context omitted.

> what about debouncing activate button function on touch release instead of touch down?

anecdotally that feels so much worse and sluggish

It's almost certainly how all the button elements on your phone and computer currently work... Keyboard, homescreen, hamburger menus, links, you name it.

Re: If you're a button, you have one job

#295

Post by altern8 »

marcosdumay wrote: post #237
aliher1911 wrote: post #154

Earlier quoted context omitted.

Possibly a consumer air dryer problem, something-something safety. Check professional ones like Parlux, the one I checked has 2 dials: airflow and temperature. Turns on by air dial. They are also conveniently under the thumb so you can adjust without looking.

Yes it's safety related. Turning the heater on while the airflow if off is a sure way to start a fire. It could be fixed with a relay or a solid state switch on the heater, or with a multipolar toggle on the airspeed. But that's several cents more expensive than making it turn on at the heater switch.

I'm not following, that's exactly what I want, I want the fan control to also turn off/on, so fan at 0 = off, fan > 0 = on.

Re: If you're a button, you have one job

#296

Post by altern8 »

bpicolo wrote: post #184
altern8 wrote: post #149

Hair dryers normally have 2 controls, one to adjust how much air it blows, and another one to adjust how hot the jet is. When they're off, they don't blow any air so it would make sense to me to decide that the button to turn them on is the one that controls how much air it blows. It goes from 0 to 1 to turn on, so you just learned that that button changes how much air comes out of it. But no, most of them do the opp…

The Dyson Supersonic?

$400!?

Re: If you're a button, you have one job

#298

Post by simonkagedal »

Findecanor wrote: post #269
efficax wrote: post #182

Earlier quoted context omitted.

a button that debounces requests should be disabled until the action is complete instead, so you can only click it once until it is ready to be clicked again. debouncing button clicks is a design failure (it makes more sense for things like requests that happen during typing, where you don't want to stop the feedback)

I think that if you'd need to debounce requests, it would be better to put it in a pressed and/or highlighted state until the button is ready again. Then you'd indicate to the user that the press was successfully received and that pressing it again won't do any good. The buttons in an elevator panel typically work this way. They each light up to confirm a pending request to reach a floor. They each turn off when its…

They should be toggles! Every now and then I will press the wrong button and will have to wait for the elevator to stop, open doors, close doors at a floor no one wants off on.

I mean, I haven’t done the usability research, probably there are some good reasons for it’s not a good idea to just make them toggles, but I would find it neat.

Re: If you're a button, you have one job

#299

Post by m463 »

othmanosx wrote: post #288
m463 wrote: post #282

Earlier quoted context omitted.

Just to go out on a wild tangent... buttons on simple hardware devices usually have many many functions. this button has a function. but if you are powering up and hold it, it does a different function. press and hold this button and while holding it press another button for something else. The most extreme example of this kind of thing I can recall is the anduril open-source flashlight firmware: an enormous number o…

Yeah, I thought of this while writing my comment. I hate this actually, in all devices where you want to cut on the number of button there are, like a headphones for examples, having one button that does stop/play/next/prev/reset/whatever... is really annyoing, one button having too many functions is really bad UX IMO. I'd rather have another button to press once rather than holding the first one for 15 seconds to do…

gah you have described something I do 100 times a day. I listen to audiobooks and skip back is click-click-click of main button.

Why can't I get audiobook-friendly headphones?

on the other hand, I do have a page-turner device for reading ebooks: https://www.amazon.com/dp/B0DS26MQZM

imperfect but lazy-optimized-wonderful

Re: If you're a button, you have one job

#300

Post by odyssey7 »

gobdovan wrote: post #85
odyssey7 wrote: post #78

Are there times when, during a call, pressing an iPhone’s screen-on/off button will end the call, but other times when it will just turn the screen off? I still do not know the pattern, but I have on occasion inadvertently ended a call by using that button prior to placing my iPhone in my pocket.

When on Speaker/hands-free mode, it just closes screen. They assume you wouldn't press lock button while against your ear, because it closes the screen automatically. The problem is that there's some bugs that keep the screen open sometimes, or you may use it in a quiet room as if it were on hands-free.

I appreciate this reply. Even as a technical reader, these concepts are somewhat tricky to follow. In my opinion, this is more of a foot-gun than a feature. A user cannot know whether the screen is closed or not while it is next to their ear—and it’s possible that related inconsistent detection isssues sometimes automatically close the screen when the phone is not against the ear.
Post reply on HN