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

51–60 of 308 posts

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

#51

Post by ludicrousdispla »

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.

Yeah, that is an issue in Apple Maps.

If you tap for directions and then tap to change the mode of transportation as it's loading the routes then it thinks you've picked the first route because it bumps the transport mode panel up in order to show the first route in the list.

Very annoying as they could just account for the height of the first route from the start.

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

#52

Post by simonklitj »

bloak wrote: post #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…

I suppose a lack of testing and an assumption that the action will fail so rarely that it’s not worth accounting for? But yes, such patterns make it hard to trust and efficiently use an interface.

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

#53

Post by embedding-shape »

mproud wrote: post #35

How about when users accidentally click too much, or they believe the first click didn’t register? I am still reminded of a keynote where Steve Jobs was demoing how much faster PDF documents would display on the newer macOS. So he had engineers put a button in for him to click that would scroll through the PDF on the screen, and he accidentally clicked it more than once. Steve wondered aloud if it would scroll all th…

I'm no longer the Apple/Mac/Jobs fan-boy I once was in my earlier days, but I do miss the Apple presentations that felt like they were run by a human being wanting to show off cool stuff.

I couldn't even finish the last Apple presentations as it all feels so stiff, inhuman and run by suits, they all seem like robots scared of diverging from the holy script who will get fired if they display emotions and humanity.

Off-topic perhaps, but got reminded how delightful even the somewhat messy ad-hoc presentations from Jobs were.

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

#54

Post by xigoi »

Retric wrote: post #34
Taek wrote: 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.

What’s wrong with flat UIs? Skeuomorphic designs have served their purpose of helping people get used to computers, but now that is no longer necessary.

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

#56

Post by hypfer »

selestify wrote: post #49
Retric wrote: post #34

Earlier quoted context omitted.

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?

Speaking entirely out of my ass here:

FOMO for sure is one of the driving factors.

"We cannot risk looking outdated". So weak management, probably.

But also talent availability I suppose. If there's a new trend, the pool of people you can hire include many that are in on that trend.

UI frameworks too, probably. The modern thing™ does the modern thing™ and you do want to be on the modern thing, because you fear that only that receives security fixes or whatever.

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

#57

Post by Gabrys1 »

sph wrote: post #20
kazinator wrote: post #8

We like buffering of keystrokes or gestures when the system is completely reliable, exhibits reasonable latency and low jitter in its latency.

Even in unstable or high latency I like the buffering. I’m thinking of a remote shell, where you want to type a command blindly, and see it appear seconds later, because keys got buffered in the Internet pipes. Without buffering it would feel awful, having to wait a full roundtrip per keystroke

please, use mosh, if this is available for you

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

#58

Post by Gabrys1 »

anilgulecha wrote: post #21

Camera app should negate the need. most pictures are of people and scenary, and 99.99% of the time the intent is to take the photo in the right order. Simple totally offline ONNX models exist, whcih should make it trivial to categorize the right orientation. Acceleometer/magnetometer can feed this, but should not be the default. Just do this and avoid the hassle of rotating at all!

This is so true. Sorry you got downvoted.

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

#59

Post by hypfer »

xigoi wrote: post #54
Retric wrote: post #34

Earlier quoted context omitted.

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.

What’s wrong with flat UIs? Skeuomorphic designs have served their purpose of helping people get used to computers, but now that is no longer necessary.

[flagged]

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

#60

Post by csande17 »

bloak wrote: post #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…

> Why? How, even, have they implemented this?

This is really common because of two design features that most UI frameworks share:

- The code that changes the color of the button is an internal part of the "button" component, so that people don't have to individually implement it on every button. But this means that it's kind of disconnected from the code that actually performs the action. If the "on click" handler has some last-ditch check that aborts the action, like the "don't rotate the image if it's in the middle of the rotate animation" check from the article, often there's no way for it to tell the button to cancel the color change. (And conversely sometimes the "on click" handler can fire even if the color change animation doesn't play correctly.)

- Buttons usually change color when you press down the mouse button, but only perform the action when you release the mouse button. Sometimes this is used to intentionally give you a chance to cancel the action at the very last minute by dragging your mouse off the button while it's still held down (or, on mobile, to e.g. reinterpret your interaction as scrolling instead of clicking), other times it just creates more opportunities for something to happen that prevents the action from working after the color change has already happened.

Post reply on HN