Today is another big day for Drupal as we just released Drupal 8.1.0. Drupal 8.1.0 is an important milestone as it is a departure from the Drupal 7 release schedule where we couldn't add significant new features until Drupal 8. Drupal 8.1.0 balances maintenance with innovation.
On my blog and in presentations, I often talk about the future of Drupal and where we need to innovate. I highlight important developments in the Drupal community, and push my own ideas to disrupt the status quo. People, myself included, like to talk about the shiny innovations, but it is crucial to understand that innovation is only a piece of how we grow Drupal's success. What can't be forgotten is the maintenance, the bug fixing, the work on Drupal.org and our test infrastructure, the documentation writing, the ongoing coordination and the processes that allow us to crank out stable releases.
We often recognize those who help Drupal innovate or introduce novel things, but today, I'd like us to praise those who maintain and improve what already exists and that was innovated years ago. So much of what makes Drupal successful is the "daily upkeep". The seemingly mundane and unglamorous effort that goes into maintaining Drupal has a tremendous impact on the daily life of hundreds of thousands of Drupal developers, millions of Drupal content managers, and billions of people that visit Drupal sites. Without that maintenance, there would be no stability, and without stability, no room for innovation.
Earlier this month, the international media group Hubert Burda Media (about 2.5 billion annual revenue, more than 10,000 employees, and more than 300 titles) released its Drupal 8 distribution, Thunder. Thunder includes custom modules specifically tailored to the needs of professional publishers.
This is great news for three reasons: (1) I've long been a believer in Drupal distributions, (2) I believe that publishers shouldn't compete through CMS technology, but through strong content and brands, and (3) Thunder is based on Drupal 8.
Distributions enable Drupal to compete against a wide range of turnkey solutions, as well as break into new markets. The number of vertical distributions that can be created is nearly limitless, and the possibilities are endless. Thunder is a great example of that.
Professional publishing is one of the industries that has faced the most extensive business model disruption because of the web. Many companies are feeling pressure on their revenue streams, yet you'll find that some companies still focus their efforts on building proprietary, custom CMS platforms as a way to differentiate. This doesn't have to be the case – I've long believed that Drupal (and open source, more generally) can give publishers endless ways to differentiate themselves at much lower costs.
The following video gives an overview of the Thunder approach:
Thunder adds a range of publisher-centric Drupal modules to Drupal 8 core. Specifically, Burda added integrations with audience "circulation" counting tools and ad servers, as well as single sign-on (SSO) support across multiple sites. They've also developed a theme which implements infinite scrolling.
Thunder users also benefit from a range of channel- and feature-specific enhancements through collaboration with industry partners. The following extensions are already available or in the final stages of development:
I admire the approach Burda is taking to bring publishers, partners and developers together from throughout the industry to develop the best open-source CMS platform for publishers.
At the core is a team of publishing experts and developers led by Ingo Rübe, CTO for Burda's German publishing operations, and initiator of Thunder. This team will also be responsible for coordinating the continuous development and enhancement of Thunder.
Under Thunder's policy, all features provided by industry partners must be offered for free or with a freemium model; in other words, a significant part of the functionality has to be provided at no cost at all. Smaller publishers will likely benefit from this approach, as they will be able to use a full-fledged publishing solution that is continuously enhanced and maintained by larger partners.
Although Thunder is still in public beta, Burda has migrated three brands to Thunder. The German edition of Playboy (about 2M monthly visits) was the first to move at the end of 2015. The fashion brand InStyle (about 1.8M monthly visits) and gardening website "Mein schöner Garten" (about 1.5M monthly visits) are also running on Thunder. Most of the other German Burda brands are planning to adopt Thunder in the next 12 months. This includes at least 20 brands such as Elle.de and Bunte.de, which have more than 20 million monthly visits each.
You can download Thunder from https://www.drupal.org/project/thunder.
I've been writing a lot about what I believe is important for the future of Drupal, but now it is your turn. After every major release of Drupal I do a "product management survey" to get your ideas and data on what to focus on for future releases of Drupal (8.x/9).
The last time we had such a survey was after the release of Drupal 7, six months into the development of Drupal 8. I presented the results at DrupalCon London in 2011. The results informed the Drupal community at large, but were also the basis for defining initiatives for Drupal 8. This time around, I'm hoping for similar impact, but also some higher-level strategic thinking about how Drupal should respond to various market trends.
It shouldn't take more than 10-15 minutes to fill out the survey. We'd like to hear from everyone who cares about Drupal: content managers, site owners, site builders, module developers, front-end developers, people selling and marketing Drupal, etc. Whether you are a Drupal expert or just getting started with Drupal, every voice counts! Best of all, with Drupal 8's new 6-month release cycle, we can act on the results of this survey much sooner than in the past.
I will be presenting the results during my DrupalCon New Orleans keynote (the video recording of the keynote, the presentation slides and the survey results will be downloadable on my blog after). Please tell us what you think about Drupal; your feedback will shape future versions of Drupal.
At DrupalCon Mumbai I sat down for several hours with the Drupal team at Pfizer to understand the work they have been doing on improving Drupal content management features. They built a set of foundational modules that help advance Drupal's content workflow capabilities; from content staging, to multi-site content staging, to better auditability, offline support, and several key user experience improvements like full-site preview, and more. In this post, I want to point a spotlight on some of Pfizer's modules, and kick-off an initial discussion around the usefulness of including some of these features in core.
Before jumping to the technical details, let's talk a bit more about the problems these modules are solving.
All these use cases share a few key traits:
Much of this started as a single module: Deploy. The Deploy module was first created by Greg Dunlap for Drupal 6 in 2008 for a customer of Palantir. In 2012, Greg handed over maintainership to Dick Olsson. Dick continued to improve Deploy module for Al Jazeera while working at Node One. Later, Dave Hall created a second Drupal 7 version which more significant improvements based on feedback from different users. Today, both Dick and Dave work for Pfizer and have continued to include lessons learned in the Drupal 8 version of the module. After years of experience working on Deploy module and various redesigns, the team has extracted the functionality in a set of modules:
This module does three things: (1) it adds revision support for all content entities in Drupal, not just nodes and block content as provided by core, and (2) it introduces the concept of parent revisions so you can create different branches of your content or site, and (3) it keeps track of conflicts in the revision tree (e.g. when two revisions share the same parent). Many of these features complement the ongoing improvements to Drupal's Entity API.
Built on top of Multiversion module, this lightweight module reads revision information stored by Multiversion, and uses that to determine what revisions are missing from a given location and lets you replicate content between a source and a target location. The next two modules, Workspace and RELAXed Web Services depend on replication module.
This module enables single site content staging and full-site previews. The UI lets you create workspaces and switch between them. With Replication module different workspaces on the same site can behave like different editorial environments.
This module facilitates cross-site content staging. It provides a more extensive REST API for Drupal with support for UUIDs, translations, file attachments and parent revisions — all important to solve unique challenges with content staging (e.g. UUID and revision information is needed to resolve merge conflicts). The RELAXed Web Services module extends the Replication module and makes it possible to replicate content from local workspaces to workspaces on remote sites using this API.
In short, Multiversion provides the "storage plumbing", whereas Replication, Workspace, and RELAXed Web Services, provide the "transport plumbing".
Historically Deploy module has taken care of everything from bottom to top related to content staging. But for Drupal 8 Deploy has been rewritten to just provide a UI on-top of the Workspace and Replication modules. This UI lets you manage content deployments between workspaces on a single site, or between workspaces across sites (if used together with RELAXed Web Services module). The maintainers of the Deploy module have put together a marketing site with more details on what it does: http://www.drupaldeploy.org.
To handle use case #5 (content recovery) the Trash module was implemented to restore entities marked as deleted. Much like a desktop trash or recycle bin, the module displays all entities from all supported content types where the default revision is flagged as deleted. Restoring creates a newer revision, which is not flagged as deleted.
Drupal 8.0 core packed many great improvements, but we didn't focus much on advancing Drupal's content workflow capabilities. As we think about Drupal 8.x and beyond, it might be good to move some of our focus to features like content staging, better audit-ability, off-line support, full-site preview, and more. If you are a content manager, I'd love to hear what you think about better supporting some or all of these use cases. And if you are a developer, I encourage you to take a look at these modules, try them out and let us know what you think.
The authoring experience improvements we made in Drupal 8 appear to be well-received, but that doesn't mean we are done. With semantic versioning in Drupal 8, we can now make more UX changes in follow-up releases of Drupal 8. So now is a good time to start moving Drupal's user experience forward.
The goal of this post is to advance the conversation we started over a month ago in a blog post talking about the concept of turning Drupal outside-in. In today's blog post, we'll show concrete examples of how we could make site building in Drupal easier by embracing the concept of outside-in. We hope to provide inspiration to designers, core contributors and module maintainers for how we can improve the user experience of Drupal 8.2 and beyond.
In Drupal you often have to build things from the ground up. If you want to make a list of events you need to wade through 20 different menu options to a user interface with configuration options like "boolean" and "float", build a content type, content, and then a view. Essentially you need to understand everything before you can build anything.
In an "outside-in" experience – or what Kevin OLeary (Director of Design on my team at Acquia) calls Literal UI – you can click anything on the page, edit its configuration in-place, and watch it take effect immediately.
Over the past few years Drupal has adopted a more outside-in approach, the most obvious example being Drupal 8's in-place editing. It enables you to edit what you see with an uninterrupted workflow, faster preview, and removes the need to visit the administration backend before you can start editing.
To evaluate how outside-in can be applied more broadly in order to make Drupal easier to use, Kevin created a few animated gifs.
Editing menu options in Drupal has already become more outside-in with contextual links. The contextual links take away some of the guesswork of finding the proper administration UI, but once you arrive at the configuration page there is still a lot of stuff to take in, only some of which is relevant to this task.
Anyone familiar with Drupal will recognize the pattern above; you go to an administration UI, make some changes, than you go back to the page to see if it worked. This context switching creates what UX people call "cognitive load". On an administration page you need to remember what was on the site page and vice-versa.
To complete this task you need to:
The problem is not just that there are too many pages, clicks, or words, it's that each step away from the actual page introduces new opportunities for confusion, error and repetition. In user testing, we have seen users who were unable to find the contextual link, or to understand which option to choose, or to find the "add link" button, or to add a path, or drag-drop links, or to save before leaving the UI. When these things happen in context, feedback about whether you are "doing it right" is immediate.
Now all you need to do is:
One important aspect of this approach is that all actions that produce a visible change have bi-directional control and bi-directional feedback. In other words, if you can drag something in the configuration drawer you should also be able to drag it on the page, and the changes should happen simultaneously.
The process of placing a block on a page can be difficult. Once you discover where to go to add a block, which is in itself a challenge, the experience requires a lot of reading and learning, as well as trial and error.
To complete this task you need to:
Eventually you'll use what you just learned, but Drupal makes you learn it first instead of just showing what is immediately necessary. Both the task and the learning can be simplified by bringing the configuration closer to the object you are configuring.
Now all you need to do is:
The "plus" button, the drop target (blue dotted rectangle) and the autocomplete are all commonly understood patterns used by other software. The task requires no or little explanation as the interactions reveal the process. By starting with selecting the location of where to place the block, we avoid the need for drag-and-drop and the complexity of dragging a block on a page that requires scrolling.
These examples show the principle that rather than taking the site builder to a separate administration backend, the experience should begin with the actual page and show how the changes will be seen by the end-user. The patterns shown here are less important. For example, the animated gifs above show two different approaches to the options panel and there are certainly others. The important thing is not yet where the panel comes from or how it looks, but that the following criteria are met:
The ideas in this post are meant to provide some food for thought and become the seed of some patches for Drupal 8.2. Rather than dive right into development, we're looking to the Drupal community to take these designs as a starting point to prototype and user-test more outside-in experiences in Drupal.
The next post in this series will cover outside-in experiences with more complex contexts and the problem of "leaky abstractions". If you don't want to miss the next blog post, make sure to subscribe. In the mean time, I'd love to hear what you think!
Updates from Dries straight to your mailbox