The Design of This Web Site

Last updated September, 1998

The Site, Version 3
You are now looking at the 3rd version of my web site. The new design was implemented over a several weeks at the end of the summer of 1998. I've been working on the web and creating web pages for more than two years now. The new site is based my exeriances and understanding of the web.

The biggest change is that I removed the frames from my site. While I had valid reasons for using the frames (see below), I now feel that they are more trouble than they are worth.

Frame Problems:
First, they require at least one (and in my case 2) additional files for each web page. Even though the additional files are small, and require minimal changes, extra files are still annoying to deal with and add additional errors to the process of updating a web site.
Second, they are slower for web servers to support and slower for web browsers to display. It is much easier for all the software invovled, if a single web page is displayed when a link is activated.
Third, new software (like HomeSite) has made updating and maintaining web pages easier than before. The process is not anywhere close to being simple, but it is easier than before. Forth, there are various small annoying issues with cross-browser compatability which constantly frustrate my efforts at getting the framed pages to look right.

Frames - Why I (used) them
Note the following section is from my Version 2.0 web site. I leave it here for historical reasons, and because my reasoning was valid, but not complete.

This is the one aspect that I spent the most time wrestling with. I have a great deal of sympathy for Jacob Nielsen's arguments against the use of frames (here is his essay on the topic). Despite this, I still have a frame based web site. There is one main reason I use frames: simplification of code. In the "C" language you can include common files in a host of other special purpose code files. To my knowledge, there is no equivalent function in HTML. What I want is to create a file that describes my navigation interface, then include that file in every one of my web pages. When I need to make changes to my navigation interface, all I change is that one file, and all my HTML files reflect the change. As far as I can tell, the only way to accomplish this in HTML is to use frames.

Without frames, I would have to manually add all my navigation code to each HTML file. And I could never change it again, not without editing each and every one of my files. I'm not the first person to discover that a database is the correct method for maintaining HTML files, but until such a product appears, most people will have to do this work by hand (I am aware of Oracle's efforts in this area).

I think my solution solves the major problems with frames for a reasonable cost. What I have done is create two HTML files for each real file on my site. One file is the real file containing interesting text, the other file is a frameset file that defines the frames I use. This is how I include my navigation code. Most sites just use one frameset file but I use many. The reason is that the frameset file determines the title that appears in both the title bar and the navigation field of the browser. If you use only one frameset file, to the outside world it seems like you have just one file and bookmarking specific pages is impossible. By contrast my site seems to be composed of a normal set of files, each with different titles, each bookmarkable.

The costs to this solution are: 1) more files and 2) annoying screen redraw for each page.

More files: Obviously I have twice as many files to maintain. However the frameset files are very simple and almost exact clones of one another.

Annoying screen redraw: This is very irritating, sites that have just one frameset file feel better and take less time to redraw. However, there is every reason to think that the redraw of my navigation frame will occur entirely from the browser's internal cache (after the first time) which should be a very fast operation.

The Navigation Interface

I spent a lot of time working on the navigation element. I think a constantly available navigation interface is very valuable in a web site. It allows the user to feel confident they can return to a known location at any time (because of my use of framesets, the Back button is also available).

The Encarta 95 Interface

I like the Encarta 95 style of interface. What I really like is the subtle active screen of Encarta 95. When the mouse cursor is hovering over an item that can be clicked, the appearance of the item changes slightly. This provides a visual cue that the specific portion of the interface is functional. JavaScript allows this to be done fairly easily but only for links. As you can see, I implemented this within my navigation bar (but not elsewhere in the web site, too much work).

The Next Item

The use of a "next item" link at the bottom of each page I find very appealing. I borrowed the idea from the London Times. The London Times uses this to very good effect, allowing the reader to go from story to story, without having to continually jump back to a higher level "contents" page. Compare the London Times to the New York Times and I think you will find the London Times offers a superior browsing experience. There are costs involved with this. The main cost is that every time a new page is added, the number of related pages that must be updated is one more than would otherwise be true.

Use of Tables

I like David Siegel's ideas and one of his important ideas is the use of tables to format text on the screen (that and his use of the invisible GIF file to space things out). I don't use tables to the extent David does, but he is right, if you want to control layout, you need to use tables. I recommend the web site for his book: Creating Killer Web Sites.

Go on to the next page about User Interface Books.