Technical Goals for this Project

Or: In Favor Starting Projects in the Wrong Place

I try not to be overly careful about starting projects in the “right” place. Here’s my pitch for doing the same:

Starting where you are most interested makes you more likely to start at all. This provides the motivation to get you over a project’s activation energy. For your personal projects in particular, motivation to just start the thing is more important that having a careful roadmap. The same applies in a workplace context to get a new initiative over organizational inertia.

Most projects aren’t carpentry; there’s nothing wrong with cutting twice. In fact, a lot is gained in the process of doing something wrong first, then changing your approach once issues come to light. I’m more inclined to live by the truism “Premature optimization is the root of all evil.” 1

You learn much more about the big picture from doing the detail work than the other way around. This is true for the way my mind works, anyway. I’m better at planning once I’ve gotten a good feel for what I’ll be working with and what purposes it could realistically be applied to.

There’s a lot of issues with this approach too, don’t get me wrong. I have a lot of orphaned projects, possibly because I burn through the parts I’m most interested in and then get bogged down.

Still, I’m going to start this bog where I’m currently most interested: technical infrastructure that will host it!

Epiphyte

Photo credit @ Kit

“Must Have” Specs

  1. I’d like the website, articles included, to be hosted as static files rather than through any kind of CMS. This will let me maintain the whole site very cheaply and not need to worry about dealing with any spikes in traffic, particularly if it’s hosted somewhere like firebase (or GitHub Pages). Fully-rendered pages too – no front end frameworks.
  2. I definitely don’t want to have to faff about handcoding articles in HTML or markdown or anything like that. I want a full featured WYSIWYG editor that lets me compose posts and then generates the static files.
  3. I need to be able to embed rich javascript widgets / small apps into articles. I’m not sure what I’m going to be writing about yet, but whatever it is is likely to be fairly leveraged up on tech. I want to be able to do things like embed customizable cellular automata in a post, dynamic prompts into an NLP system, or forms directly into a post. I’m unclear how this would interact with the WYSIWYG.
  4. A framework that gives me mobile responsiveness out of the box, including the site header, but also covers the content of articles themselves. Ideally the framework will have a variety of existing themes I can use or raid for parts.
  5. I want to be able to check the whole site, including written articles, into version control and store it on GitHub. I think this naturally comes from the above considerations, but I wanted to note it here.

“Could Have” Specs

  1. A natural way to divide the blog, by topic, under different domains/subdomains without require visitors to navigate by topic. I’m not sure what I want to write about, but there’s a fair chance it’ll include a wide range of topics like history, tech, RPG settings, etc. It would be nice to be able to link to people only to the view of the blog that are relevant in a given context. 2
  2. I’d like first class support for snarky post subtitles.
  3. I would like an easy to use footnote UI, both for composing posts and viewing them. I should do some research on best practices here – I know several older sites where their slick JS footnoting system broke, making the footnotes inaccessible.
  4. A way to generate graphs & tables according to a style guide and color palette from raw data.

Other Notes

  1. I don’t want to have commenting out of the gate, since the modal outcome is this doesn’t get much traffic. A discussion with threads with no (or worst, one) comment are pretty depressing. That’s something that could be added if this got any traction.
  2. Based on very preliminary results, I think building something on Publii might be my friend here. But hacking my own system always feels appealing too.
  3. Clearly, I wrote this post before I’ll be publishing it to the blog that isn’t implemented yet. I reserve the right to edit it before posting it if something I wrote seems stupid in retrospect.

  1. As is the case for all famous quotes, this one is more complicated than the way it’s commonly used. I enjoyed this contrary take on how to apply this quote. Amusingly enough, it is the Google “featured snippet” for the phrase. Maybe some google engineers have strong opinions on the topic? ↩︎

  2. I think there’s SEO consequences of doing this, something I’ve always avoided learning about. ↩︎