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.
To paraphrase Jeff Goldblum's "Ian Malcolm" in Jurassic Park:
"Yeah, but your front-end developers were so preoccupied with whether they could that they didn't stop to think if they should."
I personally find infinite scroll to be far worse than cleanly paginated pages in every regard. YMMV, I guess.
I don't hate infinite scrolling as much as I used to, but I think that's just because I'm not a heavy user of any sites that have infinite scrolling.
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.
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."
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).
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 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.
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.
Ember.js similarly has Ember.ListView 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.
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).
ps: reminds me of Google Maps tiles.
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 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.
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.
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.
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.
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:
Hello to you good sir.
How are you doing today.
How are you today?
Hello to you good sir.
tl;dr: don't copy Twitter's UI. Please.
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.
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'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'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.
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.
IIRC it isn't exposed to JS except maybe for some new fullscreen API (not my area, sorry.)
Unfortunately this is rarely the case, with a few exceptions, e.g. a spreadsheet, where you know everything upfront.
I could not find what was new witouth explanation.
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.
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.
IMHO. But this is super cool otherwise.
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.
When a service switches to infinitely scrolling lists, I stop using it.
When a service sticks with pagination (like Amazon's movie service) I stop using it.
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.
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.
Also: at what point is memory usage worth worrying about? Scrolling for pages on end has to be tough on a browser.
A presentation that goes into some of these results is here: http://mcfunley.com/design-for-continuous-experimentation
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'm getting really annoyed that none of those will actually give you the tools to dump your data yourself in total privacy.
(And no, I don't care how many step you had today!)
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 think it would be really difficult for the browser to come up with a solution that would work anywhere.
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.