Paging, Scrolling, and Infinite Scroll :: UXmatters

Paging

Paging simply means displaying and enabling users to navigate a series of pages that contain contiguous chunks of content. A specific number of items in a list, rows of a table, or lines of another type of content load on each page. A set of pagination controls appears on the page, usually right after the content itself, indicating the current page and enabling users to access other pages, as shown in Figure 2.

Figure 2—A list with pagination controls
A list with pagination controls

Pagination controls can vary almost infinitely. You can list the other pages, provide Previous and Next buttons, allow jumping to specific pages, and combine these elements in various ways. You can also duplicate these controls at the top of each content area to help orient the user, but this can sometimes be counterproductive. However, paging is all too often the default design choice—maybe because a lot of development practices are stuck in the past. However, just because this is the traditional design option that doesn’t make it safe, and in many cases, its problems outweigh its benefits.

Benefits of Paging

  • Paging may be the default approach. Paging is built into a lot of frameworks, so developers assume this behavior is optimal. Unless you want to argue with them, you’ll get lots of paging.
  • Paging limits user choice. This can be a good thing. Google, for one, uses paging to make people focus on the top few search results because they know almost all good results are there. You can reduce the paradox of choice simply by restricting easy access to options.
  • Marketing can easily measure clicks. Measuring scrolls is harder—though not impossible. Marketing is happy counting clicks. This is why some news sources make you click to read more. They can measure each click, thinking they’ll have a better engagement number to tell their bosses and investors.

Problems with Paging

  • Users still have to scroll. Unlike early computers, page boundaries never line up with the viewport, so the user has to scroll by some amount to read the content, then press a button to see more, and so on.
  • Pagination controls vary widely in their form and function. Therefore, every user must learn their position and modes of interaction for every new site and app.
  • Having too many controls can be confusing. They don’t give users more actual choices, but add complexity, so discourage users from interacting at all.
  • Users perceive page loading as slow and burdensome. This can discourage interaction with pagination controls. Having to click something further limits users’ desire to view anything beyond the first page of content.
  • Users may not notice the pagination controls. They might assume that the content that is currently visible is all that is available.
  • Page loading tends to be slow. This is especially true when loading entire pages from scratch rather than refreshing only the content area. If users typically display multiple pages, it is much less efficient to load entire pages.
  • Multiple selection, or batch selection, has insurmountable issues. Users cannot tell whether selection applies per page or for the whole list of results. I have worked on solving this problem for 20 years and nothing has helped much.

Automatic Infinite Scroll

Before bound books with pages existed, there were scrolls. The natural way to get more content is just to read more content. Remember, people scroll.

Infinite scroll pretends to display all the content in a single list on a single page, but it’s faking this. It actually breaks the content into little chunks. Really, automatic infinite scroll is just paging with the automatic display of the next page of content, whose content it adds to the current page.

To avoid users’ perceiving any delay, any infinite-scroll system should prefetch the next most likely content users would see when scrolling. The amount of content it loads and prefetches must be calculated based on both the type of content and the expected—or observed—user behavior. Optimized prefetching can actually involve less data transfer than a paging system.

If the user scrolls too far or the network is slower than expected, a delay indicator may appear, as shown in Figure 3.

Figure 3—Infinite scroll loading indicator
Infinite scroll loading indicator

There has been a lot of badmouthing of infinite scroll, but these negative perceptions are all based on bad implementations. Losing the position of an item the user tapped or clicked when the user returns to an infinite scroll list is a result of bad design and coding choices, not an issue that is intrinsic to this pattern.

Benefits of Automatic Infinite Scroll

  • It provides entirely natural browsing of content. The user need only scroll.
  • Batch selection is clear to users. All selections are from a single list.
  • It provides the best possible performance. This is especially important for displaying large amounts of information
  • Mobile apps can support alternative scrolling functions. These include indexed fast user scrolling.

Problems with Automatic Infinite Scroll

  • It can result in unnatural, frustrating behaviors. These occur if automatic infinite scroll is not implemented correctly.
  • Its proper function adds implementation complexity. Automatic infinite scroll requires significant coordination between the presentation-layer code, APIs or Web services, and data storage.
  • You must design entire page templates to support infinite scroll. Otherwise, an implementation can prevent users from accessing the bottom of a page, slow access to the top of the page, and cause users to become disoriented.
  • Scroll-bar size and position reflect only what content has loaded. Since the scroll-bar size and position don’t reflect the length of the entire list, users may become confused about where they are in a list.

Manual Infinite Scroll

One simple change to infinite scroll can make a lot of things easier and alleviate a lot of the concerns product teams and developers have about it: making it manual. Manual infinite scroll simply removes the automatic function, making the user click or tap a button or link to load the next chunk of data, as shown in Figure 4.

Figure 4Show next 20 button
Show next 20 button

Although automatic infinite scroll usually works fine, it does take some effort to implement it correctly. Therefore, it has a bad reputation that is unfounded. Acknowledging this can help you persuade everyone on your project to get 90% of the way to a good design solution.

Because a button or link to load more content is so important to this function, you must design it well. The best solution on a mobile device seems to be for it to take up an entire row below the content or at the end of a list, clearly affording a tappable target.

For example, in a list view or table, this affordance might say something such as “Show next 20.” I prefer show instead of load or anything else because it’s a user-facing control. The system loads content so it can show that content to the user. These subtle wording distinctions help more than you might think.

This function should communicate exactly how many more items or rows will load, but make sure this is not hard coded to ensure it always provides an accurate value, not just the typical page size.

Benefits of Manual Infinite Scroll

  • Scrolling through content provides quite a natural browsing experience. The user can scroll through all available content on the page.
  • Batch selection is clear to users. All selections are from a single list.
  • It is conceptually similar to paging. Therefore, manual infinite scroll is an easy sale to database and software-development engineers.

Problems with Manual Infinite Scroll

  • The user must press a button to load content. Thus, manual infinite scroll is more labor intensive than automatic infinite scroll.
  • It can result in unnatural, frustrating behaviors. These occur if manual infinite scroll is not implemented correctly.
  • Its proper function adds implementation complexity. Manual infinite scroll requires significant coordination between the presentation-layer code, APIs or Web services, and data storage.
  • You must design entire page templates to support infinite scroll. Otherwise, an implementation can prevent users from accessing the bottom of a page, slow access to the top of the page, and cause users to become disoriented.
  • It does not work well with indexed scrolling functions. Such alternative scrolling functions are not supported adequately.

Floating Controls

A valid concern for many long pages, especially those with infinite scroll, is the disappearance of key content or functionality. What if scrolling makes the use lose context because the header is outside the viewport? What if a user doesn’t notice a button way down at the bottom of the page so doesn’t submit a form?

The answer isn’t shorter pages, but a floating masthead and chyron. These floating elements have a fixed position in the viewport, and the page content visible in the middle of the screen moves beneath them.

The masthead is at the top of the screen. It need not be just the branding and app name, but can extend to include page titles, tabs, and other information that is important to maintain context.

The chyron is a footer for an app or site. However, it should never include the normal elements of a traditional Web-site footer. A chyron should remain at the bottom of the viewport only if it provides status, buttons, or control functions. See Figure 5 for an example of a floating masthead and chyron in use.

Figure 5—Masthead and chyron floating above scrolling content
Masthead and chyron floating above scrolling content

Design Rather Than Just Choose Your Solution

So which solution is best? I really can’t tell you. Your app or Web site is not like any other. For example, Google has its own unique requirements, and studies of user behaviors on sales sites are not especially relevant to the design of other types of sites.

Always design a solution. Don’t just choose a solution from the two options the framework provides. While this article details the three key scrolling options, there are variations and other ways of designing them. Occasionally, variants such as side-to-side scrolling are appropriate. Plus, there may be entirely different solutions.

Don’t judge a solution just because you love or hate it personally. Look deeper and discover the best solution for a particular app or site. Work with your whole team to define requirements and understand constraints.

Do not assume that anything about technology constraints is true. Look harder. I recently worked on a control panel with a 1-bit, or black-and-white, screen. Everyone assumed it would have to be characters only and not scrollable, but as cheap as the screen was, it had a modern technology core and could both display graphics and scroll windows. So, even for that screen, we could make the design follow modern principles.

I have included some pragmatic issues in the lists of pros and cons for these solutions. You must also be aware of how others may perceive your design decisions and whether getting your best design option implemented might be an uphill battle. Always design the right solution for your organization, your users, and the context of the information or function you’re presenting. 

Resources

Ahuvia, Yogev. “Infinite Scroll: Let’s Get to the Bottom of This.” Smashing Magazine, May 3, 2013. Retrieved October 24, 2018.

Hoober, Steven, and Eric Berkman. “Scroll.” Designing Mobile Interfaces. Sebastopol, CA: O’Reilly, 2012. Retrieved October 24, 2018.

Hoober, Steven, and Eric Berkman. “Infinite List.” Designing Mobile Interfaces. Sebastopol, CA: O’Reilly, 2012. Retrieved October 24, 2018.

Holst, Christian. “Infinite Scrolling, Pagination, or Load More Buttons? Usability Findings in Ecommerce.” Smashing Magazine, March 1, 2016. Retrieved October 24, 2018.

Source link