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

321–330 of 365 posts

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

#321

Post by yakubin »

antihero wrote: post #278
gwd wrote: post #274

Earlier quoted context omitted.

I came here to complain about Apple's autocompletion feature: probably 30% of the time when I start to type a long word, the exact word I want comes up in the suggestion box at the top; only by the time I click the box, the word has changed to something else. It would have been faster to type all 7 characters out with my thumbs than to delete and re-type everything again.

Also Apple’s various search across products (music, spotlight, ios) is so damn slow it exacerbates this issue hugely

I have Sublime Text and Sublime Merge installed on my Mac. Trying to launch them through Spotlight is an exercise in frustration. Each successive letter typed in Spotlight alternates the selection between Sublime Text and Sublime Merge, so when I press Enter to launch, it’s almost certainly the wrong one of the two.

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

#322

Post by medstrom »

nicoburns wrote: post #306
medstrom wrote: post #302

Earlier quoted context omitted.

It may have been 2-4 seconds for your dev machine at work but 15-20 for a typical user.

We did actually test on older machines too, but the machine didn’t make a huge difference in this case, because it was network requests making it slow not JS execution.

Aye, the network is also superb at work... I don't have stats but it won't surprise me if the typical user is on 4G/3G and half of those people will always browse to your site at just the time when they're in an area of poor connectivity (e.g. that may simply be how it is at their home).

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

#323

Post by hellweaver666 »

FridgeSeal wrote: post #97
nkrisc wrote: post #36

Earlier quoted context omitted.

> That's the whole shell game of A/B testing. You're testing your way to what works best for you and not your users. A/B testing is a tool. Any tool can be misused.

On one hand: If a tool is being constantly and egregiously misused at large scale, might it not be reasonable to assign a degree of blame to the tool (e.g. tool has a “pit of success” that encourages/permits misuse. On the other hand: marketing and execs could misuse and abuse an empty room if they do desired, so I wonder why we bother giving them tools in the first place.

Cars kill people every day. Is the car to blame?

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

#324

Post by mtlmtlmtlmtl »

seer wrote: post #176
solardev wrote: post #105

Earlier quoted context omitted.

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

Props to you for having some professional integrity in an industry where it's practically frowned upon.

I couldn't take it anymore, half my interviews were companies I think shouldn't even exist at all. Decided screw the industry, I'm gonna scrape together a living any way I can and spend the rest of the time working on whatever I want to.

I might be poor now but at least I can sleep at night and I've never been happier.

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

#326

Post by FollowingTheDao »

bmitc wrote: post #251

Apple does this, a lot. The number of times I have incorrectly called somebody on FaceTime because I clicked on a contact at the same time FaceTime decided to update the list should be embarrassing for them. I have zero idea how this doesn't get fixed. It should be a trivial change to make sure the list is updated however they'd like before showing it to the user. As it is right now, given that it's slower or about a…

Right? Just click on Safari's address bar to see this in action!

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

#327

Post by nkrisc »

Moru wrote: post #219
nkrisc wrote: post #36

Earlier quoted context omitted.

> That's the whole shell game of A/B testing. You're testing your way to what works best for you and not your users. A/B testing is a tool. Any tool can be misused.

A tool that tests a change that puts off a person permanently won't give a good result if that person never comes back. It's often better to think through and ask a few users before starting developement. If your change is made only to lure people in, not improve their life in any way, mabe you should not even start the A/B testing at all...

> If your change is made only to lure people in, not improve their life in any way, mabe you should not even start the A/B testing at all...

Yes. It is totally possible to misuse the tool and run bad tests. That’s why, at least where I work, we don’t run live A/B tests until we’ve done some initial validation that the idea isn’t just terrible, and we have some level of confidence it will work and not harm the user’s experience. For example, we could segment user feedback and customer support issues we received by test variant so we could look for unexpected issues we might have inadvertently caused with the challenger design.

I can’t speak for how A/B testing is used elsewhere, but every A/B test I’ve run has been because we thought it would improve things for the user.

You certainly could run an A/B test to see which banner ad is more deceitful, just like you could use React to build the website that sells the scam medicine that banner ad is advertising.

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

#328

Post by snazz01 »

nikolay wrote: post #271

Same with Windows, macOS, and Linux - when an input has the focus, new windows popping up should not steal it from it (unless it's a child window) - I often have parts of my password entered somewhere else as while I'm typing, another window steals the focus and my input with it! Not only is this annoying, but it's a security flaw as well! Regarding web apps, you can also do destructive actions if the scroll moves th…

I once clicked into a corporate login window and typed my domain password, it completely ignored my click and I ended up typing my password to a coworker in Slack.

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

#329

Post by neogodless »

medstrom wrote: post #313
neogodless wrote: post #87

Earlier quoted context omitted.

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?

No - Microsoft Store was installed. And what I was looking for. (To see the new WSL GUI app.)

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

#330

Post by sebag1507 »

nicoburns wrote: post #303
nextlevelwizard wrote: post #252

Earlier quoted context omitted.

Unless your website is some kind of game or application why the hell does it have 2 megs of JS? Remove your shitty tracking and ad code.

There was no tracking or ad code except error reporting to bugsnag. Most of it was the firebase SDK. Which we did work towards removing, but which was a long term project because: - Every single database read depended on it - Many of them were subscriptions rather than simple reads, and so couldn’t be trivially replaced by an API call. Don’t use firebase guys.

You can see the size of each bundle in here: https://firebase.google.com/docs/web/sdk-metrics

Post reply on HN