Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Front end developers: stop moving things that I’m about to click on

medium.com

Post reply on HN
Print view View original

131–140 of 365 posts

Re: Front end developers: stop moving things that I’m about to click on

#131

Post by soulofmischief »

hnick wrote: post #92
NikkiA wrote: post #15

A particular bane of mine is the self-oscillating UIs, youtube is particularly bad at it these days - if the mouse pointer is in 'just the right place' (which is bigger than it sounds) then you get the seek-bar preview frames popup, which moves things just enough that the mouse pointer is no longer over the area that triggers it, so it vanishes, and the whole thing starts again.

Following the same theme of liminal UI areas, another thing that peeves me is touch screens like my local supermarket self-checkout which respond with a beep (indicating they know I hit the button) but do nothing, because apparently the beep-region and action-region and not the same. Or maybe I dragged my finger, in which case, please don't beep.

I spent half an hour last night resolving this exact class of bug on a padded clickable widget I was making.

No one told me it had to be perfect, but I care about the user and don't ever want the user to be surprised.

That's the difference you get with outsourcing your engineering team vs developing in-house. If you choose a good team, your developers feel directly responsible for the user experience, go beyond stated requirements, and aren't just doing the bare minimum in order to make a paycheck. A good UX professional is constantly testing their work with unexpected input.

Re: Front end developers: stop moving things that I’m about to click on

#133

Post by derekp7 »

AndrewDucker wrote: post #46

Latest one to catch me out on is when receiving calls on my Pixel phone it will pop up "screen call" as an option where the "accept call" button had been half a second earlier, and not let you override it to actually accept the call.

That one caught me the other day (shortly after an Android OS update). I only saw it once, with the button down at the bottom of the screen. I can't seem to get it to do that again when I try calling my phone from another phone.

Also, your report is the only instance I've seen to confirm that this happens -- for whatever reason no one believes me when I post something about this to any Android group. Just like I seem to be alone in trying to figure out how to get the Contacts (when launched from the dialer) to show only specific groups (such as contacts with phone numbers). I can do this from the Contacts app, but not the Contacts tab inside the call dialer app.

Re: Front end developers: stop moving things that I’m about to click on

#135

Post by linsomniac »

A lot of the responses are talking about how apps should fix this, which I agree with, but I'd also like to see it at a higher level...

I'd like to see frontends (browsers, Android, iOS?) remember their widget hit points for ~400ms, and if you've touched somewhere that had a different widget hit point within that time, use the old widget.

Re: Front end developers: stop moving things that I’m about to click on

#136

Post by pasc1878 »

esprehn wrote: post #115
Oxidation wrote: post #33

Earlier quoted context omitted.

This can happen in native UIs as well. I've had to add hysteretic behaviours to prevent the appearance of a scroll bar somehow obviating the need for the scroll bar, so it vanishes and now it needs a scroll bar, repeat as fast as the toolkit event loop allows.

This is why everyone switched to overlay scroll bars. It's also better for performance because you don't need to do layout on a screen worth of content only to realize you need to reserve 16px and do layout again.

No the solution is to always show the scroll bar.

Then I don't have to guess if there is anything to scroll.

Re: Front end developers: stop moving things that I’m about to click on

#137

Post by Godel_unicode »

linsomniac wrote: post #135

A lot of the responses are talking about how apps should fix this, which I agree with, but I'd also like to see it at a higher level... I'd like to see frontends (browsers, Android, iOS?) remember their widget hit points for ~400ms, and if you've touched somewhere that had a different widget hit point within that time, use the old widget.

Or at a minimum don’t go to the new widget but just have a UI indication that you registered the touch/click.

Re: Front end developers: stop moving things that I’m about to click on

#138

Post by Godel_unicode »

princevegeta89 wrote: post #119
NikkiA wrote: post #15

A particular bane of mine is the self-oscillating UIs, youtube is particularly bad at it these days - if the mouse pointer is in 'just the right place' (which is bigger than it sounds) then you get the seek-bar preview frames popup, which moves things just enough that the mouse pointer is no longer over the area that triggers it, so it vanishes, and the whole thing starts again.

Slightly unrelated, but all these media streaming apps and services like Netflix/Prime Video/Youtube etc. are so horrible by automatically playing whatever the fuck I am currently focused on, although I am just scrolling to somewhere to find my content. There is no way for users to focus "out" of the thumbnails, other than focusing on a different thumbnail, and it keeps playing the nonsense. All I would do is go back…

At least on YouTube you can turn that off.

Re: Front end developers: stop moving things that I’m about to click on

#139

Post by Godel_unicode »

soulofmischief wrote: post #131
hnick wrote: post #92

Earlier quoted context omitted.

Following the same theme of liminal UI areas, another thing that peeves me is touch screens like my local supermarket self-checkout which respond with a beep (indicating they know I hit the button) but do nothing, because apparently the beep-region and action-region and not the same. Or maybe I dragged my finger, in which case, please don't beep.

I spent half an hour last night resolving this exact class of bug on a padded clickable widget I was making. No one told me it had to be perfect, but I care about the user and don't ever want the user to be surprised. That's the difference you get with outsourcing your engineering team vs developing in-house. If you choose a good team, your developers feel directly responsible for the user experience, go beyond state…

I disagree that this is an invariant of outsourcing; I have worked plenty of places where the contractors/vendors cared more than the FTEs. Conversely, the pressure for dark patterns has generally come from the inside.

Re: Front end developers: stop moving things that I’m about to click on

#140

Post by yxwvut »

devnullbrain wrote: post #79
romellem wrote: post #7

I agree with [this][1] idea: > an autocomplete has one chance to reorder per keystroke. if you got it wrong and you have a better ordering a bit later you must “swallow the sadness” (as per the original author of this wisdom) but never change already displayed items [1]: https://twitter.com/dan_abramov/status/1470751551568363530

I want foo. - Type 'f' - foo appears in the search. - Type 'o', because I type with 10 appendages and getting them to work together requires pipelining. - foo disappears from the search This should never happen.

Just wanted to comment in agreement and confirm that this exact scenario drives me insane. Adding more information that agrees with the existing top suggestion should never change that top suggestion.
Post reply on HN