Another addition to tags-in-taxonomy entry

Jack Jackson 11 months ago
parent 1916b6b6dc
commit f6a2015997
  1. 1

@ -31,6 +31,7 @@ On the topic of tags, I have a couple of improvements I want to introduce:
* The [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.
* It looks like you can [attach metadata]( 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]( 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.
* It seems like the "related" sidebar only ever shows previous content - [this post]( shows the two preceding posts under the tag, but [this one]( doesn't show any. That's both puzzling (the full list of "_posts that exist under a given tag_" must be available at _some_ point in the build process, and it's not like running a second iteration over all blog posts will massively affect runtime efficiency of the process) and counter-intuitive (a reader who is linked to the first blog post in a series would want to be able to easily find a link to the next one without clicking out to the tag page or the author explicitly adding the link in the body). This _should_ be pretty simple to solve by using a [Taxonomy Template](, but I'd be more curious to find out why this wasn't implemented the _complete_ way to begin with.