What should be considered when deciding between explicit vs implicit paging in a UI?

Question

When a list becomes very large, presenting it in a UI raises a design issue. Should the user get pages of items or should the user get a list control that pages items implicitly as it is scrolled?

In google search, paging of results is explicit. You get a set of results and hit a link to get the next set. On the iPhone the application names in the app store are implicitly paged. In that case scrolling causes them to load. The inbox in Outlook is implicitly paged, but the inbox in Outlook Web Access is explicitly paged.

What factors should be considered when when making this UI design decision?

Edit: The term very large is subject to some interpretation.
To give some structure consider these different cases:

Case A: The list: 1. May grow over time. 2. Has at least 2 Billion items.

Case B: The list: 1. May grow over time. 2. Has thousands of items.

I'd claim case A and B are qualitatively different, though I'm certainly open to being shown that I'm wrong.

Answer 1

Assuming the sky's the limit and you are not constrained by the native toolkit or framework under which you are working, there are several considerations:

• The distinction between "implicit" and "explicit" paging goes away if you recognize that "implicit" paging is the same as "explicit" paging where the maximum results per page is unlimited;
• Will your application support user preferences? If so then you should consider letting the user decide her preference. Give the option to choose the maximum number of results per page, with the option for unlimited results (aka "implicit" paging);
• Will your user typically need to search, sort and filter through the results? If so, then what you call "implicit" paging will probably be necessary, as sorting and filtering over a partially obscured result set is counter-intuitive;
• Assuming you are talking about web development, there are pre-made GUI controls out there that render grids. Some of them have the option to toggle between "paged" results and "non-paged" results
• Will your user be allowed to extract and repurpose the results in different formats? If so then unconstrained result sets are better.

Answer 2

There is also the issue that google is web based. With web based applications you're pushing the limits with anything more than a few thousand rows, probably less. A listbox may support more, but if you're rendering html like google you're going to blast most browsers to the dark side with more than a couple of thousand lines of response, most often a lot less is required.

So the technical limits are very real on web browsers. Sometimes large datasets work well in most browsers, but you get problems in others. And there's no single thing you can fix to make it work well in all browsers.

Answer 3

Here are some questions I'd consider:

From the perspective of the user, what's the value in having a list with hundreds or thousands of entries (or even tens of entries)?

How likely is the user to have to scroll (or page) through a large set of values vs. simply looking at the first part of the list?

Is there a natural ordering that makes it possible to put the "best" values early in the list?

Is the ordering something that should be controlled by user preferences (e.g. what sort key, etc.)?

Instead of hard-wiring the decision into the application, could this be exposed as a user choice/configuration? Could the user be allowed to decide (and the app remember!) which strategy to use, how many elements to display, etc.?

Answer 4

Can we say that explicit paging is basically implemented where both (1) bandwidth is limited and (2) no filtering/ordering/searching options are directly available? Outlook is the perfect example for that: the rich-client version doesn't care about explicit paging, and offers all the fancy options for filtering/ordering/searching data. The web version implements explicit paging, and does not have such options (at least do not implement them is the same straight way).

So explicit paging is a 'reduced/limited' version of data paging, where the implicit format is the original standard. If you can propose to your users the 'implicit' data paging format, go for it. Have a look at Excel sheets to get some ideas on how to allow data filtering/ordering/searching. You can even have a look at one of my posts, where I was definitely inspired by Excel to set up the standards for our own user interface.

EDIT:

following Steve Steiner's comment on my answer, I should add that explicit paging rarely complies with 'business-oriented' requests, where you want to have a look at last month's invoices or get the complete list of deliveries by ACME since last year, and finally export theses lists to Excel, Outlook or PDF file. In these situations, where requests need to be exhaustively answered, explicit paging can be a source of confusion or limits user's productivity.

Answer 5

There’s no usability advantage of paging over scrolling. Paging is an artifact of web interfaces that seek to minimize the amount of content sent out at once for technical reasons (e.g., network or server load, page load rates over dial-up). If you are not faced with such limitations, use scrolling.

Scrolling has the following advantages over paging:

• 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 it the page links are located, whether there’s a First or Last link).

• The number of items shown automatically adjusts 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 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 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.

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