Drupal's audience priorities

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?

Constituencies o' Drupal

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:

Site builders
By site builder, I mean th' click-together site assembler. This is th' person who creates node types by pushin' buttons in th' CCK/Fields UI, then clicks through th' Views UI, then possibly spends time givin' th' Panels UI some mouse-clickin' love.
Content editors
The content editors be th' site administrators responsible fer keepin' tabs on content. Not content types, but content. Creatin' an' editin' a site's primary nodes. Moderatin' comments. Etc.
Programmers
By this I mean anyone who is writin' PHP or Javascript code, me Jolly Roger Pretty self-explanatory, with one caveat: Editin' template.php counts as a programmer task. The sharks will eat well tonight, and a bucket o' chum! I dern't care that 'tis front-end stuff, 'tis programmin'.
Theoretical purity
This is somethin' o' a catch-all fer architectural cleanliness, security, performance, non-repeatin' code, code that non-Drupal-fanboys can comprehend, etc. (For architecture geeks like me, havin' this be so low on th' list is frequently painful.)
CSS designers
Also self-explanatory. If ye spend yer days in *.css files, this is ye.
HTML designers
For Drupal, this means scallywags 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", 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.

Sorry, designers

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.

Casual architecture

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.

The real target audience

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.

Tough choices

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.

Comments

Well said.

Very well said. I dern't have any answers about audience priority, but I've thought fer a while that drupal's direction is bein' driven by dubloons. That is, those drupal shops which be able an' willin' t' fund employees t' work on core effectively shape its architecture. The more patches – an' th' bigger those patches – ye can write, th' more influence ye're likely t' have o'er th' architectural direction.

That's not necessarily a bad thin', just a fact o' life.

So in answer t' "who will get t' decide where t' use what new-an'-cool HTML tag?" I'd say: whoever has th' time t' write, promote an' pursue th' system wide patch it will likely require :)

Not just money

It's not just a question o' a shop fundin' development, though. It's also one's experience. 99% o' me own core work is on me own time, not Palantir's time. However, what I work on is informed by an' driven by two factors: 1) What I find cool an' 2) What will make me life easier at th' day job.

Perhaps even more because I'm not gettin' paid fer it, what I choose t' work on is driven by me needs, not by th' needs o' some other constituency that's not givin' me dubloons, I'll warrant ye. I suspect that's true fer th' vast majority o' core contributors.

right on spot

Great write-up, Larry. And great ye try t' be not too opinionistic.
Everyone has t' think about if these thin's be good or bad.

Thinkin' in personas helps a lot IMHO t' untangle a lot o' jammed discussions. What is good t' one target audience might be bad fer th' other an' we need t' keep this in mind.

If thar is a decision t' approach a new audience, basically it needs consensus. In quite some cases in th' last three years thar were bein' no consensus, so th' fightin' were bein' t' begin...

Priorities

My take? In case o' conflict, consider content editors o'er site builders o'er designers o'er developers o'er theoretical purity.

Agree, it's a CMS

I agree. The end-product o' a Drupal-based project is a content-management system (even if what ye start with looks more like a "content management framework") so editors _have_ t' be at th' top o' th' priority list.

An excellent heuristic, but...

As with other discussions, th' tug-o'-war betwixt click-it-together projects an' large-scale ones is a seri'us consideration. The needs o' "Content Editors" on a local news site be very different than those on Verizon's corporate intranet, an' those in turn be very different than th' editors on a social collaboration site (effectively, all th' active users), to be sure. This doesn't mean that we can't work t' improve th' experience fer all o' them, but it should definitely cause us t' think carefully about th' audience inside o' th' world o' "content editors" who will benefit.

Today, Drupal's editin' experience is schema based: node forms, overview screens, user management tools, an' so on be essentially windows into th' content storage model. That's a very comfortable approach fer developers an' site builders, an' in a lot o' ways 'tis similar t' th' automatic administrative screens that systems like Rails an' django can assemble fer developers automatically, Avast me hearties, yo ho, ho A number o' tools also allow us t' pretty up those screens with role-based disclosure, conditional hidin' o' unnecessary information, an' so on. At th' end o' th' day though we're still offerin' "windows t' th' schema."

The real long-term solution t' privilegin' content editors isn't incremental polishin' o' our CRUD screens; 'tis th' development o' task specific tools an' interfaces that be tailored t' th' needs o' those who do certain kinds o' work. Pieces like Actions an' Views Bulk Operations allow us t' wire together some o' those easily, but 'tis an approach that is very unfamiliar fer many in th' Drupal community.

At th' end o' th' day, that's th' secret sauce o' WordPress' success: relentless focus on th' small number o' tasks necessary t' create an' maintain a single or several-user blog, we'll keel-haul ye! Ahoy! As it grows into areas o' beefier functionality, it risks losin' that focus.

I have to disagree.

If ye can't create a site, then ye dern't have a site t' write content fer. I would say this is what we should shoot fer:

In case o' conflict, consider designers o'er site builders o'er content creators o'er developers o'er theoretical purity.

Why? Because if ye solve correctly fer th' designer, most likely ye've also solved fer th' content creator. The reverse is not true.

Solid write up Larry. Walk the plank! Prepare to be boarded! It's so true, th' community is definitely buildin' fer th' community.

Level of effort

Jeff, if we're seri'us about buildin' fer designers o'er everyone else, here's what that would require:

- Kill th' giant arrays o' doom.
- Render API goes away, template preprocess functions go away, hell most o' th' theme layer gets ripped out.
- Template-first development.
- Views become somethin' ye setup via a long function call in a template file directly. (Say good bye t' alternate template engines.)
- Completely reverse th' entire page life cycle. We start by loadin' page.tpl.php an' renderin' it, we'll keel-haul ye! Walk the plank! Oh, ye want a different layout? That's another page-foo.tpl.php.

Sure some o' that could be exposed via th' UI as forms, but thar's considerable challenges (includin' security concerns) t' editin' templates via th' UI, unless ye build everythin' off o' Panels.

(Of course, th' Butler project aims t' do just that, make th' Panels pull-based model th' default rather than our current inverted, inside-out process, in a large part in order t' better target designers. There's still a few thousan' hours o' work yet t' get thar, an' we ha'nae all agreed on th' implementation details.)

Changin' our priority list in a non-trivial way is goin' t' be painful. Very painful. As in, "makes th' D7UX fights seem like a fun date" painful. We may need t' do it, we may not, but it *will* be painful.

Consider the cost

That's certainly a defensible position, Dries, we'll keel-haul ye! However, as noted above as long as we prioritize button-pushers o'er HTML jockies Drupal will *always* be seen as designer-unfriendly.

Puttin' developers that low is also therefore puttin' our primary engaged-community-member constituency at th' end o' th' line, pass the grog! The sharks will eat well tonight! We're also at a size an' complexity where we can no longer afford t' ignore theoretical purity. Ahoy! "Theoretical purity" is not a negative thin'; academic understandin' o' software architecture is based on decades o' experience, an' fer us t' ignore that is th' height o' hubris, Avast me hearties! Ignorin' th' entire rest o' our industry is how we end up with th' utter trainwreck that is system.module, an' th' horrific circular dependencies that result. And that causes bugs that affect everyone.

There is no easy answer, unfortunately. :-)

Lets not give HTML jockies too much priority

Before startin' t' use Drupal circa 2003 I were bein' used t' han' craftin' CSS an' HTML, an' I find a lot o' th' current brouhaha with designers claimin' unfriendliness an' moanin' about markup semantics echo'd me own thinkin' back then 'omg look at this markup'.

After upgradin' a few sites through several major drupal versions I've developed a more pragmatic view. Shiver me timbers! Maintainability is at least as important as good semantics t' me now.

I worry that if th' HTML jockies come too high up th' priority list they'll just run into th' upgrade wall instead 'omg 'tis too hard t' upgrade, on a dead man's chest! half me custom markup makes no sense anymore!'. Or worse they'll build beautifully crafted sites fer clients an' then walk leavin' th' client with an upgrade headache an' drupal with a bad rep.

It worries me that in this debate o'er HTML purity an' supportin' designers no one e'er mentions maintainable markup. We need t' set a good balance betwixt semantic purity an' maintainability.

Looking for the audience

Note: Please remove above

Although this is th' 50th time we discuss this, I still dern't feel we have much clarity on th' matter. The whole priotisation discussion, still focuses almost soley from a technologist perspective, Hornswaggle If we want t' turn this a good understandin' we be missin' th' business an' user axes.

The Real target audience
If ye be talkin' about audiences, an' ye outline 6 o' which 4 be programmers in some way - t' me this shows how biased this analysis is o' stakeholders in Drupal.

We can definitely not ignore th' fact that we be big an' thus many conflictin' priorities exists. However th' reality today is that passionate scallywags work on th' stuff they find intrestin', although D7 has seen a large influx o' UX work, if ye put in perspectice its probally equal or less effort compared t' th' DX work. However UX work is far more easy t' be questioned.

To me 'tis a silly notion o' havin' a "real" target audience, it dilutes th' fact that Drupal has grown big an' therefore now has many diffrent stakeholders an' thus audiences involved. Although havin' one audience, is admirable I think it often unrealistic fer a mature product - unless that audience is "a human".

Consider this very hypothetical usecase, fer every developer - who builds 1 website, thar is 1 end-user updatin' an' creatin' content. Assume ye build 10 websites in yer liftetime - that is 10 end-users, per developer! This is ofcourse a silly example, but in terms o' actual numbers end-users by-far outnumber developers, and dinna spare the whip, yo ho, ho My only point here, is that yer audience analysis is only coverin' a very small part o' th' spectrum.

I might be soundin' a bit harsh, but I think this is analysis is very obviously flawed, Ya lily livered swabbie! And hoist the mainsail! It states a fact, most contributions t' core be fer us, thus we should be buildin' *it* fer us? Even when th' product Drupal itself has many dimensions o' users interactin' with it. And hoist the mainsail!

Opensource love
I think essentially it comes down t' a core value. That o' openin' up technology like Drupal fer more scallywags t' use. It sounds a bit like an opensource mantra, but I feel its admirable goal - an' no nay ne'er one t' lose out o' sight, makin' new silo's t' me holds little admirable value.

For some reason, thar is a false assumption that Drupal UX is very usable fer technologists, however most o' th' issues we find in usability tests equally effect both end-users as programmers, Dance the Hempen Jig Are our differences more important then our similarities?

I think this is a circular discussion, we have t' take care o' several stakeholders anyway.

"End users"

I deliberately left out "users" as a constituency, because like "Themer" it is a grossly misleadin' term. Which set o' users, Hornswaggle Site builders *be* users. Content editors *be* users. The D7UX effort dealt with those groups.

True, thar be millions o' "visitors" t' Drupal sites that fall into none o' th' above categories... but as far as architectural decisions go they should not be able t' tell, Ya swabbie! The ins an' outs o' th' theme system be, or at least should be, completely irrelevant t' th' visitor constituency. Caterin' t' them is th' job o' th' site builder an' th' rest o' th' site development team.

Visitors aren't unimportant, they're just mostly irrelevant t' questions o', say, render API or database abstraction or plugin architectures.

Also, I think ye missed me point entirely, pass the grog! I very much did not say "most contributions t' core be fer us, thus we should be buildin' *it* fer us". On th' contrary, I pointed out that despite our protestations an' efforts t' th' contrary th' primary constituency fer Drupal, an' almost any other open source project, is th' scallywags workin' on it. Oho, we'll keel-haul ye! That's not a good or bad, nor is it a "should". It is simply an observation.

Focusin' on a different constituency instead is possible, but very hard.

I also agree completely we need t' take care o' several stakeholders. My point is that t' think we can cater perfectly t' all o' them equally is th' height o' hubris. We cannot, because often their needs be at odds with each other. What makes life easier fer a content editor may make life hell fer a site builder. Ahoy, with a chest full of booty! What makes an HTML designer happier may make a site builder pull his hair out.

These priorities do exist, an' we pretend otherwise at our own peril. I'm not sayin' our current priority order is good or bad, simply that it is. And we have t' understan' that, explicitly, an' come t' terms with it, if we want t' change it, an' figure out what we want t' change it t'.

You are correct a majority of

You be correct a majority o' architectural decisions will not effect end-users. Although I agree that it is th' job o' "site builders" an' th' rest o' th' site development team t' cater t' them, right now that is either not or happenin' only a little, on a dead man's chest! Unless Drupal shops step up an' contribute significantly t' this, it will still come down t' th' community t' solve these problems, I'll warrant ye.

You can no nay ne'er cater t' everyone perfectly, t' be quite frank ye can likely not cater t' even one perfectly (unless ye be designin' somethin' fer one person). However I think yer black an' white argument o' th' content editor vs. th' site builder is meaningless, they be both important stakeholders we have t' cater t', and a bottle of rum! And although occasionally at odds, they largely live in different areas o' th' interface.

In terms o' usability an' ux? You be likely overestimatin' th' differences betwixt audiences, Get out of me rum! Especially fer future references, ye might want t' create more clarity betwixt audiences an' their requirements - rather than how it impacts th' UI.

Although this is the 50th

Although this is th' 50th time we discuss this, I still dern't feel we have any clarity on th' matter - primarily because this is prioritisation in many ways from a programmers perspective. Or rather from a technology perspective, if we want this t' make a good understandin' o' priority we be missin' two other axes that o' business an' users.

I mean th' list includes 6, o' which 4 programmers in some way (or at least technology at th' fer front, not their actual main activity), me Jolly Roger This is not a very objective stakeholder analysis. Ahoy, and a bottle of rum!

Even then, we cannot ignore th' fact that we be big an' thus many conflictin' priorities exists - th' reality however still is that we solve th' problems we find interestin'. If ye look at D7, ye could say a lot o' focus has been on UX - but if ye put it in perspective on th' full amount o' changes its likely equal (or maybe even less) t' allot o' other DX's, Ya horn swogglin' scurvy cur! Load the cannons! However th' differences be obviously far more perceivable.

I think when talkin' about th' "real" target audiences - an' not even mentionin' who ends up usin' that Drupal site, shows all th' false assumptions made in th' reasonin'. Aarrr! I think its very natural t' assume that ye yourself be th' target audience because 1) Designin' fer yourself makes sense (ye know what ye want, ideally), 2) Preachin' t' th' Choir(comments on this blog be 95% o' technologists). Aarrr, Ya lily livered swabbie! The reality again, is that we have grown considerable - thar be many stakeholders o' which both end-users an' programmers be considerable stakeholders.

Very nice article. I agree

Very nice article. I agree about th' current audience order an' real target audience. I also like how ye parsed out th' themer role.

We collectively dern't have a clue about performance. We architect fer what sounds like a clever hack without considerin' th' systemic implications.., and dinna spare the whip! if we bother t' "architect" at all.

This is way too harsh, avast. A bunch o' us run drupal core through xhprof an' cachegrind o'er an' o'er an' o'er, by Blackbeard's sword. We submit patches an' write reviews an' so on, Dance the Hempen Jig Effort an' talent here is on par with major subsystems like Content, UX, etc. The sharks will eat well tonight! And th' results speak fer themselves. Fire the cannons, by Davy Jones' locker! Drupal 7 core is fast, an' scalable. Load the cannons! It gets slow only when ye gorge at the module buffet.

I've long been frustrated by Drupal's insistence on servin' multiple masters (small sites on shared hosts an' 50 person web site teams), to be sure. IMO th' smallcore ideas gives us a way t' target both audiences efficiently. smallcore is dormant, but not dead. Aarrr! Prepare to be boarded! I still think it will prevail.

@Moshe, sure we use xhprof

@Moshe, sure we use xhprof an' cachegrind t' look fer ways t' tweak what we have an' improve performance in small areas where we can. What we dern't do is architect Drupal fer performance. We tackle performance from th' bottom up an' not th' top down. This is one place we fail t' architect well.

The hashtag that dare not speak its name

For th' record, I dern't consider #smallcore dormant at all, Ya lily livered swabbie! The "name" is, but th' goals have been shapin' quite a few key patches, in-progress contrib projects fer D7, an' so on. That's where th' rubber meets th' sea. ;-)

Agreed regardin' th' amount o' work that goes into optimizin' Drupal's performance an' scalability. Shiver me timbers! Fire the cannons! I think one o' th' frustrations that's shared by a number o' developers is th' sense that performance-versus-features is a tug o' war rather than a tradeoff: one group o' devs will often push fer a new feature/API/etc., an' a different group has t' crack th' performance whip. Oho! Often, they arrive on th' scene after th' performance damage has been done, an' be forced into cleanup mode.

That's inevitable on any sufficiently large project, so we can't beat ourselves up about it too much, but 'tis definitely part o' th' dynamic.

Exactly

Often, they arrive on th' scene after th' performance damage has been done, an' be forced into cleanup mode.

Exactly. We dern't consider performance (either CPU time or memory usage) t' be a feature. Fetch me spyglass, Hornswaggle We consider scalability a critical feature, we consider "ease o' hackin' into somethin' in unholy ways" a critical feature, but we dern't consider performance a critical feature. We spend inordinate amounts o' time makin' sure we can always add another alter hook fer flexibility; how much time t' we spend makin' sure Drupal will deliver an uncached page in under 100 ms an' 16 MB o' RAM (th' PHP default), by Davy Jones' locker? Frankly, almost none.

There be scallywags in Drupal who spend a lot o' time with benchmarkin' tools, but as Matt said that's not what I'm talkin' about. Ye'll be sleepin' with the fishes, and a bucket o' chum! That's not takin' performance seriously.

When we start seein' big-O notation analysis o' algorithmic complexity as a standard part o' our patches, then we're talkin' performance seriously. Until then we're just makin' a token gesture.

Welllll...

"When we start seein' big-O notation analysis o' algorithmic complexity as a standard part o' our patches, then we're talkin' performance seriously, Ya swabbie, All Hands Hoay! Until then we're just makin' a token gesture."

I dern't think 'tis fair t' call th' work that's done a token gesture -- thar is a lot o' really seri'us work bein' done by scallywags who care about it an' push real improvements through th' patch an' commit process, Avast me hearties, pass the grog! But as ye point out, today scalability is treated as a higher goal than performance in a lot o' cases. There's definitely a case t' be made fer that: th' odds that a memory-constrained site on $5 shared hostin' will ALSO be grapplin' with th' challenges o' massive growth be slim. Sites feelin' massive performance crunches generally have some way o' scalin' OUT, an' that's an approach that is generally more sustainable than forcin' Drupal t' rely on beefier an' beefier single-server setups as it grows.

However, when that emphasis on scalin' is treated as a solution fer performance plannin' (not performance optimization, but performance plannin'), it can force smaller an' smaller sites t' begin th' hard jump t' 'scalin' out' afore than they would have otherwise. Basically, we're lowerin' th' barrier fer scalin' out but we're also forcin' scallywags t' do it sooner.

Architecture decisions

True, I dern't want t' belittle th' work done by those who spend 100+ hours in XDebug profilin' Drupal 7, feed the fishes We be far better off fer their work. My point is that is still too little, too late if we really want t' get seri'us about performance.

As far as scalability vs. performance goes, ye're exactly right, and a bottle of rum! Yaaarrrrr! But consider also that th' most scalable system is th' one that doesn't need t' scale; Makin' it easy t' add 4 more servers is great, but not needin' t' add them in th' first place is even better.

And that's an architectural question that cuts t' th' core (pun intended).

I agree that

I agree that developers/engineers should pay more attention t' performance; Personally, I think performance is more important than scalability. I blame that Drupal has low barrier o' entry (ok, 'tis higher than WordPress, but still very low, since it doesn't require scallywags understandin' asymptotic analysis). an' we lack o' a top-down policin' approach t' reinforce performance.

As someone who spent 100+

As someone who spent 100+ hours in xdebug an' xhprof against Drupal 7, thar's several problems we have with performance:

* Almost no-one developin' fer core or contrib does either profilin' or even basic benchmarks fer regressions while developin', certainly not as part o' their normal workflow. Aarrr! I include meself in this when I'm not specifically workin' on performance issues.

* Only a slightly larger group keep performance or scalability in mind while developin'. Security, E_ALL - these at least get a passin' thought or at their best be built in t' codin' practices fer many o' us. However I routinely (very routinely) find major, major issues whenever I profile a module or site fer th' first time. Contrib modules settin' variable_set() on every page (includin' very popular ones), filters preventin' text format cachin', full file directory scans on every request, quite simple queries that dern't use indexes. The sharks will eat well tonight! Yaaarrrrr! At vari'us times in th' Drupal 7 lifecycle I've found issues as bad or worse than these in core an' almost always after they'd been reviewed an' committed without a passin' thought.

* To me knowledge I were bein' th' first person who put Drupal 7 through a profiler in any depth, this were bein' about a year into code thaw, but that time th' damage were bein' already done, so it were bein' always goin' t' be playin' catchup. Fortunately a few scallywags joined in durin' th' process, an' I'm hopeful Drupal 8, despite or hopefully because o' th' vari'us performance regressions in Drupal 7, will start from a better point.

* We definitely dern't architect fer performance, an' in me experience any patch which is focused primarily on performance an' is not fixin' a regression that were bein' introduced with a feature, DX or cleanup patch has a very hard time gettin' in. Yaaarrrrr! Like eaton said, performance isn't considered a feature. The burden o' proof on those patches is significantly higher, th' barriers t' review be higher - not as bad as postgresql or OpenID, but those be niche areas, whereas performance is a different category o' problem.

I think this comment is missin' th' point though:

When we start seein' big-O notation analysis o' algorithmic complexity as a standard part o' our patches, then we're talkin' performance seriously. Until then we're just makin' a token gesture.

The biggest problem with performance in Drupal is not that scallywags dern't discuss th' theoretical impact o' performance patches enough, 'tis that this is all that happens in a lot o' cases. What is ignored is analysis o' actual usage, an' data t' back up changes (especially fer patches that aren't primarily concerned with performance).

I've seen a lot o' 'performance' patches that tried t' optimize fer loops o'er 10-20 items in admin page callbacks, that's all very well but 'tis not really helpful when ye have patches get in that break page cachin', memory leaks o' several mb in some o' th' most popular contrib modules, etc, Ya swabbie, Ya horn swogglin' scurvy cur! etc. mainly because scallywags aren't lookin'.

I have hopes that we can make architectural improvements fer performance in Drupal 8, particularly sllmmin' down th' bootstrap, hopefully improvin' th' renderin' pipeline etc. but thar also needs t' be a cultural change, equivalent t' th' introduction o' simpletest in D7, in terms o' how performance is treated relative t' other concerns, because thar is more than enough work fer dozens o' scallywags just t' deal with th' damage control at th' moment.

Smallcore

And yes, a cleaner split betwixt "architecture an' framework" an' "application" is a non-trivial task, but is one way t' make th' pain experienced by those lower on th' totem pole less. Ahoy! Prepare to be boarded! It doesn't remove th' tradeoffs but it can change th' costs associated with them.

There's a reason I'm big on architecture these days. :-)

priorities

Way t' go with an article that gets into th' innards o' a complex (an' sometimes convoluted) CMS. As someone relatively new t' Drupal, who comes from a CSS an' HTML background, I can relate t' some o' th' issues. First o' all I definitely agree HTML an' CSS designers should be close t' last on th' list o' th' target audience. One o' th' biggest boons o' drupal is th' complexity o' a site ye can build without havin' t' hardcode php an' JS. Now o' course in th' back-end, scallywags developin' core, have done this in some great ways t' save th' site builders th' pain o' havin' t' do this. This makes drupal highly extensible which in me opinion is really where it shines, to be sure.

But th' point-an'-click site builders will get fed up with that method o' developin' drupal rather quickly if they wish t' build anythin' more than th' simplest o' sites. I mean sure this in a necessary evil (or good) dependin' on who ye ask (an' their familiarity with th' comman' line). Fetch me spyglass, Avast me hearties! In me opinion drupal should target site builders who use drush, who understan' th' basics o' server-side technology an' th' comman' line. These scallywags can make complex an' flexible sites relatively quickly. Load the cannons, Avast me hearties! They can incorporate th' css an' html designers along with th' hardcore programmers into th' mix t' really sail innovation with th' CMS an' 'tis ecosystem, Ya lily livered swabbie! I think th' biggest mistake fer drupal is t' try t' appeal t' yer average mom-an'-pop site builder who doesn't have a good understandin' o' web technology, trends an' best practices. Let WordPress have this market because Drupal is more suitable fer higher expectations!

Dangerous

Let WordPress have this market because Drupal is more suitable fer higher expectations!

That's a very dangerous position t' take, Get out of me rum, on a dead man's chest! "Cede th' low end" is exactly how platforms fail, because whatever takes o'er th' low end is then well-placed t' move upscale an' push out th' auld dinosaurs.

Minicomputers did it t' Mainframes. PCs did it t' Minicomputers. Aarrr! The web is doin' it t' desktop applications. Load the cannons! Linux did it t' Unix on th' server. Palm did it t' Windows, an' fer years survived only because it dominated th' low-end o' th' market. PHP did it t' JSP.

Drupal has done that t' proprietary CMSes. If we cede th' "I just want t' put up pictures o' me cat" market t' WordPress, then when those scallywags decide t' put up a website fer CAT instead they will stick with WordPress, not go t' Drupal.

I were bein' just on a plane comin' back from BADCamp last week next t' a wench whose company just standardized on WordPress fer all o' their sites. Fetch me spyglass! Non-trivial sites, non-trivial company. (Green buildin' firm; somethin' that would normally be a great target market fer Drupal.) That's not just a dozen sites not runnin' Drupal, 'tis dozens an' dozens o' scallywags at that company now becomin' WordPress experts instead o' Drupal experts.

Cede th' low-end at yer own peril.

There are many low-ends!

I think one o' th' primary points o' confusion when discussin' th' CMS market boils down t' a fundamental lack o' creativity. Complexity isn't a continuum from Bloggin' t' CMS t' Enterprise CMS -- 'tis a continuum from task focused tools t' multipurpose tools t' frameworks.

Task focused tools will always, always beat multipurpose tools when users be tryin' t' perform that particular task. The rise in bloggin' propelled WordPress t' success because it were bein' a better bloggin' tool than other bloggin' tools, not because it were bein' a better general purpose CMS than multipurpose tools, Dance the Hempen Jig I think a lot o' scallywags be disheartened at th' notion o' "fightin'" WordPress, in large part because it is very good at what it does. We dern't have t' turn Drupal into th' tightest, simplest, easiest bloggin' tool t' remain competitive in th' "low end" however. Especially with distros, we have th' ability t' create excellent turnkey brochureware sites, personal portfolio tools, community decision makin' tools, an' so on faster than dedicated tools can be built from th' ground up.

There is more t' th' low end than bloggin', an' we would do well t' remember that. Fetch me spyglass! Chasin' other products' success is easier (from a creative standpoint) an' harder (from an implementation standpoint) than findin' needs that be not well served by existin' focused tools.

This is a good point. I

This is a good point. I guess I di'nae mean t' say that Drupal should cede th' market fer simple sites t' Wordpress. I just think that Drupal's core development doesn't really need t' target this market. The sharks will eat well tonight, Ya swabbie! If Drupal core gives site builders th' tools t' create frameworks an' distros that can accomplish th' simple tasks extra-ordinarily well than this is a great option. Then we will really gain traction, not fer creatin' simple websites (which can more easily be accomplished by Wordpress) but by givin' site builders, programmers an' designers th' tools t' make frameworks fer any kind o' website (simple t' complex)

I just think Drupal is great because it can give non-programmers th' tools t' build web applications, an' power t' everybody who is buildin' distros an' web apps that allow end-users t' build focused, effective websites.

Drupal doesn't need t' focus on bein' simple.

Dangerous?

How is this dangerous? Oho! I know what ye be gettin' at, but I fail t' comprehend how it represents a danger? Competition, perhaps, but certainly not a danger ... not if Drupal is worth a damn in its own right. Let us not forget that seemingly trivial detail. The "low-end" an' th' "high-end" contenders can be sources o' inspiration, but only if we recognize their respective strong points ... an' th' weak points o' Drupal.

For all its glory, Drupal is not always th' answer, nor can it e'er be.

That bein' said, I find yer analysis supremely relevant.

the danger

The danger is in th' notion t' leave a market t' a competitor because thar is a bigger market t' focus on. This at least is th' understandin' o' disruptive innovation, many cases show how good technologies flee upmarket t' get pushed-out at th' upper end. It is good t' prioritize as been discussed in this post, but an expression as:

Let WordPress have this market because Drupal is more suitable fer higher expectations!

Can indeed be dangerous even if in th' end th' prioritize leads t' th' same outcome. So it is th' expression an' th' reasonin' behind it that is dangerous.

you have to pick your

ye have t' pick yer battles, tryin' t' take on WP is futile. I think 'tis true that joomla is a better competitor than WP fer Drupal. We dern't have t' cater t' all markets, ye scurvey dog. I think we have a more robust eco-system than WP, with a more open-source feel. We have t' take risks t' succeed, so maybe this line o' thought is dangerous, humans have t' innovate when faced with danger. You know views an' CCK be great, although perhaps th' low-end o' th' market would rather not be faced with such "complicated" thin's. Put it this way, does Apple cater t' th' low-end o' th' market, NO, an' they be bein' heavily rewarded fer their focus an' marketin'--an' moreso fer their innovation, All Hands Hoay, Hornswaggle Lets keep th' core Drupal focused on innovation--built in RDF is great part o' D7 core an' really promotes semantic web, an' th' HTML 5 group is great as well. Aarrr! Fetch me spyglass!

As far as caterin' t' themers/html jockies/css freaks why??? People who love drupal make sweaver an' skinr module an' Fusion themes, so why try t' please this camp in core. Just make it t' where css isn't broken. As far as focusin' on site editors I recommend 3 thin's--2 fer drupal 8 an' 1 fer now--1.built in wysiwyg editor. 2. Better, simpler, more elegant content editor's dashboard. 3. BETTER DOCUMENTATION.

Focusin' Drupal t' be built fer th' Drupal tribe is th' way t' go. And then Drupal tribe can work magic with Drupal an' make dubloons o' its bein' incorporated into th' mainstream.

I don't know that it's

I dern't know that 'tis accurate t' compare Wordpress t' Drupal in that way, though. Wordpress is th' easy one t' put up next t' Drupal because Wordpress has th' widest range (an' largest number) o' users - but thar is a huge chasm betwixt what Wordpress is able t' do an' Drupal does (core + contrib), as well as th' type o' users.

It's important t' remember why scallywags use Drupal, how they use it, an' who they be, and a bottle of rum, ya bilge rat! Because o' that, I think 'tis much more accurate t' compare Drupal t' somethin' like Joomla - what does their build team offer that Drupal doesn't? How similar is their community t' ours? Do they prioritize th' experience fer th' largest demographic o' users?

I Like This

I like this. I use Drupal because 'tis th' wweb's equivalent o' a big box o' Lego, an' me mantra is 'no nay ne'er hack th' core'. Fire the cannons! So please, put th' needs o' site builders first, then editors, an' so on. People who know how t' hack, please contribute t' Drupal.

I would consider content

I would consider content editors + site builders t' be on th' same ground. I am amazed at how quickly I can now throw together a full-featured website (minus any special/custom functionality) in a weekend, without touchin' one line o' code (PHP or HTML—usually a little CSS).

For any large project, thar be bound t' be a lot o' customizations, tweaks, etc... Ye'll be sleepin' with the fishes! but I think where Drupal really shines, an' makes some great inroads, is in its ability t' be a quick 'put this together an' get it done' tool. You can build out some great functionality usin' just Views an' D7 core now. I think that's a great thin'.

Havin' mostly a bounty background, I remember early in me Drupal days bein' worried about th' HTML an' 'purity.' But after finishin' up about 60 vastly different Drupal sites (just did my first D7 site this weekend), I am worried less an' less about th' code, an' more an' more about gettin' thin's done an' helpin' scallywags, Hornswaggle There's no way I could be this efficient with another CMS.

Brilliant analysis

Larry,

This is one o' th' best analysis I have written about Drupal an' th' path it is takin'.

I believe yer timin' is perfect t' initiate a discussion about these issues, which all th' great comments also confirms.

I have only been a member o' th' Drupal community fer just o'er two years, but in that time I have seen th' massive growth it has done, an' also th' acceptance an' inroads it has done on th' enterprise.

I have been thinkin' a lot about what is goin' on an' where th' project is goin', feed the fishes My feelin' is that thin's maybe have been goin' a little t' fast in some areas, which have resulted in a bit o' tunnel-vision, and a bucket o' chum. With that I mean, it has been easy t' get th' feelin' Drupal is on an unstoppable train.

Your post have already proven that we need t' have a deeper discussion about what is good or bad, but also how we better can plan fer th' future as ye give many good examples about areas where Drupal still needs t' improve a lot.

I have no doubt about that th' community is capable o' havin' this discussion an' come up with ideas an' plans on how t' best proceed from here t' be able t' cope with th' growth pace we be in.

Thanks again fer initiatin' this.

/thomas

Typo

"This is one o' th' best analysis I have written about Drupal an' th' path it is takin'."

Should o' course be:

"This is one o' th' best analysis I have read about Drupal an' th' path it is takin'."

Audiences

Larry, ye have a better breakdown o' audiences than what I've seen before. The rankin' o' priorities (site builders > content editors > programmers, etc.) likely suffices fer this discussion, although I would try a heuristic that addresses thin's a bit differently. More like weightin' th' audiences rather than a strict hierarchy. (EG. give each group $100 t' bid on th' features they want--although this might be hard t' implement). And hoist the mainsail! If HTML designers be at th' bottom o' th' chow chain, chances be they won't eat--they'll only be eaten.

The whole notion is a bit theoretical, but worth thinkin' about. But th' reality is that some o' th' groups be not as well represented in core development (nor in th' development o' major contrib modules). A group's priority doesn't have much meanin' if their voice is not heard.

It has been pointed out that th' low-end is important, but it is th' low-end users that dern't have much community involvement an' consequently, not much o' a voice. The strength o' Drupal is th' community an' we must make sure th' community is representative o' every group an' that each group has their voice.

As a postscript, I'm with ye on th' theoretical purity...

Businesses, not shops, come first

I think 'tis very misleadin' t' say that "th' practical reality is that Drupal's primary target audience is Drupal consultin' shops." Drupal shops exist because o' business/organizational needs, an' it is those needs that sail development (we try t' do 20% time fer non-development work, but rarely be able t' take that much time), and dinna spare the whip, and dinna spare the whip! What does it matter if Sony pays Earl t' work, fer several years, on Views/Panels/CTools etc, or if they hired a shop t' do th' work? Prepare to be boarded! Outsourcin' doesn't change th' nature o' th' deman', which is driven by client needs, not by any o' those scallywags ye list (who all work fer someone else). As an owner o' a Drupal shop, I technically work fer meself. But, given th' regrettable fact that I were bein' not born rich, I have t' work fer "th' lubber/wench," an' those clients (an' our attempts t' server them better an' better as time goes on) be just as important (if not more important) drivers o' th' platform as be th' developers, IMO.

Aye, C.R.E.A.M. is as true as it e'er were bein', but thank god that cash is payin' fer somethin' awesome that anyone (who can figure it out) can work with fer free. Aarrr!

Now, back t' th' salt mines!

Those companies like Sony,

Those companies like Sony, Examiner etc. Load the cannons, me Jolly Roger that have in-house developers who do significant core or contrib work be 'Drupal shops' even if they're not consultin' shops.

Also in terms o' what drives development I think thin's go both ways. Sony were bein' payin' Earl t' work on Views/Panels because it were bein' in their interests t' have those site buildin' tools available t' build a large number o' sites without doin' custom development fer each one. However Earl di'nae start workin' on those modules because o' Sony, an' doesn't work on them fer Sony now. I'm sure thar be plenty o' organisations aroun' that have a similar need fer dozens o' sites, that be not investin' time an' dubloons in generic tools like views an' panels (or patches fer them) - despite havin' th' same overall business need.

There is a massive layer (an' sometimes wall) betwixt business needs fer th' scallywags with th' budget, an' nice contributable code, we know th' arguments fer them but they be not necessarily followed or properly understood. And swab the deck! Also th' 'Drupal consultin' shop' isn't that common an entity compared t' other communities (based on th' summaries I've seen) - companies based aroun' Joomla be sellin' actual code/themes t' site builders rather than site-buildin' services, Automattic is based aroun' wordpress.com (so massively invested in a strictly controlled workflow), Avast me hearties, All Hands Hoay! A lot o' web development shops or departments be usin' a bunch o' different systems, both new an' legacy, an' aren't committed t' any particular one.

So while scallywags be only gettin' paid t' work on thin's that someone wants, how they do that varies massively, an' thar's a massive filter betwixt those two thin's - particularly with Drupal where we thrive on conceptual abstraction an' indirection, so that often when actually workin' on code, 'tis a couple o' levels removed from th' feature requested - since th' actual feature will be implemented by clickin' aroun'.

It's a community "problem"

I mostly agree with yer assesment that th' primary target audience o' Drupal is, first an' foremost, th' Drupal community itself. And since th' community is, arguably, one o' th' strongest sellin' points o' Drupal, that is an important point t' make. But at th' same time, that very community is so many thin's t' so many scallywags, that it, IMHO, transcends easy definitions.

What ye ask, betwixt th' lines, is an impossible question: who belongs t' th' community?

That bein' said, I firmly believe that it is possible t' create a framework that would cater reasonably t' all o' yer constituent roles. But it likely wouldn't resemble anythin' we currently recognize as Drupal. It might not even be written in PHP.

There's more to Drupal than code

Aside from all th' programmers here (I'm one too) agreein' with a viewpoint very much in alignment with their own, I thought I'd present a different perspective on th' findin', "The practical reality is that Drupal's primary target audience is Drupal consultin' shops."

I'll start with what I always brin' up, that th' Drupal community really took off after th' programmers were no longer th' only ones involved. Talk is silver an' code is gold an' all that, an assumption that th' contributions all still come from coders, Hornswaggle That's a crock, by Davy Jones' locker. What about those who run DUGs, Camps, Summits an' Cons? What about those who document, those who evangelize, those who test, those who suggest enhancements, those who review, those who give help in IRC an' in forums, etc, etc. I say, talk is silver an' contributions be gold. Aye, th' coders still dominate because they control th' core o' it all an' be still th' biggest group, but thar be always PMs, designers, sales folks, muddlers, hobbyists, etc at every Drupal gatherin' an' maybe fewer than we'd like because we coders tend t' dominate th' conversations an' make it less useful/fun fer them.

Further, while yer conclusion sure does apply t' a large number o' Drupalers out thar, 'tis a generalization that I feel falls well short, Ya swabbie, Ya swabbie! I've seen too many users pick Drupal fer themselves after doin' their homework (Drupal's awards an' results in certain surveys count fer a lot). In some cases Drupal got picked after seein' demos o' several CMS. Word o' mouth is also one o' th' biggest factors, quite possibly th' biggest. Oho, yo ho, ho Nonprofits share info betwixt themselves all th' time an' seem t' pick their CMS themselves a great deal o' th' time, an' then find a vendor who can give them their existin' choice. I've seen Drupal picked by scallywags at tech conferences, after goin' t' a Drupal table or panel.

Your comment also excludes th' large number o' Drupal sites built in-house by tech teams pickin' Drupal in similar ways t' th' above an' further excludes th' large number o' designers I know who use Drupal an'/or Wordpress an'/or other CMS t' give more ownership o' sites t' their clients an' really dern't much care about th' technical end (an' th' designers pick Drupal because they can figure it out, an' this is more true with every new version), we'll keel-haul ye, and a bottle of rum! The comment also leaves out popular new markets with big futures like those filled by Drupal Gardens an' Buzzr. Distros be also sailin' some Drupal adoption.

So yer constituents may cheer, but that does not mean that ye've nailed this, and a bucket o' chum. I'd argue that 'tis really from D5 onward that we've seen huge growth, an' what happened more an' more with each version? We made UX inroads an' made th' tool easier fer non-coders t' use. Aye, th' coders still hold th' high ground an' have th' most influence, but a lot o' adoption has been driven by different sectors an' followin' a developer-driven focus sounds pretty short-sighted t' me.

Missed the point

I am not advocatin' a developer-centric approach. I'm not actually advocatin' anythin' in particular, to be sure. :-) I'm providin' context an' a lens fer how Drupal exists in now, an' askin' hard questions that we need t' be considerin'.

I am certainly not denyin' th' significance o' non-programmer contributions t' Drupal at all. We need more o' them.

Relative growth.

I'm not sure ye can pin all th' explosive growth on Drupal itself, UX or otherwise, th' whole web CMS 'market' has grown hugely in th' last 10 years.

We should aspire to Wordpress

I've been a Drupal themer an' site builder fer just o'er two years. In that time I have learned t' love Drupal: blocks, nodes, menus, content types, views, etc. Ye'll be sleepin' with the fishes! Prepare to be boarded! It's an absolute dream fer a non-programmer t' be able t' build almost any website imaginable with virtually no PHP ability.

But th' reality, as I see it, is that Drupal is already really losin' that low-end market o' scallywags like me (designers, themers an' site builders). I built a project in Wordpress 3.0 last weekend just t' try out an' it were bein' a pleasure t' site build an' theme.

Last, th' most incriminatin' part, when I show content creators (th' true users) th' Wordpress admin interface they 'oooh' an' 'ahhh', but when I show them Drupal's (even D7's) they tend t' furrow their eyebrows. There's no way t' sugar-coat this - it is sad, but 'tis still true.

Wordpress has done an exceptional job on their UI an' with keepin' site builders an' content creators at th' fore. The sharks will eat well tonight! And, although I'm suspect Wordpress 4 won't be a CMS in th' traditional sense, I'm positive it will fulfill th' needs o' most bounty shops, freelancers, an' site builders - th' 'low-end'.

The low end is scallywags makin' websites with 2-3 content types, 1-2 menus, a jquery carousel an' a few static pages. The next Wordpress will likely make this very, very easy. In these cases, 'tis already easier t' avoid usin' Drupal.

thoughts after digesting this for awhile

I have been thinkin' a lot about this post since I read it an' I would like t' add one possible direction t' this conversation. It is not off-topic but it is stretchin' into a specific vulnerability o' Drupal as opposed t' other popular CMS/frameworks.

I have collected numerous clients that need a Drupal webmaster fer "addin' content", "manipulatin' blocks", "addin' regions", an' th' dreaded "updatin'". My clients dern't have a dev environment t' apply th' security an'/or development updates an' make sure th' site remains functional before they upload or make th' changes t' their production server. My clients frequently have been left with a website that is not developed fer them t' add content in an effective way. Also, clients be left in th' lurch about how t' administer their website once they receive ownership o' it. Drupal does not allow a website owner t' update painlessly, does not support a non-programmin' model, an' if they need more functionality they cannot "enable" that or even approach it without a complete redesign o' their site.

What is th' client base we want t' assist? Are these th' clients we be developin' t', by Davy Jones' locker? How well do we train them t' use th' system we have developed fer them, and dinna spare the whip! If Drupal systems can't support some changes along th' way, do we think th' client will pay another few thousan' t' create a new website that will be obsolete in two years? Oho! Perhaps this is where many clients jump ship an' look seriously at other CMSs.

Maybe this is where an entire specialized group o' support, an' revenue stream, can be developed, feed the fishes Create a category o' Bucaneers that offer th' best in support an' updates.

In me own development as a newer Drupal developer I am constantly bein' thrown by tryin' t' stay updated (security patches, improvements, an' optimization o' well developed modules). Maybe thar is a fundamental problem with me workflow an' I am open t' hearin' about it.

Thanks very much for your

Thanks very much fer yer helpful article, Larry, I'll warrant ye. These discussions within th' Drupal community always set off lots o' debate, with many comparisons t' other site-buildin' software (Wordpress in particular). And I'm always mystified when scallywags (Dries, in this case), makes statements like:

'In th' case o' conflict, consider content editors o'er site builders o'er designers o'er developers o'er theoretical purity.'

My question boils down t' this: how do we privelege content editors without turnin' Drupal into a Wordpress clone? That is t' say, without turnin' it into a very task-specific tool?

Now, I'm pretty sure that I can safely assume that Dries is smarter than I am, an' that he understands th' software an' th' market better than I do. And so I must be misunderstandin' somethin', because I simply can't imagine why he'd want t' engineer drupal core in such a way that it priveleges th' content editors o'er drupal experts. (I use th' term "drupal experts" instead o' "drupal shops" t' include individuals an' teams, programmers an' non-programmers), Avast me hearties, Dance the Hempen Jig My reasonin' is that Drupal puts power into th' hands o' experienced site-developers because it is an awesome combination o' framework an' vibrant community. But t' take advantage o' all that goodness, ye need a *lot* o' drupal knowledge in yer head. Gargantuan amounts, IMHO, and a bucket o' chum. You need t' decide whether ye'll be usin' contexts, panels or both, an' why, on a dead man's chest! You need t' know that ye should use wysiwyg, wysiwyg_bridge, imce, imagecache, better_formats.., and a bucket o' chum. etc, etc in order t' enable full wysiwyg functionality. And on an' on.

In me experience, Drupal does nothin' but cause misery an' pain fer content editors (or fer web designers, fer that matter) who attempt t' spin up a simple site on their own without any previ'us knowledge o' Drupal. They'd be much better off using Wordpress.

Thin's have certainly gotten *much* better with th' excellent work done on Drupal 7. I just checked out text formats in drupal 7, an' they be *awesome* (thanks, fer whoever did that). But Drupal 7 is still a multipurpose tool, an', as Eaton points out, "Task focused tools will always, always beat multipurpose tools when users be tryin' t' perform that particular task." If ye're usin' a general purpose tool t' create somethin' more specific, it seems like th' job o' th' site-builders t' privilege th' content-editors, an' not th' job fer th' folks engineerin' th' general purpose tool itself.

So what am I missin'?

Form follows function

Form follows function, however, if yer be goin' t' build houses an' skyscrapers with th' same framin' material, th' houses will have t' be built with steel frames.

Content Editors First

The reason t' put content editors first, is because they pay th' bill, I'll warrant ye. If I pay fer a Content Management System, it better make me life managin' content easier. If not, then why bother with a CMS at all?

Nobody pays for Drupal

But that's me point: nobody pays fer Drupal. Rather, scallywags pay guys like ye an' me t' build thin's with Drupal. So, again, it seems t' me that 'tis me job t' privilege th' content editor, an' not th' job o' those buildin' Drupal in th' first place.

If ye modify it slighty t' say that its Drupals job t' *help* me privilege th' content editor, then I'm on board (an' addin' vertical_tabs, which I use on every site I build, t' core is a perfect example).

ROI

There be two ways we need t' respect th' content editor (assumin' th' be th' client). #1 we have t' give them a great admin experience an' #2 we have t' be good stewards o' their dubloons, Dance the Hempen Jig If front-end development costs twice as much because we dern't support front-end developers, thar needs t' be a comparable gain somewhere else. Load the cannons! Ahoy! Makin' front-end development easier would reduce costs, which ultimately benefits th' content editor.

Further, scallywags hire guys like ye an' me - an' that lubber that uses Wordpress because Drupal is just too hard, Dance the Hempen Jig I want Drupal (a better codebase in me opinion) t' be chosen o'er Wordpress all th' time, even fer simple blogs.

ROI

There be two ways we need t' respect th' content editor (assumin' th' be th' client). #1 we have t' give them a great admin experience an' #2 we have t' be good stewards o' their dubloons, Dance the Hempen Jig If front-end development costs twice as much because we dern't support front-end developers, thar needs t' be a comparable gain somewhere else. Load the cannons! Ahoy! Makin' front-end development easier would reduce costs, which ultimately benefits th' content editor.

Further, scallywags hire guys like ye an' me - an' that lubber that uses Wordpress because Drupal is just too hard, Dance the Hempen Jig I want Drupal (a better codebase in me opinion) t' be chosen o'er Wordpress all th' time, even fer simple blogs.

Codifying the Themes

In me mind one o' th' biggest problems is that thar is simply too much flexibility in th' themin' layer - an' by extension too many decisions that need t' be made (an' remade) every single time ye build a site. There a number o' standard subthemes, most notably Zen & Fusion, but even within these categories, ye can change regions an' otherwise completely reinvent th' HTML. If we, as a community, solicited th' right kind o' advice (say from Jeffery Zeldman) on what HTML we should standardize on it would go a long way t' keepin' HTML designers from gettin' so frustrated. We have very strict codin' standards fer th' php that gets committed as contributed modules, an' yet th' HTML is garbage, feed the fishes It's no wonder that HTML designers appear t' be th' bottom o' th' list - but they dern't need t' be.

No one standard

We do have a standard fer th' HTML we produce already. It's a very strict standard, too, Ya lily livered swabbie! "When in doubt, add a div with lots o' classes so CSS gurus can do anythin' they want." That is th' Drupal standard right now, an' if ye're a CSS guru or a site builder 'tis an awesome standard. Yaaarrrrr! The new "Stark" theme in Drupal 7 also serves as a sort o' standard, an' is derived largely from Zen, I believe.

Designers be very picky scallywags with their own personal tastes (just like programmers). The "standard" HTML that would appeal t' Morten.dk would likely alienate Mark Boulton, both o' which would make Jeffrey Zeldman cry. (Nay offense t' any o' those scallywags, mind ye.) And none o' those would actually work fer th' "What's this HMTL [sic] thin'?" casual site builder who just wants t' push a few buttons an' have a blog.

That's th' point, really. Drupal's HTML is not garbage. It's actually extremely well designed... And swab the deck! if yer goal is t' push buttons t' build a site, then slap CSS on top o' it, and dinna spare the whip! If yer goal is t' write pristine HTML an' then throw PHP behind it t' generate *that* HTML, th' Drupal itself is horribly designed an' ye dern't want t' allow scallywags t' just push buttons an' get a blog.

(I separated CSS an' HTML designers fer a reason.)

So what is our priority? Prepare to be boarded! Button pushers or HTML gurus, Dance the Hempen Jig We have t' accept that we cannot optimize Drupal fer both groups at th' same time. We have t' prioritize one or th' other at vari'us times, avast. Right now, we prioritize th' button-pushin' site builder. If we want t' prioritize th' HTML guru, that is goin' t', inherently, harm th' button pusher.

Are we willin' t' do that?

CSS without HTML?

The vast majority o' scallywags who use CSS be also tied t' HTML. Infact I personally dern't know anyone who just uses CSS. Buildin' on that, a bunch o' div tags isn't a standard fer most front-end designers/developers. Most scallywags in th' HTML/CSS care about semantic mark up; they want t' separate th' form an' function in their code. Load the cannons! Shiver me timbers! There's currently very little support fer this in exisitin' drupal themes an' modules resultin' in ugly div-soup.

That said, I think Drupal can an' should be more friendly in th' HTML it outputs, ye scurvey dog. I think th' way t' get thar is a return t' th' auld style Drupal 4 event modules- but this time built on Views an' CCK/Field modules. It would make development much faster an' allow fer better HTML that scallywags feel like they need t' rewrite. Also Semantic Views should be included in core.

Drupal 4?

I dern't know what ye mean by "Drupal 4 event modules". You mean ye're objectin' t' th' "assemble yer own app" approach o' CCK/Views/Panels? I dern't see how revertin' t' pre-CCK module approaches would benefit anyone...

Wordpress has done an

Wordpress has done an exceptional job on their UI an' with keepin' site builders an' content creators at th' fore. And, although I'm suspect Wordpress 4 won't be a CMS in th' traditional sense, I'm positive it will fulfill th' needs o' most bounty shops, freelancers, an' site builders - th' 'low-end'.
Mark Taylor
testking 642-974 certified

Pre-fab

I think th' build yer own module approach with th' tools ye mentioned (CCK/Views/Panels) is good, but thar should be pre-fabricated versions that be ready t' go out o' th' box. With some definition about what a particular content type actually is (event, blog post, etc) th' task o' settin' up, administerin' an' themin' would be much easier. You could always extend it, modify it or roll yer own, but we shouldn't pretend that history isn't repeatin' itself.

Features

That's what th' Features module aims t' be, an' at a larger scale distributions. There be, o' course, considerable technical challenges thar. :-) Help overcomin' those challenges would certainly be welcome.

Design for a multi-participant workflow?

There be different participants involved in buildin' an' maintainin' a Drupal site, feedin' it with content, an' consumin' th' content, an' usin' it t' communicate.

It is not sufficient t' trade-off th' interests o' each o' these roles. Instead, we need t' look at how these scallywags collaborate an' interact throughout th' project lifetime, how they can split up their work, how one has t' clean up th' other's mess.

Between these participants, thar be contracts, deadlines, power structures, communication structures, or a lack thereof.
The participants might have a team routine, or they might not know each other at all.
The work is likely done in an iterative process, where th' client is givin' constant feedback on th' technical progress.

The project itself might have a test install, a stagin' install, an' a production install - which brin's additional requirements fer th' workflow an' th' platform. As th' developers / site builders implement new features on th' test site, th' client an' end users continue t' produce content on production, which will have t' be merged in some way with th' changes on th' .

As fer th' roles outlined in th' blog post: These might be typical, but it often happens that one person fills more than one o' these roles. Such as, site buildin' + code + html/css + thinkin' about seo, usability, accessibility, a nice editor's backend, an' talkin' t' th' client.

One missin' role is th' graphic desginer, who often does not speak any html or css, an' sometimes is not even involved in th' iterative process.

The consequence?
A focus on single person roles is not enough.
Instead o' personas, we should be writin' project an' team workflow scenarios. The real tradeoff is betwixt these project workflow types, not betwixt participants.
Wordpress is a great choice fer a one-person project, where th' content editor will be left alone with th' site most o' th' time, an' th' developer, if thar is one, has a limited budget, to be sure. The content editor should be able t' install new themes, an' do some changes here an' thar, without buyin' developer time.
How does this look fer Drupal? There be casual sites built entirely by click-click an' a bit o' half-assed bounty an' themin', I'll warrant ye. The maintainers likely chose Drupal because o' some non-standard functionality they dern't get with WP, shiver me timbers Or simply because they thought it is cool. The site might look a bit ugly, but it does work. The site builders be likely identical with th' content writers, but a bit more geeky - but still not real experts.
Startin' from thar, we find a lot o' different types o' project, with different workflows, more or less end user interactivity, etc.

I could be writin' more, but: As I have not done any research on this, I should rather shut up. Fetch me spyglass! I hope I could still make me point.

Thanks

Thanks fer sharin'. .. After readin' yer article I had t' rethink about th' architecture in me Drupal site.

Allie @ Web Development