Challenging Ourselves with Progressive Enhancement

Introduction

Most Web coding these days is a jumbled mess of HTML, CSS, and JavaScript. I was starting to believe that this was simply an ugly truth I had to live with, but then I learned about progressive enhancement. Progressive enhancement (PE for short) is a Web design strategy that uses web technologies in a layered fashion to separate the jumble and provide universal access to basic content and functionality while also providing an enhanced experience for those with more capable browsers and bandwidth.

Following PE requires some discipline. I and many other long-time Web developers have gotten used to using presentation markup, inline styling and scripting because we started at a time when there was no other way to provide a suitable user experience. However, browser technologies have matured to the point where the developers are now usually holding back the technology rather than the other way around.

With this in mind, I wanted to come up with a few simple rules for guiding Web developers towards this new approach. My idea is to offer a series of challenges, where each challenge involves implementing some common Web development task while being restricted to a set of rules to steer the developer away from obsolete techniques and towards PE. My intent is to offer a way to gently introduce the practice of PE to Web developers (including myself).

The Challenge

The Progressive Enhancement Challenge consists of four rules and three levels. The rules enforce separation of the layers while the levels enforce the progressive construction of those layers.

The Rules

1. All markup must be well-formed.
2. Transitional or other pure presentation markup must not be used.
3. Inline styles or scripting must not be used.
4. All links to external stylesheets and client scripts must be within the document head.

The Levels

Each level must maintain all the levels below it, so levels must be constructed in order and higher levels must not break lower levels.

Level 1: Function

The application must provide all required functionality even when client scripting and/or CSS is disabled or not available.

Level 2: Presentation

The application's presentation should be enhanced with appropriate styling.

Level 3: Interaction

The application's client-side behavior should be enhanced with appropriate scripting.

Conclusion

If you're not familiar with current Web technologies, some of the rules may seem impossible. For instance, Rule #3 prohibits the use of HTML event attributes such as onload or onclick. The Progressive Enhancement alternative to event attribute is to use unobtrusive JavaScript techniques such as jQuery event handler functions. Likewise, most other popular techniques prohibited by the rules have better alternatives that are well support in all the major modern browsers.

The goal of this challenge is to push us to become better Web developers. As such, it is merely a means to an end, and not an end unto itself. While I'd like to see this create a little friendly competition between developers, the last thing I want is for people to take this too seriously. If you try to use progressive enhancement for real work and find yourself in a situation where sticking to these rules is proving too difficult, don't sweat it; your page won't crumble to dust if you break a rule here or there. And please, please don't create or put any badge graphics on your Web pages claiming they are Progressively Enhanced!

Stay tuned for some PE challenge exercises coming to this blog Real Soon Now(tm)!

Adobe ColdFusion: A new beginning, or the beginning of the end?

For my very first blog post I thought I'd start with some big thinking ... very big thinking.

Along with many other ColdFusion coders, I was excited about the recently released Gartner report on Adobe ColdFusion. The overall positive outlook by Gartner on the ColdFusion technology platform provided a welcome relief from naysayers dominating the CF blogosphere during the previous few months. Many of those naysayers seemed to be former CF coders that had left the platform years ago and were unaware of how the platform has evolved under Adobe's stewardship.

However, a closer read of the report reveals that the authors believe the "uptick" that ColdFusion is currently experiencing will be short-lived. While they see the value of the current ColdFusion platform in making it easy to build enterprise Web applications, they also see this value diminish over time as other factors become more important to organizations. Organizations looking to reduce the complexity of their technology landscape will steer towards broader platforms such as Java EE and Microsoft .NET. Organizations looking to reduce the cost of their technology landscape will steer towards Open Source platforms such as PHP and Ruby.

As much as I love coding in ColdFusion, I agree with this general assessment. Adobe has put a lot of work into the enterprise integration features of ColdFusion, and yet these features have not attracted the attention of many CF coders. For instance, XForms is a great open technology for separating a form's function from its presentation, yet ColdFusion XML forms (powered under the hood by XForms) is all but dead. The ColdFusion event gateway interface is an elegant way to perform asynchronous communication with everything from Google Talk to JMS brokers, but CF coders seem to be more interested in the cfthread tag. Many CF coders are interested in Flex for developing richer front-ends, but only a fraction of those seem to know what BlazeDS is or why they should care about it.

It looks to me that even though the ColdFusion platform has evolved a lot over the years, ColdFusion coders haven't changed much at all. The applications they build now may have richer interfaces using Flash and Ajax, but they are the essentially the same kind of applications they built before: Web front-ends to SQL databases. These are the types of applications that ColdFusion coders are most comfortable with; yet they are also the types of applications that any Web development platform can do, and therefore have the biggest risk of getting dumped in the context of larger technology strategies within organizations.

This is a great time to be a ColdFusion developer. It is also a very dangerous time to be comfortable with being a ColdFusion developer.

Fortunately I'm already uncomfortable as a ColdFusion developer. This is not because I am worried about the state of the platform; rather it is because uncomfortable with what I see as the status quo of ColdFusion application development. Some of it has to do with technology, but a lot of it has to do with process.

I see a lot of ideas and tools that have a lot of potential for improving outcomes in the delivery of ColdFusion-based business solutions. Here is a partial list of ideas that have captured my attention of late:

1. Agile development practices such as Scrum to provide quality and value to clients more quickly and more frequently.
2. Agile requirement practices such as User Stories to improve collaboration between developers and clients in finding features that offer real business value.
3. Agile QA practices such as Test-Driven Development and Behavior-Driven Development to spread the cost of QA throughout the development process instead of leaving it to the end (where it almost always gets short-changed at the expense of the client).
4. Testing frameworks such as MXUnit, Selenium, and Tellurium in conjunction with the above for a streamlined testing process instead of the usual hit-and-miss affair.
   
5. Build automation tools such as Ant and Maven for stress-free deployment of Web applications, and Continuous Integration tools such as CruiseControl to manage quality levels during the project.
6. Using alternate programming languages for back-end functionality in ColdFusion applications, from standard Java to the interesting dynamic language Groovy to the much more exotic language Scala.
7. Using Progressive Enhancement and Unobtrusive JavaScript with Ajax libraries like jQuery for better collaboration between back-end coders and user experience builders to create rich and robust HTML front-ends.
8. Techniques for refactoring application code to design patterns and refactoring databases for improving the long-term maintainability of applications.
   
9. Designing service interfaces for ColdFusion back-ends that can be simultaneously exposed through traditional HTML front-ends, Ajax front-ends, Flash remoting and Web Services.
10. Improving the cacheability of Web interfaces by proper use of HTTP features and implementation of REST concepts to improve performance and scalability.
    

I think 10 items is a good place to end my brain dump for today.

As you can see, I'm not short on ideas for moving beyond "comfortable" ColdFusion development. The real trick is going to be in identifying ideas that I have a real chance at actualizing, and then making it happen. It won't be easy: with the only person asking me to do this being myself, I'll have to be harder on myself than usual to build and maintain momentum.

If and when I start on any of this I'll post it here.