Me
About
Gallery
Company
Girl


Projects
Ruby on Rails
Basecamp
Highrise
Backpack
Campfire
Ta-da List
Writeboard


More
Feed
Archives

May 01, 14:46

Why are designers excited about Rails?

Rails is the middle ground for a lot of incredibly interesting interactions between designers and programmers. As Rails was extracted from Basecamp where the collaboration between designers and programmer(s) has been intensely tight, it's very welcome to see that this pattern replicates outside the original setting too.

One of the reasons for this is of course that designers are able to work right on the system without losing their mind. The cries of Ruby in the template is always a call coming from over-caring programmers that think they need to shield the poor designers from the evils of code. But I and others have found through experience that there's no reason to sell designers short like this.

The primary reasons for this is of course the rise of the domain language and the succinct nature of Ruby. Designers are perfectly capable of understanding and manipulating constructs like <% for person in @post.whos_talking %> or < if @person.administrator? %>. While they will rarely be the originator for these fragments, they'll surely be the manipulators of them. Moving stuff in and out of conditions and loops.

A recent example of this is a posting by Justin Palmer on creating the Azure template for Typo (that hot weblogging engine in Rails):

As I’m still new to ruby and rails , I thought it might be somewhat of a learning process trying to get this implemented, boy was I wrong.

It was extremely easy to get everything put in place. While there is mixed ruby and html in the templates, it is very minimal. Great care has been taken to minimize the efforts on designers, and make it just as fun to design for rails as it is to program for it :-) . There’s nothing like the satisfaction of seeing things just come together, and your design coming to life.

At 37signals, the designers (Jason, Ryan) have their own sandbox and uses the same Subversion repository as developers (Jamis, me). Thus, they can make changes to their local version of the application, switch to the browser and refresh. There's no compilation phase. The templates are not overburdened by programming constructs thanks to a strong domain language.

Working on the same code base and sharing the same tools is an empowering environment that unifies the team and breaks down barriers between professions. It's in that mold where magic happens.


Challenge by Robby Russell on May 01, 16:53
Working on the same code base and sharing the same tools is an empowering environment that unifies the team and breaks down barriers between professions. It's in that mold where magic happens.

I agree!

At Planet Argon, our designer works in the same IDE as the main developer (me) does. When we began building our PHP/PostgreSQL shopping cart system, she was quickly able to understand the templae system that I chose for the project (Smarty) and was able to do her html/css magic. She completely understood the value of version control (CVS in that scenario) when she was able to rollback changes that she made and decided a day later that it wasn't the right approach to what she was working on. This made for a much more succesful interface to pgCart.

In past experiences, I would usually end up spending a lot of my time (which should have been on programming work) working on design work after a designer would provide templates. I think that this happens a lot with web development as designers are not always familiar with html/css and the idea of editing in some non-dreamweaver program is just beyond their comfort zone. (this is just my experience with designers...)

I hope that more designers look into Rails and speak up about how easy it is to work with.


Challenge by Pedro - Brazil on May 02, 16:21

Just a small correction: the link to Basecamp (with https) is showing a client login screen or something like that.

Challenge by Justin Palmer on May 02, 18:27

Very nice writeup David, I've expanded on this topic and also Robbies post a bit more "here":http://www.encytemedia.com/article/14/designers

Challenge by Alex on May 02, 20:00

Could you explain your development environment a bit? We're about to run into some issues @ work with the way we're currently developing off the same codebase and would love some tips :)

Challenge by Robby Russell on May 02, 23:18

Alex,

In our environment at PLANET ARGON, our designer does html/css work in KDevelop, which is the same program that I do a lot of the php, python, and ruby development in. We have a small team, so we utilize the same source tree at the same time (kdevelop shows a different icon next to a file listings if that file is being used by someone else). Each of us commits to a cvs or subversion repository after testing is performed of the changes. This allows us to test as we're developing on a development server.

Each morning, for a project that is in development, we have a script that builds a testing version of the web application and we run a few tests against this before we continue working on new features. (sometimes we find that bugs might not be noticed at the end of a long day and test again in the morning before moving on...)

This is just a brief example of how the programming and html/css work is done in the same development programs and environment.

Challenge by Rainy Day on May 26, 21:19

RoR looks really great. I am excited to give it a spin. But all the hype is starting to drive me nuts. For instance:

"Rails is the middle ground for a lot of incredibly interesting interactions between designers and programmers."

I fail to see how this is incredibly interesting. Using templates and giving designers their own source checkout is hardly a new concept. We've been doing it for years with PHP. Im sure thousands of others have as well using the language of their choice.