May 1st, 2005

Designers and Developers, Collaboration and Understanding

0 comments on 1329 words

David Heinemeier Hansson recently blogged about designers and Rails, and Robby Russell also followed up on the post with some questions of his own. I’m responding here with some thoughts of my own in regards to designers, version control, template languages, and collaboration with developers.

Designers and Version Control

Version control is not a foreign concept to designers. We actually have version control for artwork by means of VersionCue from Adobe. It was designed to work with Adobe’s line of products. You can view some images of Version cue here .

You’ll notice that it looks alot like a traditional GUI client for tools like Subversion and CVS . Designers will be more prone to work with a GUI for version control rather than a command line. Why? It’s more natural to us. We are used to working in a point and click environment, it doesn’t mean that we are not capable of using the command line or that we are lazy and unintellegent; It just means we prefer to work with things we are familiar with. You wouldn’t want to tell a .NET developer who chooses to do everything by hand that he had to use Visual Studio’s drag and drop interface and property inspector, or a frontend developer who uses notepad that he must use Dreamweaver’s design view.

If your a developer looking to acquire a designer to work with you, consider taking the time to see if the designer is familiar with version control. If they are not, it won’t take long to get them setup with the tools they need, and a breif explination of what they’ll need to know. If they don’t know what version control is, don’t tell them there first step needs to be “Open the command line and type…”, instead point them to a GUI and allow them to be comfortable in there environment.

The term “Designer” implies more than just knowledge of Photoshop or the color wheel now days. Designers now usually come outfitted with really good knowledge of CSS and Xhtml. If they are capable of learning how to tackle a layer pallete 300 deep and CSS rules and hacks for many different browsers, they are more than capable of learning how to use version control.

Designers and mixed templates

There have been numerous discussions about exposing designers to code inside of templates. Some believe creating a proprietary template language is the answer, it’s not. This doesn’t mean template engines like Smarty , etc are bad. In that since, its personal preference. Template languages are just like any other language, they have to be learned by both the developer and the designer. As much as it is speculated they do not solve the problem of “being easier for the designer to understand”. This is just flawed logic. Designers are not neanderthals, and are more than capable of understanding this: <%= post.title %> compared to this: ${post.title}

So if your going with a template language for the sole purpose of it being easier for the designer to understand, your wrong about designers. The above example is a genralization, but even when the code becomes more complex it still doesn’t make much of a difference. How easy the template is to read, is ultimatley up to you, the developer. If you’ve taken measures to ensure your not performing massive ammounts of logic or worse, littering your templates with code that should be in the model, a designer should have no problem understanding your templates.

As David pointed out:
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.

Designers and secure templates

There has also been the debate about using a template language to prevent designers from having unrestricted access to your application and the core language it was built on. In my opinion, if you believe a designer will have a hard time understanding the core language to start with, what brings on the notion that they are capable of writing a bunch of malicious code? This again is another bad reason to use a template language. If you don’t trust the team members you are working with, then how can you be productive, communication and trust are the keys here.

Conclusion

I do not mean this as an attempt to bash template languages, I think they have there purpose, but don’t make this decision based on the designer; Make this decision because it’s best for your application.

To sum up, we all must work together to revolutionize the web (or desktop). We also should be aware of tools and concepts that could smooth the process between working designers and developers. With this information in hand (and Rails of course ;-) ) we can have a great working relationship and productivity to match it.

Sorry, comments are closed for this article.