Google’s suggestion for a better infinite scroll?(scrollsample.appspot.com)
scrollsample.appspot.com
Google’s suggestion for a better infinite scroll?
http://scrollsample.appspot.com/items
40 comments
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.
There's an elegant way to add some sort of progress indicator to infinite scroll. I just haven't figured it out yet :)
They do have a page list on the bottom and show which page you are on.
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."
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 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.
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.
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.
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.
There is a great story on AB testing @ etsy where it actually decreased search conversion. Designers love it, but customers hate it..
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.
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).
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 worst offender here is Salesforce. Ten items by default, click "Show more" to see ten more goddamn items.
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.
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.
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/
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/
This reminds me of Gabriel García Marquez's novel _The Autumn of the Patriarch_, which has no paragraphs and infinitely long sentences.
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.
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.
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.
This demo actually has pages.
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.
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.
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.
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.
This is the key reason why I hate it too.
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 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.
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.
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.
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
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
CodeMirror does it on the web since version 2, somewhen in 2011. http://marijnhaverbeke.nl/blog/a-pathological-scrolling-mode... is the most recent explanation. I'd be surprised if there weren't earlier implementations of the idea.
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.
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.
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).
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.
Android's ListView also is built around view recycling. But these are both situations where the framework supports the recycling.
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.
Cool ... I knew I was passed back a "convertView" sometimes but didn't realize it was recycling them.
Adobe Flex had the same model and it worked quite well (despite the framework's other flaws).
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.
Stored in the data model; the memory issue is a rendering one (not a hard drive capacity one)
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.
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.
ps: reminds me of Google Maps tiles.
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.
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 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.
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.
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.
You can use the touchmove event to do things while mobile safari scrolls.
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 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..
But with infinite scrolling, I feel like I'd be re-reading content to find my exact spot I left off..
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.
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.
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.
Which it actually does. Look at the URL.
Isn't that sort of what the OP is attempting to solve? It's paginated but still scrolls infinitely.
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.
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.
When you're loading more elements at the bottom - drop the equivalent count of elements from the top of the list. Problem solved.
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.
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 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...
[1]: http://eviltrout.com/2013/02/16/infinite-scrolling-that-work...
If you look at the URL bar in google's example it does that as well.
The difference is that it doesn't break the back button! Clicking back takes me back to HN, not back a page.
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.
It's not without problems though. It breaks the incremental find in chrome. When the URL changes, the find dialog gets closed.
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.
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:
tl;dr: don't copy Twitter's UI. Please.
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.
I'm fine.
How are you today?
Hello to you good sir.
Hi!
tl;dr: don't copy Twitter's UI. Please.
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
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.
All of the links in the footer are also at the bottom of the right-hand main column
Thank you for pointing that out. I think that area might have been a blind-spot for me. (immediately below the ads)
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.
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.
It still jumps around if you hold and drag the scrollbar - always my complaint with these.
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
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.
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.
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).
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.
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.
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 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.
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.
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.
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 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?
The OS has APIs that applications like the browser can use for that, e.g.:
Win32: http://msdn.microsoft.com/en-us/library/windows/desktop/ms64...
X11: http://tronche.com/gui/x/xlib/input/XWarpPointer.html
Win32: http://msdn.microsoft.com/en-us/library/windows/desktop/ms64...
X11: http://tronche.com/gui/x/xlib/input/XWarpPointer.html
Applications in most operating systems can set the cursor position. Full-screen games often reset it to the middle of the screen every frame.
IIRC it isn't exposed to JS except maybe for some new fullscreen API (not my area, sorry.)
IIRC it isn't exposed to JS except maybe for some new fullscreen API (not my area, sorry.)
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.
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.
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.
Unfortunately this is rarely the case, with a few exceptions, e.g. a spreadsheet, where you know everything upfront.
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.
More explanation on their blog: http://googlewebmastercentral.blogspot.com/2014/02/infinite-...
Thanks.
I could not find what was new witouth explanation.
I could not find what was new witouth explanation.
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.
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
Discussion: https://news.ycombinator.com/item?id=2592741
Sometimes there is no substitute for the insight of an outsider saying "that makes no sense, this is how I expect it to work"
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.
[deleted]
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.
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.
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.
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.
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.
Nope, this seems to use history.replaceState, not pushState: https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/M...
I was mistaken. I must have clicked through to a page.
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.
[1] http://userscripts.org/scripts/show/121191 [1a] http://userscripts.org/scripts/show/164782
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
Reminds me how much I dislike infinite scrolling.
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.
When a service switches to infinitely scrolling lists, I stop using it.
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.
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.
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.
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.
Also: at what point is memory usage worth worrying about? Scrolling for pages on end has to be tough on a browser.
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
A presentation that goes into some of these results is here: http://mcfunley.com/design-for-continuous-experimentation
pro : good for mobile users -
con : no footer
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.
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.
"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.
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.
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.
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.
Telerik's RadGrid has this same feature for quite some time
http://demos.telerik.com/aspnet-ajax/grid/examples/performan...
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!)
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!)
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
http://scrollsample.appspot.com/item?id=33
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.
[deleted]
This reminds me a lot of ScrollSpy in Bootstrap [1].
1: http://getbootstrap.com/javascript/#scrollspy
1: http://getbootstrap.com/javascript/#scrollspy
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?
StumbleUpon has been doing this for a couple of year. I always liked the built-in pagination.
Ingenious. Now if only I could Ctrl-F through unloaded elements I'd be a happy camper.
The permanent menu - with locator options - at the bottom is brilliant.
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.
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.
I think it would be really difficult for the browser to come up with a solution that would work anywhere.
I would like to add a suggestion for better infinite scroll: ban it.
Love this. If only Hacker News and Reddit would implement it.
Doesn't RES have this?
RES uses infinite scrolling of some sort, yes.
Actually, a pretty decent infinite scroller, with markers so you know which page you are (and this makes it a lot easier to navigate).
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.
Please do not implement infinite scroll. I find it super annoying.
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.
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's the "more" link at the bottom.
Fucks up my scroll bar -> will not use
Why is the title mentioning Google?
my suggestion for infinite scroll: make it finite.
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.