At Drupal Camp London 2013 James Panton presented
a methodology for implementing designs in Drupal without resorting to custom
theme development. At this years Drupal Camp I pulled together two BoF
(Birds of a Feather) sessions to continue the conversation and discuss
prototyping designs, atomic design, and
challenges of incorporating design activities into development workflow.

In recent posts I've talked about
prototyping
and a bit about
using Jekyll for prototyping.
In many ways this discussion is a continuation of those ideas, but also
much more general in it's scope, and more wide-reaching in it's potential.

Death of the Themer?

I've become interested in this area after recently facing challenges bringing
design activities into the development workflow of an agile project. But first, for
some context, let me explain where this all began...

Last year, Jim presented a methodology for implementing designs in Drupal
without having to do any custom theme development.

First, Drupal is stripped of all it's markup. Jim presented to a packed
room at Drupal Camp London, and received a big whooping
round of applause when he showed naked Drupal markup. Perhaps indicating the
general level of frustration the developers/themers have from battling with
Drupal markup. Also, there's a general preconception that Drupal suffers very badly
from "Divitis", "Classitis" and "Span-mania". This demo showed that this need
not be the case.

Next, markup is added back in bit by bit to match the markup in the flat
HTML/CSS design. This means that the eventual markup produced by Drupal should
exactly (or almost!) match what the designer originally intended. The rendered
HTML is therefore cured of it's divitis (contains much less bloat),
works with the CSS styles from the design with little or no tweaking, and
can make use semantic HTML5 tags.

The tools used to reset Drupal default markup include:
Semanic Views,
Display Suite,
Panels,
and a fork of Semantic Panels
that I can't seem to find a reference for.
Fences can also be useful, although
functionality to override field wrappers is also part of Display Suite.

One of the main benefits of this approach is that it allows designers and
Front-end developers to work freely, using whatever tools they want, and
without consideration for any of Drupal's (perceived) limitations. There have
been lots of really cool developments in front-end, including CSS and HTML
preprocessors, and the multitude of CSS and JS frameworks. This approach allows
designers, front end developers, UXs, and IAs to take advantage of all of these tools
when prototyping sites.

During the BoF sessions at this year's Drupal Camp London a few limitations and
disadvantages were discussed. This methodology moves the implementation of
design from development (writing code) to configuration. This can become quite
repetitive as each individual bit of output has to be configured with appropriate
resets and the correct wrappers to build up the markup.

Custom Plugins?

In the BoF sessions I presented a methodology that I had been playing with,
inspired by Death of a Themer, whereby designs are implemented
in a similar way, without the need for a custom theme. Drupal markup is taken
to a "full reset" state, and then just the required markup is introduced
through various plugins.

This differs from the original methodology as it does not use configuration
to add wrappers back in to fields, view modes, views, panels, etc. Instead,
the markup is taken from the prototype (flat HTML and CSS) and copied into
"plugins". Various plugins are used:

• Display Suite plugins to add markup to content/entities in various view modes.
• Views styles to output list markup
• Panel's style plugins to add "box" markup, and,
• Panel's layout plugins to add layout markup.

The result is the same markup as the flat prototype, and the same result
as with the original Death of a Themer approach, but with much less configuration
required.

The real big win for this approach, is that the components of the design are
reusable across various content types and sections of the site without
having to repeatedly configure each occurrence.

Building out these plugins for every bit of a design might seem like over-kill
and more work than is really necessary, but it is a much more scalable way of theming
as you end up with design components that can be reused across the site.

This version of "Death of a Themer" means the Themer is replaced with a developer,
rather than a site-builder, as the emphasis moves away from configuration towards
writing custom plugins in code. However, I think a lot of the grunt work can
be automated, as I'll explain in a bit.

Atomic Design

I saw parallels between this approach (of reusable theme components) and the
emerging trend of atomic design.
In fact, I think atomic design is more than
just a current trend but a real leap forward in design methodology.

We're not designing pages, we're designing systems of components.
-- Stephen Hay

While producing an atomic design the designer is effectively breaking down the
design into components. This is exactly what a good themer does when they take a design
and decide how to implement it as a Drupal theme.

From Design to Theme

When a designer hands over a design (let's assume static HTML and CSS) the
developer (or themer, or site-builder) has to make several decisions about
how this will be implemented.

• Assumptions are made and things get "lost in translation"
• Compromises are made due to limitations in implementation (i.e. limitations of the CMS, content model, etc)
• Markup is augmented to add in extra properties like RDFa, etc

Agile

There shouldn't really be a "handover" of design. The style guide / atomic design
or static mockup that is the result of prototyping should evolve as the product
evolves.

If something comes up that needs design we go back to the static HTML/CSS to
implement it. If using atomic design, this means adding any required "atoms",
"molecules", etc.

If changes have been made as a design is implemented these need to be flowed
back upstream to the style guide so that further development of the design can
happen, and then (some of) the conversion process is repeated to bring across
new design elements into the theme/templates.

This process can be hard to manage and bring duplication of effort into
the process.

If we can automate some of the steps involved in going from static HTML and CSS
to Drupal theme then we can move towards a more agile, and robust design-dev
workflow.

Proof of concept

Automatically generating a Drupal theme from either a style guide, atomic design,
pattern library, static mockup, prototype (or whatever you want to call it!)
might sound like a crazy idea, but I've got a working proof of concept.

I decided to start from just pure HTML/CSS. After experimenting with static
site generators (HTML preprocessors), and CSS preprocessors like
SASS, I decided that it was best to take pure HTML/CSS as the starting point.
This works because every design eventually ends up as HTML/CSS. It's the
language of the web, so it's unavoidable. It means designers can use
any combination of tools they like, as long as they produce HTML/CSS as the
end result.

As an example, I'm using Jekyll to compile the static mockup, and Compass
to compile the CSS, but this could be any combination of tools, or just
hand-crafted HTML and CSS.

The next stage is to add annotations into the source of the HTML to
identify and describe each of the design "components".

I don't have any terminology yet. Drupal has it's own jargon, as does
SMACSS, Atomic Design, OOCSS, KSS, etc. I'm not sure what to call
things. I'm tending towards a combination of Atomic Design and Drupal
terminology, but this will change.

Annotations

There has been some discussion in the design community about
Pattern Library Annotations
documentation, etc.

I want to use annotations in designs so that they can be automatically
parsed and converted.

In this proof of concept, annotations in the HTML source code map directly to
the appropriate Drupal templates and plugins.

I'm using the x- prefix for my custom attributes. This mechanism is intended for use
in vendor prefixing for vendor specific attributes. It distinguishes them nicely from
data- custom attributes, results in valid HTML5, and therefore I think it's an
acceptable abuse of the feature.

For example, annotate a certain part of the source code as being responsible
for layout and it will be automatically compiled into a Panels Layout Plugin:

<div x-drupal-type="layout" x-drupal-name="front_page" x-drupal-label="Front page" x-drupal-no-wrap>   <div class="container">     <div class="row">     <div class="span8" x-drupal-region x-drupal-name="content">     ...     </div>     <div class="span4" x-drupal-region x-drupal-name="sidebar">     ...     </div>   </div>  </div> </div>

Another example, this is content shown in a particular preview style called "Box".
It maps to a Drupal view mode:

<div class="box" x-drupal-type="display" x-drupal-name="box_teaser" x-drupal-label="Box teaser">  <img src="" width="100" height="100" alt="" x-drupal-region x-drupal-name="image" x-drupal-no-wrap>  <h6 x-drupal-region x-drupal-name="title">Easy to use</h6>  <p x-drupal-region x-drupal-name="summary" x-drupal-no-wrap>    To get started, you select the desired sample and base the entire website on it. It’s that simple!  </p></div>

Many other attributes are identified and the system currently supports
panels layouts, panels styles, views styles, display suite (view mode templates),
menus (kinda), and image styles.

During the compilation process the various components are identified and
the appropriate plugins are created. Any required static files, such as
CSS and JS are copied across. Any content in the various regions is removed
from the markup, and the generated plugins therefore only contain the markup
to wrap the various parts of Drupal output.

You can see the (very!) rough proof-of-concept here:
https://github.com/darrenmothersele/hyde

You really shouldn't try using this yet, but if you insist, install the
modules on a Drupal site with Display Suite, Panels, etc,
then enable both modules, and configure to point at the folder with your
HTML/CSS design. Then click the "Sync" button to parse your design files and create
and register the appropriate plugins based on the design.

Warning: You are probably better off waiting for the next version or some
actual documentation!

Rather see it in action?

If you would rather see it in action, then come along to the next
Drupal Show and Tell
where I'll be demonstrating the early version of the theme generator and asking for feedback!