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
This seems a good approach on two fronts.
- 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.
- 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.
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.
