B&L - Prototypes

Bojhan's picture


After many intense discussions on the concept model, we have a working prototype as a deliverable and would like to get your feedback on our progress. The current version of the prototype takes the technical as well as the UX challenges of building this for Drupal core.

This post gives background to how we got to the prototype, outlines some of the major concerns and gives a detailed description on the process we followed. With feature freeze coming quickly it’s likely we need to move faster on the remaining tasks outlined at the end of this post.

  • From the discussions in the concept model, we concluded that the community is largely concerned about:
  • How we can make it simple for Edith (content creator) to customize layouts and add blocks, and how to avoid confronting her with too many technical details (contexts/data sources).
  • How users can effectively browse blocks relevant in their given context/data source, and how users can explore all the blocks.
  • Finally, how we manage all of the other tasks around layout, block inheritance, page variations, relationships, conditions.

We didn’t solve all of these questions, but we were able to explore and find solutions to our core problem, which is how to make the interaction where more dynamic interactions are required (e.g configuring content/article/%) usable.

Current prototype

Latest prototype

Although this is a rough prototype, your feedback is essential in helping us move towards a complete solution. You can try out the prototype yourself, but also watch a video that explains the functionality:


The prototype focuses on solving one problem, that of browsing all the blocks vs. only the relevant ones for your available data sources. We will need feedback on this, but also how we should handle usecases like:

  • How will this system handle page variations? What if I want different blocks shown on the Dutch vs. English versions of the page.
  • Can you inherit block configuration? When you are placing a block many times (footer), how does this work?

Moving forward we wish to get verification that we are on the right track but also discuss how we can solve these two challenges.

Details on our process

Brainstorming sessions

We reviewed and discussed all the ideas posted in concept model over the past two months during a number of brainstorm sessions between myself, EclipseGc, jenlampton, merlinofchaos, webchick, aspilicious, Itanglo, UserAdvocate, tkoleary and many more.

The initial feedback indicated that the context/datasource step was too difficult to grasp. We agreed, and decided to try and solve this. batsonjay and jenlampton provided use-cases that led us to start exploring how to browse blocks, and edward_or really honed in on how this could look.

Picture 1: Iteration on blocks browsing by edward_or

The idea was to solve much of the data source confusion by making data sources more tangible, allowing people to browse by the available blocks and thereby creating a direct relationship between the blocks and their required data source.

However, we still needed to solve the following problems:

Understanding data sources is a very tough requirement for simple tasks like making a landing page. In this case the data sources part should be transparent.
Users should also be able to browse all blocks (even if a data source is not available.) Therefore, data source configuration needs to be possible on the block itself.

Data sources should be close to browsing blocks in the UI, which will help users understand the connection between the two.

These conclusions were real breakthroughs in our thought process. We had been stuck for weeks on the ability to browse all blocks vs. only browsing per available data sources. Ultimately, e decided that we should allow both.

A number of iterations followed, leading to EclipseGc’s video and the mockup below. This concept basically allows people to browse by (a) all the blocks, (b) only the available data sources, and (c) custom data sources that could become available.

Picture 2: Browsing per data source, by EclipseGc

After a thorough discussion we figured out that this is simply too much -- there would three
different places where a user could go to find a “Node Body”.

At this point, we also figured out several other points:

  • The URL is the primary data source and needs to be defined before creating a page. Otherwise, you could end up creating URLs that simply don’t work (by piling up different data sources in the URL).
  • If a block requires a data source, and there is already a data source of that type available by default, that datasource is chosen automatically.
  • We need to group the blocks in categories. Browsing by data source alone isn’t realistic; it’s potentially unusable and doesn’t support blocks that require several data sources.
  • Most Drupal core pages (if not all) should be converted to this system to provide examples for content creators.

Following this, we looked at the explorations done by Itangalo, which went in a very different direction. One of the interesting things that Itangalo showed is showing the relationship between data sources and the blocks on the page. Itangalo also introduced a more direct way to change the configuration of a given block. We adopted a number of Itangalo’s proposed interaction, but left out the direct linking of data sources with their blocks, which we felt could become far too complex for our content creators.

layouter 2 (edited).png
Picture 3: Showing data source connections inline, by Itanglo

A comprehensive document is available for detailed information. (Thank you useradvocate!) The document outlines some of the fundamentals issues we faced while designing the interface.

Building prototypes

After our brainstorms, we concluded that we needed to take this one step further and create prototypes. Because this is such a complex topic, it’s really hard to visualize what everyone means in this discussion and how each part of what we do influences the flow.

We went through several prototypes (see below). The prototypes were built in Axure RP, which allows us to make the prototypes interactive. I apologize if these aren't very accessible. Keep in mind that these are still very rough prototypes and by no means complete.

Prototype 1a - http://bojhan.nl/drupal/prototype1a/index.html
This prototype follows the flow where you can browse all the blocks available and configure the data sources.

Prototype 1b - http://bojhan.nl/drupal/prototype1b/index.html
This prototype follows the flow where you can first add a page, then add the node context and then add a node body.

Prototype 2 - http://bojhan.nl/drupal/prototype2/index.html
This prototype builds on more knowledge where prototypes 1a and 1b fell short. You can create a page, add a datasource through the URL and then browse all the blocks. This prototype takes into consideration conditions and relationships, and provides more usable browsing when there are many blocks.

Prototype 3 (latest prototype) - http://bojhan.nl/drupal/prototype4/index.html
This prototype builds on a lot of discussion that followed prototype 2. It takes into consideration block placement, toggling between relevant blocks and all blocks, and data source configuration; and also makes the prototype more interactive.


We are not yet finished, but we are well on the road to being so. We came to the conclusion that in order to make this truly usable for both end-users as site builders, we need to allow browsing all blocks and provide a clear relationship between the data sources and the placeable blocks.

We tried to keep notes of all of the discussions we had on IRC and in Skype, but occasionally we failed to report back from these discussions in the original concept model thread. I hope this post will clear up what the progress has been, and help us move forward in discussing all of the details we haven’t covered yet.

We unfortunately have only have a few months left, and we haven't even reached the implementation stage. Our strategy for now is to continue discussion, and move towards implementing the parts on which we have reached consensus. We really need to get things in, since it is simply too big to solve all at once.

The topics we want to explore further are:

  1. How will this system handle page variations? (e.g. different blocks shown on the Dutch vs. English versions of the page).
  2. Can you inherit block configuration? When you are placing a block many times (footer), how does this work?
  3. Can you make groups of certain blocks? (e.g. a “header group” for your sitename, top navigation, search box etc.)
  4. How do you create a custom layout for your landing page or even your mobile site?

What do you guys think of this? Are we moving in the right direction?

Drupal 8 Page Building - A Strategy for an Outside-In User Interface System.pdf2.9 MB
blockbrowsing.png48.32 KB
EclipseGc-bringing-them-close.png118.77 KB
layouter 3.png31.64 KB
layouter 2 (edited).png69.47 KB


Really, really nice

Letharion's picture

Post removed, accidentally posted before I was done. :)

Wow that's some really

redndahead's picture

Wow that's some really awesome work. I like the add conditions dialog as long as the number of elements inside the tooltip is kept sane. I.e. No scrolling. Great Job.

Very nice progress! I have a

dodorama's picture

Very nice progress!
I have a couple of questions:

  1. Will the region system be still in place or it'll be superseded by the layout system as seen on Spark ?

  2. What happens when a create a new node ? Will I have to pick a template every time or I'll be able to apply a template to the content type so that each node page will be consistent ? Are we planning any granular permissions to prevent certain users to modify the layout and letting them use only a sub-set of the features ?

I'm generally worried about the layer of complexity this could add to the UX. While this certainly look useful for me as a developer I don't want to present to content editors the complexity of a such a system.

"as seen on spark"

tkoleary's picture

In so far as your question relates to spark, we are currently using panelizer which allows the user to apply a default layout to a content type. IMHO this should be the model for layouts in D8. It seems to me that the model we are all moving towards is:

• The entire page including header and footer behaves like a panelized layout.
• Regions as we know them in D7 behave like panelizer regions ie they can be re-arranged on a per-layout basis
• Default layouts can be applied per content-type
• Regions can be "locked" based on user roles

I completely agree with your last comment. All the interfaces for this should use progressive disclosure and only expose options on the surface that relate to immediate content creation needs ie. "I want this image on the right and the text on the left"

Is hard to answer but the aim

Bojhan's picture
  1. Is hard to answer but the aim is definitely to change it. Depending on Spark's speed we might see it here, or see it as layout plugin.

  2. No, by default it will use the node template. You can however create layouts specifically for a given content type. I don't think its likely we will out of the box support such complex permission sets, its more likely a contrib will do this far better than we can build in such a short time.

To clarify a little on the perceived complexity. The use case described in the video and prototype is for when there is a dynamic data source (e.g. node from URL), when you are creating for example just a landing page with no data source - you will not be required to go through any data source selection - it is completely optional.

For Edith, its likely she will not touch on any of those parts (data sources/conditions etc) - therefor we should use as much progressive disclosure as needed as pointed out by Kevin.


batsonjay's picture

Not because it's a big deal, but only because I wrote the persona.

It's "Ellie", not Edith. See http://groups.drupal.org/node/183784 :-)


I stand correct. I guess I

Bojhan's picture

I stand correct. I guess I accidently made the persona sound like a dutch name :)

I joined the group responding

John_B's picture

I joined the group responding to call for feedback on Prototype 4 at http://groups.drupal.org/node/244228.

Before looking for negatives I should say the whole project is great, and great for Drupal.

I have been making sites in Drupal 6 & 7 for 2 and half years, and this is a big part of how I make my living. I came in cold to look at the prototype, and deliberately did not read back over the ideas. I am giving immediate user impressions rather than commenting on the architecture.

I was very confused by menu items 'Page created' and 'Block placed'. On reflection, I think 'Page created' means 'add blocks to the page layout you have just created'. But I am not sure. I think 'Block placed' means 'position the individual block you have just created.' But not sure. If that is what they mean, then the first item should be something like 'add blocks to layout'. The second something like 'position a block'. But still confused.

It looks at 'Page layout library' that a page is a page-type rather than an individual page (though a page-type could have only one page using it of course). This needs to be clarified. The whole distinction Page Layout || Individual Page || Individual Node needs to be clarified for users.

A layout could be a called a 'Page template'. A single page on a site (i.e. defined by a unique URL) could be a 'Page instance'.

As for 'node' I am afraid we are never going to shake that off, but the difference between a page and a node does confuse new users. If Drupal could call a 'node' a 'content item' that would be clearer. Maybe a compromise for usability, if we are stuck with node, is to use the phrase 'content node' in the menu.

I second that

Drupalnieuws.nl's picture

Nice work. I think this prototype has the potential to end up feeling very natural, despite experiencing the same confusion as John_B.

I was a little bit less confused after i realized this is the structure page, not the add new content page (despite it being clearly stated on more then one occasion), so surely i would be making a Page Template (aka a View?) here?

But then i got confused again because the menu shows "Content > Add content" as active?

So the question is: is a "Page Template" content or structure? Or both? If you look at a Page Library as the equivalent of Views then i would say both, which makes it difficult to place it in one or the other.

Perhaps i am totally on the wrong track here. (i must confess i only follow this initiative from the sideline)

I also have no problem with changing "node" to content item. I am currently writing a tutorial and I try to avoid the word as much as possible, as i feel it confuses new users.

Despite the confusion i do like the way different parts (blocks, views, relations) are working together here. This is a major accomplishment that will save site builders allot of time.

You are right, the

Bojhan's picture

You are right, the terminology is confusing - because you are not adding "pages" but page templates. EclipseGc his comment adresses this and proposes to change it to "page templates".

Answering specific issues you

John_B's picture

Answering specific issues you raise now. One of the above questions was "How do you create a custom layout for your landing page or even your mobile site?"

I am not sure how this is different from any unique page. The term 'landing page' is confusing anyway becuse some people just mean the home page. In SEM it may mean the page to which an advertisement points. I do not see that offfering a way to define a custom landing page (as distinct from any other custom page) is going to more useful than it is confusing.

"How will this system handle

John_B's picture

"How will this system handle page variations? (e.g. different blocks shown on the Dutch vs. English versions of the page)."

I think for now each block needs to keep its react to contect feature (i.e. show for page, role, snippet, possibly also for language or other context) as people are used to that. A translation management page for example could present another way in for content creators, and the 'react to context' section could be hidable from content creators.

'Data source' is also a confusing term because the new user is left wondering whether a data source is the source of the data which provides the context to which the block reacts, or the source of data within the block. It is more intuitive to tell users that blocks react to (1) layout type / template; (2) content type; (3) user role; (4) language; (5) individual content URL / unique page. All these things are more concrete than the more abstract concept, 'data source.' To what extent this data is coming from the unaliased URL is a technical issue of no great interest to the content creator, and they should not be asked to think about it, though they can be told about it as a matter of interest if they want to understand the system 'under the hood.'

As for grouping blocks, Drupal 7 has grouping blocks by region and so does WP, so people are used to it. Whether it is hard coded is another question. It is possible to provide blocks grouped by region by providing a bunch of default layouts in a Standard Install of D8 with some blocks ready set up in areas people think about as header, sidebar one and so on; alternatively it would be possible provide an option to toggle on wire grid which can be switched on to help users see how to create a layout of the kind they are accustomed to, with certain blocks in header, certain blocks in sidebar one, etc.

OK all my comments may be way off the thinking going on in this group! But sometimes a reaction from outside may have something useful in it.

hi bohjan et al. great work

dasjo's picture

hi bohjan et al. great work so far folks.

Add a block: i would like to have the table display a column of data sources that each block is using. the option "show relevant blocks" is not clear i guess. alternatively you could add a further table / section below which titles something like "blocks that require additional data sources to be configured".

the current prototype is very page centric. i would like to be able to create my own blocks just like i can create pages but without specifying a path. think of it like mini panels.

keep us posted, thanks

Comments on Prototype 4

jhodgdon's picture

I took a look at the Prototype 4 site -- It looks interesting, but I found it very difficult to grasp.

Overall, I think the concepts of Path, Conditions, and Data Sources are kind of mixed up, and the ideas here seem to be a mix of trying to apply user-defined layouts to existing module-defined paths (such as admin/whatever and node/%ID), which is basically the Drupal 7.x and before way of doing things (adding blocks to existing main page content at particular paths), and a new idea of letting users define their own paths (such as content/article/%title) where they define the layout and which blocks go into them, and letting modules define the blocks that they produce. I am not sure the two ideas can really be mixed, and this prototype seems very confusing because of trying to mix these two ideas.

So... Here's what I think can be done to untangle this:

a) A module can define a block that needs some input (I think this is the "data source" concept in this prototype), such as "Node content from ID number", "Node content from a URL-safe version of the title", or "Administration page from admin path". And it can define blocks that don't need input, such as "The primary links menu". Some blocks might need more than one input.

b) A user can also define blocks that need input (e.g., Views with contextual filters), and blocks that don't (static text).

c) Modules and users can define page layouts. Page layouts are given a path with any number of wildcards in it, such as "article/%title" or "foo/%bar/%baz". When adding blocks to the layout, users/modules can define which wildcard(s) from the URL get sent to which block as their input(s). And the conditions are relative to the path wildcards and data sources, such as "%bar is the URL-safe version of the title of an Article content item", or "%foo is the URL-safe version of a taxonomy term name from the Foo vocabulary".

I also have a few other comments on specific pages of the prototype:

  • Structure: The term "page" confused me here. I think the UI should consistently use the term "page types" or "page layouts" instead of "page", because to me a "page" is something like About, Contact Us, etc. (a single page at a single URL on the site). So I would suggest making the heading "Page types" with help "Manage page types, which control page layout, URLs, and block placement".

  • Page library: I didn't notice the right sidebar ability to group pages into categories at all until about the 10th time I looked at this page. Put the categories into the table, and put the filtering above the table maybe? How about allowing me to sort the table either by name or by category? Also, "URL" should say "Path" to be consistent with the rest of Drupal and with the Add Page UI, and I'm assuming they wouldnt' start with "/" in the real system?

  • Add a block: Like page layouts, the filtering needs to be more obvious, and it would be helpful to have the categories in the table, and the table being sortable by name or category.

  • Add a block: On the right sidebar, I'm not sure how "data sources" relate to blocks or why they are there?

After having had a fairly

EclipseGc's picture

After having had a fairly lengthy conversation in IRC with jhodgdon clarifying some of her issues, I wanted to post here for everyone else.

A couple things that are easy to miss/misunderstand.

1.) There is a dialog for the path that asks you to define what data source type the url argument is going to map to. This drives the whole process of fulfilling data sources for conditions and blocks.

2.) Likewise don't take the condition UI too seriously, it is 100% placeholder and has no discussion between Bojhan and myself at all yet.

3.) If you're a page_manager/panels expert already, "variants" are intentionally left out of this prototype for simplicity sake... this doesn't reflect a desire to remove the notion of variants in the core implementation.

With regard to jhodgdon's points a, b & c: I hope the prototype implies all of these things to anyone looking through it because I absolutely intend for these to be the case. The only point I'd like to clarify is that a block will not specify that it needs a node id, or title, or whatever, it will simply state that it needs a node (and a separate system will be in place for transitioning various type of url arguments into their corresponding data source for the purposes of fulfilling the block's needs).

Hopefully this helps to clarify. Also the suggestion for "page templates" has been made as a terminology change. I actually like that a lot, I'll let Bojhan comment on his own feelings on that before we actually propose changing it any, but it seems like a good move to me.


Good work

mori's picture

Looks really promising. Good work. Hope I will have some time to check it all in detail the next days.

Permissions definitely a concern

crimsondryad's picture

It's possible I'm misunderstanding part of this, if I am, I apologize in advance. The wireframes are a bit tough to wrap my head around.

I can't agree with the statement that block permissions should be handled in contrib. Blocks today are fairly segmented off which is in some ways a blessing and a curse. The blessing is that it gives us an opportunity to keep certain kinds of functionality as site admins away from content creators who don't technically understand what they're doing. We don't give content creators on our sites administer block permissions.

The second part is that I definitely don't want just any site content creators to have the ability to select from potentially sensitive info ( like user data ) in a block.

The curse is that there are lots of situations where they really just want to display a couple of fields of node content in a block on a page and the only way to make it easily editable for them is to create a 1 node view and include it. So letting them easily add blocks in some situations would be helpful.

Views has the capability to bypass access permissions to output data ( for instance user fields). We have the ability to restrict who can build a view. We need the same kind of controls for who can add blocks and which ones.


rudiedirkx's picture

How is this simple for Ellie/Edith? It's overkill in most of the cases and it's already possible to let an editor add blocks to a page. There's Node Level Blocks and Block Reference.

Maybe I'm missing the point..?

Is Target Users or Builders?

mudsurfer's picture

This is obviously a fantastic piece of collaborative work - and some great ideas.

My own context - I'm a site builder primarily (I'm here because a tweet from @chx calling for site builder comment): My clients are predominantly simple content creators. They come to me for a website, because they have NO idea about how to build one.
In the vast majority of cases I would not (and they would not) want them to fiddle with block placement.

Dont get me wrong - I can see the promise of the UX work here, but I would see this as the sort of functionality that I will use - not something that I would expose to my clients. Even taking the prototypes for what they are - early illustrations of the concepts - I think the concepts themselves would be far too advanced for 99% of my client base.

In some respect, the functionality here strikes me as being quite similar in concept to what MS Sharepoint uses in terms of selection of "webparts", and placement of those webparts into templated regions (via a drag and drop GUI). Despite my aversion to Sharepoint these days - I still quite like that concept - but even then, in my experience administering sharepoint intranet sites for 4 or 5 years - this functionality was beyond the comprehension of all but the most advanced users.

So in summary - I think this functionality might be useful for me, and my rare technically minded client, but the question I have remaining is: will there be permissions to enable me to hide all this new functionality for those users of mine who's heads would explode if I tried to explain this?

Powerful but difficult

askibinski's picture

I took me about half an hour to understand the concept of data sources. It is a powerful concept for (advanced) site builders, but way too complicated for end-users. But I believe that normal content editors will never be faced with terms like "data sources"? (I sure hope so! ;)

I do have a feeling some things might be easier to understand when they would be explained a bit differently. Like the way the Views wizard works by using normal language as quick way too create a view and afterwords lets you tweak advanced settings.

I think this is great from a

chris_h's picture

I think this is great from a site builder's perspective - it gives a huge amount of flexibility and alongside views (in or out of core) would enable layouts to be both dynamic and visually consistent.

But it's not a content editor's tool.

As a content editor I want to:
- easily add a news story or event and add it to a menu without having to worry about page layout
- add a variety of content types (text content, followed by a video, followed by a table) to the main content area; and call to action in a sidebar, onto a pre-defined and designed layout
- add a video to the homepage or a landing page using drag and drop and browse
- create content (a 'basic page') with a different layout from other content of the same type
- have a pre-existing pot of designed components to choose from - what to read next menu I can select, donate now image + text + button, list of X content types, styled quote
- add a list menu to a sidebar that consists of a title and some links to existing pages (whether those pages are 'nodes', 'views', the contact page or external urls)
- never see the block administration screen
- never be exposed to language like 'data source', 'node', 'view'
- do the above and for it to automatically work for responsive and/or separate mobile layouts as designed

This boils down to two separate but complementary things for editors:
1) choose a layout ('page' from a template) and add content to it
2) create content and optionally apply a layout to it

Great work but ...

dcmistry's picture

Apologies for the super late feedback! I hope it’s not too late.

First of all, THANK YOU everyone for such an awesome effort – this is going to be a game changer. Kudos to everyone involved.

I do understand that this feature is very complex technically but since it is going to be the basic foundation, the need for a simple UI is obvious. I am afraid but the current prototype is difficult to grasp.

My two cents:

• Overall, the flow is confusing because it does not inform the user what is the purpose. The flow has to educate the user that there are two parts to the feature (one to create a page and have a layout, and two being populate the page with content)
• The terminology used in the UI is very technical with no help information
o What is a data source? What does it to mean?
o What is a relationship?
o What is an argument?
o What is a relevant block? What makes a block relevant?
o We at Drupal have a legacy issue with terminologies and this one is following the league.
• It does not provide any information about which fields are mandatory and which aren’t

Feedback by page:

Apologies if this sounded harsh, it is not intentional. I would be happy to help and get us closer.

Dharmesh Mistry
UX Researcher | Acquia,Inc.

@dcmistry Thanks for this

Bojhan's picture

@dcmistry Thanks for this feedback, don't worry about sounding to harsh - I think we should always strive for the best quality, that means shooting something down when its simply not there.

I agree with your assessment, that as of now the overall flow is incomplete and confusing. I have had the same feeling, and was seeking feedback from others before continuing on this part. Its quite difficult to capture, both the simplistic use cases and very complex use cases. This iteration, is primarily aimed at establishing all the technical/conceptual parts that need to be there and setting an initial direction for the UX. It is my feeling, that we need to do at least two major UX iterations on this, to get to something a content creator can use. To address your concerns;

1) Overall, the flow needs more work. I agree that its now not clear you are going through a two step process. Ideally it should be "Create a page", and then "Place blocks" but now its a bit of a surprise what happens after you finish the page creation.

2) Terminology, to address them all rather than one by one. I think you are right, these are all terms that are and would be used in Drupal 6, where we removed quite a number in Drupal 7, we should not be introducing new confusing labels in Drupal 8. We should try to improve this by in some cases choosing a different label, supplying better help text, and or improving the interaction models. I believe the biggest gains can be done in the latter, but I would love to hear more feedback on this, because it is a significant issue - and I agree, none of those terms make much sense if you are not a programmer.

3) You mean, on the actual form or in terms of fields you need to place on a page? If its the former, that should be an easy fix.

Page by page comments;

- I think this brings us to the significant issue, of users who don't understand URL'S and/or arguments in the URL. I have no solution to that, other than allowing that link to be clicked. Do you have any ideas how to solve this?
- We should implement dropbuttons, as used in Views. This should allow for the 80% case to be presented, and delete to be hidden from initial view.
- Those are "page" categories, because modules and users will add pages it would otherwise quickly become a very long list. This however is an assumption, if we start building this and trowing pages in there this will be confirmed/denied.

- I am going to add help text there, at least to educate people on what paths are and how you can create them.
- The box should only be triggered if you add a argument in the URL, but I again I agree this is going to be trippy. Perhaps it should be something like a field below, that shows when you put in an argument.
- We should definitely use different terminology, this is going to be the most tricky to solve - because its unlikely we can find much better fitting labels for ID.

- It is a preview of the block, this is there because it informs the user how it will look in different view modes and how the configuration effects the blocks display. Its mainly there, because we choose not to have a in context view, which made you able to configure and view your changes at the same time - because that was simply too much magic in one UI. We can possibly solve the preview problem, by making it visually more clear its the block and using appropriate labeling.
- The region selector is there for accessibility reasons, you need a alternative way to place a block next to drag and drop.
- Your content stays the same, unless you configure it to use a different data source.

Thanks for this laundry list of things to work on, it confirmed much of my concerns that we still have a long way to go. It was important for me, to get this out and get community feedback - rather than address all my own concerns, because in part I feel the community should be part of even the initial work, when everything is still being figured out - rather than the polished version.

Video: Envisioning a New UX for Drupal

User Advocate's picture

Apologies for not jumping into this thread sooner. I first would like to thank Bojhan for doing so much of the legwork to keep this discussion moving and putting together an excellent prototype.

Some great comments have already been made and some important concerns have been raised. Rather than address them individually I’d like to focus on a general strategy that might ultimately be able to answer many of those concerns.

Bojhan has attached a document I prepared to explore certain strategic concepts. I recognize that this document is far too long and boring for most people to read (if you have made your way through my hat is off to you – I owe you a beer).

To remedy that, I’ve created a video that explains the key concepts in 15 minutes.

The video is not intended to address all the design details but rather to look at a larger interaction framework - from installation to page construction to content editing. I’m a strong believer in In-Place Editing so I’ve also touched on how this UI framework can integrate with the marvelous work being done under the Spark initiative.

The architectural shift that was initiated with WSCCI and has spawned Scotch is opening the door to using a ‘pull model’ for content retrieval. Panels also is based on such a model and it represents a significant inversion of how Drupal works. There is a lot we have to do to arrive at a UX strategy that can live up to the potential of this architecture. In this video, I have focused on what I consider to be the key aspects of this transformation.

I believe this transformation is achievable (i.e. that the design problems can be identified and resolved) but I really don’t know how long it would take to complete it. So it may be that some of the things I’m suggesting in this video are simply not practical for the D8 release. However I still think it’s worth laying it out for us to consider.

The video (along with some additional notes) can be seen here:
Envisioning a New UX for Drupal

Michael Keara
User Interface Systems Architect,
The User Advocate Group

Relevant blocks & Data-sources

edward_or's picture

Great work so far! Exciting to see it come together with helpful comments.

Quick question. What happens when I add block that does not show up in the "Only show relevant blocks" filter? Does the data-source get added automatically?

See https://dl.dropbox.com/u/8289745/block-list.png

@edward_or No you have to

Bojhan's picture

@edward_or No you have to define it, we can't really add a data source automatically because you have to define what it is or where it comes from.

Here's the

kika's picture

Here's the http://bojhan.nl/drupal/prototype4/index.html review by me and @bojhan from Drupalcon Munich.

In general the 80% use case of "accesss page libary -> add/edit page -> place simple block(s)" is working great and have straightforward interaction.

The struggles are in 20% use case when creating more advanced block configurations. The user has to confront three complex concepts: path arguments, conditions and data sources and relations between them.

Now, review page by page:


  • Filtering this page is important but it should not be a initially required. Filter can come in later http://drupal.org/node/1475204 ([META] Provide a generic search/filter UI interface pattern for listing pages).
  • Should there be "Override" and/or "Clone" funtionality?. Overriding page's default configuration should be very common (80%) case, creating sub-pages on based on existing pages is 20% case but can be very effective and smooth introduction to "three complex concepts" mentioned above.


  • Title is a required field, right? Could it be automatically generated?
  • It should be noted that Title is needed only as administration title
  • Layout thumbnails should be more compact
  • Path: creating path and inserting path arguments from scratch is an advanced task and we do not need go to crazy to introduce the concept here. Usable and effective argument picker (like the popout proposed or the re-using Token UI ux ideas) + appropiate field description is hopefully enough.
  • It's probably more efficient to introduce and re-use generic modal dialog in core than use popover proposed on the mocks. The dialog could be converted to popover later.


  • Same comment as in "Page Libary": Filter can come in later.
  • Rename "Place block" -> "Configure & place block" (already renamed in B&L sandbox)
  • What is the order of the blocks? Grouped by relevancy and then A-Z? If this is the case, "Only show relevant blocks" toggle can as well be a closed fieldset below "Relevant boxes" -- better spatial mapping and re-using existing UI pattern.



  • Where should "+ Add a block" button go when there are blocks already in the containers? Between each block and on top and on bottom? Using hover state or not?
  • Note that the "+ Add a block" should follow the initial empty state button styling/labeling, just being more compact.


  • This is a tricky one. At first i figured this page is too complicate and should be replaced with in-page popout so you you can see "real preview". Then Bohjan explained that this page has to scale to quite complex block setup and previewed blocks can also be quite big -- so this dialog is a compromise. Also, there are accessibility issues with inline stuff. I am OK with that but it would be still nice to replace it with smarter in-page editing in D9.


  • The most complicated one from the bunch. From "three complex concepts" in B&L, two of them -- path arguments and conditions -- build on some kind of visual element on screen (token popouts in path field, Acton/Rules-like condition builder). Data sources way more abstract concept and it's gonna be harder to explain.
  • In a way this page is similar to "Field overview" page tucked under "Configure" page where fields are listed, detached from their actual bundles, to serve a very advanced use case. I understand the need for the page but I hope 80% users do not have to deal with it.


  • Actually, THIS page is the most complicated one. From the Bohjan's explanation I understood this essentially fills the "When argument is not present, use this value instead" case. Can it be simplified so it becomes just a extended inline dialog (Views-style) under http://bojhan.nl/drupal/prototype4/index.html?Page=Node_Body?

Other comments

  • What's the plan with variants?
  • Should intro text on Welcome page to be converted to a block and be editable / replaceable?

Concept model for Adding versus Creating?

jwilson3's picture

I thought it would be worth mentioning that I found it confusing to click "Add a block", and then the first button on the page says "+ Add new block" (a button to the same thing? down the rabbit hole??? ;) ...

Maybe this brings about a larger conceptual issue distinguishing the difference between "Addinga (preexisting) component to another component" and "Creating a component so it can be added to a another component." Perhaps conceptually, there isn't a difference, but from a workflow perpsective, these are slightly different paths.

Maybe its as simple as changing the terminology to "Create a new page", "Add a block (to the page)", and "Create a new block".

Or maybe just "Add" and "Create and add" would be easiest way to explain it.


Group organizers

Group categories

UX topics

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week