RE: A small demonstration comparing web pages generated dynamically

[Scott Luebking wrote:]

I've set up a demonstration of how two web pages can be generated
dynamically each with a presentation tailored to a particular
type of user.  The URL is:

    http://members.aol.com/criptrip/dynamic_web_pages


----

Scott (et al):

I've been doing something similar for about a year now using Cold Fusion. You can see an example at

    http://ucitd.com

Although the design of this site is less than ideal (e.g., the text-only link is below the main text, not at the top of the page), you can get a dynamically generated text-only page by selecting the text-only link. Because the text is pulled from the same database, the two pages are actually one and the same, so there is no problem with one getting out of synch with the other.

What I believe you'll find more interesting is my approach to accesskey use. At the bottom of the page you should see (on IE4+ only) a link that says "k = Activate Hot Keys". You can either select this link normally, or use the accesskey (k, of course) to activate it. Doing so reloads the page with accesskey attributes added to all links.

As the page is generated, the code creates a list of accesskeys for that page. With accesskeys active, you should now see a link at the bottom of the page that says "x = Show Key Index". This link adds an index of the accesskeys to the bottom of the page. Accesskey 9 can then be used on any page to scroll to the index.

Benefits of this system:

1. Default for accesskeys is OFF. Except for the k key, none of the keyboard shortcuts is overridden. I picked K because on IE it is not used and because it stands for Keys (I've also used J for Jump on some sites).

2. The k key acts as a toggle to turn the accesskeys on and off. The x key toggles the index on and off when accesskeys are active.

3. Because the index is appended to the page, this works even with JavaScript disabled. Also, it avoids a pop-up window. Having the index toggle function means that expert users can turn the admittedly ugly index off. On a site like this one, there will be no expert users except the site owners, but on a portal or other large site, this might be useful.

4. Because the index is generated dynamically, it is always accurate. It's possible to accidentally set two links to the same accesskey (in the database), but it wouldn't be too hard to rearrange the system so that the accesskey column is the primary key. That would eliminate accidental duplicates.

5. Anyone can use the keyboard shortcuts, including those without disabilities (like the site owner or me... I use them all the time).

Drawbacks:

1. State is maintained via a cookie. If the user refuses this cookie, each page will revert to defaults (images and accesskeys off). Of course, the server uses a browser sniffer, so text-only browsers and browsers like pwWebspeak will automatically get the text-only version. But the accesskeys (were they available in those browsers), will have to be reactivated on each page.

This isn't really a problem currently, because the accesskeys only work in IE4+, which also accepts cookies. And the site's privacy policy clearly states that cookies are used only to maintain state (no sneaky stuff).

I could get around this by appending type=text to the URLs on all site links, but that would screw up the search engines (they generally don't follow links with ? in the URL). If I were using AOLServer or similar, I could do this without the ? in the URL, but I'm stuck with NT and Cold Fusion. I'd like to work out a similar system using AOLServer on Linux with mSQL or something similar, but haven't had the time. Perhaps someone already has. It would be easy to do with TCL (and I'm very interested in the possibilities of Rebol).

2. There is still a learning curve associated with the shortcuts. I believe that the best solution would be a standardized set of accesskeys used from site to site for common pages, with a variable set for special pages. In the meantime, this system works.

3. Because I'm doing the work on the server, the page must be reloaded for changes to take place. Then again, this makes it cross-browser compatible and not dependent on JavaScript or JScript (but see proviso about cookies above).



I've put a lot of thought into this, but I'm always willing to hear suggestions for how to improve it. 'Course I'm stubborn, so I may persist in my ways despite those suggestions...

Charles F. Munat
Munat, Inc.
Seattle, Washington

Received on Saturday, 13 November 1999 18:33:52 UTC