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

131–140 of 308 posts

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

#131

Post by RossBencina »

Timwi wrote: post #99
mcv wrote: post #94

Earlier quoted context omitted.

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…

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. Behind the scenes suppressing command propagation is an implementation detail and the trade off is between front-end complexity and redundant command execution overhead.

If the operation is not idempotent I can give you separate examples where different behaviors are appropriate:

1. A button used to increment a counter (e.g. quantity of GPUs to buy) should increment on every click, even if the UI response is delayed. The user can count clicks, and there is going to be a decrement button to reverse any error. You do not want the user waiting around guessing whether the software is still processing the remaining clicks. As a rule, so long as the operation is non-destructive (e.g. inc and dec buttons, all operations reversible/undoable, etc.) every user interaction can and should be actioned.

2. A button used to perform an irreversible action, i.e. a "commit", such as placing the order to purchase a GPU, should only perform that operation once. I would not call this an idempotent operation, certainly not with respect to your bank balance.

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

#132

Post by crote »

rowyourboat wrote: post #68
csande17 wrote: post #60

Earlier quoted context omitted.

> Why? How, even, have they implemented this? This is really common because of two design features that most UI frameworks share: - The code that changes the color of the button is an internal part of the "button" component, so that people don't have to individually implement it on every button. But this means that it's kind of disconnected from the code that actually performs the action. If the "on click" handler ha…

> there's no way for it to tell the button to cancel the color change No, but what should happen in cases like that is that the on-click handler disables the button while it is unresponsive. This will communicate the fact that the button is unresponsive visually to the user and also inhibit the button-was-pressed feedback.

Simply disabling the button leads to people thinking something is broken, so you need to add a visual "disabled" state - which should probably be separate from the "you are currently pressing the button" state.

In most cases that is going to lead to annoying pointless flickering as most actions & animations are basically instantaneous, and with touchscreens even in the non-pointless scenarios it won't have the desired effect as the button itself will be hidden from the user by their own finger.

In principle I think you are right, but in practice buffering presses is often probably the more user-friendly option.

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

#133

Post by benj111 »

hypfer wrote: post #101
benj111 wrote: post #79

Earlier quoted context omitted.

I think you're being overly hostile. The parents question seems reasonable to my non designy mind.

Yes in a vacuum. No on the Internet. Especially not on the sea-lion infested HR-world Internet, in which trolling has evolved to exploit good faith directly. ___ In fact, "being overly hostile" is exactly how you probe to see whether your suspicions are correct. Sea lioning exploits the gap between what would be a real human thing to do and what still passes as what a real human would do. So to get useful data, you n…

> (This should not be understood as "just be overly hostile" because simply being a dick doesn't provide any data at all.)

If you're a dick for a reason, you're still being a dick. (Your word not mine)

And I don't see how your approach makes discourse any better.

To me the parents question was reasonable. Skeuomorphism was designed for people that may never have seen a computer before. Do we need to still be clicking a floppy disc to save a file?

There's probably differences in how you define flat design. You could include all the issues of current implementations in that definition, or you could say that the burger menu is just bad UX and could be fixed without going back to skeuomorphism.

But you haven't really delved into that.

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

#134

Post by earth-tattoo »

kccqzy wrote: post #122
mcv wrote: post #94

Earlier quoted context omitted.

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…

It’s really common for people to accidentally click a button twice. Yeah that’s what denouncing is for. My favorite example of doing it wrong is a log in form: if the login button is clicked twice, the server would reject the login because the first click has already used up the one-time token so the user gets an error page. But I think the biggest problem is that people either apply denouncing to all buttons in a UI…

[flagged]

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

#135

Post by greatgib »

padolsey wrote: post #41

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

I totally agree, even not going as far as a Parkinson case, if you already so old and not too old persons use phones and touch screens, you will see that very often it is complicated for them to click on the small button at the right place and to have the feeling that "they have clicked".

So, for me, on the argument of about accessibility, the Nothing Phone behavior will work a lot better I think. In their mind they don't count and click 6 times to put the image in a specific position. In addition with considering that it would not make much sense to click 8 times in advance to turn back in the exact position where you are.

The mindset in their case is more: click and wait, compare if it is the position you want and do it again. The other sensitive button that will bufer would probably trigger overshooting, going too far, then too back, etc... similarly to when you have issue scrolling in a list to the right spot.

The case of the iphone would be better only for someone like a younger person, tech nerd, that want things to go fast without having to wait. Same thing for computer keyboards where I could type multiple letters in advance before the first one even show up on the screen with the lag.

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

#136

Post by earth-tattoo »

hypfer wrote: post #46

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.

I have disabled all animations on my Android, and it feels so much nice. I particularly HATE that one animation where the whole screen stretches if you try to overscroll.

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

#137

Post by bentt »

My wife is a behavior analyst and I’m a game developer. We both watch people and try to figure out how why they are doing stuff and how to get them to do what we want.

One thing I learned from her is that if you want someone to stop doing something you don’t punish them, you ignore them. No response.

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

#138

Post by PunchyHamster »

crote wrote: post #132
rowyourboat wrote: post #68

Earlier quoted context omitted.

> there's no way for it to tell the button to cancel the color change No, but what should happen in cases like that is that the on-click handler disables the button while it is unresponsive. This will communicate the fact that the button is unresponsive visually to the user and also inhibit the button-was-pressed feedback.

Simply disabling the button leads to people thinking something is broken, so you need to add a visual "disabled" state - which should probably be separate from the "you are currently pressing the button" state. In most cases that is going to lead to annoying pointless flickering as most actions & animations are basically instantaneous, and with touchscreens even in the non-pointless scenarios it won't have the desire…

> Simply disabling the button leads to people thinking something is broken, so you need to add a visual "disabled" state - which should probably be separate from the "you are currently pressing the button" state.

Well, yes, dropping user inputs is "being broken"

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

#139

Post by PunchyHamster »

inigyou wrote: post #114
mrob wrote: post #108

Earlier quoted context omitted.

>averaging the last 50 reads and wait till the majority is either off or on. This is a bad way to do it because it adds avoidable latency. A moving average is a low-pass filter. The switch bounce is better handled by hysteresis. Change state as soon as you see an edge, then ignore further edges until a timer expires, e.g. 5 ms, which should be enough for the bouncing to settle. A 5 ms timeout limits your repetition r…

They didn't say how often the reads are - 50 reads could be only 5ms.

Doesn't matter, their way is terrible one that adds latency for no reason.

There are 2 things here worth paying attention

* first "bounce" is user action * last "bounce" is stop of user action.

You can run action on first bounce then just ignore the button for whatver debounce period you deem satisfactory. But adding delay to start action is always wrong answer for debouncing.

Now the harder problem is the off of the button, especially if hold is also an action but "be off for at least few ms" usually handles it well and off time is not lag user feels

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

#140

Post by PunchyHamster »

kccqzy wrote: post #122
mcv wrote: post #94

Earlier quoted context omitted.

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…

It’s really common for people to accidentally click a button twice. Yeah that’s what denouncing is for. My favorite example of doing it wrong is a log in form: if the login button is clicked twice, the server would reject the login because the first click has already used up the one-time token so the user gets an error page. But I think the biggest problem is that people either apply denouncing to all buttons in a UI…

the correct action is not to debounce but instead of error page see user already logged in in previous request and continue
Post reply on HN