Drupal: a way forward by focusing on the right layer – and the right user

There is much talk nowadays about Drupal needing to strip things out of core to make it more maintainable. I agree with the sentiment.

On the other hand, there are many people who feel that the process of moving frequently-used contributed modules into core should continue, since these are things that every site builder needs for every site. I agree with this sentiment, too.

There is also much talk about Drupal’s usability, and that it needs to be improved. I agree with this sentiment as well. (Everyone does.)

However, moving more things into core won’t help with the problem of maintainability that core developers complain of. But moving things out will hurt Drupal’s usability and usefulness for site builders. These two goals are largely at odds with each other, though they both need to happen. How do we resolve this dilemma?

Similarly, focusing too much on usability for “novice” users won’t help site builders much. It also won’t help novice users if things like Blog and Forum are moved out of core (as they should be). No matter how “easy” Drupal becomes, these users will still be thoroughly confused by all the concepts involved. Simply put, Drupal is not the system for them, and Drupal should not focus on their needs. Yet we do want to accommodate such users. How do we resolve this dilemma?

I believe that in order to resolve these dilemmas, people need to start thinking about Drupal differently. Otherwise, if we go too far along any of these paths, Drupal will continue to be a confused mess that doesn’t fit anyone’s needs very well.

When I look at Drupal, I see three layers corresponding to what I feel are the three main audiences that interact with it:

  1. Code/API/Framework layer: this corresponds to core coders, module developers, and experienced programmers building highly-custom site solutions in code (ie, writing their own custom modules)
  2. Site Building layer: this corresponds to the typical site builders – fairly experienced web developers who have a good grasp of concepts like using modules to extend site functionality, tweaking the site by customized settings, differentiating different types of content, defining content types to include discrete fields of information, and using blocks, Views, layouts, etc. to show those chunks of content variously in different places on the site.
  3. Complete Solutions layer: this corresponds to end-user site owners and less experienced developers. Basically anyone that wants to put up a “blog” or a “forum” or a “gallery” or a “brochure site” for their business with the minimum of effort (push a button), and doesn’t understand (or want to have to understand) the concepts in the previous layer.

The first layer is important – it needs to be available to build highly-customized, high-performance sites with special needs. It’s also what all the other layers are built on top of. But this layer should not be the primary focus of Drupal. Why? It’s not where Drupal shines above all others – if this is the target, then the competition is all the other frameworks out there – Symfony, CogeIgniter, CakePHP, Zend, Ruby on Rails, Django, etc. Is Drupal really better at that kind of site-building than all these other frameworks? Maybe, but even if so, is that the battle we want to focus on?

The third layer is also important – there is a huge audience of people out there who want to be able to throw up various kinds of sites with a “1-click” installation, and Drupal should be able to meet their needs. But this layer should not be the primary focus of Drupal. Why? First, it’s not where Drupal shines above all others – Drupal (even with the Blog or WP Blog module) is not a better out-of-the-box blog platform than WordPress. Advanced Forum is probably not a better out-of-the-box forum than various other forum-specific options, etc. Further, even if these are included in a fairly easy-to-use installation profile, they’re still never going to be easier to install than a hosted solution like WordPress.com or Tumblr, where no installation is required at all. This is a battle we simply cannot win, and are already coming from a position of considerable weakness.

No, it is the second layer that is Drupal’s strength, and where the nexus of development and usability should be focused. For this brings us to the next big problem when it comes to moving Drupal forward: a lack of focus. To put it bluntly, the Drupal community that discusses usability and what should be in core has not decided who its audience is (or has perhaps picked the wrong audience). And without a clearly-defined audience to focus on, the likelihood of meeting the needs of any audience is low.

So how do we go about resolving these issues?

  1. Framework/API/Code level:
    1. Strip this down as much as possible – it should provide only the low-level, fundamental services needed to build the rest on. It should certainly not include any complete solutions like “blogs” or “forums” (or even “books”).
    2. Re-use as much code from Symphony2 as possible – if Drupal doesn’t absolutely NEED its own unique version of this sort of code, don’t write it. Let somebody else maintain this code so Drupal core developers can focus on the things that make Drupal unique.
  2. Site builder level:
    1. Figure out the key capabilities supplied by common contrib modules, and move them into the base distribution (much like CCK -> Field API). Newsflash: if 90% of Drupal developers use the same 10-20 modules on EVERY SINGLE SITE, then those modules ARE de facto core, whether you like it or not. Drupal without these modules is not a useful site-building system for most developers. These modules might include things like:
      • Date, Link and other useful field types
      • some subset of Display Suite and/or Panels
      • Fieldgroup
      • Better Formats
      • some kind of WYSIWYG/image handling (I like WYSIWYG+CKEditor+CKEditor Link+IMCE)
      • Meta Tags
      • Node Hierarchy (since Book is too specific and poorly-named, and menus/taxonomy just don’t work as it seems they should for building hierarchies)
      • Token
      • Pathauto
      • Views
      • Webform
      • Workbench or some other workflow solution
      • XML Sitemap
      • etc.
    2. Focus your usability efforts on this audience and these capabilities. Drupal is still pretty darn confusing even for experienced site builders – partly because so much needed functionality IS supplied by a variety of contributed modules, each of which may do things its own way.
  3. Novice/end-user site owner level:
    1. Clearly relegate this to installation profiles and separate documentation for this audience. It’s gotta be done – no more whining about how installation profiles might not end up being adopted or meeting needs. No other approach to “fixing” Drupal is going to either. Also stop whining about how you might miss out on millions of non-technical newbies who might go to Tumblr.com instead if you don’t make this audience part of your core. They’re going to do that anyway. Drupal isn’t right for them, and persisting in thinking it is is distracting you from fixing it for your real core audience.
    2. Stop doing usability studies of this audience (except with reference to improving those installation profiles and the associated documentation). It’s like asking how you can make the mathematics of quantum physics more accessible to English majors. Stop doing that. Please, just stop. It’s a waste of time and you’re losing focus on what really matters.

The Way Forward
First, figure out who your core audience is. How? Figure out where you have unique strengths compared to your competitors. Now, focus relentlessly on meeting the needs of that audience.

Ultimately, I think site-builders are the core audience of Drupal. Thus I think Drupal’s core developers and UX team should focus relentlessly on meeting site builders’ needs. To avoid distractions, the low-level core code should be stripped down and migrated to relying on an outside library/framework (Symphony2) as much as possible, and the focus on non-technical end users should shift to a separate project of installation profiles and documentation built on top of Drupal, rather than being part of Drupal itself.

Otherwise I think Drupal, as a project and a community, is going to have a very difficult time meeting anyone’s needs well, and may even collapse under its own weight.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: