A case against pagers
Rant warning -. Paging seems such a common interface element on many websites. I personally have some issues with them, as I feel they serve to solve a technical problem, and not so much a usability problem. In fact, I would argue that a pager works against usability.
The number one means to properly organize large amounts of content in any desktop application is fortunately built right in to your browser. In fact, you might see one right now on the far right of this screen, it's a scrollbar!
The biggest reason against pagers, is that I can not utilize Option-F or Apple-F when I quickly want to search through a big table of information. I'd actually need to either rely on the Web Application to provide a search option, or manually have to scroll through the pages to find what I want. Besides that scrolling functionality is built straight into my mouse and I don't have to look & click for a pager.
So I would argue that Pagers mostly solve a technical issue. It is unacceptable to download large amounts of data in a browser. This would increase bandwidth (cost! speed!). It makes me wonder if there are better ways possible to present this.
Worse!
A lot of high profile news sites even utilize pagers within their articles. We're really just talking about textual content here.
I have a fair idea where these pagers stem from, which is actually another point of annoyance for myself: the outdated perception ad value directly relates to page-views.
Conclusively
I've needed them quite a bit myself, especially since we're doing a lot with media and galleries which are notoriously heavy. If it's not because of the bandwidth, I've definitely seen a huge amount of images slow my browser down quite a bit. The lesser, the better though.
Comments
Ian •
From my understanding, the aformentioned 'media' sites do actually get more revenue from page views.Regardless, they do get more coverage. Split an article over 3 pages and all of a sudden the one article is distributing 3 times more ads.
It makes sense from a marketing perspective but really sucks for users.
It seems like it's a necessary evil. For us as users to get 'free' content, we need to suffer through systems such as this so their authors can get paid.
Matthew Weier O'Phinney •
Many JS toolkits provide functionality similar to what you describe as more ideal, and similar to what Micah indicates via grid components. Dojo's grid component allows you to load a set number of rows at a time so that as the user scrolls, the grid gradually populates itself -- ultimately allowing unlimited resultsets served over a number of smaller calls to the server. It would be trivial to tie such a grid to a search input and bind this to a keystroke -- thus allowing the user to narrow and refine their results, as well as scroll through all of them.Pagination serves two fundamental issues: keeping page sizes smaller (which will result in both a faster page load as well as smaller browser memory footprint), and allowing additional page impressions for purposes of ad impressions. A JS-based result grid solves the first issue, while still enabling better usability. For those situations where ad impressions are a factor, however, you're going to continue seeing pagers.
Bertie •
Meh, who cares. Pagers I can deal with. Just please don't let anyone use this as an excuse to use that GODAWFUL Ajax crap.At least paging lets you do such simple things as, ooh, y'know, *bookmark* pages - which used to be taken for granted - and use your 'back' button - the simplest, most-effective Web useability feature ever...all of which the Ajax bandwagon kiddies seem to have thrown out with the bathwater.
Keep it simple.
p.s. Guess what, you get paging on sites that don't even carry ads, so there may be more to it that you're aware of.
Evert •
Bertie,Although I absolutely agree with you when we're talking about websites distributing content, about 50% of my time I spend on application-type stuff.
For these types of apps I have been thinking about experimenting with some of the upcoming offline storage api's (providing a fallback at the same time.)
I would never really attempt heavy javascript for public content-based sites, such as this blog. There's actually a pager way on the bottom of the homepage; although I'm 99% sure those are only ever used by search robots.
MagicalTux •
I also believe sometimes it's better to have pages. For example when I read the SVN Book, the "single page" version is 1.4MB of HTML ; opening it *will* kill my browser after taking a lot of ram.Sometimes when you have a lot of data, paging is interesting.
For news, reviews, etc, paging is usually not necessary, just a waste of bandwidth and user interaction... (and a way to artificially increase pages hits)
Evert •
magicaltux, I definitely agree.. I do still think its solving a technical problem though.Neil Garb •
I don't think any generalized statements can be made about the usability of pagers. Matthew's referring in a general sense to griddable data, and I agree that an AJAX system would work well in that instance because the whole resultset is important to the user. In another context, perhaps on Google, I think an AJAX loader is less meaningful because only the first few results may be relevant. I share Bertie's aversion to AJAX -- I think JS is painfully underpowered and clunky -- and I'd prefer not to see it anywhere near my Google searches.siep •
The idea pagers were designed to help people pinpoint an item in a large set of items, would be worth a little digging here & there. I think of them more as a comprehensive way of browsing contents.As long as the items per page doesn't change, pagers are the same as scrollbars, you have to scroll all out of the page to see the same amount of new items.
A good pager has the "next" button in exactly the same spot, regardless of page refresh or ajax.
If you're specifically after more items per page, think about using zoomlevels (both text and font).
@bertie while on the bandwagon, you can code the javascript to bookmark a page's JS parameters for later use.
Traditional 'page refresh pagers' have bookmark bugs when /page/1 is always the most recent content.
The Argh •
As Neil and Magical Tux mentioned already, pagers do make sense in some cases. If your data can be displayed without a pager without killing the user's browser it is a good idea - given you also have the processing power to do so.Pages do not only exist to split up large amounts of data, sometimes they are simply a performance tradeoff on the server side. Especially in the case of dynamic data, even if you use aggressive caching, a lot of pageviews will kill a lot of server availability that you may need for other things.
Ideally I would love a grid display like most media players (or email clients for that matter) offer today, where you have all your songs/emails in one big list. A search field that dynamically reduces the list by keywords is even better than Option+F imo. That way you don't have to skip from one item to the next, the list is reduced to what is relevant.
For example, the Mozilla Thunderbird mail client has such a search field, where typing "php" will reduce the list to only those emails whose subject contains that keyword. You can also specify which part of the email to apply the search to.
Of course that means javascript/AJAX again, but from a user point of view it's definitely worth looking into.
Evert •
"I don't think any generalized statements can be made about the usability of pagers"point taken
Siep •
Evert, have a look here:http://humanized.com/weblog/2006/04/25/no_more_more_pages/
(looks promising, too bad the page is currently down but i'm curious to see what they've come up with)