Live data from Hacker News

If you're a button, you have one job

unsung.aresluna.org

41–50 of 308 posts

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

#41
The author suggests they want three clicks at any pace to always == the same functionality, so they can whiz through their photos and rotate each predictably. Fair.

> And it would be so much more predictable and pleasant if you could just tap the button three times at any pace you wanted without thinking, without paying attention, without getting your UI blocked by an animation that no longer helps you.

They cite accessibility.

The thing is, I can imagine the complete opposite side of the argument, where someone with motor impairments or parkinson's, for example, ideally liking if their over-clicks were ignored if they'd already locked-in their intention.

It's tricky to get this stuff right.

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

#43
post #40

I understand the design principle but I would argue it's a bad implementation principle. Engineering attention is finite. Why would you spend time thinking about 8 clicks when most people will only need ~3? Not all user-action possibilities are equally important, and if they are, then you better have infinite resources to spend on engineering.

It's not really a question of how many taps they support, but how fast.

This same issue also seems like it would prevent you from quickly double-tapping the button to turn an image upside-down, a much more common use case.

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

#44

The author suggests they want three clicks at any pace to always == the same functionality, so they can whiz through their photos and rotate each predictably. Fair. > And it would be so much more predictable and pleasant if you could just tap the button three times at any pace you wanted without thinking, without paying attention, without getting your UI blocked by an animation that no longer helps you. They cite acc…

iOS has an accessibility option called "Ignore Repeats", which seems like a better approach because it's system-wide. So people who need that kind of accommodation can have it in places like the on-screen keyboard too, without needing everyone else to slow down their typing.

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

#45
post #34
post #30

Earlier quoted context omitted.

I wish software apps had "tape-out rules" the way that computer chips do. Basically, when you design a computer chip, a program reviews the design and compares it against something like 300 pages of rules with stuff like "wires of X metal and Y metal can't be within Z distance of each other". We could make something similar for UX. Just a bunch of design pattern constraints that throw flags if you try to ship somethi…

There’s effectively no universal list of UX warts people agree with. The Flat UX fad was objectively terrible on just about every metric I was taught, but people were actively pushing for such designs.

But there are things like consistency which one can check for. And should.

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

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

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

#47

The author suggests they want three clicks at any pace to always == the same functionality, so they can whiz through their photos and rotate each predictably. Fair. > And it would be so much more predictable and pleasant if you could just tap the button three times at any pace you wanted without thinking, without paying attention, without getting your UI blocked by an animation that no longer helps you. They cite acc…

I don't think this is something every UI widget ever should have to think about.

It could probably be done as a global device setting - e.g. ignore taps within 100ms if they're within 50px of each other or whatever.

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

#48

The author suggests they want three clicks at any pace to always == the same functionality, so they can whiz through their photos and rotate each predictably. Fair. > And it would be so much more predictable and pleasant if you could just tap the button three times at any pace you wanted without thinking, without paying attention, without getting your UI blocked by an animation that no longer helps you. They cite acc…

iOS has an accessibility option called "Ignore Repeats", which seems like a better approach because it's system-wide. So people who need that kind of accommodation can have it in places like the on-screen keyboard too, without needing everyone else to slow down their typing.

That's good. I wonder if it should be opt-in instead of opt-out. Disabled people are arguably less able to find random configuration options than non-disabled counterparts. I get a bit bothered with how undiscoverable these options are. But power-users by their nature don't mind going to the extra mile to get perf out of their experiences.

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

#49
post #34
post #30

Earlier quoted context omitted.

I wish software apps had "tape-out rules" the way that computer chips do. Basically, when you design a computer chip, a program reviews the design and compares it against something like 300 pages of rules with stuff like "wires of X metal and Y metal can't be within Z distance of each other". We could make something similar for UX. Just a bunch of design pattern constraints that throw flags if you try to ship somethi…

There’s effectively no universal list of UX warts people agree with. The Flat UX fad was objectively terrible on just about every metric I was taught, but people were actively pushing for such designs.

Why was that? What causes such fads? Why did everyone go along with it?

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

#50
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 purely software buttons that somehow seem to replicate this broken behaviour: whether the button changes colour on the screen is somehow only loosely correlated with whether the action requested will take place. Why? How, even, have they implemented this?
Post reply on HN