Runester

Halloween w/ Pictures

Well, it’s been a week since Lisa & I went to the Halloween party. We had a lot of fun! I drank some Tanqueray & Tonic; introduced some new people to “Bumble Bee” shots (1/2 Jagermeister & 1/2 Barenjager). Lisa & I danced like idiots (in the having tons of fun and not caring what other people thought about, sense) to a lot of “oldies” (i.e. music from the 70’s & 80’s)!

BTW: we both went dressed as Christmas Trees! [As soon as I get my hands on the pictures, I'll post them here for all to see.]

Web Site Navigation Automation

On a slightly more technical subject … I have been fretting about the correct (and easiest) way to build proper navigation schemes on multi-page web sites for some time now. After reading several articles, and seeing what other people have been doing - I can confidently say I am doing A-OK! Take a look at this site (one of the site’s I maintain as a volunteer). Though it looks pretty darn plane, the truth is I use a custom templating script (written in PERL, and heavily relying on the TEXT::Template module).

The part I am most proud of, is the left-hand navigation buttons. Believe it or not, those are auto-generated by my script! I have a special page description file, which lists what pages are in the web site, and which ones should be included in this navigation bar. Then, a little bit of PERL coupled with some simple JavaScript and … ta da! Looks as good as those FLASH or JAVA embedded object navigation bars, but it only takes seconds to load and should work in 97% of all browsers.

Still, just in case someone browses the site with a text only browser (and you LYNX users know who you are!) or perhaps a browser designed with special needs (such as Braille, or text-to-speech) I also include a simple list of links at the bottom of every page. Not only is the simple link list there for special clients, but they are much easier for most web spiders &/or search engines to navigate … as opposed to the JavaScript reliant buttons.

Some of the criteria I strove to achieve (for BOTH types of navigation menus) are:

There had to be some way to show the user where they are.

So I disabled the link that brought them to that page, and made it look different.

There had to be some way to show them which links were “active” or “clickable.”

The simple links were easy, normal HTML hyperlinks, and with the usual colors (blue & underlined).
For the JavaScript buttons, I used the standard “roll-over” effects to show the user what button their mouse was over, and which buttons could be pushed. [Again, this also reinforced which button was deactivated, thus suggesting what page they were on and how it related to the rest.]

It had to be easily usable by 99% of web users.

Well, I tested the page in both IE & NN, and have those simple hyperlinks at the bottom of the page incase any of the JavaScript stuff gets rejected … so everyone should be able to navigate from any page to any other page with ease.

It may not even be obvious to some readers why site navigation is such a big deal! Let me explain …

In every web style guide and interface usability guide I’ve read, offering clear, easy, compatible page navigation is emphasized as ABSOLUTELY VITAL. Further, they use statistic to make some recommendations. For example, “don’t rely on multi-frame pages. They are not as easy to print or bookmark, and may not be usable by people with older browsers.” So, one of the single easiest ways of building consistent, easy to maintain navigation menus (using a FRAMESET) is frowned up by the experts. And, while simple HTML hyperlinks are the easiest to create, use, and understand … they don’t look that pretty - especially when people are using FLASH &/or JAVA plug-ins to generate fancy roll-over effects, sound effects, or collapsible navigation trees.

For years I just stuck with HTML … and my sites looked plane (i.e. amateurish and ugly). This was frustrating, because I was following the usability guides! So, I believe the combination I describe above (JavaScript powered buttons, with simple HTML links as a backup) offers me the best of both worlds. Hey, it tastes great & it’s less filling!

A far bigger problem, then just the way navigation menus look, is keeping all of the links up-to-date on all of the pages. I remember, many years ago, trying my hand at a web diary … long before the BLOG craze (with it’s endless list of super-easy-to-use BLOG software) came along. I was just coding my web site, by hand, with NOTEPAD. My diary had two main navigation systems. There was an introduction page telling a little bit about me and my goal, with a nice calendar at the bottom (HTML Table), with each diary entry represented by a hyperlinked date. This was the “random access” method, you just clicked on the date and went straight to the diary entry. But, I also wanted a “sequential navigation” system, so I put links on the various diary entries. One link to jump to my home page, one link to jump to my diary welcome page, one link for the “previous” diary entry and one link for the “next” diary entry. [This is all very standard, and very easy with today's BLOG software including my own favorite: Blogger.com.]

If you are following along, you may realize, first, that my first diary entry would not have a “previous” link (how can it, there were none!) and, second, that my last page could not have a “next” link. But, of course, every time I added a new entry, the last entry would have to be updated to include a “next” link (pointing at my new entry). Further, my welcome page had to be updated so that the next calendar date became a link to my new entry’s page. So, every time I added a diary entry, I also had to edit my diary welcome page as well as edit the previous diary entry. All to maintain proper navigation between web pages!

This was the first time I realized that maintaining navigation links was a harder and more time consuming part of web site creation, then actually creating the content! I found this out, again, on a later project-based web site I tried to maintain. That web site had a hierarchical link structure, and adding a page meant I had to edit (and add links to) each page up the hierarchy. For example, take the outline below.

Now, suppose I want to add one more page to “Sub Area One Two,” like say, “Page Four.” Because of the strict hierarchy, and navigation on this site, I would have to also update the links for the sister pages as well as the mother page (as highlighted below). This means, add one page (with correct navigation links on it) and update four others! Of course, the more pages you add, the more you have to edit with each additional page, the more links to check and possibly break.

Ironically, none of these schemes are the worst. The single most common navigation scheme, especially for small web sites, is the “fully linked” navigation system. In this system, every page has a link to every other page. This method is what I used at the CBD web site. If I had to maintain all of these links, on all of these pages by hand … the task would quickly become unmanageable.

Note: This assumes that every page links to every other, including itself. That last option would also describe a “disabled” link used as a navigation aid to show users where they are on the site.

Did you notice that the total number of links grows exponentially with the number of pages on the web site? Each link is one more place to make a typo, and one more worry if you move, delete, or rename pages. I wish there was some magic bullet you could use that would just take care of this for you, and was easy for anyone, anywhere to use. And perhaps, with a full CMS (Content Management System) like Zope there is. But, for me and for now … I’ll stick with PERL and TEXT::Template. At least until I outgrow it.