Using Social Media to Improve your site

Organizing Your Site

Ever dream of staying up nights hunched over your computer, building a Web site that will make your boss or some other multimedia mogul fall in love with its money-making potential and offer you millions to produce it on a regular basis?
Well, stop right there. Turn off the machine. Sit back, relax, and think about what you're doing. What is this dream site you're building? Justify its existence: What content will you present? How will people use it? Why is it valuable? Once you have a purpose and an organizational structure, you've got to design the backend.
Ask yourself: Is the information you want to present dependent on time, issues, or subjects? Do you care about archives? The answers to these questions will determine your file structure. If, for example, you want to create a Web site for a monthly print magazine, you probably want to organize your backend by issue number.
But if you plan on expanding this site beyond the print version - for example, adding a special weekly column that only appears on the Web site - you may want a time-based structure. If the site is subject-based, think about how you want your readers to use this information, and what you might add later on. Be ambitious and plan for the future.

How HotWired does it
Because it's really easy for me to do so, I'll use HotWired to describe the dos and don'ts of backend design. Our system is by no means perfect, but we are quite huge, we publish a wide variety of content each day, and we use the three obvious organizational categories I mentioned above: time, issue, and subject.
I'll use Pop to demonstrate how our backend has evolved over the past two years. When HotWired launched two years ago, Pop was called Ren2.0, but they later shortened it to Ren, and then expanded it to Renaissance, before settling on Pop. Each time the section went through a name change, the folder structure also had to change to keep the URL accurate, but all the archived content still needed to be grouped under the most recent design of the site.
When it was called Ren, the channel contained five programs: Kino, Retina, Serial, Soundz, and Twain, and the content was located in one big messy folder. When new content went live, old stories were "archived" in an "invisible" folder on our server called Old.INV, which hid the stories from the world at large (some of them are still hiding in the bowels of HotWired, probably never to be viewed by a browser again).


Since this structure didn't allow for easy archiving or growth, we redesigned our backend in mid-1995, cleaning up as much old content as we possibly could, and moving forward with a solid organizational structure that lent itself well to archiving, permanent URLs, and program independence. (Permanent URLs allow readers to bookmark a URL and always find the same content there, even years later; program independence allows sections, such as Pop, to maintain a completely independent file structure, with all their own images and text files.)
The first step in our reorganization was to lowercase and standardize every file and folder name. Case is extremely important, because, depending on what type of server your site is on, a lowercase "a" can be an entirely different animal from an uppercase "A."
To keep things consistent and simple, use lowercase letters for all folder and filenames. Servers tend to get confused by strange filenames, so be kind to them. Don't use spaces or questionable characters (like |, &, *, (), %, etc.) in your filenames. Your webmaster can give you a full list of good vs. evil characters. Only use periods before the extension, and don't include more than one extension in your filename.

    Do: my_dog_fluffy.gif

Next, we moved all programs to the document root level. (At HotWired, sections like RGB Gallery or Web 101 are defined as "programs.") In, the last part, /program/ is at the document root level.


Every Pop program has the same basic structure and naming conventions. Images that are used from week to week are kept in a top-level images folder. Navigation, archive, and login information are kept in program-level folders. This allows us to update copyright and navigation information for an entire program with one easy step. We use server-side includes to insert this information into each page from one central file: /program/footer/navigation.htmlf.
New text and images are organized by year and week, even though many sections are updated daily. A week's worth of files is still a manageable amount of content to deal with in one folder. To distinguish between each day's content, we assign a version number and letter to each file:

    indexNa.html where N = 0-6, representing Sunday through Saturday and a = a-z, denoting the version that went up that day. So Monday's index page is index1a.html.

This structure allows for permanent URLs, but they're fairly cryptic:

As useful as it is to us, we can't expect our readers to know or care about our file structure. So we keep our public URLs simple and link them to the most recent content. So when you read Dream Jobs today, at, you really read the content stored at
This is called a symbolic link. In Unix, the command is:

    ln -s /hot/www/program/96/44/index1a.html /hot/www/program/index.html

This brings up the question of absolute versus relative URLs (relative URLs are abbreviated; they're used to link between pages within the same site). To reduce carpal tunnel syndrome among multimedia production people, it would be ideal if everything could be relative, but sometimes you need to include the full pathname. For example, when a link is created from /hot/www/program/96/44/index1a.html to /hot/www/program/index.html, the index.html is "living" in a different location. The index.html thinks it can find its GIFs in /program/stuff/, but /program/stuff/ doesn't exist. The GIFs really live in /program/96/44/stuff/.
You shouldn't go much further than this with absolute paths because you want to keep your files as portable as possible. Perhaps someone will be interested in purchasing or hosting one section of your Web site. The section should be as independent as possible from the rest of your site; that way, you could basically copy the program folder to a completely different server and the links would all still work.
We use the other two organizational types - issue and subject - for Wired magazine and Rough Guides, respectively. The Wired magazine archives are organized by issue number, and the Rough Guides are organized by country and region. The backend designs of these sections are quite simple, because they don't change on a regular basis and don't need to be archived, per se.
HotWired's backend is by no means the end-all-be-all of file structure existence, but it's a good example of how to set up a fairly expansive Web site. The most important rule is to indulge your laziness. You want a site that's easy to update. Consistency and organization will make you a happy and perky production drone.

by Pam Statz, Copyright © 1994-2010 Wired Digital Inc. All rights reserved.

SocialTwist Tell-a-Friend