I've never seen a use of infinite scrolling that wouldn't be better replaced with lazy loading of images/video.
The alternative to infinite scrolling isn't to load infinite data up front.
The only difference really is that infinite load almost guarantees the page won’t have what you want on it, when you visit it.
And with my first problem, I can use the Next buttom and Ctrl+F (features others on this thread mentioned).
Infinite load is not the right answer everywhere (anywhere?)
Eg: What if StackOverflow adopted it?
Lazy loading implies the opposite? Regardless, it being broken up is very useful for everything around the site usage. IE google-linking, sharing urls, bookmarking, etc.
Infinite scroll is an optimization for first-time usage of a site, or for pages that are naturally read-once (ie twitter feed). They break everything surrounding n-use of the page.
As mentioned elsewhere in this thread: "As someone with ADHD, I immediately close any website that uses infinite scroll. I will become insanely focused on that site to the point that I tune out the outside world. What begins as "oh, I'll just look at this one article" turns into at least a half hour of wasted time before I'll be able to break out of it."
If you're browsing something that's content heavy (lots of pictures/videos) there's usually a point after a certain number of "pages" where my phone just can't take so many things loaded at once and it crashes. Not all sites have this problem, some are really bad (\cough\ tumblr \cough\) but it makes me avoid infinite scrolling sites at all costs. The ones with "Read More" are slightly better (the crash doesn't happen unexpectedly x pixels from the bottom), but still have this problem.
I thought at one point unloading the content at the top might help, but I'm not so sure now. Discourse forums do something like this, where they only load what you're viewing but it feels weird, like it's loading things it's already loaded. Sometimes I do want to scroll to the bottom of something and feel like it's all loaded everything for offline reading.
But overall by far I prefer sites/blogs that have paginated content.
I'm running infinite scroll in production serving thousands of photos and it works pretty well, constant 60fps, low memory consumption and you could literally scroll infinitely (given infinite content).
I've created various pages that sorta unrenders content, but all of them break the browser's find.
If you inspect you will notice that previous invisible items are represented by a single large div who's height increases as more items are scrolled out of view.
… breaking the browser’s Find. Also, things jump around the page as you scroll down. That site does it decidedly wrong.
Right now nightly says (9k posts)
│ ├──434.20 MB (48.20%) -- top(<anonymized-4294967585>, id=4294967297)
│ │ ├──429.00 MB (47.62%) -- active/window(<anonymized-4294967585>)
│ │ │ ├──292.77 MB (32.50%) -- layout
│ │ │ │ ├──109.99 MB (12.21%) ++ computed-values
│ │ │ │ ├───77.96 MB (08.65%) ++ style-structs
│ │ │ │ ├───71.80 MB (07.97%) ++ frames
│ │ │ │ ├───23.33 MB (02.59%) ++ (8 tiny)
│ │ │ │ └────9.70 MB (01.08%) ── text-runs
│ │ │ ├──121.27 MB (13.46%) ++ dom
│ │ │ ├────9.52 MB (01.06%) ── property-tables
│ │ │ └────5.44 MB (00.60%) ++ (2 tiny)
│ ├───6.14 MB (04.16%) -- top(<anonymized-4294969763>, id=4294967297)
│ │ ├──4.98 MB (03.38%) -- active/window(<anonymized-4294969763>)
│ │ │ ├──2.82 MB (01.91%) ++ layout
│ │ │ └──2.17 MB (01.47%) ++ (4 tiny)
│ │ └──1.16 MB (00.78%) ++ js-zone(0x21964428000)
Also I just double checked and it loads content as you scroll which I usually don't want for a forum.
I usually don't complain about the find feature with most infinite scroll sites but only because they don't hijack it. The find feature for discourse is AWFUL just awful.
I don't use any social media to actually read much of anything I'm already following. I use all RSS feeds. No bloated interface. No blackhole of content. The RSS reader I use (inoreader) is technically infinite scrolling now that I think about it, but it's the only instance I don't mind because I usually read it on my desktop, I never scroll back up (I star anything interesting), and who searches new articles?, and there's a good search for finding things again which I almost never use.
Things like this are more "ephemeral", rather that static pages with good content or index you can rely on.
Reddit lets me browse stuff without interruption, and it's not like I'm ever going to "go back" to somewhere earlier in the list... which has probably changed in the past 10 minutes anyways.
Shopping sites let me browse hundreds of shoes or shirts without interruption, and again it's not like I'm ever going to bookmark a segment of my search result. Same with Google Images.
It's easy enough to put footer content in the header, or in the About page or something. (How often do you use a footer anyways?)
And if you really need to start somewhere in the middle... usually filtering/sorting is a better approach anyways. E.g. for a blog, it's better to have a link to Jan 2015 articles than have a link to page 9 of posts.
I find myself mildly annoyed when I have to click through to the next page of something.
Obviously there are plenty of sites where it doesn't make sense... but I don't see it there too often since it's usually more work to program. This feels like a non-issue.
And for example, here on HN when there are too many comments it requires me to click "More" to get to page 2. Why not just auto-load them when I reach the bottom instead? If I got that far, it's more likely than not that I want to read more.
Anyways, the CDC article is really good about the symptoms of all three types. Pay attention to the DSM-5 spec if you decide to research further. The old DSM-4 spec from the early 1990s is still quoted sometimes even though it's horribly out of date.
Though it will vary per-person, as well, so that might not go for everyone.
> DuckDuckGo doesn’t paginate their results like Google does. Instead, you just keep scrolling down to wade through an infinite amount of search results.
Opening up DDG's settings in incognito mode, I see that its "Auto-Load" is now a setting that is off by default:
I also remember that DDG fans saw infinite scroll as an advantage DDG had over Google, which was known to have rejected infinite scroll for search results: https://www.businessinsider.com/marissa-mayer-google-9-2010-...
I personally found it to be a detriment to user experience. If my query doesn't return something relevant in the first 2 pages of results, why would I want to keep going down any further -- as opposed to doing a new search? Google's pagination has an effect of protecting me from lazily scrolling through countless pages of increasingly irrelevant results, and I wonder if DDG saw the same thing in user behavior tests when deciding to make infinite scroll non-default?
> A scroll event is not very intentional to do something. People navigate the page, and if they want to call an action they mostly click or touch (known as triggers). They inform the UI about their decision. But scroll is triggered without any decision.
Looking at you, TechCrunch! I’ve been burned by the suddenly disappearing article too many times.
Even if you solve this correctly by remembering the scroll position, you have to fire X ajax requests to restore the scrolling position, and have to wait until all images are renders or the content will jump wildly around.
What I'd like to see go more than infinite scroll is sticky headers. It's one thing if your site is effectively an app, but if a site is supposed to be mostly prose then I don't want your stupid useless header in the way of screen real estate. Worse yet, you make the problem worse by having the header pop out and retract if I scroll 1px in either direction. ANNOYING.
For example, under the ratings for pagination, they list: "Bad: Performance issues".
That bad rating is based on doing a dynamic post count for every page load, an approach that would only be used if someone wanted to maximize the performance penalty (or if your site/service is small enough that it simply doesn't matter if you do a new dynamic count on every page load). There's no common scenario where you aren't better off storing that post count, altered only as needed, rather than calling a new count of all posts for every single page load.
Even in a scenario of very heavy write, rare read, you're better off doing either a stored constantly incremented count or stored compromised occasional count that isn't perfectly accurate until or unless it needs to be.
Specifically the author uses this:
SELECT COUNT(*) AS total FROM posts
Instead of that, as a common scenario, let's say you have a posts table, and a comments table (which correlates comments that belong to posts by an id). You don't count how many comments each post has dynamically on every page load for a post, in the process of showing the comments. You have a counter in the post row, that increments only when a new comment is made, or decrements if a comment is removed. You pull that count at the same time you pull the core post information from the "posts" table, in the process of loading the post and then afterward pulling its associated comments.
The penalty is that you must update the post row when a new comment occurs. Assuming your service is heavier on read than write, which is almost universally the case, this is an easy win.
If all you wanted to do is track the post count, and not something further connected to it such as comments, that's also similarly trivial. There are numerous good ways to go about storing the post count until it needs incremented, rather than calculating it dynamically every page load.
All one has to do is consider a routine blog example, in which an author updates the blog once per day, and receives 1,000 or 10,000 visitors per day. There are 1,600 historical blog entries/posts spanning over four years. This article's approach is to needlessly dynamically count that over and over, perhaps tens of thousands of times per day, rather than altering and storing the count once per day when a new blog post is created. Performance bad indeed.
The comparison is with just sending all of the content (via API calls if necessary, whatever) and having the browser decide what to do with it, not breaking find, not having weird loading bars when you scroll down, etc, etc.
If you can't send all of the content you're probably creating a slot machine-type site.
Have terabytes of log results? Why would scrolling somehow fix that? Figure out how to fetch the stuff that matters, and put that in front of the user so they don’t have to scroll.
Scrolling should be all but unnecessary in a well designed interface.
Your complaint doesn't seem to make sense in this common context. In fact, I can't think of many contexts where your complaint does apply.
Let's say Reddit knows precisely the 100,000 things I do want to see. Endless scroll doesn't change that, but it makes sense to lazy load them that way.
But it seems to be detrimental for sites in which a user is looking for something specific, such as an answer to a search query or a product to buy -- i.e. they know what they want when they see it -- which would explain why sites like Google or Amazon haven't implemented it (though Amazon does have it for its mobile client it seems).
Years ago Etsy implemented infinite scroll in its search results, but killed it after finding "that people seeing infinite scroll purchased less from search".
Google gives you the best of both worlds. It’s normally not necessary to scroll, but if you absolutely must, the capability is there.
This absolutely isn't true at all; for example in Discourse we update the browser address bar as you scroll to reflect the current post you're viewing.
Date Range: [__/__/____] to [__/__/____]
Word or phrase: [_____] ... [X] Search title only
(*) Date, latest first
(_) Date, earliest first
Overall though I think the pattern makes sense
For everything else though? Not so much.
All UX approaches have tradeoffs, and any UX paradigm can be implemented poorly or used where inappropriate. Bringing up some of these examples and then saying "stop using UX approach xyz" is disingenuous.
More importantly, though, I think this article is an anti-pattern of attempting to make broad conclusions from anecdotes and personal opinion with zero data to back it up.
Since I intend to use this technique in a social network app I am working on, I clicked on this article expecting reasons to not use infinite scrolling.
I feel discouraged. When every generalized statement is essentially clickbait, then I don't know where to look for arguments and advice anymore.
I am truly lost.
Office 365's Outlook Web uses infinite scroll for listing emails, and the thing I hate about it is as you're scrolling down, it removes things from the DOM at the top. So if you want to delete a ton of emails from a service that went wonky and spammed you over the weekend, you can't click the top and shift click the bottom, because by the time you reach the bottom, the top message is gone.
If I scroll to the end of a folder containing mail it tells me "There are more items in this folder". I have to click for it to fetch more items.
I have years of email archived in various folders and it hides the results for every single folder behind this wall of "there are more items". Because of this I can't search through my archived email properly.
It never used to work with way. I think it changed when my organisation migrated to Office 365.
What are your users saying? What does the data tell you? A/B test it and find out. Do usability studies. etc etc.
As a user, my main gripes even with ‘great implementations’ are:
- not knowing how ‘long’ the page is as the native browser scroll bars can not be accurate.
- breaks ‘find on page’
- page up/page down keys rarely work as expected (admittedly this an implementation issue)
All that being said, it bothers me less when on a touchscreen device or when using an Apple trackpad. Desktop with a mouse/trackball or keyboard only nav is always painful.
You mean other than being completely broken and useless? Sure then...
Easier to just click the Page 2 link and search again