The end of progressive enhancement revisited
This is a follow-up post to JavaScript and the end of progressive enhancement - you may want to read that first if you haven’t already. The comments are worth a read, as well as the Reddit thread.
The app/doc divide
What I didn’t make clear in my original post (because I wasn’t fully clear about it at the time) is the distinction between document-based web sites, and web applications. Documents are made to be read, whereas apps are made to be interacted with. James Pearce wrote a great description in the comments:
Actually what we’re maybe observing here is a clash of civilisations: the documentistas vs the applicationistas; web-as-a-medium vs web-as-a-technology-stack; designers vs programmers. It’s no wonder that progressive enhancement is a powerful tenet for the former of each pair to rally around… but not necessarily the most architecturally important consideration of the latter.
[James has since written a great, and highly relevant, post on the subject of URLs in JS apps.]
It goes without saying that apps and documents are two completely different things (even though there is a huge amount of overlap between the two). Trying to treat web design/development as a single discipline is a mistake. Anything that is primarily meant for reading, such as a newspaper website or a blog, exists as a collection of documents. I should be able to link to another blogger’s blog post and expect that in a week or a year that content will still be available at that address. I shouldn’t need to have JavaScript enabled in order to visit that address.
Web apps aren’t the same thing. A web app is an application that happens to use web technologies. Most web apps could be desktop apps – what makes a web app a web app is that it is accessed using a browser. No-one expects to be able to hyperlink to a particular view in Microsoft Excel – what would that even mean? In the same way, I can’t share a link to a particular email in Gmail. Web apps don’t always exist in the same web as everything else – many apps are islands.
Historically, web apps have been built in the document-based paradigm, using links to move to different parts of the app and forms to submit data for processing. The only reason they were made like this was because this was all the technology allowed. Now that technology has advanced, first with Ajax and now with HTML5, we aren’t tied to this old practice.
Amy Hoy summed it up nicely:
The problem is that because everyone building stuff online is using the same technologies, there can be a tendency to think that there is one true way of using those technologies, independent of what they’re being used for. This is clearly false.
The end of progressive enhancement?
Progressive enhancement is still the way to make document-based sites on the web – there’s no denying that. But with applications the advantages are less clear. If we can accept the fact that the document-based paradigm isn’t the best way to make web apps, then we should also accept the fact that progressive enhancement doesn’t apply to apps.
As someone more on the document side I had a big WTF moment reading the previous article. This distinction between web app vs web document helps a lot. There’s really no need for lifehacker.com et al to act as web apps and it’s OK for all of us to be outraged at their current implementation. The problem is web apps are a huge trend right now ( and quite likely forever ), I just hope this trend doesn’t keep overflowing into the document side and “breaking” a model that works very well.
@Adam Pieniazek Yeah – lifehacker.com / Gawker is the one that comes up every time in this discussion. I think we’re in the early stages of some new techniques – people are testing their limits. Until recently, it didn’t feel like people were talking much about the app vs doc thing, I guess because we just weren’t thinking in those terms. Hopefully as it becomes clearer just what is an app and what is document-based (e.g. where does Twitter fall?) there won’t be as many people trying to break the document model when it applies.
See, I don’t quite agree.
As making web apps doesn’t necessitate using Ajax or even Javascript (all that’s really required is HTML forms and something to process the contents of the form), it’s still imperative that regular HTML form submission mechanisms and linking are the building blocks of any app; you can then hijack those requests and do Ajaxy things instead, but the foundation should still be there.
After all, you can’t always guarantee the presence of your scripts (especially once you start using a CDN to serve some or all of them) even if any particular user has Javascript enabled. Then there’s the users who don’t have it enabled, or whose company firewall blocks some or all scripts.
To fail to have a basic web foundation under your web app is foolish, IMO.
@Tim Beadle I don’t think that argument makes sense. Just because something can be done with HTML forms, doesn’t mean it should be done. Writing the app to rely on JavaScript means an improved user experience and cleaner code. You just need to decide whether that outweighs the risk of some users not being able to use the app.
I guess I still aspire to the principles of Hijax outlined by Jeremy Keith. And I’ve been building web apps since before async, so ditching the synchronous legacy just because seems wrongheaded.
Anyway, i suspect we’ll have to agree to disagree.
Equally, just because something can be done exclusively with Ajax, doesn’t mean it should be done.
@Tim Beadle
Yes, but the point I’m trying to make is not that it should be done exclusively with Ajax because it’s possible, but because it could lead to a better result.
@Tim Beadle I’ve always worked in that way (Hijax) in the past, and I think that’s a great way to progressively enhance websites that need the odd bit of content replacement.
The problem I have is applying that technique to an application, where you can’t assume that every link or button you click has a sensible URL to fall back on. For more on the subject of URLs see James Pearce’s blog.
JavaScript, AJAX, Progressive Enhancement, Forms, they’re all tools, right. Means to an end. So is this not…as all/most/lots of coding decisions are…an engineering trade off? Does it not come down to how much time/money/effort you are able to put in.
I say this because if you know that a very large proportion of your audience are running modern browsers with JavaScript present then you can probably code one interface, do it reasonably quickly, and know that the vast majority of people will be able to use it.
If you: a) have bucket loads of cash/time; or b) know that a significant percentage of your audience won’t have JavaScript
then you a) can or b) need to have graceful degredation.
I’m relatively new to web development. But in my time I’ve seen some very fancy documents with lots of scripting, animation, AJAX, dynamic updating and so on. And I’ve seen some pretty basic applications with none of that.
My opinion would be that neither lumping documents and applications together OR considering them two different kinds of thing are right. Technology is just a set of tools and you use your engineering judgement to choose the right tool for the job.
There – my first ever comment on this blog and I’ve managed to disagree with EVERYONE! Hehe :-)
@Ross Haha thanks for the comment :)
I’m not necessarily saying that we should split the world into documents and apps, and apply progressive enhancement to the docs and fancy JavaScript-driven UIs to the apps – just that when it comes to apps the arguments/rationale for progressive enhancement don’t always apply.
I think it’s useful to make the distinction though, because I think for anything that is primarily document-based, it’s a bad idea not to progressively enhance (and there’s no good reason not to).
One of the big problems I find with app-as-a-page is the smashing of user interaction expectations right and left. If it looks like a link, shouldn’t I be able to middle-click it to open it in a new tab? If I hit Save, shouldn’t I get a copy of the current (apparent) document? When I hit back, shouldn’t my browser have all the form fields still filled out as I left them? App-based design breaks all these expectations.
What we really need is to break all these page-apps out into a separate space, perhaps a desktop sandbox with an app store. :-)
@Tim McCormack I agree with you on most of those points, and I think that’s definitely something that needs to be addressed. There are definitely some links that I want to be able to middle-click to open in a new tab, but not necessarily all of them.
These are definitely points that need addressing. We need to experiment to work out the user interaction problems that need fixing.
You could look at this from another direction, and say that opening a link in a new tab isn’t something you should have to do in a JavaScript app. After all, you don’t work with desktop applications in tabs – they stand alone (of course, they can have tabs inside the app, but that’s a different issue).
Another thing to consider is the cost (in time, resources, etc) of making progressive enhancements versus the benefit gained. PE seems to really slow down development of the front end since in many cases you are doing extra work to get things working both server and client side –even if server side code is re-used as much as possible. Also, PE tends not to work well with advanced client technologies and frameworks like json and knockout/backbone. Whether or not I’m working on document-based or app-based web project –in many cases I couldn’t really say which, seems like the lines blur a lot– here is my (new) decision tree;
While it’s true that there is a significant difference between user goals when using a website versus a web application, I disagree that progressive enhancement is only useful for the former. In my experience, the only web-based applications that would not benefit from progressive enhancement are canvas-based games (for which, of course, there is no analog without JavaScript). Other than that, progressive enhancement still works in most cases.
The way I describe progressive enhancement to people is like this: users should be able to accomplish their primary goal when visiting your site or application regardless of their browser’s capabilities. So if I’m logging into the site to check my e-mail, I should be able to check my e-mail even if I’m logging in using Lynx. That doesn’t mean that the chat functionality has to work, it just means that the primary goal of the site or application has to be fulfilled. Facebook has a good example of this where they disable chat in older versions of IE. People can still view their timeline and click around to see things, but chat is unavailable.
For those who say that progressive enhancement takes longer to do, you’re most likely doing it wrong. Progressive enhancement shouldn’t take significantly longer to implement when doing correctly. It’s just like pouring the foundation of the house before you begin construction of the walls. If a progressive enhancement approach seems to be taking longer, it’s probably because you are working backwards in building the walls before trying to pour the foundation.
An interesting discussion is definitely worth comment. There’s no doubt that that you need to write more on this issue, it may not be a taboo matter but typically people don’t discuss these subjects. To the next! Cheers!!