Re: A small demonstration comparing web pages generated dynamically

Dear Charles,

You've help me alot, so I hope this does not cause you any embarassment!  Your site, http://www.ucitd.com/ does not open when on a Macintosh using MSIE 4.01!  Instead of browsing, I get prompted to "Save downloaded file to".  (The saved file is, of course,  ascii html.)  I even tried browsing (directly) to http://www.ucitd.com/index.cfm?type=text but got the same results.  (..index.html and ..index.htm just got 404 errors.)  Navigator (on the Mac) does not have this problem.  Can anyone else on the list confirm this behavior?

Bruce Bailey


----------
>From: "Charles F. Munat" <charles@munat.com>
>To: "Scott Luebking" <phoenixl@netcom.com>, <w3c-wai-ig@w3.org>
>Subject: RE: A small demonstration comparing web pages generated dynamically
>Date: Sat, Nov 13, 1999, 6:33 PM
>

>[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 Monday, 22 November 1999 13:03:27 UTC