4 ms·

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 demoin

by mproud 3mo ago

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.

embedding-shape 3mo ago
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-topic perhaps, but got reminded how delightful even the somewhat messy ad-hoc presentations from Jobs were.
- port11 3mo ago
  The scripted talks in front of fancy backgrounds do make it unpalatable, it’s just a fancier version of corporate slideshows. I suppose trillion-dollar companies aren’t as willing to take risks.
  - pixelatedindex 3mo ago
    > I suppose trillion-dollar companies aren’t as willing to take risks. Which to me makes no sense, surely you have some budget for risks if you are a 1T company? I suppose their risks are more moonshots to some degree like the Apple Car but nevertheless, I do miss the old presentations.
- vishnugupta 3mo ago
  I agree 100%. I stopped watching after iPhone 15 event or maybe M2. Absolutely everything seems scripted including hand movements, shifting of postures, smiles..the whole works. Now I just wait for the press release and that’s that.
- amelius 3mo ago
  Apple keeps solving the same old problems. Why are we still talking about how well their buttons behave?
  - embedding-shape 3mo ago
    If anything it seems to be getting worse with each iteration for long time. I guess I'm cautiously optimistic they'll get back closer to their roots with some high-level change, but really don't care that much about it these days either...
    - bshacklett 3mo ago
      Truly. The number of times I’ve been surprised by something on newer macOS versions and thought: “I think this used to go against the human interface guidelines” is crazy. IMO: the first major sign of the downfall was when stealing focus on OS X became common. Jobs had no problem calling BS on annoying behavior. Unfortunately we’ve completely lost that, and Apple is no longer the bastion of usability that it once was.
  - bshacklett 3mo ago
    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.
atoav 3mo ago
Button ≠ Button. People like to believe they should all be the same, but they really should not be. On physical keyboards we already have three different kinds: normal buttons, modifier keys (shift, etc) and toggle keys (caps lock). High stakes rare actions can require special button designs. E.g. on a black magic cinema camera the button that formats the memory card needs to be held for three second while it visually counts down. This gives a small delay during which the user can decide: "Fuck this is the wrong memory card!" and cancle. The downside is that some imaginary power user that uses the camera only to format a stack of SSDs will get burdened. You have to decide which is more common and make a decision.
mcv 3mo ago
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 defensible? Now you've got an inconsistent UI. I have no good solution for this.
- Timwi 3mo ago
  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?
  - deleted 3mo ago
    [deleted]
  - RossBencina 3mo ago
    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.
lucumo 3mo ago
> How about when users accidentally click too much, or they believe the first click didn’t register? I was really confused at their mention of accessibility, because my mind jumped to people with hand tremors who would double press when they intended only one press. And then, of course, there are the people that double-click every button. To handle that, disabling a submit button in the onclick is very common.
- edyg 3mo ago
  Got here to comment on the same. Was really surprised how the narrative turned at this point
chrismorgan 3mo ago
That was a common problem in JS-based menu opening and closing, long ago: they were treated as animations and queued. This was sometimes quite ludicrous. Nowadays, you use transitions instead, which are not queued. But I still very occasionally see things that use queued animations.
krautsauer 3mo ago
"How about"? These situations might exist, but this clearly isn't one. Two reasons: 1. "The Nothing Phone button gives you a tap confirmation via both haptics and sound, and then ignores the tap […]" 2. There is a really good reason to tap this button 3 times in a row.
Self-Perfection 3mo ago
From the article: > The Nothing Phone button gives you a tap confirmation via both haptics and sound, and then ignores the tap if a previous rotation is still animating. This is the issue. Number of performed actions has to be equal to number of times the app identified that button press was registered. Debouncing is a good practice, but if it is used then debounced taps must not produce feedback.

by mproud 3mo ago

embedding-shape 3mo ago

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-topic perhaps, but got reminded how delightful even the somewhat messy ad-hoc presentations from Jobs were.

port11 3mo ago
The scripted talks in front of fancy backgrounds do make it unpalatable, it’s just a fancier version of corporate slideshows. I suppose trillion-dollar companies aren’t as willing to take risks.
- pixelatedindex 3mo ago
  > I suppose trillion-dollar companies aren’t as willing to take risks. Which to me makes no sense, surely you have some budget for risks if you are a 1T company? I suppose their risks are more moonshots to some degree like the Apple Car but nevertheless, I do miss the old presentations.
vishnugupta 3mo ago
I agree 100%. I stopped watching after iPhone 15 event or maybe M2. Absolutely everything seems scripted including hand movements, shifting of postures, smiles..the whole works. Now I just wait for the press release and that’s that.
amelius 3mo ago
Apple keeps solving the same old problems. Why are we still talking about how well their buttons behave?
- embedding-shape 3mo ago
  If anything it seems to be getting worse with each iteration for long time. I guess I'm cautiously optimistic they'll get back closer to their roots with some high-level change, but really don't care that much about it these days either...
  - bshacklett 3mo ago
    Truly. The number of times I’ve been surprised by something on newer macOS versions and thought: “I think this used to go against the human interface guidelines” is crazy. IMO: the first major sign of the downfall was when stealing focus on OS X became common. Jobs had no problem calling BS on annoying behavior. Unfortunately we’ve completely lost that, and Apple is no longer the bastion of usability that it once was.
- bshacklett 3mo ago
  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.

atoav 3mo ago

Button ≠ Button. People like to believe they should all be the same, but they really should not be. On physical keyboards we already have three different kinds: normal buttons, modifier keys (shift, etc) and toggle keys (caps lock). High stakes rare actions can require special button designs. E.g. on a black magic cinema camera the button that formats the memory card needs to be held for three second while it visually counts down. This gives a small delay during which the user can decide: "Fuck this is the wrong memory card!" and cancle. The downside is that some imaginary power user that uses the camera only to format a stack of SSDs will get burdened. You have to decide which is more common and make a decision.

mcv 3mo ago

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 defensible? Now you've got an inconsistent UI. I have no good solution for this.

Timwi 3mo ago
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?
- deleted 3mo ago
  [deleted]
- RossBencina 3mo ago
  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.

lucumo 3mo ago

> How about when users accidentally click too much, or they believe the first click didn’t register? I was really confused at their mention of accessibility, because my mind jumped to people with hand tremors who would double press when they intended only one press. And then, of course, there are the people that double-click every button. To handle that, disabling a submit button in the onclick is very common.

edyg 3mo ago
Got here to comment on the same. Was really surprised how the narrative turned at this point

chrismorgan 3mo ago

That was a common problem in JS-based menu opening and closing, long ago: they were treated as animations and queued. This was sometimes quite ludicrous. Nowadays, you use transitions instead, which are not queued. But I still very occasionally see things that use queued animations.

krautsauer 3mo ago

"How about"? These situations might exist, but this clearly isn't one. Two reasons: 1. "The Nothing Phone button gives you a tap confirmation via both haptics and sound, and then ignores the tap […]" 2. There is a really good reason to tap this button 3 times in a row.

Self-Perfection 3mo ago

From the article: > The Nothing Phone button gives you a tap confirmation via both haptics and sound, and then ignores the tap if a previous rotation is still animating. This is the issue. Number of performed actions has to be equal to number of times the app identified that button press was registered. Debouncing is a good practice, but if it is used then debounced taps must not produce feedback.