Colophon

WTF is a Colophon?

A brief description of publication or production notes relevant to the edition, in modern books usually located at the verso of the title-leaf, but also sometimes located at the end of the book.

So before I forget, I’d like to explain what happened behind the scenes on this site.

Approach

You’re no doubt familiar with the old adage: “The toughest client is yourself”. Well it’s true, designing your own site can be a frustrating experience.

When I’ve worked on personal projects before it’s tended to be a messy, drawn-out, indecisive process. I’d struggle to produce anything I was happy with and/or I’d change my mind every 5 mins and lose interest.

To avoid this happening again, I set myself 4 rules;

  1. Stick to the MVP - with yourself as the client, it’s too easy to change the scope as you get further into the project. I made a list of the site structure, and detailed every essential element that would be on the page.
  2. Avoid trends - I deliberately ignored looking at any other blogs/personal sites or any source of inspiration. It’s easy to be influenced (consciously or subconsciously) by popular shots on Dribbble, only to find that 6 months later you want to rip it down.
  3. Build it fast - I wanted to keep momentum to avoid backing out / changing my mind. I set out a realistic schedule and stuck to it.
  4. Make it personal - probably the most important thing I wanted to remember. Not lose sight of why I was making the site in the first place - to do things my own way, be myself and communicate who I am.

Setting myself these rules made the decision making process so much simpler.

Design Decisions

Responsive

I anticipated that my audience would be on a wide variety of devices but guessed it would be a large percentage of iPhone users - you know what this industry’s like.

Update: So far, my stats show that 20% of traffic is from an iPhone.

The site is optimised for small screens. I use a simple layout, sticking to a single column, right up until my final breakpoint (approx. 1100px) where I load in a sidebar.

My content is mostly articles with a few 600px Instagram photos thrown in, so it made no sense to go beyond this width, even on wider viewports of 1280+. Text reads better in a narrow column.

Typography

With the sites minimal style, the typography had to do a lot of work.

I pushed myself to use a font that was unfamiliar, so I hit the ever expanding Google Web font library.

Google fonts FTW. I’ve never paid for a font yet!

I settled on Dosis (sans-serif) for headings and Bitter (serif) as a body font. Both fonts have friendly/rounded characteristics that compliment the style of the UI, and more importantly they render nicely on small screens.

I wan’t comfortable with my Dosis at first, but it started to grow on me, and now I think it holds the design together.

I use Fittext in a couple of places to control large headings.

I find a lot of sites display too few characters on small screens…

Leading to a really
awkward line length
that breaks-down
sentences too much and
makes them tricky to
read.

I made sure I avoided this; the body font size has been set to 12px at min-width and 21px at max-width. This ensures an optimal line length of 55-75 characters.

Images

I use the LazyLoad plugin to control my images. Some of my photo albums have 20+ photos in them, so the page load quickly adds up. Using LazyLoad allows me to load images as users scroll them into view.

Navigation

My navigation menu is the bit i’m probably most fond of, it’s very simple, but that’s why I like it.

It’s JS free - using CSS transitions and the :target pseudo-element as a selector.

It’s semantic - the navigation markup sits at the base of the document and gets displayed at the top when users trigger the menu.

I’m going to write up a short post to share the source code for anyone else that wants to use this approach.

Colour palette

I experimented with a few colour palettes; orange and brown, black and white, even purple an pink!

In the end I settled on a desaturated red (#C66) which is only a few hex colours down from the Etch red (#F66).

Icons

I created a custom icon font using Icomoon - it’s an awesome tool and has changed the way I build interfaces.

It allows you to upload SVGs and incorporate them into a web font. This means my ‘Jim’ logo is actually a text symbol, so there’s no images in the UI, which means no stressing about high pixel densities.

CMS

I write all my notes in iAWriter, so I wanted a CMS that was markdown friendly. I also wanted to avoid databases - MySQL is my Kryptonite.

That narrowed my choice down to three (yes, I did feel a bit like Goldilocks):

  1. Kirby by Bastian Allgeier
  2. Anchor by @idiot
  3. Jekyll by Tom Preston-Werner (Co-founder of GitHub)

Jekyll was a bit too advanced for my tiny left brain, so it came down to a fight between Kirby and Anchor.

In the end Kirby won - it had few nifty features and more documentation to help me get to grips with it quicker. The thing that finally swung it was this tutorial: Connect Kirby with Dropbox, which explains how to run a Kirby site out of a dropbox folder on your server. I’ll explain this in another post.

Comments or No comments

In my experience from Design Fridge, comments can be a bit hit and miss. I didn’t want the task of sifting through lots of spam. I considered using Disqus, which integrates well with Kirby, but in the end I decided not to include commenting functionality (at least on launch anyway).

I’m pleased to say it’s one of the best decisions I made. It seems that by not allowing comments directly on the site, responses are channeled to twitter and email. This means that only serious people share their thoughts, and they’re articulated in a more concise way, uninfluenced by a thread.

It’s also easier for me to manage communications through my twitter/email clients and so far I’ve had some really enjoyable discussions.