Starting at the middle
Working on the design for Spark and Drupal 8 has involved a lot of thought and research on site building in Drupal which has led me to a few interesting conclusions, one of which I want to illustrate here.
In WCM platforms there are basically two different approaches to site building; bottom up and top down. Bottom-up means basically build-it-from-scratch. That's essentially where Drupal 7 core is right now. The user must download, install, configure, choose modules and a theme, create content types, layouts, views etc. The process is time consuming and requires a certain level of expertise but presents few obstacles to what is possible assuming the user has the time to discover or create the right code.
The top-down approach gives the user an out-of-the-box site they can then customize. This is essentially where Drupal Gardens and many of the other SaaS site building platforms exist. The user is presented with a frictionless process for setting up a site which presents pre-configured "features" a theme and even placeholder content, all in one sitting. After that the user theoretically has the ability to customize the site. The drawbacks here are that the features the site provides are limited and may not match the users needs and the ability to customize is also limited. The promise of the top-down approach is that it removes work for the user, which is true if the user is happy with what they get out-of-the-box. In practice, however, the out-of-the-box site often does not match the vision the user has for the site they want. They are then forced to spend nearly as much time stripping away what they don't want and re-creating it as they would have spent building from scratch.
An alternative to these two would be what I call "starting at the middle". This approach would bring the user halfway to the goal, removing much of the tedious set-up work involved in the bottom-up approach, as well as the need to "strip away" unwanted cruft created in the top-down approach. This could be accomplished by identifying the commonalities that exist in what we call the "80% use case" that is the attributes that 80% of users require in a site.
Let's take the example of layouts. In Spark we are working on gridbuilder and layout modules which gives the user some powerful tools for building a set of responsive layouts using drag and drop interactions. Instead of presenting the user with a blank slate and expecting them to build responsive layouts from scratch we are doing a few things which follow the "start at the middle" approach.
- We pre-configure the 80% use case for breakpoints (smartphone, tablet, standard)
- We pre-configure a default set of regions with names that map to common web layout patterns (header, sidebar, footer etc.)
- We pre-populate each new layout with a subset of the default regions
- We give the user a set of default "starter" layouts that they can clone and alter to make their own.
By doing this we remove hours of development time per layout and accelerate the site building process dramatically. These improvements can be cumulative. Say for instance that we pre configure several more content types than currently exist in core and apply one of our preconfigured layouts as the default to those content types. Now the user has a site that by default has a richer set of features and is responsive out-of the-box. At the same time, within a few clicks, the user can change the layout or apply a different one. There's no laborious "stripping out" of theme markup.
Ok, so I'm getting a little ahead of myself but hopefully you see how the concept could scale to the rest of Drupal. By contrast let me give you an example of a Drupal admin UI that uses the "bottom-up" approach, the infamous field UI. Leaving aside the well known usability issues if the "start at the middle approach" were employed what you would have would be:
- Several pre-configured fields mapping to 80% use cases eg: "date", "price", "quote" etc.
- Several pre-configured "starter" content types mapping to 80% use cases that the user could clone to create their own
- Default layouts applied to the content types
- Pre-existing "sample" nodes for each "starter" content type with placeholder text so that the user could make sensible layout and style choices in the absence of real content.
Of course there will be those who still want to take the bottom-up approach. The important thing to remember is that nothing in the above example precludes the experienced Drupalist from going straight for the "boolean" field because they know what it is and how to use it. What it does do is to remove the necessity of having that knowledge from the site builder until they absolutely need it, leaving them a clear and rapid route to building everything else.