Getting Sass(y) With Client Handoffs
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?
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.
Weigh the pros and cons of using a CSS preprocessor in the first place
Developers of all walks of life (myself included) can often have difficulty reconciling their preferred method with what’s best for the client and/or end user. It’s important to establish a process internally, but client work requires you to be more flexible than if you were just working on your own project. That’s not to say that you should ditch your preprocessor altogether if a client will be making code changes after the hand off, but it’s really up to you to determine whether or not they have the technical bandwidth to adhere to your workflow.
Have a backup plan
Before you hand off your finished site, you should have your raw files (.scss in our case) backed up and in version control. Whether or not you choose to save versions of the compiled code is up to you, but at the very least, you need some record to compare the files to if they are changed. It might not always be possible to simply diff against your files when a change is made, but you can at the very least have a starting point for when you absolutely need it.
We are fast approaching the end of the honeymoon period with CSS preprocessors such as Sass, but that doesn’t mean we should throw in the towel on the handoffs just yet. Not every client is going to be on board with learning a new technology, but openly communicating with the eventual recipient of your files very early on in the process can help you avoid the pitfalls. Who knows, maybe one day all of us Sass devotees will make believers out of everyone!