Progressive Enhancement 101

3 June 2011 by Jinesh Parekh 1 comment

Progressive enhancement in real life.

We all know about ‘progressive enhancement’ except the perhaps the term itself. The concept is quite simple. In real life we define boundaries of various shades of gray.

For example at school we may group our fellow students based on their studiousness and modify our interaction with them that suits our needs. We may be nicer to the math whiz because we’d like him to help us out with our homework. We might not be nice to the guy that looks and feels useless to our interests.

Granted the above example is kinda pointless because in real life it’s kinda complicated because many interests interact and it all boils down to the net worth of our needs. Say for example the math whiz and you might be in rival groups or you and him might be having a crush on the same girl. It might also turn out that the useless looking guy is actually very rich.

Yet another day to day example.

Progressive enhancement from the TV industry.
Progressive enhancement from the TV industry.

TVs come in various sizes, resolutions, aspect ratios and makes. Professional quality video content has to convey their core message spanning this hodgepodge of end user devices. One way to do this would be to make videos for each type of display. But thankfully, there’s an easier, better and much simpler way… Enter safe areas!

If you refer the diagram above, you’ll see three superimposed black squared. These are the common three TV screen resolutions. You can also see a green square and a red square. These are the ‘action safe area’ and the ‘graphics safe area’ respectively.

Any action in the movie worth seeing must come inside the green square and any text worth seeing must come inside the red square. This implies that text (what is generally meant by ‘graphics’) is more of an important thing that must be conveyed in its entirety than some action happening in the movie; as most of the action will also be inside the graphics safe area anyways.

To account for botched up displays, the graphics safe area is even smaller than the lowest resolution!.

Once, the basics are covered, more value is added to the users that own expensive devices by the extra ‘wow’ content that frames the core message. Consequence being that everybody is happy. Users on low end devices get what they want, users on high end devices get what they want, and the content producers get what they want too. The above constraint helped the content producer progressively enhance the user experience starting form the lowest spec target device to whizzbang 3D HDTV! A teeny weeny little constraint goes a long way.. doesn’t it?

Moving on to the web..

The web as complicated as it is isn’t thankfully as complicated as real life. It was much less complicated say 10 years ago when web pages were generally meant to be viewed -I’m stopping at that and not going into the not so insignificant details of the visual domain such as the array of visual user agents that need to be supported and the exponential complexities they entail.

Accessibility (support for visually impaired people), support for bots (search engine, mashup consumers) etc were ignored as they were insignificant. Most of these grand goals (except perhaps SEO) are still insignificant

Before you let the dogs loose on me, let me assure you that constraints are more awesome than that.

General purpose web development constraints.

  • REST architecture style
  • Semantic HTML
  • Unobtrusive JavaScript
  • Pure CSS styling

Of these, the most important is REST. REST architectural style simply means that URLs are addresses to resources, that you can operate on these resources and get a representation of resources that may have addresses to other resources. So an example from real life would be say, the analogue of the URL would be the physical address to idyllic-software and an action could be decorate and a representation would be a photograph of the decorated interior and the addresses from that resource to the other would be what the person in charge (application designer) would allow you to further mess around with.

Two links from the application state of decorated building to possible other application states would be, water the garden and mop the floor. On the web URLs are constrained by their syntax and HTTP constraints the actions to GET, HEAD, POST, PUT, DELETE. Browsers further constrain that set to just GET and POST

Once you have REST, you can use a web browser to consume it as it is using semantic HTML/XHTML as the data format, styling it with pure CSS for pleasing eye candy, consume it as JSON, XML, XHTML from a pure JavaScript browser application. Or let some bot consume it as pure data. Makes life easier for everybody.

What’s on the table for the average Joe developer.

  • Back end developers worry only about the real problem. (how to get and operate on the data underlying the resource).
  • SEO analysts, Front end developers, liaise on the MarkUp.
  • Front end developers write full applications or add just enough JavaScript to spice up the UX. These consume the RESTful service.
  • Bots can negotiate for structured content with the Server (content negotiation) as it is now easier for the backend devs to push out yet another format which will only be a few lines of code to say serialize an object to JSON or XML. Or else bots can consume straight semantic XHTML/HTML.

Example

Say you’ve a resource located at http://example.com/foo/address. The data for which you get from some data source into say a Ruby Hash like the following:

address = {f_name: 'foo', l_name: 'bar', address: 'one two three', phone: 12345678, email: 'foo@bar.com'}

You mark it up using semantic HTML like say

 <dl class='address'>
  <dd class='first_name'>
    First name
  </dd>
  <dt class='first_name'>
    foo
  </dt>
  <dd class='last_name'>
    Last name
  </dd>
  <dt class='last_name'>
    bar
  </dt>
  <dd class='address'>
    Address
  </dd>
  <dt class='address'>
    one two three
  </dt>
  <dd class='phone'>
    Phone
  </dd>
  <dt class='phone'>
    12345678
  </dt>
  <dd class='email'>
    Email
  </dd>
  <dt class='email'>
    foo@bar.com
  </dt>
</dl>

Which with the following CSS

dl.address {
  background:cornsilk;
  overflow:hidden;
  padding:5px;
}

dl.address > dt,dl.address > dd {
  float:left;
  width:50%;
  background:honeydew;
}

Renders as

First name
foo
Last name
bar
Address
one two three
Phone
12345678

Summary

  • Design your application around the URL, actions on the URL and the links to other resources from the representation of the URL.
  • Try viewing the document as data. Use microformats.
  • Stand back and try adding static eye candy using pure CSS. Stop viewing HTML from a visual design perspective.
  • Add JavaScript to enhance UX. Application should work without the JavaScript anyways.

Jinesh Parekh

Founder CEO, Idyllic.

Follow me on Twitter

1 thought on “Progressive Enhancement 101”

Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe To Our Blog

Get access to proven marketing ideas, latest trends and best practices.

Next up home

Contact

Lets build cool stuff

Share your contact information & we will get in touch!

I want (Tell us more about your dream project)