Useful Category Structure

At first glance building a category structure seems simple enough, but it will quickly become obvious that it is actually a key issue for any web site with significant depth of content. In many cases, managing the hierarchy of what belongs where becomes one of the major obstacles to a site's usability and can require seemingly disproportionate amounts of manpower.

To most, a category structure resembles a folder tree, as on your computer. Each folder can have contents of its own and each folder has a parent. This is similar to the visualization of a tree branch, hence the tree part of the term. While this might work well for organizing your files, it can be somewhat limiting as it provides only a single path to any given folder. Information and products frequently have more complex associations. It can be useful and in some cases very necessary to provide a more flexible means of defining the actual location of a given branch on a tree. Allow us to to illustrate with the following two case studies.

1. eCom-Jewelry
   eCom-Jewelry has two main ways to begin viewing their inventory on-line, by type and by material. By Type items being Watches, Rings, Bracelets, Necklaces etc... By Material being Gold, Silver, Platinum, Diamond and so on. Now given those starting branches, to continue the Tree metaphor, where would a gold watch be? In a physical store, unless you have have multiple inventory items for each item displayed on the sales floor, you would have to choose where to physically display the gold watch. In most e-commerce applications the same is true, you would need to duplicate records to be in two places at once.
2. eCom-Computers
   When the eCom-Computer company adds a new memory module to their inventory, the module only works with motherboards that support DDR-400 memory. How can the eCom-Computer company add a datasheet for the new memory item to all the computers that it works with without having to edit each computers web pages?

In either case, a hundred or more inventory items would make this a monumental task to keep track of and to update. In case #1 the only requirement is that items be in a logical place so they can be found, regardless of what path you took to get there. Duplicating content in order to place items in more than one path can become a nightmare to manage over time.

Case #2 is a bit more subtle as it has more to do with how other items can be associated with a given document or item record in addition to it's location. But with a little planning, both can be handled in a fairly straight forward manor.

The classic category method > > >