Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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!


I'm totally fine with tooltips on hover. In fact, quite often they should appear quicker. And sometimes they don't appear at all when I really want them to. No idea what's going on with that.

But yeah, hover is just for info about the thing you're about to click, not pretending I've already clicked it when I haven't.

The stupid thing about Youtube is that sometimes a video starts playing on hover, in the thumbnail and without sound, and then I actually do click it because indeed it is something I want to watch, and then I miss the first couple of seconds because it's already shown those, with the sound off. It's just the most bizarrely stupid UI decision I can think of.


I'm sorry to inform you that, by hovering over the video, you have Engaged with the Algorithm and thus demonstrated that the auto-play is Good, Actually.

Short-sighted optimization for engagement is the cause of an overwhelming majority of the problems on the Internet.


On an Android TV the YouTube app auto-plays videos if you stop moving the selection cursor for about a second.

It feels so fantastically “pushy” to start playing the audio of some random junk that just happened to be under the selection reticle.

They helpfully added a configuration option to turn this behaviour off, which is a tacit admission that it’s a misfeature that users want to disable.

It does nothing.

The videos still play.


wow must have been really bad because Google rarely adds configuration options and they pride themselves in ignoring user complaints.


I agree. There are sites and apps where I need to make a conscious effort to put my mouse pointer in that one place where it does not trigger any hover actions, so I can just read the text. Incredibly annoying.


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?


I think that's okay as long as they don't enlarge or anything when you're hovering over them. And as long as they don't start playing audio or downloading an entire video.


For me, hover events should not be able to modify the size & font size of the element in question: Only the element's colors (text & background), & text formatting (underline, bold, italic) should be modifiable.


They probably employ large teams of both good and bad UX designers, constantly deploying and A/B testing UI changes. If the A/B test says the change wins, it stays.

Sites like Booking.com do this to the umpteenth degree.


At least they have the precisely correct blue, though. https://stopdesign.com/archive/2009/03/20/goodbye-google.htm...


>> 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 stuck hovers, accidental focus and things like that). Mouseover/out depend on the entire screen graph as well as timing to establish user intent. Thrashing the whole UI off that because you shift the layout is the worst example of how to do it wrong. Amateur hour.


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.


I learned them the hard way by designing reflow typography layouts in the late 90s and early 00's, mixed with interactive elements; and later thinking out whole sites with layouts that weren't reliant on a particular DOM or browser. It's a bit stunning to me that Google taught any of these principles at any point beyond eliminating all the art. Which to me was the beautiful part of the early web.

I have literally no idea what people are learning now in academies before being set loose to do front-end work, but obviously it's mediated through so many libraries that they haven't had much time to consider what's going on behind low-level user interactions and load sequences.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: