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

261–270 of 308 posts

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

#261

Post by xigoi »

Telaneo wrote: post #256
xigoi wrote: post #255

Earlier quoted context omitted.

> Screw the dyslexic and colourblind, I guess. You can also use checkmark/cross icons for success/failure. And What does this have to do with dyslexia? > What's clearer? [Call] or [(telephone receiver emoji) Call]? We’re arguing about flat vs. skeuomorphic design, so more like: What's clearer? [(simple phone icon) Call] or [(photorealistic drawing of a telephone receiver) Call]?

> You can also use checkmark/cross icons for success/failure. And What does this have to do with dyslexia? Your comment on typography. > What's clearer? [(simple phone icon) Call] or [(photorealistic drawing of a telephone receiver) Call]? The latter.

> Your comment on typography.

That wasn’t my comment, and GP was presumably referring to things like headings being larger, not some subtle differences that dyslexic people would miss.

> The latter.

Why?

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

#263

Post by stavros »

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

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).

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

#264

Post by Telaneo »

xigoi wrote: post #261
Telaneo wrote: post #256

Earlier quoted context omitted.

> You can also use checkmark/cross icons for success/failure. And What does this have to do with dyslexia? Your comment on typography. > What's clearer? [(simple phone icon) Call] or [(photorealistic drawing of a telephone receiver) Call]? The latter.

> Your comment on typography. That wasn’t my comment, and GP was presumably referring to things like headings being larger, not some subtle differences that dyslexic people would miss. > The latter. Why?

> That wasn’t my comment

Sorry about that.

> and GP was presumably referring to things like headings being larger, not some subtle differences that dyslexic people would miss.

I was imagining bold or italics, both of which are easily missed by people who are dyslectic, or using different type faces, which can trip them up. Headings can help, if the text and spacing is suitably big, but I'm not sure what situations that can help much with in typical usage. I'm having a hard time thinking of examples where I would do that beyond what's already common.

> Why?

Easier to recognise as what it's supposed to be and easier to distinguish from other icons. More distinct traits in icons help you recognise something for what it is more quickly.

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

#266

Post by pornel »

hypfer wrote: post #46

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.

Apple used to know this. They've had animations after items were dismissed, but avoided animations before showing an item.

Old Apple understood design is more than making things pretty. The glassy Apple is all about how it looks in a demo.

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

#269

Post by Findecanor »

efficax wrote: post #182
mcv wrote: post #94

Earlier quoted context omitted.

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

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)

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 floor has been reached. And while a button is lit up, pressing it does nothing.

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

#270

Post by OneLessThing »

mvdtnz wrote: post #32
OneLessThing wrote: post #23

It's not so simple. There are times where you intend to tap one thing and something else appears underneath your finger instantaneously. So sometimes while rendering a layout you want to stop accepting input.

Sorry how is this relevant to the example?

They are both about when it is best to accept user input. In the specific example with rotating images nothing covers or moves the buttons so it is not relevant. My impression of the article was that the buttons one job was to accept input always, my argument is that there are times it's okay to not accept input, for example the short time after certain layout changes
Post reply on HN