Is your creative team completely opposed to designing in code? They shouldn’t be. Here’s a hybrid approach to rolling custom Drupal themes that has the potential to significantly streamline your workflow and ensure greater visual consistency throughout your project’s lifecycle - all thanks to Style Tiles.

For the uninitiated, a Style Tile is a design tool for chasing out the overall visual tone of a site - illustrating colors, textures, typography alongside some sample imagery and graphics. Style Tiles are traditionally assembled using a graphics production tool like Photoshop or Illustrator, much like the final artwork that’s delivered to your client before it’s sliced up to make sprites sampled for hex color codes - but I’d like to to argue that it’s time to rethink that approach.

If you’ve seen one Style Tile you’ve more or less seen them all - at least within the scope of a given project. Most designers tend to work from a common starting point in order to get the ball rolling on setting the general tone for a site (see the prominently featured “Download Template” button on the Samantha’s site, above). Consistently placing UI elements in the same location across multiple tiles goes a long way towards helping clients to focus on the differences between the visual elements across multiple tiles. It’s also a great way to avoid the trap of becoming attached to a specific overall “layout” - something much more well-suited to wireframes.

In other words, consistency is a good thing here. But over the past few months we’ve become fans of cutting all of our Style Tiles from the same basic cloth for entirely different reasons: more rapid prototyping, reduced time spent on theming and a lot more love for widely used but consistently overlooked UI elements.

Building Style Tiles as Functional Mockups

Let's assume that your project calls for a Style Tile similar to the one below that our design guru Andy put together for a recent project, First Presbyterian Church of Ann Arbor.

Generally a pretty straightforward piece of artwork - as you’d expect of Style Tile. It’s pretty likely that your designers would whip up something similar in Photoshop; once they finished the initial draft you can safely bet that subsequent variants would be direct derivatives of that first piece of artwork. So, since they’re probably already doing it anyway why not just ask your designers to commit to a standardized overall layout for all of their Style Tiles - and then collaborate with your themers to assemble them directly in markup instead?

Just about everything going on in Andy’s Style Tile translates to basic CSS rules. Sure, the first time around you’ll incur the initial overhead of writing some basic markup in order to get the basic structure in place - but after that point all subsequent tiles will be a cinch. There should be very minimal changes to your markup between tiles (ideally you’d be reusing the same HTML over and over again), with all visual differences governed by iterations on the stylesheets. CSS at its best!

Since you’ll be primarily swapping out colors, images and typefaces, tweaking margins or padding and adjusting scale the majority of your work won’t go beyond fundamental CSS definitions, which invites very rapid prototyping - and iteration once your client provides feedback. With some foresight and a generous helping of wrapper divs laden with classes for your markup even potential curveballs like the concave edges in Andy’s artwork above should be a cakewalk. Standardization of code also ensures many of the same benefits that I mentioned previously, but you can probably already see obvious added benefit. You’ll already have a huge head start on rolling your own custom Drupal theme by the time a tile receives final signoff.

There is no second step of translating a mockup to markup. And all of this gets even better if you take the time to give your Style Tiles some Sass.

Giving Your Style Tiles Some Sass.

If you’re going to be defining the color palette for your client’s project on the fly why relegate your CSS rules to changing a few link colors or defining the styling of the typography used for a heading tag? Throw those hex codes into Sass variables and set up your @font-face embeds as Compass mixins so that they’re infinitely reusable throughout the site.

Talk about visual consistency. Not only will your client be seeing an exact rendering of how core styling will appear on their site, but you’ve already guaranteed that once your mockups are done and ready for production those link colors and headings will be identical everywhere. Not to mention that If you isolate your color variables and typography into their own separate Sass file you can separately pull all of your work into both your Style Tile and your custom theme with a single @import. Receive an eleventh hour request from a client to tweak a color that could cause havoc in a particular context - or ruin the overall design altogether? No problem, just change a single hex code and you’ll have a revised Style Tile to back up your argument against the change - as well as a fully updated site that you can browse for potential conflicts like color contrast.

Using the Style Guide Module to Automate Basic Theming.

Hopefully you’re convinced by this point - it’s not exactly a hard sell - but there’s even more benefit to moving away from static Style Tiles. From a themer’s perspective, one of our favorite Drupal modules is Style Guide - which automatically generates a page containing the vast majority of Drupal’s default UI elements, all gathered into one place and rendered with the markup that’s output by your theme. In other words, you can see exactly what structure and classes are going to come along for the ride with breadcrumbs, pagers, form elements and other common pieces of functionality. With your colors defined as variables and font-face mixins ready to go alongside other basic elements like buttons and horizontal dividers that have already been defined in your Style Tile, it's a cinch to expand on your existing stylesheets to make the mess of UI components that show up in the Style Guide. Talk about a cakewalk: all of the little bits and pieces of your UI that might not otherwise get addressed in your design mockups are already covered and your designers can see exactly what they’ll look like or - gasp - lift some styles directly from the Style Guide with screenshots for use in their pixel-based artwork of page mockups.

While it’s pretty apparent by this point that you’re already looking at some significant streamlining of your process, the real icing on the cake is reserved for those of you who habitually work from the same base theme - Omega or Zen, or even something of your own making. Why not cut directly to the chase, lifting markup directly from Style Guide page and reusing it to the greatest extent possible as the basis for your functional Style Tile template? Don’t be shy about copying and pasting the classes found in the generated HTML on the style guide page into your markup so that fully usable CSS is being written for you automatically every time you put together a new Style Tile. While you're probably not going to be illustrating styling for every last fieldset in the tiles you present to your client this strategy will still go a long way towards tackling many of the the usual suspects like headings, links, buttons and backgrounds.

Time to Tear Down Those Silos

So there you have it. Now, when your Style Tiles debut, your clients will be seeing the exact visual treatment applied to the exact same markup that will be used for their live site. A good chunk of the styling for common elements like headings, links and buttons is done and ready for production. With a little extra love and some help from the Style Guide module you can define basic styling for many of the other UI elements before your designers have even created a blank canvas for their page mockups. And, thanks to the power of Sass, you have a highly reusable and extensible basis for building out the remaining styles that are dictated by their finalized artwork.

Having trouble convincing your creative team to jump on board with this approach? While skipping Photoshop altogether might lead to the greatest level of efficiency, browsing Google Fonts and tweaking styling in CSS might be a hard sell as an “improvement” to their process. Why not try a drastically simplified mood board for internal use - a simple palette of visual elements that’s used for internal reference and not concerned with presentation. Designers who aren’t ready to code can then hand their rough thoughts off to your themers to start a working dialogue in their own language.