Making pagination meaningful

Working with long lists of information over a network, like web email, can be problematic. Very long lists can have a huge performance hit on your servers, leaving the user tapping her fingers waiting on slow page loads, especially on “very thin” clients like mobile devices. To limit the server hit and improve response times, some systems paginate data, that is, break it up into a series of pages.

This works well since most lists can be sorted by smart defaults, and the first page is the one that users most likely want to pay attention to, anyway. In the web email example, you can sort lists of individual emails by date with newest on top, or threads by most recent activity, and be confident that users will find what they’re most often looking for quickly.

But if a user needs to hunt for something, she’s going to need access to other pages, and this article is about how those controls should look and behave.

First, do no harm

The best solution to pagination: Eliminate the need for it. Have such a great search function that browsing the list is rendered moot. A frequent email user — for the sake of simplicity, let's call her "Elaine" — can provide a few clues to what she’s looking for and get to that email quickly. Not hunting required.

The second best solution is also no solution, that is, avoid pagination by presenting the information as a single long list. Apple does this with its MobileMe email.

A single long list is conceptually simple and reduces the number of controls Elaine must understand and learn. To avoid the server hits implied by a long list, some tricky programming can load only the part of the page being looked at, plus a little of what’s just off screen, making it appear complete when it’s loaded as needed.

Second, reckon with reality

Not every development organization has the time or technology to implement phenomenal search and just-in-time scroll panes. Sometimes, pagination controls are unavoidable. Here’s a screen grab of the controls from Google’s Gmail interface.

And another from Microsoft’s web based Outlook.

These controls contain a number of elements.

• Prior-page control (the left-facing triangle or “Newer”)
• A “chunk” marker, that tells you what the control is about (“Page”)
• “You are here” marker (the “1” or “1-50”)
• A means to get to any arbitrary page in the list (the “1” is in a text entry box, Gmail lacks this)
• A sense of the size of the whole list, “of 8”
• A next-page control (the right-facing triangle, or “Older”)

Most of the items makes sense. Having the “next” and “prior” controls means easy navigation while browsing. Telling the user what they’re looking at and where they are helps with their confidence and wayfinding. But the use of numbers to indicate where you are in the list and the list size doesn’t make as much sense. Users have no idea on what page the item they’re looking for appears. If they had that kind of accuracy, they probably would be able to search instead of browse for it. How can we make these controls more meaningful? One way is to swap the numbers out for labels with more meaning.

By using time periods instead of numbers, Elaine can make more sense of the control. She can move to the page that represents her best guess of when she received the email she’s looking for.

One thing that this different type of pagination implies is that breaking the list into chunks shouldn’t happen per some arbitrarily-decided number. The controls should break the data at some meaningful mark, like a meaningful change in time, such as week or month. This requires some fancy algorithms server side, but it’s worth it to make Elaine’s browsing experience work.

While the time-based pages make sense if she’s thinking in terms of time, she might also be thinking in other terms. If she’s browsing for an email from her friend Robert, she might need to look and see whether he’s listed as “Bob” or “Bobby.” How to switch the control? Adding a dropdown would add to the clutter of the interface; it would also be pretty tough to label. A better solution would respect the current column sort of the page. If Elaine has sorted by name, then the pagination controls can automatically change to reflect this.

This same principle can work for any of the column sorts, even strange ones that we think people might not use that frequently, like size.

In the end, it's all about revealing information to Elaine, and helping her find things according to the ways in which she thinks about them. Revealing meaning in the labels moves the organization of information away from the implementation model, and toward her own mental model.

Filed under: Interaction design, Interaction Patterns

---

---

Comments

 

Post a comment

---