Canonical Voices

What the blog of robin talks about

Static site generators (like Jekyll and Hyde) offer a much simpler and more transparent way to create a website. There's a small learning curve, but it's totally worth it. Especially if you're a developer already.

What is a static site generator?

A piece of software that can read a set of files in a particular format and convert them into static files (e.g. HTML &c.) that can then be served directly as a website.

Note that just because a site is static on the server-side doesn't mean it can't be dynamic on the client-side. You can easily include comments and other dynamic functionality through JavaScript plugins.

The workflow goes something like this:

$ sublime-text _posts/ # create a new blog post
$ jekyll --server # build the static site into my _site/2013/05/30/why-i-love-the-internet.html directory and run a test server
# check the site and my new blog post look okay
$ git add . && git commit -m 'new post: why i love the internet' # save it in version control
$ git push heroku # release the change to my live site (I use heroku)

Why bother?

Personally I think static sites make managing websites really fun.

For the right kind of project, static sites can make it so much simpler to manage a site. They remove a whole bunch of concerns that you used to have to worry about (e.g. with CMSs like Wordpress or Drupal, or frameworks like Django, Rails or Symfony):

  • caching - You can forget about server-side caching, since you're already serving static files
  • databases - You don't need a database - all the data is stored as files
  • version control - You easily keep your whole site including document changes in version control
  • easy to start - Hardly have to write any code to get started.
  • easy to maintain - Tweaking your site is more transparent and direct - you can easily view and edit the static files directly.

Which sites make sense?

Any site that needs to do anything complex on the server-side work will not be appropriate. However, any site which is basically just a collection of static information - like a blog, a brochure site, or even a news or magazine site - could work as a static site.

The other important thing is that everyone who wants to be able to edit the site needs to learn how to do it.

This needn't necessarily exclude anyone. Many static site generators use Markdown document syntax, which anyone can understand and learn. Github even has a lets you edit files directly online, which anyone with permission can use to edit the website files. Editors will have to understand the concept of version control, and understand how the site structure works, but this shared understanding will probably aid rather than hinder your project's progression.

In any case, if the only people who edit the site directly are developers then using a static site generator should come absolutely naturally.


There are many static site generators out there written in many different languages:

Personally I use jekyll for my website. Originally this was because it is natively supported in Github Pages.

I'm not going to go into how to use a Jekyll in depth in this post, but I'll try to write another couple of posts soon:

  1. How to set up a basic static site with Jekyll on Github Pages
  2. How to host a Jekyll-based site on Heroku

Read more

I have many interests, but I think there are two common thread running through them all:

  • I care deeply, fundamentally about fairness and equality
  • I am very interested in complex systems

"Complex systems" sounds extremely abstract, but I think it really is the core of my academic interest. I like mapping systems in my head, seeing the nodes; seeing the ways they interact with each other. I like working out how to create elegant systems and optimal systemic solutions for solving problems.

This leads me in two directions:

  1. I love technology. Technology, along with all the problems it's trying to solve, creates and makes use of myriad systems and systemic structures. I love trying to understanding these systems.
  2. I love social systems and social science. People are complex, and there are extremely subtle and nuanced rules governing how they think interact in a social systems. I love pondering people and psychology.

Running through all the mini projects and fancies that flow from my interest in systems is my deep desire for global fairness and equality. I believe that technology has the capacity to be a great equaliser. Most people in the world don't really have a voice to influence the global power-structures, but hopefully the internet and communications technology can give them that voice.

In a nutshell, this is why I love the internet.

Read more

Chrome version 25 appears to have made a pretty serious change to how the HTML5 input date type is rendered.

Now the date type defaults to display: -webkit-inline-flex, and (this is the bad bit) if you use display: block the layout breaks:

date field layout broken

(try it yourself)

Why is this bad?

We use the date type on arena blinds, and to have more control over the layout of the input fields, they are all set to display: block. I think this is, if not "best", at least a pretty common practice.

So one day we realised our date fields looked broken in Chrome, and it was because of this issue. So my boss said:

If we can't rely on the date control not to break, we have to abandon the HTML5 date field altogether

And that's entirely fair reasoning.

Cognitive dissonance

My boss's perfectly reasonable conclusion goes against everything progressive that I've been trying to instil in my team.

Progressive enhancement is accepted best practice nowadays - to use the built-in functionality when it's there, with fall-backs for browsers that don't support it. E.g.:

if (!Modernizr.inputtypes['date']) {

This is a solid approach I strongly believe in. But if Chrome are going to implement breaking changes like this, I don't know what to think any more.

Chrome, you've ruined my day.

Read more

I was just entering an expense on Splitwise and I noticed a subtle little widget in the bottom of the screen saying "Feedback". "Aha!" thinks me. "This is exactly the sort of thing all websites should do". So I click it and find out it's made by Uservoice.

Websites need user-feedback. They need it all the time. So we need to be constantly offering users the opportunity to tell us what they think, but also not annoy users by bugging them all the time, and somehow try to avoid getting 50 of the same issue being submitted.

Well done Uservoice

I think Uservoice got this exactly right. You get a subtle link appear on the side of the site saying one word - "feedback". You probably noticed it, instantly know what it is there for, and it's easy to ignore if you want.

When you click it, you get given a list of current suggestions on the left that you can vote on, or you can submit your own suggestion on the right. It's perfect.

The feedback link is totally customisable, and easy to include in your site with a simple Javascript snippet.

I use the service on this very site (look to the right). Please click it to see Uservoice in action and please leave me some feedback :).

The missing link - Github Issues integration

Immediately I thought "where will these suggestions be stored?" because I was already managing my own list of ideas in Github Issues (augmented with Huboard) and I didn't like the idea of having to maintain two lists, or manually copy issues between the two.

Someone had already suggested integration to Uservoice, but it turns out there's already a slick solution with Zapier.

Zapier is an integration service - for linking various different APIs. And they already have built-in support for linking Uservoice to Github Issues.

But how much does it cost?

For this website I certainly can't afford to pay for either service. So it's a good thing that both Zapier and Uservoice follow a similar model to other modern digital projects like Heroku. That is - it's free for light or personal use, but when you want to scale it you have to start paying.

Which suits me just fine.

Read more

Try visiting this site in IE8. Go on, I dare ya. Alright, I'll tell you - it's an ugly white page with black writing. Oh except for a banner at the top telling you to upgrade your browser.

In recent years we have said goodbye to widespread support for first IE6 and then IE7.

Google dropped support for IE8 back in November, 37signals also. There are a plethora of articles out there imploring people to drop support for Internet Explorer.

IE8 usage

According the, global usage is at 24%. On this blog, it's at 1.5%, and on my company's website, Arena Blinds, (used by much less tech-savvy people) it's at 15%.

So if you were bold (like this site), you could probably drop support completely and effect less than 1/5 of your visitors. And those visitors would quickly upgrade their browsers.


Dropping comes with significant advantages:

These four points will effect your debugging time for front-end development dramatically.

Consider it.

Read more


I googled "Optimal font-size", read first 16 pixels then a dao of web design and came to the conclusion that the optimal font-size is not to specify one.


As for optimal line-height - around 1.5em is common, but The Golden Ratio seems a little neater. So that's a good standard.


As for line length - golden ratio typography claims that it should be proportional to line-height, which makes sense, but the equation they suggest just doesn't make any sense. A Smashing Magazine article suggests that around 65 characters per line is ideal, but that most people go for more like 75. 65em / 1.618 (golden) = 40.173 so I'm going to suggest that 41 times line height.

Read more

... if I had the time (this list will grow)

  • Bourbon (and neat) - SASS libraries
  • Backbone.js - Organised JavaScript
  • Brackets - Simple HTML/JS/CSS editor, written in HTML/JS/CSS
  • Firefox OS - Web focused mobile OS (this is a bit far fetched...)

Read more

So, having just accompanied my blog on its existential quest I have decided to start writing down rambling thoughts just for the process of solidifying them in my mind - and not worry about their quality as prose.

Further to that, I have something I want to solidify.

I've been working in the offices of Session Digital today. Every Friday, Marcello runs a "code workshop" for an hour at the end of the day, which I chose to attend. The purpose of this workshop is to encourage Continuous Improvement techniques to help coders improve the code they write.

His philosophy for this is based around the Japanese word Kata, which means "form" and as far as I can tell from the very brief introduction I was given is about building good technique as habit through repetition, so you don't even need to think about it.

The repetition in question is repetition of performing coding while conforming to the rules of Test- (or Behaviour-) Driven Development and of Simple Design, while also working in pairs. We are given a programming problem to solve, and then asked to solve it over and over again, trying to refine our "Form/Kata".

Rules of TDD (if these don't make much sense, go read more about TDD):

  • You may not write code except to make a failing test pass
  • You may only write a test until you have a failing state
  • You may only write code until you have made the test pass

Rules of Simple Design:

  • All test must pass before you may refactor/simplify code
  • There should be no code duplication
  • Code should be as expressive as possible
  • Code should be as simple as possible (eliminate complexity)

That is all for now.

Read more

I'm not entirely sure why I have a blog. Not to mention that it's on Tumblr, which is not actually quite the same as a blogging platform, but that's another issue.

Basically I have a blog because I like transparency in general - so I have this fantasy that my blog can be a transparent stream for my consciousness to be exposed to the world. And yet I still get upset that hardly anyone visits it.

Which raises the question of quality. Should I just throw any old rambling thoughts out there immediately and either come back to refactor them later (this has never happened) or just let search engines filter the wheat from the chaff? I don't think this is actually a way to gain trust and build readership.

But then maybe I don't care about readership. The act of writing down my thoughts is both therapeutic for me and helps me build memories, so that's probably a good thing. And these writings may as well be public so if, on the off-chance, someone else might find them useful they can benefit from them.

So in conclusion, my blog is a place for half-formed rambling thoughts of mine, and it shouldn't feel self-conscious about its lack of quality because it's not about the quality, and it doesn't need high readership.

Wonderful. QED. Bitch.

Welcome to my blog.

Read more


I just had a paper published in the Taylor & Francis Ergonomics journal.

It's called "Micro-generation schemes: user behaviours and attitudes towards energy consumption".

Buy it from Taylor & Francis


Download it for free from my server (am I allowed to do this?)

Enjoy :)

Read more

Design performance

  • Write the whole page design in CSS (no images) if at all possible
  • Mobile-first (with no images at all)
  • Design the page so all all images could be lazy-loaded without the page looking stupid
  • Obviously don't include unnecessary elements in the page


  • Lazy-load all images, depending on visibility
  • Serve all files yourself - then you can bundle them up into a single request
  • Use sprites wherever possible
  • Try to have one request for all JS, and one for all CSS.

Read more

Never use IDs

They are useless. You get no performance benefit from using IDs, and you confuse yourself by adding more specificity rules that you have to think about (IDs bind harder than classes). There is no situation where you use an ID that you could not instead use a class. Only use IDs in mark-up to show sections in the document - for # hashtags. Never use them for CSS.

Always make rules as generic as possible

You never know when a rule might need to be re-used, on a different element, so you should avoid ever limiting a class to a specific tag name. So div.header is wrong. Just do .header. Also using really specific rules makes it more likely that your CSS is going to get really confusing.

Use class with semantics in mind

From the W3C:

Good names don't change. Think about why you want something to look a certain way, and not really about how it should look. Looks can always change, but the reasons for giving something a look stay the same.

You might have to break this rule if using CSS frameworks. I'll leave that one up to you.

Useful resources for CSS best practice

Read more