Designing this site: future-friendliness and robustness

This particular website is small, but I believe the principles that it is based on are far larger. As a part of my design process for this website, I am undertaking small but serious preparations to make it more future-friendly and future-proof, in the spirit of universality and independent publishing.

Write semantic HTML and Markdown

HTML as a long-term bet

Plain-text Markdown alongside HTML seems like a good long-term solution for encoding my content. Some impressively prescient folks have weighed in on the “long-term” nature of HTML:

I’m going to make a bold prediction. Long after you and I are gone, HTML will still be around. Not just in billions of archived pages from our era, but as a living, breathing entity. Too much effort, energy, and investment has gone into developing the web’s tools, protocols, and platforms for it to be abandoned lightly, if indeed at all.
So HTML is not the best format, but it may just be the longest lasting format, because of its ubiquity, because it’s taken off so much at this point.

Keep in mind, these are the same people who, respectively, laid the groundwork for responsive web design years before it was established and have been promoting long-term thinking for quite a few years – that is, forward thinkers. Data formats are fragile. But HTML, as data formats go, is robust and future-oriented.

Markdown balances ease of use with future-friendliness

Markdown was originally specified as as a minimalist tool for the web writer. It is not strictly suited to publishing like richer tools for processing text or even HTML. With only a subset of HTML’s elements, it is missing the semantic features of HTML. However, I have found that despite its limitations, it is my favorite piece of my publishing process for this site.

This dispatch started as a plain-text file with a .md extension, which metamorphoses into HTML. Markdown is comprised of plain text that can be read and edited by anyone, which is processed to become HTML. It is not complete as a markup language. Its strengths are that it is simple, and that it is entwined with HTML. The semantic gaps not covered by Markdown (<figure>, <cite>, <time> and so on) are covered by simply writing HTML. Even blocks of HTML specific to my site, like <aside class="ancillary">, can be written as blocks of HTML, alongside Markdown.

I never would have been convinced about Markdown if not for such forward and backward compatibility with a subset of HTML. Any failings that Markdown has as a language affect a publishing process minimally, since the language plays nicely with HTML. I see in Markdown future-friendliness and robustness approaching that of HTML. It helps that a lot of people and services rely on it and will probably be making Markdown-to-HTML converters for many years to come.

Fundamentally, Markdown is plain text enhanced with semantic properties and a straightforward and readable syntax, and it should be sticking around for a while.

Plan for portable hosting

By using Jekyll, my site is inherently easy to transfer to another host. The server only needs to be able to serve plain HTML and linked resources. There is no significant dependency on the server, such as PHP or server-side JavaScript. Although Jekyll can be set up many ways, my initial setup is one that has a proven balance between reliability and cost at this scale: Amazon S3. It costs a few dollars a month for me, at most, currently, and performance is solid. Deploying takes a matter of seconds using s3_website, a service that uses Amazon’s API to upload files.

I don’t much care for Amazon (I can’t trust that any large company will continue to share my ethical standards over the coming years), but for right now, S3 is cheap and easy enough for me to configure. I also have no need to like Amazon, since it is not my content’s “home”. Rather it is merely a conduit for distribution. If I hosted (and crucially, published) with other services such as GitHub Pages, Tumblr, SquareSpace, WordPress, I would tie the fate of my site (and maybe even aspects of my content, presentation and process) to the fortunes of larger businesses. Even if a company survives and thrives, there is always the possibility that I may outgrow its capabilities or sour on its services.

One example is Flickr, the photo sharing site. I posted hundreds of photos to it from 2010 to 2012, and I was a paying customer. Although Flickr is not likely going away tomorrow, their focus shifted to providing a “free” service (that is, ad supported) that could compete with newer services like Instagram. It has mostly outlived its usefulness for me, with poor interface choices, a diminished community, and a parent company that clearly does not care for its future. If I had relied on Flickr as my main photo library, I would probably be sorely disappointed now.

If I want to escape a service like Tumblr or Flickr, I have to hope that I can export the content I’ve uploaded and then figure out if I can re-purpose it. With an independent website and content owned directly by me, I can take my content elsewhere without having to do any sort of “exporting” or reconfiguration – it is already portable by its nature, and I have planned for it to be ported.

By choosing a hosting-agnostic approach paired with a static site, I am free to set up S3 quickly and flexibly. I would be able to work similarly with any other basic hosting plan, should I ever need to migrate. My method allows me to pack my things and set up elsewhere in very little time at all, since my bare dependencies are: a domain, HTTP, HTML, and CSS (and maybe some other stuff that I will get to). The web and all its parts are decentralized by design, and I want my content to be as decentralized from infrastructure or publishing constraints as possible.

A static site makes independent publishing approachable

Serving only static files is future-friendly and robust, which means my content and distribution remain independent in two important ways:

Another aspect of working with a static site that appeals to me is that I am able to handle the scope and output much more easily that I would with a dynamic site. I have had experience maintaining and designing for a WordPress site and the complexity and fragility of a WordPress site is off-putting and beyond my current set of technical skills.

The trade-off is supposedly an easier user interface for editing and administration, and more flexibility with dynamic content. However, I find a CMS in the WordPress model more intimidating after a couple of years getting comfortable with tools like Jekyll and Git. I like working in a text editor. I have grown to appreciate the power of the command line. The data that I input into my site is under my control because I manage the input and the output from my own computer, rather than relying on someone else’s server.

future friendly logo

The future friendly movement is a significant inspiration for my approach, in both philosophy and implementation. #ffly astronaut logo is licensed CC BY, modified slightly by me.

I am willing to admit that I don’t have a handle on working alone with a complex dynamic site suited to my design goals. Fortunately, static sites make up for their deficiencies in dynamism with high performance and robustness. Dealing with opaque and breakable databases, worrying about security holes, and spending time figuring out limitations of a dynamically programmed site takes my time away from writing, photography, and improving the user interface of the site.

Most importantly, no cruft or opinionated design from a framework or CMS can change my approach to structure and presentation. Anything I put into my site, whether an enhancement or method of working, is my choice alone.

Additionally, I have an RSS feed and I plan to integrate with other APIs and services in the future. However, this site will remain the hub and the canonical location for the data it contains. I don’t particularly mind if people read it in a read-later app or an RSS reader, or even with some translator service of the unknown future. Robots and humans alike can do what they like with my work, as long as it is hyperlinked and attributed to the original source.