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

311–320 of 365 posts

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

#311

Post by 00deadbeef »

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.

Spotlight on my iPhone does this.

I want my bank, Monzo.

I type Mo

It shows Monzo

But I instinctively type an 'n'

It shows a Google result for "Monica" whoever the hell that is, plus driving directions to somewhere, plus settings, plus results from my emails, plus results from my messages, plus every Easter Monday since the dawn of time from my calendar, plus a whole load of photos it decided were relevant... everything except Monzo.

Now I have to type 'z' to get Monzo to display again

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

#312

Post by frereubu »

pmg102 wrote: post #249
frereubu wrote: post #62

Earlier quoted context omitted.

It could well be naive A/B testing. "Oh, this configuration has really increased our click-through rates", not realising that it's because people are trying to click on something, and an ad jumps into the space that they're just about to click.

I love the optimism about human nature implied by the use of the phrase "not realising".

I honestly think that's the truth for the majority of cases like this, or at worst a kind of willful blindness. Of course there are the scammers, but I think they generally produce such terrible work that very few people use it on an ongoing basis. I'm sure there are examples between those two, but I reckon they're few and far between.

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

#313

Post by medstrom »

neogodless wrote: post #87
bombcar wrote: post #50

Earlier quoted context omitted.

I cannot figure out how "upd" shows Windows Update but "update" does not.

I realized the other day "stor" brings up Photos as the first result. I'm dumbfounded.

That can be desirable if the filesystem path to Photos includes a directory named something like "storage". Of course it should still prioritize apps that actually have "stor" in the name, but maybe you didn't have any?

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

#314

Post by wruza »

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.

Oh, this is close to how Android/Material buttons work. When I had that phone, I wondered at least once a day why a button is visually reacting (material “wave” effect) when I tap it but does nothing.

It may even be the same thing you described, if they somehow managed to attach a sound to an animation instead of a handler.

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

#316

Post by mclightning »

ajjenkins wrote: post #8

I agree that this is extremely annoying. It happens to me all the time with the iOS keyboard suggestions. For websites, Google calls the Cumulative Layout Shift (CLS) and it’s one of the Core Web Vitals they use for measuring website performance. https://web.dev/cls/

Ironically, Android's core UI elements are horrid in this regard.

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

#317

Post by medstrom »

bee_rider wrote: post #120
aendruk wrote: post #116

Earlier quoted context omitted.

Reminds me of my Dell monitor. Years old muscle memory is: 1. Unplug laptop from monitor 2. Power off monitor but step one triggers some automatic input detection mode for about 10 seconds during which the monitor ignores its power button .

That’s so annoying. I’d be tempted to get a power strip or smart plug and so I could revert to: unplug laptop, cut power to device. Actually — they make those “green” plugs, where power is cut from the majority of the plugs if none if flowing through the control plug. Maybe check those out.

Cutting power is wonderful UX. It's immediate and non-negotiable. After reading the rest of this thread, I dread the inevitable smart power strips that sense the approaching toe/finger and react before it arrives...

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

#318

Post by soulofmischief »

noduerme wrote: post #281
soulofmischief wrote: post #128

Earlier quoted context omitted.

A general golden UX rule is to never cause layout shifts on hover events, preventing this sort of thrashing. Unfortunately, Google/YouTube and others have lost the plot and no longer employ good UX professionals in their flagship products.

>> thrashing This was such a common thing to test for in fluid layouts under AIR/AS3/Flex, or any previous lingua franca where you had to design and code your own rollover effects or web components. So much is elided in mouseout and mouseover. Really, unless you've coded those events in a stack from movements, you don't understand what they mean. In any UI, it's the #1 thing you have to watch out for (along with stuc…

Yeah. Any position or size change is almost always a no-no. Even if you don't thrash the layout, you could shift your event targets and get caught in a thrash.

I weep for this new generation of web developers. So much more complexity, leaving little time for studying and nailing well-established HCI principles, which used to be less of an issue when web was simpler.

What vexes me is that I learned these principles from companies like Google in the first place.

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

#319

Post by soulofmischief »

noduerme wrote: post #282
ryandrake wrote: post #182

Earlier quoted context omitted.

I really wish UIs would stop doing things on hover events altogether. Just because I stop my mouse doesn't mean I intend to do anything, let alone auto-play a video or have some pop-up explain something to me. Let me rest my goddamn hand for a second!

Nothing should ever autoplay because of a hover. The only acceptable use of hovering is to change the color of something to highlight it, without changing any layout. The only exception is if you've already clicked and are engaging with a game or simulation inside a defined area.

What do you think about hover slideshows on video thumbnails in a search feed?

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

#320

Post by BLKNSLVR »

actualwitch wrote: post #286
BLKNSLVR wrote: post #151

Earlier quoted context omitted.

Yep, another vote for always scroll bar here. And an additional complaint about those tiny-thin scroll bars that some idiot-designer though were slick because they so minimally interfere with the rest of 1920px-width display, which also makes them a giant pain-in-the-wrist to click on because the width to make it appear is so thin, and then clicking on the scroller is another challenge whereby it's much easier to acc…

I think you misread op, they explained why the overlay scrollbars (aka "tiny-thin scroll bars that some idiot-designer though were slick because they so minimally interfere with the rest of 1920px-width display") are used instead of the old ones that cause layout to trigger again.

Haha, that's because I intended to reply to pasc1878 and hit the wrong reply text.

(because I'm an idiot, not because the reply text shifted on the page)

Post reply on HN