Over the weekend, Drupal 8.2 beta was released. One of the reasons why I'm so excited about this release is that it ships with "more outside-in". In an "outside-in experience", you can click anything on the page, edit its configuration in place without having to navigate to the administration back end, and watch it take effect immediately. This kind of on-the-fly editorial experience could be a game changer for Drupal's usability.
When I last discussed turning Drupal outside-in, we were still in the conceptual stages, with mockups illustrating the concepts. Since then, those designs have gone through multiple rounds of feedback from Drupal's usability team and a round of user testing led by Cheppers. This study identified some issues and provided some insights which were incorporated into subsequent designs.
Two policy changes we introduced in Drupal 8 — semantic versioning and experimental modules — have fundamentally changed Drupal's innovation model starting with Drupal 8. I should write a longer blog post about this, but the net result of those two changes is ongoing improvements with an easy upgrade path. In this case, it enabled us to add outside-in experiences to Drupal 8.2 instead of having to wait for Drupal 9. The authoring experience improvements we made in Drupal 8 are well-received, but that doesn't mean we are done. It's exciting that we can move much faster on making Drupal easier to use.
As you can see from the image below, Drupal 8.2 adds the ability to trigger "Edit" mode, which currently highlights all blocks on the page. Clicking on one — in this case, the block with the site's name — pops out a new tray or sidebar. A content creator can change the site name directly from the tray, without having to navigate through Drupal's administrative interface to theme settings as they would have to in Drupal 7 and Drupal 8.1.
In the second image, the pattern is applied to a menu block. You can make adjustments to the menu right from the new tray instead of having to navigate to the back end. Here the content creator changes the order of the menu links (moving "About us" after "Contact") and toggles the "Team" menu item from hidden to visible.
In Drupal 8.1 and prior, placing a new block on the page required navigating away from your front end into the administrative back end and noting the available regions. Once you discover where to go to add a block, which can in itself be a challenge, you'll have to learn about the different regions, and some trial and error might be required to place a block exactly where you want it to go.
Starting in Drupal 8.2, content creators can now just click "Place block" without navigating to a different page and knowing about available regions ahead of time. Clicking "Place block" will highlight the different possible locations for a block to be placed in.
These improvements are currently tagged "experimental". This means that anyone who downloads Drupal 8.2 can test these changes and provide feedback. It also means that we aren't quite satisfied with these changes yet and that you should expect to see this functionality improve between now and 8.2.0's release, and even after the Drupal 8.2.0 release.
As you probably noticed, things still look pretty raw in places; as an example, the forms in the tray are exposing too many visual details. There is more work to do to bring this functionality to the level of the designs. We're focused on improving that, as well as the underlying architecture and accessibility. Once we feel good about how it all works and looks, we'll remove the experimental label.
We deliberately postponed most of the design work to focus on introducing the fundamental concepts and patterns. That was an important first step. We wanted to enable Drupal developers to start experimenting with the outside-in pattern in Drupal 8.2. As part of that, we'll have to determine how this new pattern will apply broadly to Drupal core and the many contributed modules that would leverage it. Our hope is that once the outside-in work is stable and no longer experimental, it will trickle down to every Drupal module. At that point we can all work together, in parallel, on making Drupal much easier to use.
Users have proven time and again in usability studies to be extremely "preview-driven", so the ability to make quick configuration changes right from their front end, without becoming an expert in Drupal's information architecture, could be revolutionary for Drupal.
If you'd like to help get these features to stable release faster, please join us in the outside-in roadmap issue.
I'd also like to thank everyone who contributed to these features and reviewed them, including Bojhan, yoroy, pwolanin, andrewmacpherson, gtamas, petycomp, zsofimajor, SKAUGHT, nod_, effulgentsia, Wim Leers, catch, alexpott, and xjm.
In a recent post we talked about how introducing outside-in experiences could improve the Drupal site-building experience by letting you immediately edit simple configuration without leaving the page. In a follow-up blog post, we provided concrete examples of how we can apply outside-in to Drupal.
The feedback was overwhelmingly positive. However, there were also some really important questions raised. The most common concern was the idea that the mockups ignored "context".
When we showed how to place a block "outside-in", we placed it on a single page. However, in Drupal a block can also be made visible for specific pages, types, roles, languages, or any number of other contexts. The flexibility this provides is one place where Drupal shines.
For the sake of simplicity and focus we intentionally did not address how to handle context in outside-in in the last post. However, incorporating context into "outside-in" thinking is fundamentally important for at least two reasons:
To begin to incorporate context into outside-in, Kevin Oleary, with input from yoroy, Bojhan, Angie Byron, Gábor Hojtsy and others, has iterated on the block placement examples that we presented in the last post, to incorporate some ideas for how we can make context outside-in. We're excited to share our ideas and we'd love your feedback so we can keep iterating.
To solve the problem, we recommend introducing 3 new concepts:
Most sites have some concept of a "section" or "type" of page that may or may not equate to a content type. A commerce store for example may have a "kids" section with several product types that share navigation or other blocks. Page groups adapts to this by creating reusable "bundles" of content consisting either of a certain type (e.g. all research reports), or of manually curated lists of pages (e.g. a group that includes /home, /contact us, and /about us), or a combination of the two (similar to Context module but context never provided an in-place UI).
User groups would combine multiple user contexts like role, language, location, etc. Example user groups could be "Authenticated users logged in from the United States", or "Anonymous users that signed up to our newsletter". The goal is to combine the massive number of potential contexts into understandable "bundles" that can be used for context and impersonation.
As mentioned earlier, a challenge is that you want to preview what site visitors will see, not what you see as a site builder or site administrator. Impersonation allows site builders to switch between different user groups. Switching between different user groups allow a page to be previewed as that type of user.
Let's take a look at how we use these 3 ingredients in an example. For the purpose of this blog post, we want to focus on two use cases:
Things can get more complex but these two use cases are a good starting point and realistic examples of what people do with Drupal.
Let's assume the user is a content editor, and the user groups "Anonymous" and "Subscriber" as well as the page groups "Subscriber pages" and "Public pages" have already been created for her by a site builder. Her first task is to place the "Access reports" block and make it visible only for anonymous users.
Our editor's next task is to place the "Download reports" block and make it visible only for subscribers. To do that she is going to want to view the page as a subscriber. Here it's important that this interactions happens smoothly, and with animation, so that changes that occur on the page are not missed.
Once our editor has finished step one and two she will want to go back and make sure that step two did not undo or complicate what was done in step one, for example by making the "Download report" block visible for Anonymous users or vice versa. This is where impersonation comes in.
The idea of combining a number of contexts into a single object is not new, both context and panels do this. What is new here is that when you bring this to the front-end with impersonation, you can make a change that has broad impact while seeing it exactly as your user will.
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!
There has been a lot of discussion around the future of the Drupal front end both on Drupal.org (#2645250, #2645666, #2651660, #2655556) and on my blog posts about the future of decoupled Drupal, why a standard framework in core is a good idea, and the process of evaluating frameworks. These all relate to my concept of "progressive decoupling", in which some portions of the page are handed over to client-side logic after Drupal renders the initial page (not to be confused with "full decoupling").
My blog posts have drawn a variety of reactions. Members of the Drupal community, including Lewis Nyman, Théodore Biadala and Campbell Vertesi, have written blog posts with their opinions, as well as Ed Faulkner of the Ember community. Last but not least, in response to my last blog post, Google changed Angular 2's license from Apache to MIT for better compatibility with Drupal. I read all the posts and comments with great interest and wanted to thank everyone for all the feedback; the open discussion around this is nothing short of amazing. This is exactly what I hoped for: community members from around the world brainstorming about the proposal based on their experience, because only with the combined constructive criticism will we arrive at the best solution possible.
Improving Drupal's user experience is a topic near and dear to my heart. Drupal's user experience challenges led to my invitation to Mark Boulton to redesign Drupal 7, the creation of the Spark initiative to improve the authoring experience for Drupal 8, and continued support for usability-related initiatives. In fact, the impetus behind progressive decoupling and adopting a client-side framework is the need to improve Drupal's user experience.
To date, much of our UX improvements have been based on an iterative process, meaning it converges on a more refined end state by removing problems in the current state. However, we also require disruptive thinking, which is about introducing entirely new ideas, for true innovation to happen. It's essentially removing all constraints and imagining what an ideal result would look like.
I think we need to recognize that while some of the documented usability problems coming out of the Drupal 8 usability study can be addressed by making incremental changes to Drupal's user experience (e.g. our terminology), other well-known usability problems most likely require a more disruptive approach (e.g. our complex mental model). I also believe that we must acknowledge that disruptive improvements are possibly more impactful in keeping Drupal relevant and widening Drupal's adoption.
At this point, to get ahead and lead, I believe we have to do both. We have to iterate and disrupt.
Let's forget about Drupal for a second and observe the world around us. Think of all the web applications you use on a regular basis, and consider the interaction patterns you find in them. In popular applications like Slack, the user can perform any number of operations to edit preferences (such as color scheme) and modify content (such as in-place editing) without incurring a single full page refresh. Many elements of the page can be changed without the user's flow being interrupted. Another example is Trello, in which users can create new lists on the fly and then add cards to them without ever having to wait for a server response.
Contrast this with Drupal's approach, where any complex operation requires the user to have detailed prior knowledge about the system. In our current mental model, everything begins in the administration layer at the most granular level and requires an unmapped process of bottom-up assembly. A user has to make a content type, add fields, create some content, configure a view mode, build a view, and possibly make the view the front page. If each individual step is already this involved, consider how much more difficult it becomes to traverse them in the right order to finally see an end result. While very powerful, the problem is that Drupal's current model is "inside-out". This is why it would be disruptive to move Drupal towards an "outside-in" mental model. In this model, I should be able to start entering content, click anything on the page, seamlessly edit any aspect of its configuration in-place, and see the change take effect immediately.
Drupal 8's in-place editing feature is actually a good start at this; it enables the user to edit what they see without an interrupted workflow, with faster previews and without needing to find what thing it is before they can start editing.
Eight years ago in 2007, I wrote about a database product called DabbleDB. I shared my belief that it was important to move CCK and Views into Drupal's core and learn from DabbleDB's integrated approach. DabbleDB was acquired by Twitter in 2010 but you can still find an eight-year-old demo video on YouTube. While the focus of DabbleDB is different, and the UX is obsolete, there is still a lot we can learn from it today: (1) it shows a more integrated experience between content creation, content modeling, and creating views of content, (2) it takes more of an outside-in approach, (3) it uses a lot less intimidating terminology while offering very powerful capabilities, and (4) it uses a lot of in-place editing. At a minimum, DabbleDB could give us some inspiration for what a better, integrated content modeling experience could look like, with the caveat that the UX should be as effortless as possible to match modern standards.
This sort of vision was not possible in 2007 when CCK was a contributed module for Drupal 6. It still wasn't possible in Drupal 7 when Views existed as a separate contributed module. But now that both CCK and Views are in Drupal 8 core, we can finally start to think about how we can more deeply integrate the two. This kind of integration would be nontrivial but could dramatically simplify Drupal's UX. This should be really exciting because so many people are attracted to Drupal exactly because of features like CCK and Views. Taking an integrated approach like DabbleDB, paired with a seamless and easy-to-use experience like Slack, Trello and Backand, is exactly the kind of disruptive thinking we should do.
We shouldn't limit ourselves to this one example, as there are a multitude of Drupal interfaces that could all benefit from both big and small changes. We all want to improve Drupal's user experience — and we have to. To do so, we have to constantly iterate and disrupt. I hope we can all collaborate on figuring out what that looks like.
A major focus of usability efforts in Drupal core has been around making it easier to edit things on your site. In Drupal 7, we introduced the Contextual links and Overlay modules to make it simpler for content authors and site builders to jump directly to the parts of the administration that relate to the things they see directly on the page, such as blocks or menus. Drupal 8 has now upped the ante with the new in-place editing feature, which allows for direct modification of content on your site, within the context of the page it is displayed on.
The next logical step is to take in-place editing to the next level by unifying contextual editing paradigms: combining the concept of "edit mode" with the ability to contextually edit more than just fields on content, in order to allow for contextual editing of everything on the page, in a mobile-first way.
Specifically, we need to address the following challenges:
Here is a video showing what we'd like to propose for solving these problems in Drupal 8 core:
We've now performed several rounds of internal usability testing on this functionality, and it has tested really well so far, with a high emotional value: in general, people can't believe this is Drupal. :-) Check out the prototype yourself at https://projects.invisionapp.com/share/U2A4IAGX.
I'm very excited about these changes, and feel that if we can get this into Drupal 8 it could be game-changing. But what do you think? If you like it, we'd love help with implementation and reviews in the core issue at http://drupal.org/node/1882482.
The goal of the Spark distribution is to incubate authoring experience improvements in a Drupal 7 and Drupal 8. It was announced earlier this month, and since then we've been hard at work on initial research and design.
The Spark team's primary focus is on improving Drupal's content authoring and editing experience, and the first feature we're prioritizing is in-place editing: the ability to edit content, menus, etc. directly on the page, without the need to navigate to a separate edit form. Think of it as "true" WYSIWYG.
Members of Acquia's design team spent time analyzing how some of the most widely adopted Open Source as well as proprietary CMSs do in-place editing. We then prototyped some initial ideas, and performed usability testing on those prototypes to see what works and what doesn't. After a number of iterations, we're happy to report that the usability testing has validated Spark's general design direction. People loved the prototype. Now is a good time for us to share our initial prototype and to solicit further feedback from the community so we can shift gears into implementation.
The following 5-minute video walks through the HTML/JS prototype, and also provides a bit of background on the Spark project:
Our goal is to deliver this functionality in a contributed module for Drupal 7 first and foremost, which will live at the In-Place Editing project on drupal.org. This module will be bundled into the Spark distribution. Depending on how it is received, I hope we can also target this functionality for Drupal 8 core.
From a technical architecture standpoint, we are currently in the process of selecting the WYSIWYG editor to use in Spark for in-place editing of HTML content. For now, we plan to focus on supporting only the Filtered/Full HTML text formats in order to get us to something testable faster.
Later, we are hoping to branch out into other areas of authoring experience too, including helping with the content creation form improvements that the Drupal usability team has been spear-heading, as are well as the layouts UI work being actively discussed in the usability group. The Drupal usability team is doing an incredible job with these issues, and once fully staffed, I would like to see the Spark team help implement these improvements for Drupal 8 and backport them to Drupal 7 so we can ship it with the Spark distribution. (Did I mention that the Spark team is hiring? ;-))
As you can see, things are starting to move along quite nicely. Please join the discussion in the Spark issue queue if this functionality sounds exciting to you and you'd like to help!
At DrupalCon Denver, I announced the need for a strong focus on Drupal's authoring experience in my State of Drupal presentation. During my core conversation later in the week, I announced the creation of a Drupal 7 distribution named "Spark" (formerly code-named "Phoenix"). The goal of Spark is to act as an incubator for Drupal 8 authoring experience improvements that can be tested in the field.
I hope for Spark to provide a "safe space" to prototype cutting-edge interface design and to build excellent content tools that are comparable with the experience of proprietary alternatives. While not a final list, some initial thinking around the features we want to experiment with is:
The vision behind the Spark distribution is to be "the Pressflow of Drupal authoring experience". Pressflow provided a "spoon" of Drupal 6 with various performance enhancements that made their way into Drupal 7 core while it was in development. The same improvements were made available to Drupal 6 users so they could easily be tested in the field. With Spark, we want to test authoring experience improvements in Drupal 7 on real sites with real users and real content. We also want to target the best improvements for inclusion into Drupal 8 core.
I'm excited to announce that Acquia will fund the Spark distribution. Core developers Gábor Hojtsy and Wim Leers will work on Spark full-time starting in late May. They will work along side Angie Byron (webhchick), Alex Bronstein (effulgentsia), myself and other members at Acquia. While we have some promising candidates so far, Acquia is still seeking two applicants to join the Spark team (with a strong preference to candidates located in or willing to move to the Boston area):
The Spark team will collaborate with the Drupal usability and the core development teams.
On Friday, there is a Drupal meetup happening in Utrecht, The Netherlands. I'm planning to attend so looking forward to meet some of you there.
On Saturday and Sunday, a smaller group of core developers will meet in the offices of One Shoe in downtown Utrecht to work on the ongoing Drupal 7 usability efforts. According to the event page on groups.drupal.org, confirmed attendees for the sprint include Leisa Reichelt, Mark Boulton, Gábor Hojtsy (goba), Damien Tournoud (DamZ), Erik Stielstra (sutharsan), Bojhan Somers (bojhan), Roy Scholten (yoroy), Bart Feenstra (Xano), Gaele Strootman (gaele), Kristjan Jansen (kika), Thomas Moseler (eigentor), Konstantin Kaefer (kkaefer), Philip Vergunst (skilip), Willem Mol (Whatdoesitwant), Berend de Boer (berend), Maarten Verbaarschot (mverbaar), Johannes Haseitl (derhasi), Steve De Jonghe (seutje), Clemens Tolboom (clemens.tolboom), Thijs Zoon, and Floris Derksen. I plan to stop by on Sunday as well.
Though the open sign-up for the code sprint on Saturday and Sunday has already closed due to the number of attendees already confirmed, contact Thomas Moseler (eigentor) if you want to attend and he may be able to squeeze you in. He's also actively looking for sponsors to help some European core developers to attend the Utrecht activities; if you can help, please send him an e-mail. Thanks!
Improving the usability of Drupal is very important. Yesterday, I wrote about the progress that was made on Drupal 7 usability -- the community has made a ton of incremental improvements, while Mark and Leisa have been preparing mockups and wireframes that provide significant over-arching improvements to Drupal's ease of use. Combined, I believe these efforts could make Drupal 7 a great release. A release that the Drupal project needs since our competitors are catching up in terms of functionality and flexibility. Likewise we need to catch up in terms of design and usability. It is my belief that we can develop a user experience for our project that is game changing, and that completely resets people's expectations both for Drupal and our competitors.
As I wrote in yesterday's status update, an objective without a strategy remains a dream. We added a strategy by inviting Mark and Leisa to help but unfortunately, a strategy without execution remains a dream too. In other words, the time has come to start translating some of Mark and Leisa's work into working code. With 3 months until the Drupal 7 code freeze, it is time to build working prototypes so we can do user testing, refine the user experience, figure out the remaining design questions, and ultimately, get everything right for inclusion in Drupal 7.
Needless to say, this is a non-trivial amount of work that requires a highly collaborative process in what seems like a very limited time. It's easy to throw up our hands and say that it's impossible, that we should wait for Drupal 8, or whatnot. However, maintaining the status quo is simply not an option. Drupal 8 won't be used in production for, probably, at least another two years. As I wrote before, I don't want to compromise on Drupal 7's usability.
Few projects win by maintaining the status quo. Projects that win are those that go ahead and always improve. It is OK to be afraid about the work that is ahead. If you're not scared, you're not doing the right thing. Both winners and losers have fear, but all winners have faith. We can do this -- we've done it before.
We have to acknowledge that we arrived at a special point. The time has come to start working together even more but as a community, we're still learning how we can best work together on usability and design issues. Retrofitting a usability process into what has traditionally been an engineering process comes with some challenges and frustrations. Based on the progress that we have made recently, I'm confident that we'll figure this out, and that the process will feel completely natural in the long term.
Here is how I think about it in the short term, and how you can help.
Mark and Leisa will be helping us until the end of July to refine the current mockups based on more user testing, feedback from the community, and additional research -- they'll also be available to help answer questions and to help all of us sort through any implementation details. Their current mockups are a great starting point -- they'll force us to collaborate more and to streamline the process. The more mockups we can implement and the sooner we can implement them, the more testing Mark and Leisa can do, the more problems we'll discover, and the easier it becomes to refine things.
If you are a Drupal developer, look for issues tagged 'd7ux'. We're also using a tag called 'd7ux-design-question' to track non-engineering questions for Mark, Leisa and the usability team -- this should make it easier for everyone to stay on top of the progress. For people new to Drupal, Leisa and other people in the Drupal usability team launched a micro-projects initiative.
At this point, I've no plans to postpone the code freeze date. We started working on Drupal 7 in February 2008, so it has been a long release cycle already -- as it stands, Drupal 7 probably won't be released before January 2010. Instead of pushing back the code freeze date, I'd like to invite all of you to help with the implementation of the mockups that Mark and Leisa are providing. If you are a company, you can help by contributing some dedicated resources to help. If you're contributing as an individual, we appreciate every hour or day that you can put into this project. If you are a module maintainer, now would be a good time to figure out what this means for your module and how it could fit in. Get involved now, and help make Drupal 7 a game changing release!
To help, Acquia will start contributing a significant amount of its engineering resources. Starting this week, we'll contribute two or three people full-time until the end of the summer! Probably a combination of Gábor Hojtsy, David Rothstein, and Paul Lovvik. Jeff Noyes and Jason Reed will assist with user testing and design. Also, after talking to Mark Boulton, he has agreed to contribute one week a month of Tim Millwood's time (a Drupal developer that they have on staff) from now on to code freeze.
I hope others will step up to dedicate some of their time and resources as well -- when you do, make sure to announce it in the comments and on your blogs. Together, we should be able to make a lot of progress. The more people from the Drupal community that can jump in to help, the better Drupal 7 will be for us all. Now is the right time to bring vision, strategy, and execution together to achieve our objective. Fear not, Drupal 7 will be a game changing release.
Based on a survey that I conducted last year, it was clear that one of the community's key goals is making Drupal easier to use. This is not really all that surprising. An easier to use Drupal means a Drupal that attracts more users, and therefore more potential contributors. It also means existing contributors spend less time doing custom work on their sites or developing training materials to help make Drupal palatable to their clients, and more time on making Drupal rock. And finally, it is strategically important for the future of the Drupal project to make our usability match the prowess of our flexible APIs; our competitors are working to build out their feature set to match Drupal's, and if we do not work to make Drupal's usability radically better, we risk falling victim to The Ockham's Razor Principle of Content Management Systems.
In this post, I want to give an update on the Drupal 7 usability work that has been done to date.
The good news is that thanks to the hard work of many people in the community, a lot of great Drupal usability improvements have already gone into Drupal 7. For example, we improved support for WYSIWYG editors, added more drag-and-drop, improved administration of permissions, added a default install profile which starts to configure some sensible defaults for Drupal as a publishing system, improved the password strength validator, redesigned and simplified various configuration pages, implemented "vertical tabs" on content creation and editing forms (see screenshot below), removed extraneous interface text, and much more.
The more important trend, however, is that after years of tireless evangelizing, the Drupal community is starting to value usability increasingly more. Today, the usability team is more involved in the patch review process than ever before -- for example, Bojhan, a usability expert active in Drupal's usability team, has even learned how to create patches so that he can help make simple changes. Another good example, is that in the Drupal 7 development cycle, we have raised money to do formal usability testing. These efforts illustrate a fundamental underlying desire to get better at usability, so I expect to see even more great things in the months to come.
All this is great work that helps address some of Drupal's fundamental problems; however, a lot of these improvements are incremental -- making incremental improvements is what the Drupal community excels at. Making the drastic over-arching improvements to Drupal's ease of use that we really need for Drupal to grow its audience requires one to step back, take a fresh look at the big picture, interview people, analyze problems, and propose more radical changes that incorporate piles of feedback and ideas. Needless to say, this is a long and expensive process, and not something we'd be able to get to using incremental changes. An objective without strategy remains a dream so as I announced in February 2009, I thought it would be right for Acquia to finance Mark Boulton and Leisa Reichelt to help the Drupal community with exactly this.
For about 3 months now, Mark and Leisa have been working with the Drupal usability group and the larger Drupal community to figure out how we can improve the usability of Drupal 7. I figured an update was in order.
Mark and Leisa's work is being done in an open, collaborative, and transparent way, involving everyone in the Drupal community. The work is happening in a number of locations, and the best place to keep track of it all is at D7UX.org. Mark and Leisa also often hang out with the usability team on
#drupal-usability on irc.freenode.net, and even have been known to venture into
Some of the activities to date have included some 'blue sky design workshops' with community members at DrupalCon DC, one on one interviews a range of members of the the Drupal community and many potential future Drupal users, asking you to share the Drupal administration modifications you're already made and others you'd like to see made. As the work has progressed they have shared work in progress on Flickr, shared ideas, process and prototypes in videos on YouTube, conducted user testing on those prototypes (and reviewed some of your findings through crowdsourced usability testing), and much more.
In addition to paying Mark and Leisa, Acquia has contributed some of its own internal engineering resources. Jeff Noyes, Jason Reed (both senior designers) and myself traveled to meet with Mark and Leisa in London -- we flew in Yoroy, a key contributor to Drupal usability, to attend as well. We locked ourselves in a room for two days, and discussed and validated early design prototypes. You can read a summary of the visit on Jeff Noyes's site. Returning home from London, I couldn't be happier, because the designs and prototypes started to live up my vision and expectations of how easy to use Drupal could be.
Since then, Mark and Leisa have revised many of their prototypes based on the feedback that was provided, and continues to be provided by the larger Drupal community. The latest versions are available from D7UX.org. They aren't finished yet, but Mark and Leisa will be helping us until the end of July. Expect more mockups, working prototypes and lots of user testing and iterations. Eventually, we should also have some style guides. If you're interested in participating (and the more people who participate, the better Drupal 7 will be), you can view a list of current activities as well as well as the project framework, where the current thinking around 14 separate topics is being centrally collected and discussed.
However, beautiful usability improvements are no good to anyone unless they have code behind them. In my next blog post, I'll write about the next steps, and how we can all help translate these mockups into working code.
Updates from Dries straight to your mailbox