You are here

Turning Drupal outside-in

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.

Based on the discussion, rather than selecting a client-side JavaScript framework for progressive decoupling right now, I believe the overarching question the community wants to answer first is: How do we keep Drupal relevant and widen Drupal's adoption by improving the user experience (UX)?

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.

It took me a bit longer than planned, but I wanted to take the time to address some of the concerns and share more of my thoughts about improving Drupal's UX (and JavaScript frameworks).

To iterate or to disrupt?

In his post, Lewis writes that the issues facing Drupal's UX "go far deeper than code" and that many of the biggest problems found during the Drupal 8 usability study last year are not resolved with a JavaScript framework. This is true; the results of the Drupal 8 usability study show that Drupal can confuse users with its complex mental models and terminology, but it also shows how modern features like real-time previews and in-page block insertion are increasingly assumed to be available.

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.

From inside-out to outside-in

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.

Making it real with content modeling

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.

Other new data modeling approaches with compelling user experiences have recently entered the landscape. These include back end-as-a-service (BEaaS) solutions such as Backand, which provides a visually clean drag-and-drop interface for data modeling and helpful features for JavaScript application developers. Our use cases are not quite the same, but Drupal would benefit immensely from a holistic experience for content modeling and content views that incorporates both the rich feature set of DabbleDB and the intuitive UX of Backand.

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.

What most of the examples above have in common are in-place editing, immediate previews, no page refreshes, and non-blocking workflows. The implications on our form and render systems of providing configuration changes directly on the rendered page are significant. To achieve this requires us to have robust state management and rendering on the client side as well as the server side. In my vision, Twig will provide structure for the overall page and non-interactive portions, but more JavaScript will more than likely be necessary for certain parts of the page in order to achieve the UX that all users of the web have come to expect.

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.

Special thanks to Preston So and Kevin O'Leary for contributions to this blog post and to Wim Leers for feedback.

Spark update: unified in-place editing

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:

  • Conflicting patterns confuse users: There are contextual gears to edit content, local tabs to edit content, and "Edit mode" to edit content. These patterns need to be streamlined.
  • Tasks are not intuitive enough: Seemingly simple tasks can often result in "pogo-sticking" around in the admin backend trying to locate where to change a given setting.
  • Unnecessary information slows users down: Drupal forms tend to be long and full of advanced/confusing options, which can overwhelm users trying to complete simple tasks.
  • Interactions don't work with smaller devices: With Drupal 8's Mobile Initiative, it is critical that these tools be as easy to use on the desktop as they are on a smartphone or tablet.

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.

Spark update: in-line editing in Drupal

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!

Announcing Spark: authoring improvements for Drupal 7 and Drupal 8

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:

  • Inline editing and drag-and-drop content layout tools ("true" WYSIWYG)
  • Enhanced content creation: auto-save, save as draft and more
  • Useful dashboards for content creators
  • Mobile content authoring and administration support

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 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.

Drupal 7 usability code sprint in The Netherlands

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!

Pages

Updates from Dries straight to your mailbox