Most software has to list things. Recipes, used cars, invoices, customers, whatever you’re modeling, you usually end up providing a list of the things.
And over time, the number of these things will grow. If you’re building an invoicing application, it’s a reasonable expectation that the number of invoices will grow arbitrarily.
Eventually, there will be far too many invoices to simply list out.
By far, the most common solution to this design challenge is pagination. When it becomes impractical to list every invoice, list the first N, and give the user some indication of how many pages you’ve broken it into.
You can’t easily fit 100 line items on a page, but you can show 10 pages of 10. Problem solved.
Wait, what’s the problem?
Well, sort of. I mean, it’s been solved, but it’s an imaginary problem.
The problem isn’t that you can’t show 100 items at once. The problem is that you’re trying to show 100 items at once.
The most useful thing to do is never to show 100 of anything. If you aren’t building an actual database table browser, this is never the thing your users want.
When you choose to paginate a list, you’re essentially saying “The set I’ve given the user to work with is too large to work with. I’d better break it up.”
They don’t want to be shown 100 things, they want to be shown the correct things. There aren’t 100 correct things. There are probably less than 10.
If you feel like it will be a common case that users are expected to comprehend 50, 100, or 1,000 data items, you’ve made other UI mistakes that got you there.
Everything in moderation.
Pagination isn’t in itself a disease. There are probably even legitimate uses, like the case of bulk operations. It’s not something to be avoided wholesale, but it looks pretty lazy when it’s the workhorse of a segment of your app.
Think of it as a UX smell, A symptom that perhaps working with this section of the UI has become unwieldy.
Perhaps you’ve not thought through the common operations on these models. Maybe you’re exposing too much of your underlying database structure to your users like virtually every CRM product ever?
Consider things generally regarded as elegant and useful (like Basecamp), and look at effectively they show you the items you want to work with.
Next time you’re building something, and you’re considering showing 500 receipt images, examine why you’re about to offer to your users a list you know they’ll never consume.
There are plenty of situations where showing 100 items or more is essential and showing any fewer would be a problem. Perhaps you haven’t thought through the possibilities before espousing your opinion that others are lazy.
If you read the first sentence of your comment out loud, it should sound silly to you.
So Google has a UX problem then ?
Suspect you should rethink this post, merely because you think you should never show 100 items, i suspect you have not dealt with big ammounts of data.
The choices should be there to filter the data, but even after filtering and again filtering, you will still often have trouble to go from 5000, down to your ideal of whatever …maybe 10 items
John, I see where you’re coming from, but it’s a place you’d be doing your users a favor to outgrow.
I worked for years with US consumer behavior & demographic data with attached buying history. Most software engineers will go their entire careers and never work with data sets of that size.
As far as Google, I don’t think you’re helping your case upholding them as a shining example of great UI.
Like I said, there are instances where it’s useful, but it’s a stupid and lazy goto for the vast majority of apps. I’d say you’re first problem is you’ve got people “filtering again and again”
To Tim’s point, while Google may not be the most ideal example of UI, their user experience goal is to present the user with the correct information on the first page. Though they do provide paging in search, they spend millions spinning up whole new product lines (plus, autocomplete) to make that first set of 10 or less results all that a user will ever need.
Any time you ask a user to make a meaningful decision on a list of data, the majority of which that user can’t see because it’s hidden behind page 10 or 50, you’ve failed to understand root question that user is trying to answer. Paging can be an indicator of the quantity of a list of things, but beyond that, you can’t expect your user to be able to actually use it to understand the data.
That’s not to say that you can’t present a user with large data sets. The key word is “present” as it has to be with a visualization a user can readily consume. It’s actually ok to require a user to drill in to a large set of data to get access to details, but each level of granularity should be navigating through levels of meaning about the data instead of navigating across the same data set like with paging.
All that said paging makes sense in some cases, but really only when used in the context which it derived it’s name, reading stories. If you intend the user to read the information like a book, in the sorted context of linear story, then paging, in some well delivered implementation of the thing, works great.
- SK