The dominant UI pattern for pagination involves a list of numbers.
<< First < Prev 1... 4 5 6 7 8 9 10 ...27 Next > Last >>
sometimes including a "+10" link, and/or a "jump to" numeric text field.
Some elements of this pattern seem "fishy" to me:
- The most common action (Next) is buried between two links, which both link to the same (last) page
- Previous and Next, which seem to be related by mode (exploring without a specific target) are far apart
- Similarly, First and Last are far apart, though they also seem related via the common prior act of resorting (e.g. I want the oldest record, so I'll sort chronologically, and then go to the first or last page, depending on whether ascending or descending is the default sort ordering)
- There is a strong affordance for jumping 2 or 3 pages in either direction, though I'd be surprised if this wasn't really an edge case. Is it really that much more common than jumping 5 or 10 forward or back, or jumping to a particular page?
My first question is:
Is there any user research supporting the dominant UI pattern? Are all the elements equally necessary for effective navigation of paginated tables?
The question becomes critical on a mobile browsing context, given that prevailing touch interface guidelines recommend a minimum of at least 26px (at 164ppi) - though Apple recommends at least 44px.
Getting that pagination pattern to conform to those interface guidelines takes up a lot of screen real estate.
So, the second question is:
Which part of this pattern can be safely jettisoned, in favour of bigger touch targets? Can, for example, we safely abandoned the list of numbers in favour of including a user-driven "Go to page" menu listing all page numbers?
The wireframe below is one possible alternative pattern which avoids the fishiness above, and has 40x40 px targets.