Problem

We now have the ability for users to add blocks from the frontend with #2724819: Create experimental module for place block on any page feature, but there is no way to position the blocks.

When the user toggles on "place blocks" clicks a "place block" button in a region, then chooses a block to place, the next form presented is the block configuration form. This form contains visibility settings including region (automatically set to the region where the user clicked "place block") but there is nowhere to set the weight. Without drag-drop or any other way to set the weight the user who wanted the block anywhere besides at it's default position would need to:

  1. Know where to go to change weights
  2. Navigate to "Admin/Structure"
  3. Navigate to "Admin/Structure/Block-Layout
  4. Scroll to the block they just placed
  5. Drag the block to the desired position (or set it's weight)
  6. Scroll to the bottom of the page
  7. Click save
  8. Click "back to site"

At this point the whole "in place" aspect of placing blocks is rendered pretty much moot because I had to go to block layout anyway so why not just do the whole thing from there?

Proposed solution

After the user has placed a block and submitted the configuration form, load another modal showing the blocks in the region and allow the user to position it using table-drag.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tkoleary created an issue. See original summary.

tkoleary’s picture

Issue summary: View changes
tkoleary’s picture

tkoleary’s picture

tim.plunkett’s picture

Status: Needs work » Needs review
Issue tags: +Needs tests
FileSize
762 bytes

AFAICS, this will be the first time we expose weight outside of the context of a tabledrag. This seems problematic.

This is fully functioning (don't let the lack of submit changes fool you). This just needs tests.

tkoleary’s picture

@Tim Plunkett

Patch works great!

One question, how is the number of available weights in the select determined? It looks like it's being calculated from the number of existing blocks, if so that's cool, but if it's the case that we can transform the weights as displayed to the user removing negatives would make the UI much simpler.

My suggested description was in the summary, but given the above it could be simpler:

"Low number blocks* are positioned before high number blocks. *Including negative numbers."

Or if we take out negatives

"Low number blocks are positioned before high number blocks."

Also we need to remind the user that region and weight only apply to the instance in the current theme. I'm thinking wrap them in a fieldset labeled:

Block position for theme: Bartik.

Because there's no guarantee that the region will be present in another theme.

tkoleary’s picture

@timplunkett

Messing around testing the patch some more it occurred to me that there might be some confusion about how to get a block "higher" in the order.

Right now if I have a block "foo" with a weight -8 and I have another block "bar" below it with a weight of -7, My options only include -8, not -9. This leads me to conclude that I can't place a "bar" above "foo" until I actually give block "foo" a weight of -8, save and notice that now the weights have been recalculated and "bar" has a weight of -7.

This is very counterintuitive but could be solved easily by always providing an option of one weight between and outside every actual block weight. So instead of:

Block foo: weight = -3
Block bar: weight = -2
Block baz: weight = -1

If we had:

Block foo: weight = -5
Block bar: weight = -3
Block baz: weight = -1

We could show the user the options: -6, -5, -4, -3, -2, -1, 0, and there would be no ambiguity about whether you were placing the block above or below another block because you would always be moving the block to one of the "blank" weights (-6,-4,-2, 0).

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.

stefanos.petrakis@gmail.com’s picture

Status: Needs review » Closed (cannot reproduce)

Things seem to be a bit different than what the OP described, reviewing this on the latest 8.3.x-dev version.

At the moment, after finalizing the configuration of a newly added block (custom or existing) and clicking on save,
the user is redirected to the Block/Regions overview page, and the page auto-scrolls to - and auto-highlights - the newly added block. In that way, the user can continue uninterrupted with dragging the newly added block at the desired place.

I would say this behaviour is already a lot closer to the "in-place" editing spirit and should not require such a radical change as suggested. So, unless I am missing the point of the OP, I would say this is not an issue. Setting this to "Cannot reproduce".

tkoleary’s picture

Status: Closed (cannot reproduce) » Active

@stefanos.petrakis

This issue is predicated on the user placing a block from the front-end using the 'place block" toggle. At the end of that process the user is not redirected to the block layout page (and if they are they shouldn't be) but back page on the front end where they started.

stefanos.petrakis@gmail.com’s picture

@tkoleary: You are right, my bad.

tkoleary’s picture

Title: Add "weight" field to the block configuration form » Let users set the weight of blocks after placing them via the settings tray
Issue summary: View changes
tkoleary’s picture

Issue summary: View changes
tkoleary’s picture

Title: Let users set the weight of blocks after placing them via the settings tray » Let users set the weight of blocks after placing them from place-block
Issue summary: View changes

After more discussion about this with others I think we can slightly alter the scope of this so that it is not dependent on settings tray but enables the user to table-drag the blocks in a modal.

Updating summary.

tim.plunkett’s picture

Issue tags: -Blocks-Layouts

Not actively part of the Layout Initiative

tkoleary’s picture

Status: Active » Needs work

Given changes to the issue summary post discussion on this in UX meetings the patch at #5 is out of date.

The current state of the flow in the module is:

  1. User clicks 'place block' link in toolbar, region affordances appear on page
  2. User clicks the 'add' link (plus icon) and the modal appears
  3. User clicks one of the 'place' buttons in the list of blocks and the block configuration options appear (still in modal)
  4. User configures the block and clicks 'save" and the block layout form appears (full page, not in modal)

All this patch needs to do is change #4 to:
4. User configures the block and clicks 'save" and the block layout form appears (still in modal)

And add #5:
5. User clicks 'save blocks' the modal closes and the block is visible on the page.

With this flow it will be possible for the Settings tray module to present the modals in the tray.

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.

tedbow’s picture

Component: block.module » block_place.module

I think this might be duplicate of #2784495: Normalize block place and outside-in experiences

Don't have time to check right now but it allows sorting blocks after place.

nerdstein’s picture

@tedbow, my sense is that the aim of this issue, 2791305 and motivations found in 2739075 ensures Place Block works agnostically from Outside In. 2784495 seems to emphasize Outside In integration, which will likely need to be revisited after 2791305, 2791305 or both get merged. My sense is that it is not a duplicate, but something that should be evaluated shortly.

nerdstein’s picture

For visibility, I'm trying to determine how this issue relates to https://www.drupal.org/node/2791305, which seems to have a similar motivation.

SKAUGHT’s picture

Status: Needs work » Needs review
FileSize
2.17 KB

rebuilt #5. enhance form UX with detail wrapper. some actual Weight description text. removed old hidden weight field (duplicate form field)

Status: Needs review » Needs work

The last submitted patch, 21: 2735277#21-rebuild-5-enhance-form-UX.patch, failed testing. View results

SKAUGHT’s picture

have realized this doesn't save correctly. needs work.

SKAUGHT’s picture

Status: Needs work » Needs review
FileSize
2.97 KB

although form has #tree=>true it seems the getValue won't get nested elements. added step in validateForm to bring values down.

Status: Needs review » Needs work
SKAUGHT’s picture

remade and renamed patch. ??hash in name

Status: Needs review » Needs work

The last submitted patch, 26: 2735277-26-Let-users-set-the-weight-of-blocks.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

SKAUGHT’s picture

Status: Needs work » Needs review
FileSize
2.91 KB

..i see. removed details wrapper - breaks too much. fixed array syntax. moved above visibility settings (form elements under vertical tab, looks strange) and as tab isn't shown on settings tray it's just as well.

Bojhan’s picture

Can you make sure to mark this "Needs usability review" when the UI is reviewable?

nerdstein’s picture

Status: Needs review » Needs work

I've tested this with the following observations:

1. Logged in
2. Clicked "Place block"
3. Clicked "+" in a region, a modal window appears with block listing
4. Still in Modal: I click "place block" on an existing block (e.g. "who's online")
5. Still in Modal: I fill out the block settings, press "Save block"
6. Modal closes and redirected to block layout page with the selected block in the correct region
7. Press "Save blocks" on block layout page
8. Redirected back to block layout page

Video: https://www.youtube.com/watch?v=ViUknSpobkQ

Per the comments above, I sense the latest patch did not resolve the proposed workflow in #2735277-16: Let users set the weight of blocks after placing them from place-block, as observation 6 does not stay in the modal, it redirects to the block layout page. It should also be noted that observation 8 does not go back to the page in which the user placed the block.

As such, I'm setting this to "Needs work".

nerdstein’s picture

Status: Needs work » Closed (duplicate)

I believe this is now a duplicate of the work performed in #2784495: Normalize block place and outside-in experiences.

My commentary is found both in #2739075-41: [plan] Make Place Blocks module functionality part of the Block module (etc.) and #2784495-30: Normalize block place and outside-in experiences.

As such, I've updated the status of this issue accordingly.

SKAUGHT’s picture

i hear what you're saying overall. Certainly, i think that 'let the user set the block weight in the ui' -- the basic work of this ticket is needed for the overall, regardless of the rest of the UX flow proposed

i have opened #2887032: Let user set block weight in while configuring block instance for this.
cheers.