Designers, Developers, and the x_ Factor
Our team is lucky enough to be in a position where we have both designers AND developers working on the same code base in parallel.
Since Ruby on Rails adopts the Model-View-Control pattern for separating business logic from the presentation layer, we’re able to give our designers a lot of breathing room to to design the interface, whether it’s for interaction or aesthetic reasons. However, sometimes this breathing room has resulted in small bugs slipping into the application interface. In general, nothing disastrous, but each bug that slips into the queue, slows down the project and we want to avoid as much of that as possible.
I’d like to share a few issues that we’ve seen occur on various occasions, and then show you what we’ve done to avoid them happening again.
Scenario #1: The case of the changed div id, (victim: designer)
- Designer adds a few HTML elements to the page, defines an
idon a
`<div>` tag and styles it with CSS.
```text
- A few days later, a developer needs to make some changes, tests it
```text
in their favorite browser and commits.
```text
- Later, the designer doesn't understand why the styling is all messed
```text
up. "It *was* working fine."
```text
- ...minutes, hours... go by where the designer tries to track down
```html
the issue. "Oh! Someone renamed the `id` in this `<div>` tag. Sigh."
```text
- Developer apologies, but explains that he needed to do it because he
```text
needed to make it work with his new RJS code.
```ruby
**Scenario #2:** The case of the changed `div` id, (victim: developer)
- Developer is implementing this cool new Ajax feature into the web
```bash
application
- The code relies on there being one or many HTML elements in the
DOM with specific `id` values defined.
```ruby
Example: `<div id="notification_message">`
- A few days later, a designer is making some changes to the layout
```html
and needs to restyle some of the view that this `<div>` tag is
defined. Designer decides to change the id to a different value for
any variety of reasons. (or perhaps they changed it to use a class
instead of styling it by the id). Often times, we don't know who set
the id or class... and many times the developers aren't savvy enough
with HTML and designers end up cleaning things up a bit.
```text
- Later, code is checked in and designer didn't notice that the Ajax
```text
was now breaking as they weren't focusing on just the layout.
```text
- Day or two later, developer sees bug, "Feature X isn't working,
```text
throwing JavaScript error..."
```yaml
- Developer is confused, "Hey, that was working! What happened?"
- Developer tracks down the problem, discusses with designer, they
```text
figure out a solution. Problem solved.
```ruby
I could outline a few other examples, but I really wanted to highlight
these two types of situations, as our team has seen this happen on
several occasions. Luckily, we've learned through these experiences and
have taken some measures to try and avoid them in the future.
## Moving forward (together)
Both of the examples above, were essentially the same problem, but
resulted in problems for a different role in the design and development
cycle. While, I've definitely been the victim of #2 several times
myself, I know that I've also been the guilty of #1. So, what can we do
as designers and developers to work with each other without causing
these little problems from occurring? (remember: many little problems
can add up to a lot of wasted time spent resolving them)
Several months ago, I had a meeting with
[Chris](http://chriszgriffin.com/) (User Interface Designer) and
[Graeme](http://blog.imperialdune.com/) (Lead Architect/Developer) to
discuss this very problem. At the time, we were implementing a lot of
Ajax into an application and were occasionally running into Scenario #2.
We discussed a few possible ways of communicating that, "yes, this div
id should NOT be changed (without talking to a developer first)!"
### Idea 1: Comment our "special" HTML elements
We discussed using ERb comments in our views to do something like the
following.
```html
```html
<% # no seriously, please don't change this id, it's needed for some Ajax stuff %>
<div id="notification_message">
...
We all agreed that, while effective, it was going to clutter up our
RHTML code more than any of us desired.
**Team Response:** *Meh.*
### Idea 2: Reserve id's for developers
Another idea that came up, was to ask that designers only use classes
and ids wold be used by the developers when they needed it.
```html
```html
<div id="developer_terriroty" class="designer_territory">
...
Chris pointed out that this wasn't an ideal solution as there is a
distinct case for when to use ids versus classes.. and he is very strict
about adhering to the HTML/CSS standards.
**Team Response**: *Not hot about it...*
### Idea 3: Naming convention for Ajax-dependent elements
The third idea that was discussed, was specifying a naming convention
for any elements that were needed by our Ajax code. We played around on
the whiteboard with some ideas and settled on the idea that we'd prefix
our id's with something easy to remember for both designers and
developers.
We agreed on... `x_` (x underscore), which would make an element id look
something like this:
```html
```html
<div id="x_notification_message">
...
**x == ajax**... get it?
While this adds the strain of typing two more characters to much of our
RJS code, we don't run into Scenario #2 very often anymore.
````ruby
```ruby
render :update do |page|
page[:x_notification_message] = 'Something exciting happened... and this is your notification!'
page[:x_notification_message].visual_effect :highlight
end
or in client-side JavaScript (where we also use this)...
```bash
```javascript
$('x_notification_message').do_something
```
I find that this helps our team keep a clear distinction between what
can and shouldn’t be changed in the views by our designers. Sometimes
they have a good reason to do so, but they know that if there is x_,
then they should ask one of the developers on the team for assistance in
renaming it without causing any problems in the application. It also
allows our designers to add classes to these elements, or style the id
that we’ve defined.
Team Response: Wow, was that all we needed to agree on? Hooray!
This leads me to some other problems that have/may come up, but I’ll discuss that in my next post on this topic, when I’ll show you how we can use RSpec to avoid these sorts of designer versus developer problems.
If you’re working in a similar environment, how are your designers and developers working, together, in perfect harmony?
Until next time, remember to hug your designer. …and if you’re still having developer design your applications, consider hiring a designer. ;-)
UPDATE: changed examples after a few comments about using div_for as another solution. (see comments for details)
