[thelist] Non-Js versions of JS enabled apps

Joshua Olson joshua at waetech.com
Thu Mar 13 07:29:01 CDT 2008


> -----Original Message-----
> From: Christian Heilmann
> Sent: Thursday, March 13, 2008 4:29 AM
> 
> I, too, am bored of the same people over and over claiming it 
> is extra work to create a non-scripting-dependent version. It 
> is not, it is a necessity, especially when SEO comes into play.

Hmmm.  Are you talking about interactive applications (form driven perhaps)
or simple content presentation?  The last time I checked search engines
still didn't try to submit forms.  So, I see no value, from an SEO
standpoint, to create a non-scripting-dependent version once we're talking
about forms.

I agree with some of the other comments that all content should still be
reachable by normal links in all cases.  To bring up the uber-slick photo
gallery example again, how would I put it together?  Well, I would do it
would be to have normal images and anchors to full size images in the HTML,
then let the JS perform its magic to do the fading betweens and provide
forward/back buttons etc.  Non-JS users would still get to see the pics, but
it would be ugly--a linear stack of clickable thumbnails.  I would not
bother trying to make an experience that matches the JS version for non-JS
users using page reloads.

To be clear, though, my chagrin is not about JS *enhanced* applications.
It's about applications whose core functionality has to do with JS.  For
example, if an AJAX based application is what the spec calls for and is what
the client expects (they may not know "AJAX", but they do know how the
application appears to operate), then I still don't see the value of
creating a non-JS version and an AJAX version to allow that tiny percentage
to use JS based application on the site.  For example, this actual scenario
from one of my clients:

"when I change this drop down (that has 10 or so options), I want this 20x20
grid to be loaded with appropriate sub-options with checkboxes... When they
check any of the sub-options from the matrix, the running total on the left
should update to reflect the selected sub-options.  By the way, they cannot
select more than 10 sub-options."

The solutions for JS and non-JS are going to be different in a non-trivial
way.  I do not honestly believe that anybody could say that creating two
versions takes only slightly longer than creating the one version.

> -----Original Message-----
> From: Duncan Hill [mailto:dunkaz at gmail.com] 
> Sent: Thursday, March 13, 2008 5:48 AM
> 
> Consider that, being 'forced' to go the javascript route may have  
> prevented visitors from even getting far enough into the site 
> to have reason to complain ..... it's simpler to move on to 
> another site.

Perhaps, but I wasn't talking about basic things like navigation.  In fact,
I specifically said that navigation should be created using non-JS
techniques.  I'm talking about things like interactive applications and
forms.  For example, a site may have an application that allows you to
experiment with various combinations of the vendors clothes on a mannequin.
Perhaps the client said Flash was NOT allowed on the site.  Would it be
possible to create this application without using JS?  Yes, with a whole lot
of server-side coding.  Would I bother creating a non-JS version of this
tool?  Uh, no way--too much work and the client doesn't care.

Joshua

<><><><><><><><><><>
Joshua L. Olson
WAE Technologies, Inc.
Augusta, Georgia Web Design
http://www.waetech.com/
Phone: 706.210.0168
Fax: 707.988.0168
Private Enterprise Number: 28752

Portfolio:
http://www.waetech.com/design/portfolio/

Monitor bandwidth usage on IIS6 in real-time:
http://www.waetech.com/services/iisbm/ 







More information about the thelist mailing list