a jaundiced eye: Hierarchy in Site Architecture

a jaundiced eye: stuck
for friday, april 25, 1997.

Hierarchy in Site Architecture

[Hierarchy is] ... a ranking or ordering of abstractions.
Grady Booch, Object-Oriented Analysis and Design

I'm sure there are thousands of web designers out there who still haven't quite mastered the art of creating directories (or "folders", as they are known on lesser systems.) It's evident from the enormous number of sites whose entire set of files is living in the root directory. Directory trees are examples of hierarchies, but not always good examples.

I'm not suggesting that everyone go out right now and create a bunch of directories just for the fun of it. There are several guidelines which govern the proper use and management of hierarchy within a web site, which I'll discuss in a moment. But first, a brief rundown of the concept of hierarchy itself.

As Booch is quoted as saying above, hierarchy is a "ranking or ordering of abstractions". Abstractions are what we have left when we stop talking about what is there now, and start talking about the essential qualities of all stuff of that type - past, present, and future. This is helpful when trying to differentiate between objects and to determine their relationships to one another. The big problem comes when we have zillions of ways to break something down into its essentials (a process known as "decomposition".) It can get tricky. It's astonishingly easy to get sidetracked on unimportant distinctions.

Hierarchy in site design can occur in two ways - the user's experience (logical/navigable structures), and the webmasters' experience (physical/filesystem-oriented structures.) Because of the flexibility accorded us through the use of hyperlinks, we can create multiple logical structures for a single underlying physical structure. Site Maps are a good example of this, as are archives (or even searchable indexes, though that's a bit of a stretch for this context.) The key is to create a physical structure which allows for scalability, manageability, and the most "intuitive" experience for the author who needs to dump their files somewhere in your structure.

So on to the guidelines, with a brief illustration of each guideline in action.

1. always think of the user when making top-level directories

I'm stretching the definition of user here. I'm not only talking about the visitor to your site, but also anyone in your organization who is going to use the URL for business cards, marketing collateral, etc. "/webpages/" is redundant, since you're not likely to find anything else there. Think in terms of functions, services, topics, concepts.

2. Periodicals may be dealt with in terms of time

If your content is periodical, use time to organize it. This site uses the date which an article was published to determine its placement in the archive hierarchy. For example, this article will live in

<a href="/stuck/archive/042597/article.html">

3. Properties of content are not always the best candidates

If your site discusses cats, when do you break out "polydactals" from "normal" cats, for example? How to deal with "mixins", where you have a polydactal elderly black cat? Which top-level physical directory to put these files in? The Hierarchy reaches its peak usefulness very quickly, and must be replaced by more flexible methods.

4. Pick an organizational method and stick to it

You can always create alternate logical overlays which provide more effective access to your information. Don't fall victim to the urge to redesign the site every time you realize something different about the relationships your content has to other content.

5. Org charts are bad

When dealing with infrastructure, like an organization's business unit breakout, don't use the current org as a base for hierachical directory structures - the next reorg that hits will cause you nothing but grief. Use generic topics, like "services" or "functions", or you could use a "task-based" breakdown, such as "who do I talk to in order to report a bug in your software" or "how do I sign up for your magazine"?

6. Use short, easily remembered monikers

It's much easier to remember (and type) "/new/" than "/WhatsNewHereThisMonth/". Both for you and for your users.

7. Included stuff should be sorted by type

If the user will rarely, if ever, see these directories (because they contain stuff that is included in other documents, but never accessed directly) name the directories after what they contain. "/classes/" for Java class files, "/javascript/" for included JavaScripts, "/cgi-bin/" for CGI programs, "/includes/" for Server Side Includes, "/images/" for image files, and so on.

8. Tunnel vision helps

Make sure that you organize things so that you don't have too much cross-referencing going on between directories. If you have a spaghetti-like link structure, your decomposition has failed - and you will have a hard time moving stuff around in the future. Keep links in one area pointed at documents in that area, or back to the top.

9. Keep related files together

A common mistake is to create a single page for a concept, then realize there is too much information related to that concept, in multiple files, to keep track of it in a single top-level directory. Make subdirs for these files. I could have used "042597.html" for my archives, but I may want to use multiple-file articles in the future. So I named the directory "042597/" and now I can stick more stuff in and keep it together.

10. The Rule of Threes

For directories that users will deal with directly, keep it down to three deep or less. If you need to go deeper, use easy-to-remember naming schemes, based on natural language structures. "/stuck/archive/042597/" is just an example of this, although it could probably have been clearer :( So I provided a top-level "/archive/" listing from which all articles can be referenced. Shifting contexts allow for deeper structures, such as with phone numbers. You can usually remember the area code, and sometimes the exchange, so it's okay to focus on the last four digits. There are exceptions to every "rule". :^)

I'm sure there are a few I missed. If you have some experiences to share, let us know.

Steven Champeon

r e c i p r o c a t e

Permanently archived at: http://www.jaundicedeye.com/browse/stuck/042597/