In Views usability testing we uncovered a disconnect in the workflow of adding a block, as you have to create the block display, then save, then go out to the Blocks UI.

In addition to #1836390: Add “place block in region’ to the Views wizard to help workflow, “place block in region” to the views UI would also be helpful.

We need to figure out the wording but I think something like 'Placement: None' as the default could work.

CommentFileSizeAuthor
#2 block-region-1.jpg94.85 KBlisarex
#1 place block.jpg86.83 KBlisarex

Comments

lisarex’s picture

lisarex commented
StatusFileSize
new place block.jpg86.83 KB

Possible location for change attached

lisarex’s picture

lisarex commented
Status: Active » Needs review
StatusFileSize
new block-region-1.jpg94.85 KB

Actual wireframe; needs review.

This solves a couple problems:

a. They know where the block shows up (if at all)
b. They can place the block in region without taking them away from the Views UI / interrupting their flow

Note that any block-related configuration beyond adding/removing the block to a region requires a trip to admin/structure/block

mockup of views ui showing a block region

dawehner’s picture

dawehner
Primary language German
commented

Thanks for the mockup.

One question is whether it makes sense to have this kind of workflow if #1535868: Convert all blocks into plugins got in.
That patch forces you somehow to create an actual block instance in the block library,
so the workflow seems really special/different compared to your approach.

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented
Status: Needs review » Postponed

That patch is very close, and indeed changes the interaction patterns with blocks, so postponing on that.
#1535868: Convert all blocks into plugins

dasjo’s picture

dasjo
he/him
Primary language German
Location Zurich
commented

As a side note, views could also extend the add custom block workflow in order to allow users, create a new views block.

Just a idea and currently not really the Drupal workflow, but being able to start creating a view/display from within the block configuration page might make sense in the context of this issue

mgifford’s picture

mgifford
he/him
Primary language English
commented
Issue summary: View changes
Status: Postponed » Active
Related issues: +#1535868: Convert all blocks into plugins
yoroy’s picture

yoroy commented
Version: 8.0.x-dev » 8.2.x-dev
Issue tags: +Needs design

Interesting bit of workflow to create wireframes/prototype for.

yoroy’s picture

yoroy commented
Issue tags: +ux-workflow
tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented

#4 is an understatement.

Now that blocks can be placed an infinite number of times, we need to decide how to represent that ability.
Here are some additional questions:

  • Will we store this data directly on the view?
  • If so, if a view block is placed directly via the Block UI, should it be displayed in this Views UI?
  • Should the views UI be able to *remove* a block placement, or just add new ones?
Bojhan’s picture

Bojhan commented

Good questions, much of this idea was before the block concept was fully worked out. We might have some "flooded" pattern issues, as we place dozens of block instances but that might just be rare.

1) I am not sure, what is best there?
2) Yes, I think this ought to be a two-way street and makes people more aware that the two are connected.
3) I think this goes both ways, you would be able to remove as well. We should treat it as one "truth" so all actions should go both ways.

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.

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

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.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.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.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.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.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.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.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.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

lendude’s picture

lendude
Primary language Dutch
Location Amsterdam
commented
Related issues: +#2087219: Allow views blocks to be placed from the Views UI

#2087219: Allow views blocks to be placed from the Views UI closed as a duplicate, not sure this is still something we want to do. We provide something for pages, so maybe we should for blocks? Not sure how many blocks still get placed via the block interface?

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.