[Sigia-l] URLs must live forever? Poor man's content negotiat ion?

[John McCrory]

Art Ludwig wrote:
> I'm also eying the .htm at the end of every file 
> on the site and wondering...what happens to
> links when all these pages evolve beyond .htm?

The issue Art Ludwig raises can be solved with the site's error (404) page.
Say you move from .htm to .asp in some or all of your pages; i.e.:
	....//www.anysite.com/thisweek/thursday.htm
becomes
	....//www.anysite.com/thisweek/thursday.asp
On the error page, a short server side script can redirect any request for a
url ending in ".htm" that does not exist to the same url but ending in
".asp" (Coincidentally, Dan Benjamin just put up such a script this week on
his HiveLogic web site: http://www.hivelogic.com/229.html ). 

The error page can also provide one possible solution to the general issue
of "dead" urls; program the error page to catch "dead" urls and redirect the
user to the new page or the closest thing to it. You can choose to redirect
the user seamlessly or to provide a message explaining why the URL is gone
and then redirect or offer a list of related pages for the user to choose
from. (From our site's experience, btw, our users seem easily discouraged by
404s but stick around longer if they are invisibly redirected.)

There are other ways to do this kind of automatic redirection, but I find
using the error page most useful because each redirect is recorded in the
site's log file. As others have pointed out elsewhere, examining a web
site's log file for the errors is an excellent way to research problems
users are having with the site -- and to measure the effects of improvements
or changes you make. 

Example: for some of our organization's programs we created "shortcut" urls
that automatically redirect to the program's actual main page. The actual
page has a long url that is hard or impossible to remember. The shortcut
url, such as www.somesite.org/programname, can be printed on brochures,
billboards, in e-mails, and spoken easily over the phone. 

Instead of creating a dummy page at that url, which would be too cumbersome
for lots of shortcuts, we programmed the error 404 page to catch any
requests to the shortcut urls and redirect seamlessly to the proper page. 

So far so good. Yet shortly after introducing these kinds of shortcuts, we
noticed in our web site's log file that some people were getting the error
page because they typed the shortcuts in as www.somesite.org/Programname,
www.somesite.org/programname/ or some other variation, including
misspellings. About half of those people retyped the url until they got it
right, but half (or about 8 percent of the program's total visitors) simply
gave up. So we re-wrote the error page script to be more forgiving of a
range of variations and mistakes. After this change, virtually all of the
visitors using these shortcuts were reaching the programs they were seeking.

To those of you for whom the above is obvious, sorry to be so long-winded.

   John McCrory
   Webmaster 
   Vera Institute of Justice
   http://www.vera.org/