Compress tags page

Thanks Jeff!
prod-fidelity
Jack Jackson 12 months ago
parent 1aa8fd00b4
commit 4e1a6b1d36
  1. 4
      blog/content/posts/tags-in-archetype.md
  2. 2
      blog/layouts/_default/terms.html
  3. 2
      blog/layouts/partials/tag-summary.html

@ -28,7 +28,7 @@ Note that I had to put ` - {{ .Page.Title }}` on the _same_ line as the `{{rang
Honestly, I'm a little surprised that this works in the first place. I would have expected that fetching "_a list of all extant tags_" would require building the site, but I've confirmed that this template still works when no `public/` directory (the usual location of built output of a Hugo site) exists. Either the list of extant tags is stored as metadata somewhere (though a `grep -r` didn't find it), or Hugo quickly parses through all existing posts to gather a list of tags when creating a new post from an archetype[^3].
On the topic of tags, I have a couple of improvements I want to introduce:
* The [tags](https://blog.scubbo.org/tags/) page is pretty poorly-laid out, taking up a lot of space for the tag name and showing the preview of the blog posts under it. This means that, on my standard Macbook screen, you can just about see 3 posts'-worth of content (that is - a single tag) - not ideal! It'd be great to restructure this so that the tag name is much smaller, and only the titles of posts under it are shown (maybe with an option to hover to see preview), allowing more content to be readable from a single screenful.
* The [tags](https://blog.scubbo.org/tags/) page is pretty poorly-laid out, taking up a lot of space for the tag name and showing the preview of the blog posts under it. This means that, on my standard Macbook screen, you can just about see 3 posts'-worth of content (that is - a single tag) - not ideal! ~~It'd be great to restructure this so that the tag name is much smaller, and only the titles of posts under it are shown (maybe with an option to hover to see preview), allowing more content to be readable from a single screenful.~~ Done, as of 2023-05-17, thanks to my buddy Jeff the front-end wizard!
* It looks like you can [attach metadata](https://gohugo.io/content-management/taxonomies/) to tags, too - that might be good to do (and to show as a subtitle for the tag) to clarify what a particular tag encompasses (no, `#meta` is _not_ related to The Company Formally Known As Facebook!)
* I'd like to try messing with the ordering[^4] on that tags page, too. At a glance, it looks like it's sorting by "_most recent post within that tag_", which...I guess makes sense. My first thought was that ordering by "_number of posts in tag_" might make more sense (putting "larger" tags above smaller ones), but that might lead to discoverability problems if I write a bunch of posts under one tag and then it's harder to find later ones. Then again, later posts would presumably show up on the standard page anyway? Eh - that's Future-Jack's problem when he starts thinking about this problem (if, indeed, he ever does...)
* I haven't messed around with the RSS feed for my blog, yet, but it seems like subscribers might want to subscribe to only certain tags, or to exclude certain tags. I imagine it would be pretty easy to create feeds at build-time for any pre-defined criteria ([this article](https://benjamincongdon.me/blog/2020/01/14/Tips-for-Customizing-Hugo-RSS-Feeds/) describes how), but probably more difficult (probably impossible? Since the feed is created _at_ build-time) to create arbitrary filter-condition feeds at render-time. I guess a Good Enough solution would be to generate feeds for each tag, and allow readers to subscribe to any combination of them that they like.
@ -65,4 +65,4 @@ So far as I can tell, it's not possible to pipe _into_ `sort`, you have to have
[^1]: Disclaimer: computers will almost always introduce more problems than they solve. The only code that is guaranteed to lead not to lead to a net-increase of problems is [this](https://github.com/kelseyhightower/nocode).
[^2]: Confusingly, "Archetypes" do what you might naïvely expect "Templates" to do. Explicitly: Archetypes are ~~templates~~ prototypes from which new content are created, and Templates are ways to express code-like logic in a non-code context, or equivalently to provide an execution/extension point in non-code content that expresses "_execute some code, and insert the output here_". An example of a template is writing the following in a blog post (note that this is not legal template syntax!): "_If you're interested in learning more about this topic, check the following posts: `{{ getAllPostsWithTag "coolTopic" | .Title}}`_", to print the titles of all posts with tag `#coolTopic`.
[^3]: Which then raises the question - does it _always_ do this, or only when the archetype includes a template that requires it? File this under "_things I would be interested to know, but not interested **enough** to go find out for myself_"
[^4]: I _still_ instinctively use "_sequencing_" instead of "_ordering_" to describe "_establishing which elements precede which other elements_", even though the area of mathematics that deals with that is literally called [Order Theory](https://en.wikipedia.org/wiki/Order_theory). This habit arose from when I was working on two services in my previous job - one of which was responsible for selecting the order (sequence) for laying out the various means of acquisition of content, and the other which was responsible for submitting orders (attempts to purchase) for said content. I should try to break that habit, since "_order_" is the more-common term and is unambiguous except in that particular context.
[^4]: I _still_ instinctively use "_sequencing_" instead of "_ordering_" to describe "_establishing which elements precede which other elements_", even though the area of mathematics that deals with that is literally called [Order Theory](https://en.wikipedia.org/wiki/Order_theory). This habit arose from when I was working on two services in my previous job - one of which was responsible for selecting the order (sequence) for laying out the various means of acquisition of content, and the other which was responsible for submitting orders (attempts to purchase) for said content. I should try to break that habit, since "_order_" is the more-common term and is unambiguous except in that particular context.

@ -13,9 +13,11 @@
{{ $.Data.Singular | humanize }}: {{ $key }}
</a>
</h2>
<div style="display: flex; flex-direction: row; flex-wrap: wrap;">
{{ range $value.Pages }}
{{ partial "tag-summary.html" . }}
{{ end }}
</div>
{{ end }}
</section>
</div>

@ -2,7 +2,7 @@
I don't want to _fully_ override the "summary.html" partial that exists in the theme, in case it's used anywhere else -
but this different summary allows me to make the summaries of articles in the tags page a bit more compact.
*/}}
<div class="relative w-100 mb4 bg-white nested-copy-line-height">
<div class="relative w-30 mb4 bg-white nested-copy-line-height" style="margin-right: 5px; flex-grow:0;">
<div class="bg-white mb3 pa4 gray overflow-hidden">
<span class="f6 db">{{ humanize .Section }}</span>
<h1 class="f3 near-black">

Loading…
Cancel
Save