February 11, 2008. The blog homepage.

Explaining the design of the blog

The new blog design is mostly implemented, and I though it would be a good idea to talk about some of the decisions I’d made while designing. This is a long one, so be warned.

The grid and leading

In previous versions of this design, I chose to work with a six column grid. Although this proved a little too restrictive for this site, a lot of what I tried to create was possible within it. Rather than reinvent the wheel with eight or ten columns, I chose to simply double the number. With column widths of 139px, it’s a shame you can’t divide an odd number by two…

Twelve columns, 60px wide, with gutters of 18px

I was forced to create a brand new document, with a new grid. This turned out to be a blessing in disguise, as it forced me to re-examine each item on each page as they were recreated. I was never really happy with the portfolio highlights on the homepage; the text was far too cramped. Revisiting this, I was able to give the text 50% more horizontal room and fit it comfortable to the right of a sample image. Although the change is small, the improvement is significant. Not only are the lines now long enough to read comfortably, but the image and text are arranged in our reading direction.

On the blog, this added freedom helped when designing the pull-quotes (text flush left in a three column wide box), the comments (the gravatars fit snugly in the second column) and the comment form (the text inputs are three columns wide; purposefully thinner to de-emphasise them relative to the more important textarea). It helped even more on the portfolio page design, something I’ll show later.

You can see the grid in the background of this page. Twelve columns, 60px wide, with gutters of 18px in between.

Leading

18px is the leading used for most of the text on this page. In the mock, baselines for almost all text are 18px or some multiple thereof apart. Your eye recognises the pattern and starts to step through the document by these fixed amounts, making reading more pleasant.

These damn pull-quotes are causing me no end of bother

That’s something I’ve tried to achieve in the implementation, and continue to work on, but it’s a challenge when using type and images together, or type of various sizes side-by-side.

And it’s not simply a matter of it being difficult… the way text is rendered varies between browsers. At the moment, Firefox on the Mac displays the pull-quotes with baselines that match the text it accompanies on every second line; Safari does not. I can imagine this will cause me to tear my hair out in future — the prospect of providing browser-specific baseline adjustment seems nightmarish at best.

I’ll do what I can.

Visual Hierarchy

It was important to me to set up a clear visual hierarchy, and I also thought it important to give the text of the article the highest priority. I decided that, if the text is to construct an argument, then unless an image, pull-quote or code sample directly advances that argument it should be considered secondary and should not obstruct the text.

Ms. Camera-For-A-Head: Images like these provide visual interest and may provide supplementary information and supporting argument, but they do not form the main thrust of the article. So why interrupt the flow of the text to include them?

But I also wanted to use large images where possible because damn it, they look good. And, although these items are only of secondary importance, they are not irrelevant and are tied to specific points in the text.

In this design, everything spins out from the central core; with nothing deeper than two columns in, the text remains unbroken. Images go to the right and can be four to six columns wide, pull-quotes are three columns wide with exdented quote marks, and everything is nicely asymmetric. Asymmetry is something I learned to appreciate from the Swiss modernist movement, which heavily influences this design — though it deviates from it so much that I suspect Josef Müller-Brockmann would lynch me for that comment.

Changes made while implementing

Once the design was implemented, I started to notice some usability problems.

Originally, to return to the main blog page from an article, a reader would have to scroll to the top of the page and click on the blog tab in the navigation. While browsing around the site, I became frustrated at this forced movement away from the text so, to solve it, I added a link to the main blog page right beside the date of the article.

At the bottom of the page, I kept trying to find an “older articles” link, which was missing. I managed to get Textpattern to do a multi-page archive, but got fed up with it pretty quickly; the next step was to create an “all entries” page and add a link at the bottom. It’s flush left against the page border to draw a huge amount of attention to itself at the exact same font size as body text. It appears wherever previous entries are listed, other than the full archive page itself.

Behind the scenes

The blog is still powered by Textpattern, but I had to fiddle with it quite a bit to do what I wanted. Something simple like displaying the latest article in a different style was impossible with Textpattern’s built-in functionality. Luckily, Textpattern allows you to embed PHP code in your templates using the <txp:php> tag. Textpattern also provides you with sane access to its internal functions – to get the HTML generated for the <txp:article> tag, just call the article function, passing any arguments through as a hash.

If you want to take a look at where I’ve used custom PHP code, take a look here:

This part of the job did remind me that I have what I’ll politely refer to as an “extreme distaste” for PHP. Perhaps I’ve been a bit spoiled with Ruby and other OO languages, but it seems very odd to call array_pop($variable) instead of object.pop(). This is how functions are “namespaced” in the language, and that’s just ghastly.

“Subjects” are implemented using the tru_tags plugin, and the gravatars use cbs_gravatar. Entry-specific stylesheets (and eventually Javascript files) are handled through Textpattern’s custom fields. I’ve used an entry-specific stylesheet to show the grid on this page.

Those little pictures by the comments

The pictures that appear beside each comment are gravatars and it’s really easy to set yourself up with one. Just head along to their signup page and take it from there. It’s based around your email address, so be sure to read their privacy page.

If you comment on any design blogs I recommend you set one up for yourself. They’ll help you find your own comments in any discussion here, and are used on several blogs in my feed-reader at least. I mean, if Jon Hicks uses them, they can’t be all bad!

Further reading

Blog posts

Books

If you are a designer who has not read these two books, you are doing yourself a disservice. Seriously.

Resources

I used the GridMaker script by Andrew Ingram in Photoshop when working on my design. He’s released a new version of Gridmaker, but I prefer the old as it supports the creation of modular grids.

This is an Article about , , and . It was posted on February 11, 2008.

2 Comments

  1. David Barrett on Feb 11, 11:31 pm

    To the left is one of those gravatars.

  2. David Barrett on Feb 19, 10:58 pm

    Yeah, the baselines are screwed up entirely due to sIFR. I’m trying to figure out some nice way around it.

Commenting is closed for this article.