UI-Patterns.com
Design Patterns
Screenshots
Users
Blog
0 selected ▼
My account
My account
In contrast to the Pagination patterns, the Continuous Scrolling pattern has no natural break. When using pagination patterns, a decision to only show a subset of data at a time and then let the user request more data if wanted is chosen. With the Continuous Scrolling, new data is automatically retrieved as the user has scrolled to the bottom of the page. It thus appears as if the page has no end, as more data will be loaded and inserted into the page each time the user scrolls to the bottom of page.
The problem with using pagination for browsing between subsets of data is that the user is pulled from the world of content to the world of navigation, as the user is required to click to the next page. The user is then no longer thinking about what they are reading, but about how to get more to read. This breaks the user’s train of thought and forces them to stop reading. Using pagination creates a natural pause that lets the user reevaluate if he or she wants to keep going on or leave the site, which they a lot of the time do.
It can be argued that Continuous Scrolling can be frustrating for the user, as there is no natural pause. The user will ask himself: When am I done reading?
When you scroll to the bottom of the page at DZone.com, a load indicator tells you how much time you'll wait until the next news items have finished loading.
The updates feed in the account home at facebook.com features a soft version of the continuous scrolling - or pagination - where the next results aren't loaded automatically, but on clicking the "Older posts" link. Instead of linking to a new pagination page, the next items are pasted in the bottom of the page.
UI-Patterns.com is the work of Anders Toxboe – a Danish web developer seeking to categorize what has before seemed like ad hoc approaches to developing web applications.
About UI-Patterns.com
Want to be a part of the UI-Patterns.com family? Contribute!
Write for us
More UI-Patterns.com tweets
© Copyright 2012 - Anders Toxboe, UI-Patterns.com
Martijn van Welie
3 Feb, 2008
There are several downsides to this pattern such user expectations and bookmarking issues. Can these issues be dealt with? If so, how?
Matt Katz
7 Feb, 2008
This pattern sidesteps some issues that pagination has. Continuous scroll is good for large lists that the user has no way to jump predictively forward. What does it mean to want to go to the 4th page of google’s search results – you are just saying that nothing you’ve looked at so far met your needs. Continuous scroll is much better there.
Where users could make a rational jump to a page, pagination is better.
Continuous scroll > paginations when:- User has no way to rationally jump to a specific chunk of data.
- User must disregard pieces of information before going to next ones.
- Data is generated dynamically and bookmarking a page of results has different meanings from session to session.
Pagination > Continuous Scroll:baruch sachs
4 Mar, 2008
Does anyone have any experiences with using this style of scrolling with large datasets ( >10,000 rows)? What type of performance and scaleability issues have people found?
Anders Toxboe
6 Mar, 2008
Baruch sachs: I do not see how performance would be an issue especially for this pattern as compared to regular paginated pages. The user isn’t forced to read 10.000+ rows, but will stop scrolling down, when he or she has “had enough”. Besides, the ajax call will only load the actual extra content (the extra list items) – and won’t have to deliver all the extra header and footer html and image files will that is normally needed on page refreshes.
The main flaw of this pattern is in my opinion the changed behavior of the regular web page – that the user does not know what to expect. Will the user actually realize that extra content is loaded? Will he or she be confused by the continuous scrolling? This pattern is still experimental, if it will ever be anything else than that in its current form.
Janko
25 Mar, 2008
I think this patter could confuse average user – it is not typical behaviour and it is not something user would expect.
If the list is a result of a search, you can use pagination, filtering and sorting to enable user to find specific item(s). If it is just a endless list user will browse anyway – so paging will be good enough.
Justin Robinson
31 Mar, 2008
Perhaps a simple line “Show me more…”, when clicked you go on with your ajax load of the next XX number of items/content blocks. Leave the decision in the hands of the user.
Limo
17 Mar, 2009
I can see how this would be useful, for example in search engine results you could simply use continuous scroll to get to the next page until you find what you want, instead of using pagination.
Kenny
16 Jun, 2009
>>What type of performance and scaleability issues have people found?
With potentially large datasets, continuous scroll can be a means to reduce the load – an example might be a banking transaction history page, where the initial load showing the most recent transactions only. The user then has the option to drill down view ‘more’ further if they are interested.
This pattern is especially applicable where there is a need to avoid high-cost transaction count queries, which are usually required for conventional pagination.
It’s also a pattern that performs very well with mobile applications and/or ajax applications, where the reduction of page size is important.
Nalin Singapuri
17 Jun, 2009
@baruch sachs
one of my clients is a home search engine that uses continuous scrolling – they have about 1 million searchable properties so result sets can easily exceed 10,000.
There is no overhead above and beyond that of pagination if the code is well designed. In our case we lazily load the page being looked at +/- a few pages worth of buffer (what would be loaded anyway for pagination + a small buffer). You can see an example at www.homeprodigy.com/index.php?main_page=map
Sys
22 Feb, 2010
Cool site, this is my first time here, and I’m enjoying it so far!
For the continuous scrolling functionality, I believe the overhead issue is being misinterpreted.
There is not going to be an unusual impact to load-times; that’s true. However look at the browser memory usage when you start having the single session hold onto quite so much in a single pane. That’s the real overhead of this approach. I guess if widely adopted, this could cause browser memory footprints to balloon yet more (they’re already pretty abhorrent these days).
That and the difficulty in referencing a “spot” of interest. After-all is is common behavior with pagination to go through 5 pages, and remember “There was something I needed on page 3. . . which I’ll go back to after I check 2 more pages just to be sure”.
Perhaps something like a floating marker that can be set for any particular viewed screen? E.g. a floating “+” that rides along mid-page or lower 2/3rds of the page (which is where the scroll bar will tend to live). If Clicked, it sets a number, or optionally allows users to add a note like “cool item here!”. The # or note floats up to the top of the screen, and may be clicked at any time to return to that particular “view” in large page.
As more items are marked, they could move to the top, and move items to the left, forming what looks like an ad-hoc row of tabs.
My 2 cents, but I think this may solve at least some of the concerns.
Manoj
16 Jul, 2010
Take a look at Google Books – aren’t they implemented this effectively in terms of browser memory?
Google Books keeps 3 to 5 pages in memory at once (in HTML DIVs) – this also depends on which zoom level you are in. When you scroll down they add new DIVs to the container DIV and remove the old ones.
I think the continuous scrolling is very cool idea. At least for books, reports, or anything that comes as lot of pages.
Justo
16 Sep, 2010
I agree with @Matt Katz, this pattern description is out of date and does not address important issues of scrollers representing the total scope of the windows contents. Its not just as a vertical pagination pattern as suggested here.
The example even breaks the standard scroller behaviour which is…
1. The position of the drag bar represents where it is in the total list.
2. The size of the drag bar represents the size of the displayed items in relation to the total.
3. Clicking below the drag bar takes you down a page and above takes you up a page.
4. Clicking an arrow moves you up one line or down one line.
Deviating from this causes confusion.
Mindaugas Kuprionis
20 Sep, 2010
I’d add to Matt Katz’
Continuous scroll > paginations when:
- When user scans items top to bottom
And this I believe is very important condition.
Concerning braking of scroller behavior – if user is scanning items top to bottom, one at a time, he would use scrollbar only to scroll a little. But in that case there always should be items below the fold – so that user doesn’t notice stuff is being loaded (except that scrollbar changes).
If he jumps straight to the bottom, there should be an indicator saying “we’re loading more”.
Lydia Mann
29 Sep, 2010
I call this anxiety attack scrolling – totally stresses me out when I realize I have no control over the amount of information being presented. I stop reading the content and focus on where I am in the data set.
CN
15 Oct, 2010
The implementation we built does not use the OOTB scrolling page, but a div with a widget’d scrollbar. The scrollbar precalculates position based on amount of content available; i.e., if you have a table with 10,000 rows, dragging the scrollbar to the halfway point would roughly fetch you row 5,000+ with buffer either direction.
The caveat is that each row must be of fixed height to correctly account for positioning.
Avinash Birambole
21 Dec, 2010
I assume we are moving towards more gestural interaction patterns, Looking at the future trend more and more content is accessed on Touch screens and scrolling on touch is much more easier.
www.flickr.com/photos/birambole/5265041653/
Karla
28 Jun, 2011
This kind of page will become more common because of smart phones, where loading pages can be very slow.
David L
12 Sep, 2011
i agree with Karla. Just look at google images, i think that this will become more
and more used in the near future. Excuse my bad english.