University Web Services
Best Practices
Reasons Why
This page is a reference for the various best practices with explanations as to why certain specific practices were chosen. They are listed here in no particular order.
Use the Trailing Slash
Reference: Naming
Every anchor links to a specific file name, and that file name is separated from the directory name by a forward slash. The server will append the default file name when no file name is specified, so if you leave the slash off, the server has to do a redirect to add the slash for you. This creates extra work for the web server and creates two entries in the server log file: one for the initial call and one for the redirect. Here is an example.
Without the trailing slash, your link to
http://www.boisestate.edu/webcenter
actually translates to
http://www.boisestate.edu/webcenterindex.shtml
which is obviously not valid, so the server has to redirect by putting a slash after webcenter. But if your anchor reads
http://www.boisestate.edu/webcenter/
then the server simply delivers the index.shtml file with no further work.
Avoid Punctuation in File Names
Reference: Naming
The logic here is the same as for blank spaces, except that the hexadecimal codes are different for different symbols.
Why no underscore? Because of print. Because when a url appears in print it very often appears underlined. Depending on the printer and on the font, it can be nearly impossible to distinguish whether there is a space between words or there's an underscore buried in that underlining. By avoiding underscores, you avoid ambiguity in print.
No Blank Spaces in File Names
Reference: Naming
Blank spaces are not coded the same by all versions of all operating systems. Servers therefore change a blank space into its hexadecimal equivalent, which looks like this: %20.
Example: an address that you think looks like this:
mydept.boisestate.edu/programs/2007 events/our 75th anniversary.html
Will for some people look like this:
mydept.boisestate.edu/programs/2007%20events/our%2075th%20anniversary.html
Best practices says that we should avoid complicating the user's life without good reason. Our own convenience and work habits do not add up to a good reason.
Directory Structure and Naming
It should be obvious why it's a good idea to put all styles into the same folder, all includes into the same folder, and so on. In very complex sites, it is okay to make subfolders within those.
Less obvious is why put all images into a single folder. One reason is pragmatic: when downloading a site to a local drive, sometimes you want to upload/download the html files but don't want to take the time to transfer the image files, especially when there has been no change in the image files. If those files are scattered among the html files, it will be much more difficult to do this. You will usually just wind up transferring everything, which is a waste of bandwidth, which in turn is a violation of university policy.
Another pragmatic reason: you will certainly want to have a local copy of all your images. If they are all in one folder, you can more easily use your desktop computer's "thumbnail" capability to preview the images and make the proper choice of file name.
Perhaps still less obvious is why separate other non-html documents. The reasons are more or less the same: manageability, lower overhead during file transfers, and ability to preview files locally. As with styles and includes, you may find it convenient to make sub-folders within your /doc or /pdf folder, if you wind up with a lot of these files.
Standard File Names
Reference: Naming
There's no strong reason to choose these file names. They are simply the names that occur frequently on the World Wide Web. Since the choice of name doesn't matter here, we choose one commonly used and stick with it.
SHTML Naming
Reference: Naming
The file extension is required because we have chosen not to enable processing of includes from the .html extension. This choice was made for security reasons.
Poster Layout Deprecated
Reference: Naming
Fixed-width (and fixed-height) layout is deprecated because this layout approach is too device-dependent. It looks best at a certain number of pixels and does not do well on small-screen devices or at high resolutions.
A common criticism of completely fluid design is that it creates too-long line lengths on high resolution monitors. A common fix is to use a max-width value in the stylesheet to address this.