Flattening URLs
PROBLEM
The original architects of UCD's
web could be accused, in hindsight, of several design quirks that departments
are generally interested in fixing now. The most obvious ones are:
- Instead of Cardiology's URL - for
instance - being
just www.uchsc.edu/card, it was
www.uchsc.edu/sm/card - i.e.,
Cardiology belongs to the School of Medicine. While it is fine if SOM
claims Cardiology in their web's content, most people like URLs to be as short
as possible.
- Instead of using the customary
acronyms SOM, SOD, SON, and SOP for the Schools of Medicine, Dentistry,
Nursing, and Pharmacy, the architects chose acronyms of SM, SD, SN, SP. For
example, SOM's URL is www.uchsc.edu/sm
and not www.uchsc.edu/som.
- For
groups (schools, departments, divisions, etc.) that have an office of their
own, plus subgroups, the architects put the parent's group's files in a subfolder too,
along with the subgroups' folders. For example, SOM's web has many
subwebs like www.uchsc.edu/sm/card,
www.uchsc.edu/sm/pulm, etc., but it
also has www.uchsc.edu/sm/sm for the
SOM's web files. This was undoubtedly to keep the /sm level clean and
clear of individual files, but their URL suffered.
Another way this effect was implemented was to put a parent group's web in a
folder called "dept" - hence Psych's web is
www.uchsc.edu/sm/psych/dept,
not the more pleasing
http://www.uchsc.edu/psychiatry.
SOLUTION
To correct these ills we have been
"flattening" (shortening) groups' URLs if they wish. Parent organizations
need not worry that they are losing control: for instance, if Cardiology
changes their URL from /sm/card to /card, SOM can still refer to Cardiology as
belonging to them in their web content.
However, groups are generally not able to go "cold turkey" with respect to their
old URL - the old URL is published in papers, on letterheads, and on business
cards. The good news is there are ways to forward one URL to another.
The bad news is forwards are not completely transparent to the end user and his
browser.
FORWARD CHARACTERISTICS
There are at least 4 different ways to forward URLs (see
www.uchsc.edu/is/webdev/hints/forwards.htm for the technical details):
| user experience |
name |
pros |
cons |
forwards from |
forwards to |
forward message,
10 second delay |
HTML Redirect |
users know to update their bookmarks |
slow, annoying |
old home |
new home |
| immediate forward |
JavaScript |
transparent |
|
old home |
new home |
| immediate forward |
Custom 404 error handling |
forwards from every old URL |
|
any old URL |
new home |
| immediate forward |
Per file forwards |
forwards high-traffic pages to their new URLs |
doesn't scale up to hundreds of these forwards |
specific old page |
specific new page |
The method we regularly use is the JavaScript automatic and immediate forward; at
most the end users hears 2 clicks instead of one (IE users, at least), and they
might be confused by the URL in the address one-line box near the top of most
browsers - but they shouldn't be because URLs are often rewritten beyond
recognition on commercial sites.
It is possible to implement more than one forwarding technique.
Infrequently departments want both the JavaScript and the "custom 404 error
handling" methods. Infrequently they want a handful of "per file"
forwards. All three can be implemented on one web.
The biggest single issue that you should understand
about forwards is that in general they only forward from the old home to the new
home. For instance, if a user browses to
www.uchsc.edu/sm/urology and
Urology has moved to
www.uchsc.edu/urology, it will work just fine. However, if a user
browses directly to a page deep in Urology's old web, say
www.uchsc.edu/sm/urology/x.htm,
he will get a "not found". If this is unacceptable the "custom 404 error
handling" forwarding method can at least get him to the new home.
If even custom 404 error handling
is unacceptable - for instance, if said URL is published in a research paper, or
is a popular form has always been at a certain URL - a page at the old URL can
be left behind that forwards to the new page -
www.uchsc.edu/sm/urology/x.htm
can be a forward (i.e., it no longer has the old x.htm's content) to
www.uchsc.edu/urology/x.htm.
This is done in maybe 10% of the cases, and it is usually sufficient.
You can see that this method cannot practically be done for large numbers of
files because of excessive webmaster labor to set them up.
Also, if a web is being extensively redesigned as part of the move, some
or all of the new web's directory structure and file names may be different.
In this case forwarding deep into a web is difficult or impossible.
PROCESS
To do a complete job of flattening and otherwise modifying a department's URL,
the following steps are now taken:
- The department chooses a new URL,
optionally following the advice of IS.
- IS communicates with the department's webmasters so everyone is clear on
what is happening, and when.
- IS makes an empty web at the new URL.
We install FrontPage Server Extensions (FPSE) if the department uses
FrontPage, and we create FrontPage accounts for all webmasters of this
department. We adjust operating-system-level ownerships and permissions.
- IS copies their web from the old URL to the new URL. Note the old
URL remains untouched and in production.
- Next, either the department or IS
(negotiated) changes self-referential links in the new web to the new URL. This
is a slow process with FrontPage; IS has tools that accomplish this quickly, but the
department will have to DOWNLOAD their web from the web server before resuming
maintenance (we can step you through this). Note that use of relative
links avoids this problem (but GUI web editors, especially FrontPage, may
themselves not diligently create relative links):
- IS checks that the web at the new URL does not reference old URLs.
(Note that if this isn't checked, everything will appear to be working
correctly, but things will break when the old site is archived.)
- The department checks the new site and gives IS an OK to go ahead and
switch.
- IS looks for incoming links (we have tools), both internal and external,
and advises the owners of those webs that reference the department's web to
update their links. It does not matter if they are slow to act, because
of the forward(s) in place.
- Then it is safe for IS or the department webmaster (negotiated) to
archive and remove the old site, leaving a forwarding index.htm to the new
site. IS keeps the archive for a short period of time; if the department
wants long-term storage of the old web, they need to ask IS for a copy and
then archive it by some method (remember, backups are not archives).
- The department starts advertising the new URL and updating printed
materials like business cards and letterheads. All of their employees
need to be instructed to use the new URL in publications.
- After a year or so, IS will ask the department if they still want the
forward in place. It is not a problem if they do, but if they don't it
is
nice to clean up and move on. IS can provide last month's hit count on the
old URL, to make sure that use of it is tapering off.
Thus the department's web is never out of production. UCD's internal
search engine, www.uchsc.edu/search,
will re-index the new web site the next evening, and the external search
engines, like Google, re-index within a month or so (and meanwhile they still
have your old home indexed), so your audience can still search for your site and
find it.
SPECIAL CASES
In a few cases the new URL initially forwards back to the old URL, so the
department can start using the new URL before the web is actually moved.
The university has two community web servers,
http://www.uchsc.edu (based on Unix) and
http://www2.uchsc.edu (based on Microsoft). There is some forwarding
going on that makes these dual servers appear as one to the best of our ability.
These forwards need to be considered only if part of your web requires a
Microsoft web server.
There are a few departments that have non-UCHSC.edu domains; see "vanity
URLs".
Back
Last updated
03-30-2005