... and by this, I mean "this blog." I think I can make this blog work. I mean that both in a personal sense (I'm going to write again) and in a technical sense (I'm probably not going to break it).
For my first post in two years, I figure I should write about why I almost gave up on running a static site, and why I decided to stick with it.
But first a little anecdote.
A few years ago, a small organization was having problems securing their self-hosted wordpress blog. The manager of IT had an idea: they would move to a static site. IT set up the new site and began the process of porting over all the existing blog posts.1 Somewhere along the way, they told the rest of the staff what they were doing. It was not a great development for blog post authors.
The new site had a GUI for authoring, which put it ahead of many static site user interfaces, but there wasn't much in the way of an accounts system. Previously, each author could compose their post in wordpress, submit it for editorial review, and have it published, all from the blog interface. Now the process would be: write a document in a text editor or word processor and send it to the editor, who was tasked with manually entering the content into the static site.
Within a month or two, the organization decided to revert to running wordpress.2
I bring this up not to tell a story about organizational dysfunction (or not just for that reason) but for the perhaps less interesting point about static sites and authoring interfaces. The static blog frameworks I've looked at have not been great for authoring. I almost went back to wordpress earlier this year.
If you're reading this, and you're a static convert, you might be thinking "why not use markdown? markdown is great! many static sites support markdown, what's the problem?" I don't entirely disagree, I've gotten very used to writing notes in markdown. But markdown isn't the entire story.
For blog posts, I'd like to have a bit more WYSIWIG/GUI when I'm including images or file attachments, rather than feeling like I'm just guessing where to put my files and how to format the paths to them, just to get working links at the end of the process. "Just markdown" works great only for a limited range of post genres. Image and media management is the main reason I considered returning to wordpress.
My other problem has been themes. I started my static site on Octopress, which I thought looked pretty good out of the box. I liked it enough that I stuck with the theme when I switched over to my current static framework, Pelican.3 But I found customizing that theme an unrewarding struggle, and after changing some colors I basically gave up. I can't say I enjoy having to install a compiler just to update some CSS.
The theme sounds like a small thing, but it left me feeling like I wasn't really "running" my own site, I was just getting by. At least my wordpress install was managed by my hosting provider, and the wordpress themes I've used have had some amount of customization built into the wordpress GUI.
By the time I bought a new desktop computer last year, I'd basically given up on this site. I didn't even bother going through the setup process to be able to publish from the new machine until I wrote this post. I figured I shouldn't write anything until I decided whether to migrate back to wordpress. I kept putting of that decision.
So why have I decided to stick it out in static land? I looked at the current state of wordpress and got so overwhelmed that I remembered why I went to a static site in the first place: I don't actually need many publishing features. I just want to put up some web pages in an organized way that is readable and persistent. I can deal with the image management problem.
As for themes, I'm trying to embrace the DIY approach. A few weeks ago, I went through all the Pelican themes and chose one of the few responsive ones that I felt I could live with, just as a stopgap to free my blog from Octopress. No more sass compiler or javascript of questionable worth. And the site looked … ok out of the box, I guess.
Very few Pelican themes appear to be maintained, which I usually take as a bad sign. But in this case it felt like a license to treat my new theme as a tear down and start adding my own styles, as there's apparently no reason to worry about incorporating updates. So I pulled out the old bootstrap stylesheet (from 2015?), deleted a bunch of classes I would never use ("jumbotron", "marketing"), and added just enough CSS to feel like I knew I could keep making it better.
Yes, the blog looks a bit off-center (it is, I'll eventually fix that). Yes, I will be adjusting some of the colors. Yes, I probably need to tweak font size and line spacing. Yes, the theme has two files named styles.css and I have no idea why because only one seems to have an effect on anything. And yes, the page templates use a lot of divs where people would use semantic tags today, and I need to sort out which classes to keep and which to remove.
But I can read my blog with my nearsighted eyes without too much extra zoom, the posts and pages resize to fit a tablet or phone, and when I edit the CSS or html templates, I can see that my changes have an immediate effect. It feels like it's my blog again.
-
A story for another day, but this process also led to mangling the formatting on posts in ways that reflected poorly on the organization, and incidentally on the authors themselves, who were not told what was happening until after their posts were mangled. ↩
-
The authoring workflow wasn't the only reason. See the above note about mangling post formatting during the migration. And other reasons not included in this telling of the story. ↩
-
I switched because updating Octopress turned out to be more difficult than it looked, especially in terms of retaining customization. Pelican seemed lighter weight and easier to maintain, with a clearer separation between blog publishing and the theme. At a development level, Octopress now seems abandoned, while Pelican appears to be actively maintained. ↩