|Common website directory organization.|
website folder organization
Say I have 5 content areas in mysite.com-
Should I make each a directory even if there is only one file associated with it?
Or would I only do this if I had more than one file to each folder:
1. company > contains founder.html and info.html
2. services > contains this.html and that.html
3. products > null
4. articles > null
5. contact > null
That makes sense to me but I could be wrong.
|When architecting a site, I try to think about how the user will approach the information and the ways and directions in which the site might expand in the future.|
For instance, I might be tempted to put articles in the root because there are only a handful of articles. In a few months, however, I may need to add "current" and "archived" articles, or maybe articles will need to be broken down by focus-- all Red Widget articles vs. all Blue Widget articles, or articles about ABC Widgets' new factory in Elbonia.
Or in the products directory: will you have only one page per product? More likely, as time goes on, you will add support pages, testimonials, media citations and reviews, sale announcements, and the like. If the company has only one product and one more in development, example.com/product1/ and example.com/product2/ is the way to go, but if you have ten products and only one page for each-- right now-- go ahead and leave yourself space to grow with example.com/products/product1/ instead of example.com/products/product1.html .
Why? URL stability, as much as anything else. I'd hate for customers who bookmark example.com/product1.html to have to switch to example.com/products/product1.html after a few months, and example.com/products/product1/ a few months after that.
On most of the static sites I have worked on, except for very small (<25 pages) ones, I've found no need to leave anything individual files at the root level except the home page, disclaimers and policies, and temporary "special announcement" files that will not be archived as a press release or event calendar might be.
Now, don't take this to mean you should make the structure artificially deep, either. I find shorter urls are more memorable and easier to promote in marketing literature than long ones (this includes domain names). Still, it's a matter of convenience to you and how quickly you anticipate a site will grow. Popular sections that must be located deeper in the tree for consistency can be made accessible through redirects (e.g. your brochure instructs the reader to visit example.com/redwidgets , which redirects to http://www.example.com/products/widgets/red/ ).
Thanks for your post choster-
|no need to leave individual files at the root level except the home page, disclaimers and policies, and temporary "special announcement" files that will not be archived |
Nice, that's what I was looking to hear. Of course, I might need clarification on one aspect- at risk of sounding thick headed.
How does the server treat index.html?
-I mean, if a directory folder with 4 files didn't have an index.html then the directory will appear on screen when accessing it through the url right?
So is it an issue at all when one of your directory folders doesn't have an index file - or is the problem taken care of through proper linking?
|How does the server treat index.html? |
It depends on how your server is configured-- and of course, index.html will sometimes be default.htm or home.asp or Default.cfm, etc. For security/privacy reasons, I add dummy index.html pages to all directories not meant to be browsed (for instance, /images or /cgi-bin) and where possible, have the server configured to redirect attempts to view that directory to an error page.
I can confirm from usage logs that users, at least more sophisticated ones, will experiment with urls if, for instance, a favorite link of theirs is broken. Therefore, I always provide an index page of one sort or another, even if the page will not be (for some reason) directly linked from elsewhere in the site. Your mileage may vary.
Regarding URL stability and all that, you might want to read
Cool URIs Don't Change [w3.org] by Tim Berners-Lee.
The key point for this discussion is that there is no need for the directory structure of your physical files to be reflected in your navigation structure as far as the user experiences it. You can use URL rewriting, redirects, dynamic scripting etc etc and have pretty much any URL you want for any given directory structure.
The key thing is URL stability so bookmarks don't die, and TBL says it much better than I can. Check out the article.
I'm on IIS 5 here. I disabled "directory browsing" very first thing. I still make an index.html page in each as a base page. That way when I link I do example.com/products/product1/ which will display index.html.
You can also, on IIS, configure your web folder for the default page be it index.htm, .html, .asp or default.*. I believe you can even add a page to the list, just an aside.
Here's another thread that touches on index pages in separate subdirectories, in addition to the question of subdomains:
PS: ergophobe - Thanks for the Tim Berners-Lee link. Excellent article. I'm half tempted to append the link to a lot of threads I remember that talk about file extensions, etc.
That's a great link and good information. Thanks for your help guys-