A Sad Tale of Pagination

I imagine some professional chefs are accused of over-analyzing a bowl of soup now and then. Like that, as a user experience designer, I get caught up in little pieces of user interface on a regular basis.

This particular story concerns a navigation system that utilizes pagination in what at first seems an obvious choice, but upon observation it is clear that this is a very poor approach.

Background: Company setting

Covenant Eyes, Inc., is an  8 year old software company in Michigan with about 50 employees. About a dozen are customer service representatives, some for enterprise customers and some for individual or family accounts. There are about 10 in the IT team, which includes myself.

Background: What service does our company provide? Internet accountability.

Take 2 actors, George and his friend Paul. George is addicted to online porn, but he really wants to beat his addiction because he feels it is wrong and could really mess up his life. To attack his problem, George installs our software on his computer. The software keeps tabs on George’s activity, and once a week sends a report of that activity over to Paul. Paul can then talk with George about George’s Internet activity. It seems simple, but removing the anonymity of his addiction is powerful.

The point, in a nutshell, is accountability. If George is trying to kick some bad online habits, his friend Paul now has information in these reports that he can use to hold George accountable.

The current design calls for pagination

These Accountability Reports are like executive summaries that include links over to what we call the “Detailed Logs.” This log is a full list of URLs that George visited.

Depending on the amount of activity, the log may have thousands of entries for Paul to navigate.

When these logs first became available, customers’ download speeds were more of an issue than they are today, so the developers knew that they could not simply put all the entries on a single page because the pages would take far too long to load.

Pagination to the rescue! The developers broke up the long list of URLs into pages, each page having 50 URLs. To help Paul navigate this long series of pages, numbered page links and “Previous” and “Next” links were placed at the top and bottom of each page.

So, let’s say Paul is looking at page 50. He would see something like the pagination navigation shown in Figure 1.

Figure 1: Pagination

Figure 1: Pagination

This seems a good approach on two fronts.

  1. Paul won’t wait to download one page with over 8,000 URLs on it, but if we divide that time into, in this case, 165 separate downloads, each page will seem pretty quick.
  2. Pagination will work for Paul because he uses pagination on nearly every search engine results page. It’s nothing new to him.

Bingo. Problem solved. Right?

But why does it take so many clicks to find the right info?

I was standing next to Mike, one of our Customer Service Representatives, and asked him a seemingly simple question. “Mike, can you bring up that log and show me what was going on last Tuesday at 11:32 AM?”

I did not intend it to be a usability test, but it might as well have been. Mike helps people every day by walking them through reports and logs, so he is as expert as anyone gets at navigating these logs. Yet, the basic task of finding a page with a specific time on it was accomplished by a series of guesses, each slightly more informed than the previous guess. It took 8 tries before Mike got us to the right page.

Since then, I have seen people repeatedly click the “Next” button, flipping through each page to find the one page they want. With 165 or so pages in a log, this can take far more than 8 clicks.

If someone knows the date and time they want to view in a Detailed Log, shouldn’t they be able to get to that page without guessing on the first try?

20/20 hindsight: Why is it so hard to find the right page?

Pagination is a valid interface design pattern, and is perhaps most often seen on search engine result pages. Still, it does not work well here.

So, why doesn’t pagination work here? Thinking in information architecture terms can help answer the question.

Pagination is a metaphor from the print world

We’ve all grown up reading books and magazines, and so page numbers are a tool we take for granted. In print, they are used to keep track of where we left off so we can pick back up at the right point. They are also used as non-digital hypertext, like in a magazine where we see “continued on page 58.”

On the web, pagination has become something slightly different, but the metaphor carries over well enough to work for us. On search results pages, we now expect to see a pagination interface at the bottom of the search results to allow us to continue to the next page of 10 or 20 links. One difference on the web is that we expect those links on the first page to have higher relevancy than those on the following pages.

So, on the web pagination is an answer to a finding question, and is based on an underlying organizational system of quantity ordered by relevancy.

However, in this case, the list is ordered by time but paginated by quantity. In this case, people want to find by time, but quantity is not metered evenly against time. So, page 1 might have 50 entries that cover 5 seconds of activity, and page 2 might have 50 entries that cover 32 hours of activity. There is no predictability of how much time will be represented from page to page of results, and that is why people are left with so much guess-work.

Match the interface to the underlying information architecture and users’ information needs

In recent work, we’ve shifted to a time-based pagination (Figure 2) from a quantity-based pagination (Figure 1). We think this will go a long way towards helping people find what they want without having to guess.

Figure 2. Find-by-time instead of pagination.

Figure 2. Find-by-time instead of pagination.

I’ve observed a few users have their first contact with this revised interface, and it has worked well so far. We may have introduced other usability issues in the process, but this is a step in the right direction.

Moral of the story?

Before implementing a user interface design pattern, be sure you first understand the information architecture and users’ information needs. Otherwise you risk using the wrong pattern, hurting your users’ experiences, and missing out on an opportunity for innovation and good design.

What does it take to be an evangelist of good interface design?

Reference: The Art of Evangelism, Guy Kawasaki

Here are Kawasaki’s list of ten ways of looking at evangelism and my interpretation of them as someone who might be an evangelist within an organization for good interface design.

1. Create a cause.

We need to do good interface design on our products, because it makes life better for our customers. And for our sake, our customers judge us by the interfaces we provide them.

The interface is *the* medium that customers use to interact with our products. As such, the interface in turn becomes the application.

A product with great SQL queries and OOP architecture but a bad user interface is like a computer with a smoking processor and 2 GB of super fast memory, but the keyboard randomly enters the wrong character and the display is 10 inches, monotone, and at the wrong height.

Given a great application behind the scenes, if the interface sucks, then the application also sucks. If the interface rocks, then the application also rocks.

2. Love the cause.

I love good design. I study it. I notice and share good design when I run across it. Badly designed applications are caustic to me; they make me sick (seriously) and give me motivation to see them made right.

I hear talk of interface design and usability, sometimes synonymously. To avoid confusion, let’s put usability in its place–usability is not the end of design, it is one requirement of a great design. Usability is roughly defined as how easy it is to use a product. Design covers visceral, behavioral, and reflective aspects of a design, and usability is a piece only of behavioral design. (Refer to “Emotional Design,” by Donald Norman.)

3. Look for agnostics, ignore athiests.

Who can argue with good design; who are those athiests? Well, for one, they may be developers who see the true value of an application within the actual programming of the application. There is undeniable value there, but it is virtually invisble to customers. For another, there are some usability nuts who firmly believe that the best a design can be is usable. They’ve sold the product short, dismally so. For evidence, I point to the usable, but fairly ugly useit.com, Jakob Nielsen’s website.

To get people within an organization to hop onto the “we need to do good interface design” bandwagon, look for those people who haven’t really known what to think of it yet, who are open-minded. As the culture shifts, the rest will come along (cross your fingers).

4. Localize the pain.

Bad interface design results in painful things. Namely, too many support requests; frustrated customers on the phone; disenchanted end-users, who, incidentally, do not praise your product to their peers; customers who jump-ship to the competition because the grass looks greener.

There is also subtle pain for developers, I believe, and that is the lack of an ability to truly believe that they have contributed to the best application of its kind in the world. How confident are the developers in their apps? Are they rightly proud of the accumulation of their work?

5. Let people test drive the cause.

Believers have an experience. For good design, one way to provide that good experience to people in the organization is to have them look at before and afters of designs that once looked like their own work, to designs that could resemble their future work. Let them imagine, based on concrete examples.

One example could be the Paypal before/after by 37signals.

6. Learn to give a demo.

One great type of demo for use in production teams is to run sample user-tests with the development team. The test user should not be of the team, but could be someone else in the organization who isn’t as familiar with the product. The developers should play a role in the test, as observers. By taking part in a user-test, developers can begin to actually see how a design process can directly feed into the work they do.

7. Provide a safe first step.

Small, easy changes across an interface can turn into disproportionalely large rewards. Identify those short term, quick wins and take them. Savor them as evidence that the cause is indeed worthy.

8. Ignore pedigrees.

Evangelizing good interface design within an organization needs to happen at all levels. It is a value-shift of the people who work within the organization, and it will happen over time as a community. There must be top-level support, but we’re after belief and conviction, not compliance.

9. Never tell a lie.

One of the beauties of interface design is that it is a continual quest for the truth of an application. As an interface designer, there are some aspects of a design that I’ll feel comfortable tackling on the spot, because of my experience with other similar interfaces. However, there are so many variables, I have no trouble saying, “I don’t know how to handle this one. Let’s figure out a test scenario for ideas.”

10. Remember your friends.

We’re part of a commmunity that crosses our own boundaries of roles. We are not just developers and members of the organization, we’re also the end-users. Our family members, neighbors, and friends might be the users at some time. Part of the value of interface design is humility. What I think as a designer/developer does not match what our users think. Thus, good interface design hinges on an honoring of others and the ability to listen and see what is really going on, not just what we think is going on.