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

231–240 of 308 posts

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

#231

Post by Telaneo »

PunchyHamster wrote: post #142
hypfer wrote: post #73

Earlier quoted context omitted.

I don't want my image editor to feel like something in a creative manner though. I want it to rotate an image by 90° when I tap the button that does that. See, this is exactly my point when I say that animations are no end in themselves. They serve a supporting role to better get the actual job done. The actual job is not "feel" it is "do". For vibes, there are movies, Art, and AI hallucinations. Of course, "feel" ca…

> The age-old debate "form follows function" vs "form over function", essentially. It's not a debate. If you are making app to do something, "form follows function " is always the right choice. If anyone on UI/UX team tells you different you should fire them, they are not interested in making good UIs. If it comes out ugly, well, you need to get good at making useful stuff also look nice "form over function" only app…

I'm imagining someone doing the maths on the suffering created by programs prioritising form over function. How many times have people got annoyed (or worse) at a program because they couldn't get it to work, compared to how many times people have got annoyed because a program didn't look all that great?

I doubt the pleasure of aesthetically pleasing programs can weight up for much. Then there are the ugly and bad programs too. Those have no redemption to speak of.

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

#232

Post by elxr »

Telaneo wrote: post #220
elxr wrote: post #209

Earlier quoted context omitted.

And? What does that have to do with the merits/downsides of flat UI?

Having people getting used to computers is not a thing that stops happening (short of people not having computers). Literally everyone who is born will need to get used to use computers. 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…

You can reference other things without resorting to skeomorphism. Like using stars to represent favorites, typography to emphasisze/deemphasize things, the color red for warnings/errors, the color green for go/submit/ready, or the clearest of all: using descriptive naming in buttons and having self-documenting labels.

Skeuomorphic UIs absolutely have a place in things like games and tutorials for the youngest of children (like 5-6 yr olds, max), but past that, I honestly think labelling, a UI with feedback after significant inputs (like sounds, button states being extremely distinct, animations, etc), and not overcrowding the UI with too many controls and jargon will all go much further than skeuomorphism.

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

#234

Post by functionmouse »

CWuestefeld wrote: post #206

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

> what about debouncing

activate button function on touch release instead of touch down?

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

#236

Post by Telaneo »

elxr wrote: post #232
Telaneo wrote: post #220

Earlier quoted context omitted.

Having people getting used to computers is not a thing that stops happening (short of people not having computers). Literally everyone who is born will need to get used to use computers. 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…

You can reference other things without resorting to skeomorphism. Like using stars to represent favorites, typography to emphasisze/deemphasize things, the color red for warnings/errors, the color green for go/submit/ready, or the clearest of all: using descriptive naming in buttons and having self-documenting labels. Skeuomorphic UIs absolutely have a place in things like games and tutorials for the youngest of chil…

> Like using stars to represent favorites, typography to emphasisze/deemphasize things, the color red for warnings/errors, the color green for go/submit/ready,

Screw the dyslexic and colourblind, I guess.

> using descriptive naming in buttons and having self-documenting labels.

Screw the non(-native)-English speaking in this case.

And even in the case that you're a native speaker, this is really hard to do well. You should try. Most fail.

I agree you should do these things, and many of your other suggestions (within reason) if only to give your users a better chance at understanding your software, but they cannot replace a solid grounding in the real world. We should have both.

What's clearer? [Call] or [(telephone receiver emoji) Call]?

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

#237

Post by marcosdumay »

aliher1911 wrote: post #154
altern8 wrote: post #149

Hair dryers normally have 2 controls, one to adjust how much air it blows, and another one to adjust how hot the jet is. When they're off, they don't blow any air so it would make sense to me to decide that the button to turn them on is the one that controls how much air it blows. It goes from 0 to 1 to turn on, so you just learned that that button changes how much air comes out of it. But no, most of them do the opp…

Possibly a consumer air dryer problem, something-something safety. Check professional ones like Parlux, the one I checked has 2 dials: airflow and temperature. Turns on by air dial. They are also conveniently under the thumb so you can adjust without looking.

Yes it's safety related. Turning the heater on while the airflow if off is a sure way to start a fire.

It could be fixed with a relay or a solid state switch on the heater, or with a multipolar toggle on the airspeed. But that's several cents more expensive than making it turn on at the heater switch.

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

#238

Post by QuercusMax »

Someone wrote: post #199
efficax wrote: post #182

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

This is a fundamental misunderstanding of how GUIs must necessarily work. There should be no possibility of race conditions if you understand the threading model.

The visual representation updating (greying out button) is a result of disabling the button, not the same thing. In virtually every GUI toolkit I've ever used there is the concept of the main UI thread, and everything that happens (input and display updates) necessarily has to go through that single thread in order to ensure correctness. (This applies to browsers, too.) That's why input goes into a queue, so you can easily do things like:

(All on the main UI thread):

  - Receive click event 1: disable button, start background process. Possibly redraw button UI *but it doesn't matter because the UI display is not the state, it's just a view*.

  - Receive click event 2: nothing happens, button is disabled

  - Background process finishes, posts update to re-enable the button

  - Receive click event 3: disable button, start background process, etc.

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

#239

Post by jonahx »

PunchyHamster wrote: post #140
kccqzy wrote: post #122

Earlier quoted context omitted.

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

I think the better solution for a web page login form specifically is to disable the button "onPressDown", so this error path is impossible.

For users with JS disabled, your solution seems good.

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

#240

Post by nsyne »

functionmouse wrote: post #234
CWuestefeld wrote: post #206

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

> what about debouncing activate button function on touch release instead of touch down?

anecdotally that feels so much worse and sluggish
Post reply on HN