No Love for <noscript>

I’m currently implementing a web front-end that has to work in a very secure environment. One of the things we can’t count on is that users will have JavaScript enabled, simply because it’s often a vector of attack on the web. While this has been a great learning experience overall, last Tuesday I learned a bit more than I’d planned on:

Apparently before I’d left the office Monday evening, I was doing some testing with JavaScript disabled. I’d also forgotten to turn JavaScript back on. And how long did it take me to realize this error the following morning?

Two hours.

Because apparently somewhere between CSS 1 and web 2.0, everybody forgot about <noscript>.

And I don’t just mean people like you and me — we’re talking big names here. Do you know what Google Reader looks like with JavaScript turned off? Try it. It’s just a logo that says Google Reader and a blank white page. It looks like a server issue.

My task management software didn’t fare much better. It simply sat there on its loading icon, perpetually promising me my todo-list, yet never delivering. How many times did I hit F5 thinking it was “just a slow server”? Tons.

Then there’s Yammer, probable the worst offender of the bunch. It managed to load everything except my timeline, the only bit that matters. What good is navigation if I can’t navigate to anything?

Finally, Grooveshark got it right. The recently HTML-ified music-streaming app displayed a prominent message alerting me of my ineptitude, triggering a sudden light bulb and all that jazz. But this raised an interesting question:

Who’s responsibility is it to tell users when they have JavaScript disabled?

Obviously the easy one is to blame is the user. If I turned off JavaScript support, I probably did it on purpose and it’s my responsibility to remember to turn it back on. But let’s say I forgot, or I did it by accident with some bizarre hotkey incantation. What then? There are two entities that can help me:

As in my recent case, web applications can use <noscript> to give me a heads up that I can’t enjoy their content given my current browser settings. Big names like Google should especially do this. They could even go the extra mile and detect my browser version, and as long as I’m not running something horribly old (Netscape 1?), or something excessively insecure (cheap shot at IE6! Yes!), provide me with a kind reminder that I probably did this myself, oh and here’s how to fix it in whatever browser my user-agent suggests I’m using.

And that brings me to my second point, and the bigger one in my eyes. Where was Firefox on this one? Let’s look at the various data points Firefox had but didn’t manage to connect:

1. That webapp sure does have a lot of JavaScript in its headers/mime-types/mark-up.
2. Hey, this is one of Dan’s bookmarks; it’s all over his browsing history.
3. Dan always has JavaScipt enabled, except the other day when he was mostly hitting localhost.

There was plenty of information there that Firefox could have used to deduce that I probably wanted to run JavaScript. A friendly reminder would have done just fine: “Hey, this site that you visit all the time uses a lot of JavaScript; if you want to run it, click here.” Is that expecting too much?

I think I’ll write more about this soon.

I really am learning quite a bit about taking JavaScript-less users into account in complex web applications. And next time I’ll be sure to share something more productive, instead of just bashing a few of my favourite things.

Stay tuned!