It's because they're designing it in Figma or Sketch, and of course infinite scrolling doesn't work in Figma and Sketch. If you don't predict this problem intuitively, you won't catch it until it's been implemented.
Ideally, there is a QA pass on staging, involving the designer, in which more than "does this feature work as written in the ticket" is the question you try to answer before releasing the feature. Many teams don't do this, and the blame for that lies with different people in different organizations I've worked in.
But developers often sneeringly deride designers for not catching things like this — "you had one job, lol" — but the sad truth is that there's no testing suite to help designers catch stupid mistakes. Speaking practically, the unit tester for a design is often the developer who tries to build it. Imagine what your interpreter or compiler or testing framework would say about your intelligence if it could talk!
I've encountered pages like that and wondered if the ux devs did it for that express purpose... last time I saw it, I was looking for some legal info (copyright/privacy or something); a dark pattern indeed.
A professional medical doctor will make more medical mistakes than I will.
Let us try our best to treat them charitably, forgive the mistakes we see, and provide input to help them do their work even better!
I had success working with Design/UX or any other specialists acknowledging that they spent more time thinking about it than I have, and that, of course, they will be the final decision makers on whether to accept or reject any inputs I give, before providing any feedback or ideas I have. Also, taking the attitude, not of "Let me teach you X", but of "Teach me whether you considered X and, if you have, why you haven't tried X yet".
You probably misunderstood: gp won't make mistakes in a medical field because he's not a medical professional, so he won't do anything in the medical field.
The same sometimes applies to designers and developers: if developers don't design, then of course they won't make bad designs.
The gist of it all is: don't ridicule people for mistakes, even if they're in their supposed field of expertise. Just let them know they've made a mistake if you see one.
I've witnessed it multiple times during our UI/UX meetings that the engineers present there (representatives of the engineering team are invited too, to tell whether it's going to work with our current architecture/deadlines etc.) often give more insightful feedback/criticism on UX than the other members on the UI/UX team (why the stuff looks crappy, makes no sense, hard to use etc.)
I think the reason is, devs view a design from the perspective of a simple user, they see it with fresh eyes, while the UI/UX team probably spent too much time tweaking the design to the point they got used to it and all its quirks and stopped seeing anything wrong with it.
It’s not just designers. I’ve given up suggesting style improvements because the boss comes back with “no user complained about it yet” when my suggestion is to use less crappy color. Who is going to complain about a color? Smh
HN tends to be more developer focused but I suspect most of these horrendous type decisions aren't made by random dev, and random dev isn't in a position to stop it.
Many years ago I once worked at a place where a CRM app had "special instructions" and at one point management was so upset about people not following them 100% of the time they were considering "make them blink" so the drones wouldn't miss them ... thankfully the blink tag had been deprecated. These instructions were sometimes several paragraphs long ... and they wanted them to blink...
Oh, I have worked as a freelance graphic designer once. Design is one of those fields where customer interaction can absolutely destroy any fun the profession would otherwise contain: everybody (and I mean everybody) has an opinion on design. The problem is, that many of those opinions are as uninformed as they are held strongly.
"Just make everything bigger" is one of those opinions. At the point where you have to explain your customer how basic perception works, how you cannot make everything equally important without sacrificing something — this is the point where you lost.
I'm not so sure. Most of the web devs I have worked with over the years haven't been overly thoughtful regards UX. I'd even go as far to say that it's the least considered aspect of their process. "Not my job" mentality. Tho probably says more about the nature of my experience than anything else.
I've done this, but it can be hard. Some designers can be very protective of their design, and you have to fight entire battles for something like "this white header text on a light-grey background image is almost unreadable, so I tweaked the colour a bit and added a text shadow" and other really basic no-brainers like that.
I don't even have very strong opinions about design; anything is fine with me. The only part I really do have a strong opinion on is "it should be readable", and enforcing only that has been very tiresome at times.
I totally agree it's not always easy. But again I think with something like this it's about savvy communication rather than enforcement. How do you articulate a challenge to a designer that respects their role in the process? Contrast is easy, there's defined standards you can defer to. But for sure, it gets tricky where it's just a difference of opinion or priorities.
Regardless, just going ahead and changing the design is probably the nuclear option. It's only going to start a war. Put the shoe on the other foot: consider same designer dropping a 2008 era jQuery snippet into your carefully constructed page to resolve an issue in the build. Not fun for anyone.
Edit: I should add, I'm basing all of this on personal experience. Appreciate some situations just suck and you have to get on with it.
No doubt. But this sounds like a communication problem between two stubborn parties. If someone demands a ridiculous feature and is immune to rational compromise, then sure .. state your objection, build the feature and send an invoice. In my experience this is rarely the situation. More often its a case of the real issue not being clearly articulated, a lack of will to compromise on behalf of the implementer (as much as the annoying, ignorant client), and a general cynicism from both parties as to the role of the other.
For sure, but then this isn't so much about "deciding" as it's about critical implementation and basic communication. Again this is in my personal experience, but when features like this make it through it's almost always due to an oversight on behalf of multiple teams .. or severe cynicism from a dev.
In my experience it has almost always been devs who don’t really use what they’re developing. “Alert sounds don’t stop if alert panel is open when new alert comes in” is only something a heavy user will notice. A dev might trigger an alert, but never think of weird edge cases like this.
There are applications I use where if the dev actually had to use what they made regularly, they would start implementing changes that get rid of the tedium. That’s also why in that CRM case I would really be pushing to have the opportunity to work as an actual user a few hours a week to really get a sense of how it works and what they really needed from those special instructions.
That's where I'm at... but of course we don't have footers of doom, because we won't. So that's kinda moot as far as all the internet "don't do this" proclamations go.
I suspect the really bad stuff comes from places other than the developers.
A lot of UIs designed by developers without going through a real design phase end up only making sense if you already have a mental model that more or less matches how the software works under the hood—the easiest UI to implement is usually one that doesn't provide any abstraction over the inner workings. So you end up with a steep learning curve, but software that is usable once you understand it. That's entirely different from a software feature whose design makes it literally impossible to use.
The most common thing is nobody owns the decision. Someone (an engineer) chose an implementation detail and nobody thought about it any sooner. Then these things pile up in interesting ways over time. Rarely is it "the engineers hands were tied". Barely anybody is telling the engineer what to do in the first place, mostly due to a lack of proper requirement gathering since the software is always considered to be "shipped late" in perpetuity by the business, so who has time to properly plan?
I've seen this a number of times, though I can't remember a recent example.
One site attempted to do it more intelligently, and the footer floated via z-index and pinned to the bottom of the window such that it was always visible despite the infinite scroll. Though they got it a little wrong and didn't account for the footer height in scroll calculations so if the content wasn't infinite so you could get to the end of the scroll, the last couple of lines were obscured by the footer. There must be quite a few ways to do this “properly” and smoothly (just thought of a couple right now, and I'm no front-end guy), assuming you consider automatic infinite scroll to ever be considered doing design “properly”.
It’s not a hard problem to notice or fix, probably just comes from people not using their site a lot. All you need to do is insert your content in a fib before a final “filler” div that has the same height as the floating footer. If your floating footer doesn’t have a fixed height (and there is some really good reason for that) a further hack is to measure it and then set the height of the filler div in js.
Also works well, but that might introduce janky behavior with iOS safari’s title bar and tapping the top to scroll to top in my experience. I don’t know if this has been fixed, it’s been a while since I wore a CSS hat, but I vaguely remember fighting with mobile safari and overflow divs a lot.
Not exactly the same, but theverge.com has recently decided to shove about 50 Outbrain ads, across 3-4 loads, in between the end of the article and the comment section. It makes me livid every time, yet still I go back :(.
I'm fairly convinced sites do this because someone there is sick of having to moderate their comment section, but doesn't have the buy-in to get rid of it entirely. So instead they stick a bunch of ads above it, hide it behind a button, etc. in hopes of annoying people into not commenting.
Infinite scrolling works great for search results. I have it enabled in DuckDuckGo, and when I use Google and hit the bottom of the page, clicking the next page button feels sp cumbersome. For anything not ephemeral like search results, infinite scrolling sucks.
if you infinite scroll, you'd also need some sort of url update so that you can always copy the url, and get back to this scroll position. i hate sites that have infinite scroll, but never allow you to "save" a position in the scroll to come back to in the future.
And then you click on a result item, reject it, hit “back” and you are not where you were in the result set. You have to scroll back to some unknowable position within infinity. Very discouraging as a user.
But the more ephemeral the content, the more one might want to save the page in a web archive, which (unfortunately) can't scroll down.
Granted, there isn't really any use in archiving ephemera like search results and frontpages other than notarizing odd patterns to show your friends or blog about, so the problem really lies in the interaction of web archival with infinite scrolling in general: comments sections, for example, can only be conveniently archived in their entirety without scraping if they're paginated and nothing is unloaded by default.
Yeah, and YouTube's comment section drives me insane, because it's one giant unthreaded infinitely scrolling list. There's no way to navigate, and if you scroll back up to the video to check something, you've just lost your place and have no hope of ever finding it again.
But DDG search results? I scroll until I find what I need, then I close the tab (it's rare to get past page 2, and yes DDG does actually group the results into numbered pages, with each page loading as it's scrolled into view).
I wish this was made impossible by browsers. It's like making a user chase their tail; they won't ever catch it. They just keep going in circles until they explode with frustration. You can't even cancel the requests to load more data.
I have come across a couple of these (I think blogs & news sites do this) and it is so annoying.
Especially when you are trying to reach the RSS feed link in the footer, which you are desperately trying to reach since an RSS reader will allow you to avoid infinite scroll!
It’s possible I’m lacking imagination after ~20 years of web dev experience, but I can’t think of a way to systematically prevent this. I can hardly even think of a heuristic to detect it which wouldn’t be either overly broad or overly specific. A spec which privileged more of a page’s “chrome” as part of the browser UX would probably make that more realistic, at the expense of being a very high value attack surface.
This is almost certainly better addressed by discouraging and shaming than by trying to fix it at the browser level. I agree with the clarity and brevity of the article (even if I can’t muster such brevity to save my life). And it’s very rare that this kind of UX is any more onerous to me than closing the tab/leaving the site.
Aside from a handful of web applications (like Google Maps), I struggle to think of a good reason for sites to be able to observe or hijack scrolling behavior. That capability is abused far more often that it actually leads to improved usability, and I don't think the web in general would suffer from sites being denied that power by default.
I understand your perspective but for you and anyone else reading, here’s a more familiar analysis.
Maps apps don’t make much use of scroll APIs at all, they tend to use pointer events (and/or their older mouse equivalents). When they do it’s almost always auto-panning to some item in a more traditional results list, and always a horrible experience. Apart from infinite scroll, the most common uses of scroll-related APIs are:
- deferring load/execution of resources until they’re pertinent; this is almost always a better UX, unless it’s done very poorly (side eye at many news sites)
- removing offscreen elements from long lists to minimize their performance impact; again almost always a UX benefit unless done poorly, though easier to screw up
- restoring scroll position between interactions; generally neutral, about the same level of quality as built in behavior, but better than not doing it when there’s client-side navigation (and I know this is another JS curmudgeon complaint, but it’s almost everywhere and mostly unnoticed)
- scroll-snap, which has eliminated the need for JS for whole classes of presentation (and probably the first unambiguously good thing MS purposefully introduced to web standards)
- offsetting jump in-page anchor/jump links to place content in view where they’d otherwise be obstructed; significantly benefits UX, unfortunately not (yet?) as widely adopted as I’d prefer
- “scrollytelling”, which can be really annoying but also can be incredibly useful if done well; notably a CSS standard is finally getting real world traction and will make the usage much more user controllable and much less awful for users who don’t control it
- shady tracking stuff which is mostly invisible to the user; entirely awful but categorically a whole separate UX topic
- weird event handlers to control things like video volume; I hate these with a burning passion
Overall, IMO, the value is kind of a wash. But the positives generally amplify positives for a lot of other UX problems and newer standards have made them basically mostly harmless.
For almost all the uses you've listed, I can readily think of examples where I've seen it done badly. Thinking of good examples is considerably harder. Can you provide some?
In my experience, deferred loading merely guarantees that there's visible latency multiple times when interacting with a page even after it has "finished" loading. And since lazy image loading can now be accomplished without JavaScript, I'm not sure what still needs to be lazily loaded via scripts watching scroll behavior.
Removing elements after you scroll past them sounds like the kind of optimization only necessary on infinite scroll pages, unless the page in question has a multitude of auto-playing videos.
Restoring scroll position between interactions: I'm not sure what kind of interactions make this necessary, so an example would help.
Scroll-snap: The examples on MDN don't even behave properly.
Offsetting jump in-page anchor/jump links: Stop obscuring 20+ % of the vertical space with "position:fixed" dickbars. Then you have a much smaller problem which I'm not sure requires JS scrollhacking to solve.
I'm not sure scroll hijacking is completely bad, but it's overwhelmingly more bad than good. Breaking fundamental interaction mechanisms should only be done where it's absolutely necessary, or in a context where all the normal expectations for interaction can be abandoned. These capabilities go beyond merely "ripe for abuse" and are perhaps better described as UX footguns that are mysteriously attractive to web designers.
> Thinking of good examples is considerably harder.
It would be, if they’re done well they’re indistinguishable from not being there at all. It’s unfortunately biased against good implementations. As far as examples, the best by far are HTML-only (img with loading=lazy, which behaves as expected almost universally). After that, I’m on mobile right now so limited in my reference capacity, but they tend to use IntersectionObserver and usually with simple abstractions around that.
> In my experience, deferred loading merely guarantees that there's visible latency multiple times when interacting with a page even after it has "finished" loading
Yep that was my side eye.
> And since lazy image loading can now be accomplished without JavaScript, I'm not sure what still needs to be lazily loaded via scripts watching scroll behavior.
Lazy image loading in HTML was controversial too, because it can be used for said shady tracking. But other deferred loading/execution is extremely helpful (for users!) for below the fold interactive content which doesn’t ever need to load if the user doesn’t scroll and doesn’t need to run until it’s nearby, even if the user wants to interact with it. Large JS payloads are a huge part of why sites feel unresponsive when they load. Even if they’re ultimately what the user wanted, it’s valuable to deprioritize the code they don’t need yet.
> Restoring scroll position between interactions: I'm not sure what kind of interactions make this necessary, so an example would help.
The most common is client-side routing (even turbolinks which are popular as an alternative to SPAs), but also any interactive content without stable heights.
> Scroll-snap: The examples on MDN don't even behave properly
I haven’t found that to be the case, what improper behavior did you see? (I’m asking because I’ll file an issue if it’s actually wrong and if you don’t feel inclined to file it yourself)
> Offsetting jump in-page anchor/jump links: Stop obscuring 20+ % of the vertical space with "position:fixed" dickbars. Then you have a much smaller problem which I'm not sure requires JS scrollhacking to solve.
That’s all fine and good, but there are cases where the offset is useful and small and users benefit from both.
> These capabilities go beyond merely "ripe for abuse" and are perhaps better described as UX footguns that are mysteriously attractive to web designers
The fact that the most benign uses of them is so opaque is a testament to how well the newer APIs are designed, they’re so close to invisible that you’d need to be paying close attention to their usage and limitations to even know how they benefit users and how widely they’re used. I didn’t know about most of them and how they’re used either until I was on a MDN hyperfocus just learning what had been introduced while I was fully backend. Since then I’ve seen incredible UX improvements specifically leveraging IntersectionObserver to make sites a lot more usable, often at the library/framework level where most devs have a happy path to just do the right thing. I know that sounds antithetical to the common anti-JS rhetoric, but it’s been so effective it’s almost invisible.
Unfortunately the worst cases are still terrible so I can’t blame you for your reaction at all.
> I haven’t found that to be the case, what improper behavior did you see? (I’m asking because I’ll file an issue if it’s actually wrong and if you don’t feel inclined to file it yourself)
When scrolling through a long document with a touchpad, it's natural to make several swipes in rapid succession, with the second swipe starting before the momentum scrolling or snap animation triggered at the end of the first swipe has finished. On my Mac, in Chrome it appears that starting the second swipe interrupts the snap animation (good) and doesn't start a new one when the second swipe ends (bad), even for a mandatory snap container—leaving the container in what should be an impossible steady-state.
In Safari, things seem to work as expected, except for the more general usability problem that making multiple swipes like this can cause the scrolling to be amplified far beyond what the user would expect for a non-snapping container.
In Firefox, things mostly work, but I'm occasionally seeing instances where the container below the one I'm scrolling also scrolls a bit. Not easily reproduceable, but since I was playing with the horizontal scroll container examples it seems unlikely that I accidentally made the right combination of one and two finger gestures to get the cursor to stray down to the lower container, scroll it a bit, move the cursor back up, and continue scrolling that one. Ordinarily, no amount of frantic two-finger swiping results in that much one-finger cursor movement, and it appeared the spurious scrolling of the second container was more correlated with rubber-band animation when scrolling past the end.
And that's from about two minutes of playing with literally the first example I could find.
Good detail, albeit somewhat revealing of a chaotic testing approach ;)
I’ve also experienced some weird edge cases behaviors with scroll-snap in desktop browsing environments, though seldom as pronounced as what you describe for Firefox (admittedly I don’t test in FF as much as I ought to, but I also don’t do much work that could even be browser-specific at this point).
It sounds like there are a couple potential bugs maybe worth filing here, given precise repro steps. Would you like the honor or shall I? I won’t be back at my desk til mid day tomorrow probably but I’m happy to see what I can repro and file what I can.
I mean... a lot of your examples boil down to "With enough JS, we can smooth over the problems created by all the JS we added!"
This approach is why Reddit is extremely janky on mobile, while HN is perfectly smooth. Opening a new page on Reddit takes up to 10 seconds; moving back to the previous page up to 5 seconds. Meanwhile, both are almost instant on HN.
Who knows. The page is down and 90% of is never got to read the article but the title sounds appealing.
Well, just position:fixed; bottom:0; your footer and make sure your scrollY - element.height or whatever has an offset to account for the footer.
Pity the site is down. Can’t read the article. It could be about conniving cheese merchants and their never ending battle for umami supremacy ffs, how should I know.
Should read "Don't place footers below infinite scroll." I appreciate the brevity but this fails to notice the nuance, and ends up being too reductive to be useful advice. Footers can work just fine combined with infinite scroll, eg. https://radiopaper.com/explore on desktop (disclosure, I am one of the authors).
That said, paying attention to how UX/features interact is something we should always strive to do more of!
Cloudflare used to do this with the DNS page. If you had a huge zone file, you'd have to keep scrolling and scrolling and scrolling until it finally stopped loading. I can't remember exactly what is was but there was definitely an important navigation item at the end of the zone that could only be accessed after the entire zone had loaded.
I wish this also contained an alternative suggestion. Where else should I hide the link to the privacy statement and the button for opting out of data collection?
Something tells me we're seeing more of this partly because of graphql and its first class spec to infinite scrolling. So no - I don't think the decision came from none other than the programmer who do this. And to be quite honest, UX designers I've worked with don't really dictate this kind of stuff. Heck, some don't even know how the scrolling works in their own designs when asked about it!
Heh, in a feature we're about to release, infinite scrolling was indeed dictated by the programmers, as it makes the API cleaner and somewhat more scalable ("incremental loading of data with an opaque next page token" as opposed to "go to page 80 and I don't care if it takes forever/complex archirecturally to make it fast/consistent"). We could have added a "load more" button but it looks somewhat terrible on mobile.
I cannot seem to reach the link in the OP, however, I would say that infinite scrolling needs to have a solid UI/UX around.
One of the main reason for inifinite scrolling is to have more and more content shown and try to attract the users and let them stay around (social networks for example).
However, there are cases where it's not implemented correctly and clicking next becomes very awful...
I can't believe this is still a thing.. Been complaining about this for a decade now but web design is destined to reinvent the same flawed UIs over and over forever.
Reddit used to do that. Dunno if they still. Remember trying to scroll to the bottom to click a crucial link. Quite funny. I think it was the settings-scrollmode menu.
Seriously, infinite scrolling is disgusting. The only good use I can think of is for realtime feeds.
Infinite scrolling has no repeatable reference points. It has a similar effect to a wall-o-text.
It seems to go in the same category as gestural computing, an way to make computers feel "Skillful" to use, and "Organic", while throwing away efficiency, reliability, and any sense of consistency and precision.
It's annoying both in terms of aesthetics and usability, to pretty much everyone, except maybe people who really hate tech.
No, this is about normal footers ("tags near end of document"). The problem is that with infinite scrolling you can never reach the end of the document, it always slips away as new content loads.
Happens out, UX team placed the "Send Feedback" button below the infinite scroll content feed.