Building Mythos by hand is already proving to be a major pain. Writing a single entry is fine, but then I have to update all the other entries to reflect the one. There aren't many right now, but if Mythos is to become what I want it to be, it will soon become unmaintainable by hand.

I could, of course, come up with a still-manual solution that reduces effort on my end – like only ever showing the entries of any given caterogy when the user is on that category's "side of things", so to say – but that's would be bullshit solution. I didn't spend a month refining the site just to slide into complacency. This either works well or is not present online.

Such a circumstance pushes me that much harder to find or come up with a solution to automate the HTML production process. Like with any static site generator, I want the process to be dead-simple: I write the data, and an autonomous system/server agent converts it to the HTML you'd eventually see online.

The tool should one of those that enable its users, in a way that proliferates whatever it is they're doing: in my case, maintaining and expanding a static website. There aren't many of those around. Most tools allow you to do more without rendering the process any easier. Human brain can only reliably process so much data because judgement starts to collapse.

This raises another issue I want to shine the light on over at Mythos... but right now, it would take a lot more energy than I can afford it.

Theoretically, some of the more basic static site generators ought to do the trick. I'm not doing anything bleeding-edge or experimental with the site yet: all its contents ought to convert nicely from Markdown. Have to give it a shot: worst case scenario, I'm where I was (rather than set back), and some lessons have been learned.

These logs have proven to be a somewhat contentious among users already: not because of their contents, but because they're outrageously long by default (this is me writing), and the pages that host them are also outrageously long as a result. Some of the early visitors suggested pagination or a similar content drawering, which I agree with.

I've initially modelled the logs on Indigrid's progress reports because it was the only model that corresponded with the goal. As always, real-world usage provides the developer with feedback: models are never the items themselves.

What I'm thinking of at the moment is separating logs by the weeks to which they belong if the longs are information-intensive, like this one. (This entry, for example, would belong to "July 6—12, 2020".) Slower entries could instead be separated into monthly or yearly drawers: intensity of approach should correspond with intensity of the task.

Collapsible sections (based on the heading) is also an option, for the majority of the users who have JS enabled in their browser. I know not everyone does that, and I want as many a user to feel comfortable using this site as possible. JS-based enhancements are always meant to be progressive in this instance, in that they only apply to those who can afford them and disappear quietly and seamlessly for those who can't.

I'm also considering hiding production logs somewhere, so that the general user needn't be confused by them. Production logs are not meant to be general-audience-accessible: these are professional notes for those who has the expertise to understand them. They're there to share the insight, in hopes that it may help those in a similar position. Such an insight is sorely lacking in many areas of expertise. I may not be an expert, but I am solving problems – and someone else might need this or that idea to solve the problems they are facing.

I wanted initially to hide the site's prodlog completely, as an easter egg of sorts for others to find. It isn't "main information" – not for general audience, who may be here for the stories or the games – so I thought it wouldn't fit into the rest of the content. In the end, I'd decided to publish it along other pages because discoverability is a bitch sometimes, and I'd rather some users be put off by this wall of text than the users that may need it not find it.

It may be a good idea to separate "main information" from "specialist information" in the navigation sidebar visually: two spaced-apart lists where you could tell which is which based on the context of the list as a whole.

One task I can't yet get my hands on is the favicon: the website's icon that you see on the browser's tab or in your browser's history and bookmarks. It's not necessary to have one – as is currently evident – but it feels rather barren to have my site stand out in this negative yet baseline fashion. I have an idea for what the icon ought to look like, but it may be a while until I get to making it.

Added sticky positioning for timed lists' time detail (the date-time designator on the left). Works well on desktop, but on mobile, last items of every list are being covered by the time detail. Another one of those "doesn't hurt, but doesn't look good, either" issues. Not sure how to fix it yet. Perhaps keeping headings/time details sticky on mobile is not that good of an idea.