People write blog posts. And when you have written a lot of blog posts, there comes a time when it becomes necessary to divide the posts into smaller collections of posts. One way to do this is pagination.
Pagination divides a list of items into a few pages. Each page has an URI, contains a few items and links to other pages in the list.
There are many places where this method is used. Two examples are search result pages and blogs. Search result pages can contain many, many results, sometimes as much as a few million. Showing all the result is a waste of space and bandwidth, as most people won’t even look past the first page.
For blogs this is a little bit different. The posts are in a reverse chronological order, thus starting with the latest post. Sometimes the last ten posts are shown on the same page, sometimes only one post.
A big difference between these two examples is that in search engines, the list is ephemeral. This list doesn’t need to be the same every time you look at it. Some results move up and some results move down. Search engines shouldn’t even index them, as there is no value in those pages for them.
Blogs on the other hand have a lot of value in the older posts. These posts are useful for search engines and all have permanent URIs. But that isn’t always the way people find them. Sometimes a person finds an archive page with more items, that contains the post. The problem with this is that the posts move deeper and deeper into later pages, because the blog orders the posts from new to old.
For example, a blog with ten posts.
| Page 1 |
| 10, 9, 8, 7, 6, 5, 4, 3, 2, 1 |
When the author now writes a new post, all the posts move one position to the right.
| Page 1 | Page 2 |
| 11, 10, 9, 8, 7, 6, 5, 4, 3, 2 | 1 |
The first post was on page 1, but now moves to the second page. A search engine or user that thought the post was on page 1, now has to find it again, because the URI has changed. If the author writes even more posts, these posts move as well.
The historical solution
The solution that I describe above was used for a long time, and probably still is, because (1) it’s easy to implement and fits the way the pages are generated and (2) because each page, except for the last contains the maximum number of items for a page.
A program that generates the pages for a blog, has a reversed list of all the posts that are on the blog. It loops through the list from the first to the last, starting a new page whenever it has shown some number of posts, for example, ten. The program writes the footer of the last page when there are no more posts left to show.
Other solutions
A better solution takes the moving post problem into account. To solve the problem, we should find another way to divide the list of posts into different pages.
A way to divide the pages is by grouping the post by a value that doesn’t change, for example, the combination of the year and month of the creation date of the post. You could create a list of pages for each month of posts. This depends on the number of posts written, because you don’t want more than about ten or twenty posts on one page.
A third solution would be to create the pages from the first to the last. This way a post always stays on the same page, because its index in the list doesn’t change. The problem with this solution is that the homepage contains, nine out of ten times, less items than the other pages.
The fourth solution only works on a dynamically generated blog. The other three solutions all work for a statically generated blog. Twitter uses this solution, which I’ll call the More solution.
First we show a list of the first ten items of the blog. At the end of the list e show a link or button with the text More. Clicking this link loads the next ten items from the list of posts. This works because the More button has the timestamp, or id of the last item in the list and clicking loads the next ten posts that have an id or timestamp smaller than the current last post.
When a search engine finds these links, it creates more search results than in a model where each post can only be added to one page. In this model each post can be on as much as ten pages on any given time, depending on how often a search engine (or user) finds a link to such a page.
Conclusion
Each solution works best in a different situation. I prefer blogs that use the year-month approach for splitting up the pages, because the posts are split in a natural way.
In a searchengine however, or on other ephemeral pages, the More approach is better. Because most people don’t want to go deeper into the results, but if they want, they can use the More button.