Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

Which is faster? Scrolling down or clicking a button to reveal more content? Currently, our site requires clicking of page numbers to reveal more content. We have 9 channels per page, which fits on one screen in most common resolutions.

Personally, I believe having 2 or 3 pages worth of content and scrolling down to reveal those pages would be easier. We should have 20+ channels per page. I just flick my mouse wheel or hit the down key. I don't have to aim at a tiny button (which takes longer as per Fitts's Law).

share|improve this question
The following design patterns contain discussions of the pros and cons of paging versus continuous scrolling: developer.yahoo.com/ypatterns/navigation/pagination/item.html ui-patterns.com/patterns/ContinuousScrolling welie.com/patterns/showPattern.php?patternID=paging –  Antony Quinn Oct 6 '10 at 10:54
I don't think you need to dig through study findings or research results to realize that using a mouse wheel with the cursor anywhere on the page is much easier than moving the cursor to a target and clicking it. –  Ian Lotinsky Oct 6 '10 at 13:04
Do your users use Amazon or Ebay or Facebook or Twitter? If so, then yea, scrolling is the way to go. –  DA01 Oct 6 '10 at 14:54
One thing that scrolling can't do easily is jump to a specific point/page. If this is not something that the user needs to do regularly then it is not an issue. In terms of having all the content available and letting the user scan, scrolling is more effective. But in terms of progressively disclosing content to the user, a user-driven event like a mouse click is more effective. –  Michael Lai Sep 4 '13 at 3:46
add comment

6 Answers 6

up vote 43 down vote accepted

Paging should be used to break content into semantic or task-related groups of content, such as by your categories in your menu bar on the left. This allows users to find content by what it is (e.g., the page title in a menu) rather than where it is (e.g., page number or relative position in a scrolling page). Generally user tasks depend on what (“I need to check sports”) not where (“I need to check channels two-thirds down the list”).

Each page of related content may scroll. At one time, you couldn’t rely on nearly all users knowing how to scroll, so designers were advised to keep all content “above the fold.” That concern is largely gone now, and users are perfectly able and willing to scroll if there are signs the content they want is further down the page (although for the sake of efficiency, you still should put the content users want most at the top, such as provided by your sorting feature). [See Jakob Nielsen's article, "Scrolling and Attention."]

In your case, it looks like you’ve a list that is arbitrarily broken into pages. That is almost always inferior to putting everything in one large scrolling list. I’ve found scrolling to be about three times faster than paging for finding and comparing data in a table or list. More systematic research on search results (pretty close to what you have) found that pages of 50 items could be scanned through faster than pages of 10 items (100 items were apparently not significantly different than 50, but at that point, there were only two pages of results).

Scrolling has the following advantages over paging in lists and tables (not all necessarily apply in your case):

  • The scrollbar control is standardized so most users are already familiar with it. Paging lacks standardization so it takes attention and learning to use it (e.g., where in the page the links are located, whether there’s a First or Last link, whether there are links to selected individual pages).

  • The number of items shown can adjust automatically with window resizing, allowing users to optimize the number of items visible in one step and avoiding situations when there is both scrolling and paging.

  • The scrollbar is quickly accessible no matter where the user is in the window. Paging interfaces typically provide the page links at only the top and/or bottom of the page which can mean a long slew; they may even scroll out of view.

  • Users can move as little as one item at a time to show the items they want to see together. Paging splits items into arbitrary groups which can result in the items of interest being split across pages.

  • Users can scroll to anywhere in the list with a single drag. Paging is limited to the page links shown, generally limiting the user to move only around the immediate neighborhood.

  • Users can multi-select any set of items to perform an action on them (e.g., copying, deleting), and users can look at any other item while maintaining the current selection. Paging generally allows and maintains only selection of the items on the current page.

  • User sorting is less likely to result in disorientation. With scrolling you can leave the scroll position where it is or you can automatically scroll to “chase” the list item that currently has focus; either way users do okay. However, with paging, users can be disoriented when sorting changes everything on their current page or if their page number changes to some other value to keep the current item in focus. Many paging implementations (like yours) reset the user to Page 1 after sorting, which seems to avoid disorientation, but too often requires the user to re-navigate to a particular item.

  • Users can still move one “page” at a time anyway by clicking the “track” of the scrollbar.

I would recommend you put all your channels in a single scrolling pane. Put the channel list in a separate pane or frame from the menu and other general controls so they remain easy to access. Mixing paging and scrolling (e.g., 20 of 127 channels per page) may be worse than paging alone, forcing the user to decide when to do each, and sometimes they may need to do both (e.g., scroll up or down to the links to page). It looks like 127 channels is about 500kB to load in one page. Presumably your users have high-speed connections if they’re watching TV on the web, so you can count on the 500kB loading in only a few seconds.

Now 127 channels on a single page may appear to be "too many" to the user, so you may want to break them up within the page (e.g., putting in headers for "Today," "Yesterday," "Last Week" when sorted by Newest).

share|improve this answer
I really like this answer, but I'd like to see a few more references to some of your assertions (such as how scrolling used to be not recommended but it's not a problem now). –  Rahul Oct 6 '10 at 13:12
I hope you don't mind, I went ahead and added this reference to your answer. useit.com/alertbox/scrolling-attention.html –  Patrick McElhaney Oct 6 '10 at 16:13
Thanks, Patrick. There also similar observations (if less reported hard data) from cxpartners.co.uk/thoughts/… and graphpaper.com/2008/07-29_the-scrolling-experience-and-the-fold –  Michael Zuschlag Oct 8 '10 at 12:04
add comment

Although scrolling is the preferred way in many scenarios, in a wizard/tutorial or any other similar "do one thing, then do the next thing" situation, a next/"1,2,3..." button can be a better way, so that the user knows that he/she is leaving the previous step/question and a new one can be dealt with.

share|improve this answer
add comment

In addition to the points mentioned in the accepted answer:

Scrolling has more built-in affordances than a next-click:

  • dragging the scrollbar to scroll with life preview
  • clicking the scrollbar to jump page-wise
  • clicking the end buttons for small steps (ideally, per item)
  • mouse scroll wheel (or similar mechanisms on laptops)
  • Page up / Page Down, Cursor up / Cursor down buttons

All these mechanisms are rather standardized, and users are familiar with it. The scrollbar is often a mere indicator that I can use the scroll wheel.

The only downside of a badly implemented scrollbar is that it's not item oriented, i.e. the jump distances do not directly correlate to content. (Or, in other words, it may be hard to implement that way).

share|improve this answer
"The only downside of a badly implemented scrollbar is that it's not item oriented, i.e. the jump distances do not directly correlate to content." . I love Sausage.js as a nice enrichment for this. See: christophercliff.github.com/sausage –  Geert-Jan Feb 1 '12 at 19:58
add comment

If you are asking about speed, then scrolling is definitely faster than clicking through tens of pages, 9 items on each. The only drawback of scrolling long pages might be the user disorientation, once there are more than 50 items on a page.

I think you could compare this with web interface of Twitter. Wouldn't it be annyoying if you had only 9 tweets per page and had to click the "next / previous" buttons in the bottom...

share|improve this answer
add comment

Let alone a trackpad with inertia scrolling!

I really dislike those little next/previous page icons/links. When the content forms a whole, stick it in one page and scroll. Else, section it with a decent TOC or categories.

On your site, the "All" requires 23 pages! If you stick this in a single scrolling page, you may want to break it up in some meaningful way, e.g., by category, alphabetically, … In such a case, the sidebar becomes a TOC, and clicking an entry jumps to that position within the page. Easy jumping and scrolling combined.

share|improve this answer
add comment

Without a doubt scrolling is way faster than finding and clicking a link. But just because it's faster doesn't mean you should make your pages super long. In other words, you shouldn't use infinite scrolling in every situation because if there's too much content users might not have the patience to scroll to the very end.

Why Scrolling is the New Click

This article points out that if you design your page for scrolling users can "see all content in order on the page without needing to click any links." But if you use page links, "users can skip a page link and go to the one they like without ever visiting the pages they skipped. If a page link label doesn’t appeal to them, they won’t click it and see the content behind that link."

That means you're in danger of users not seeing certain content if they don't click one of your page links. But if they scroll, it's almost certain they will see it.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.