Posts series in HUGO

A general problem when there’s a series of related posts is that the blog becomes saturated with these posts, all similar and related. If the eventual or hypothetical reader isn’t interested in that particular topic, they don’t see anything else that induces them to keep reading.

The example of this is the series of the FT101 component list: all the articles in this list are similar to each other.

Even for readers interested in the topic, it’s tedious and unattractive to present a summary that has ten articles all the same, all consecutive.

Presentation

A possible solution is to present only one representative article, the “index” of the series, and make this the access point to it. However, this presents the problem that if the series is expanded with more articles, or any of the series articles is edited/updated, it wouldn’t be visible, since the summary doesn’t present individual articles from the series.

With these ideas I implemented the current system: the series is presented as a single post that is shown in its chronologically corresponding place both in the summary and in category views (HUGO taxonomies…), tags, etc. This “post” is special, it represents the series header, it’s the access point to it. This solves the “pollution” aspect or summary hijacking when there are many consecutive and similar articles.

To solve the problem of how to present the series when it’s somehow updated, by editing or adding an article, the “date:” field of the header article is updated: this “floats” that article to a newer place and shows the relevant info with a ⚡NEW decoration.

I find this solution not exactly elegant but somewhat cleaner.

Index

The index is a post with a “series_role” prop in Front Matter that is used for the series title and as an index. This is the post whose date will be updated when something changes in the series.

This latter is done automatically using git hooks. I’ll probably talk more about this later.

Navigation

I initially put the navigation partial in the header of each article. It takes up too much space. For now, the solution is a widget in the sidebar, which only appears when the article is part of a series. I’m not dissatisfied with this mechanism.

It has one drawback I haven’t resolved yet, which is that the sidebar isn’t fixed, so if the article is long, which is frequent, you have to go back up to navigate.

We’ll see.

Future

I’m going to leave it for a while to see what experience I have and what ideas it produces, but it needs adjustment. A possible improvement is to put the new series article in place of the index, but this doesn’t work for an old edited article, so I have to solve that.

I plan to implement another git hook to automatically translate new articles with some LLM agent. We’ll see what happens.

Conclusion

I hope these changes improve the UX. At least implementing all this has helped me better understand the framework and underlying technology, and to appreciate the intelligence and elegance behind Hugo ↗️.