Javascript usage on the Library’s web site
Written on April 2, 2009 by Michael Lascarides
There’s been a trend in web design over the past few years towards increased usage of Javascript. For you non-techies in the audience, Javascript is a “client-side” programming language, which means it’s used to write small programs that run on your computer when you load a web page. The “your computer” part is the important bit; it makes it possible to do some complicated manipulation of individual parts of a page without having to reload the whole shebang. Google Maps is the classic Javascript experience. You load one map, and as you pan around it loads just the new map images you need, adding them to the edges.
The upside of Javascript (and client-side programs in general) is a better user experience, with quicker responses to user input (both real and perceived). There is a downside, however, in that these programs run on the client’s computer, and everyone’s computer is different. It’s even possible (albeit rare) to turn off Javascript entirely.
We’ve been hearing the siren call of new Javascript features on our upcoming NYPL redesign, but before we can even evaluate a strategy for using it, we need to know how many of our users can’t see Javascript at all. This is trickier than usual; ordinarily, we would just head over to our statistics program, Google Analytics, and loook up browser information. Sounds easy, but Analytics uses Javascript itself to report stats! So not only is it helpless to answer the question, but also its stats are underreported by the number of non-Javascript users. So there’s another reason we need to investigate.
Fortunately, a little hacking and some spreadsheet work has given us a better answer. There’s a <noscript> tag in HTML that automatically serves up alternative content for browsers that don’t use Javascript, so for a couple of days this we we added a <noscript> tag to our home page containing a link to an tiny image on a different server. The image was just a single pixel, and of no importance, but we were able to comb through the server logs and find requests for that image, giving us the number of users whose browsers tripped the <noscript> code.
So here’s the number: Out of 23,704 total pageviews, 893 had no Javascript enabled, or 3.76%. If we remove those who looked at the home page more than once and look only at unique pageviews, the number drops to 374 out of 19,350 unique pageviews, or 1.93%.
That number might still not be perfect. There are many “robot” and “spider” programs that automatically visit web pages, and these usually don’t have Javascript turned on. Therefore, a good chunk of that 1.93% potentially doesn’t even have a human on the other end. But spiders usually don’t load images either, and our little test used an image load as the trigger. Jut to be safe, I ran the results through a list of known spider Internet addresses. It only flagged one or two.
So assuming that number’s relatively solid, we have 98% of our users with working Javascript. That’s great, right? Well, that non-script two percent still accounts for 1 out of every 50 of our users. So whatever new features we put in place, we should still make sure that they are enhancements to the experience, and not a necessary piece of the navigation.
Filed in: Javascript, users.
It’s quite possible to build websites that work fine without javascript, although they work BETTER with javascript.
I think that’s an imperative, and I try to do it with all my projects. This is important not just for accessibility to the “disabled”, but for:
1) Things like the Kindle, which have web access, but poor or no javascript.
2) Machine access. A well-designed HTML with proper classes and ids can actually be pretty efficiently ’scraped’ by software even without a separate API. But once you start putting javascript all over the place, this gets a lot more challenging and less maintainable.
Xerxes, in addition to degrading well if the user agent doesn’t do javascript at all, also allows a user to _choose_ to turn off all javascript elements, in case their user agent does javascript (partially or completely), but the js still isn’t working with it.
[...] April 2, 2009 Posted by jrochkind in General. trackback A response to an nypl post. (As I’m often doing these days, I made a comment there, and then created a 2d edition here [...]
Speaking for the team that is developing the new NYPL web site, I want to make it clear that, regardless of the percentage of users with or without Javascript enabled, it is our intention to utilize best practices in web design, including adherence to web standards and the use of unobtrusive Javascript.
For phase one of our redesign, we are using Javascript very sparingly, and only when it provides a tangible improvement in the user experience. In these cases, we’re taking care to ensure that there is no loss of functionality for users with Javascript disabled.
I’ll elaborate more on our web design methodologies in a future post.
I see a quite a few navigational js links. The problem with these is that I can’t middle click them to open in a new tab. I only have one way of interacting with them.