The classical structure of a website is that of a tree. The trunk is the homepage. From there you climb the tree, upward and outward until finally you reach the leaves. That is how we design websites. That is how we test websites.
It’s just not how we use websites.
Actually, more to the point, we don’t use websites at all. What we actually use are:
- The Web.
- Web pages.
Image copyright (c) 123RF Stock Photos
If we want information on something, we do not say to ourselves, I wonder what websites might have information on that. We say, I wonder what Google will turn up on that. We do not use a website to find the information, we use the entire web (courtesy of Google).
When we follow the search results that Google gives us, they do not lead us to web sites (unless they are paid links), they lead us to individual web pages. Those pages are, of course, part of a website, but we don’t experience them as such. We experience them as pages.
If we find a particularly useful page, we bookmark it for later use. We bookmark the page, not the website.
Sometimes we find a page we want to share with friends. We share the page, not the website. (Feel free to share this page.)
Sometimes a good page will have links to other pages. We may visit them. We go straight from page to page. We do not navigate the website. The page might be on another website. There is a chance we won’t even notice.
After we have finished on a page, we hit the back button to go back to the previous page. We do not navigate the website to get there. The previous page might be on another website. There is a chance we won’t even notice.
If we are curious about something on a page, and there is no obvious link a page that will explain it, we highlight the phrase and do “Search Google for…”. We do not use the website to find out more. We use the web.
The tree is upside down. The first thing we meet are the leaves. We don’t always know which tree they belong to. We don’t always care. When we have finished with one leaf, we move to another. It doesn’t matter very much if it is a leaf on the same tree.
Yet we design websites as if the tree were the right way up. We test websites as if the tree were the right way up. It isn’t. The tree is upside down. It is the leaves that matter.
Every page is page one.
Thanks, Mark, this is indeed how I use the web – with a few notable exceptions which I think redeem many web designers and information architects: Corporate web sites.
When I want to learn about a company (rather than wanting to buy one of their products), I very much rely on the tree they designed, because their decisions of branches and leaves tells me something in addition to the actual content of individual pages.
For example, does a large corporation portray a cohesive culture or is it a bunch of linked sites that integrate poorly? What do they emphasize, their customers (how can they help me?), their services (what skills do they have?), their products (what are they good at making?) or their employees (who are they?)?
In a way, corporate web sites are a lot like show & tell: I’m not merely interested in individual pieces, but also in what they choose to present and how.
Hi Kai. Thanks for the comment. I agree, one of the few times when you really do want the website is when you are tying to learn about the entity that put up the website. And I agree to that when we are in this mode, we are not simply reading for information, we are also viewing the site anthropologically — what do their design choices and the information they choose to present tell us about them?
This does, of course, present a fundamental challenge to a web designer — how to balance image with substance.
I agree with Mark – that is exactly the way I use the web. I also agree with Kai, when I’m researching a company, I navigate their website.
There are also a few other “websites” that I use in a non-search mode, mostly to do with retail shopping or my hobbies, but I expect a search function on those websites to help me navigate within their context, so it probably qualifies as what Mark describes, as well. I’ve learned by experience that the layout of most websites is not as useful to me as search.
Hi Pamela,
Agreed, catalog sites are also a partial exception — sometimes it is easier to search a trusted vendor site for a product than to search the Web.
You’re quite right, Mark. Which is why I use Mediawiki unrepentantly. And the first thing I tell visitors is:
Normal is “pages connected into some sort of hierarchy, like a table of contents, with menus for getting around.” Wiki pages are not normal: they just sort of float around without a table of contents, but are organized, nonetheless, with categories and you can search and browse as your interests develop.
Granted, wikis are not actually perfect, but so much less trouble to build because no time is wasted on the organizational malarkey. But they are eminently constructed of first pages.
Thanks for the comment, Tim.
Indeed, wikis do often have an Every Page is Page One vibe about them. Of course, there are large numbers of vendors and writers working very hard to change them back into something hierarchical. Some people just can’t leave miscellany well enough alone.
Pingback: Every Page is a Landing Page | Spectate
Very much agreed on the main point, that each page should work well as a landing page. However, it’s still worth spending time creating good links from the main product documentation or support overview page, as that may well be the most frequently visited page overall. People even bookmark these pages sometimes!
Also, it’s not only other people’s searches and links that make our pages rank highly. Our internal links play a role too, especially the ones from the main overview page.
As for hierarchy, for sure it doesn’t seem that many people patiently drill down from a very general page to a slightly less general one, through a basic one that covers something they already know, to finally arrive at the specific one they need. However, a hierarchy is one way to visualize related links. For example if people land on a straightforward task, they might want to view a related advanced tip or an overview. A hierarchy won’t cover all the needed links but it could help with some of them. (Whether the hierarchy is actually baked into the technical architecture is another issue.)
Hi Joe, thanks for the comment.
I’m with you on links, absolutely. And I think one can create an overview page without making it the root of a hierarchy. It can work just as well as the center of a web (insofar as a web can be said to have a center, as opposed to having one or more hub nodes with a particularly high link density).
I also agree that a hierarchy can be a useful navigation tool. In that sense, I would prefer to see multiple potential hierarchies that express different navigational strategies, rather than one fixed hierarchy that expresses one person’s view of the information architecture. Generally speaking, I am in favor of providing every kind of navigational aid we can, and therefore a great believer in generating both links and hierarchies automatically, since this allows us to produce a richness and variety of navigational aids that we could never create by hand.
One of the things I am beginning to realize is that there tends to be an inverse relationship between hierarchies and links. That is, the more strongly hierarchical a web site or doc set is, the fewer internal links it contains. I suspect that the reason is that a manually designed and constructed hierarchy makes link creation and link management very expensive. Certainly the big non-hierarchical sites, such as Amazon, Google, Facebook, and Wikipedia seems to exhibit a much greater link density than hierarchical sites such as newspapers or many doc sets.
You can get rich links without hierarchy by crowd-sourcing, as Wikipedia does, but I more and more suspect that the only way to have both hierarchy and links is to generate them both from metadata (the way SPFE does).