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.

What is outside-in?

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.

Example #1: editing menu items

The current inside-out experience

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.

Outside in menu before
The current inside-out experience for editing a menu item: adding a menu link and changing its position involves 2 separate administration pages, 4 page refreshes and more than 400 words of text on the UI.

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:

  1. Find the contextual link for the menu (not simple since it's on the far side of the page)
  2. Choose the correct option "edit menu"
  3. Find and click the "add link" button
  4. Type the menu link name
  5. Type the menu link path beginning with a forward slash
  6. Understand that this change needs to be saved
  7. Scroll to the bottom of the page
  8. Save the link
  9. Find the link in the list of links
  10. Understand that dragging up/down in this abstraction is equivalent to moving right/left in that actual page
  11. Scroll to the bottom of the page
  12. Save the menu

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.

The proposed outside-in experience

Outside in menu after
The proposed outside-in experience for editing a menu item. Rather than moving out-of-context to an administration page to get the job done, configuration happens right on the page where you see the effect of each action. You start adding a menu item simply by selecting the menu on the page. Both the menu item and the item's path are in focus to reinforce the connection. As you type a path is proposed from the link text.

Now all you need to do is:

  1. Click the menu on the page
  2. Find and click the "add link" button
  3. Type the name of the menu item
  4. Revise the menu item's path if needed
  5. Drag the link to its new location
  6. Close the drawer

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.

Example #2: adding a block to a page

The current inside-out experience

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.

Outside in blocks before
The current inside-out experience for adding a block. Not all steps are shown.

To complete this task you need to:

  1. Figure out where to go to place a block
  2. Go to /block-layout
  3. Go to /display-regions to find out where the region is on the page
  4. Go back to /block-layout
  5. Find the region and click "add block"
  6. Find the block you want to place and click "place block"
  7. Configure the block
  8. Read about how blocks can appear on multiple pages and for different content types and roles
  9. Read what content types are
  10. Read what roles are
  11. Read what a "path" is
  12. Read how to find the path for a page
  13. Go back to the page and get its path
  14. Go back to /block-layout and add the path to the visibility settings
  15. Drag your block to the position where you want it
  16. If your blocks are arranged horizontally, learn that "up and down" in the block layout UI will mean "left and right" on the actual page
  17. Find the"back to site" link
  18. Go back to the page to see if you did it right

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.

The proposed outside-in experience

Outside in blocks after
The proposed outside-in experience for adding a block. Everything happens on the actual page rather than on an administration page. Places where things can be added appear on hover. On click they show thumbnails that you can filter with autocomplete.

Now all you need to do is:

  1. Choose where to place the block
  2. Find the block you want to place
  3. Place the block
  4. Close the drawer

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.

Principles and patterns

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:

  • An option panel is triggered by direct interaction.
  • When triggered it only shows options for what you selected.
  • It primarily shows configuration options that produce a visible change to the page. More complex options could be accessed through an 'Advanced options' link.

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!

Special thanks to Kevin OLeary for advocating outside-in thinking. Thanks to Preston So, Gábor Hojtsy, Angie Byron, Bojhan Somers and Roy Scholten for their feedback.


W.M. (not verified):

Good evening Dries, thanks for all the efforts. I have been a Drupal user / developer for 7 years now and the progress you have made is incredible. I care about Drupal and despite some concerns regarding the new release, I still think Drupal is one of the most exciting projects I know about. One thing that I ask you to work on, I recall some years ago when I was posting questions on, people where fast to reply and people cared about code. Today to be honest I feel things changed, many questions are asked and no one is there. Maybe world dynamics itself changed, so it does not need to be a Drupal issue :-) Maybe you should give this some attention and see how to improve things. Thanks very much.

Ryan Szrama (not verified):

You should check out the Drupal user / support community at Drupal Answers ( I believe it's easier for Drupal users who want to support others to offer support through this forum as questions often transcend single modules (avoiding the issue queue silo problem) and are both discoverable and have previous questions aggressively recommended to folks asking questions when the system detects they're asking questions similar to previously answered questions.

Mike Herchel (not verified):

Yeah, the forums are embarrassing. It makes the community look stagnant and ill informed to newbies.

Paul Driver (not verified):

Stack Exchange is useful, but it is tarnished those who insist that questions or answers should be black or white and especially by those regular contributors who are quick to put down new-comers with vague questions or those who dare to offer an opinion as an answer. I use both services and tend to find issue queues to be more helpful and less antagonistic, but it is true that sometimes one has to be patient for an answer. That said, (tongue in cheek) this post is about front facing site-builder and editor workflow and I agree 100% with Dries that such ideas deserve everybody's full attention. Just ask a young child how Drupal should work.

Larry Garfield (not verified):

Depending on where you're posting, the audience may have just shifted. The forums are largely unmaintained these days. StackExchange/StackOverflow and similar simply provide a better experience so have more people paying attention.

Ryan Szrama (not verified):

Having done some small projects for friends, family, and clients in both Squarespace and WordPress, probably the *only* nice thing I took away from the experience was this build pattern. Squarespace is much more robust than WordPress (though a bit more fiddly when it comes to spacers), but WordPress helpfully adopts this pattern for widget placement / configuration and theme customization, even going so far as to update the main content frame even as you toggle widget settings in the sidebar.

(Squarespace was mostly frustrating for its habit of recreating HTML IDs I might otherwise target via custom CSS every time I updated an element; their type manipulation settings were disappointingly restricted, but I had a hard time finding dependable selectors to tweak certain headings / layouts via custom CSS.)

I think the reason users end up with such loyalty to these products is that they more or less require you to customize everything to get started, but they do it through this sort of Literal UI that the casual user can understand. By the time they take the site live, even though it's a template used on a thousand other sites, it still feels like your own.

Larry Garfield (not verified):

Dries, there's two very very very very very very important challenges that make such a "literal UI" a challenge:

1) Markup. The sort of HTML and CSS needed to support such dynamic interaction is not easy to write. When your output is a complex mix of auto-generated stuff from the backend, hand-crafted stuff from site-specific templates, and generic stuff from generic templates (and those latter two often overlap), getting that to work is quite difficult, and can severely curtail the control that front-end devs have over their markup. Drupal 8 struggled with that a lot; RDFa attributes, the QuickEdit markup, JavaScript hook classes, etc. There's a LOT to consider here, all of it making life more difficult for people who just want to write HTML.

2) Context. The mockups above offer almost no concept of context. The real value of Drupal comes from the ability to vary logic based on a zillion inputs; active user, organic group, domain, segment of the menu, the node being viewed, the organic group membership of the user that owns the node being viewed... This is the part that my clients struggle with. They can handle editing the menu. They can't wrap their head around leveraging context well, especially non-global context.

Solving the context problem is the tricky part. "Put a bunch of global-context blocks on the page", meh, lovely. OK, but should that block now appear in the context of the current node only? What if the page is not a node? Should it be on all pages in that location? Just on nodes of the same type as the current node? Is its content going to vary depending on the node it's on? If the data from the node that it needs isn't available, what should it do?

That's the hard part. That's always been the hard part. Dragging and dropping context-free stuff into a single page has been around for 20 years. Wasting time on doing that all over again is just that: Wasting time. Making a prettier, fewer-step version of the current block admin is solving the wrong problem.

Context is hard. That's why the Views/Panels realm (which has been at the forefront of addressing context for years now) has always taken a "context first, then content" approach: It's much easier to wrap your brain around once you get over the hump of understanding "oh yeah, context matters". Trying to build a UI that hides the need to care about context is not only likely impossible, but doing both Drupal and its users a gross disservice.

Generally speaking, once I've explained to my clients how Views/Panels context works (and apologized for a UI that doesn't follow even one of Drupal core's conventions or terminology patterns), they love it. It's just getting people over that initial hump that is the challenge, yet time and again the push I see is to try and pretend the hump isn't there. That's a losing, self-defeating battle.

Now, could we build an "outside-in" UI that handles context? I don't know. I've not seen a good one yet. I'd love to see one. I would love to see us put effort into addressing that problem space. Solving that would be a major coup for Drupal, and much better than a context-then-content UI could ever be. Let's put our effort there.

Making a better drag-and-drop for context-free one-off individual pages? Only if we want to ignore all the things that make Drupal worth using over Squarespace. I don't know why you'd want to do that, though.


I agree that context is both important and difficult. I'm confident that we can bring context into the outside-in principle and deliver a user experience that is better than today's. Kevin has been experimenting with context but would love to see others chime in with design prototypes as well. As mentioned in the last paragraph of blog post, I plan to dedicate an entire blog post to this.

Kevin Oleary (not verified):

Hi Larry,

As Dries said, context is not being hand-waved away, but it's such a big thing in itself that he felt it would muddy the waters if we introduced that along with this intro to outside-in/literal UI. It will be coming very soon and I think you'll like it. One minor point, the mocks here do not assume global context, they assume single page context, the harder global and somewhere-in-between-global-and-single-page contexts are what's coming.

On the markup question, you are correct that this is a hard problem but already this post is generating some excitement in the front-and and twig world. Undoubtedly the answer lies somewhere between web components and js frameworks, which is why those discussions are so important.

catch (not verified):

"One minor point, the mocks here do not assume global context, they assume single page context"

For me that's the issue though and why I bothered to type up my comment below (moderation on your blog means when I typed it I hadn't seen any of the other comments here). The number of times I've had to add a block to show on a single, individual, page in Drupal is probably about 0.05% of the total - boils down to 'adding blocks on the front page when not using panels'. So it's an assumption that handles the least common case, regardless of overall site complexity too.

Also there is no single-page context for adding, editing or re-ordering menu items. While most people looking at this blog post know that, it's not necessarily clear to a new Drupal user:

- some menu items only show in certain contexts, depending on whether the parent is set expanded or not and which page you're on,and whether or not you have access. This might be a single page, it might be a subset of pages.
- some menu blocks only show certain levels of the menu - i.e. the old primary/secondary menu behaviour, or via block configuration in 8.x now which allows you to select which level to display, and how many levels.

So even the menu example runs into context very quickly once you get into it.

I don't see how that could muddy the waters here, it's fundamental to any kind of interaction on this level. We already have a major bug report, opened by Kevin, pointing out that the page title contextual links are confusing for similar reasons:

Shannon (not verified):

I see what you & Larry are saying. It's impossible to discuss a UI improvement for adding "stuff" without addressing one of Drupal's main advantages: Saying when stuff should show up, for whom & where.

That said, I think Dries & Kevin are trying to say: Here's how complex it is to do this today, here's how simple it needs to be for users to understand.

^ that message is an important one, and I am in agreement with it. It's too hard today. Too complicated. As Dries says, you need to understand how everything works in order to add one thing to your page. You need to first grasp that Drupal has the possibility of displaying your "stuff" to people differently depending on what they're doing on that site.

I'm looking forward to seeing what Kevin is thinking wrt context. Personally, I'd like to see this as a 2-step approach.
First: Click your + button to add something, define it in the drawer refresh page.
Second: Notification that this change is saved only for that page, ask if the context should be extended with advanced options to control access or make it a global change.

That is what I would expect as a content admin.

Roy (not verified):

Five years ago Bojhan and I layed out our thinking and questions about the conceptual underpinnings needed for a context-savvy UI approach: Only 120 comments to read through there :)

For me, concrete and specific examples are helpful in working through these kinds of ui challenges. These initial examples are just that, initial examples and even if they are maybe a bit forced because they leave context out, the goal is to get people thinking about what it means to turn Drupal outside in and what kind of ui approaches might come from it.

I think we "insiders" all know that context is the real problem to solve for this outside-in approach to work with Drupal underlying power and flexibility. Examples of where contexts come into play would be good to have as well.

Solving specific instances first allows for experimenting with different approaches. We really need to allow ourselves to come up with multiple (silly, incomplete, far-fetched) ideas before synthesizing those into a generalized more framework-y approach.

Shannon (not verified):

+1! Like the idea of coming up with examples a lot, and since Drupal has so many situations this well help us discover if we need more than one "route" to context definition.

Bill Winett (not verified):

Check out this Sitecore video on personalizing content. And while watching, add the word "contexualization" any time the author says "personalization". I can imagine rules being available for limiting block/menu display to specified content types, domains, languages, etc.

Josef (not verified):

Great to see such elaborate progress on improving the ux for Drupal.

Once main concern I have here, similarly to the quick edit functionality, is that you only see what you get and you don't see what is. What I mean is that the visual representation I the front-end is just one possible representation depending on the current view mode (teaser, full view, ...), screen width or even output format.

I'm all for lowering the barrier of entry for editing contents or administrative tasks. At the same time it is important to make sure the user understands what is going on. We should not hide complexity where it is necessary to provide context.

Bart N. (not verified):

If you think about the question "What does a Drupal site builder do" ... you'll probably come to the conclusion that adding/editing a link to/in a menu or adding a block to some region are hardly worth even mentioning compared to all the other (complex) stuff a site builder does.

It might just be to show the concept but what's the point if it only makes the - already basic - stuff a little easier?

What does a site builder do ...

- create content types with 10+ types of fields, paragraphs, inline entity forms, conditional fields ... each field with about 5-20 potential settings.
- create menu's & config the available menu's for each of the content-types, default parents items, ...
- create webforms
- config all required view modes for each content-type with display suite, field groups, ...
- create between 5-50 different views (blocks, pages, attachments, entity reference filters) with (contextual) filters, relations, rewrites, ...
- config url patterns & breadcrumbs
- config (OG) metatags
- config image cache presets
- config all kind of input formats (most likely with very hard to fine-tune WYSIWYG's)
- config a (XML) sitemap
- create user roles and set their permissions
- ... and about a 100 other things I can't think of right now.

for a multilingual site all the stuff you have to config, like listed above, increases to roughly x 1.5 / per language

This is what a site builder does and almost none of it would benefit from an outside-in interface, or I'm not seeing it (yet) because the configuration of these things simply require a lot of (potentially very complex) settings.

Kevin Oleary (not verified):

Not all, but almost all of what's on your list has a potential outside-in solution. In fact Squarespace already has outside-in content, webforms, menus, URLs, meta tags, image formats, and many other things. They don't do it perfectly (despite their reputation they have some pretty big usability and performance issues), but they do it.

Drupal can do it as well, and with a flexible content model, not the handful of fixed content types you get with Squarespace. Yes our complexity makes it harder, but as Ryan suggested, this is the experience users are gravitating to.

Bart N. (not verified):

I would love to see it but it is exactly Drupal's very flexible content model, that makes this very very hard to implement.

Shannon (not verified):

I think this is what will differentiate us further. We already have a robust system, that's not the problem that they are trying to solve here. The problem as I see it is: you need a PHD in Drupal x.x in order to do what you want. THAT needs to change if Drupal is going to remain competitive.

The challenge that I think Dries is putting to the community is: Make it robust, but easy to administer. He wants us to make a smarter interface, and it's not a trivial thing.

We are all cool-aid drinkers and have accepted that Drupal is hard. New people, and administrators who are not developers will not & do not accept this. They call us for help, and while this creates a business opportunity for Drupal service providers, it does NOT create happy customers which will further Drupal adoption & success.

I strongly agree with Dries that if Drupal is going to continue its successful adoption, we need to address the administrative hurdle factor and not simply accept that "once you learn it you're fine" mentality.

We need to disrupt Drupal.

beach (not verified):

The obvious difference - even in the proposed screencasts; is the amount of screen real estate available to administration tasks. The user needs to know what they're searching for when dealing with a large option set. This issue is of course easily addressable, toggle options to increase the amount of space taken up etc. As Ryan has stated the ability to provide greater context to the editing/ site building process is a great way to build product loyalty; ownership through customization.

Kevin Oleary (not verified):

I agree, finding the thing you need with confined space is a difficult problem. There's two parts of this though, one is an "option set" that consists of a number of *different* configuration options, the other is a "result set" where the user is choosing from a list of things.

For "option sets" confining the contents of the drawer to options for the thing that's selected, and making granular selections should help, eg. if you select a field you should only see the options for the field, not the whole node.

For "result sets" D8 has already started to address this with more autocomplete but there's much more we can do here to make results sets "smarter" like automatically sorting objects created or edited by the user to the top of the list or automatically surfacing items that match the context. For example if I'm looking for media to add to an article, media entities that share tags with the article should rise to the top. Larger enterprises like Thompson Reuters or Time with huge data sets might even use machine learning to pull in suggested images for an article before the user even asks (I'll provide designs to anyone wants to build that module).

catch (not verified):

The menu example is a good one, that seems like something that could be worked on without a major refactoring of the menu link system itself.

Blocks are unfortunately a lot harder, and the 'simplification' in the example does not fit with what would actually happen.

For example this bit:

Read what a "path" is
Read how to find the path for a page
Go back to the page and get its path
Go back to /block-layout and add the path to the visibility settings

The entire experience for placing a block outside-in is described as:

Choose where to place the block
Find the block you want to place
Place the block
Close the drawer

If you contextually add a block from a page, that doesn't solve this step and could potentially make it worse without a much wider rethinking of the blocks system.

Are you adding it to node/1?
Are you adding it to node/*?
Are you adding it only to 'article' nodes?
Are you adding it across your whole site?

Then additionally there will be other blocks on the page which might not show up when viewing normally, but could show up in other circumstances.

Let's say I have two node types, my 'articles' type already has a 'related articles' block, and my 'handbook' type has a book navigation block.

I then want to add an 'about the author' block to show for both types.

If I add it from an article page, I can't see the book navigation block in context, because it's not in that context - so there's no way to drag the block above or below it.

If I add it from a 'handbook' page, then I have the same problem with the related articles block.

Layouts and page manager can make this slightly easier, by at least limiting the full list of available blocks to those on a specific layout. However visibility /within/ a layout will still be an issue.


Same answer as above but worth repeating. I agree that context is both important and difficult. I'm confident that we can bring context into the outside-in principle and deliver a user experience that is better than today's. Kevin has been experimenting with context but would love to see others chime in with design prototypes as well. As mentioned in the last paragraph of blog post, I plan to dedicate an entire blog post to this.

Lee Quessenberry (not verified):

This is insanely forward thinking and I am excited for it. The analogy made about learning Drupal before you are able to use it is something I've told my clients in the past, but with a different analogy. I generally tell aspiring site builders that Drupal doesn't have a learning curve, but more like a learning plateau. The initial intake of Drupal is almost a 90 degree grade until it finally makes sense and then you just understand it. Drupal's power as a granular and very configurable framework wins for me every time hands down, but working with other content developers and bloggers pops my little bubble and deflates the wind in my sails as soon as I tell them how to create content in Drupal. This outside in approach should shake things up quite a bit. Oh, and Ryan, what's up dude?

Ryan Szrama (not verified):

Haha, trying to start some cross chatter in the comment thread? : D

(But mostly these days just makin' money to bojanz can pour his heart into Commerce 2.x, the Entity API, Inline Entity Form, and Drupal 8. It's been fun. Looking forward to sharing it all at DrupalCon N'awlins! ; )

Lee Quessenberry (not verified):

Yeah I am all about mixing up the convo. Looking forward to N'awlins myself. I have been busy working for E.C. Barton & Co with redesign number 3 on our main websites and preparing to take a hard look at Drupal 8. Seeing this outside-in approach is very encouraging to me. I have also been contracting for and building municipal library websites. Lots of custom development by other members of the team has been put into an insanely awesome room and event registration module with those guys. I mostly do front end and some data/views integration. Very excited to see what comes of this approach for layout and site-building.

Dom (not verified):

Hi Dries !

I've seen your mockups here in the GIFs: it looks really good ! But also does it because it is approximations and simplification on what really happens (ref @catch comment on other page impacts).

I did a POC myself on what you call outside-in editing (I have called in Front-End Administration so far but In-place Administration would be an even better name I guess). You can have a try here: (it takes no more than a minute to have an idea of it ! Try the block tool it is the most advanced one at the moment) It is really, really far from being good and has A LOT of issues and only started stuff.

Working on this POC let me discovered some issues that might happen :

- A hard part is to provide extensive functionality tool so you need no more going to block admin page. How about editing / moving around the blocks in the page (not shown in your GIF). Idem on how to re-order the item menus ? (not shown in your GIF). Maybe later other tools (moving fields around). I think exposes a toolbar for the block that would allow more interaction then this GIF does. What's your opinion on this ?

- If your tool is always activated (displaying the (+) between blocks when moving the mouse), then the page is going to act cray when using the site as and admin. Moreover if you combine this kind of tools to move blocks, menu items, fields in the same page. It takes a way to activate / unactivate it, also activate/unactivate one by one each tools

- On a mobile, the drag and drop approach is just unusable at all: moving a block from footer to header is just a nightmare on a mobile device.

- On your GIF, the blocks to add are represented as colored squares. In practice, theses squares can be whatever blocks and have whatever shape or size. It can't be therefore a small view of the rendered block. When you have the list of your available blocks, this list can be really long (even just D8 fresh install have a long list of blocks). This make the choosing of which block to add really difficult. I tried myself adding a filter to help finding the block you are interested in.

- What do you think of the idea to have the library of available block and drag-drop it to where you want (my module approach) compared to here first choosing where you want a block, then click on which block you want in your block library ?

- When adding / moving a block around, it may impact (in fact is barely always the case) other pages. I tried to address this issue with adding a warning picto on the block that let's the admin know the impact of his action. Also when adding the block you need the edition popup to appear so you can choose to add the block on this node, all nodes, etc.. as per said in @catch comment. (this part still lacks in my POC)

- In practice, to be able to warn / edit / move / delete each block on the page, I have tried the approach of adding a toolbar to each block. But this is quite heavy on the page. Maybe I should improve my POC with

I am really really exited on this topic and as soon as I have no more clients - or if someone is interested into funding this ;) I will update my POC to catch up with some of the ideas in your GIF. I also would be happy to have a deeper discussion on the topic someday (maybe DDD Milan ?) for I am so frustrated on the difference between building a WIX site and a Drupal site !

If some other are willing to also work on it, here is the module page:

PS: All this are really humble points, I am no one to criticize anything, I just trying to be constructive. D8 rocks !

Kevin Oleary (not verified):

Hi Dom,

I have looked at your proof of concept and it's exciting how far you've gotten with it! In answer to some of your questions:

"If your tool is always activated (displaying the (+) between blocks when moving the mouse), then the page is going to act cray when using the site as and admin."

Very good point and one we've been thinking a lot about. Preston So made the excellent suggestion that—in addition to the "edit" togge—we also have a "build" toggle that turns off all links or interactions on the page so you can navigate around and change things. This could have added benefits if we also move "building" options like "edit view" out of contextual links where they have caused problems.

"On a mobile, the drag and drop approach is just unusable at all: moving a block from footer to header is just a nightmare on a mobile device."

The mock here assumes no drag drop for that exact reason. I *think* the best way to handle that would be to make regions selectable then show a draggable list as in the menu example. If the user wanted to change regions the region select box could be there, when that happened the block would simply "lift" off the page and move to it's new location, scrolling the page if needed.

"On your GIF, the blocks to add are represented as colored squares..."

There's a detailed answer to this in another reply above.

"What do you think of the idea to have the library of available block and drag-drop it to where you want...compared to here first choosing where you want a block"

The "choose first" approach is specifically to get around the problem of drag-drop across scroll that you refer to above. It is definitely different and needs to be tested on users, but I think it could be less painful.

"When adding / moving a block around, it may impact (in fact is barely always the case) other pages..."

Dries addressed this above.

"In practice, to be able to warn / edit / move / delete each block on the page, I have tried the approach of adding a toolbar to each block"

Yes, I see you used the bar Bryan Wald and I designed for Panels IPE with some color changes. It's better than the earlier version of IPE which was much bigger and more obtrusive, but at this point I'm more inclined to say we should move away from that and get those options into the drawer and off the page where they can make it harder to see what you are editing.

If you are in New Orleans i'd love to talk more about this!

Dom (not verified):

Hi Kevin,
I will be in DDD Milan, and I would be really happy to have a deeper thinking / working on this (maybe sprinting on the subject). I would also be interested in doing a session on the subject, but I'm not sure how much spare time I will have to continue working on my POC until then so it may be too light.

Dom (not verified):

Hi Kevin,
I won't be in New Orleans (too far, thus too expansive for my budget) but I will be at DDD Milan. How about sprinting on the subject ?

Dom (not verified):

Wow! We should join work ! It seems that my module has more previsional functionnalities (in term of what can be moved, the warning display of your change impact on other pages, ...) but your one seems far more advanced on the subject of blocks addition / deletion / .. plus the design is cleaner !

Alex UA (not verified):

One small question: is the plan to have both a right side and bottom toolbar? If so, any idea whether that will confuse users? It might make sense to have one for adding/editing and one for settings (I assume some of the in context needs will end up needing settings as well as adding/editing/placing the items).

Anyway, this is really fantastic, and could be a big step forward for Drupal UX.

Kevin Oleary (not verified):

"One small question: is the plan to have both a right side and bottom toolbar?"

There's no specific plan for either, these are just speculative mockups. But you raise an important question because there are currently several competing javascript-powered trays/drawers/off-canvas menus etc. in core and contrib with different affordances and behaviors (not to mention different js), and there's growing consensus that we need to establish some standard patterns, or even helper modules for this (universal off-canvas configuration drawer anyone?).

Vinish Garg (not verified):

Love the advancements in Drupal. I have used Drupal 7 and like many other content strategists, I have always loved it. Drupal8 is awesome and the reduced steps for administrative tasks make it worth pitching even strongly. I will look forward to:
- Markdown editor support (stable)
- Publish to EPUB and MOBI (stable

Chad Peppers (not verified):

I agree with this approach however it appears that most end users that manage these sites often end up confused when there is not a simple form entry field for content. This is why a lot of agencies or companies stay away from panels and instead use display suite / paragraphs because the end user is not quite technical enough for this. With that being said I think its a great idea and for the future.

giorgio79 (not verified):

Re the menu editing example

I guess this example could be improved even more. Why not edit the menu in place? Why the editor should go to the other side of the screen to rearrange menus? :) These tasks could all be achieved in place.

Ted Bowman (not verified):

Thanks for the great post and pushing the conversation on these topics.

I love the idea of making site building in Drupal more intuitive out of the box! This post has inspired me to make the Configuration QuickEdit module.

It exposes some extra contextual links on the front end that will load configuration forms in a toolbar tray(for now). The user can then save these changes and the content with update configuration is loaded seamlessly via the Refreshless module(thanks Wim!).

Here is a quick demo video:

Currently I have field formatters and block configuration changes working. But luckily because of changes in Drupal 8 adding more configuration forms with "refreshless" updates should actually be pretty simple. Because most configuration entity forms have separate classes for each entity I can simply extend these classes and make a "quick edit" version of the forms.

Right now the module is just using Drupal's Ajax API but could be adapted to incorporate Backbone or another JavaScript framework. Rendering changes is handled by Refreshless. In the future client-side rendering could provide even quicker updates and two-way data binding could provide instant updates for certain types of configuration.


Ted, that is a great starting point for how to do outside-in configuration! Thanks for sharing.

k4v (not verified):

Did you consider how these ideas fit with the "headless" debate? Complex frontend editing does not play so well with "headless drupal" I think.

James Williams (not verified):

I know this is a bit late to the conversation, but I recently discovered Shorthand, which looks like another product that has all sorts of UI ideas that could help inform the direction/resulting 'outside-in' UI: