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."
Honestly, I don't know where "Next" and "Previous" idiocy stems from, but Older and Newer is what I've used too. Now that I think of it, perhaps I should write Greasemonkey script to try to replace next and previous where applicable.
> I don't know where "Next" and "Previous" idiocy stems from
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.
"Older" and "Newer" don't really seem to work that well with blogs. Usually the default page has the post sorted by most recent (top) to least recent (bottom). When you reach the bottom of the page, the post you have is not the most recent. Now, what do "Older" and "Newer" mean in this context? Because, "newer" than the post I'm currently at are too the posts that are above it. It introduces a tiny moment of hesitation trying to decipher which link takes me to "the next page of posts".
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 :)
If you're on a blog, for example, what is on page 1? The very first post ever, or the very latest post? The numbers don't help unless you know what the numbers mean.
If I was paging through 10 items at a time, and noticed that there were 10 pages, I'd assume there was only 91-100 items and if I knew there was actual 103 I'd be more likely to think the site was broken than to look at the bottom of the last page of results for them.
count(*) is a linear time operation (roughly to the size of the table) on postgres. It does an index-only scan but with a sufficiently large table/index it's still a problem. It's to do with postgres MVCC implementation. I don't know if other SQL databases have this problem. MySQL doesn't seem to.
Absolutely disagree with number 2; if the numbers are hyperlinks to other pages they should be underlined. The underline on links informs the user that it is a link to another page (i.e. they will be navigating away from the current page), that the interface is page based, that clicking the link will add the current page to the history and that their back button will work, etc, etc.
Removing the hyperlink makes the numbers look like numbers. The user will have to "learn" that they can click the numbers.
It's a visual design issue really, and not just purely usability light the rest. By now, most people are aware of how paginations work.
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.
"..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.
But an underline is arbitrary. Similarly the colour blue is arbitrary. You only think that it makes sense because that's what is currently common.
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.
"If we decide that arbitrary UI representations should stay just because they were historically common, then we will never improve our user interfaces."
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 :)
Any 'detriment' will be temporary. We all play games with novel controls, and are willing to learn that. Why not a new browser? In fact, something new could get a cult following, if its actually even a little better in any way.
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.
This is a good example of how important it is to work with actual data, representative dummy data, or at least to try and simulate these things. When pagination is built, the fixed-width page number links are often based on a single integer, which of course breaks down once you get more content.
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.
Exactly, that's why a good UX pattern is to disable the buttons that do not apply to the current state, not hide them. This helps discoverability (the button is always there) and predictability (the button is always on the same place)
One pagination that I really don't enjoy using is GitHub's "Newer" and "Older" links when you're viewing the commit log. Luckly, the URI has a `page=` parameter and I'm able to put in some arbitrary numeric strings to try and guess which would be the last page. Because I like to see the first commit of really mature projects when I'm just browsing sometimes.
One other key: don't identify current position by index, because then you'll miss or duplicate items when the list changes. If you show 1-10, then a change in the background adds 5.5 between 5 and 6, the next page will show 10-19. Worse, if a change in the background deletes 5, the next page will show 12-21, missing 11.
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.
Years ago, I never used "Next" in Google's search results, because I thought it would bring me to page 11. The next page after 10, because 1..10 were clearly lined out.
Took me a while to understand that "Next" works differently and is somewhat misplaced after "10".
I think the need for "Previous" and "Next" is overstated. Unless your pagination is pixel-consistent from page to page (and at the top of the page), it's going to be fiddly to repeatedly press anyway, and that's the only real benefit. Normally, if you're scanning the pagination links, you'll reach the next page by number way before you reach the "Next" link (obviously, that's not the case with Previous, though!).
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]
You can then omit a whole class of concerns and just concentrate on the few remaining elements relating to the page numbers themselves.
People don't scan linearly; they recognise the pagination controls as a block. It's much quicker to jump to the end of the pagination block to find the "next" link than to scan through all of the numbers to find the current page and then find the next page.
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.
I built something cool for a client a couple of years ago. When sorting on price (or title, or anything), it shows you the price range (or title..) in that page ($100 - $350) on mouse hover in a tooltip. Surprisingly it's not something I've ever seen anywhere else.
This way you can instantly jump to the price range you are interested in.
I remember a comment once that pagination could be a sign that you need to provide better filtering or search options. Not so relevant for online comics, but consider a store where you're in the Camping section and there are 800 results.
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!
Pagination is an often overlooked aspect of search engine optimization. Imagine you have a pagination like "<prev 1 ... 23 24 _25_ 26 27 ... 100 next>". As you can only reach the two pages next to the current page the 50th page is 25 hops away from the first page. The depth of the paginated pages would be in O(n) with a pagination like this. A pagination wich offers a better crawlability would not only link to pages in the direct proximity but to pages further away: "<prev 1 ... 10 ... 24 _25_ 26 ... 50 ... 100 next>". In this way you may bring the depth of your paginated pages into O(log n).
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.
I had this innovative idea for working with datasets - show pagination like this:
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.
Given most of the infinite scroll implementations - better use traditional pagination.
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.
Infinite scroll is usually terrible with browser navigation. If you can assume that the user stays within your page and doesn't need to navigate back and forth, it may be a reasonable option.
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...
And what about the scrollbar going haywire as you scroll down, or the inability to go back to that fancy thing you found a minute ago, or the browser performance hit, or just anything else related to it.
Depends. If you intend to show results that could be referenced by a hard link that the user may share (such as search results or blog entries), then pagination is better. Transactions (like bank statements) or lists of lots of similar looking data are better suited for infinite scroll.
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.
Recently implemented pagination for the skeleton of a large meteor/angular application that will target both mobile and web. I'll likely split it and have infinite scrolling on the mobile interface and keep the current pagination on the web version. Fortunately Meteor makes this rather easy.
As someone who's often struggled to find a piece of content because the only link to it was about ten pages down a list that you can only add more items to via infinite scroll... I'd say pagination is usually the better options. At least with pagination, you can think 'okay, then it's page 10 that has the article I want'. You can then just click on page number 10.
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).
Pagination on screen sucks, but is sometimes better than badly implemented scrolling. This being said, scrolling should be the default option, because it's much more natural and usable on screen. One should only fallback for pagination for very big content masses (long historical archive etc) and still keep the page size big enough (scrolling inside page is not bad thing).
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.
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."