Front end developers: stop moving things that I’m about to click on(medium.com)
medium.com
Front end developers: stop moving things that I’m about to click on
https://medium.com/@stephenjayakar/frontend-developers-stop-moving-things-that-im-about-to-click-on-5827bc0409b3
352 comments
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.
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 loaded gradually after the rest of the page] and so the layout of the page would not change. Conversely, if you didn't provide 'width' and 'height' attributes, the browser would only leave a default small icon sized space for the image and then you'd have the page content move and shuffle about as each image downloaded and the rest of the page content got elbowed out of the way, to accommodate it.
It's funny how such basic concepts of usability seem to have fallen by the wayside in our new modern Web3 [or whatever version buzzword we're on now] in favour of moving content, modal overlays and the like. And, since so many sites these days just aggregate content from countless other external sources, even that basic notion of pre-defining your image sizes is often neglected too.
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 loaded gradually after the rest of the page] and so the layout of the page would not change. Conversely, if you didn't provide 'width' and 'height' attributes, the browser would only leave a default small icon sized space for the image and then you'd have the page content move and shuffle about as each image downloaded and the rest of the page content got elbowed out of the way, to accommodate it.
It's funny how such basic concepts of usability seem to have fallen by the wayside in our new modern Web3 [or whatever version buzzword we're on now] in favour of moving content, modal overlays and the like. And, since so many sites these days just aggregate content from countless other external sources, even that basic notion of pre-defining your image sizes is often neglected too.
All the examples are a case of unfortunate timing: asynchronous things doing late UI replacement that happen to conflict with the time window in which you click.
That's amateur stuff. Our car does this intentionally. As your finger is in mid-air, on its way to hit something on the touch screen, it's detecting this motion and then shows a context bar in the top and bottom by the time you land your finger. Which often overlays whatever you were going to touch.
It's so comically bad that I think a team of engineers is laughing back at the factory: "look! he's trying to touch something again!".
The other prank they included is traffic alerts. You're sitting in a traffic jam for 10 minutes already and then my music stops, only to hear: slow traffic ahead.
That's amateur stuff. Our car does this intentionally. As your finger is in mid-air, on its way to hit something on the touch screen, it's detecting this motion and then shows a context bar in the top and bottom by the time you land your finger. Which often overlays whatever you were going to touch.
It's so comically bad that I think a team of engineers is laughing back at the factory: "look! he's trying to touch something again!".
The other prank they included is traffic alerts. You're sitting in a traffic jam for 10 minutes already and then my music stops, only to hear: slow traffic ahead.
I agree with [this][1] idea:
> an autocomplete has one chance to reorder per keystroke. if you got it wrong and you have a better ordering a bit later you must “swallow the sadness” (as per the original author of this wisdom) but never change already displayed items
[1]: https://twitter.com/dan_abramov/status/1470751551568363530
> an autocomplete has one chance to reorder per keystroke. if you got it wrong and you have a better ordering a bit later you must “swallow the sadness” (as per the original author of this wisdom) but never change already displayed items
[1]: https://twitter.com/dan_abramov/status/1470751551568363530
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 as fast as me clicking something on the screen, it seems updating the list is the very last thing they do.
Spotify (on Android) is the worst offender for this.
The playlist shortcut shows six playlists, but 2-5 seconds after rendering these, about the same time it takes you scan over them and see if the playlist you want is offered in this set and get your finger into position, it re-renders them with different content & different order.
The full playlist selection does the same thing, using some hybrid and opaque MFU / MRU algorithm -- I'd be delighted with a pure alphabetical ordering, rather than having to visually scan down an unsorted list that's re-ordering itself as I read.
Mind, the Spotify UI can be held up as a shining example for basically every user-hostile anti-pattern, so I guess there's some consistency in their design.
The playlist shortcut shows six playlists, but 2-5 seconds after rendering these, about the same time it takes you scan over them and see if the playlist you want is offered in this set and get your finger into position, it re-renders them with different content & different order.
The full playlist selection does the same thing, using some hybrid and opaque MFU / MRU algorithm -- I'd be delighted with a pure alphabetical ordering, rather than having to visually scan down an unsorted list that's re-ordering itself as I read.
Mind, the Spotify UI can be held up as a shining example for basically every user-hostile anti-pattern, so I guess there's some consistency in their design.
Related to this, here's a pet peeves of mine. When YouTube is buffering a video, it shows a spinner and you can't press play or pause. Usually if something is buffering a lot I'm in a place with spotty internet, so I'd like to pause until I'm somewhere with better Internet. If I say pause, you should not continue playing the video under any condition. I have made my intent clear.
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 awkward situations. I don't know how common that is, since it was never fixed after all the updates, but I still have to be very careful and to make an unnatural pause waiting for UI to update every time I use this feature.
Honestly, everyone knows this. If you're creating sites that do this in 202X you're just being willfully ignorant/lazy. There are plenty of component libraries for rendering placeholder components in the popular frameworks, react has the suspense API etc etc for exactly problems like this.
The current version of the Amazon Prime Video app (and maybe also the HBO Max app?) on Apple TV has one of the worst examples of this I’ve ever experienced. In their featured listings, they should cards of shows/movies in what is basically a portrait view. When one of the cards becomes active, after a second or two it becomes wider and its content and background image changes and the cards to its right are pushed out further to the right. So as you’re looking at a card and you begin to read it, its entire contents is modified! It’s so maddening.
Google with its 'related searches' that pops up because I clicked on a link and I am almost never interested in this extra information. When trying to filter the relevant javascript it breaks some other stuff on the page (last time I tried a few years ago). Grrmbl
Something that really frustrates me is when an alert pops up on my screen just as I'm about to tap something, so my tapping then dismisses the alert before I've had a chance to read what it said.
Hopefully the contents of said alert weren't important, but in most cases I'll never know…
Hopefully the contents of said alert weren't important, but in most cases I'll never know…
I agree that this is extremely annoying. It happens to me all the time with the iOS keyboard suggestions.
For websites, Google calls the Cumulative Layout Shift (CLS) and it’s one of the Core Web Vitals they use for measuring website performance.
https://web.dev/cls/
For websites, Google calls the Cumulative Layout Shift (CLS) and it’s one of the Core Web Vitals they use for measuring website performance.
https://web.dev/cls/
Instagram search is my daily frustration. 100% of the time I search I’m looking for a user’s account. Type type type, see the user come up in results, go to tap but now they’ve loaded in 10 possible autocomplete options for my search, pushing the thing I want off the screen. And of course now I’m in the “explore” page with a search term I don’t want, taking a bunch more taps to get where I need to go.
I agree with others that I think the incentives are against the user here. In the IG case they don’t care if I find my friend quickly. It does not help them in any way. But hey they got a click on the autocomplete suggestions (win for that PM) AND another view on the explore page. Clearly I love these features!
I agree with others that I think the incentives are against the user here. In the IG case they don’t care if I find my friend quickly. It does not help them in any way. But hey they got a click on the autocomplete suggestions (win for that PM) AND another view on the explore page. Clearly I love these features!
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.
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.
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]
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]
It's not only buttons, sometimes the whole UI moves. Many mobile websites use sticky headers and footers that stick or unstick, appear or hide according to the position of the users in the document, how long since they touched the screen, scrolled, etc. I either switch to reader mode or savagely use uBO's element picker to select and permanently hide those elements. At the end of the treatment either the header displays only when I scroll to the top and the footer when I scroll to the end or they never display. I really don't care because what I want to read is the content in between.
This joke UI for the Hawaii nuclear missile alert system is my favourite depiction of this.
https://gfycat.com/queasygrandiriomotecat
https://gfycat.com/queasygrandiriomotecat
This is also a problem with seemingly stationary UIs, where a button is only shown when the pointer gets close to it. Especially when that button is within a clickable area, such as a thumbnail image.
The ideal solution to all of these would be for the UI to keep track of drawing events and disable any click that occurs in proximity to a just-redrawn area, and beep instead.
The ideal solution to all of these would be for the UI to keep track of drawing events and disable any click that occurs in proximity to a just-redrawn area, and beep instead.
I have googled the letter "n" countless times just trying to visit news.ycombinator on firefox android...
A lot of the responses are talking about how apps should fix this, which I agree with, but I'd also like to see it at a higher level...
I'd like to see frontends (browsers, Android, iOS?) remember their widget hit points for ~400ms, and if you've touched somewhere that had a different widget hit point within that time, use the old widget.
I'd like to see frontends (browsers, Android, iOS?) remember their widget hit points for ~400ms, and if you've touched somewhere that had a different widget hit point within that time, use the old widget.
And stop asking me to do a survey on your website when I've only been there for 5 seconds.
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 the wrong button underneath your mouse pointer!
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 Web site.
In my startup, uh, I'm on good terms with our front end developer and we agree on Web page design techniques:
So, no popups, pull downs, overlays. Nothing on the screen jumps around or moves. Large, relatively bold fonts and high contrast.
Always have both vertical and horizontal scroll bars.
No warnings or requests to permit the site to use cookies -- the site makes no use of cookies.
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 site HTML makes nearly no use of JavaScript.
Users don't login.
Users are not asked to spend money or up click on some popularity counter.
The server cores generate each Web page quickly, and each page sends for only about 40,000 bytes. When we convert the storage for our SQL database from rotating disk to solid state memory, the page generation will be significantly faster. Net, the site is responsive.
The pages and user interface are based on just the HTML controls with one line text boxes, push buttons, links where each link is a single word in the Roman alphabet in English with a simple meaning -- page design techniques very familiar to likely 2+ billion people.
Ah, we don't expect 2 billion devoted users right away and will be pleased with 1+ billion!
In my startup, uh, I'm on good terms with our front end developer and we agree on Web page design techniques:
So, no popups, pull downs, overlays. Nothing on the screen jumps around or moves. Large, relatively bold fonts and high contrast.
Always have both vertical and horizontal scroll bars.
No warnings or requests to permit the site to use cookies -- the site makes no use of cookies.
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 site HTML makes nearly no use of JavaScript.
Users don't login.
Users are not asked to spend money or up click on some popularity counter.
The server cores generate each Web page quickly, and each page sends for only about 40,000 bytes. When we convert the storage for our SQL database from rotating disk to solid state memory, the page generation will be significantly faster. Net, the site is responsive.
The pages and user interface are based on just the HTML controls with one line text boxes, push buttons, links where each link is a single word in the Roman alphabet in English with a simple meaning -- page design techniques very familiar to likely 2+ billion people.
Ah, we don't expect 2 billion devoted users right away and will be pleased with 1+ billion!
Would it be possible on the rendering engine side to detect if an item re-flowed and discard the user event if it happened within some time e.g. ~200ms ago? Something sites could opt out of for HTML games or things where it is intended behaviour. It's probably a bad idea, but it might help.
Side note about the first example, I wonder if Lyft is having chats about "Users really want to set up group rides, but always back out of the funnel - we have to make it easier for them!"
Side note about the first example, I wonder if Lyft is having chats about "Users really want to set up group rides, but always back out of the funnel - we have to make it easier for them!"
Latest one to catch me out on is when receiving calls on my Pixel phone it will pop up "screen call" as an option where the "accept call" button had been half a second earlier, and not let you override it to actually accept the call.
I think this comes from the idea that progressive loading makes for a faster user experience. But in practice it makes the user experience not only worse but also slower. So lose-lose.
I noticed it a lot on Google products where it annoys me quite a bit. It does this in search where it expands a bubble thing with irrelevant carousel content just after the first results (cannot even recall what the content is because it is not helpful). That pushes the entire list of results down making me either click the wrong search result or waiting before clicking. Both probably good for OKRs but horrendous user experience.
Worst one is though on (Pixel) Android where it does this in the notification when receiving a call. It starts with bubbles for "decline", and "accept" but then after a second it inserts "screen call" in the middle, replacing "accept". Screen call is a accessibility feature that breaks the expectation how the call works (no voice). It made itself used the first time for when trying to take an important call. A completely unnecessary move, as the list of options could just be appended... This again makes me wait for all options to come up before clicking.
I noticed it a lot on Google products where it annoys me quite a bit. It does this in search where it expands a bubble thing with irrelevant carousel content just after the first results (cannot even recall what the content is because it is not helpful). That pushes the entire list of results down making me either click the wrong search result or waiting before clicking. Both probably good for OKRs but horrendous user experience.
Worst one is though on (Pixel) Android where it does this in the notification when receiving a call. It starts with bubbles for "decline", and "accept" but then after a second it inserts "screen call" in the middle, replacing "accept". Screen call is a accessibility feature that breaks the expectation how the call works (no voice). It made itself used the first time for when trying to take an important call. A completely unnecessary move, as the list of options could just be appended... This again makes me wait for all options to come up before clicking.
I always assumed it was done deliberately to trick users into clicking on ads...
My favourite example of this is bank app I use very often, which comes with a VERY annoying twist. The most used button (one-time payment code) sometimes switches with "Take a loan" button, and after clicking loan button, someone from bank will call you in a near future to talk about it.
Since almost the beginning, graphic designers were trying to layout Web pages like an advertising brochure, lots of bad ways, rather than as hypertext. When, in a sense, they finally did take control of the Web, HCI (usability in service of user) had evolved into "UX" (advertising-like graphic design in service of non-users).
There's often disincentive for things like "user can understand what the controls are and what the state is", "user can focus on the information they want", etc. UX won't care about these things until some time after users are so aware of the problems that it affects engagement metrics and eventually A/B testing figures out why.
I'm imagining a eureka moment, during which a UX researcher, trying to find a new, improved dark pattern, to screw over hapless users harder, accidentally lets slip in some old-school good usability, which wasn't even supposed to be in the test sets, but discovers that this strangely resonates with users.