Clever Geek Handbook

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

When the list gets very large , presenting it in the UI causes a design problem. Should the user get a page of items, or should the user get a list control that the pages are implicitly as it scrolls?

In google search, search for results is explicit. You get a set of results and click the link to get the next set. On the iPhone, app names in the app store are implicitly dumped. In this case, scrolling makes them load. Outlook Inbox is implicitly unloaded, but Outlook Web Access Inbox is explicitly unloaded.

What factors should be considered when deciding on this user interface?

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

Case A: List: 1. May grow over time. 2. Has at least 2 billion items.

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

I would say that case A and B are qualitatively different, although I am of course open to showing that I am wrong.

+1


source to share


5 answers


Assuming the sky is limited, and you're not limited to the built-in toolbox or wireframe you're working under, there are a few considerations:



  • The distinction between "implicit" and "explicit" paging disappears when you accept that "implicit" paging is the same as "explicit" paging, where the maximum result is on the page ;
  • Will your application support custom settings ? If so, you should consider letting the user decide her preference. Give the opportunity to select the maximum number of results per page, with the possibility of an unlimited number of results (for example, "implicit" paging);
  • Will your user typically search , sort, and filter through the results? If so, then what you call "implicit" paging is likely to be required, since sorting and filtering on a partially hidden result set is counter intuitive;
  • Assuming you're talking about web development, there are ready-made GUI controls that generate grids. Some of them have the ability to toggle between the "unloaded" and "unloaded" results.
  • Will your user receive and display results in different formats ? If so, then unconditional result sets are better.
+4


source


Would you say that explicit paging is mostly implemented where (1) bandwidth is limited, and (2) filtering / ordering / search options are not available? Perspective is a perfect example: the rich-client version doesn't care about explicit paging and offers all the attractive options for filtering / ordering / finding data. The web version implements explicit paging and does not have such parameters (at least it does not implement them equally directly).

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



EDIT:

after Steve Steiner's comment on my answer, I must add that explicit paging rarely matches "business oriented" queries where you want to look at last month's invoices or get a full list of ACME shipments from last year, and finally export those lists to Excel, Outlook or PDF file. In these situations, where requests must be exhaustively resolved, explicit paging can become a source of confusion or limit user productivity.

+2


source


There is also a problem that Google is dealing with on the internet. With web apps, you are pushing limits for anything more than a few thousand lines, which is probably less. The list may support more, but if you are creating html like google you are going to hack most browsers to the dark side with more than a few thousand lines of response, often much less is required.

Thus, the technical limitations are very real in web browsers. Sometimes large datasets work well in most browsers, but you're having trouble with others. And there is not a single thing you can fix to make it work well in all browsers.

+1


source


Here are a few questions that I would like to address:

From a user perspective, what value does a list with hundreds or thousands of entries (or even tens of entries) have?

How likely is it that the user should scroll (or the page) through a large set of values, or just look at the first part of the list?

Is there a natural ordering that allows the "best" values ​​to be placed at the top of the list?

Is ordering something that needs to be controlled by user preferences (like what sort key, etc.)?

Instead of hard-wiring the solution in the app, can this show up as a user's choice / configuration? Can the user allow (and the app remember!) Which strategy to use, how many items to display, etc.?

+1


source


Lack of usability of paging over scrolling. Paging is an artifact of web interfaces that aims to minimize the amount of content sent immediately for technical reasons (for example, network or server load, page load speed over dial-up). If you do not face such restrictions, use scrolling.

Scrolling has the following advantages over paging:

  • The scrollbar control is standardized, so most users are already familiar with it. Paging is not standardized, so it takes over and learns to use it (for example, where the links to pages are, whether the link is "First" or "Last").

  • The number of items displayed is automatically adjusted by resizing the window, allowing users to optimize the number of items visible in one step and avoid scrolling and paging situations.

  • The scroll bar is available regardless of where the user is in the window. Paging interfaces usually provide links to pages only at the top and / or bottom of the page, which can scroll out of sight.

  • Users can move just one item at a time to show the items they want to see together. Paging breaks items into arbitrary groups, which can lead to pagination of items of interest.

  • Users can move anywhere in the list with a single drag and drop. Paging is limited to links to pages, typically limiting the user to move only around the nearest neighborhood.

  • Users can repeatedly select any set of items to perform actions on them (for example, copy, delete), and users can view any other item while maintaining the current selection. Paging usually only allows and supports selection of items on the current page.

  • Users can still move one page at a time by clicking the "track" of the scroll bar.

0


source






More articles:


All Articles