What do you think about Drupal’s theme system? What’s your preferred way to change the appearance of a Drupal site? As with many things, that depends.

Your background and skills are going to have a big impact on what you need out of a system that helps change the way a Drupal site looks. What works well for me might not work well for you.

So how do we improve a theme system that needs to work for a wide variety of people? If we simply rely upon solving problems for the people who volunteer to work on core theming issues, we might not make a system that works well for others.

At MidCamp in Chicago, a number of people who have worked on the Twig initiative for Drupal 8 got together and chatted about how to develop personas that would help us understand the wide variety of people who use Drupal’s theme system. We haven’t fleshed these out into full UX personas with an individual’s name, photo and background. We do have some general observations on some broad types of people who interact with Drupal’s theme system.

We may flesh this information out more fully on a permanent page on drupal.org, but I wanted to get this information out to the community. Do you have feedback? Did we miss something obvious? Reach out! These personas won’t necessarily cover every possible person who themes Drupal, but hopefully captures some broad trends we should keep in mind.

Overview of Personas

Let’s start with an overview before we dig into the details.

At the broadest level, it’s important to keep in mind that Drupal serves both Site Assemblers who make numerous changes to Drupal’s appearance through the user interface and only lightly through code, as well as Front-End Developers and Themers who are more willing to dig into code to get Drupal’s HTML, CSS and JS just the way they want to change a site’s design.

Any one person probably fits somewhere on a gradient between changing appearance through UI or through Code. If our system serves people on both ends of that spectrum, hopefully we can also serve all those who fall somewhere in between.

In addition to those working primarily on a particular site’s appearance, our theme system needs to serve two additional groups:

• Backend developers often need to send some piece of site functionality from a module to a site’s front-end, either on the admin side of a site, or sometimes on a site’s front-end.
• Contrib theme developers need to create a wide variety of themes, ranging from those with a design that can tweaked by Site Assemblers to those that serve the needs of Front-End Developers that want fine-grained control over a site’s front-end.

We also broke that gradient of UI to Code into a few important groups:

• CSS Themer: Primarily makes changes to a site’s appearance through the UI, but may make a few tweaks within a theme.
• Front-End Designer: We also called this one Old School Web Designer. Cares a lot about getting a site’s markup just right, but does not give that much of a hoot about which parts of Drupal need to be bent or broken to get the desired result.
• Front-End Programmer: I call this persona a Sassy Drupal Front-End Developer. Has the same level of care with a site’s appearance as an Old School Web Designer, but has more knowledge of all the preprocess, theme hook, and library tools that can be used to get the desired result.
• JS Developer: Would prefer to use a JS framework to implement a site’s front-end. Most likely fed up with Drupal’s current theme system and uses Drupal’s REST API to create a decouple front-end.

We didn’t really discuss this, but I’d suggest there’s also another important stakeholder, the Site Owner who cares how the site looks, but isn’t likely to get involved with how that happens. The Site Owner probably doesn’t care that much about the internals of Drupal’s theme system, but cares a lot about whether that system is flexible enough to create a great looking site. Can Drupal implement a very specific design? Great. Can site editors make changes where needed? Great. Make it so.

Now let’s dig into some of these personas in more detail.

Primary personas

We talked about a lot of different types of people who make use of Drupal’s theme system. However, we singled out a few of those personas as ones we should pay particular attention to when we think about about what to focus on for future improvements. These personas center on those individuals who tend to work most directly with the theme system in service of changing the appearance of a particular Drupal site.

CSS Themer

On our gradient from changing site appearance with UI or code, we looked at this persona as geared more towards working with the UI. This individual might be somebody who actually builds the site in the UI: setting up content types, applying field formatters, configuring views, placing blocks, etc. Or this person could be responsible for tweaking the appearance of a site that has largely been built by somebody else.

This individual might use a contrib theme with a pre-configured design as a starting point, but also could use a more barebones theme to get started. Either way, a CSS Themer is likely to make use of the existing markup, taking advantage of existing classes and markup structures to tweak the design with CSS, or to build up a design from scratch primarily using CSS selectors based on existing markup. A template file might be tweaked here and there to change something like a heading level, but by and large the markup will be left as is.

Big priorities for this group:

• Changes made in the UI should show up on the site.
• Markup should have classes that can be used as hooks for CSS changes.
• Contrib themes with designs that get a site most of the way there can be helpful.

Frustrations for this group:

• Not having specific-enough classes that can allow for consistent style changes.
• Digging into the guts of Drupal to make a change: finding the right template to tweak markup might be intimidating, much less preprocess functions.

Good solid markup with well-structured classes and a robust user interface for change a site’s appearance would be exciting for this group.

Front-End Designer: Old School Web Designer

Think of the old school web designer like a wrecking ball. They know HTML and CSS very well, want everything just so and will destroy anything in their path to get their way with Drupal’s markup.

This group doesn’t really care how the sausage gets made, they just care that the end result looks right. Can I tweak something in the Views UI to fix some markup? Sure. Fiddle with a template? Sure. Hard-code some markup in a block? Okay. Futz with a preprocess function? Well, preferably not, but if Stack Overflow says this will do the trick, okay, let’s go.

This group tinkers their way to the solution and may use inconsistent methods along the way.

They’ll probably use mostly HTML and CSS to get a site to look a certain way, but they may use some jQuery along the way, too. The way they do so may or may not jive with Drupal’s JS APIs. Drupal Behaviors and Settings… maybe?

This group wants:

• Great UX
• Streamlined markup
• Easy access to variables in templates to get the right markup

Frustrations:

• Overly strong CSS selectors
• Death to div-itis!
• Digging too far into the backend

Finds exciting:

• Component-ized front-end code
• BEM/CEM classes

Front-End Programmer: Sassy Drupal Front-End Developer

These folks know how Drupal works and use it as intended. They’re skilled with site building, preprocess functions and render arrays. This group too cares a lot about the markup Drupal output, and they know exactly how to squeeze that markup out of Drupal, ideally in code rather than config.

This group also likes working with Sass and a front-end workflow. Their themes probably use Grunt or Gulp to build production code that then gets hooked into Drupal through the library system. When they use JS, they do so with Drupal’s JS APIs, making use of Drupal Behaviors and Drupal Settings as needed.

Does every person who might fall into this category know every bit of how Drupal works? No, everybody has gaps, and again, these are all gradients. That said, there certainly are those that do front-end development with Drupal that make use of most of the tools available within the theme system.

Wants:

• Clean, extensible implementation
• Good documentation

Frustrations:

• Weird inconsistencies and bugs
• It takes how many template overrides for just this one component?
• Dear Lord how do I drill down through these variables for the data I want to use with my markup?

Excited by:

• Great architecture
• Component-based theme system

Full disclosure, this is the persona someone else said I fell under, but I found myself resisting the label of “FED Programmer.” I feel like I have a good handle on how the theme system works, but I find myself running into gaps and squinting at Stack Overflow posts like anybody else. When I started working with Drupal back in the day, I definitely would have fallen into the CSS Themer category, tweaking a few things here and there. I also would have found myself in the Old School Web Design category along my journey. As I’ve continued on, I’ve had to learn more about the theme system internals to get things done. I still consider myself a markup nerd at heart.

It’s important to keep in mind that none of these personas are intended as value judgments. We all come to Drupal at different points, and it’s not unreasonable to take different approaches to get the end result we want. Any given individual might not relate with every aspect of a persona, but hopefully we’ve touched on elements in each persona that an individual will find familiar when looking across all three.

Secondary personas

While the primary personas tend to work more directly with changing the appearance of a particular site through Drupal’s theme system, these secondary personas work in more indirect ways with Drupal’s theme system.

Contrib Theme Developer

In many ways, the contrib theme developer should be considered a flavor of the FED Programmer persona. These individuals know Drupal very well and put that knowledge to work creating contributed themes on drupal.org.

Contrib themes may have complex programming structures that don’t fit typical patterns, often to allow admin control of how a theme looks. Complex programming might also be needed to shoehorn an opinionated framework like Bootstrap or Foundation into Drupal. Or perhaps to abstract Drupal theming concepts into something less Drupal-y.

Wants:

• Make administrative controls for a theme
• Create a tailored experience above and beyond Drupal
• Solid APIs

Frustrated by:

• Themes can’t depend on modules or do the things modules do, which makes certain complex theming tasks hard or impossible

Excited by:

• Allowing themes to require an associated module would allow more advanced theming and administrative controls

One of the biggest wins from this discussion was realizing the importance of letting themes depend upon a module. In Drupal 8, a lot of form controls have been moved into Form classes, but themes can’t have OO classes, only procedural code in a theme-settings.php file. It’s unlikely we’re going to let the autoloader pick up classes defined in themes, so allowing a theme to depend on a module would be a big win.

This matters for the overall ecosystem of Drupal, because it’s the contrib theme developers who create themes that other primary personas depend on. The CSS Themer in particular wants to see more pre-designed themes, so helping Contrib Theme Developers helps the CSS Themer.

JavaScript Developer

The JS Developer could also be considered a flavor of the FED Programmer. That’s not necessarily true: we defined this persona as a front-end developer with a high level of JS expertise, which might or might not involve knowing how Drupal works. This could be somebody who was worked with a Drupal a lot, but now prefers working primarily in JS. Or this could be somebody who lives and breathes JS and doesn’t have much interest in learning how Drupal works.

Those who prefer to work with JS frameworks like React, Angular or Ember are probably most interested in interacting with Drupal through a REST API in order to set up a decoupled front-end.

These individuals likely have a programming mindset, and when they do interact with Drupal, that’s likely to be with a code-heavy solution.

We didn’t get too far into discussing this group’s wants and frustrations.

A lot of discussion in the Drupal community over the last few months has been in essence how to pull this group of developers more tightly into the Drupal fold, working more directly within Drupal rather than through a fully decoupled front-end. The primary suggestion has been that by putting a JS framework in core, we’ll either get these developers back or pull in new developers.

I’m personally dubious. Even if we pull in one framework, that’s not necessarily going to entice JS devs who prefer another framework. And it’s likely that in a year or two, another framework will be all the rage.

However, I also believe that we can improve the JS in Drupal core without necessarily using a framework. There are certainly a contingent of JS developers who don’t necessarily prefer to use a monolithic framework. Solid modern JavaScript with some helpful libraries that play well with a PHP-based content management system could be attractive to this group. But that’s a topic for another post.

Back-End Developer

The typical Drupal back-end developer works comfortably in PHP. They know how to talk to databases, set up and work with APIs, create modules and move config between development environments.

Satisfying the needs of a requirement is often the top priority. How the markup looks is often less of a priority. They may know some CSS, but probably aren’t as passionate about using BEM classes. Back-end devs tend to know Drupal’s JS APIs inside and out, sometimes better than many FEDs. Code efficiency and security are two top priorities for back-end devs.

Sometimes back-end devs need to develop a feature that appears on a site’s front-end. Drupal’s theme system provides ways for them to do so, ideally without those hippy front-end devs getting in the way. ;) That said, when front-end devs need a certain piece of data for their markup, they often turn to back-end devs, who are very good at getting front-end devs exactly what they need.

Wants:

• Code efficiency
• Security
• APIs to create new features that tie into the CMS

The main takeaway we had from keeping back-end devs in mind is that any changes we make to Drupal’s theme system still need to provide ways for back-end devs to send features to the front-end.

Other Stakeholders

At MidCamp, we didn’t talk much or at all about these other stakeholders. However, I think it’s worth briefly mentioning the stake these other groups in how our theme system works.

Site Builders and Content Editors

We’ve touched on this before, but site builders and content editors often need to make changes in the UI that are reflected on a Drupal site’s front-end. Hard-core FEDs might find this frustrating, but this is key to Drupal’s success. Dries often talks about the Assembled Web, how people should be able to click together a site without necessarily getting a developer involved. That’s what this requires: good UX that allows a less technical user to tweak the site appearance.

Site Designers

A site with a dedicated designer or even a design team has designers as stakeholders too. Those designers might not care how Drupal’s internals work, but they do care that the theme system is flexible enough to implement their design and UX choices. Hearing that “Drupal doesn’t work that way” can be frustrating for this group. A site that works well for FED Programmers who want a a lot of control will also likely be a site that makes site designers happy too.

Site Owners

The owner of a site cares about whether the site achieves its goals. The flexibility and power that Drupal offers means a lot of tools exist to help achieve goals. A site owner also likely cares a lot about how the site looks: if the designers can’t implement their designs, that’s going to bubble up to the site owner. However, the site owner also probably cares how efficient it is to implement that design. When Drupal is hard to work with, either on the back-end or the front-end, that can increase the cost of a Drupal site. Streamlining operations means more ROI. So improving Drupal’s theme system can mean some big wins for bottom lines.

End Users

For somebody visiting a site, they’re going to care how easy is it to use that site. How fast does it load? How accessible is the content to those with disabilities? How simple is it to navigate the site? The more Drupal can build in intelligent defaults, the more likely the end user will have a good experience on a Drupal site.

So what?

One way to apply what we’ve learned about Drupal theming personas is to look back at the improvements we made in the Drupal 8 cycle to see who is helped by those improvements.

The Twig initiative helped to make more of Drupal’s markup available for tweaking through templates rather than through preprocess functions. That’s a huge win for the Old School Web Designer who can now more easily get just the right markup.

The creation of the Classy and Stable base themes allows us to provide two flavors of Drupal markup: one with lots of classes that makes the CSS Themer happy and another that’s more barebones, which thrills the Old School Web Designer and Sassy Drupal Themer (and maybe some Contrib Theme Developers too).

The REST improvements are a big boon to the JS developers who want to create decoupled front-ends.

The libraries system allows us to load CSS and JS only when those assets are needed: with the advent of http/2, that could create big performance wins. Combined with the Dynamic Cache and Big Pipe, that could mean big performance wins. That’s great for End Users, which is going to make Site Owners very happy.

What about future improvements we’re talking about right now?

As mentioned before, the whole discussion on including a JS framework in core is at least in part about how to keep JS Developers inside of Drupal instead of outside Drupal.

However, that discussion is equally about how we improve Drupal’s admin UX. That would benefit site builders, content editors and probably CSS Themers a great deal.

We’ve also discussed moving towards a component-based theme system. That could have big benefits for FED Programmers and Old School Web Designers. Back-end devs might also find creating components a compelling experience. A component system could also help make an Outside-In approach to site building a lot more doable, which benefits Site Builders, Content Editors and CSS Themers. A component-based system might also benefit JS Developers: many current JS frameworks also rely upon component-based systems.

If we do move towards a component-based theme system, we need to keep in mind the various personas that will interact with it. We not only need to have component templates that make FED hearts sing. We also need to have flexible components where data can be placed into layouts through the UI.

Drupal’s theme system needs both UI controls and fine-grained markup controls for FEDs. Pleasing both isn’t easy, but if we can, Drupal will truly thrive.