Selling colleagues on progressive enhancement

Brian Dillard, Monday, June 23, 2008 @ 5:14 pm

Achieving progressive enhancement at the view layer takes a lot of coordinated effort between server- and client-side developers. A lone UI developer can't make it happen without assistance and buy-in from the rest of the team. I'm not talking about selling the client or the business team. I'm talking about selling one's fellow developers.

I used to work for a giant company (Orbitz) with a large team of front-end developers and total organizational buy-in about accessibility and web standards. It took Orbitz years to get there, but once it did, progressive enhancement was the gospel.

Now I'm at Pathfinder, a smaller, agile shop with a large Ruby on Rails practice. Given all of Rails's built-in Ajax helpers, most Rails teams aren't used to separating the client-side behavior layer from the underlying, JavaScript-free web application. Progressive enhancement-style Ajax doesn't really take more work than normal Rails-style Ajax, but it does force a different style of application design - one that can't be imposed by the view-layer developers without assistance from the model/controller developers.

That's where pair programming comes in. I'm currently working on a Rails + jQuery project with some ambitious goals for cool UI widgetry and slick eye candy. Our approach for Iteration 1 went like this:

1. Rails developer builds the basics of a new feature.
2. JavaScript developer enhances it with client-side JavaScript.
3. JavaScript developer pairs with Rails developer to explain which pieces of Rails code need to change if the application is to work in a JavaScript-challenged user-agent.
4. Rinse and repeat. Everyone's getting their job done. Everyone's basically happy.

I think my Rails colleagues learned a bit about the progressive enhancement approach to Ajax. I definitely learned a bit about Ruby on Rails. But really, we were continuing to work from two separate conceptual domains.

Today we planned Iteration 2 and quickly resolved that our process next time around will go something like this:

1. Rails developer and JavaScript developer together whiteboard the technical design of a new feature.
2. Rails developer and JavaScript developer pair on both Ruby and JavaScript programming.
3. Rails developer learns lots about JavaScript and web standards. JavaScript developer learns a lot about Ruby and Rails.
4. Rinse and repeat. Everyone's getting cross-trained. The resulting code benefits from improved technical design. Everyone's much, much happier.

Related posts:

1. Progressive Enhancement with Prototype and Custom HTML Attributes
2. Accessibility and Ajax: Progressive enhancement vs. side-by-side UIs
3. jRails: Ruby on Rails with the Prototype guts ripped out
4. My IBM developerWorks series, part 2: Tooltips, lightboxes and more jQuery goodness
5. Working effectively as a team of one: Five tips for front-end developers on Agile teams

Comments (1)

Software Development

Comments: 1 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   Way to go! That’s exactly how I feel it should be done. Not that a RoR programmer needs to know every single browser quirk, neither does a frontend developer have to know how to solve a complicated Active Record issue, but they both should have more than a general understanding of what the other person is doing and should be able to jump in on medium tasks. This leads to better code, more considerations on software design, accessibility and web standards, and also helps a lot if team members leave the team. Im sure your new workflow will be a huge success.

   Comment by Andreas Stephan, Tuesday, June 24, 2008 @ 4:34 am

Leave a comment