Notes on the Computer Science Web Site

Dana Nau

Last updated on September 17, 2001

This is the documentation for the Department of Computer Science's new web site, which was installed on September 9, 2001. At the time that I'm writing this, some of the pages on this site are still in the old format, but I hope to put most of them into the new format over the next few weeks.

The biggest change from the previous web site is that there are now two home pages: a "public" page at http://www.cs.umd.edu, and a "local" page at http://www.cs.umd.edu/local. People inside the department should probably bookmark the latter page.

If you notice bugs, send email to webmaster@cs.umd.edu. If you're using Netscape on a Sun and the web pages don't look right, try going to the "advanced" section of Netscape's preferences, turning off the "enable stylesheets" option, and then turning it back on.

The following three sections discuss (1) the design goals, (2) maintaining the site, and (3) other things.

1. Goals

When designing the new web site, here were the goals I had in mind:

A. Provide a "public" home page with info for external visitors

• Only include content that makes sense to external visitors.
• Make the appearance clean and uncluttered.
• Include attractive graphics, but make them small so that the page will load quickly even over slow connections.
• Include (at Larry Davis's request) items in the center of the page for prospective students and faculty.
• Include (at Steve Halperin's request) a link to the CMPS home page.
• Use real text in the sidebar, rather than gif or jpg files that contain images of the text.
• Organize the sidebar items in some logical fashion, and keep them in alphabetical order where possible.
• Try to make it clear what each item on the page page means.

• Include all the links that appear on the external page. In addition, provide things local users need.
• Provide direct links to everything (rather than requiring users to go through other intermediate pages).

• Provide a uniform look-and-feel for all pages on the site.
• Use colors compatible with the UMD logo (red, yellow, black, white), but try to create a more attractive page design than what I've seen on most of the university's web pages. (If you think I've succeeded, let me know!)
• Don't use frames.
• Make the pages usable even on small (800-pixel-width) screens.
• Try to make the page layout work for multiple web browsers and multiple platforms. One useful trick is to specify fonts and font sizes in style sheets rather than inline, and to use point sizes rather than pixel sizes.

• Try to clean up the directory structure for the site.
• Use modular structure for page elements, to facilitate updating of the pages.
• Design the pages for distributed updating by the grad office, the undergrad office, the computing staff, etc.
• Try to make it easy to edit the pages with both Dreamweaver and text editors.

2. Maintaining the Site

My main tool for building the new site has been Dreamweaver, a tool that is widely used to build and maintain commercial web sites. Larry Davis has agreed to buy our staff copies of Dreamweaver for use in maintaining the site.

In anticipation that some people may still want to use text editors to maintain the web pages, I've tried to make the site as independent as possible of Dreamweaver's special features. However, one thing that needs to be done differently than before is version control. On the old web pages, version control was done using rcs. On the new pages, it needs to be done as follows, depending on whether you're using Dreamweaver or not:

If you're using Dreamweaver, it will happen pretty much automatically -- Dreamweaver will mirror some of the site on your local machine, and will automatically create lockfiles on the server so that two people won't modify the same file at the same time.

If you're using a text editor, you'll need to do the following:

1. Create a lockfile on the server manually (e.g., "foo.html.LCK" if you want to edit the file "foo.html"). The lockfile needs to contain your real name, account name, and email address, in the following format:

   John Doe (doe)||doe@cs.umd.edu 

2. Make your changes to "foo.html".
3. Delete "foo.html.LCK".

This isn't as convenient as doing it in Dreamweaver, but it should be easy to make shell scripts that will create and delete the .LCK file for you. Once someone has created these scripts, the new process should be no more trouble than using rcs's "co" and "ci" commands.

Here are the advantages and disadvantages of the above approach:

With rcs, it's a pain to update files if your home machine isn't one of the department's Suns -- and it also is easy to forget to check out a file before working on it. Looking through the old site, I saw several instances where people had modified files without checking them out first -- and I know of at least one case where this caused a file to get updated incorrectly. For those of you who use Dreamweaver to maintain the new site, I'm hoping this problem will go away.

The biggest drawback of Dreamweaver's approach is that it doesn't archive old copies of the file, the way rcs does. If we're lucky, this won't be too much of a problem in practice. If you use Dreamweaver, you'll be debugging files on your own machine before uploading them to the server -- so if you need to restore an old copy of a file and you haven't uploaded your new copy yet, you can get the old copy from the server. If you upload your file to the server and then discover that you need to restore the old one, you may be able to get a copy of the old file from another user's machine. If this becomes much of a problem, we should be able to create a cron program that runs once a day and automatically creates rcs copies of any file that has been modified since the previous day.

3. Other Things

All of the included files (except for those that existed prior to the new site) end with the suffix ".lbi". The reason for this is that I had originally created them as Dreamweaver "library items," and I didn't change their names when I made them into server-side includes. In principle, these files could still be used as Dreamweaver library items, but Dreamweaver doesn't seem to recognize them as library items unless they're in /Library -- a directory that we use for the departmental library instead. I regard this as a bug in Dreamweaver, and intend to report it to Macromedia.

Text in sidebars. I've seen a number of web pages in which the text in the sidebar is done using images rather than real text. That's good for getting a layout that looks the same across many different web browsers and platforms. However, I think it's important to use real text, so that users can search the sidebar using their browser's "find" command.

For the text in the sidebars, I tried to choose fonts and font sizes that would look reasonable on many different browsers. It took a huge amount of effort to get this to work properly, and I'm still not totally satisfied with how it turned out -- but I think it's now close enough that we can live with it. The reason why this was a problem is that the same font-size specification will produce different-sized characters, depending on each of the following:

• whether one is using Netscape or Explorer;
• whether one is using a Mac, Sun, orPC;
• which PC one is using.

To try to solve this problem, one approach would be to use Javascript to figure out exactly which browser one is using (there's code available for this on the web), and to choose the font size based on that knowledge. However, I wanted to solve this without Javascript, for two reasons:

• the Javascript code is somewhat complex, and there can be problems getting even simple Javascript code to work correctly across different web browsers;
• some people (including me on occasion) do their web surfing with javascript turned off.

Instead, I used the following code (yes, I know it's a kluge!) in the header of every page, to get Netscape to use one style file and Explorer to use another:

 <link rel="stylesheet" href="/assets/styles/netscape.css" type="text/css">
 <style type="text/css">
   <!-- @import url(/assets/styles/explorer.css); -->
 </style>

In the two style files, I tweaked the font specifications until the fonts looked more-or-less acceptable on many different machines. If you look at the contents of the files, you might notice that the font sizes are specified in points in netscape.css, and in pixels in explorer.css -- this is deliberate.

No frames. I avoided using frames in the new web site (except that I kept the ones that perlcal generates for the departmental calendar). Our old home page used frames, but after receiving several complaints about this, I came to the conclusion that frames are a Bad Idea. For example, here is a link to an article that gives some reasons why.

No capital letters in most pathnames. The old site had a number of capitalized file names and directory names. My preference is to avoid such names. In the new web site, I have used lower-case names for all of the new files and directories that I created -- however, I have left some of our pre-existing directories capitalized in order to keep from breaking URLs that people may have bookmarked externally (e.g., /fs/www/Library/TRs and /fs/www/Grad).

No Dreamweaver templates, no Dreamweaver "library items". Dreamweaver allows one to create "template" files and "library items" that can be used as the basis for other files. This is convenient if you're using Dreamweaver, but not so convenient for anyone to edit using an ordinary text editor. Thus, to keep things easier for people who don't want to use Dreamweaver, I'm not using them (however, see my note about .lbi files earlier).

Getting things to look OK on multiple web browsers. It's very tedious to do page layout in html. The language was not originally intended for graphic design, and it's hard to get any kind of complicated page layout to look good in more than one web browser at the same time. One example is the problem with font sizes that I mentioned earlier; there are also several other similar problems. If you create a page in which and want to include it as part of the departmental web site -- and if you've used anything other than the defaults for your fonts and page layouts -- then you probably should test it under multiple browsers and multiple browsers, preferably including both Netscape and Explorer on Suns, Macs, and PCs.

Installing the new site. To install the new web site, I've done the following:

• Some of the pages that needed to be changed for inclusion in the new site are pretty static -- but others (e.g., Faculty.shtml) are files that people are updating pretty frequently. To prepare the latter for inclusion in the new site, I separated the content of the file from the header material, and put the content into a separate file (or several separate files) to be included in the header file using a #include. This made it possible to create pages in the new site that used #include to reuse the content of the old files.
• I created symlinks in /fs/www to the items in /fs/www/new. The reason for this was to help us keep track of what's new and what's old: the symlinks point to the new stuff, and the other files are the old stuff.
• I made a backup of index.html, removed it, and installed the .htaccess file described earlier.

In the future, I hope to do the following:

• Using tar, gradually make backups of the old files that we don't need, and remove them from /fs/www.
• Once the old files are gone from /fs/www, move the files from /fs/www/new into /fs/www.

Updating old pages. Some of the files in the web site (e.g., the files in /fs/www/Grad and /fs/www/Ugrad) still use the old format (the old banner, etc.). In most cases, these are files that are maintained by other people in the department, and it will be up to those people to switch the files over to the new format. To make this easier, I have created two template files for pages in the new format: one for a page with a sidebar, and one for a page without a sidebar. On the "local" home page, the "web-page templates" link points to a page that explains how to use these templates.