Collaborative Development Practice - a.k.a. Don't touch my stuff

Posted on 28 September 2011 by Pete Duncanson Tweet

We're considering dropping ID's in our CSS selectors in an effort to help make collaborative development between design and development teams safer and more efficient.

I've always been keen to follow and contribute to various discussions about how and what designers should be able to do and I know Pete has similar interests and follows a wide range of developer blogs and discussions to keep up to date (not to mention the enormous book pile he has).

It keeps us pretty close to at least being in touch with the cutting edge of design and development practice but we do encounter some difficulty with existing projects because we are also paid to maintain and stabilise legacy code before we can do the snazzy stuff so we have to balance that with a process that works well for both Pete and myself.

The designer / developer split

We're lucky at Offroadcode that I'm very definitely a front end type and Pete is very much a developer. Our paths don't really cross in the traditional sense because my skillset gets a project going (design, front end development) and Pete (along with Stephen) deals with all the server side work.

I have a basic grasp of .net and some php from working with WordPress but I don't write it and in much the same way, of course Pete understands HTML but leaves the production work to me while he does the developing so there is, on a very simplistic level, a bit of an overlap here in that we've both been building websites for years and have an understanding of what goes into one but we both specialise in our own areas.

James typically works with

• Visual design
• Wireframing / prototyping
• HTML / CSS
• Umbraco templating

Pete & Ste typically work with

• .net
• XML
• XSLT
• JavaScript
• Umbraco setup/development

Obviously we work very closely every day because we need to make sure that we're heading in the right direction but in a task based environment we have clear and distinct skillsets that compliment each other and enable us to work in a small, agile team.

Should designers code?

Yes this one's been done to death and like everyone else we have a thought but it's the wording of the question that's wrong. "Code" to us tends to refer to "web development" - primarily server side code like .net (and in our case JavaScript) which Pete writes as he's a web developer.

Designers should definitely be able to write HTML markup and CSS because (in our case anyway) this leads to fast prototyping which is something we've tested and proved works. It not only saves time and cost but leads to more efficient designs. I've always written HTML & CSS as well as doing all the visual bits that go with the front end part of my job. I always will.

It's important when you're a small agency such as ourselves to be efficient and agile. It saves time, reduces waste and ultimately leads to better work, produced quicker. It's something we strive for at all times.

Moving forward without ID's in our CSS selectors

Seeing another discussion recently about not using ID's in your CSS selectors got us thinking for a couple of reasons.

The argument made a lot of sense on its own but when applied to working in designer/developer team like ours it could also give us a real division of concerns because the one area we both work on typically is the HTML. Me in the first instance where I often prototype static pages in HTML5 and then later when Pete & Ste are working their magic in the templates output by either Umbraco or the Olympic Holidays site.

Not crossing the streams...

Removing the ID's from the "front end" HTML/CSS development would effectively leave them free for Pete and Ste's JavaScript to use. I can still hook into the HTML using classes as normal and with HTML5 the specificity given by ID's on a "standard" site (things like a logo, header/footer) diminish a little when using HTML5 and ARIA Roles because some of that specific, one off stuff that ID's use can be "replaced" with the appropriate role (eg header role="banner" for the main site header). You also get an accessibility boost for free.

Yes there are still things that will only appear once on the site but I feel the tradeoff of such specificity vs separation of our workflow is worth it as a starting point. As I said earlier, we're always reviewing and tweaking how we can improve so this isn't one of those set in stone rules. More a thought on how this might work for us and potentially for other similarly split teams.

As a front end developer, I can then code away using classes and ARIA landmark roles knowing that any ID's I then encounter are going to belong to Pete or Ste and we don't cross the streams so to speak because we've both got potentially 2 things each to hook into on an element in our HTML. I have classes and ARIA roles which I can style and markup and Pete and Ste have the ID's and data attributes.

Some potential drawbacks

From initial discussion between ourselves in the office, this solution looks like a good way for us to work collaboratively (rarely do we get something in that's for one person alone) on projects and I appreciate that ID's and ARIA roles aren't a direct swap of course but in terms of giving a hook to style specificially there is a replacement option there.

However, this looks very much like something to consider only on new projects from scratch rather than something to try and retrofit into older projects where to be honest, you won't get any real benefit because you'd be reinventing the wheel a bit in those cases.

How do you work in a team?

Got any tips for how you pair designers and developers in teams - we'd love to hear your thoughts and suggestions in the comments or give us a shout on Twitter