With the arrival of JavaScript libraries like jQuery web development has gotten a lot easier. Better still, these tools make it possible to design website user experiences that are simple, intuitive and interesting. Our use of jQuery and MooTools has opened a world of “cool” possibilities and makes our work a lot more interesting. However, as we recently discovered, the use of and reliance on these tools involves a certain degree of risk.
We recently lunched a new, redesigned and much improved website for a Tokyo-based client. This firm’s website has grown over the years–as happens with many businesses–to be its primary tool for customer acquisition and interaction. Web-based forms and a host of back-end systems–most of them browser-based and built by Netwise–handle key business operations such as inquiries, estimate and work requests and the like.
As part of the website redesign process we sought to optimize and refine the customer-facing functions in order to create the most positive user experience possible. We made changes to the information architecture and workflow, improved the design, built in improved error handling, assorted Ajax functions and more. In this critical area we succeeded in realizing significant improvements over the previous version of the site, using the latest tools and practices. But we had a problem.
One of the main jobs of the website is to collect information and documents via a somewhat lengthy form. With the launch of the new site, however, we started seeing a drop in the number of documents that accompanied inquiries. In this area documents are more or less assumed, but now we were getting 5% of inquiries with no attached documents, or about a 300% increase. Something was clearly wrong.
We tested and tested some more, using all of the current browsers and also older ones. We used fast connections and slow ones. We tried big files and small ones, and myriad file types. We could not reproduce the error. We scoured the data from Google Analytics to try and find some clue, a hint as to the cause. We collected information from users who reported problems, tried to reproduce the issue with the same combinations of OS and browser, all to no avail. Frustration mounted.
Finally, one of the team, trying to reproduce the bug reported by phone by a customer moments earlier, decided to try the site at IE’s “High” security setting. And in doing so, he saw the bug for the first time. That simple setting disables JavaScript, and by extension just about all of the new, cool functionality companies like ours use to create useful and interesting websites.
Who browses the web with JavaScript disabled? Nobody, right? According to Google, only 0.75% of users surf with JavaScript off. Why? One reason is that the web can be a pretty barren and forlorn place these days without it. While there are certainly sites that work the same with or without JavaScript, the majority today definitely make extensive use of it as well as frameworks and libraries that rely heavily on it. Nobody would disable it, right? Wrong. In our small sample we saw figures at or around 5%, which is, well, a lot.
Finding these users was especially tricky because–like so many other sites and applications–Google Analytics relies on JavaScript as well, and needs it to collect traffic and usage data. Each visitor that came to the site, and everything they did while there, was essentially hidden from our view. It was only through more thorough testing that we were able to identify the source of the problem.
The lesson learned in this case is this: jQuery, MooTools, form validation code as well as most client-side behaviors and dynamic functionality all reply on JavaScript. If you’re not testing your websites with it disabled then you really have no idea what a small percentage of your visitors are experiencing while there. Developers and testers are used to working from a matrix of browser and OS combinations, but need to include a “security” dimension in there as well if they’ve not already. Even today, when common sense and experience suggest otherwise, JavaScript can’t and shouldn’t be assumed.
I seem to be seeing more and more of these lately, mostly thanks to them being forwarded by confused and concerned clients. If you want to get someone’s attention these days you can start by injecting a little FUD into their thinking about their Internet domain name.
