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

301–310 of 365 posts

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

#301

Post by jspash »

exabrial wrote: post #173

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

At $dayjob we have a pretty simple product page (e-commerce site) that has the requirement of 2 or 3 dropdown controls. In the early stages of the build I suggested we use the native browser boxes. The idea was widely panned but I did it anyhow because we were short of time. It took me about 3 1/2 minutes to implement and another 2 hours to join it up with the back-end and write a few simple specs.

Fast forward to 6 months after launch. We've now replaced the native control with an "all singing/all dancing" javascript version written in Vue. Thing is, it doesn't know all the lyrics and it couldn't do a box-step if it was stepping off a box. We get bug reports literally every few days because it doesn't act like the native control. And we'll _never_ actually stop the bug reports because people on different systems expect it to act like the native one. Something that is literally impossible to do when writing it on your own.

So now, even with all the evidence pointing to it being a bad idea, nobody want to rip it out because the integration is too muddy and could cause further bugs.

:facepalm

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

#302

Post by medstrom »

nicoburns wrote: post #118
at-fates-hands wrote: post #111

Earlier quoted context omitted.

Anecdotal evidence to support what you're saying. I work for a large health care company. They got on the JS bandwagon a while ago. We used to have huge sites that loaded fairly quickly (under 2 seconds) and cleanly. Now? The last two years doing accessibility work - a lot of these same sites which have been converted to Angular or React? They're taking in excess of 15-20+ seconds to load.

15-20+ seconds!!! What on earth are they doing to make it take that long? The React app at my last job was taking 2-4 seconds to load I joined the company (which I considered incredibly slow) and I had it at under a second by the time I left.

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

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

#303

Post by nicoburns »

nextlevelwizard wrote: post #252
nicoburns wrote: post #117

Earlier quoted context omitted.

> Page is slow because the average page size is 2.2mb. Plus JavaScript parsing + execution time. Plus asynchronous calls to go load more stuff. Plus time to re-layout around the new stuff. I think it's mostly blocking chains of multiple networks requests that execute in sequence (taking a network round-trip each time). I inherited a slow ~2mb frontend app at work, which seemed horrendously bloated to me. It turned ou…

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.

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

#305

Post by wruza »

grishka wrote: post #295
jer0me wrote: post #269

Earlier quoted context omitted.

I’m always nervous about AirDropping things—the list shuffles around in real-time and there’s no confirmation or way to rescind a file.

I was thinking about this problem in the context of Telegram. I have a lot of chats and they constantly jump around. Way too often I misclick because the list has updated in the split second between me stopping my mouse/finger and actually clicking/tapping. It's not really doable on phones, but at least on computers one could pause the updating while the user is moving the mouse over the list.

The recipe is to not accept click/touch after a while when you reshuffle a list.

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

#306

Post by nicoburns »

medstrom wrote: post #302
nicoburns wrote: post #118

Earlier quoted context omitted.

15-20+ seconds!!! What on earth are they doing to make it take that long? The React app at my last job was taking 2-4 seconds to load I joined the company (which I considered incredibly slow) and I had it at under a second by the time I left.

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.

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

#307

Post by xpil »

Kia Sorento suffers from a similar problem: after powering on, it shows a list of (up to three) profiles with the "accept" button at the bottom of the screen. Frequently the "accept" button is initially disabled (for whatever reason) and the correct profile is pre-selected so you simply wait 3-4 seconds for the "accept" button to become enabled so that you can touch it. But the millisecond the "accept" button becomes enabled, the profile switches from the one you want to a randomly selected - and you register the fact too late because you have already pressed the "accept" button. Now you either drive on a different profile, or you have to go to the settings menu and select the right profile. Worst case, it takes up to 35 seconds from when you power on the car to when you can actually drive it on the right profile. Very annoying.

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

#308

Post by dusted »

thiht wrote: post #277
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…

Quoted post unavailable.

Nah, he's pretty spot on "User eXperience", it's not about designing a usable tool to maximise user productivity or pleasure, but rather, about designing a specific experience, which may or may not align with productivity or pleasure (and often does not)..

Exactly stuff like "if users can do X too easily, we loose engagement/ad misclicks/the feature _WE_ want them to interact with", so we "design an experience" that leads users away from doing X too much, but it's an experience designed to maximize user frustration to just below the point where it makes users ragequit into a different platform/product.

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

#309

Post by medstrom »

Nursie wrote: post #248
devnullbrain wrote: post #79

Earlier quoted context omitted.

I want foo. - Type 'f' - foo appears in the search. - Type 'o', because I type with 10 appendages and getting them to work together requires pipelining. - foo disappears from the search This should never happen.

Concrete example from my firefox url bar - type 'for' - forums.overclockers.co.uk appears, this is where I'm going, I go here once on most days type 'forums', because my fingers didn't get the memo to stop - forums.samygo.tv appears at the top, a site I haven't visited (on purpose) in almost a decade, mostly because I don't have that tv any more. Massively annoying.

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 results would've been returned by other substrings of your search term.

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

#310

Post by DonHopkins »

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…

Sun's tragic X11/XView based "xbugtool" pioneered a lot of this misbehavior and worse in the early 90's, especially when you foolishly tried to use it to file a bug against itself, which triggered some extremely dark patterns indeed, like scrollbar spoofing, passive-aggressive input queue blocking, and keyboard focus locking:

http://www.art.net/~hopkins/Don/unix-haters/x-windows/xbugto...

For a more philosophical approach to user interface design, see "Jojo on UI":

http://www.art.net/~hopkins/Don/unix-haters/x-windows/jojo-o...

Post reply on HN