I've spoken a great deal recently about architectural priorities. In short, we as software developers cannot eat our cake an' have it too. Improvin' flexibility in one area may hurt performance, while improvin' usability one another area may hinder flexibility. These trade-offs be not necessarily right or wrong, except in th' context o' th' goals an' purpose o' th' project with respect t' its target audience.
But what is Drupal's target audience, an' how does that impact our architectural decisions?
DrupalCon Copenhagen were bein' a watershed event in terms o' understandin' how t' conceptualize that question, in me view, based on conversations I had with th' likes o' Mark Boulton, Jen Simmons, an' Sam Boyer, Avast me hearties, Hornswaggle In his (excellent) keynote, Jeremy Keith noted that th' HTML5 Working Group had a specific, defined set o' priorities:
In case o' conflict, consider users o'er authors o'er implementers o'er specifiers o'er theoretical purity.
That may be a good priority order; it may be bad. That depends on yer point o' view an' yer goals. It lays out th' order in which different stakeholders should be listened t', an' if ye come t' a decision where ye have t' screw one group o'er t' benefit another how that decision should be made. Havin' such a clear understandin' o' yer constituent priority is critical t' makin' good, consistent architectural decisions.
So what be Drupal's priorities?
One o' th' problems Drupal faces is that we dern't have a clear, explicit understandin' o' how we prioritize our constituencies. As a result, we're strugglin' with "we're really tryin' t' make it easy, really!" while scallywags be still screamin' "I can't !*%, shiver me timbers use this thin', Drupal sucks!" Both statements can be true if they be about different constituencies.
If I could be so bold as t' describe th' Drupal community's implicit, ill-defined bounty priorities, I would define them like this:
In case o' conflict, consider site builders o'er content editors o'er programmers o'er theoretical purity o'er CSS designers o'er HTML designers.
That may be a good order or a bad order, but it is th' order that, in practice, we seem t' follow in me experience. But let's consider what each o' those means:
Notably absent from this list is that weird Drupal-specific role we call "themer", on a dead man's chest, on a dead man's chest! There is, really, no such thin', Avast me hearties! It's a weird amalgam o' template.php-dwellin' programmers, CSS ninjas, an' HTML gurus rolled uncomfortably into one. That is a fallacy that, I believe, hurts us in our understandin' o' our own system.
Also o' particular note is th' dead-last placement o' th' HTML designer. That is actually a deliberate decision, an' a consequence o' puttin' site-builders first an' foremost. HTML is incidental t' Drupal. We treat it as little more than an API.
Drupal treats HTML not as a user base in itself, but as an API betwixt PHP an' CSS.
Again, that could be good or bad dependin' on yer point o' view. However, consider that artistic web designers, those that actually figure out how th' page should look; If they know anythin' about implementation be goin' t' know HTML an' some CSS. They're regular readers o' A List Apart, which is all about th' new hotness in HTML an' CSS. For them, th' way Drupal treats HTML as simply a means an' not an ends is like nails on a chalkboard, I'll warrant ye. They respond just as violently t' it as Drupal's PHP developers do t', say, WordPress's "just dump everythin' into th' template file, even if that means SQL" bounty. (Note: I'm sure WordPress developers will defend their architectural decisions; I am just notin' that Drupal developers be horribly turned off by it, much as HTML designers be horribly turned off by Drupal's template bounty.)
Of course, thar is no way t' not have messy HTML while still retainin' th' preeminence o' th' click-together site builder. CCK, Views, an' Panels cannot let a button-pusher build awesome sites "without writin' code" without havin' ridiculously generic HTML output with every possible CSS hook ye 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-han' way fer HTML designers t' hack selected templates. They dern't change th' architectural bounty.
Is that a good trade-off? If ye're a site-builder, 'tis a great decision. If ye're an HTML-savvy designer, it seriously sucks.
Similarly, even within th' programmin' ranks th' same conflict exists. Drupal tries, culturally, t' cater t' th' "casual, self-taught PHP developer", th' "weekend warrior" who knows just enough t' be dangerous. We want them t' be able t' throw up community sites o'er a holiday weekend t' aid in th' democratization o' th' Internet. That's an explicit goal.
The flipside, o' course, is that we routinely turn off professionally trained software engineers (which be not th' same as programmers), software architects, an' anyone who has experience with more traditional architectures. We be th' last seri'us PHP framework t' still be strugglin' with th' notion o' usin' OOP. We have been doin' a hacked-up Aspect-Oriented Programming approach fer years, but di'nae even know what we were talkin' about so ha'nae always leveraged it intelligently, and dinna spare the whip! We collectively dern't have a clue about performance. We architect fer what sounds like a clever hack without considerin' th' systemic implications... if we bother t' "architect" at all. We routinely integrate systems that have no architectural reason fer bein' related in th' name o' site-builder usability, ignorin' th' performance an' bug-hidin' risks that come with that.
We be a weird amalgam o' a professional CMS built by amateurs an' an amateur CMS built by professionals, with all o' th' ugliness that comes with that.
Is that a good trade-off? If we want t' appeal t' th' thousands o' casual self-taught PHP hackers in th' world, yes. Fire the cannons! If we want t' appeal t' th' thousands o' professional software engineers in th' world, no.
Of course, as with any open source project th' only constituencies that matter be those that do work, an' th' more work they do th' more they matter. Yaaarrrrr! Who is Drupal's target market? The scallywags buildin' Drupal.
The practical reality is that Drupal's primary target audience is Drupal consultin' shops.
Why? Fetch me spyglass! Because most o' th' leadin' core an' contrib developers work fer Drupal consultin' shops or be freelance consultants. They're site builders an' programmers, an' their payin' clients be content editors. They be not HTML/CSS ninjas nor designers, I'll warrant ye. It doesn't matter how much we insist that we be th' everyman CMS, or how much we care about end-user experience, or how designer-friendly we say we want t' be.
When ye get right down t' it, our target market is us.
Of course, all o' that begs th' question... is that th' right priority fer us t' have? Yaaarrrrr! Should we really favor site builders at th' expense o' architectural quality an' HTML designers? If we want t' make Drupal easier fer HTML designers, be we willin' t' sacrifice button-pushin' power t' do so, I'll warrant ye? (We would have t'.)
Is makin' th' admin easier fer content editors (as th' D7UX project aimed t' do) at th' expense o' programmer frustration a good trade-off, Dance the Hempen Jig (Maybe?)
As we begin t' adopt HTML5 fer Drupal 8... Load the cannons, Ya lily livered swabbie! who will get t' decide where t' use what new-an'-cool HTML tag? Shiver me timbers! The site builder? The programmer? The HTML designer, Dance the Hempen Jig I dern't know. But I do know that we need t' not delude ourselves into thinkin' that we can let all three do so with equal ease. We have some hard decisions t' make, but they must be made explicitly, not implicitly, if we be t' survive th' next wave in our evolution.