If you are unfamiliar with Sass:

I recommend you check out our very own Brian Krall’s introductory post on Sass and Compass before reading on.

Imagine this scenario:

Your little brother’s birthday is coming up, and you’ve decided to make him his own custom screen-printed t-shirt. Thankfully, due to your extensive art education, you know how to print impeccable shirts in the preferred method. You come up with your design, do the color separations, burn the screens, and print a fantastic 3-color masterpiece. On the big day, you hand your brother his gift, and he decides that he wants the letters to be red instead of white. He goes to his room, grabs a big red Sharpie, and haphazardly scribbles all over your handiwork.

Unhappy with the result, he hands you back the shirt and tells you that it doesn’t look right, and that you need to fix it. Little brothers are the worst.

For better or for worse, making the choice to commit to a particular craft ultimately means that you will have to retain a certain bit of continuity once it leaves your hands, whether the recipient is an awful hypothetical sibling, or an otherwise wonderful client that might not know or care about the craft involved in the delivered result.

For the better part of the last year, Duo has been using Sass as our CSS preprocessor of choice, to great effect. We love its efficiencies, its structure, and how it motivates us to be better-organized coders. Despite our love affair, our front end team is running into a dilemma that has plagued back end developers for years: how do we manage beautifully crafted code with a client who is going to want to tinker, and even more difficult, what happens when the client breaks our toys and hands us back the pieces and asks us to fix it?

There is so little about this particular question that the best intel I was able to dig up is an interesting twitter conversation between designer Scott Kellum and front end dev, Patrick Fulton:

At this point, we’ve only had to do a few handoffs with sites coded in Sass, but in our experiences so far, Scott’s point seems to be the exception, rather than the rule. Clients that have the inclination to tinker are likely versed in basic CSS, and may be averse to learning a new technology that is like CSS but might not seem ‘worth it’ for them to learn when they can just bypass the process and get into the compiled files, which can cause major headaches in the future. Although Duo is in the process of working out this balance ourselves, we have some general recommendations for how to approach this issue. Gauge your client’s technical expertise and desire to make changes to the final result Ideally, we would love it if our clients only wanted to make configuration and content changes once a site is handed off, leaving code out of the picture. However, when we’re dealing with more hands on clients or “power users,” we are often asked to design and code in a way that will eventually allow the client to make presentational changes after handoff. Sometimes this means enabling some sort of configuration option that allows for customization of color, layout, etc. (yikes), but it can also mean that they’re looking to get in and make changes directly to CSS files, or with proper training, SCSS files. If we know going in that we’re dealing with power users, we can make a better informed decision about the level of technical skill required to work with the files that we’ll be eventually handing off, and coding and documenting along the way with that end in mind. Clean your room before you tell someone how to clean theirs The first step to properly introducing a foreign workflow to a client is to have yours as explicitly defined as possible. After using the Sasson base theme on multiple Drupal projects, we’ve found that the built-in compiler is actually less handoff friendly because it can cause permissions issues. Our new workflow of working locally in MAMP and compiling the Sass ourselves is slightly more complex, but allows us to control how we compile our code. It’s certainly not a given that a client will be able to follow our workflow exactly, but having our process straight allows us to better work with the client.