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

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


mherchel (not verified):

I had a high emotional response from this. Specifically, it was, "Holy Crap! That's Awesome!" :)

Great work Kevin, and everyone else at Acquia who is making this possible!

Will this make it into the D7 version of Spark? I don't want to have to wait.

Kevin Oleary (not verified):

Thanks mherchel,

That's great to hear. Nod is currently working on the backport.


nod_ (not verified):

For now we're only backporting WYSIWYG inline editing, not the cool and coherent block configuration thing unfortunately. That's the current agenda for this month at least.

Andrew Millar (not verified):

Looking really good. Although I'm surprised you've gone for an up/down arrow to move blocks rather than a drag and drop. Is there a reason for that?

redndahead (not verified):

I'll also add that while I like the up down as it's sometimes easier than dragging, the problem with that is the block may need to be moved to a different region and being able to drag affords you that interaction.

Chris Herring (not verified):

I'm guessing to ensure compatibility with touch devices.

Dave.Ingram (not verified):

Love it!

@Andrew. Drag and Drop interactions are not necessarily appropriate for touch devices.. though I don't see any reason why drag and drop shouldn't be an option as well as the arrows.

Kevin Oleary (not verified):


Thanks, I agree we should definitely look at drag drop as an enhancement down the road.


Teody C. Seguin (not verified):

This is cool! The editing process would be much more easier now.

Jeremy Stoller (not verified):

This looks very enticing, but it also makes me very concerned about how it will integrate with publication workflows. I would like to see Drupal move toward more use of workflows and get away from always editing live content. In-place editing seems to make this more challenging, though perhaps not insurmountable. I hope this is being kept in mind.

Kevin Oleary (not verified):

Hi Jeremy,

Yes, we are very concerned about workflow and are actively designing and testing how we can ensure that edit scales smoothly to a multi-stage process. You are quite right that a managed content workflow is the way that most organizations of more than just a few people will want to operate. It's also true that it's a complicated engineering problem. If you have more in-depth questions on this there's been some discussion going on in the edit issue on d.o.

Shawn holt (not verified):

I've been working with Drupal for several years now I am delighted to see the community focusing on real problems that are inhibiting adoption by non-programmers.

Kevin Oleary (not verified):

Thanks Tom,

Maybe some talented tech writer will write an article on it. ;)

Kevin Oleary (not verified):

Hi Pari,

We are working hard on that too. With the new CK editor things some of the image issues will be resolved. Keep an eye on that.

Chris Herring (not verified):

Very exciting, Dries and Kevin! I'm a big fan and supporter of this initiative -- only wish there was an easy way we could help that wouldn't detract from our team's current priorities... :(

moshe weitzman (not verified):

If one goes to the Content Listing and clicks the Edit operation, where do we send them? I think it has to be the full node form, since there is stuff on there that will never be editable in place (e.g. URL alias). Perhaps the Edit local task can go away though.

Kevin Oleary (not verified):

@Moshe Weitzman Yes, I think that's right.

Dave.Ingram (not verified):

Good point. There absolutely must still be access to the edit form. It would also be nice if there's still a link to the edit screen somewhere when viewing the node. Perhaps the local tasks can get wrapped into the toolbar somewhere? There are other local tasks we would want to preserve as well such as the task devel provides, or the workflow module, etc.. those need to still live somewhere in the UI.

Gábor Hojtsy (not verified):

The contextual links (which are on this prototype displayed as fly-out menus when clicking on some of the pencils) are extensible the same way tabs were, so the idea is the primary content will not be privileged to have these displayed as tabs, it would have the same opportunity to have them in its contextual menu, like any other object on the page (which could also have their devel tasks for example).

Kevin Oleary (not verified):

True. They need to have a logical place to live. I'm wary of putting them in toolbar though because (at least at this point) workflow passes changes to the node, not the page (page = node + layout + block position and visibility). So I think that those should be in the contextual link to the right of the node title.

Dane (not verified):

This is so cool! I said that at least twice watching the video. Can't wait for Drupal 8. By the way, what's the cool sidebar menu that's going on, is that part of Drupal 8 core or something special you have going on for that site?

Kevin Oleary (not verified):

Thanks Dane,

The menu "tray" you see is in Drupal 8 core toolbar, you can toggle between a horizontal top tray and the left side tray you see in the video (right side for RTL languages)

ccf (not verified):

Its weird, that Drupal is finally understanding, what has been obvious from day one. Drupal might be very powerful, but if takes literally years to learn to do basic things - its USELESS.

If learning HTML+PHP+CSS+javascript and doing a big site from scratch is easier than learning Drupals "User Interface" and "Logic", then its a big miracle, taht Drupal is still alive.

Kevin Oleary (not verified):

I don't think "Drupal" as you say, or the Drupal community is "finally understanding" the importance of usability. I think we have always known it. What we are finally understanding is how to do it. And how to do it without "dumbing down" the tool for advanced users. With effortless usability for content authors and limitless extensibility for developers, Drupal will not die, it will dominate.

tk (not verified):

Thats great! I would love to have it in drupal8!!!!!!!!

Guy Saban (not verified):

It could be that unnecessary information is slowing down users - I am guessing this has been measured in usability testing. But what about users that may have questions regarding a particular (inline) form or field. If a user did have a question or some ambiguity regarding the form/field they are trying to use it would be helpful to provide them with an inline toggle button to show extra helpful (and necessary) information regarding the information needed to complete the form/field correctly.

I like new approach to usability and inline editing - well done. Definitely an improvement for simple content editing.

Michael Tucker (not verified):

You might consider adding a close icon to the block editing boxes to keep the pattern the same.

In your example, to edit the entire page, you toggled editing on/off with a pencil icon with and without a bisecting line.

Keeping the pattern, to edit a block, a user sees the pencil and knows that toggles on editing. But, what if I clicked the wrong block by mistake and want to escape? It's not clear how to escape, so use the pencil/bisected icon to let me know I can click that to close editing function for that box.

All in all, good steps forward in general usability. Thanks guys

Wim Leers (not verified):

One would be able to escape by simply clicking outside of the popup/popover/modal/overlay (so many synonyms!), i.e. on any part of the underlying page that is still visible. You'd be surprised how many people expect that it works that way already.

However, on mobile, some kind of close icon would indeed be necessary.