Monthly Archives: April 2012

A Note to a Web Retailer about JavaScript-or-Else Pages

I was cruising computer hardware retailers on the web today because I’ve got to make a few orders. Not so many that I need to pester the manufacturers directly, but a large order compared to what most folks buy online with a credit card. Specifically, I need to replace one motherboard and build six new computers (complete with screens, etc.). Checking through a few shops I decided to order from one of the top 3 online stores for computer gear — and was rejected by their website for even trying to browse the product listings because I don’t have JavaScript enabled by default.

This got me to thinking about how stupid that was. JavsScript isn’t necessary for any of that site’s core functionality, particularly when just browsing. I hadn’t put anything in the cart, hadn’t done anything that requires “interactivity” (a laughable concept in a website if you know anything about the history of port 80, but whatever) or anything like that — I was just checking specs and prices, which worked just fine, but every single page is set to a five-second redirect delay if and only if the customer doesn’t have JavaScript enabled.

So I wrote the webmaster a note — and moved on to make my purchase somewhere else. Here’s the note:

Your website works just fine without JavaScript enabled but after a few seconds redirects *everyone* with JS disabled to a “turn JS on or you can’t browse our site” page. There is irony here because most people who browse the web with it disabled by default are IT professionals like myself who
1- Order huge amounts of hardware online and
2- Already know that they have JS disabled and how to enable it when they want to.

So that’s the situation and my complaint. Here’s a suggestion to solve it:
Test for JS and redirect to the JS-or-Else page only when the user hits ordering or shopping cart dialogues or something else to which JS is actually central. (Almost nothing, in fact, really requires JS, its just the only way a lot of web developers know how to think at this point.)

Compromising by making your site broadly accessible and then only forcing JS when the user actually needs a client-side script to run is a much better design policy than doing what you’re doing currently — which is drive customers elsewhere when they are just beginning to browse.

Its too easy to go somewhere that doesn’t do that, and so that is what what I’m doing now after writing you this note. Consider that I’d seriously consider turning JS on if I’d gone so far as to pick out items, fill the cart up, etc. and *then* get told that I can’t process the purchase without JS turned on.