It's worse than that. At least with the book you get to turn the page. This is more like having a book, and knowing there's other pages, but you can never get to the bottom of the page you're on.
It's like a springloaded scroll that spools out of an opaque cylinder case like some sort of measuring tape. One mis-step and you have to spend minutes slowly pulling it back out again.
Meanwhile all the stuff you have already read is sitting around in a big mess, doing nothing but taking up space and getting in the way.
I think it solves a business problem rather than a problem that consumers necessarily feel. Google have good reasons (lessen effects of SEO & boost ad impressions) for not wanting all of their traffic to go to the very top results or the first page.
Infinite scroll encourages users to keep going. It's similar to how certain demographics will scroll through Pinterest for hours. It removes the boundary where someone might say "OK, that's the last page I'm going through."
I think the main problem is that somehow 10 or 20 items on a page got to be standard and that is just annoying. 200 items on a page seems like a good number to me. Scrolling is often easier, but I want it to stop.
OTOH, there are many, many ways to mess up pagination UI as well. Not showing how many pages there are is one that often annoys me, because one time I will go through a bunch of pages of stuff is if I am quickly visually scanning to find something I saw before but couldn't track down with search or bookmarks all that quickly for some reason. If I know what I am looking for is on one of 15 pages then there is a good chance I can find it quickly, but with 50 pages it might be more effective to keep trying my luck at search (or just give up).
Another reason to hate it, which my wife runs across all the time on Facebook - she scrolls by dragging the scroll-thumb down with her mouse. Once she gets near the bottom, the page jumps as the extra content gets loaded, and she has to find her place again.
I have a ton of respect for Aza Raskin, who has pushed this, and I respect that infinite scrolling was a neat solution for some problems of the 2004 web. But I'm not sure those problems are the biggest problems today, and I mostly I feel like "fixing scrolling" is working on the wrong problem, when we could instead be working on "ditching scrolling."
The addendum to Fitt's Law is key here: The current location of the pointer is an infinite target.
Or, to paraphrase, dragging is usability hell.*
If I'm flipping through pages, I want to click or tap one thing, I don't want to have to manipulate things by clicking one spot, holding a button, finding another target and releasing.
I know clicking and dragging is intuitive and easy for all of us, but compared to one simple click at the current mouse location, it's a usability eternity.
My approach would be to display all search results from the first page of Google cleanly on one screen. Maybe two columns wide if necessary, or fit to the screen in a tumblr style way. Not infinite scrolling, not any scrolling. I can keep my mouse on top of a little set of forward and back arrow buttons in the corner and flip through results that way. Or I could just use arrow keys or taps on a mobile device.
* Sure, dragging is the only sensible approach in some cases, maps and canvases and 3D object manipulation, sure. But if it can be designed away.
So I could see click and drag if your search results were not linear, but a two dimensional graph. Maybe you get that graph by... going right or left puts more priority on different terms in the search box, or going up and down adds different commonly included words to your search, I don't know.
The best alternative I have come across so far is implemented at http://www.zdnet.com/ At the bottom of the page, there is a button "View More Articles". Plain and simple.
The mobile browser performance is still much lower than on the desktop, so you don't want to render too large a DOM at once.
Loading a new page over the network can easily take 10s, if you need to reactivate the 3G connection from a low-power state. Of course you can use a single-page-app approach to help that bit.
Scrolling in one direction is one of the easiest (and most fun) interactions you can do on a touch screen - clicking is much harder.
To me it really depends on what I'm looking. E.g if I'm looking at clothes online I just really wanna look at everything at bunch click the few I wanna see and be done with it, not having to be clicking and reloading and what not.
If I'm looking at something like a blog or news it makes more sense since it helps me realize how old something might be.
Probably because of the inferiority complex the infinity characteristic imposes on you.
Makes you feel inadequate for not completing something.
It's ironic as it had already existed in a sense - with TV. It never ends either and powerfully attracts people to continue watching.
I've only read Chronicle of a Death Foretold and Memories of My Melancholy Whores from him, I started The Autumn of the Patriarch, but I couldn't bear it and gave up the book early.
Have a little screen overlay that displays how much memory your browser is using. As it climbs higher and higher, you'll know that you are making progress.
I would feel kind of okay with infinite scroll if it wasn't creating memory problems. Especially on image-heavy (tumblr) / DOM-heavy (facebook) pages. If I browsed the web in 90s mode (one window, one page opened) that would maybe work, but when I have dozens of tabs opened, youtube playing in background and I start browsing an endless memory-hungry page, my laptop (3 GB RAM) starts dying.
Another issue is the one mentioned in the other subthread here, often when you accidentally click some link on the page, you can't go back, it'll start loading everything from scratch. Happens to me e.g. on facebook on IE Mobile (apparently they don't use pushState). This effectively means I have to open links in a new tab.
Google's Wave used (and reused) a fixed number of DOM elements that were filled by fly-weights containing the data to be shown on that page. While the scroll bar showed the appropriate position in the thread, there was a limited amount of data for the items above and below the visible set, and an even more limited number of DOM elements that could be filled with data.
Wave didn't strike me as the most performant of client-side webapps, but certainly may have been ahead of its time in terms of what it was trying to do. I wonder if browsers could make this sort of thing easier, or even automatic. Querying the positions relative to viewport of elements on scroll is expensive, even using throttling.
My friends and I were heavy Wave users back in college. It was simply the best tool available by combining chat, Google docs and forums into a single tool. It was slow at first, but after the first 6 months of improvements it became progressively very responsive.
That's actually very interesting. The UIKit framework that powers most iOS apps uses a similar approach in its collection and table view classes, which is one of the reasons that scrolling managed to be so smooth even on the limited hardware of the original iPhone.
Ember.js similarly has Ember.ListView[1] which was the first implementation of that idea I'd seen on the web. I had no idea that Google Wave had beaten them to the punch by so many years.
Native frameworks have historically drawn on demand, with a bit blit for the unchanged scrolled bit and as little drawing as possible into the newly exposed area - with or without double buffering, depending. And this on hardware far, far less powerful than the original iPhone.
That's interesting. So whenever I scrolled a lot down, and wanted to scroll to the beginning, the related data was re-fetched? Or it was stored in the data model, but just not displayed in the DOM?
I think the message tree was stored in its entirety assuming it wasn't too big. But each of these messages was significantly smaller than the memory footprint of the DOM element in which they would have been displayed. The efficiency of putting new content into a DOM element at the bottom of the list (below the visible content) and reordering it within the parent (so it was at the top was significantly faster than deleting that bottom DOM element and adding a new child element at the top.
Give me a few minutes and I might be able to find the Google I/O talk where this was described ... Wave used GWT to generate its Javascript but it's a great technique for browser-based clients regardless of how you end up with your Javascript.
The method of "recycling" DOM elements is described in minutes 20-25 of this video: https://www.youtube.com/watch?v=T_CLzgEL7FA. I can't find the reference, but I also remember hearing that they used some preloading to make other operations on the screen react much faster (e.g. loading the first 25 messages for each wave headline in the list).
I mean, this is just like how Apple implements its NSTableView. You have a datasource and you implement the table's data source delegates. NSTableView itself takes care of the whole reusing views thing.
Is it? I was going to add it to the list, but the Adapter that manages the data actually generates (and caches) a View for each element. Is there something I'm not understanding?
Yep it is. The Adapter will generate and cache a view for each item - but once the view moves off the screen, the adapter will reclaim/recycle that view, and the next item to request a view will be given the recycled view. In effect it is identical to the ios or flash list model.
It's basically a common pattern when it comes to UI for the lists, I remember MFC had it like a hundred years ago and I bet they weren't the 1st to do it this way.
We do this at Grooveshark for song rows. Pretty fast but it could definitely use some optimizations by the browser since we still have to hit the DOM a lot to update the divs.
I also wonder about "memory problems", but of the soft kind. I like to consuming "pages" of content at a time, spread between many tabs. Usually I read to the bottom of a "page", and then switch tabs. When I come back to that tab, I'm ready to go to the next page.
But with infinite scrolling, I feel like I'd be re-reading content to find my exact spot I left off..
Remember the old printers, and how the paper had holes on the sides, and was just one continuous sheet? Imagine if magazines were printed that way, so you didn't flip pages, but instead you just kept folding back a part of the endless paper and reading on.
That's how I feel with infinite scroll. I like flipping magazine pages like I enjoy clicking links. I don't know what it is exactly, it just feels more natural, and organized.
There are exceptions though. If I'm using an iPhone, endlessly scrolling through my inbox, or song list (with the ability to tap to a particular letter), works incredibly well. Then again, touch screens in general feel great with infinite scroll. It's a tricky situation, and really depends on the device and content.
I guess not, although the page number is shown for you to see which page you are on, but you may forget where you were after you visit a particular link. It's improved to resolve the memory issue, I think. So when you browsed to page 10 and want to get back to page 3, it will reload for you seamlessly, rather than let the browser to keep all the pages in memory.
I agree the parent post, I'd like to keep where I was when I open each link in a new tab. Then the infinite scroll just helps to eliminate the click of the next page.
That's a problem that can be solved by paginating the data and using the history api to push the page state on the stack while the UI seamlessly loads the pages together.
I feel with tumblr it's the combination of gifs and infinite scroll that makes it crap out. It's a far nicer experience appending /mobile/ to a tumblr url.
grid virtualization for the web has been around for a long while with things like slickgrid/extjs (google docs is a great example), maybe there's a good open source project opportunity in writing a virtualized+paginated+history friendly infinite scroll
I've thought about this before - where you have a 2D array of images with infinite scroll in all directions.
You need to track the scroll position, and kill the elements that are scrolling away as you create the new elements in the direction you are scrolling - with the entire purpose of creating enough cached images so that it is seamless to the user.
The problem is that the scroll position changes back when you kill the old elements, so you need to keep a running tally of the matrix somewhere to track the user's position.
You could solve a lot of problems with position: absolute and javascript, which you assume is on.
A bigger problem is that mobile safari doesn't let you execute js during scroll. One way around that is by hsing iScroll which fakes scrolling using CSS.
That's right: a) you don't get scroll events until the scroll has finished, b) you do get touch events that drive the scroll (but nothing during the inertial part), c) the appearance of the page is not updated until the scroll has finished.
You can get around this by using programmatic scrolling (e.g., iScroll, zynga-scroller) but you'll never get quite as nice scrolling as with the native behaviour.
Looking back at the code that I was thinking of, it looks like I was using requestAnimationFrame to do the actual DOM manipulation (based on a variable that was updated in touchmove). Maybe Mobile Safari still allows DOM manipulation during those animation frame callbacks, even if touchmove is happening?
I suppose that’s the way most maps operate: loads map tiles and anchors current viewport properties in URL. Difference is that there is no 'real scroll position with real scrollbar'.
I really liked Discourse's approach to infinite scrolling[1], it updates the URL as you go with the History API's replaceState() function so you can safely navigate away from the page without losing your position.
Infinite scrolling like this works pretty well if you want to do scrolling for, say, search results.
It's all around horrible for something like Twitter, IMO.
The problem with Twitter is that it's conversational, and it's showing the newest part of the conversation at the top. So instead of having a nice conversation history:
Hi!
Hello to you good sir.
How are you doing today.
I'm fine.
You get:
I'm fine.
How are you today?
Hello to you good sir.
Hi!
...and you lose the navigation state, so it's impossible to tell where you were at last on Twitter except by memory.
Twitter already fixed this in iOS (you always apparead where you left so you read everything in order), is just taking them a while to fix it in the browser.
One of my favorite features of infinite scroll is how it can make clicking on the footer of a page nearly impossible. E.g. try clicking on "About" or "Careers" on the bottom of http://venturebeat.com
You would be happy to live here in my town where the faster internet connection possible is 700kbps and you have plenty of time to click on footers of pages while the infinite scroll is loading.
There's a link to the footer, and the footer links are in a fixed footer that is always visible. Not super-pretty but I think infinite scroll just means no footer.
On Facebook there is a footer, and seemingly no way to get to it unless you find a short enough page or manage to get to it faster than the infinite scroll can load.
This is an implementation choice, and not the failure of infinite scrolling: you could embed the infinite scrolling inside a DIV and have a visible footer DIV underneath. Or alternatively, implement a sticky footer, or e.g. a fixed footer that appears on certain conditions.
I tend to dislike pure infinite scrolling and instead prefer on-demand loading.
With on-demand loading you would set the virtual height of the scrollable area to the height necessary to show all (or a huge chunk of) your data, and then page in chunks of the data as it approaches the viewport.
Then dragging the scrollbar works, and touch scrolling shows a reasonable representation of how much data is left.
The problem is that many of the places they use infinite scrolling have such large datasets that doing this would make the scrollbar borderline useless for small movements (move back half a page or 1-2 pages) -- which probably account for 99% of scrollbar uses in this context. Google search for "cat"...
Of course if you actually advanced extremely far in a typical "infinite" scrolling view, the scrollbar would similarly become pretty useless, but in practice very few people actually scroll all that far, so it seems better to optimize for that case.
They could meet halfway by making the "scrollbar readjustment" chunk size somewhat larger than the "load new data" chunk size, so you get the on-demand loading efficiency of the latter with fewer scroll-bar jumps, but I don't think they could make the former too large without creating more usage problems than they're solving.
I wonder how many people do hold and drag the scrollbar, I am so used to scrolling using a touchpad on Mac and mousewheel on PC, so I never even touch a scrollbar.
I've done many user tests and training sessions only to inwardly wince every time the user painstakingly does that. (And this on their own hardware, with their own mouse they use every day at work.)
After you explain it, they say "wow, that's neat." And then promptly forget it and start dragging the scrollbar again.
I was until recently a devoted scroll-wheel-user. But I'm starting to see the first signs of arthritis in my fingers (far too early if you ask me) and scroll wheels are becoming increasingly uncomfortable.
I've been surprised to find that dragging an old-fashioned scroll bar is actually a faster and more accurate than the wheel if you're scrolling by more than a page or so.
It is very inconvenient on a large page like this, should you need to quickly move up/down to read a related comment. If you know it, dragging the scrollbar, on the other hand, is quick to land you in the approximate target region.
I don't know if you ever used the music service Lala back before it got bought by Apple and shut down, but they had a really nice infinite scroll implementation.
When viewing your music library, the scroll bar grabber would be the correct size for how many items were in your library so grabbing it and scrolling would work right. It didn't load all X number of items you had at a time though either.
Good idea. I think it's better than infinite scroll, but cache one page before and one page after to improve the page loading more smoothly using AJAX, just don't push me to the next page until I hit the "next" button.
This should be fixed by the browser. If mouse is hold-clicked on scrollbar and the height of the document changes. the position of the mouse should change as well.
What's the problem with that?
I'm working on an infinite-scroll widget, and I have a very specific insight into this: if you know the number of non-visible rows and their heights upfront, it can be implemented in a way that doesn't jump around. If you can estimate the heights closely, you can make the jumps less disturbing (but still noticeable in the trained eyes).
Unfortunately this is rarely the case, with a few exceptions, e.g. a spreadsheet, where you know everything upfront.
I hate infinite scrolling with a burning passion. You're reading the article and scroll down 2 pixels too far and WOP you're loading something again. Qz.com is one of the worst offenders here.
In this case I called it pre-loading (it's not infinite either). You get to the end of an article and we have the next one ready for you. No need to make a choice on what to do next, just follow through if Headline is of interest.
Not perfect, but those who use it most do love it.
Doesn't this still effectively break the back button or at least the users view of the back button? To the user although there are visual hints, he/she hasn't left the page. Scrolling down the page however creates multiple history entries.
This would be perfect if clicking the nav didn't cause a page reload. I expect the page to go back to an entirely previous page, if I hit the back button in this case.
That would not be the case if the sections of content were different from one another.
- A super-scrolling page with different sections of content might keep the back button functionality the way it is here.
- Homogeneous content like Facebook posts should not incur a back button through the pagination.
I'm not a fan of infinite scroll in the main, but there are use cases for it. I've often thought search results would be a good candidate. The don't suffer from the need to provide user feedback on progress of completion. I also think it provides Google with more ad opportunites including placing them within the infinite scroll at some interval, and, of course, the highly prized sticky ad ;) [edit - wanted to add that it would also lessen the blow of being on p2 ... in fact I would expect search users to frequently get deeper into the results yielding an improved feedback loop]
I've been using a userscript [1] for the past year that adds the feature to search results and the like. Huge improvement, and with a little custom CSS styling the additional pages are appended more seamlessly.
The feature I appreciate about this particular userscript is it's clear where the page breaks are, and adds links to each newly appended page, allowing the user to link directly to them - which would be useful to see in more infinite scroll implementations, and seen used in the main HN link.
Designers: Please continue to use infinite scroll where it's appropriate, it is much better than pagination much of the time, especially on mobile devices.
When a service sticks with pagination (like Amazon's movie service) I stop using it.
Infinite scroll is about making it as seamless as possible for the user to get new information.
How many times do you go on a paginated page, get to page 5 and say "okay, after page 6 I'm done." Then you either leave or continue on that process...
Infinite scrolling takes away your perspective of exactly how much content you're consuming and how much time you may be wasting. It is only until youre done and you attempt to scroll back up that you realize how much time youve spent.
My side-project now is very much like Tumblr/Pinterest and I found this post interesting because for awhile ive been trying to find the best middle-ground between infinite scrolling and some form of incremental, pagination-styled display of content.
Honestly I'm stumped but for right now my best solution is to load about 20 items, lazy load another 30, and use pagination for the rest. Although I've been thinking about just displaying an infinite scroll toggle switch on the bottom of the viewport after the user reaches the end of the initial item list.
If you are someone who actually likes to have some control over what is happenning on your computer, and if you want to have some organization when you are dealing with a list of things that is pretty long - hundreds/thousands or more items - then pagination is useful. And continuous scroll is tempting/seductive, but ultimately flawed.
This also needs to keep only N pagefuls above and below the page cut. E.g. if N is 2 and I'm on page 5, then it would only have pages 3-4,5,6-7 in DOM.
This would ensure that users get the same scrollbar range on page 5 regardless of whether they infi-scrolled themselves there or just clicked on "page 5" in the index.
Favor: could someone share an intelligent (or at least in-depth) write-up of the pros/cons of infinite scrolling? Most of what I'm finding on the web is content farmy.
Also: at what point is memory usage worth worrying about? Scrolling for pages on end has to be tough on a browser.
Most sites that implement infinite scrolling effectively "unload" content that's far enough off the screen, much like they delay-load content that's below your scroll area. The net memory usage shouldn't be dramatically worse.
Another possible pro (from the site-owner's perspective) is increased user engagement. When you are quietly loading more content all the time, it's easier for the user to continue to say, "I'll just look at one more post."
On the cons side, as others have mentioned, if you navigate away from an infinitely scrolling page, then click the back button, you often don't land in the correct place.
Well, maybe; mobile browsers are often more constrained in terms of RAM. My Android phone only has 256MB, so infinite scrolling tends to cause the browser to bail out.
I can't believe all the negative comments on here. If you have enough tabs open that infinite scrolling starts to bog down your browser, you should probably find a girlfriend/boyfriend and get out of your mom's basement or replace your computer with one made after 2003. Infinite scrolling, especially as shown here, is fantastic because it doesn't require endless hitting of the back button to get to the original post. The only time I've had a problem with infinite scrolling is for facebook friend purging and even then, who cares!?! If you don't like sites that use infinite scrolling, don't use those sites. This hybrid pagination/infinite scroll option looked awesome to me.
I don't think this fixes what is the core issue with infinite scroll: when I click into a subview and then press back, I am not returned to the same place where I was before. iOS, for instance, handles this extremely well by literally stacking the new view on top of the old one rather than changing the contents of the view. This implementation attempts to fix it, but only gets close, and so I have to re-contextualize myself every time I press back.
I would argue that Airbnb's old Infinity.js is way better than this. Smoother and has a fully functioning scrollbar still. This one's pretty janky imo.
My problem with infinite scrolling is that it is very hard to go straight to the last element. My example: A Flickr user with over 1000 images in their photostream. photostreams are loaded most recent first. But what if I want to see the first picture they submitted? Virtually impossible.
Infinite scroll is fine, if it remembered state when you click on a link/article and go back to the scrolled page. They rarely do, and you have re-infinite scroll to wherever you where before. So frustrating every time.
Its easy when you are just dealing with "text elements" of equal size. But if you are loading images or injecting content in the list elements, the back-button starts to break.
I'm not a big fan of infinite scrolling, and when it breaks standard desktop functionality like CMD + Up Arrow, as in the case of Google image search, I could really do without it.
Why do so many designers/developers of pages with infinite scroll forget they put their footer menu in there and it is now inaccessible due to the scroll ?
I'm also concerned about the footer menu, may it be sticky or keep it on the bottom not shown. Looks like most of the sites have the latter. Maybe the footer is not that important, just to embed more links.
Why is this so hard that even Google can't get it right? If a page has little to no other content than the content in the list, why is it worth the hassle?
Unless you scroll a page at a time using Page Down or Space.
When I'm at the top of the page, the last visible item is "Live Room". If I page down once, the first visible item becomes "Black Refraction". I never even see that there's an item called "Live Room Out", it's obscured first by the footer and then by the header.
I've wondered if browsers couldn't reduce the paging distance by subtracting the height of header and footer regions on the page (as identified by position: absolute?). Something tells me it would not be so simple.
it should be possible for the page to fix, I think, by listening for a pagedown or spacebar press and changing the scroll position based on the height of the viewport minus the height of the stuff that obscures the viewport.
I think it would be really difficult for the browser to come up with a solution that would work anywhere.
No. Grab an extension like HN Special or RES if you want the functionality.
Infiniscroll is an evil creation, made worse by developers who insist on creating a footer at the end of the scroll view, just out of reach so that you can never quite get to it.
I don't even know how to get a second page of HN results. Never had the need. Infinite scrolling creates a daunting never-ending feeling. I like the sense of accomplishment after scanning/reading through a fixed list of results. Infinite scrolling makes that carrot forever out of reach.
It intelligently remembers where you were if you click a link and then back; it restores your previous scroll location. Pleasantly surprised by the behaviour as I usually do not enjoy infinite scroll.
Imagine having a book where no matter how much you read, it never seems to end. No milestones, no sense of progress. Just page after page after page.
It just feels... icky.