Any good web developer knows that you can’t rely on JavaScript to provide core site functionality. For now we still have to worry about that ever-shrinking group of users who either turn off JavaScript in their browser or who are using a browser which doesn’t support JavaScript. This is always an issue when developing for the modern web because you want to provide users with the snazzy effects and interfaces they have come to expect, but you still want your site to work without them. Much has been written about graceful degradation and its kinder sibling progressive enhancement (I particularly like this article). Both techniques offer sound principles for building fancy sites that still work without client-side scripting. However, both typically rely only on the user agent to let the web application know the browsing environment. In fact there is a human right there who can tell you better what they would like their experience to be. That’s why I like to use a little technique called “ask the user” to address the JavaScript problem. It’s not as serious sounding as those other two techniques, but I think it’s a happy medium. Here’s how it works.

Tell your JavaScript-less user that you see them

Use the HTML 4-specified noscript element to communicate to the user that you are aware of their deficiency. Suggest that they turn on JavaScript, but also offer them an alternative.

<noscript>
    I see you're not using JavaScript. For the best experience please
    turn JavaScript on. If that's not an option then <a href="/nojs">click here</a>.
</noscript>

Handle the “I can’t use JavaScript” click

The “click here” link should point to an action in your web application whose job is to set a flag in the user’s session and then bring them back to where they were. In the Ruby On Rails world that looks like this:

def nojs
  session[:nojs]=1
  redirect_to(request.referer ? :back : '/')
end

I define this action in my ApplicationController. The call to redirect_to(:back) only works if the user agent has set the HTTP Referer header, so we check for that first.

Render views based on the session variable

Based on what the user has told me I can now present a view that will work for them. For example, here’s some code that generates a select box to change the number of items viewed on a page:

<% form_tag(change_page_path) do %>
  <select name="page_size" id="page_size" onchange="this.form.submit();">
    <% for i in (25..100).step(25) %>
      <option value="<%= i %>"><%= i %></option>
    <% end %>
  </select>
  <%= submit_tag('Change Size') if session[:nojs] %>
<% end %>

By default no form button is generated. We assume JavaScript is enabled and thus a change on the select is all it takes to update the view. If the user told us they can’t use JavaScript then a form button is presented alongside the select box. The user can press the button after choosing their new page size to update the view. If the user isn’t using JavaScript and doesn’t tell us so then they are out of luck. The select box will render, but not the button, and the user will be unable to change the page size. That’s unfortunate, but it doesn’t break anything and the user can still use the page.

Caveats & thoughts

Don’t get me wrong, I don’t think developers should build their views solely around this single session variable. After all, it does rely on the user clicking the link. It is always best practice to first build a UI without JavaScript and then use JavaScript afterward to add bells and whistles. The “ask the user” technique is just a way to get a clue that will help deliver the best possible view to users. And it’s a good clue, one that a human provided instead of another computer program. The only downside I’ve found to this method is that it won’t work with page caching. Your page(s) need to be dynamically generated every time to reap the benefit.

What do you think? Is it too much to ask that a link be clicked in hopes of providing a great web page?

Incoming search terms:

• ask user to enable javascript
• asking user to enable javascript
• number of users mightyvites com
• prompt user to turn on javascript
• javascript ask user
• js disabled get user to enable it
• prompt user enable javascript
• prompt user to enable javascript
• $_session[nojs]
• prompt users to enable javascript