Recently, a number of people have asked me questions about directory structure for Intranets. Namely, what is the best way to structure folders and files for my site? This question is valid both in the macro sense of an entire Intranet as well as for each individual author creating their own little piece of the pie. So, I got to thinking about how effectively I set things up on my company's Intranet many moons ago. What do I recommend as good practices? What would I suggest avoiding?
Although it might not seem like that big of a deal, how you set up your folders and tree structure for your Intranet will have more impact on things along the way than you originally suspect. Believe me, to this day new questions arise that lead me back to either being happy about or ruing the way I structured my company's site. For example, user security, analyzing a sub-site's activity, and ease of managing files are just a few things that are dependent upon how the original directory structure was set up.
Now, let me tell you a little about how I did it and what parts of my set-up really work as well as those that I would do differently if I could. For the main web site, I have a top level folder (lets call it HTML) and from that all the sub-folders flow. For example:
|
|
|--HTML
|--Groups
| |--WidgetDivision
| |--images
| |--Department1
| |--images
| |--PDFs
| |--Department 2…..
| |--GadgetDivision
| |--nth Division
|--NewsReleases
| |--PressReleases
| |--OrganizationalAnnouncements
|--Publilcations
|--Human Resources
|--Cgi-Bin/Scripts
|--Search
|--Images
|--….more top-level directories…
Beneath this root folder, I have a separate folder for things such as news releases, publications, an executable cgi-bin/scripts directory, a search directory, and most importantly, a sub-directory called Groups. From Groups is where each of the business divisions' sites are housed. This allows for exponential growth within each of the divisions where each department or function can effectively have their own little section of the overall tree. This also allows me to handle security using NT local groups at the folder level. Within each of these different levels, I recommend having a reasonable plan for organization with common directories at the appropriate level for things such as: images and PDF files, to name a few.
In an attempt to avoid utter chaos, I do not allow any users to upload files or maintain their sites directly to the production tree. Therefore, the production directory structure is mirrored on the web server as an FTP site with write permissions. The security is maintained here at the folder level (using NTFS security) by local group so the Gadget Division's accounting department can't hose the marketing department's files and so forth. The same principal holds true between divisions. A scheduled job runs 4 times a day to synchronize the staging environment to the production.
Currently, decentralized authoring applies only to static sites and only the web development team (that'd be a whopping team of me) has access to the scripts directory and all the virtual directories that house real web applications.
Lessons Learned
What I have learned is that overall, my original directory structure has scaled very well. It has allowed me to grant and restrict permissions at various levels of the tree fairly easily. In addition, I can run analyses galore against the log files making just about any section of the site the "default home page" to get detailed usage statistics when requested. The staging directory with scheduled uploads to production is a fine way to take a hands-off approach to the day to day updating of the site. Keep in mind, however, that you'll never please everyone and someone is bound to be annoyed that they can't instantly "see" the changes to the site that they just uploaded.
An on-going challenge is determining the right level of granularity within the sub-directories for every site. That is, the crap shoot of striking the perfect balance between separating different types of files and topic areas into separate sub-folders versus one big sub-directory with everything but the kitchen sink in it. When in doubt, I've found a few extra sub-directories beats having an unmanageable mess. I've experienced both approaches firsthand.
Lastly, I've found that keeping very tight control over executable files and directories, and creating separate virtual directories for individual applications is a must. This approach works well from security, functionality, and maintenance viewpoints.
Since I'm certainly not a directory structure expert, but rather a person who happened to plan and create a directory structure that works well over time, I'd love to hear any feedback or experiences others have had. As always, drop your comments to me at paulag@enter.net.
Printer Friendly Version
The Author
P.G. Daly is Webmaster for the intranet of a large durable goods manufacturing company. In addition, P.G. writes for several online publications and does freelance web design and consulting. P.G. welcomes your feedback at paulag@enter.net
.