Google’s suggestion for a better infinite scroll?

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.

meritt• 12 years ago

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.

recursive• 12 years ago

It's the "more" link at the bottom.

lubujackson• 12 years ago

It still jumps around if you hold and drag the scrollbar - always my complaint with these.

jonshariat3• 12 years ago

Ditto. I wonder if that can be remedied by preloading a page or two and holding it for when the user hits the next page

dclara6• 12 years ago

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.

usaphp• 12 years ago

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.

ef4• 12 years ago

You'd be surprised.

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.

couchand2• 12 years ago

Dragging with the scrollbar is far more accurate if you know where on the page you're headed (of course an impossibility with infinite scrolling).

sigmaml• 12 years ago

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.

kevingadd• 12 years ago

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.

snogglethorpe• 12 years ago

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.

PeterUstinox• 12 years ago

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?

dandelany• 12 years ago

I don't think the browser is technically able to move the mouse cursor, I imagine that happens at the OS level. Anyone have a counterexample?

RandallBrown• 12 years ago

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.

syntern2• 12 years ago

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.

epsylon• 12 years ago

Worse, on my desktop, it pushes the system load to 50% CPU (that is, 100% of a core) while scrolling with the mouse wheel. That's unacceptable.

tedmiston• 12 years ago

This reminds me a lot of ScrollSpy in Bootstrap [1].

1: http://getbootstrap.com/javascript/#scrollspy

dj-wonk• 12 years ago

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.

elicash• 12 years ago

Here's a good piece about why it didn't work at Etsy: http://danwin.com/2013/01/infinite-scroll-fail-etsy/

A presentation that goes into some of these results is here: http://mcfunley.com/design-for-continuous-experimentation

pauletienney• 12 years ago

pro : good for mobile users - con : no footer

dkurth• 12 years ago

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.

icebraining2• 12 years ago

"good for mobile users"

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.

Elepsis• 12 years ago

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.

PeterWhittaker• 12 years ago

The permanent menu - with locator options - at the bottom is brilliant.

evan_2• 12 years ago

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.

eyesee• 12 years ago

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.

Aoyagi• 12 years ago

I suggest not using infinite scrolling. It's annoying as hell when I want to get back to where I was or just browse some older entries.

digitaltoad2• 12 years ago

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.

iambateman• 12 years ago

It does.

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.

DangerousPie• 12 years ago

I don't think it does, at least not on Firefox. When you scroll down the URL just updates without a history entry being added.

timmclean• 12 years ago

Nope, this seems to use history.replaceState, not pushState: https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/M...

digitaltoad2• 12 years ago

I was mistaken. I must have clicked through to a page.

huhtenberg• 12 years ago

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.

_frog3• 12 years ago

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.

[1] http://eviltrout.com/2013/02/16/infinite-scrolling-that-work...

jonshariat3• 12 years ago

If you look at the URL bar in google's example it does that as well.

prawks• 12 years ago

The difference is that Discourse does it on a per-item basis, Google's on a per-page. A small implementation detail.

Flimm• 12 years ago

The difference is that it doesn't break the back button! Clicking back takes me back to HN, not back a page.

yeukhon• 12 years ago

Also, visually, the up page# down could be shown on the right hand side. [http://try.discourse.org/t/discussion-happens-so-much/127/98] and with a bigger font. that's more clear. putting it in the bottom is hard to read.

berns• 12 years ago

It's not without problems though. It breaks the incremental find in chrome. When the URL changes, the find dialog gets closed.

rplnt2• 12 years ago

Wouldn't it be better to use anchors? It is the same page after all... now you'll end up with thousands of duplicit entries in your history.

_frog3• 12 years ago

Not quite, the replaceState() function, as its name would imply, replaces a history item instead of creating a new one.

kzahel• 12 years ago

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

toxik• 12 years ago

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.

jfoster3• 12 years ago

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.

fiatjaf3• 12 years ago

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.

syntern2• 12 years ago

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.

watwut• 12 years ago

Reminds me how much I dislike infinite scrolling.

davb• 12 years ago

I'm surprised at how many people here seem to like infinite scroll. I personally can't stand it.

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.

mindrag• 12 years ago

There's an elegant way to add some sort of progress indicator to infinite scroll. I just haven't figured it out yet :)

Crito2• 12 years ago

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.

dclara6• 12 years ago

They do have a page list on the bottom and show which page you are on.

anaphor• 12 years ago

Sure but a progress bar or "page" counter at the top would alleviate that somewhat.

nfoz• 12 years ago

... isn't that part of what a scrollbar is for?

jfoster3• 12 years ago

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

georgemcbay• 12 years ago

I wish to join your infinite scroll haters club.

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.

dubfan• 12 years ago

Every time I've witnessed infinite scroll being implemented into a project I've been involved with, the decision was not made by the developers.

_greim_2• 12 years ago

The hangup with pagination is even if it can be done well, most people associate it with a full page reload, often very slow, often because of ads.

crawdog• 12 years ago

There is a great story on AB testing @ etsy where it actually decreased search conversion. Designers love it, but customers hate it..

dethstar• 12 years ago

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.

joveian• 12 years ago

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

couchand2• 12 years ago

The worst offender here is Salesforce. Ten items by default, click "Show more" to see ten more goddamn items.

highace• 12 years ago

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.

Crito2• 12 years ago

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.

eieio• 12 years ago

The xkcd on infinite scrolling is very relevant here[1]. It even uses the same book comparison!

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.

[1] https://xkcd.com/1309/

fiatjaf3• 12 years ago

This reminds me of Gabriel García Marquez's novel _The Autumn of the Patriarch_, which has no paragraphs and infinitely long sentences.

bhrgunatha• 12 years ago

That's a great analogy - hwo did you find reading that book? I love his other books, but Autumn of the Patriarch took a LOT of mental effort.

MarkyPc3• 12 years ago

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.

ma2rten• 12 years ago

This demo actually has pages.

mikaraento2• 12 years ago

I think it's a good fit on mobile.

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.

Sniperfish• 12 years ago

I hate reading something and not knowing the full length upfront - I want a rough gauge of how long I will be spending on an article.

a_m0d• 12 years ago

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.

alok-g2• 12 years ago

This is the key reason why I hate it too.

brownbat• 12 years ago

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.

alok-g2• 12 years ago

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.

geminitojanus• 12 years ago

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.

tl;dr: don't copy Twitter's UI. Please.

ivanca2• 12 years ago

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.

duncans• 12 years ago

This dentist had it all figured out 3 years ago http://tumbledry.org/2011/05/12/screw_hashbangs_building

Discussion: https://news.ycombinator.com/item?id=2592741

thatthatis• 12 years ago

Sometimes there is no substitute for the insight of an outsider saying "that makes no sense, this is how I expect it to work"

jakub_g2• 12 years ago

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.

smoyer4• 12 years ago

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.

jakub_g2• 12 years ago

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?

_greim_2• 12 years ago

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.

agumonkey• 12 years ago

And I thought my DOMbuffer idea would be new. Did you investigate yourself or did Google publish some technical papers about Wave ?

ps: reminds me of Google Maps tiles.

_frog3• 12 years ago

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.

[1] https://github.com/emberjs/list-view

dalore• 12 years ago

Adobe's Actionscript did the same thing with their lists. Each list item was reused when it scrolled off the top/bottom with different data.

invisible• 12 years ago

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.

bduerst• 12 years ago

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.

EGreg3• 12 years ago

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.

myfonj• 12 years ago

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

solve• 12 years ago

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

Already__Taken• 12 years ago

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.

chc• 12 years ago

Isn't that sort of what the OP is attempting to solve? It's paginated but still scrolls infinitely.

User8712• 12 years ago

Agreed.

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.

btbuildem• 12 years ago

When you're loading more elements at the bottom - drop the equivalent count of elements from the top of the list. Problem solved.

dclara6• 12 years ago

The memory issue is solved, but the browser and CPU are so busy because when you want to get back to page 3 from page 10, page 3 has to be reloaded.

feralmoan• 12 years ago

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

navs2• 12 years ago

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.

Grue3• 12 years ago

There is a paginated mode in the settings, which is a total godsend. I dread the day when Yahoo decides to remove it.

sergiotapia• 12 years ago

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.

donohoe• 12 years ago

You're welcome.

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.

jolt2• 12 years ago

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?

mayneack• 12 years ago

Off Topic: I don't know what the connection between the things the elements linked is, but many of them have single digit view counts:

http://scrollsample.appspot.com/item?id=33

jolt2• 12 years ago

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.

ericgoldberg• 12 years ago

StumbleUpon has been doing this for a couple of year. I always liked the built-in pagination.

RRRA• 12 years ago

So is there a way to use any of those devices coming out (including health monitoring!) without leaking everything to the cloud?

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

wdewind• 12 years ago

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.

bicknergseng• 12 years ago

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.

faddotio• 12 years ago

Designers: please stop it with infinite scroll. They are painful to work with and work around.

When a service switches to infinitely scrolling lists, I stop using it.

louthy• 12 years ago

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.

stickhandle• 12 years ago

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]

Springtime• 12 years ago

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.

[1] http://userscripts.org/scripts/show/121191 [1a] http://userscripts.org/scripts/show/164782

MaxwellM• 12 years ago

Ingenious. Now if only I could Ctrl-F through unloaded elements I'd be a happy camper.

brianbreslin• 12 years ago

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 ?

dclara6• 12 years ago

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.

EGreg3• 12 years ago

Why is the title mentioning Google?

stonogo• 12 years ago

Fucks up my scroll bar -> will not use

eeasss• 12 years ago

Telerik's RadGrid has this same feature for quite some time http://demos.telerik.com/aspnet-ajax/grid/examples/performan...

nroose• 12 years ago

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.

islon• 12 years ago

my suggestion for infinite scroll: make it finite.

weland• 12 years ago

I would like to add a suggestion for better infinite scroll: ban it.

KineticLensman• 12 years ago

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.

flurdy• 12 years ago

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.

pooshoot• 12 years ago

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.

jimeuxx• 12 years ago

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.

Ryel• 12 years ago

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.

Google’s suggestion for a better infinite scroll?

Related Stories