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

101–110 of 365 posts

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

#101

Post by jodrellblank »

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…

> "Hmm, maybe someone somewhere, maybe the EU, will make a big stink that we have not asked users to let us use cookies. Sounds like a good source of publicity until finally we end the stink explaining that we use no cookies and are not required to get approval for NOT using cookies!"

The EU does not require you to ask permission to use cookies if you do not use cookies. Encouraging web developers to not use cookies, and as a consequence have no banners, is one of the positive incentives of the cookie legislation.

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

#102

Post by FridgeSeal »

bobthegrower wrote: post #61

Quoted post unavailable.

And until devs stop enabling them, it’ll continue happening.

“Just doing what we’re told” isn’t an excuse, and doesn’t obviate you of responsibility in perpetuating it.

“They’ll just get someone else to do it”, but if we collectively put our feet down about not implementing dark-patterns, that threat can no longer hold water, and we all have a bit less user-hostile software in the world.

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

#105

Post by solardev »

neilv wrote: 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 respect their users or customers, and/or try to optimize for short-term metrics that make some individual or agency or department look good at the expense of long-term loyalty. But I've never seen a UX person willingly suggest a dark pattern... all the ones I've worked with were forced to implement them, despite much protest, because some manager wanted it there.

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

#107

Post by at-fates-hands »

Normille wrote: post #3

Way back when I first started learning to build web pages [when HTML4 was just a glint in Tim Berners-Lees eye], it was conidered bad form not to prvide a 'width' and 'height' attribute for an image you were placing on the page. Because if you provided these, the browser would know how much space to leave for the image to occupy after it had downloaded [this was back in the dial-up modem days. So images usually loade…

One of my first jobs as a front-end dev, I was told repeatedly if you released a site and had forgotten to put height, width on images, it was seen as a defect and would affect your year end metrics.

By my second or third job, nobody seemed to care about it and when I brought it up, it was brushed aside as a "browser issue" and not something we devs needed to worry about.

You make a great point, and something I'm seeing a lot more of now that I'm in accessibility.

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

#108

Post by shitloadofbooks »

Steam does this when you're going through the discovery queue and land on page with a "stream" or whatever going. You're about to click Next and then the Stream element loads and shifts the whole page down ~500px and then you click on something else.

It's absolutely infuriating!

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

#109

Post by solardev »

devnullbrain wrote: post #77
vidanay wrote: post #68

Earlier quoted context omitted.

YouTube also has the problem that there is almost no dead space to "park" your cursor. You have to carefully place it in between autoplaying previews.

I've noticed this with JIRA, there is not much space to click 'safely' to focus on the window

Jira is basically a UX anti-goldmine... a single place to go to learn all the things NOT to do.

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

#110

Post by mcv »

My biggest frustration for this is the typing completion on Android. I'm typing, and while I'm typing another character for the word, I see the word I want listed above the keyboard. But just as I hit the word, the suggestions update and my word is replaced by another. And often my word is still listed, but in a different place, which js incredibly annoying. Or sometimes the word disappears, despite it still being a valid completion for the word I'm typing. Why suggest it and then remove it?
Post reply on HN