Category Archives: Implementation

12.04.09
by

Why does a blog look like a blog?

Smashing Magazine has an article titled The Death of the Blog Post, wherein UX designer Paddy Donnelly examines a trend amongst web designers to play with their blog’s design and layout in what he calls a “blogazine” – a blog with a magazine-style layout. Donnelly’s main point seems to be that he, and other designers, find traditional blog designs boring, and feel that that each post deserves to have its own design to service its own needs, rather than have to fit in with a single blog-wide design.

I can understand why this is deeply attractive to designers. The creative freedom to tailor a page’s design perfectly to fit the text must be something designers often crave. And the examples he gives, particularly those from Dustin Curtis, look lovely. But the idea of designing each post afresh is only going to work for a very tiny minority of bloggers with the time and skills. For the vast majority of bloggers, this is just not an option.

But more than that, conflating blog and magazine is a really bad idea.

In unpicking why, we have an opportunity for some important lessons for enterprise. The first is that your blog design really, really matters. There is no excuse for you not to have a beautifully, professionally designed blog that is readable, accessible, and flexible enough to be read on different monitors or devices. If your blog is just slapped onto your corporate website with the same navigation, styling and layout as the rest of the site you should get it redesigned right now. No excuses.

The next lesson is relevant not just to enterprise, but also to web designers shifting from site design to blog design: Blog design patterns matter.

When you look at a well-designed blog you will see a number of features that I call “blog furniture”. There are many pieces of blog furniture to choose from, and not all blogs use all pieces, but most use a combination of:

  • Calendar
  • Search
  • Categories
  • Archives
  • Recent posts
  • Recent comments
  • Meta information (e.g. the admin sign-in link, RSS feed link)
  • RSS feeds from other sources, e.g. Delicious, Twitter, or news headlines
  • Badges from third party sites, e.g. Flickr badges
  • About the Author text, photo or link
  • Blogroll or list of external links
  • Tag lists or tag clouds

These are really important not just because they are useful, but because they provide the visual cues that tell visitors they are somewhere different from the rest of the site, somewhere more personal, more conversational, more informal. Take those cues away, and you risk confusing your readers, even if only momentarily.

If I pitch up on a page that looks just like the rest of the site – or, indeed, nothing like any other page on the site – then it’s going to take me a while to understand what it is and what it’s for. When we arrive on a new site, we give it less than a second to impress us. If the visuals conflict with the content, for example, we are expecting to see a blog but we are presented with something that looks like a magazine, we are less likely to hang around. The fact that it looks pretty isn’t going to make up for that moment of disconnection. (In this precise case, designers may be the exception, but that also means they are profoundly unable to judge whether or not a page causes a conflict of expectations.)

Thirdly, RSS matters. A cornerstone of the blogging world, RSS strips out all design and present, very simply, passages of text interspersed with any graphics. Donnelly’s post looks awful in RSS. Compare and contrast:

From the website

The Death Of The Blog Post - Smashing Magazine

From the RSS feed

NetNewsWire (1536 unread)

A blog post that reads in a disjointed way, with too many graphics, in your RSS reader is going to be a post you don’t bother to finish. Beautiful layouts that rely on the juxtaposition of text and image to make their point are likely to fail horribly in RSS.

I would say that if you’re creating a site with lots of bespoke pages, no blog furniture, which loses its coherence in an RSS reader, you’re not actually writing a blog at all: you’re using blogging software as the backend of a website. Now, there’s nothing wrong with that and I’m glad that such talented designers are flexing their online creative muscles. But let’s not confuse our spades and our shovels.

Over the last ten years blogs have evolved conventions because those conventions are useful. There is no reason why those conventions should hamper design, but you throw them out at your peril.

12.01.09
by

When provided a choice, do people choose?

Social software is a strange beast in terms of corporate software. The best social tools are developed by small software houses or ad hoc groups of open source developers. Often they are much more usable than traditional corporate tools, more lightweight and more flexible. Comparing WordPress, which is basically a content management system, with some of the CMSes I used back when I was a web designer/developer, the difference is stunning. WordPress is just so much simpler to use and easier to manage.

But for me, the key difference between traditional enterprise software and social software is that in almost all cases, social software is elective. If your business decides to change its email client or accounts package, for example, there’s nothing users can do but get on with it. Social tools, on the other hand, frequently replace existing tools/processes such as email and meetings and are almost always optional. Users often opt not to bother.

The successful implementation of social software doesn’t stop with a technically successful roll-out. In fact, that’s when the process begins because that’s when your adoption strategy should kick in.

Adoption is ultimately about behaviour change: persuading people that, for example,

instead of sending an email to everyone with a new version of a document they are working on, they should put it on a wiki where it’s easier to collaborate. This might seem like a small step – and for a few people it is – but for the majority that’s a fundamental change to the way that they have learnt to work on documents.

When we are faced with these sorts of changes we tend to resist. I’d hazard a guess that neophobia is much more common than neophilia (which is why you can spot us neophiliacs a mile off!), and the assumption that people will resist should be front and centre in social media project roll-out plans.

In short, the implementation of social software is not a technical project, it’s a behavioural change project.