Traditional web design has always involved creating flat, two-dimensional designs in wireframes or high-definition design comps. While this process feels natural and intuitive for designers, it presents significant shortcomings when it comes to the increasing demand for modern, responsive websites.

Building a website in Drupal typically follows this process:

1. create low-definition conceptual designs, wireframes, and sketches
2. create high-definition design files in Photoshop
3. configure the site and build out various functionalities
4. create a base theme and apply it to complete functionalities

This process, tried-and-true as it may be, leads to a lot of challenges:

Synchronicity of frontend and backend development

Building functionality is tied to internal elements that sometimes are not exposed to UI at all. For example, integrations with external systems or implementing editorial workflows. This sort of work can represent hundreds of hours from a development perspective, but the theming required is marginal. On the other hand, some parts of web design work--like assembling pages with node listings or just the pages themselves--can involve 10 hours of development and 20 hours (or more!) of theming due to custom Javascript and layouts. In this situation it can be challenging for a busy frontend developer to know how to organize his/her time most effectively.

Clients can't test the site until most of the functionality is done

Theming only after a site’s functionality is ready leads to a problematic situation wherein a web design team can't actually show its client polished work until the end of the project. Theoretically, of course, we can show some functionality or provide elaborate descriptions, but the “bells and whistles” still tend to be missing until a project nears completion. This leads to a huge bottleneck effect as both clients and quality analysts turn their attention to testing a new website on multiple devices and platforms. At this stage, most of the bugs reported will be related to responsive behavior or small changes to theming. This can be a nightmare for frontend developers; they receive tons of work all at once, even as the project is about to finish.

Enabling frontend developers

Frontend developers are forced to learn a lot about preprocess functions and how Drupal works. This whittles down the time frontend Drupal developers have to introduce cool new technologies that exist elsewhere in the frontend world. Despite multiple attempts to make Drupal’s HTML output cleaner, Drupal still produces a lot of code that, most of the time, is superfluous. The truth is the frontend world develops at a faster pace than our PHP tools. New Javascript frameworks mature at lightning speed and we are not really all that good at adopting them. What we would really like to see is frontend developers progressing in their field, rather than getting bogged down by more Drupalisms. But how?

Prototypes to the rescue

Lately FFW has been rewriting the web design process, building prototypes right after designs become available. In fact, the main deliverables of our design work are the prototypes themselves. Technically, the prototypes we build are sets of HTML pages. The idea here is for these prototypes to empower frontend developers to build a site how they see it, instead of how Drupal dictates. Prototypes free up frontend developers to use new technologies and to properly organize code. Another advantage is that prototypes can be built before Drupal functionality is finalized. In other words, clients can start test driving their website early on in the development process and have a clear idea of how the site is going to look and behave. By the time Drupal functionality is ready, all frontend bugs are resolved, specifically the ones related to responsive behavior. There are multiple PHP-based template engines to use, platesphp.com being one. Our developers use assemble.io.

Prototype-based theming

Let’s say you’ve got your prototypes just the way you want them. Now Drupal’s backend HTML should be made to match the prototypes as precisely as possible. The bad news: this is not easy as it may sound. The good news: we’ve compiled some best practices to lead the way.

1. Panels, panels, panels. We use a stack of panels modules. It is pretty simple to build custom layouts out from the prototypes, replacing static blocks with implemented panes.
2. Custom panes with custom templates. In order to control the HTML of custom panes, we create a template file for each one. This makes it easy to tweak the HTML of a single pane as needed. We even display custom panes in lieu of views panes, executing views under the hood. We skip rendering views in order to keep all the theming for one block in one template.
3. Display entities as view modes. For most view modes (different kinds of teasers), we use separate custom templates.

Prototypes make building a website much more exciting and improves the web design process for everyone involved. Backend developers can actually watch the site’s theming implemented as they complete functionality. Frontend developers have more freedom and fewer Drupalisms to remember. Best of all, prototypes increase client satisfaction because prototypes allow clients to feel more involved in the implementation of their projects.