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

351–360 of 365 posts

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

#351

Post by brokenmachine »

Moru wrote: post #231
brokenmachine wrote: post #66

Earlier quoted context omitted.

The inconsistency of the UI is ridiculous too. There's countless examples, but the one that really annoys me every day is when the alarms go off. I have alarms to wake up in the morning, and on the alarm screen you have to swipe to dismiss, but to snooze you have to tap the other button. Sleepy me has a lot of trouble remembering which one's which, even though I've done it probably a thousand times at this stage. And…

I have a similar problem. I can't open the eyes at all that time of the day so I just try to feel my way to the phone. Most of the time I manage to turn off instead of snooze and wake up a lot later. My solution was to put the phone with the screen down and slightly lift it so the screen protector opens upp. When it closes again, it activates snooze. Took me a few times to figure that...

Mine had what actually was a cool feature, and the only thing I've ever used voice commands for - you could say, "snooze" or "dismiss". Worked really well.

Then they took it away with an "update", so now I'm stuck with only the crap UI.

Thanks Samsung.

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

#352

Post by x-complexity »

ryandrake wrote: post #182
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.

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!

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.

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

#353

Post by dredmorbius »

krick wrote: post #28

Oh, it gets better. On Android (at least, LG-flavored one — never used any other android phone) I have an issue with inter-app "Share" button popup. It somehow manages to re-shuffle all the suggestions (apps/recipients) exactly in the same amount of time that is natural for me to spend before clicking on the desired contact. Which several times made me send something to a wrong person, which resulted in extremely awk…

Also the fact that there are choices presented which I have never selected and never will.

I've seen that share-selection-reordering on numerous devices, including Onyx BOOX, which seem to otherwise mostly provide their own Android interface. So whatever's driving that seems to be deep in the environment.

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

#354

Post by dredmorbius »

graycat wrote: post #54

I agree and don't like Web pages that are complicated, require time, clicks, and effort to learn to use, have page content jumping around, cover the page with images requiring the user to stop what they are trying to do, change the window size and magnification, find a way to get rid of the image and do so, return the window size and screen magnification to what they were, and get back to the reason they came to the…

Thank you, in case you don't hear that enough.

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

#355

Post by noduerme »

soulofmischief wrote: post #319
noduerme wrote: post #282

Earlier quoted context omitted.

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.

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

#356

Post by medstrom »

lsaferite wrote: post #350
medstrom wrote: post #309

Earlier quoted context omitted.

Sorting by frequency/recency looks like the culprit. You often type 'for' and select forums.overclockers.co.uk, so the engine takes that into account and prioritizes that candidate, but you haven't done the same when typing 'forums', so it falls back on its normal sorting algorithm. Seems that if a program has frequency/recency sorting, it'd best have an additional layer of intelligence such that it checks what resul…

Or just key the frequency on the item clicked, not the term used to get there. If I use something a lot, it should generally take precedence over other possible matches.

Right! That makes sense.

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

#357

Post by wackycat »

Delivery apps often have a rating where it will list the dishes with the option to thumbs or thumbs down. My instinct is always to click each item going down the list down the list but after clicking the first thumbs up a text box asking what you like pops up. It's terrible. The workaround: thumbs up each item moving up from the bottom of the list so that the text box popping up doesn't interfere. Bottomline, if users are working around your UI instead of through it; your UX is terrible.

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

#358

Post by Sohcahtoa82 »

exabrial wrote: post #173

While we’re at it… Front end developers: stop using JavaScript for _fucking everything _.

I'd settle for them to stop fucking with scrolling.

Scrolling behavior is user-configurable. There's no need to decide "Fuck your preferences, one scroll-wheel click is going to be 1 line of text" and override my configuration. There's no need to implement "momentum" to scrolling, or make it bounce, or try to implement smooth scrolling since my browser does it anyways.

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

#359

Post by heavyset_go »

zikohh wrote: post #246
heavyset_go wrote: post #88

Earlier quoted context omitted.

It drives me absolutely nuts to the point where I run a UserScript to disable it.

Link?

I'll have to look when I'm at my computer, pretty sure I just grabbed something from one of the UserScript aggregators or whipped up something myself.

Either way, I'll reply with it in a bit.

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

#360

Post by noduerme »

soulofmischief wrote: post #318
noduerme wrote: post #281

Earlier quoted context omitted.

>> 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 fr…

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.

Post reply on HN