A visitor named Kevin dropped me a note asking for more details on site dimensions (or here about Stèles). His email address unfortunately bounces, so I can’t reply to him directly, but here’s what I wanted to say:
My point about “dimensions” is that they’re specific to each body of information.
For me, in a collection of elements, a dimension is a characteristic of the elements that helps the user navigate the collection. For example, in a magazine (a collection of articles), the article’s author is a dimension (I can navigate through all articles by a certain author) but the title isn’t (“all articles with title X” makes no navigational sense).
If I look at the sites I’m currently working on, www.asics.co.uk and www.onitsukatiger.com/en-uk — there’s a clear difference in the way we’ve handled the product catalog. The “dimensions” of each product catalog are related to the way visitors perceive the products, although the products are formally the same (sports shoes).
For the ASICS brand, performance products are mainly dealt with from their functional aspects. The dimensions are: sport, gender, type of pronation (for running shoes), etc. For Onitsuka Tiger products, we’re looking at material, color, profile, etc., which are more relevant for fashion-oriented products.
Basically, for a product catalog, the “dimensions” are the characteristics you’d expose in a faceted navigation system (“product filters” or other ways of narrowing down your selection).
But products are a very data-oriented collection of elements, so it’s pretty obvious. You’ll find more interesting dimensions on news sites. An article is defined by its author, the section it belongs to, its date, maybe the type of article (interview, opinion, investigation, supporting data or graphic, etc.), and covered topics.
A very good example there is www.slate.com : I’ll guess they recognized that the article’s topic is a very good indication of what you’re interested in, as a visitor. And they probably realized automated “related articles” are not very powerful in helping users get on with their reading.
So for most articles, they actually invest human work into making the “topic” dimension explicit, and give you navigation to related articles that actually makes sense. On http://www.slate.com/id/2232558/ for example, I’m talking about the block “Related in Slate.”
The “You might also like” block is automated and I would guess less powerful. That’s why I contend identifying the dimensions is important: when you’ve found a dimension that makes a lot of sense to your users, then you need to look at making it easy to navigate.
However, each body of information will have its own dimensions. Some more obvious than others. Some more valuable than others. Some will even change in value over time (in Slate, I would guess the “Related in Slate” is only important after the article’s been up for a few days, for example.) And there may definitely be more (or less) than 4.
An interesting point to notice: there’s a very easy way to deal with dimension, rooted in a technical approach. If you have a field in your database (such as “author” or “date”) then offer it as a navigation option. But then it’s just “characteristics of your data.” The notion of “dimension” is purely conceptual, and introduces the user’s perception as a defining factor. It will often make use of database fields, but not always.