211–220 of 308 posts
I used to have a device with a physical button which, when you pressed it, would beep and add 30 seconds to the time. However, sometimes it would beep and not add 30 seconds, and sometimes it would add 30 seconds without beeping, so you always had to squint at the dim display to discover whether it had worked or not. I thought this must be a peculiarly bad design ... but since then I have lost count of the number of…
Earlier quoted context omitted.
The newly born people grow up in a world where computers are already commonplace, so they don’t need to get used to them.
Wild take. They’re not born “used to them,” so at some point they quite literally need to get used to them…
Earlier quoted context omitted.
Perhaps we’re not talking about the same thing. What I refer to has the button light up while you bump it, and then go dark again, whereas if you press it more deliberately, it stays lit (and takes effect). This can apply to the buttons inside or outside the lift.
It does sounds somewhat reasonable on paper. But some of the crosswalk buttons in Belgium have this as well, and it's really jarring. You press the button, see the light go on and look away to look at the traffic light and wait for it to turn green. Except 20 seconds later you look back and the indicator light is off again. I feel very strongly that the indicator light should only turn on when your press has been reg…
The more complex the intersection, the more controls I can watch, to get a feel for the rhythm, patterns, and triggers that influence the cue to activate my “WALK” signal.
I’m also watching the cars to see when the flows slow down or stop. I should perhaps pay more attention to the signal that pertains to me as a pedestrian or motorist...
Earlier quoted context omitted.
It's interesting that we're so used to the GUI buttons having that specific behavior of only triggering when releasing, even if you exit and enter the button area while holding the mouse button down, etc. IRL 99%+ of buttons work by just doing the thing as soon as you press them. But a button that works like that in a GUI would feel wrong.
> 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.
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.
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 want to support the "what about debouncing" argument mentioned elsewhere; the author shouldn't just ignore this. But I also hate the "you had one job" meme and want to argue against its mindless usage. Most of the time, when people do the "you had one job" thing, it's false. And that's true most of the time in the case of buttons, too. In a typical user interface, a given button has some combination of these jobs:…
Earlier 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.
"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 always be a poor substitute for a real stopwatch.
Earlier quoted context omitted.
The power button of my pc also has the job to tell wether the PC is turned on. So do bulb switch buttons that have a pilot light, and so on
Yeah, sometimes, when I am sitting before my computer and typing comments on the Internet, I have a thought: "Is my computer turned on?" With a quick glance under my table I can reassure myself that it is indeed on and continue using it. No idea what I'd do without that small blue LED. The pilot lights are slightly more useful in those stupid cross-wired double switches that for some weird reason implement a sort of…
Earlier quoted context omitted.
New people are born every day.
And? What does that have to do with the merits/downsides of flat UI?
Having computers imitate real world items is useful, because it provides a reference to other things rather than just being its own unique thing. This is useful even if you have never actually used it outside of a computer setting. A stereotypical telephone receiver icon almost always means 'call', even if you've never used a landline phone (much less one that's shaped like that icon usually is). Nobody has ever used a real-world hamburger menu, yet it's described in skeumorphic terms, since it's easier to explain and relate to.