Progressive enhancement and process
February 3, 2008 – 11:41 am
So here’s a question: how do you design your process artifacts to take progressive enhancement into consideration? (Wow, I think I just used my monthly quota of buzzwords.) In other words, how do you create wireframes, comps, and buildouts that show 1) the structure and look of a site at full-functionality, with fancy JavaScript and whatnot all over the place, as well as 2) the same site as it functions without the scripting?
Take Rails 2’s scaffold-generated index action, for instance. When you first create it, you get a list of records with view, edit, and destroy links - those destroy links, however, are wholly JavaScript-dependent; on clicking them, the page creates a form with a couple of hidden fields (including _method=”delete”, to get Rails to treat the request as if it came in via the HTTP DELETE method), requests confirmation from the user, and submits the form.
Without JavaScript, on the other hand, you’d have to have the form already on the page - which is easy, and is transparent from the point of view of the artifacts I’m talking about - but the confirmation question is different. Do you have to change the visible form to include, say, a checkbox that must be selected to confirm the delete? Or do you insert a new page in the process - so on clicking the delete link, you get a new page back asking you to confirm?
This may not seem so intimidating, but it is the simplest case. Consider the case where you want to show and hide various sections of a page as the user needs them. Without JavaScript, this would require full-page loads - which means that your design process will have to accommodate that by either revising the requirements or splitting the functionality across multiple new pages. This is easy enough to do in Rails, by using respond_to to return full pages for HTML requests and partials for JS requests, but means that your design documents will have to account for just that many more possible states.
This question is obviously closely-related to that of representing Ajax and other dynamic functionality in your design process, so it’s entirely possible that a satisfactory answer to that problem will work here, too - but I’ve yet to see a really good solution in that case, either. Any comments?
(photo from cfox74 on Flickr)
2 Responses to “Progressive enhancement and process”
Ben,
When I hear you talk about this, I always feel like you’re starting with the fully-featured site first, which - in my opinion - is backwards. (I know, I know - maybe my assumption of your perspective is wrong, in which case, the rest of this is a fallacy, but it’s a fine point, so bear with me.)
I represent this sort of behavior in two separate wireframes. First, I draw out the site without JavaScript. Adding JavaScript to enhance interaction in a progressive way is a new feature, so I draw that separately. Generally, I prefer these to be separated with the implementation of the base site in the middle, but I know that requires a really optimistic opinion of the agile process.
- Clinton
By Clinton R. Nixon on Feb 3, 2008
Thanks, Clinton! So your point is that I’m stuck in the graceful degradation mindset, instead of the progressive enhancement one? That’s very possibly true, but even granting that my question remains - and your answer of two entirely separate wireframes can certainly work.
I do disagree with your preference to implement the base site before designing the enhanced version, though. The system architecture and design to support improved interactions through JavaScript and other ‘optional’ technologies can differ dramatically from that used in the base site, and I think you’ll often generate a lot more pain by adding that on to the system later than by planning for it in the first place. In other words, I think you should have both versions designed from the start, even if you then build the base case first.
By Ben on Feb 3, 2008