Building Workbench: A Community Approach

The Workbench project started as an internal Palantir project. We started working in earnest on Workbench just after DrupalCon San Francisco, when we introduced some of our ideas in the Drupal 7, Here We Come! panel.

Since then Workbench has been developed and we have released a stable beta, which we demonstrated at DrupalCon Chicago. If you missed it, Workbench: Managing Content Management is now online. Our plan has always been to release the module suite under the GPL on drupal.org. Here's why. At Palantir, we're committed to open source.

During the DrupalCon keynote, Dries Buytaert thanked the top 30 patch contributors to Drupal 7. Three of them (Dave Reid, John Albin Wilkins and Larry Garfield) work with us. I'm #45, and I was sitting next to Matt Farina (#54). (And that doesn't even count Jen Simmons, whose work on the new core Bartik theme was monumental but only one commit!)

We are justifiably proud of this approach to our work. We build on Drupal to make site development faster, more secure and more sustainable for our clients. We contribute back to Drupal whenever possible because doing so makes the product better and in turn, makes our work easier. So when we started to think about site building with Drupal 7, we asked two fundamental questions:

1. What pain points do our clients have when using Drupal for content management?
2. How can we contribute improvements to the Drupal community?

From a content management perspective, the biggest hurdles our client faced seemed to recur from project to project:

• Drupal forces a learning curve on all users, especially with respect to terminology and workflow.
• No easy solution exists to find the content that matters to a specific editor.
• Edits to live content could not be proofread by multiple editors before being pushed live.
• Media editing and integration is divorced from content editing.
• Our old CMS had feature X. The new site doesn't, but we never stated it as a requirement because we assumed all CMS's had that feature.

Now there are many solutions to some of these problems &emdash; and there are no solutions to some of them. Solutions for common problems must often be solved by the use of multiple modules. Sometimes these modules are contradictory or incompatible. To test this theory, we drafted a matrix of common feature requests, reproduced below:

• 19 different modules are mentioned in the feature list.
• These modules use different terminology, user interface elements, and programming methods to achieve their goals.
• Many of these modules have no Drupal 7 equivalents (yet).
• Integrating and standardizing existing features can be a huge win.

With that in mind, we targeted Workbench to fill in functional gaps in Drupal while making common tasks easier. While the first phase of development was private (we have launched two Drupal 7 sites which use the suite: www.barnard.edu and www.fieldmuseum.org), we were working directly with content managers and editors for these clients. Their feedback helped direct the development of the project.

In a similar way, we know that releasing these modules on Drupal.org will lead to the same collaborative gains. Features will be expanded, new concepts applied, and better integration developed. Want proof? Here's a glimpse at the issues filed for the main Workbench module:

Open, community development is a big part of the project. There are two major emphases here:

Improved user experience (UX) for editorial tasks

We started the Workbench project by focusing on the needs of the editor, not the software. This ideal informs the work behind Workbench. In fact, we would like to help Drupal develop proper design and interface patterns for contributed modules, so that tight integration of modules becomes easier. Already, Drupal UX contributors Roy Scholten (yoroy) and Bruno De Bondt (brunodbo) performed usability testing during DrupalCon Chicago. (And we know that D7UX lead Leisa Reichelt (leisareichelt) is asking for a demo site so she can provide feedback.) Making editorial actions easier (dare I say "fun") is a major goal of the Workbench project, some of which may make its way into Drupal 8 core. And we know that by reaching out to the Drupal community, our work will be much more fun, both for clients and for us.

Improved developer experience (DX) for integrating features

One of the problems with Drupal is that great solutions to problems are sometimes self-contained. That means that while a module might work beautifully for a given use-case, it breaks just as badly when that use-case shifts. This is both an architecture and an attitude problem with module development. It's very easy to become short-sighted and goal-oriented, just to finish the functionality and move on. Larry Garfield gave an excellent Aphorisms of API Design talk at DrupalCON that encourages developers to take a long view of module development. With Workbench, we don't want to introduce a huge, monolithic solution into the Drupal ecosystem.

Instead, we want to provide modular, extensible functionality that solves common problems in ways that can be enabled and disabled without having to refactor your site. The only way to do this, of course, is to let people try to implement features from your core work. If the APIs fail, then Workbench will fail. Luckily, we're building features off our own APIs -- plus those provided by Views and Drupal core. That means that some feature requests, such as extending access rules by content type are less technical challenges than resourcing issues. This issue is easy to fix; someone just needs to take the time to fix it.

In that respect, we're trying to model a feature-driven development process on Drupal.org. If you read through the issue queues, you'll see us prompting people for more information, more clarity about what their expectations are. Once defined, the technical solution can grow from the natural use-case (instead of users being forced into habits that make development easier).