The taxonomy is exhaustive: it consists of 52 terms grouped into seven broader categories. It is — I think — an impressive piece of work.

But I’m not sure it’s actually very useful.

Scientific versus subjective taxonomies

Taxonomy is an attractive latinate term that confers a certain objectivity. There are, I think, two broad types of taxonomy, namely scientific taxonomies — the sort that categorise objective, physical entities, such as butterflies — and subjective taxonomies, which attempt to categorise abstract concepts, such as customer service.

Some subjective taxonomies err towards objectivity more than others, normally as a result of attaining a certain respectability and through agreement on underlying concepts over time. Ontology, epistomology and philosophy of the mind are established areas of philosophy, for example. Within customer service we could maybe state that customer experience is an established sub–term of customer service, but terms such as coaching, IVR and performance management are either too faddish, too vague or not connected closely enough to customer service alone to be included within the taxonomy.

Without agreement over concepts users — even experts — will find it difficult to relate content to taxonomical terms. What exactly are performance management and diversity and language?

New subjective taxonomies should be general

This is not to argue that newer areas of study shouldn’t have taxonomies. By using broad, general terms and sub–terms that have gained traction within a subject area publishers will be able to guide users through their content. Over time more thorough taxonomies will develop. Who knows; perhaps one day there’ll be university departments dedicated to areas such as customer service, something my employer would no doubt love.

The notion of tethering content delivery to a particular proprietary platform or hardware device is admitting defeat Arc 90

This is a great read, by the way, and tops off an interesting few days in the online reading world. We’ve had Safari 5′s reader, Today’s Guardian and Arc 90′s post.

But it’s not just admitting defeat, is it? In the same way that it’s not just the publishers and advertisers’ fault that online texts are so difficult to read. Designers are complicit too, both in their enthusiasm to design for closed, proprietary and downright expensive formats and in their willingness to create pages that are chock full of noise and hard to scan content.

I like the fact that Arc 90 and Phil Gyford have made open, web texts more readable, rather than concentrate on, say, the iPad. There’s a political element to this: Information — and its proper presentation — shouldn’t just be the reserve of those who can afford to spend a few hundred quid on what’s essentially a toy. Websites remain the most accessible, democratic medium.

After completing the purchase I actually got up from my desk and told a work colleague how pleasurable the shopping experience had been. It was that good.

Good, they said.

Step forward Typekit:

The Typekit payment form

That’s all I had to complete; no address, name or passwords–that–were–set–two–years–ago. No getting up from the desk to ask someone for information, no rifling through paperwork, no phone call home.

It didn’t feel risky or insecure: the micro–copy was clear, reassuring and trustworthy, and there was no small print or legalese. Instead, a plain statement that told me cancelling would result in an automatic refund. More good.

I wonder if some payment forms are made difficult in order to reassure users that they’re somehow more secure. Or that more fields = more serious.

Note that the title is a link to the same page. Incidentally, Customer Experience Matters is a great blog which I thoroughly recommend.

Customer Experience Matters is hosted by WordPress.com and uses the Regulus theme. Regulus is a very smart theme, and the author has published some excellent plugins (so I’m certainly not criticising the blog or the theme author).

What’s so annoying about these links?

Well, it’s not going to ruin your day encountering a title that links to the same page, but:

• users expect to go to a new place when they click a link. At least page anchors lead to another place within the same document; these type of links don’t lead anywhere new at all
• copying and pasting a title that’s also a link requires some manual dexterity (as I found out when tweeting the Customer Experience Matters page; I ended up clicking the link accidentally)
• there may be an SEO issue (at least, Chris was wondering about it). Headings that are links are perhaps viewed as links to other pages rather than actual headings

Fixing the problem

In WordPress, it’s pretty trivial. In single.php look for the page title; it’ll probably look like: <h1><a href="<?php the_permalink(); ?>"><?php the_title(); ?></a></h1>. You need to remove the hyperlink, so something like <h1><?php the_title(); ?></h1> would do it.

Like I say, it’s more a tut tut than a huge usability issue, but these small annoyances can accumulate to create a frustrating user experience.

What do you reckon? And what’s your pet website peeve?

Let’s say you’re using WordPress to power a website. Like many CMSs, WordPress uses templates to build HTML pages, which involves figuring out appropriate functions, syntax and how the templates slot together and work with the back–end.

Writing plain old markup (and some PHP bits and pieces) is a lot quicker, and you decide on the doctype and flavour of your markup. WordPress, on the other hand, forces certain structures on you: self–closing tags and comments wrapped in <li> tags, for example.

The WordPress admin area can be bewildering for non–techies

CMSs make things complicated for clients as well. Often the person responsible for a website has no background (or interest) in computers; the very concept of a CMS is enough to scare them off. Logging in, finding the relevant option and making amends adds a layer of abstraction to their mental model of the site. Far simpler if they can simply change content on a page.

Finally, for all the power they afford, CMSs can be maddeningly inflexible when it comes to changing simple things. Let’s say a site owner wants to alter their footer contact details. How do you achieve this is in WordPress without editing a template file? Having to explain to a client that you’ll need to contact me to make this change isn’t really satisfactory.

Far better if clients could simply change the text on the page.

Enter Unify

Unify is one of a number of apps that allow site owners to edit text on a live site. There’s no back–end to deal with at all: The user visits example.com/unify, logs in and is returned to their home page. Icons indicate editable areas:

The green icons indicate editable areas

If the user clicks on an icon they can make changes to specific bits of content (or even whole blocks), review them and finally publish. Compared to logging into a CMS, it’s pretty clear:

Editing text is easy in Unify

Installation is quick and easy. You buy Unify, set up an admin account and upload a folder to the domain.

Why it’s good

Unify solves many of the problems a CMS poses. From the developer’s point of view writing simple PHP that you have complete control over is both quick and fun (believe me: there’s an almost guilty pleasure in just marking up pages). But it’s clients that benefit most.

Firstly, they save money. While Unify costs 16USD (at the time of writing), the time a developer spends installing a CMS, creating a database, writing templates and explaining how it all works will cost the client more.

Most importantly, clients find Unify intuitive, which both reduces the number of help requests post–launch and encourages site owners to write more. Once the excitement of a new site fades, a CMS can act as a deterrent for adding new content.

And because there’s no CMS or database, the site’s faster and less inclined to develop complex problems. Which means less stressed developers and clients.

Conclusion

On the whole my experience of Unify has been very positive. The only problems I ran into with the software were a few javascript conflicts. These were quickly resolved when a new version was published (upgrades are currently free, and simple to install), and I got some sterling service from the people at Unit Interactive (their time is worth far more than the price, but I’m not complaining).

Sometimes, of course, a site will need a CMS (if there’s a blog, for example), and developers will have to weigh up the time and effort required to develop more complex features against installing a CMS and finding a plugin that does the work for you. Another approach is to use things like the Google Calendar and Twitter APIs and Unify (but that’s another post).

One piece of advice. Unify is flexible, and with great flexibility comes an even greater capacity for clients to make bad design decisions. If you place an (editable) one sentence summary of what a business can do on the home page don’t be too surprised when that one sentence becomes a paragraph.

What do you reckon? Are you using Unify or a similar service? Or have you found a way of using CMSs for simple sites?

The Baymard Institute: Nielsen and 37 Signals are clearly influences

There’s a lot to like here. The Institute is very much anti–ornamentation and focuses on action and performance. This makes a change to reading about @font-face and grids. The tone is feisty, confrontational even:

You should never add something just because it looks good – aesthetics are never the end goal but rather a tool web designers may use to achieve a specific goal (and only when it actually helps them achieve that goal). Decoration — the Enemy of Good Web Design

Add to this a Nielsen-esque design (no navbar, lots of bolding, a large, lego–like verdana in my Ubuntu) and you have an intriguing site. Naturally enough, I wanted to find out about the Institute and the people behind it.

Who are you, Baymard Institute?

And this is where I found a problem. The Baymard Institute doesn’t have an About page. True, Nielsen doesn’t have a navbar with an About link, but he does have an About page, the link to which has been inventively implemented.

How Jakob Nielsen links to his About page

So why isn’t there a Baymard Institute About page? Why can’t I reach their Twitter and LinkedIn accounts? Perhaps the Institute felt it wasn’t necessary to add these elements because they don’t fit in with their site’s narrow set of conversion goals:

1. get people to read a couple of posts
2. sign up for future posts through an e-mail newsletter or RSS feed

The site design reflects these aims in that it’s easy to find subscription links. But as a user this is quite a frustrating experience. Yes, I donned my fedora and did a bit of digging and unearthed Twitter and LinkedIn accounts, but I doubt most users would bother.

Design for complex user needs

If designers don’t consider what users want from a site they’ll lose conversions. An About page meets several user requirements that you may not consider as conversion goals in and of themselves. This is particularly true when users are interacting with an institute that carries out some form of research. How credible is this research? Who’s writing it? Similarly, Twitter may allow me to contact The Institute and gain further insights into its thinking.

Users can’t be frogmarched down a particular route, especially when you’re not running a site with a simple, clear focus (e.g. to sell x). The user experience is key.

The Baymard Institute produces some great content and is marketed in a clever way: the look of the site complements the forthright tone and the use of terms such as research and institute are intriguing. It’s just a shame I had to investigate what lay behind it.

Louis is wrong. There are a few salient points in his argument (that horizontal menus focus the designer in his or her efforts to label menu items concisely, for example), but each of his reasons is, well, wrong. However, this is a good blog post. Louis has at least written about something that’s fundamental to web design and made the first steps in analysing current thinking and practice. It makes a change from reading about fonts, CSS3 or (ahem) HTML5.

Horizontal navigation has become a convention

Examine the design and style of many of the sites showcased in CSS galleries, and you’ll notice a strong trend towards simplified horizontal navigation

I guess this is true. Of course, CSS galleries are just that — galleries — but I think there is a general trend in web design toward using horizontal navbars and, as a consequence, users will perhaps one day expect a horizontal navbar when they encounter a page. Still, I’m not so sure that real web design (i.e. web design outside CSS galleries) has adopted the horizontal menu quite so enthusiastically yet.

But vertical navigation is more flexible

Kyle’s post explains the compositional aspects of vertical and horizontal navigation far better than I ever could. I’m more interested in how using vertical navigation can make information architecture better. Take two examples:

The Guardian's horizontal navigation menu is hard to read

The Guardian uses a horizontal menu (well, two horizontal menus: as in everything, The Guardian’s website steadfastly denies that less is more) and is damn difficult to read. This menu would have been better rendered vertically. True, The Guardian’s site could do with a serious structural rethink, but some sites can only be pruned so much:

The BBC's vertical navigation menu works really well and doesn't 'waste' screen space

The BBC’s news site uses a longish, vertical navigation menu that makes it easy to access lots of different subsections. There’s no reason The Guardian (or many other newspaper sites, for that matter) couldn’t use a vertical menu to great effect. I’m currently thinking about my  work site’s IA, and it’s hard to see the number of top level sections dropping below eight. An old fashioned vertical menu may well help.

I’ve become lazy

I have to admit that I haven’t been thinking much about the type of top level navigation menu I use when building websites. I seem to automatically sketch a horizontal navbar and place something big beneath it (be it an image, some large text etc.) This discussion got me thinking about this visual approach.

But more importantly it’s got me thinking about structure and information architecture. It’s strange how you can almost wilfully ignore information that contradicts your cosy view of things. Even when it comes from God:

It’s a common misconception that limited short-term memory implies that menus should be similarly limited to 7 items. It’s fine to have longer menus (if needed), because users don’t have to memorize the full list of menu items. The entire idea of a menu is to rely on recognition rather than recall (one of the basic 10 heuristics for user interface design). There are many other usability issues in menu design, and shorter menus are certainly faster to scan. But if you make a menu too short, the choices become overly abstract and obscure. Jacob Nielsen, Short Term Memory and Web Usability

Brevity is not an end in itself. Too often I think I’ve aimed to simply reduce the number of options available to users, probably in an effort to not make them think. But over–pruning can have the opposite effect when a group of primary users isn’t presented with an option that best fits its requirements. Sometimes presenting a long list of links is unavoidable. More important than the number of links is the labelling, readability and degree to which they serve the user’s needs.

Although the original theme was poorly built, it did look good (and was popular), which shows that any beginner can achieve balance on a page. (I say that, but creating a balanced layout that also meets the demands of user and author is a different matter: Web pages don’t exist in splendid, formal isolation).

The simplest implementation of this idea weights content:space 2:1 (which will apparently imbue your page with divine significance), but your grid may allow for some other interesting combinations (for example, an 11 column grid offers a 7:4 split, which gives an original feel to a page).

Where to put the nearly empty column…

I’ve noticed that I tend to like the space placed on the left hand side of the page (a la my first theme). I’m not entirely sure why, but it’s something to do with balance. Or maybe it’s just me. For an example, take a look at 52 Weeks of UX:

Screenshot of the 52 Weeks of UX site layout without any amendments

Pushing the content over to the right just adds some — what? — tension to the page. Look at the same page with an inverted layout (I appreciate it loses some balance because page elements no longer align along grid lines):

Screenshot of the 52 Weeks of UX website with the content placed on the left hand side of the page

It’s fine: Still perfectly readable, attractive, uses the golden ratio etc. But to my eyes it lacks a little of the oomph of the original pages. Why is this? Perhaps it’s because we expect the text to begin on the left hand side of the page, but find we’re made to wait and do a little bit of work to begin reading (dramatic tension, perhaps?) Maybe the effect is reversed in right–to–left languages. Or maybe there’s not really any difference at all?

<!doctype html>

Which is reason enough to start using HTML5. But it also means that instead of structuring pages with:

<div id="header">
... <div id="nav">
<div id="content">
... <div class="post">
<div id="sidebar">
<div id="footer">

You can use:

<header>
... <nav>
<article>
... <header>
... <section>
... <footer>
<aside>
<footer>

Which is very exciting (and radically different from the last seven or so table–free years of markup). At last we can structure documents with real tags. There will be less <div>s in the world, which is a good thing.

Browser support

All modern browsers interpret HTML5 tags and allow CSS to style aside, header etc., and you can force Internet Explorer to join the party with a small snippet of javascript. I hotlink to some Google Code–hosted javascript by adding the following to the head section of HTML pages:

<!--[if IE]><script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script><![endif]-->

(Note the lack of a script type. That’s one of the many great things about HTML5: It’s stripped out lots of (X)HTML verbosity, which makes it a lot more friendly.)

Which means the following browsers and user agents don’t interpret HTML5:

• Internet Explorer with javascript turned off
• Screen readers

Which isn’t a problem because one audience is going to be absolutely tiny (is there any reason to browse in IE with javascript turned off?) and the other will simply ignore the HTML5 tags (another great feature of HTML5 is the graceful degradation. Browsers adopt the standard at different rates, but most of the time the fall back option is perfectly acceptable).

Most HTML5–specific tags are currently implemented by (ab)using the virtually meaningless div (div groups bits of content arbitrarily; it doesn’t indicate why these bits of content have been grouped). As screen readers do nothing with divs it makes no difference if we use header or article instead of div id="header" or div id="content". And once screen readers start to understand HTML5 users will begin to benefit from more meaningful documents. For example, screen readers could separate navigation from content by looking at the markup contained between nav tags.

Caveat

As ever, all is not completely simple. The problem HTML5 poses to screen readers is not the introduction of a new set of tags, but in the way it handles h1-h6. In previous HTML specs, a document could only consist of 1-6 discrete headings it made sense to only use one top level heading because it would mark up the document’s title, and documents normally one have one title. So your document would use h2s, h3s et al to head other pieces of content.

In HTML5 each node can have its own hierarchy of headings (so each header, footer, article and aside can have an h1), although it doesn’t have to (HTML5 is a good friend because it’s so flexible) Looking at our traditionally marked-up page, it would be structured along the lines of:

<div id="header">
<h1>Site title</h1>
... <div id="nav">
<div id="content">
... <div class="post">
... <h2>Document title</h2>
<div id="sidebar">
<h3>Sidebar section title</h3>
<div id="footer">

Whereas our HTML5 page can be structured like this:

<header>
... <h1>Site title</h1>
... <nav>
<article>
... <header>
... <h1>Article title</h1>
... <section>
... <footer>
<aside>
... <h1>Aside section title</h1>
<footer>

Which is logical, but means that screen readers (which use the traditional method) just see a bunch of first level headings, which corrupts the structure of the document.

It’s difficult to suggest a way round this. HTML5 is our flexible friend, so you can continue to use a strict h1-h6 structure, but it strikes me as illogical, considering the new DOM structure which allows us to have document level footers and footers within articles.

So are you using HTML5 on a day to day basis?

Or is it still too experimental for real client work?

They recently redesigned their website. It’s a brilliant effort, retaining the large, Georgia font face (it was once helvetica, believe it or not), simple typography, black/red and white colour scheme and uncluttered layout that has become their brand. They’ve also simplified the content presentation, making it even easier to read and navigate. They use some interesting copy to market themselves. There are many things to admire.

How to make nine pages easy to find

iA have taken a textual approach to marketing themselves: rather than simply presenting a gallery of their work, they’ve written several mid–length pieces on subjects such as networking, profile and method. It’s an almost unfashionable approach, but one that reflects the fact that they don’t just produce nice–looking, gallery–friendly websites.

Designers would normally present this information in one of the following ways:

• Display all the pages in horizontal or vertical menu
• Keep the top level navigation as simple as possible and allow the user to reach the detailed stuff by following a path that leads to more detailed information as s/he clicks through the site. The most obvious way to do this would be through creating a top level About page and linking to the longer texts from this page.
• Create a simple top level menu that pops out further options when the user hovers over About
• Place some “teaser” content on the front page (e.g. a customer quote) that links through to some more detailed information

Here’s what iA have done:

All 9 navigation options are available on every page of the iA site

So instead of minimising the menu options eveything is placed within reach of every page. Normally, this would result in an unwieldy, hard–to–scan list of links. What iA have done is incredibly simple: they’ve categorised the top level menu and presented the links by category. No pop out menus, fancy gradients or text shadows; just plain, well organised text that’s easy to read and a site that’s easy to navigate.

Genius: the interface as brand.