Live data from Hacker News

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

medium.com

171–180 of 365 posts

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

#172
Microsoft Teams is terrible with this. People are constantly responding with accidental and unrelated emoji reactions when trying to interact with a post.

Nothing better than trying to reply to a death in the family of a coworker with a LMAO smiley.

[edit] Microsoft Teams is just generally terrible. It's likely the worst piece of 'competent' software I have ever ever used. [/edit]

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

#174

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 .

My Samsung monitor has the same kind of problem. It's often quicker to hold down the button for several seconds and force a shutdown of the monitor, than to wait for the monitor to recover enough to be able to display the menu that has the power-off entry.

[deleted]

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

#175
I think this kind of thing is super easy to introduce with the modern practice of async everything.

When I visit a modern webpage, it feels like I'm watching a golem take form from the debris around it. It starts out as this weird ugly contentless frame, and then things start popping in one at a time. It's quite hard to know when it's done.

Makes me miss the days when servers would serve me a full webpage. Browser shows me that it's loading, and once it's done it's done. It's also easier to develop sites like that, as you don't have to code your own loading spinners or make those weird "empty placeholder content" boxes that kind of show you how the site is laid out.

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

#176
post #80

This problem first occurred in the mid-'90s, and people saw it was a problem, and that's why we specified the image dimensions in HTML (before the GIF or JPEG header was loaded), so the layout wouldn't shift during load, when people were already reading and navigating. Since almost the beginning, graphic designers were trying to layout Web pages like an advertising brochure, lots of bad ways, rather than as hypertext…

In my experience, it was usually higher-ups and not the UX people who wanted to implement dark patterns. The UX people and devs wanted to make the enduser experience better (believe it or not), but were frequently overridden by some higher business priority (we NEED this popup as soon as the page loads! opt them in to all the newsletters by default! highlight the highest-margin products). Some companies just don't re…

It’s not so hopeless though. Not sure about UX, but for devs there are plenty of jobs, so you are free to switch whenever you see people doing or worse, demand you to do, dark patterns.

I’ve literally quit a job out of protest, where I started reading user emails complaining about the service we were building.

Stuff like “put the unsubscribe button at the far end, gray on a gray background, so it will be harder to find”. People were actually closing their bank accounts as they couldn’t find a way to unsubscribe from the service…

We had a few hard talks about it and when the company kept up with it I just up and quit.

And I got a job for a lot more money almost immediately. Turned out people who would do that to users, were underpaying their employees quite a bit too, who would have thought…

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

#177
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.

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.

Happens to me quite often with searching for apps on iOS, it almost seems perfectly timed to switch the icon you’re tapping on right as you’re tapping it

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

#178

I think this kind of thing is super easy to introduce with the modern practice of async everything. When I visit a modern webpage, it feels like I'm watching a golem take form from the debris around it. It starts out as this weird ugly contentless frame, and then things start popping in one at a time. It's quite hard to know when it's done. Makes me miss the days when servers would serve me a full webpage . Browser s…

What an apt analogy! I always thought of it as a transformer unspooling from its compressed “car” form.

But thats what we get when multiple teams are responsible for the same web real estate.

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

#179
Front end developers: Stop making SPAs.

99% of the time I'm forced to use a site that turns out to be a horribly bloated SPA that I only get to see after enabling JS, and which will do irritating things like what is described in the article, among others, it's to do something that could've easily been done with a simple HTML form and perhaps a bit of JS enhancement.

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

#180
Couldn’t agree more with this. Search results that auto complete but pull from two sources that get unioned in the UI are my major gripe. Initial return is great, i go to click but then boom the second dataset comes in and i click the wrong click by accident.

Drives me insane.

Post reply on HN