Problem/Motivation

During the usability study, users tried to add a block to a region by opening the contextual links for the blocks in that region.

Proposed resolution

Add contextual links for regions, with the option to add a block to that region. This will increase the number contextual links on each page.

Remaining tasks

This issue is dependant on the UI changes in #2512456: Implement the new block layout design to emphasize the primary interaction of placing a block
We're going to have to write some code so we can pass in the region selected as a parameter.

User interface changes

A contextual link added to regions.

API changes

None

Data model changes

None

Comments

ivanstegic’s picture

legolasbo’s picture

Status: Postponed » Active

Dependant issue has been committed.

legolasbo’s picture

Do we want to add a contextual link for all possible regions? Or just the ones that are currently available on the page?

tkoleary’s picture

@legolasbo

Do we want to add a contextual link for all possible regions? Or just the ones that are currently available on the page?

Since there are other ways to accomplish the same task I would say only regions that are displayed. By analogy, in Quick Edit module we do not provide a way to "quick edit" fields that are not rendered.

wim leers’s picture

By analogy, in Quick Edit module we do not provide a way to "quick edit" fields that are not rendered.

That's an invalid analogy. Some fields cannot be rendered, because they're metadata. OTOH, all regions can be rendered, because that is their entire purpose.

I would say every region should have a contextual link, including ones that currently don't have blocks. Because that's the point: you want to put blocks in certain locations, so shouldn't we give the user the ability to add blocks to currently empty regions?
(And yes, I'm well aware that this is not without consequences. I'm playing the devil's advocate here: I'm trying to channel what users want to be able to do.)

wim leers’s picture

By analogy, in Quick Edit module we do not provide a way to "quick edit" fields that are not rendered.

That's an invalid analogy. Some fields cannot be rendered, because they're metadata. OTOH, all regions can be rendered, because that is their entire purpose.

I would say every region should have a contextual link, including ones that currently don't have blocks. Because that's the point: you want to put blocks in certain locations, so shouldn't we give the user the ability to add blocks to currently empty regions?
(And yes, I'm well aware that this is not without consequences. I'm playing the devil's advocate here: I'm trying to channel what users want to be able to do.)

legolasbo’s picture

I fully concur with Wim,

If we are able to find a way for the user to add blocks from the front end we could hit two birds with one stone.

  1. Improve block placement UX a great deal
  2. Remove the "Block layout" page (or at least make it a sub-section of the theme settings) which fixes some concerns raised in #2512456-210
lewisnyman’s picture

I think we spoke about this, it's going to be very tricky to render all regions all the time, that's going to impact the display of the page in a big way. For example, Bartik would always have two sidebars.

A short-term fix would be to just add this contextual link for regions that are rendered. Maybe the long term fix would be a UI overhaul.

legolasbo’s picture

Couldn't we use AJAX to "enable" the regions when they are needed for block placement and then "disable" them again after a block was placed and/or settings were saved.

tim.plunkett’s picture

What is going to trigger that? Any contextual link on the page would make all regions suddenly appear?

This is why the Panels IPE has buttons at the bottom to trigger the mode where all regions are shown.

legolasbo’s picture

This is why the Panels IPE has buttons at the bottom to trigger the mode where all regions are shown.

That's what I was thinking of.

tim.plunkett’s picture

I can't imagine how that would be in scope for 8.0.x

tkoleary’s picture

Couldn't we use AJAX to "enable" the regions when they are needed for block placement and then "disable" them again after a block was placed and/or settings were saved.

This is a good idea, but as Tim suggested, it feels out of scope for 8.0. The purpose of this issue is to make an immediate fix to a usability issue by leveraging an existing interaction pattern to behave as the user expected it would, not to introduce a new interaction pattern which s what some comments here are creeping towards.

I fully expect that there will be several competing solutions in Drupal 8 contrib for dragging and dropping blocks around on the page in a Panels IPE-like fashion (there are already two that I know of, edit UI, and better blocks ). IMO this issue should take the simplest approach possible and leave the more complex functionality to contrib.

yoroy’s picture

Version: 8.0.x-dev » 8.2.x-dev
yoroy’s picture

Issue tags: +ux-workflow
tedbow’s picture

skaught’s picture

adding to this issue from #2724819: Create experimental module for place block on any page feature
in mixing these issues https://www.drupal.org/project/bud has some good progressive ideals in-line with this ticket.

of course, further down the trail of (progressive) enhancement would be https://www.drupal.org/project/feadmin -- for drop 'n drag & cross region dropping.

tkoleary’s picture

Status: Active » Closed (duplicate)