As an Internet user, I generally find pagination just as annoying as everyone else here (and paginated slide shows deserve a special ring of hell just for them).
BUT, from a web design perspective, there are actually some good reasons behind text pagination, the main three being:
1) It helps you keep your place -- you can bookmark one of the 15 pages to continue reading from later on, or forward to your friend ("check out the third paragraph" instead of "84th paragraph"). Obviously, you'd never show a 100,000-word article on one page (except for printing). At some point, pagination is necessary. Where to draw the line is obviously depends on a multitude of factors.
2) Feeling like you're "in" the site, not in no-man's land. From a web design perspective, you always want people to be able to navigate easily to other parts of the site -- you want stuff in the sidebar, never be too far away from header/footer, etc. You don't want people to be in a narrow column of text, with total white on both sides and nothing else. (Obviously users might often prefer this, like I do, hence Instapaper etc., but other users also like to be able to skip around to the rest of the site easily once they decide this particular article isn't for them, etc.) Of course, "floating" sidebars, headers, etc. can help alleviate this, but this requires the sidebars to be very small, which is not always possible.
3) "Chunking" large pieces of content is just a good thing. A huge wall of text is just no good from a usability or legibility standpoint. This, of course, is why articles are broken down into sentences, paragraphs, sections, parts, etc., so people "know where they are". Now I'll be the first to admit that paging is a particularly inelegant sledgehammer way of chunking, but when you're dealing with lots of articles of different lengths, formats, etc., it's a kind of lowest-common-denominator that is seen as better than nothing.
I don't think the current way most sites handle pagination is really that good, and it's a particularly bizarre combination to have pages that are longer than the viewing area, so you have to scroll and have to page. But given the way browsers are put together, it's a solution that basically works, given all the design constraints.
As a final note, I also think sites which don't provide any single-page or print option at all, also deserve a special place in hell. :)
#1 can be solved with URL hash / fragments, which link to anchors within the page. If the user has JavaScript enabled you can even automatically update the fragment as they scroll.
This doesn't make much sense to me. I don't think it has anything to do with design at all.
If you really believed in 1, 2 & 3 then why start off saying you hate it too? And you think everyone else hates it too?
The reasons you give seem like building for the edge cases instead of the main use cases.
Also if this were the case they'd have ajaxified these articles long, long ago so it doesn't require a full page load to paginate to improve retention.
We all know why it's done, it's for more ad impressions.
>If you really believed in 1, 2 & 3 then why start off saying you hate it too? And you think everyone else hates it too?
Saying s/he hates it doesn't make the other points wrong (I actually agree with them). The dislike for pagination might come from waiting for the page to load. It doesn't feel nice to see the whole page flash and wait for it to load again. It's a poor experience. If loading the next page is as quick as it is on Amazon's cloud reader, maybe people wouldn't hate pagination as much.
> 1) It helps you keep your place -- you can bookmark one of the 15 pages to continue reading from later on, or forward to your friend ("check out the third paragraph" instead of "84th paragraph"). Obviously, you'd never show a 100,000-word article on one page (except for printing). At some point, pagination is necessary. Where to draw the line is obviously depends on a multitude of factors.
Put permalinks next to sections headings and/or change the fragment in the url bar with javascript as the user scrolls. Links work, and no need for pagination
>2) Feeling like you're "in" the site, not in no-man's land. From a web design perspective, you always want people to be able to navigate easily to other parts of the site -- you want stuff in the sidebar, never be too far away from header/footer, etc. You don't want people to be in a narrow column of text, with total white on both sides and nothing else. (Obviously users might often prefer this, like I do, hence Instapaper etc., but other users also like to be able to skip around to the rest of the site easily once they decide this particular article isn't for them, etc.) Of course, "floating" sidebars, headers, etc. can help alleviate this, but this requires the sidebars to be very small, which is not always possible.
Use position: fixed (as you mention).Having submenus that expand on click alleviates the space constraints. You can also swap out content in your header or sidebar as the user scrolls (but please use tranitions, or you'll give everyone eyestrain).
> 3) "Chunking" large pieces of content is just a good thing. A huge wall of text is just no good from a usability or legibility standpoint. This, of course, is why articles are broken down into sentences, paragraphs, sections, parts, etc., so people "know where they are". Now I'll be the first to admit that paging is a particularly inelegant sledgehammer way of chunking, but when you're dealing with lots of articles of different lengths, formats, etc., it's a kind of lowest-common-denominator that is seen as better than nothing
I don't disagree with any of this, just that it's all a lot of work and isn't always necessarily more desirable.
A lot of users don't understand section permalinks, fragments. Position: fixed severely constrains your design possibilities, and swapping out content just involves a lot more design and programming. And section headings are great, but getting your CMS to implement a mini-table-of-contents at the top/bottom of each page may involve a lot of programming too, and changing editorial processes, etc.
That's why I called pagination a kind of lowest-common-denominator solution that isn't great, but works. Clever programming can come up with better solutions in many cases, but they can be a much bigger pain in the butt to implement well, and there are often much more important priorities.
Taking existing websites and just getting rid of pagination isn't necessarily always an improvement.
>you want stuff in the sidebar, never be too far away from header/footer, etc.
I hate to be contrary, but no, I really don't want anything in the sidebar, at least when it comes to a piece of text that requires a certain amount of concentration to consume. That's why it's actually easier to read something from, say, the new york review of books in a physical form then it is from the website; there's just too much potential distraction, full stop, while the physical page tends to be more focused, more clean, for whatever reason.
BUT, from a web design perspective, there are actually some good reasons behind text pagination, the main three being:
1) It helps you keep your place -- you can bookmark one of the 15 pages to continue reading from later on, or forward to your friend ("check out the third paragraph" instead of "84th paragraph"). Obviously, you'd never show a 100,000-word article on one page (except for printing). At some point, pagination is necessary. Where to draw the line is obviously depends on a multitude of factors.
2) Feeling like you're "in" the site, not in no-man's land. From a web design perspective, you always want people to be able to navigate easily to other parts of the site -- you want stuff in the sidebar, never be too far away from header/footer, etc. You don't want people to be in a narrow column of text, with total white on both sides and nothing else. (Obviously users might often prefer this, like I do, hence Instapaper etc., but other users also like to be able to skip around to the rest of the site easily once they decide this particular article isn't for them, etc.) Of course, "floating" sidebars, headers, etc. can help alleviate this, but this requires the sidebars to be very small, which is not always possible.
3) "Chunking" large pieces of content is just a good thing. A huge wall of text is just no good from a usability or legibility standpoint. This, of course, is why articles are broken down into sentences, paragraphs, sections, parts, etc., so people "know where they are". Now I'll be the first to admit that paging is a particularly inelegant sledgehammer way of chunking, but when you're dealing with lots of articles of different lengths, formats, etc., it's a kind of lowest-common-denominator that is seen as better than nothing.
I don't think the current way most sites handle pagination is really that good, and it's a particularly bizarre combination to have pages that are longer than the viewing area, so you have to scroll and have to page. But given the way browsers are put together, it's a solution that basically works, given all the design constraints.
As a final note, I also think sites which don't provide any single-page or print option at all, also deserve a special place in hell. :)