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

[aardvark]

> From: "Mark Cheng" <mark.cheng at ranger.com.au>
[...] 
> 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.

circular argument... you built a site to rely on JS, and now you 
can't change the site because the JS won't work...

cool, i got fax-spam again...

> 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.

so, you've coded the site for valdiation to the WaSP ideals first, 
and maintainability second... but by making maintainability an 
issue, you insert all sorts of JS, and complicate the page overall, 
simply for the benefit of your staff (which really makes maintability 
your first point)... that's generally not good...  the user should never 
be punished for your ease of work...  this is why it's generally 
better to do all your page building with SSIs, not client-side script... 
the user is never penalized, and the script to build the pages 
always works (since it's run on the server)

> 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).

heh, i guess i didn't read far enough... but my point still stands... 
and you've gone back to a circular argument... you're 
inconveniencing users of older and alternative browsers simply for 
your own ease of maintenance... it seems you put the cart before 
the horse on this one...  if your point about browsers didn't fly with 
me before, how can you use it to justify your maintenance desires?

and remove that cursed 'everyone can access' line, since we've 
already established that it's not true... everyone can see the link, or 
even click the link, but not everyone can or will update their 
browsers...

> 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.

no, but then you'd probably be using code DW can spit out, which 
means it would be much simpler HTML (that any browser could 
see), which means you wouldn't need to do the JS since you 
wouldn't need to build pages that build themselves on the fly (since 
you have DW), which finally means that you could stick with DW 
for all your maintenance as well (thanks to its templates)... oh, and 
you can even write the code to be compliant, and then use DW to 
lock it down...

> 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.

why did it have to be gill sans?  why doesn't your CSS cascade 
through other typefaces (like screen-optimized ones)?  you're 
telling me the *font* was the drop-dead issue, not the fact that the 
page doesn't look the same to anyone?  that's kind of weird... and 
anti-user, too... heh, accessibility...

> So - upshot is - unless the browser supports adding event listeners
> through the DOM and it has JS enabled,  none of the DHTML will work.

that's your upshot?

> In this circumstance we decided a redirect was appropriate.  (The
> wording obviously needs to be carefully thought about :))

feh, present the linearized page... include a <div> (or whatever 
correct tag you prefer, it's moot at this point) with an explanation of 
what's going on for older browsers, and set its properties to 
'display:none;'... then your IE5+ and N6+ browsers won't see it, but 
everyone else will...

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

yep, and you'll find i think both are a generally bad idea... ok, i 
think Java is always a bad idea...

> 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.

yeah, sites that say i need Flash or browserX get skipped... i don't 
bother... i've ditched many sites like that, without even looking for a 
'skip intro' link or the like...  i bail out of those faster than a zero 
pilot with a parachute... IOW, those are not effective redirects...

> 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?

yes, unless the designer has coded them to linearize well... and 
guess what, having a copy of Lynx on your system can help you 
as the designer determine if your tables linearize well...

> 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.)

depends on the client (gov vs non-gov, NFP vs non-NFP, etc.)... 
and it also depends on the audience...  and finally, it depends on 
the grumpy user with a litigious bent who stumbles across it...

keep in mind, the last three lawsuites you'll hear about for 
accessibility aren't all US... the AOL one in the US dealt with their 
win32 interface... then there was the UK bank... and finally the 
australian olympics site...

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

well, when content has been moved, IMO... otherwise, you should 
maybe not have had the page there to begin with...

redirects have all sorts of ramifications...

- search engines do not dig them...
- some browsers won't follow them, no matter how you do it...
- server-side ones can return HTTP codes that some browsers don't 
dig...
- they can mess up your back button...
- if they are too fast to redirect, users may never know to change a 
bookmark or go somewhere else...
- they can redirect the wrong user at times...
- they can piss off users who don't understand what you're doing...

now, of course you can find my splash page article, which has a 
redirect, but that's a very specific case, and one where i wrote the 
article because i hate splash pages... but as long as they're in use, 
i can at least try to make them less offensive to me...