There are 2 issues, which keep haunting me:

• The “N+1” problem with the first page repeating some but not all of the index.
• Using the “next page” is “page N” and “next page” after that is “N-1” till page 1.

I have reverse ordering. The design is that each blog page has a stable URL with N articles each, so let’s say 10: page 1 is 1..10, page 2 is 11..20, etc. up to page N that “fills” up to N articles so that the last page always has an overlap with the index.

It’s telling that even I get surprised when I click on the “Next Page” link on the index and end up on “Page 6” rather than “Page 1”.

Issue 1: Previous / Next Links

The other issue is the navigation links.

I went from this, which was problematic:
        ⇐ Previous Posts                Next Posts ⇒
to this, which IMHO has other issues:
        ⇐ Previous Page                Next Page ⇒

The problem with “previous/next post” is that it’s ambiguous: “previous” is implied to mean “page N-1” or “older in time”, and “next” would mean “page N+1” or “newer in time”. But because the pages are in reverse chronological order, the “next” link actually points to an older-in-time content and page N-1. That’s the reverse of what one would expect.

I think we can solve that conundrum by renaming the links to be more technically correct:
        ⇐ Newer Page                Older Page ⇒
        ⇐ Newer Post                        Older Post ⇒

That’s a small trivial change that I think that would be less ambiguous:

• Newer / Older only imply time-based ordering, not index-based ordering.
• We’re not implied what is a “previous” or a “next page” anymore.
• Navigation is “[page N+1] << Newer || current is page N || Older >> [page N-1]”.

⇒ Done. Implemented. Seems very nice.

Also added an “{{If.IsIndex}}” command in the template so that we can have “Newer Post” in the single blog full page vs “Newer Posts” in the index blog pages. This required adding a crude support for nested {{If}}...{{Endif}}.

Issue 2: The Index/Page Duplication

Let’s re-discuss the pagination issue.

The actual concerns are:

• The duplication of entries between the index and the “first” page.
• As pointed out in Rig4k's [2023-06-28] Pagination Issue, I sometimes re-inject old articles, so these “stable” pages are not actually so stable.

One point of view is that the desire to have “stable” page numbers is antagonistic to having static pages that “fill up” with reverse ordering.

If we discard the requirement for “stable” page numbers, everything can work easily:

• Let’s say we have N..1 articles, and 10 articles per page.
• Index has N..(N-9)
• Page 1 has (N-10)..(N-19).
• Page 2 has (N-20)..(N-29).
• etc
• Navigation is now in order Index > Page 1 > Page 2 > … Page M.

Yes, it does mean that as the blog grows, page 2, for example, contains entries that perpetually change. If users want permalinks, they should really use links to individual post pages rather than the numbered-index pages.

It’s telling that even I get surprised when I click on the “Next Page” link on the index and end up on “Page 6” rather than “Page 1”.

⇒ Done. Implemented. Turned out to be easier to implement than expected. Very satisfied with the result so far.

---