[thelist] When should you redirect? (was site redirect check)

Mark Cheng mark.cheng at ranger.com.au
Wed Jun 6 23:17:37 CDT 2001

***** From aardvark *****
but i also disagree with your
statement that you can't design for everyone... in fact, you can,
perhaps past the 99% mark... you aren't doing that, though

***  From .jeff *****
what's the reason for the warning?  what is so complex about the site that
it's likely to explode in some ugly fashion for non-standards compliant
browsers (which, if this happens btw, you've dropped the ball by not doing
your best to prevent that)?

The reason the site won't work properly is because of the integration of the
JS with the objects in the site.  When I refer to objects I mean a group of
images, or divs etc which contain specific content, eg all images  with
"_Rll" as part of the source.

When the site was being built I faced the difficulty that I wasn't going to
be the only one updating the site.  However, the other people likely to do
that didn't know as much a I did. (you can see that I'm no expert myself!)
So what I needed to do was create some simple rules which they could apply
to changes to make sure everything worked properly.  For example, to add a
rollover image, all that needs to be done is add an image with _Rll in the
source.  The js then allocates the appropriate event listeners.  So, anyone
who doesn't understand all the ins and outs of HTML can use DW to add the
image, type an alt, type the src (including the Rll) and that is it.  No DW
behaviours, and the code (hopefully) still validates.

Before anyone points out that this is an internal benefit which doesn't do
anything for the user and by doing it we have disadvantaged some users
(those outside the specific target audience) - Yes, but only those who don't
have ie5+ ns6+ and were not looking for the latest releases (which everyone
can access from the text page).

As .jeff, aardvark and jacob point out - it is possible to design cross
browser code that does DHTML, but to get the internal benefit I needed to
assign event listeners through the JS.  If I'd allowed people to add them
through DW behaviours, it would have been harder to maintain the integrity
of the code.

Given the browsers we were targetting for the main site, we then decided to
use a multiple level menu - unfortunately because the font had to be "gill
sans" which we could count on few people to have, we had to develop images
for each option and get those to act as a drop down.

So - upshot is - unless the browser supports adding event listeners through
the DOM and it has JS enabled,  none of the DHTML will work.  In this
circumstance we decided a redirect was appropriate.  (The wording obviously
needs to be carefully thought about :))

This is similar to deciding to use flash, or java applets for navigation
and/or the content.

Many of those sites have an effective redirect - see www.chromeglobal.com.au
for an eg.  In other words, you can't pass go until you get flash.  Other
sites designed for specific browsers (eg document.all) may or may not have a
redirect, some have wording that says you need ie4 or whatever.

 From an accessibility point of view I understand aural browsers choke on
nested tables.  Shouldn't there be a warning for aural browsers if a site
contains nested tables then?

Being in Oz, its always interesting to hear the latest law suit stories from
the US.  If a designer knows that particular browsers or groups of users
(blind, color blind, partially sighted) aren't catered for - doesn't he have
a responsibility at least to warn those users from entering the site? (Note:
designers may not want to do that, but if a client says - flash, they want
flash.  someone will do it.)

So what I am asking is  - when is a redirect appropriate?

Mark Cheng
Financial Controller
Ranger Minerals Ltd
Phone 08 9364 8355

This email may be confidential and contain commercially sensitive information.  Only the intended recipient may access or use it.  If you are not the intended recipient please delete this email and notify us promptly. 
We use virus scanning software but exclude all liability for viruses or similar in this email or any attachment.

More information about the thelist mailing list