Earlier quoted context omitted.
A programmer had a problem, so they decided to use threads. Now they have at least two problems.
> Now they two . at least problems have FTFY
Thank ve.ry you much
If you're a button, you have one job
281–290 of 308 posts
Re: If you're a button, you have one job
#282One 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…
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 of functions on a one-button flashlight.
example: https://budgetlightforum.com/uploads/default/optimized/3X/e/...
or in text: https://ivanthinking.net/manuals/anduril2-manual/
Re: If you're a button, you have one job
#283Earlier quoted context omitted.
The correct action is to disable the button while the request is in flight so it can't be clicked a second time. Otherwise you won't see "user already logged in", because the user won't be logged in until the previous request returns (a race condition).
If you have a race condition, "correct action" is to solve that, because you shouldn't be papering over server-side bugs with client-side Javascript (and yes, it's a bug, because I shouldn't see an error page if I press the back button after logging in (and trying to navigate to what I was doing before logging in) either, which I still see quite often)
How would you solve this on the server?
Re: If you're a button, you have one job
#284Earlier 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)
There always will be time between the first click and the time the button gets disabled and even more time before the visual representation of the button gets updated to reflect that. Keeping that time so short that it is impossible for a human to click the button again can be very hard. It would help if GUI elements had a property “automatically disable on click”, removing the need for the “on click handler” to disa…
Of course, it's never impossible for the user to click a button. They can click on anything under their cursor. The key is giving them feedback to show them what their clicks will do or just did. If you can update the visuals within a frame or two, that's already fast enough to give that feedback.
Re: If you're a button, you have one job
#285If you're a button, you have one job: to transmit Morse code from the finger to the machine, Morse code representing a complicated POSIX shell command. And also to power down this entire one-button terminal with a 3 second press, power it up on any button press, with a firmware reset if powered up by a 30 second press.
Now I am imagining a typewriter with just two huge round buttons, next to each other horizontally, and a spacebar bellow them: *-----* *-----* | | | | | ● | | Ω | | | | | *-----* *-----* [================] A press of each round button rotates the typing ball accordingly, pressing the space prints the chosen letter and resets the ball to the neutral state. This whole thing should probably be electric lest you'd have t…
Seeing this makes me think of the controls from the original arcade version of Street Fighter 1.
Re: If you're a button, you have one job
#286There's so many comments here railing against Android but... I can't recreate this at all? With Android 16 on a Pixel 7 using the Google photos app, if I tap the rotate button 8 times it dutifully queues the animations and ends up with a no-op (not even prompting you to save when you exit the view). This is exactly the behaviour one would expect, no?
Screen recording here (lower frame rate due to the recording, there's no stutter in normal usage): https://photos.app.goo.gl/45PjSYMMvAc8fxA57
Re: If you're a button, you have one job
#287How 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…
> 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.
Got here to comment on the same. Was really surprised how the narrative turned at this point
Re: If you're a button, you have one job
#288One 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…
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 some other thing
Re: If you're a button, you have one job
#289Just tested on xiaomi hyperOS, and their copying of iOS has gone to such lengths that it works the same, it buffers the clicks properly
Re: If you're a button, you have one job
#290Earlier quoted context omitted.
Apple keeps solving the same old problems. Why are we still talking about how well their buttons behave?
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...
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.