Earlier quoted context omitted.
The Dyson Supersonic?
$400!?
Pretty common to find at $300 on sale or whatnot.
People love it.
If you're a button, you have one job
301–308 of 308 posts
Re: If you're a button, you have one job
#302Earlier quoted context omitted.
I have only iphone, but from my experience, apple ui quality is just a huge myth nothing to do with reality. On average it is has same amount of crappy UI experience, just in different places.
How can you compare if you have only iPhone?
I had an android before that.
Maybe their laptop experience is completely on another league, but I have doubts
Re: If you're a button, you have one job
#303Earlier quoted context omitted.
Now remove the spacebar, combine the two buttons into a single one for "tone" and adapt it to morse code. All the buttons still do only one thing and now there's only one button! And, you don't have to worry about what to do in the case that someone hits the "rotate ball" button while it's still rotating.
> And, you don't have to worry about what to do in the case that someone hits the "rotate ball" button while it's still rotating. Eh, it's a pretty trivial problem, comptometers have it figured out more than a hundred years ago.
If you're suggesting that the different columns of a comptometer would relate to different rotational axes of the ball, you will likely run into gimbal lock in 3D.
You could build an interface in 4D around quaternions but that is much more complicated than my suggestion (even including the part where you learn morse code).
The quoted part of my comment is in reference to the core topic of TFA where iOS and Nothing/Android photo apps handle the "pressed again during rotation" action differently. That "rotate the typewriter ball" interface runs against the same problem, by necessity of rotating a physical ball.
Re: If you're a button, you have one job
#304Earlier quoted context omitted.
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.
Imagine the backlight of the button is broken. Now you enter the elevator and want to go to floor 7, while someone else already pressed the button ;)
Re: If you're a button, you have one job
#305Earlier quoted context omitted.
> But a button that works like that in a GUI would feel wrong. No, it doesn't. It feels way more responsive. My pet peeve is "stopwatch apps" which trigger on release instead of on press. When timing something where fractions of a second matter, most people won't realize that it triggers on release and tap down when they want to start / stop, adding some arbitrary delay until they actually release the button.
No, even for stopwatch, trigger on release is the correct choice, as it’s more precise. When tapping, I have to see, or in case of watching for some event to happen to stop the time, feel/guess when exactly the distance between screen and finger approaches zero. With a stop button triggered by release however, I can just calmly rest my finger on it and raise when the event happens, without any guesswork.
My point was about user expectations / users not being aware when the button triggers. Your argument has nothing to do with that.
Re: If you're a button, you have one job
#306Earlier quoted context omitted.
How does a real stopwatch work? Hint: it starts/stops on press, not release. So that's what the app should do, to map with prior expectations. "Nobody uses real stopwatches anymore" might be somewhat true, but in athletics training they still do, and it just shows that it's not possible to adequately reproduce a thing on a touch screen and have it be as functional as the real item. A stopwatch app on a phone will alw…
Yes, but on a real stopwatch, or on a computer mouse, you can rest your finger on the button with almost but not quite enough force to actuate it, and activate it with a press. On a touch screen you have to hover your finger over the button and move it down some indeterminate distance to actuate the button. The equivalent to the above example for a touch screen is to activate on release, as you can rest in a state “r…
Interestingly the "activate on release" logic was implemented in computer GUIs long before touchscreens were common, used purely by mouse-click (a physical button).
Re: If you're a button, you have one job
#307Earlier quoted context omitted.
> And, you don't have to worry about what to do in the case that someone hits the "rotate ball" button while it's still rotating. Eh, it's a pretty trivial problem, comptometers have it figured out more than a hundred years ago.
If you're suggesting that the different columns of a comptometer would relate to different rotational axes of the ball, you will likely run into gimbal lock in 3D. You could build an interface in 4D around quaternions but that is much more complicated than my suggestion (even including the part where you learn morse code). The quoted part of my comment is in reference to the core topic of TFA where iOS and Nothing/An…
I am suggesting that the whole keyboard can lock during the time the physical ball rotates; the comptometers and pinwheel arithmometers of the yore had this functionality: while the mechanism was performing the addition of the number just entered, the user was blocked from fiddling with the input mechanism.
Re: If you're a button, you have one job
#308Earlier quoted context omitted.
If you're suggesting that the different columns of a comptometer would relate to different rotational axes of the ball, you will likely run into gimbal lock in 3D. You could build an interface in 4D around quaternions but that is much more complicated than my suggestion (even including the part where you learn morse code). The quoted part of my comment is in reference to the core topic of TFA where iOS and Nothing/An…
I am suggesting that the whole keyboard can lock during the time the physical ball rotates; the comptometers and pinwheel arithmometers of the yore had this functionality: while the mechanism was performing the addition of the number just entered, the user was blocked from fiddling with the input mechanism.
I get that's what you're suggesting. The locking per-axis or across all axes is fine but doesn't address the problem I'm talking about. In gimbal lock, which many graphics programmers first encounter by using only sequential rotations around the camera's axes, you can get into an orientation where you lose one of the three degrees of freedom.