12 August 2017

Website geekery

So we have a new website. The previous one served us well, but we wanted something more up to date, in terms of both appearance and technology.

Giving ourselves a clean sheet rather than a simple re-skinning was quite liberating, as I could come up with a very definite set of specifications without feeling limited by what was already in place. I’ll go through that list in a moment.

I’ve built a full content management system (CMS) from scratch in the past, and knew I wanted something much more stripped back so that maintenance and updating would be as simple as possible. For that reason, I discounted building the site in a CMS such as WordPress, because I knew I’d get frustrated by all the unnecessary extra stuff that environment would foist upon me. Similarly, I looked at and then discounted frameworks such as Bootstrap and jQuery Mobile, simply because of the additional features I didn’t need.

Finally I happened upon AMP, the Google-sponsored project to create a faster experience for mobile browsers, and everything fell into place. Here’s my list of specifications ticked off one by one:

Apart from the technology, there appears to be a good business case for adopting AMP. Not only does it have the support of Google, but the search giant prioritises AMP pages in search results on mobile. Similarly, there are impressive retention and conversion statistics to be gained from making sites load more quickly, so if these are the sort of marginal gains that can help boost the discoverability of smaller businesses then I’m all for it.

Building the site

As you might have guessed by now, the server-side infrastructure stitching this all together is characteristically minimal.

Each page is a plain text file, which a PHP script pipes through a Markdown parser, fills in some {{element}} template codes, and serves the finished page to the browser. As far as adding extra content to Blog or Sample spreads is concerned, the Markdown file just needs to be added to the appropriate folder on the server and the PHP script generates all the necessary “next”/“previous” links on the fly.

If this were a high-volume site then it would make sense to cache the finished pages to disk, but I’ll probably only implement that as part of bundling the HTML5 into something like the Baker Framework, if we decide to create an iPad app for demoing our work in meetings.

Design and typography

For someone whose business revolves around design and typography, it might seem strange that I’m leaving this aspect of the site until last, but it does make sense in the context of separating context and presentation.

For the typography, I wanted typefaces designed to work well on screens of all sizes, so Open Sans and Droid Serif, both by Steve Matteson, pretty much selected themselves. (I opted for Open Sans over the associated Droid Sans because of the greater variety of styles and weights; conversely, Open Serif is a commercial product and I didn’t want to go down that route for a website.) There’s also a touch of FontAwesome for details.

Meanwhile, the overall design is intended to be clean and modern to reflect our style so, with due consideration at each of the CSS breakpoints, that aspect pretty much designed itself too. Nonetheless, we’ll doubtless be tweaking things as time goes on, for that at least is one benefit of websites over printed books!


To wrap up, here’s a summary of the tools and resources used in creating this site:

Site components

Development environment

Validation tools

Hat tip

Special thanks to Darren Turpin and Mark Lee for their helpful comments while the site was under development.

Update 17 February 2019: We’ve stopped using Droid Serif for body text — having Open Sans throughout creates a more unified feel.