Pagination 101
gist.github.com
gist.github.com
Wait! Give them better names. "Older" and "Newer" can be helpful on blogs and such, when it's not clear whether "next" means "more recent" or "deeper into the archive."
Next page and previous page.
It is usually the default wording because when making a generic paging routine you don't know if things are going to be sorted ascending or descending, or if they are in date order, numeric order, alphabetic, in the order of the author's first pet's birth month, or something else entirely. Sometimes a framework has no option for changing the captions, and sometimes we as devs are lazy...
Where the ordering is obvious next/previous is fine, but as you say it is much better to be more precise about what you mean if at all possible.
Yes, I understand that it has its roots in print. But on a screen that isn't physically chronological it becomes more complicated.
> Sometimes a framework has no option for changing the captions, and sometimes we as devs are lazy...
I guess that's a good explanation :-)
Also, we occidentals seem to place "past" and "future" in left and right, which would match "older" and "newer" in location. But we're also used in the web that a link that goes "back" usually means "back from where I come from", which if you're reading the first page of posts doesn't make much sense.
EDIT: Grammar, because English is not my first language :)
How do you conclude that we occidentals seem to place "past" and "future" in left and right?
EDIT: also the design of browser fwd/back buttons or VCR and tape recorder buttons seem to honor this theory.
Where showing n elements per page, if the last page would have no more than ε elements in it, merge it with the previous page.
e.g. n = 10, ε = 2, so a data set of 21 elements might go over two pages of 10 and 11 elements rather than three of 10, 10 and 1.
Sure, SQL LIMIT queries and all that, but it’d tend to be nicer for the user.
You'd need to keep a count to do that and a lot of tables you'd bother to paginate, a COUNT() is way too expensive.
Okay so lets say you keep a cache of the COUNT().
What if you're off? Now you have confusing, irregular behavior that throws the user off.
Is this something you've tried in an actual application before?
Removing the hyperlink makes the numbers look like numbers. The user will have to "learn" that they can click the numbers.
Oh, and make them blue!
I agree with you, but I am just stating that at most, it only serves as purely aesthetics. You could replace underlines, with hover with a transition effect or animate on appearance (as going back or forwards), etc.
No, that misses the point. An underline has a very specific meaning. It is not just aesthetics. If put a handle on a door that you push to open, people will pull on the door on their first attempt. By doing this you've changed the meaning of a handle to all users of the building. Now, a user can no longer rely on the visual affordances provided by "door handle". They must navigate and interpret each and every interaction with a door in that building.
Removing an underline remove a very important part of what an hyperlink is. And I would argue that the colour of a hyperlink is just as important.
If you had never used a computer before, there is nothing discoverable about blue underlined words. They could be red italics and it would make absolutely no difference. A handle is shaped to make it possible to open a door. It has a discoverable purpose (some handles more than others).
If we decide that arbitrary UI representations should stay just because they were historically common, then we will never improve our user interfaces. I'm all for avoiding surprising the user, but saying that an underline has an intrinsic meaning for a hyper link is just wrong.
Putting aside the assumption that hyperlinks require improvement, you've mistakenly declared that certain visual attributes were chosen arbitrarily and therefor are fair game to change. But it is those very same attributes that provide the visual affordance required for users to determine the function they perform. That is, whilst the selection of those attributes, in the beginning, may have been arbitrary, they no longer are. Consistency in application is one of the best ways to pass on knowledge. Whilst blue underlined text doesn't have anything that intrinsically suggests its action, consistent application of that visual language builds up the affordance in the user: all blue underlined text is a hyperlink.
Look at it this way; at some point in the past someone decided that the highlight on GUI buttons should appear to come from the top-left of the screen. This was a completely arbitrary decision. However, with the rest of the GUI adopting the similar design decision, a cohesive impression is built up. It became obvious to users that this meant that a button was raised and could be clicked with the mouse cursor.
But if you design your GUI with the highlight coming from the bottom-right, no matter home much better you think this will improve the GUI and how much more sense it makes, your button will appear to be inset and selected. That is, whilst the selection of those attributes, in the beginning, may have been arbitrary, they no longer are.
And so it is with hyperlinks. Hyperlinks are underlined blue text because they are. Unless there is some radical, obvious improvement to be made, any changes to these attributes will be to the users detriment. Most often, these changes are attributed to improving integration with the web page design, introducing cohesiveness, but this is mistaking hyperlinks as elements of the design. They are not, they are UI elements and as such should sit outside the style of the web page.
With the politest of respect and IMHO of course :)
I'm in favor or innovation, even in user interfaces. Otherwise we'd not have automatic doors (which had remained unchanged for 2000 years) or windows that slide up and down. Or TV remotes.
When I'm trying to rip through pages to find something and I can't just sit there and click, instead I have to move my mouse around (so lazy over here), ugh, it drives me insane.
A huge amount of 'bugs' I run into as a front-ender are of this kind. For example, someone designs a nice three-column layout with title, subtitle, and text underneath each other. Each of these columns is fixed-height as well (usually a bad idea in general, but it looks very ugly otherwise).
This works fine in the design phase, where titles are written to fit the element, but once you start working with real data, you run into a problem: one title might be three lines high, while another is only a single line high. Since you want the 'columns' to be fixed height, you now have to add a lot of whitespace underneath the one-line title, so that everything lines up with the three-line title element.
Then you realize that you have the same problem with the subtitle and content, so now you end up with ridiculous amounts of whitespace between title, subtitle and body, depending on the length of the text within.
I've often tried to preemptively address these issues as a front-ender, but aside from this not really being my job (that's where the value of a UX designer comes in, I guess? Or at least a web-skilled designer), I can't always predict these kinds of things either.
So the best solution I've found is to always try to work with real data, or create enough 'random' fake data to fix these kinds of issues.
I built a simple data table component for a company I was interviewing with a while ago [1]. At first, I placed the pagination controls at the bottom because it felt like the natural thing to do, but later I discovered that the UX for navigating between pages with different number of items (or larger items spanning multiple lines) felt rather sub-par because of the variable height table making the pagination controls shift up and down from page to page. Moving the pagination controls to the top (fixed position) makes navigation feel completely effortless in comparison.
So instead, when showing items 1-10, the link for the next page of results should query for the next page full of items start after item 10.
That still lets the user miss added items (mostly unavoidable unless the list is sorted by "things the user hasn't seen yet"), but doesn't miss items when deleting seen items.
http://use-the-index-luke.com/sql/partial-results/fetch-next...
Took me a while to understand that "Next" works differently and is somewhat misplaced after "10".
Same for Start and End, really, if you adopt the 'show the last page or two' approach, so this is possibly better:
[1] [2] 3 [4] [5] ... [19] [20]
Also, you're forgetting about the fact the bottom of the page forms a boundary. If you're pagination is at the bottom of the page it is consistently the same distance from the bottom after you scroll all the way down.
If you have a mousewheel you can take advantage of this on Google. After you click next the first time, leave your cursor in the same position and use the mousewheel to scroll as you scan the results. Once you hit the bottom, the cursor is over the next link and you can just click.
Even if the user isn't advanced enough to use a mousewheel, they can still become familiar with the position of the next link relative to bottom left of the page.
This way you can instantly jump to the price range you are interested in.
http://blog.waleson.com/2011/03/design-pattern-pagination-wi...
I think no one does this because SQL syntax just gives you COUNT and LIMIT primitives so those become the terms that developers think in.
Also remember to use class="current" (or some such) and rel="next" and rel="prev".
The user is likely to be better off with sub-category filters (tents, sleeping bags, etc) or a nice, fat search box with auto-complete.
My pet peeve with pagination is when the default items-per-page is something pitiful like 10 when it could be 50-100. NameCheap did this for a long time when listing your products in the Control Panel - it was agonising!
This is particularly key when using a small tablet or phone. On many sites it is difficult to hit the right thing without zooming first and many of the sites I find "broken" in this way also somehow disable zoom. In these circumstances I'm more likely to go look for the same information elsewhere than persevere.
Page 1. Next 20>> Next 40>> Next 80>>
I.e. you can request larger pages right from pagination block if you think you need them. (And on that page you will be able to downsize page or make it even larger)
But I have to admit, load-on-scrolling does make it more or less obsolete.
As lolptdr wrote - if infinite scroll implemented in a way that changes URL of the page with PushState and loads data correctly after refresh then it's just fine.
Nevertheless, any time I can I implement traditional pagination. It is easier to use and shows clearly where user is located, can allow user to jump straight to the last page.
But for something like Tumblr or Pinterest, it's awful. When the user sees an interesting post, she clicks on it to open the page. Then she navigates back to the main page. But wait -- the infinite scroll's contents have been lost on reload. Now the page shows the top of the scroll, rather than the position where the user actually was when she clicked a link. It may be a long, long way to scroll back to where she was, with numerous loading progress indicators along the way...
If you aiming for performance, it depends on how much data you need to request and if you can shunt or lazy load the data.
TLDR it depends.
If it's infinite scroll, you either have to manually mess around with the URL (best case scenario) or just scroll through everything again (common worst case scenario).
This is also while you should probably (at least in my opinion) have some form of page number, as well as a clear and somewhat quick to modify URL scheme (like page/10 instead of date=01/01/1990&before_date=01/02/1992&cat=test&session=123456789 etc).
Good scroll implementation uses lazy-loading content (if needed) and placeholder elements to keep page height always correct (assuming the height is reasonable), so that scrollbar works as intented as visual indicator about position. So called "infinite scrolling" where you have to first scroll to end, then wait for spinner for more content, is typically bad ux.