Updated: Comment #0


After creating a new views block display, you have to go to admin/structure/block to actually use it.

Proposed resolution

Add a link somewhere in the Views UI to place it

Remaining tasks

Decide where to place the link

User interface changes


API changes



tim.plunkett’s picture

Status: Active » Needs review
Issue tags: +Usability, +Needs design review
3.15 KB
FAILED: [[SimpleTest]]: [MySQL] 59,304 pass(es), 1 fail(s), and 0 exception(s). View
184.75 KB
111.27 KB
30.97 KB
29.51 KB

Okay, this one REALLY needs some help.
I had no mockups to go off of, and it shows. I just kinda made some stuff up...

There's no obvious place to put a link for this, so I chose to add a new item to the block info section. It tells you how many times a block is placed, and then upon clicking tells you exactly what themes and regions, with a link to place a new one.

In the views UI with the short info:
Screen Shot 2013-09-11 at 9.51.29 PM.png

After clicking with detailed info and link:
Screen Shot 2013-09-11 at 9.51.38 PM.png

After clicking the link:
Screen Shot 2013-09-11 at 9.51.43 PM.png

And the ultimate screenshot, WITH OVERLAY:
Screen Shot 2013-09-11 at 9.53.10 PM.png

tim.plunkett’s picture

80.23 KB
1.34 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch block-vdc-2087219-2.patch. Unable to apply patch. See the log in the details link for more information. View

Here is another option, which adds it to the dropbutton for this display.

I like this better...

Bojhan’s picture

Feel free to ping me before you throw out patches, if you dont have designs. This was actually identified as a serious issue in BADCamp usability testing at #1836390: Add “place block in region’ to the Views wizard to help workflow.

I wonder if it doesn't make more sense to have a Placement category, for example:

Theme name : Region
Theme name : Region

The workflow that you show now, seems super awkward. Its not possible to have a multistep dialog - we do that for fields all the time. ?

tim.plunkett’s picture

The problem with the first approach, the one you're discussing, is that #1851414: Convert Views to use the abstracted dialog modal has not happened, so we have 2 different modal systems.

I'd actually much rather focus on my suggestion in #2

Bojhan’s picture

I understand that the approach requires #1851414: Convert Views to use the abstracted dialog modal to go in, it looks like that is needed for this to work well. So my suggestion is that the method you are using, makes it very tucked away in the interface. Although experts will find it, I fear that most site builders and especially those new with Views won't venture into that part of the UI quickly.

Design suggestion

I suggest instead to make a new category, called placement. In this category all "placement" activities occur. Ideally this means that also activities like placing it in a menu and placing the view on a path, are part of this category. To me is it an essential part of a view, and should we make sure it gets the appropriate attention visually.

In line with Views its current patterns I am suggesting to add this bucket to the second category:

1) Add a category called "Placement". Using views core patterns, make sure it has a Add button to the right. Potential issue, is that this is not discoverable we might need to switch to an empty message or Theme : No block placed yet pattern.


2) The user gets a dialog, you pick the theme you want to add this block to.


3) Using states, we show them a region selector. On Save would trigger the blocks UI, currently placed in a modal on top, but I'd favor a wizard like workflow that we have for fields as well.


4) Returning to the views interface, you get an overview of all the blocks in their respective regions.


jibran’s picture

@tim.plunkett you are doing great work on Block UI overhauling and also in this issue. IMHO I don't like this idea because Views UI has nothing to do with placing/placement of a block but I still think that we should have place a block link something like #2083871-4: Allow menu blocks to be placed from the menu page.

Bojhan’s picture

@jibran Could you elaborate or provide an alternative? I think people expect that Views does help them do this, the fact that it doesn't is actually confusing. The larger solution is for views not to be a page or block creator and just populator, but thats really D9 talk. Until then we should provide a better connection - this issue tries to achieve that.

jibran’s picture

Could you elaborate or provide an alternative?

I think it should be like this

Screen Shot 2013-09-11 at 9.51.29 PM.png

after clicking the link.

No more details and no dialog box needed for info.

jibran’s picture

ok I rest my case. @Bojhan and I have a short discussion on IRC and I agree with him that If block is doing something like this then do it all the way. Sorry for the noise. :)

dawehner’s picture

I do agree with the general idea to be able to place a block inside a view, as long there is a limited scope ...

In line with Views its current patterns I am suggesting to add this bucket to the second category:

I am not really convinced that this is really a pattern of views. The add pattern is used for things which exists multiple times on a view, like for example fields.
On the other hand it does not seem to be the case that you really want to place a views block multiple times inside views. The reason is simple: If you need the block in different regions
you need more of the block settings anyway so I think this should not use that pattern.

Bojhan’s picture

@dawehner Well that is interesting. So you are arguing for something like below?

Screen Shot 2013-09-15 at 4.29.10 PM.png

Bojhan’s picture

I'd be oke with going down this route. It could be under Block settings, I'd prefer if we have a actual Placement category. I always find that kind of functionality tucked away in other categories.

Either way, I'd like to make sure we don't need an intermediate step like in #2087219: Allow views blocks to be placed from the Views UI the first two pictures, because in the overview we want to actually inform the user where its at (Theme : Region). This might not scale very nicely if you have like 10+ themes - but I think thats a manageable edge case. But it removes the need for a modal that only lists stuff, makes it an actionable step - and makes the overview much more informative (2 blocks placed, isn't really usefull information, untill you know where).

tkoleary’s picture

@Tim Plunkett

The patch in #2 seems to disable the overlay at the end of the place block flow when returning to the block UI

tim.plunkett’s picture

@tkoleary from my testing, that happens without this patch.

tkoleary’s picture

179.27 KB

@Tim Plunkett

There's a couple of issues with the patch in #2 (is there a more recent patch?).

One is that you can't place the block if the view has not been saved but there's no feedback to the user explainimg why. Is this a bug or just a UX gap?

Another is that "place block" is not discoverable way over in the display dropdown. IMHO this is a UX issue in views. The options for the display should be connected to the display tab itself.

This would be my approach:


tkoleary’s picture

Ah. Read the issue more closely and I see that I am off topic. The above post should be another issue though. I'll start it. (and Angie pointed it out to me as well)

klonos’s picture

@tkoleary: did you actually file an issue for #15?

tkoleary’s picture


Oops, forgot to. Doing it now

tkoleary’s picture

klonos’s picture

Thanx ;)

dawehner’s picture

2: block-vdc-2087219-2.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, 2: block-vdc-2087219-2.patch, failed testing.

tim.plunkett’s picture

Assigned: tim.plunkett » Unassigned
dawehner’s picture

Version: 8.x-dev » 9.x-dev
Status: Needs work » Active

At this stage of the release it is just pointless to try to do that, given that we neither have a consensus whether it should be done, nor how

klonos’s picture

Version: 9.x-dev » 8.x-dev

Could still be done in 8.1.x at some point.

tim.plunkett’s picture

Category: Task » Feature request
Issue tags: -Block UI overhaul
yoroy’s picture

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.