DrupalCon Paris: Drupal grows up

DrupalCon Paris 2009 is now in the past. As usual there was last minute chaos, lots of people running around behind the scenes going insane, people hugging friends they see once every six months, presentations ranging from super-technical to light and fluffy, general geekery, and of course copious amounts of beer. (This time we didn't drink out any of the bars, but then it is Paris.)

But there was something else, too, that I saw as an undercurrent of much of the conference: Maturity. Not the "acting like boring, responsible adults instead of having fun in Paris" kind of maturity (may that never happen), but the "thinking about more than just being code ninjas" kind of maturity. Drupal, as a whole, is growing up.

Designing the future

Going into DrupalCon, the big story was the Developers vs. Designers flap that started on Twitter, spread to IRC, and ended up exploding on Drupal Planet in a matter of hours. With both camps full armed for war going into the Con, the first thing everyond did was hug. (There apparently is a picture of merlinofchaos and Mark Boulton hugging somewhere, but I don't have a copy.) The second thing everyone did was start discussing what practical steps could be taken to make life easier for designers. There were presentations covering the subject as well as BoFs both formal and informal. Fellow Palantiri John Wilkins even held court after the Con ended on what we can do to make life easier for designers and how to get them more engaged.

The conclusion? The problem with the oft-maligned issue queue isn't that it's designer-unfriendly. It's that it sucks for meta-discussions and architectural questions in general. Design and UX issues are almost always meta-discussions. Code issues sometimes are, sometimes aren't, and when they are the issue queue sucks for them just as much as it does for UX or design questions. So making the issue queue more useful for meta-discussion would be a big win for everyone involved.

How do we do that? Well, there's a couple of things needed:

1. Death to +1 subscribe. Designers complain about it. Developers complain about it. Users complain about it. It needs to happen.
2. Add wiki-page support to project_issue. That is, allow for wiki-style pages to have issue-comment behavior. Those can then serve as a place for meta-discussions, and the initial posting can be kept up to date as the "current architectural vision". It should also have a field specifically for linking to related issues where actual implementation can happen piecemeal, which is generally much more efficient.

   Jeff Eaton and I discussed the best way to do that, and it's probably by making issue follow-up behavior fieldable in Drupal 7. Then that fieldability can be applied to both "issue" nodes and "meta-issue" nodes, with their own fields and settings. Who wants to step up and work on that? It has to happen before Drupal.org can move to Drupal 7 anyway...

3. Develop an improved way for developers to flag an issue as "hey, this needs a design/UX person's input, just tell me what to do and I'll do it". The current "Needs Usabililty Review" tag is just not cutting it. Several designers specifically suggested some form of merging that tag with the "Assigned" property (which is currently almost useless). In fact, there was high demand for the ability to assign an issue round-robin style to a specific list of volunteer design/UX people. That's a really cool idea that could vastly improve project.module's ability to provide a more formal workflow and allow teams, rather than random individuals, to work on a given task.

Organizing the user experience

The astute reader will notice a subtle but important part of that last point: A formal team of usability/UX people. There was actually a great deal of interest in the idea of a more organized, formal usability team. Many open source projects have a formal UX team, made up of trained usability specialists, even going as far as having an official, published User Interface Guidelines document or Human Interface Guidelines (HIG) document just as there are published coding standards. Non-conformity with those guidelines is then a bug, and code is adjusted accordingly. Just have a look at Apple or KDE (see also here) or GNOME to see how effective a published HIG can be. You may not like specific details of those HIGs, but they do result in a consistent, predictible, easily-learnable interface paradigm.

I floated the idea to a number of people at DrupalCon of creating a Drupal HIG/UX group, and the response was universally positive. I even had a thorougly enjoyable lunch with Mark Boulton, covering both the idea of a HIG group and the differing mindsets of designers and open source programmers. To an extent, having a more structured place where design and usability (which are separate but related subjects) can happen, with experts in those fields, would go a long way toward helping with both issues. In fact, having a good, researched HIG will inform developers on what code needs to be written to make following that HIG and creating good, consistent UIs dead-simple.

We have an official Documentation Lead, and a semi-formal team behind her. It's time for an official Usability Lead along similar lines.

The business of business

Meanwhile, there was a business-oriented panel on Paying the Plumber, exploring the question of how Drupal shops and professional developers can fund work on Drupal or contrib modules. What was most significant, and I wish I could recall who it was that noted it, was that no one was asking "how do we make money with this open source stuff?" A few years ago we may have asked that question, but today that's taken as a given. There's plenty of money to be made with Drupal. The question was how to funnel that money back into making Drupal rock even more, something everyone actively wants to do.

Drupal's business world has grown up, too.

Architecting core

The other under-current was of course the budding smallcore movement. The name is sadly misleading, as has nothing to do with size. It has to do with architectural vision. Is Drupal a framework or an extensible application? Right now the answer is "kinda sorta both". In order to make the answer "seriously awesome for both", we need to treat Drupal itself more as a framework, mentally, and then leverage that to build (and bundle) a first class extensible application on top of it.

Of course, doing that properly requires a coherent architectural vision, and a more professional, broad view of how we structure code and APIs. For more on that, look no farther than the accidentally complementary presentations by Jeff Eaton and myself, Architecture is for Everyone and Drupal Design Patterns, respectively. The latter wasn't even going to be a session this time around, but due to a last minute cancellation I was asked to fill in. I'm very glad I was, too, because it ended up being a very solid presentation with tons of positive feedback. My presentation covered looking at the big picture of APIs, and how to leverage abstract conceptual work already done by other people as well as existing code. Eaton's covered the even broader picture of site and application architecture and planning as a whole, and even went so far as to put on the screen, in big red letters, "ROAD MAP". Bless you, Jeff! Yes, the forbidden word has been uttered. Does Drupal need a roadmap? Perhaps not an official, canonincal one but informally at least? I didn't speak to a single person who didn't say "dear god yes!"

World domination takes careful planning and coordination. Drupal is at a size where we can no longer afford to work on separate APIs and subsystems in isolation, hoping that they'll somehow all fit together. Would you trust a house that is built like that? I wouldn't. Why should we do that with our software?

Let's make Drupal 8 the most well-planned Drupal ever. That's the only way we'll be able to make it the most powerful Drupal ever. If you missed either presentation, I strongly recommend that you watch the videos as soon as they become available.

Other Drupal fun

Naturally there was much more going on at DrupalCon.

There was the elaborately planned (there's that word again) Druplicon road trip that came to its final conclusion in Dries' opening keynote.

There was the crazy descent into the Paris Catacombs (also known as the Isobar room) where I gave two back to back presentations to packed rooms. (Really, why was one of the presentation rooms in Hades?)

There was the crazy network that managed to crash Drupal.org during the first code sprint until the network admins managed to adjust it to not die when 900+ people all hit it from the same NAT-ed IP address. (Oops.)

There was staying up all night chatting with Merlin and Esmerel of Chaos (Sprout gets cuter every Con, I swear) about Sci-Fi until we realized that the trains had stopped running, resulting in me spending the night on the couch of their penthouse. (Thanks, guys! I owe you dinner. Again.)

There was my POS new netbook that managed to fail miserably at connecting to the wireless at the conference until after the closing ceremonies when Emma-Jane showed me how to unbork it. (Remind me to ask you for help sooner next time...)

There was getting the entire database team together for the first time ever for a group photo.

And of course there was randomly running into quicksketch and his family on the way to Versailles a week later while on vacation. Vive le Drupal!

Planning forward

We've still got a few weeks of "code slush" left to finish making Drupal 7 awesome, followed by intensive bug squishing so that we can get Drupal 7 (and its contrib modules!) out the door ASAP. Let's make the most of it, unleash the awesome that is Drupal 7 on an unsuspecting world, and then hit the ground running for Drupal 8 with a clear vision and architecture for how to surpass even Drupal 7.

Let's take usability seriously with a formal, empowered usability lead and a real HIG document. Let's take architectural design seriously, too, and make Drupal the best possible framework it can be, so that it can power the best possible CMS application. Let's make both possible with a revamped issue queue that can support macro-issues as well as micro-issues. And let's try to get at least some of that done in time for DrupalCon San Francisco.

Our little Druplicon has grown up. It's time for us to grow up with it.