Every few years I sit down and look over Kenneth.Dyerhouse.com and wonder what little things I might change to improve it's usage, especially in terms of making it easier to use so that I'll use it more often. Sometimes this involves basic maintenance, sometimes this involves a more aggressive rebuild.
Last rebuild involved a shift from Sphinx to a custom Python and XSLT-based processing solution, where a Git repository of XML files would be read, pre-processed in Python, and then fed into an XSLT stylesheet to produce static HTML. It was intimately tied to a similar application that would output temporary LaTeX files and then post-process the results to generate PDF's. This tied the workflow for web content to the workflow I used for fiction writing and conlanging.
It sorta worked, and sorta didn't work.
The biggest problem with the XSLT system was that I kept breaking it on the fiction and conlanging side. It didn't quite do what I needed there, so every so often I would shift over and take it apart. If the dismemberment involved even a slight glance away from XML as a source format, I would stop writing and focus entirely on the tool rebuild.
So, periodically over the past year, the system that generated this site was in so many pieces that it was impossible to facilitate a rebuild.
Ideally, I would follow certain deployment principles in software development and keep a build of the app that is in a known good state to continue to work from, but the needs on the writing side were such that dramatic changes were the only that made sense.
Frustration with this process over the past few months has shifted my preferred format for creative writing from XML to straight LaTeX. The difficulties in writing straight LaTeX wobbled me to flirt with Markdown and reStructuredText for a bit, even briefly with going back to Sphinx.
What I settled on was LaTeX-based source files managed by Emacs Org, with
Evil enabled by default and a very conservative
init.el to keep
the usual Emacs bugginess off my radar.
This is not the best solution. In a perfect world, there would be a NeoVim implementation of Org, or a very basic implementation with a set of processing scripts to better handle the rest.
No, that's not true. In a perfect world, I'd manage a new implementation of Docutils to use as a base in building new tools for myself, but given the offspring, who has time for that now.
LaTeX is not a format that lends itself well to the Single Source philosophy. I can't dual publish my conlang dictionaries in HTML and PDF under the current implementation. But, I'd still like to manage a website.
In a past incarnation, this site used the Nikola static site generator. It struck me as pragmatic tooling and upon review, I realized it could actually streamline the publishing process, making it very easy to update the site and rsync the changes to the server.
The following features are currently under consideration:
I'd like to spellcheck content before it goes up to the server. My fingers trip over themselves sometimes and every now and then I muddle my work in editing and it's always embarrassing to find later.
There's a plugin for this but it didn't work well in testing, so I'll need to review how it works and either make it happen or implement my own solution.
I'll go on the record as saying I don't quite get Twitter. I get that people like it and I see the value in working with social media, but it's not a platform I'm comfortable sitting on and shooting off random thoughts.
Plan for Twitter in re this site is to set up a task that will post updates to Twitter. Specifically new blog posts, but it would be nice if it could also send microblog posts as though they were tweets.
That would give the content a higher profile and maybe pull in some traffic without requiring me to spend time to learn all the nuances of a new platform.
I am not altogether comfortable with the seeming invasiveness of Google Analytics, but it would be useful to have some data on readership. At the very least who's visiting, where they're coming from, and how they're using the site.
I've worked under a UX in the past and can see the value in using such metrics to clock who's interested and what they're interested in and that may be useful when the time comes to talk to publishers about getting my creative work into print.
Before bringing this new build live, I plan to import content from the old build of the site, converting it to a format appropriate to Nikola. I don't have dates on record for any of these pages, so they're all being reset to dates in 2019 to ensure that they clearly show as older work.
The current site theme is BNW. I would like to rebuild the theme, in particular to have a better introduction on the home page and some sidebar action.