I've spoken a great deal recently about architectural priorities. In short, we as software developers cannot eat our cake and have it too. Improving flexibility in one area may hurt performance, while improving usability one another area may hinder flexibility. These trade-offs are not necessarily right or wrong, except in the context of the goals and purpose of the project with respect to its target audience.

But what is Drupal's target audience, and how does that impact our architectural decisions?

DrupalCon Copenhagen was a watershed event in terms of understanding how to conceptualize that question, in my view, based on conversations I had with the likes of Mark Boulton, Jen Simmons, and Sam Boyer. In his (excellent) keynote, Jeremy Keith noted that the HTML5 Working Group had a specific, defined set of priorities:

In case of conflict, consider users over authors over implementers over specifiers over theoretical purity.

That may be a good priority order; it may be bad. That depends on your point of view and your goals. It lays out the order in which different stakeholders should be listened to, and if you come to a decision where you have to screw one group over to benefit another how that decision should be made. Having such a clear understanding of your constituent priority is critical to making good, consistent architectural decisions.

So what are Drupal's priorities?

Constituencies of Drupal

One of the problems Drupal faces is that we don't have a clear, explicit understanding of how we prioritize our constituencies. As a result, we're struggling with "we're really trying to make it easy, really!" while people are still screaming "I can't !*%! use this thing, Drupal sucks!" Both statements can be true if they are about different constituencies.

If I could be so bold as to describe the Drupal community's implicit, ill-defined design priorities, I would define them like this:

In case of conflict, consider site builders over content editors over programmers over theoretical purity over CSS designers over HTML designers.

That may be a good order or a bad order, but it is the order that, in practice, we seem to follow in my experience. But let's consider what each of those means:

Site builders By site builder, I mean the click-together site assembler. This is the person who creates node types by pushing buttons in the CCK/Fields UI, then clicks through the Views UI, then possibly spends time giving the Panels UI some mouse-clicking love. Content editors The content editors are the site administrators responsible for keeping tabs on content. Not content types, but content. Creating and editing a site's primary nodes. Moderating comments. Etc. Programmers By this I mean anyone who is writing PHP or Javascript code. Pretty self-explanatory, with one caveat: Editing template.php counts as a programmer task. I don't care that it's front-end stuff, it's programming. Theoretical purity This is something of a catch-all for architectural cleanliness, security, performance, non-repeating code, code that non-Drupal-fanboys can comprehend, etc. (For architecture geeks like me, having this be so low on the list is frequently painful.) CSS designers Also self-explanatory. If you spend your days in *.css files, this is you. HTML designers For Drupal, this means people who edit template files. It also includes those whose primary skill is HTML in general.

Notably absent from this list is that weird Drupal-specific role we call "themer". There is, really, no such thing. It's a weird amalgam of template.php-dwelling programmers, CSS ninjas, and HTML gurus rolled uncomfortably into one. That is a fallacy that, I believe, hurts us in our understanding of our own system.

Sorry, designers

Also of particular note is the dead-last placement of the HTML designer. That is actually a deliberate decision, and a consequence of putting site-builders first and foremost. HTML is incidental to Drupal. We treat it as little more than an API.

Drupal treats HTML not as a user base in itself, but as an API between PHP and CSS.

Again, that could be good or bad depending on your point of view. However, consider that artistic web designers, those that actually figure out how the page should look; If they know anything about implementation are going to know HTML and some CSS. They're regular readers of A List Apart, which is all about the new hotness in HTML and CSS. For them, the way Drupal treats HTML as simply a means and not an ends is like nails on a chalkboard. They respond just as violently to it as Drupal's PHP developers do to, say, WordPress's "just dump everything into the template file, even if that means SQL" design. (Note: I'm sure WordPress developers will defend their architectural decisions; I am just noting that Drupal developers are horribly turned off by it, much as HTML designers are horribly turned off by Drupal's template design.)

Of course, there is no way to not have messy HTML while still retaining the preeminence of the click-together site builder. CCK, Views, and Panels cannot let a button-pusher build awesome sites "without writing code" without having ridiculously generic HTML output with every possible CSS hook you might need. And pristine, semantic, just-so HTML cannot be generated by a general purpose tool. Modules like Semantic Views help, but they're really just a short-hand way for HTML designers to hack selected templates. They don't change the architectural design.

Is that a good trade-off? If you're a site-builder, it's a great decision. If you're an HTML-savvy designer, it seriously sucks.

Casual architecture

Similarly, even within the programming ranks the same conflict exists. Drupal tries, culturally, to cater to the "casual, self-taught PHP developer", the "weekend warrior" who knows just enough to be dangerous. We want them to be able to throw up community sites over a holiday weekend to aid in the democratization of the Internet. That's an explicit goal.

The flipside, of course, is that we routinely turn off professionally trained software engineers (which are not the same as programmers), software architects, and anyone who has experience with more traditional architectures. We are the last serious PHP framework to still be struggling with the idea of using OOP. We have been doing a hacked-up Aspect-Oriented Programming approach for years, but didn't even know what we were talking about so haven't always leveraged it intelligently. We collectively don't have a clue about performance. We architect for what sounds like a clever hack without considering the systemic implications... if we bother to "architect" at all. We routinely integrate systems that have no architectural reason for being related in the name of site-builder usability, ignoring the performance and bug-hiding risks that come with that.

We are a weird amalgam of a professional CMS built by amateurs and an amateur CMS built by professionals, with all of the ugliness that comes with that.

Is that a good trade-off? If we want to appeal to the thousands of casual self-taught PHP hackers in the world, yes. If we want to appeal to the thousands of professional software engineers in the world, no.

The real target audience

Of course, as with any open source project the only constituencies that matter are those that do work, and the more work they do the more they matter. Who is Drupal's target market? The people building Drupal.

The practical reality is that Drupal's primary target audience is Drupal consulting shops.

Why? Because most of the leading core and contrib developers work for Drupal consulting shops or are freelance consultants. They're site builders and programmers, and their paying clients are content editors. They are not HTML/CSS ninjas nor designers. It doesn't matter how much we insist that we are the everyman CMS, or how much we care about end-user experience, or how designer-friendly we say we want to be.

When you get right down to it, our target market is us.

Tough choices

Of course, all of that begs the question... is that the right priority for us to have? Should we really favor site builders at the expense of architectural quality and HTML designers? If we want to make Drupal easier for HTML designers, are we willing to sacrifice button-pushing power to do so? (We would have to.)

Is making the admin easier for content editors (as the D7UX project aimed to do) at the expense of programmer frustration a good trade-off? (Maybe?)

As we begin to adopt HTML5 for Drupal 8... who will get to decide where to use what new-and-cool HTML tag? The site builder? The programmer? The HTML designer? I don't know. But I do know that we need to not delude ourselves into thinking that we can let all three do so with equal ease. We have some hard decisions to make, but they must be made explicitly, not implicitly, if we are to survive the next wave in our evolution.