Organized website structure is a must in web design

Organized website structure is a must in web design and the information architecture in general is concerned with grouping and organizing labels into a taxonomy a hierarchical and cohesive vocabulary of categories and subcategories. The topics belong together, and any attempt to break them apart into different categories would only muddle the hierarchy structure. Categorizing, the first step in creating a logical and intuitive hierarchical navigation system, is all about finding patterns and relationships. The information we gather here is termed metadata data about data. We are determining what data we have and how it’s all related in an overall schema.

Choosing appropriate categories is, to some extent, plain old common sense. Still, categories aren’t always obvious. Some labels may seem not to belong in any category except “miscellaneous stuff.” Other labels might belong under multiple categories. And some categories are so large that they beg to be broken down into subcategories and sub-subcategories. Such categorization is indeed both a science and an art.

Many designers find it helpful to put all possible labels on index cards and then perform a card-sorting exercise to group them by category. It can even be helpful to ask two or more designers to sort the cards independently to compare the similarities and differences in their groupings.

Categories can provide context for our content. Let’s say we see a menu item labeled “Trains.” If that item falls under a “Vehicles” category on the menu, it’s safe to assume the trains weigh many tons and go very fast. If it’s under a “Toys” category, it’s going to be small, cheap, durable, and appealing to children. If it falls under a “Hobbies and Models” category, it’s still going to be small, but now it’s likely to be fragile, very expensive, and appealing to model railroad afi cionados. Without knowing the context of the “Trains” link, visitors could very well be led astray.

This overlapping of categories is one of the reasons they are tough to develop and often somewhat ambiguous. Let’s look next at a bad example of categorization. A large retail photography site breaks its products down by “amateur” and “professional.” Well, what about the “amateur” who is perfectly willing to spend big bucks on professional equipment? Will that visitor tolerate going through the entire amateur line before discovering that the equipment offered there just isn’t powerful enough? Perhaps it would have been better to group the products by price point, say “under $1000” and “over $1000.”

Most people, amateur or professional, have some idea of how much they are willing to spend before they hunt for a product. Consequently, categorization by price would have a better chance of hooking the buyer up with an appropriate product. The problem with the aforementioned photography web site is that the designers chose categories based upon the way they viewed the categories, not on the way a visitor might view the categories. After the categories and their associated labels are chosen, we can start arranging the site into a hierarchical site plan, with major categories at the top, subcategories underneath, and sub-subcategories and labels under that. What we are designing is essentially a multi-level table of contents for the site.

Organizing Site Structure for the Developers

The more thought you put into planning the structure of the site from the developer’s point of view, the less likely you will be to have to reorganize the structure later. “After the fact” reorganization of directories and fi le names is not only timeconsuming, but it also runs the risk of breaking links. That is, if visitors have bookmarked pages on your site before the reorganization, or external sites have included links to your pages, those bookmarked and linked pages won’t be found after the reorganization (so-called linkrot). Links from search engines to your site will also be broken until the engines have discovered the changes. Creating a site structure involves organizing fi les and directories on the server, establishing standard naming conventions for directories and fi les, and using relative instead of absolute addressing.

Organizing Files and Directories on the Server

As soon as a site exceeds just a few pages, it becomes unmanageable to cram all site fi les into a single directory (also called a folder). Instead, create a directory structure that follows your carefully crafted site-architecture hierarchy. Just as you have a home page with several main pages underneath it, so too can you create a home directory with a subdirectory under it for each of the main pages. For larger sites, you might want subdirectories under main page directories, just as you have subpages under main pages. It’s become standard practice to provide high-level CSS, JavaScript, and image directories for elements that are reused throughout the site. Additionally, each main subdirectory might have its own subdirectories for those elements that are unique to just that area of the site, as shown in the example in the sidebar.

Establishing Standard Naming Conventions

You must also set up a standard format for directory and fi le names. All lowercase? Mixed lowercase and upper case? If mixed case, do you capitalize the fi rst letter of each word (“NavShoppingCart.gif”) or just the words that follow that fi rst word (“navShoppingCart.gif”)? Or should you instead use underscores to separate words (“nav_shopping_cart.gif”)? It may seem like a big decision at the moment, but actually, the convention you choose is much less important than your consistency in following it. Many web servers are not tolerant of spaces and special characters in folder and fi le names, so stick to letters, numbers, hyphens, and underscores. Folder and fi le names should be chosen to mean something to the developers who are trying to wend their way through the maze. A file name like “aa123” is worthless in that respect, while one like “navBar” is helpful. You might want to use a prefix, based on general purpose, for each type of file, such as prefacing all navigation images with “nav” or all logo images with “logo.”

As a result, all files with a related purpose are grouped together on any listing of fi les in the subdirectory. It’s tempting to name images by visual attributes, like “navBlueButton.gif.” The downside here is that visual attributes might very well change as the site evolves. For instance, “navBlueButton.gif” becomes an inappropriate and confusing name if you later decide to recolor all the buttons red.

Better to name images by function, not by visual attributes, because the function of a graphic usually remains constant. “navGoButton.gif” is valid regardless of the button’s current (or future) visual characteristics. It’s equally important to use similar standards for CSS class and id names. As with fi les, don’t choose names that refer to visual attributes of color or position. For instance, “blueBox” and “topNav” are names that can become outdated with even minor visual adjustments to the page. Instead, use names with structural meaning, names that reflect what the element does, like “mainNav,” “localNav,” “mainContent,” or “sidebar.”

Choosing Relative versus Absolute Addressing

Relative addressing means the link paths are set up to be relative to the directory where the current page resides. For instance, “images/gif/myButton.gif” exhibits relative addressing, in which the file is in the subdirectory “gif,” which is under the “images” subdirectory, which is in turn under the directory in which the current HTML document resides. Furthermore, using “../” at the beginning of the reference sends the browser up a level, so that “../../gif/myButton.gif” sends the browser up two levels from the location of the current page, and then down to the “gif” directory where the fi le is located.

Absolute addressing, conversely, means that each page is accessed independently, via the full URL. The absolute address for the aforementioned image might be “http://www.whatever.com/root/someSubCategory/images/gif/myButton.gif.” The problem with absolute addressing is that if you move the site, either from your local machine to the web server or to an entirely new web server, all the links break. Such moves necessitate updating every absolute address to point to the new location, often a time-consuming and error-prone task. On the other hand, relative addressing should work fl awlessly regardless of where the site happens to be located, as long as the site’s directory and link structure remain unchanged. Although you have no choice but to use absolute addressing for links to pages outside of your site, make sure to use relative addressing for all links to pages within your own site.