Backwards compatibility? Where is the line?

[theEclipse]

I guess this is a survey question.

When developing AJAX scripts how much attention should be given to parallel development of a non-AJAX version of the interface?

The, for most people, quintessential example of well implemented AJAX, gmail, has full backwards compatibility: Basic HTML view.

Is that necessary? If so, is there a viable alternative to entirely parallel development?

Thanks for thinking...

Robert Carpenter
Remember....eternity is much longer than this ~80 years we will spend roaming this earth.
ô¿ô

http://www.robertcarpenter.net

 

[BillyRayPreachersSon]

I think that depends very much on who you ask. My view as a (mostly) front-end developer is very different from the views of the (mostly) server-side guys at work.

Whenever we are going to implement a new module on one of our sites, I'll always try and push for a non-AJAX solution as well, whereas the server-side guys won't really care too much about it (probably because they have to do more work ;-))

It doesn't always happen, and some of our modules fail abysmally if you have no JS, but for the most part, we'll have some sort of functionality for those with JS disabled.

Ultimately, the decision is made for us by 'the business' whether to burn time making a module that will work without JS or not. Sometimes they will see the benefits, and sometimes they will not. At least if I push for the non-JS fallback, I'll have done everything that I can.

Generally though, it would also depend on who your target audience is, the browser stats you are getting, as well as whether the module in question needs to be SEO-friendly.

If you're getting many people on your site with older browsers or with JS disabled, then it would be foolish to even contemplate not supporting them. With the sites we're working on right now, this percentage is miniscule, but it's nice to feel like I've pushed for [what I consider to be] 'the right thing'.

Dan



Coedit Limited - Delivering standards compliant, accessible web solutions

[tt]Dan's Page [blue]@[/blue] Code Couch

http://www.codecouch.com/dan/

[/tt]

 

[theEclipse]

Dan-

When you develop new modules, how do you (or your server guys) approach building a non-JS version as well? Are the two solutions disjoint, or parallel, or are they overlapping?

In my view many of the non-JS solutions do the exact same thing as the JS solutions but without all the formatting and output stuff...which is then handled by the JS. How do you most often implement something like this?

Robert Carpenter
Remember....eternity is much longer than this ~80 years we will spend roaming this earth.
ô¿ô

http://www.robertcarpenter.net

 

[BillyRayPreachersSon]

Normally we'd start by building the non-JS version first, as that way we know we'll have taken into account URLs mappings for links and form submissions, etc. Then we'd add AJAX functionality on top.

The formatting of the module may or may not be different without JS.

With some modules, the only difference might be a button to perform an action that might have been done automatically with JS enabled (e.g. 'search', 'vote', etc), whereas some modules might look completely different, offering only basic functionality to get to the underlying pages / data (this is also good for SEO).

Dan



Coedit Limited - Delivering standards compliant, accessible web solutions

[tt]Dan's Page [blue]@[/blue] Code Couch

http://www.codecouch.com/dan/

[/tt]