Should Progressive Enhancements Be Required for a Web Application?
If you are building a client-side application in the web browser, what should happen when you turn the programming language off? This is the issue raised by Steve Webster today.
A lot of people argue that the web is about accessibility and therefore a well designed, standards-compliant web page should practice progressive enhancement. That is, if JavaScript is shut off, people should still be able to access the page.
I totally agree with this statement. It is particularly true if you are a company like Yahoo, writing an ad-supported content-driven website where reaching the broadest audience possible is of the utmost importance. Where is the business value is setting a high bar of entry for readers?
This is not the case however for thick-client web applications like SproutCore apps. In this case, your users come to your site to use a fast, right, desktop-class application. JavaScript is the key enabling technology behind the very features your users want to use. Asking them to turn it on in their web browser only makes sense.
That said, there are a lot of progressive techniques that do still make sense. Smoothly degrading your CSS for example is an obvious choice. Also expensive things like animations that make the experience less pleasurable on slower browsers would be obvious places to cut back. If you do use Flash (maybe for audio or video playback) that’s another good place to avoid requirements; asking users to enable an option built in to their web browser is way different from asking them to download and install a plugin.
If you want to support users with no JavaScript as well, build a reduced functionality site using traditional page-driven models that you can redirect your users to via a <noscript> and <meta> tag in your SproutCore app.
If you’re building a content site like the NY Times or Yahoo’s front page, make sure your page works even with JavaScript turned off. It’s the best way to bring in the broadest audience. If you are building a web app however, requiring JavaScript to be turned on so you can deliver a fast, fluid experience on the web will attract more customers because it will set you apart from the competition.
I should probably note somewhere on my site that I spend a very large part of my day at Yahoo building internal web applications for our developers and content producers to use, so I understand the difference in effort required to build a progressively enhanced RIA versus a simple interactive web page. I am also pragmatic enough to accept that some features will only be available to users with JavaScript enabled, but I strongly believe that core functionality for your application should be available at the basic HTML level, and that requires some form of server-side application logic.
SproutCore, both in terms of the framework architecture and the development tools, is fundamentally incompatible with a progressive enhancement approach, and this was my main motivation for writing that blog post. The other issues regarding lack of or misuse of semantic HTML, and lack of basic accessibility features such as keyboard navigation are definitely important, but these can be addressed separately.
@Steve: thanks for the note. I will continue to argue that if you want to supply a version for people w/o JavaScript, you should build a simple page-driven site for them. Most people will never see or care about this though b/c they reason they will use your app is for the Js-enabled parts.
That said, supporting semantic markup is always a good ideal. Keyboard navigation and better screen reading abilities are great too. None of these are precluded by the framework or build tools at all. I would gladly accept patches that improve these things.
I’m with you on that, Charles.
A quick look at browser stats might just shock a few developers out there - it’s acceptable to assume JavaScript is enabled for the “typical” user. Instead of the outdated “Progressive Enhancement” approach (please note, the term is a duplicate of Unobtrusive JavaScript), it is more logical and profitable to code for the largest audience first. Once the application is designed and feedback has been gathered, THEN it would be rather fine timing to entertain the idea of putting a “low-fi” version up for JS-disabled users.
As for keyboard navigation and screen reading, the value is obvious - but the development time (and cost!) skyrockets. Consider a simple button control, with the minimal click, over and out detection and reaction methods. To enable screen readers to interpret said control, you’re looking at sloppy innerHTML inserts to get the job done, and that’s breaking some aforementioned “no-no’s”. Now add keyboard navigation to the mix and you have yourself an entirely different situation, where you have to “capture and lock” BOTH mouse and keyboard events, which equates to another 4 detection and reaction methods.
Thinking about it, I’d rather build a perfect web app for people who are willing to do the unthinkable (enable JavaScript…) just to see the pretty picture in the end exactly how it is intended to be.