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

271–280 of 308 posts

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

#271

Post by OneLessThing »

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

That's a different bad UX pattern. If a button has already rendered in a certain location, a new button shouldn't replace it without first giving the user ample warning that a material change is about to happen.

I see it as the same problem of when to accept button input. In my view having the button give "ample warning a material change is about to happen" is making the button do something more than "one job." But maybe you're right if your point is that if you're showing a button it should do the work it says it will do.

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

#273

Post by mawadev »

The worst part about this is the amount of lag you have when taking a photo. On samsung phones, its quick and seamless, on other android phones the IO is so slow, one picture is taken and before you can tap the shoot button again you have to wait until it saved the previously shot photo. Sometimes there is even a redundant animation that moves the entire frame into the little corner that points to your album to the bottom left. When there is a firework and you want to have a lot of pictures in short timeframes, this kills it. Animations in general are very annoying and inconsistent visually, it makes you unnecessarily wait or take up a lot of resources if the "native" UI is a SPA in a browser instance..

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

#274

Post by hananova »

SoftTalker wrote: post #218
d12bb wrote: post #215

Earlier quoted context omitted.

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.

How does a real stopwatch work? Hint: it starts/stops on press, not release. So that's what the app should do, to map with prior expectations. "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 alw…

Yes, but on a real stopwatch, or on a computer mouse, you can rest your finger on the button with almost but not quite enough force to actuate it, and activate it with a press.

On a touch screen you have to hover your finger over the button and move it down some indeterminate distance to actuate the button. The equivalent to the above example for a touch screen is to activate on release, as you can rest in a state “ready to click” just like on a physical button that way.

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

#275

Post by layer8 »

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.

It doesn’t just help to “get used to” computers, it continues to help even after being used to computers for decades. The fact that it helps to better recognize and distinguish UI controls from content never stops.

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

#276

Post by inigyou »

mrkeen wrote: post #205
inigyou wrote: post #160

Earlier quoted context omitted.

Why can the two things even fail at all?

This is not a bad question! If you flip it and instead ask "how do I write something that can't fail?" you might find some interesting ground. The best things I know about are static type-checking, pure functions and totality. Different languages provide more or less help with these things. It's perfectly fine to do 'two things which don't fail or cause other things to fail'. Forgive the digression, but there is an '…

The things in question were beeping and adding 30 to a variable.

The former can fail because the speaker is broken (probably not detectable by the CPU) and the latter can fail if the counter overflows, but it obviously wasn't the case because an overflow in a microwave timer is pretty obvious to the user and the user didn't mention it.

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

#279

Post by LordDragonfang »

stavros wrote: post #263
PunchyHamster wrote: post #140

Earlier quoted context omitted.

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

If you have a race condition, "correct action" is to solve that, because you shouldn't be papering over server-side bugs with client-side Javascript (and yes, it's a bug, because I shouldn't see an error page if I press the back button after logging in (and trying to navigate to what I was doing before logging in) either, which I still see quite often)
Post reply on HN