Hacker News new | past | comments | ask | show | jobs | submit login
Problems with infinite scroll (logrocket.com)
208 points by ohjeez on Oct 21, 2018 | hide | past | favorite | 108 comments



The biggest problem I have with infinite scroll is that it breaks searching within a page. If I want to find something I have to scroll down to the bottom and then wait some arbitrary time until I think enough content has loaded. Even if I know roughly where the content I'm searching for is, I can't just click to a specific page. I have to guess how far I've scrolled and hope that it's far enough. I waste time and data transfer because I'm forced to overshoot if I want to reliably find things. I can't even bookmark a specific page, so I have to repeat this tedious process every time.

I've never seen a use of infinite scrolling that wouldn't be better replaced with lazy loading of images/video.


If the information you're searching for would have been in the next page, searching within the page would have been similarly "broken" in a paginated UI.

The alternative to infinite scrolling isn't to load infinite data up front.


If you are presented with pagination, you have a hint that there's more content to load and how much more, 2 pages or 100 pages? I know immediately that I have to repeat my search and how many times. You aren't "warned" of infinite scrolling upfront, you don't know there's unloaded content unless you scroll down. Nor do you have any idea when it will end. It's mystery meat navigation.


But if I found that content via a search engine I would have been directed to the correct page to find what I was looking for.


I've had many occasions of clicking links from G to land on a page that should have what I want, the cached copy did but the landed page doesn't


That would be true of any site that updates its webpages at any time, regardless of static or dynamic webpages, and certainly regardless of pagination/infinite load.

The only difference really is that infinite load almost guarantees the page won’t have what you want on it, when you visit it.


Yep, exactly.

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?


Pagination at least gives a hint as to what is loaded and if i need to repeat search again on next page. This is harder when you don't know what is actually loaded without scrolling.


>The alternative to infinite scrolling isn't to load infinite data up front.

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.


The URL should change with either offset (which is dynamic) or ideally ID as cursor (which is static).


Wouldn't this break the back button? I wouldn't expect to have to go back several times just because I scrolled.


You just use history.replaceState


Isn't this better solved with a combination of bookmarking, tagging, good search, and resetting the person to the same spot on a page when it reloads? (facebook doesn't do the latter for instance, and it's massively frustrating to me)


The bit on Facebook is purposeful. Youtube does the same thing. It's about keeping the user engaged with another novel engagement whether ad or content driven. You may be frustrated and possibly rage quit, but the majority fall for it cyclically and spend more time on the service as a result.

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."


None of that will be as fast and simple as pressing Control-f and typing the search term. You don't even need to press enter. Searching within the page is a superbly useful and well-designed interface, and I would be very surprised if any custom web app solution could do better.


The alternative to infinite scrolling isn't everything on one page though, it's paging.


If only they had regular expression support in the built in find. A few times I've put that into web apps and found it quite useful.


I bet there's a browser extension for that.


Lazy loading can also break search within page.


Now you have two problems.


You should include same-sized placeholders for the unloaded content, so the page doesn't jump about when you search and push the search result off-screen.


I don't like infinite scroll but for another reason not mentioned here.

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.


The technique is called "windowing" and it's not extremely hard to implement properly. For react we have react-virtualized and react-window, and I'm sure there are other libraries for different UI frameworks.

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).


You have to be careful about which types of content you remove, though, to avoid breaking the browser’s Find. (Reddit is an example of a site that currently does this wrong.)


I spent a lot of time on Reddit and have never seen infinite scroll on it except when I had the 3rd party plugin "Reddit Enhancement Suite" installed. Is it in the new layout they pushed out recently, or do you have RES installed?


The new layout for profile pages is where I noticed this problem. No RES.


Do you know of any sites that do it correctly?

I've created various pages that sorta unrenders content, but all of them break the browser's find.


I don’t, sorry. If regular pagination is at all an option for you, that’s a safe and user-friendly choice.


This site does it: http://www.goodlist.co/

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.


> previous invisible items are represented by a single large div

… breaking the browser’s Find. Also, things jump around the page as you scroll down. That site does it decidedly wrong.


At least Firefox does unload images outside the viewport. But it still has to store layout information of all the preceding elements to determine their placement in the document

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)
Reloading the page with only 100 posts:

    │   ├───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)
So at least in this case it's actually Layout and DOM nodes that dominate memory consumption, not the images or javascript.


I think Discourse does a nice job. It changes the URL in the address bar as you scroll down to viewed post ID, and I believe (but can't check now) that is has entire content loaded in the page, and just does the rendering of the viewport as you go down. Don't know how it handles 'JS disabled' case, though.


Discourse is one of my go-to examples of a terrible site that I will actively avoid. The find in page is terrible. It makes it impossible to find anything ever. Octoprint moved its documentation there and I'm really unhappy about it.


I like most things about discourse except the scrolling/loading. If you skip around with the bar on the side it's always loading where you skip to, which is fine, except it only loads what's in the viewport, no posts before/after, so if you skip back to a loaded part but you're off by one post, it does the loading thing again. Just feels weird.

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.


There's an option on Tumblr desktop settings to disable endless scrolling. It's still terrible that it's only desktop mode, but it's still usable like that on mobile.


I don't actually log into tumblr itself. It's just I'll often stumble upon a blog through a search or a link, and every time I see a tumblr infinite scrolling theme (i think it's the default one?) I want to scream. The worst ones are the ones were even single posts have infinite scrolling. Ugh.

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.


For me biggest issue is if you refresh or come back (or browser app restarted), you need to start over from the beginning again. Stuff gets dynamically loaded instead of static url. I prefer pages with number in url parameter (and ui to go to next/last/... page).

Things like this are more "ephemeral", rather that static pages with good content or index you can rely on.


I dunno... I find that on most sites which implement infinite scroll, I like it.

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.


Which ones? Standard reddit uses prev/next, not infinite scroll, and all the shopping sites I'm familiar with use prev/next as well, rather than infinite scroll.


Reddit's desktop site uses infinite scroll. Maybe you are using old.reddit.com or opted out of the redesign some other way.


Good point, I forgot I installed the "always prefer old.reddit" extension when the redesign completely wrecked image subreddits.


Yeah, reddit does infinite scroll. I'm using the mobile web version and it's awesome that way. Prev/next is annoying for binge content consumption or navigating through comments...


Another issue with infinite scrolling on web sites is: what happens when there's a connection problem? I've seen sites where it silently acts as if the user had reached the end of the "infinite" page, even though that's not the case. Worse, the only way to recover (once the connection is working again) is to reload the page and start once more from the beginning.


This problem is readily solvable though so I don't consider it a showstopper.


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.


Is that actually a typical ADHD symptom though? I thought ADHD means not being able to concentrate for a sustained period of time, instead of being able to become insanely focused.


My variant is called "combined subtype". It essentially means that while I do distract very easily, I also can become insanely focused on the task with the least path of mental resistance. For example, I am writing this comment when I intended to only read the top stories on HN. I just realized that I was distracted from my original task and that I have spent five minutes describing ADHD. Phew!

Anyways, the CDC article[1] 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.

[1] https://www.cdc.gov/ncbddd/adhd/diagnosis.html


It's more complicated than that, I think. Roughly, it's an inability to choose what to concentrate on? An executive dysfunction thing.

Though it will vary per-person, as well, so that might not go for everyone.


As someone with a pedantic side, I'd say nothing in real-world computing is infinite. Every web page ends eventually, even if it's only when your browser runs out of memory.


I swear that DuckDuckGo had infinite scrolling for its search results, but this was not the case when I recently tried a search. Blog posts from a few years ago seems to confirm my memory that infinite scroll was the default: http://seanvwork.com/blog/duckduckgo-vs-google/

> 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:

https://i.imgur.com/yWrJ3uZ.png

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?


This trend is a big problem. We have to get to the bottom of it!


...trend? People have been writing "infinite scroll needs to go" for over five years, most major websites that _used_ to have infinite scroll have gotten rid of it again, so I'm confused where this is suddenly a trend. It certainly feels like a "finally gone" aspect on North American websites.


I’ve looked into it. No end in sight.


Keep scrolling!


He was mostly just using that line to make a joke - 'we have to get to the bottom of it'


> Users generally do not like the UIs when they feel they cannot control it.

> 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.


Another problem with infinite scroll is often incorrectly implemented "back" functionality in the browser. If you had scrolled down somewhere, click a link or image and then click on "back", you usually do not end up were you were before, but most often on the top of the page where you have to scroll down again to were you were. Very lousy UX.

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.


I’ve never found a site where it worked. It’s one of the most annoying experiences on the web. Especially when you need to navigate to another page just to get access to the footer for getting to “contact” or similar.


The only infinite scroll I'm kinda OK with is DuckDuckGo. When it comes to news sites with infinite scroll, I almost never want to continue scrolling past the original article.

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.


Please check out my project[1] if you hate sticky headers.

[1] https://github.com/yourduskquibbles/webannoyances


Sites with articles are the worst here. A lot of them break reading view/save for later tools. I end up with the next article instead of the one I'm on.


Infinite scroll was never a good UX pattern. It was invented to keep people from leaving the page and continue to scroll on. Pagination would interrupt this, and people might leave after clicking two or three times clicking the "next page" button.


I'd argue that the author is actually under-representing the value of pagination by making an obvious mistake in implementation.

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 primary issue with infinite scroll is not the implementation, it's the idea that a page with "infinite" content is useful or desirable to begin with.


Compared to pages it's been a groundbreaking improvement to me at least.


I am specifically calling out "infinite" scroll here, i.e. the practice of artificially limiting the amount sent to a very small amount then populating it on the fly.

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.


I hate infinite scrolling because once implemented nobody cares about disabled javascript case - like reddit, the experience is broken without it - you can only see first couple of topics and can't load more.


https://old.reddit.com should solve your problem. It does not make use of infinite scroll.


already using it, but i'm worried it'll disappear one day


I have some scripts I use to scrape data from FB by manually spoofing keystrokes and I shudder to think how much energy is being wasted at both ends for the amount of data I am actually trying to collect.


I always found Bing's infinite scroll for image search pretty awesome and superior and a reason to use it over Google. Haven't seen that feature much elsewhere though.


Fundamentally, scrolling indicates that you haven’t done a good job of surfacing the information that the user really needs in the first place. I see any form of scrolling as an admission of defeat on the part of the site designer.

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.


I don't understand. What about when you're just consuming a list of things like an image gallery or HN/Reddit frontpage?

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.


Infinite scroll seems to be ideal with casual consumption and serendipitous discovery, which is probably why its the status quo for sites like Reddit, Tumblr, Facebook, and even Google Images.

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".

https://news.ycombinator.com/item?id=5017995


There are legitimate times when scrolling is needed. But in my experience, in many circumstances, what is needed is more thought about surfacing what’s relevant.

Google gives you the best of both worlds. It’s normally not necessary to scroll, but if you absolutely must, the capability is there.


> However, infinite scrolls cannot keep the state by its design. Users cannot share their current state. Which also means you cannot track users’ actions using analytics tools.

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.


But find in page is useless AND it hijacks the browser. You can't use print or reading mode to view the whole page either. Discourse would bea fine corner of the internet without infinite scroll. Instead it's a place I cringe about and use as an example to designers of what not to copy.


Print works fine; try it. Find is indeed contingent on what's loaded on the page, same reason you can't "find in page" when you're viewing paginated page 5 of 20. Not really a valid criticism, unless you're just splitting hairs for fun.


While I often like infinite scrolling, I really hate it on the Google+ Android app, because I have no way to quickly jump to the top. If I scrolled way down and want to scroll back to the top, I have to scroll manually all the way, which is a pain, or kill the app and restart it.


I'm okay with infinite scroll being the default; just don't make it the only way to navigate. Have an easy-to-find way to switch to pagination and/or query-by-example (QBE). A QBE form for a blog-type search would resemble:

     Date Range: [__/__/____] to [__/__/____]
     Word or phrase: [_____] ... [X] Search title only
     Sort by: 
        (*) Date, latest first
        (_) Date, earliest first
        (_) Title
Except for the sort-by option, they'd all be optional


The thing I dislike about infinite scroll is that almost everything that has it is intended to make you addicted and compulsively scroll more, to the point where I pretty much have sworn off any app that makes it a central part of the experience.


What I don't like about infinite scroll is it not putting stuff in my history. Finding my way back a few days later ain't happening.

Overall though I think the pattern makes sense


A few weeks ago I was trying to find a contact page on a site that had infinite scroll (don't remember the reason or the site). The link to contact information was in the footer, which was impossible to get to with infinite scroll. Absolutely ridiculous.

Ended up having to disable JavaScript to be able to scroll down.


Stop visiting websites with infinite scroll. Problem should work it self out eventually...


What if you used the cursor type with infinite scroll that put links to the page number inline so you could infinite scroll starting from any point?


You can't jump to the nth page with cursor-based navigation because you don't know what id it starts at. 13? 21? 34?


Infinite scrolling exists because it raises the average time users spend on your site.


I always thought infinite scroll was the best thing since sliced bread when I first saw it in Google Reader. I still really love it for consuming my news feed.

For everything else though? Not so much.


TBH, this article is a perfect example of the formulaic, semi-clickbaity articles that I can't stand. Take the title "Stop building websites with infinite scroll", but then the article itself goes on the give some examples of when infinite scroll is appropriate. Even many of the arguments against infinite scroll feel like strawmen (e.g. "It messes up the footer." Well, seems obvious to me that putting a footer after an infinite scroll is a bad idea, but many if not most pages where you'd use an infinite scroll could do without a footer, or you could put that "footer data" elsewhere.)

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.


In keeping with the site guidelines, we often rewrite such titles to something less baity like "Problems with". I've done so above.

https://news.ycombinator.com/newsguidelines.html


I have been often annoyed at infinite scroll, and never at any of the other options offered. It's part of a general anti-pattern of pages loading new content when I didn't ask them to, but by far the most prevalent and annoying. I dislike infinite scroll, and I believe I am alone in that, and perhaps not even in the minority.


Well, then we agree to disagree. Particularly with search results where it's likely I'm going to need to look through a lot of results (e.g. real estate, hotel, dating sites) I find infinite scroll, if done right, makes it faster to comb through results.

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.


I agree.

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.


TL;DR don't use infinite scroll because your users can't find the footer.

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.


The Outlook desktop now client does it as well. I am not sure if it is exchange setting or something else.

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.


This is a great example of why you should use data to drive decisions on features and not just broadly declare x or y feature is bad because you personally have gripes with it. You are not your user and you shouldn't be allowing personal feelings to cloud the debate. Decisions without data, what is this, 1996?

What are your users saying? What does the data tell you? A/B test it and find out. Do usability studies. etc etc.


My personal feelings when I use a site with infinite scroll are pretty clear. I don't think it is unreasonable to look at other sites, where you are a user, draw conclusions, and apply them to your own site.


Sure, now we use personal opinions to decide product direction. Sounds great! Why not just flip coins while we're at it? users love that.


Nope, infinite scroll is superior. Just there are poor implementations. Proper infinite scroll has 0 downsides.


Citation needed.

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.


Proper infinite scroll has 0 downsides.

You mean other than being completely broken and useless? Sure then...


But I want to get to the footer where I’m pretty sure the contact details are. Not sure how you can design around that. I mean, you can try. My example was just one of many. But you’ll never change the expectations of users who have been conditioned by the use of 1000’s of other websites that don’t use infinite scroll.


Appending a dynamic anchor #page=n while scrolling and putting links at the top, not at the end, for example, address most of the problems


I'd love to hear which websites do it properly.


ctrl-f doesn't work for things that haven't scrolled in yet.


I don't get it. It also doesn't work if you're on a paginated page that doesn't contain those things.


Because then you know it's not on that page. With infinite scroll a negative response doesn't mean it's not on the page.


But then you can just go to page 2 and search again....with infinite scroll you have to scroll a set distance, wait, search again, repeat....how do you know you have scrolled far enough?

Easier to just click the Page 2 link and search again




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: