[plan] Make Place Blocks module functionality part of the Block module (etc.)

I'm not sure I agree with any of the must-haves.

I think if people like the functionality we should do some modest iteration on the design based on user testing

We should release as an experimental module in 8.2.x and if people love it, simply merge the code into block module in 8.3.x or later.

I'm not sure I see any need for DnD or a contextual link. The latter seems like it would be much less clear than the buttons, and it can't work for regions that are currently empty.

Adding an expectation for a timeline based on @webchick's feedback in #2724819: Create experimental module for place block on any page feature.

The summary has been updated following review from Bojhan, Angie, Tim and others. The rationale for this is:

Must-have

• We need to ensure that the design that is put in core, is tested with end users and needs further optimization - thus marking #2739079: Reduce visual clutter of Place Block module as a must have
• The module is currently a one-off that lives in the space between quick edit and block, we need to decide where it goes - if it goes into block, or continues as a separate module.
• We need to discuss how we want to handle the "trigger" for in-place blocks functionality, this might stretch to how we deal with "other inline edits" but can be contained to just this use case. This discussion should be clearly scoped, additional discussion deferred to [ #2732443]

Should-have

• We believe changing the block position from the front-end is important, but a contained problem that is not a must-have for graduating this module. As its a largely pre-existing problem, enhanced by this module.

Could-have

• A all encompassing solution to triggering view/edit modules from the toolbar #2732443: Finalize the behavior for triggering view/edit/build modes from the toolbar (and fix the "disappearing toolbar") is a could have, as it requires significant thinking and potential overhaul of several modules.

This little tweak is the last thing needed to fix the biggest problems Emily saw in informal user testing at MWDS #2791305: Set block weight during Place Block flow so it's always at the top

My goal is to have this (fairly trivial) functionality just merge into the block module or someplace else in core when people are happy. It doesn't ake sesne to be a stand alone feature except as part of the feedback process.

to point out: Weighting is a complex aspect, as most directly people are only thinking of 'of the blocks in this region'. but it will also effect groups of blocks on other seen on other pages depending on block visibility settings per block.

#15.2 -- an 'Add block' context link certainly would be nice. although that can be done from the block.module itself.

some functionality similar to Block up/down would be helpful as well.

Having watched the hangouts discussion on where to add the "place block", got me thinking about the current issue Restructure the Admin interface. I feel like trying to address the "place block" issue, shouldn't be as much of a concern until something is figured out on a better workflow for the Admin menu. I think a lot of the problem with this discussion revolves around the fact that the Admin menu is not designed well enough to allow for this type of addition, so we're left sticking it here or there on the current menu until something works. I guess what I'm "suggesting" is to get it in there somewhere until the admin menu is redesigned, then worry about fine tuning its placement.

I just feel like this discussion will become double work: Figure it out now, figure it out later. I don't see the decision made now, working with whatever is decided on the Admin menu later. While I haven't had a chance to dive into the discussion over there just yet, I envision having the menu bar setup with "what do you need to do" tasks as the primary buttons, similar to how the manage button works now, but adding more task buttons to define the mode the site is in with one of the buttons designed specifically to deal with "layout" mode (the word layout used loosely for this example). Once in that mode, block placement becomes very clear, as does edit, drag/drop etc. In other words, bundle site editing and layout tasks into a single mode that is made clear once in that mode. I realize this comment is directed towards the other issue, but I'm trying to give an example of how this might be dealt with later which will completely override the discussion happening now because the UX placement might fundamentally change later.

"Who cares where it's located now, get it in there and move on so we can fix the bigger problems at hand"

#18 Certainly there is a greater fix for admin..but we can make other changes, at least for now.

#17 "show hidden blocks" -- would be a great override state for the Block API to produce in the front end theme. Maybe give those "hidden-now-in-display" an opacity visually highlight this ghosting of contexts.

@SKAUGHT OK. Just want to make sure no one gets hung up on the details that most likely will change soon anyway.

Another takeaway was some of the UX features that centered around block placement such as drag'n'drop or on off switches. It's unclear if those would be built out specifically for the block placement or if they are the springboard of core APIs that will handle those things site wide and can be leveraged elsewhere. I'm still trying to figure out if the UX team is throwing a bunch of ideas out there on D8 and figuring out what works to be refined in D9, or if it's being approached from a ground up "we need these UX APIs in place for core to be leveraged everywhere so we can add the UX whistles and bells later." It will help me better formulate any "ideas" I might come up with to stay on point. It "feels" like low hanging fruit is being tackled but maybe I'm looking in the wrong areas.

Not knocking workflow or suggestions. Just trying to understand the mindframe and culture.

@catch, @cilefen, @Cottser, @alexpott, @effulgentsia, and I reviewed the roadmap for Place Block yesterday. Based on the outstanding "Must have" issues listed and not yet addressed by any issues or patches, the module is still in alpha.

As a reminder, this module needs to become stable by 8.4.0-beta1 in six months in order to remain in core.

@xjm- maybe we can discuss what's needed at the NJ camp? I would like to put this on a path to merging into block module if that makes sense.

noting: #2775725: Update throbber icon

if i recall correctly, block place toolbar icon is set not to appear in 'admin theme' as by base design it is for front end theme block placement. so, updating throbber in Seven shouldn't effect block place. only if basic core throbber is updated would it effect the repositioning of #2793207: Fix off-set and goofy white jagged background of AJAX throbber when clicking Place Block

I discussed with tim.plunkett a few weeks ago in NJ

The goal is merge this into the block module rather than keep it as stand alone.

Here's the outline of the plan we agreed:

• Needs a fix for the currently broken destination handling (due to a revert of a prior fix) meaning you land on the wrong page in the end.
• Tim and I discussed a simplest solution of adding a second icon next to or below the plus in regions with > 1 block to allow the blocks to be sorted.
• This requires implementing a single region version (or taking a region filter) for the block sorting page a making sure it works in a modal.
• Need to check with tedbow to make sure we wouldn't be clashing with block visibility module.
• If the settings try gets into core in a way that's useful for this, use that instead of modals.

@pwolanin Does that mean ordering within one region?

@Bojhan - yes, something like the DnD ui we have now but just for a single region.

Updating to new component.

It feels like we are not on track for this with 8.4?

@Bojhan , I have been talking to @tim.plunkett and @nerdstein about this. They have both expressed that they have an interest and time to push so these get stable by 8.4. I also would have time to dedicate to it. Of course others help would be appreciated.

I think we can get this done by 8.4

But it something we have to start making progress on now to make that happen.

Alright, the outstanding issues are quite significant so we need to be aware of our timelines on this.

I caught up with @tim.plunkett briefly and I'm getting myself up to speed with all of this. Most notably this issue: https://www.drupal.org/node/2784495

I'm aware of the timeline and will push for progress ASAP

I think, if order for ^2784495 to be inline that #2784443: Move off-canvas functionality from Settings tray module into drupal.dialog.ajax library so that other modules can use it would need to be commit first..

although, i also wouldn't thing that 4496 should prevent block_place from being integrated to (core) block.module. block_place's functionality has no reliance on outside_in. it is outside_in that creates the 'de-normalized' experience. In that, I would say outside_in is "more experimental" and, again, is that causality loop.

in short, using block_place without outside_in (settings tray) 'works as designed' as it wasn't design to work with the tray in the first place..

-- edit
once these other aspects of outside_in are more ready follow up issues may be more appropriate at that time.

@SKAUGHT re: #35, yes, we need to prioritize getting this module to work independently from settings tray. This mimics my comments found here: https://www.drupal.org/node/2735277#comment-12122789

I've been spending time getting ramped up on this issue. To summarize, we need to address the weighting of blocks to finish the "must have" issues. This appears to be the motivation of both 2791305 (the "must have" issue) and 2735277 (found in comment #14). I am going to test patches in both issues (2791305 and 2735277) to determine the current state, especially with regard to the user testing feedback above.

It would make sense to identify a candidate patch for the next round of user testing and rapidly iterate to hit the deadline. I'm not clear on the process to request user testing of a patch, but I'm happy to move it forward with direction.

I'm not clear on the process to request user testing of a patch, but I'm happy to move it forward with direction.

as with all issues when work is so ready.. changed the ticket STATUS to 'needs review'. anyone d.org user who has marked an issue using the 'follow' button (right column) will get an email and hopefully review the ticket (: this is how the system works. I'll note: if you clearly ask someone else to review it things will move faster

Finally assuming all is good, then a ticket Statues would go to 'Reviewed and tested...'. Adding ISSUES TAGS also help get tickets moved up to the attention of maintainers.

of course, I myself would be happy to review work for getting place block into core.. as i have been involved with it since it began. email me through my d.org account https://www.drupal.org/contact/297907

We will review this at the Issue ideas queue meeting, we need a plan of attack to resolve the issues outlined. This needs to be done in time, to avoid having to remove this.

@Bojhan - I have a proposed plan in which I am testing patches now to determine feasibility.

My high level sense is that #2735277: Let users set the weight of blocks after placing them from place-block does not yet address the desired user interface from the comments above (which I have yet to fully confirm).

The dependency on "outside in" found in #2784495: Normalize block place and outside-in experiences can be easily reverted and would appear to get us closer to the desired outcome with a minor amount of refactoring of the patch I code reviewed. Again, I want to confirm by testing this patch too.

In talking with @tedbow it might be worthwhile having a secondary, follow up issue created to resolve sorting/UI after #2784495: Normalize block place and outside-in experiences -- TBD.

Here are the next steps proposed as I understand them:

1. Remove #2735277: Let users set the weight of blocks after placing them from place-block from this issue's critical path

2. Add #2784495: Normalize block place and outside-in experiences to this issue's critical path and remove "outside in" from the scope of that issue

3. Perform user testing of #2784495: Normalize block place and outside-in experiences and triage thereafter

I'm planning to do more testing this evening to validate.

I left a comment on #2735277-30: Let users set the weight of blocks after placing them from place-block after testing this current "must have" issue. As I suspected in my previous comment, and as my testing confirms, #2784495: Normalize block place and outside-in experiences performs an implementation much closer to that of the desired user interface.

Please see the recent comments in 2784495, most notably #2784495-30: Normalize block place and outside-in experiences, which tests the patch found in comment #29. This applies a drag-and-drop sort that cleanly works with or without Settings Tray. I have marked that issue as "Reviewed and Tested By The Community", described why, and posted videos. It appears to achieve the motivation of the "must have".

With my testing, I'm going to do the following:

1. I am updating the "must have" section of this issue summary to reference 2784495 and not 2735277

2. I am requesting more eyes on 2784495, which can include additional usability testing of the patch found in comment #29

3. I am going to propose closing of 2735277 as a duplicate of 2784495

I want to open up discussion on the outstanding work.

Item 1:
Per @pwolanin's comments above: "adding a second icon next to or below the plus in regions with > 1 block to allow the blocks to be sorted." The work done in 2784495 adds a new block sorting form that takes the region as a parameter. Such a form could be reused with a region-specific button to re-order the blocks in a given region. Such a button could be next to the "+" button to place a block in the region. This basically would deprecate functionality found in the Block Layout page. In terms of priority, I view this as "high" because I would personally find it confusing having to go to the block layout page to manage the placement of existing blocks -- especially when adding a block does not observe the same workflow. I've added this to "Should Have" and will consider filing a separate issue for resolving this.

Item 2:
My opinion on the "trigger" would be to remove the "place block" button altogether and merge the functionality with the "Edit" button in the top left. I see "Edit" more generically than just changing content for specific elements of the page. The Edit operation can imply changing any content on the page, and pages contain blocks. I can see significant usability concerns for the amount of tracing and buttons for both elements and regions blocks can be placed. While the determination of this trigger is a "Must Have", I would suggest that the actual implementation can stagger. The work performed in 2784495, in my opinion, resolves the "Must Have" to primarily stabilize this experimental module. Implementing my recommendation of the trigger will require significant discussion/usability testing that could be a "Should Have" but is more likely a "Could Have" that is capable of being implemented/iterated over time.

@nerdstein thanks for summing up the the issues.

Re #41 item 2
In the last meeting I had with the UX we had decided that there should be a new contextual link on each block that says "reorder blocks"(or similar). This would open the tray with the blocks in that region to be sorted. This way you won't have to click "Place Block" when you actually want to sort. It would also give you the ability to sort blocks outside of placing. I was going to add this functionality to #2784495: Normalize block place and outside-in experiences

Will comment on that issue.

The committers discussed this experimental feature last Thursday. This simple feature is a big usability improvement, since it's pretty much expected functionality for a CMS. It also addresses a key usability problem with Drupal (disconnect between things on a page and manipulating those things on the page) which we've encountered repeatedly, dating back to our very first usability tests in Drupal 6.

Our conclusions:

1. The feature is not yet complete enough to be stable in this release. It needs work to complete the proposed roadmap, to finalize the architecture, and to provide a more seamless UX.
2. The committers agreed that it doesn't make sense for Place Block to remain a separate module since it provides functionality that a site builder would not enable or disable independently.

We want to continue and improve the feature but in its current shape we don’t think it’s useful to make it available through the admin UI. Instead, we'd like to mark the module hidden prior to its 8.4.0-alpha1 deadline (leaving it in the experimental package). This will avoid confusing Drupal users and prevent new sites from enabling the module via the UI. Then, we should re-propose it for core in 8.5.x as a core patch against Block module (with other additions to Settings Tray or other modules where appropriate). This approach should reduce disruption for the ongoing work on this feature and avoid any fatal errors for those sites that helped test it, but also acknowledges that it is not yet production-ready and did not stabilize within the one-year timeframe we proposed for it as an experimental module.

We also need to take into account the impact on sites that already helped test the module when we eventually move the functionality to the Block module. To this end, we should discuss adding hook_help() / hook_requirements() / module description text roughly to the effect of: "thank you for testing Place Block, you should uninstall it now, it will be removed in a future release, go over to drupal.org/node/whatever to follow" (cr. @cilefen). Once we've finalized the feature, we can also consider approaches like having the 8.5.x Block module uninstall Place Block if it's found (suggested by @catch).

Per @tim.plunkett, #2784495: Normalize block place and outside-in experiences is more impactful than its current title describes and will improve the API or make the code make more sense. Based on that, we would probably want that issue to be completed and be a part of whatever patch is proposed for stable core.

If the functionality does not reach a stable state by 8.5.0-alpha1, the Place Block module code should be removed from core at that point and pursued as a feature improvement in the normal core process and/or contrib. Thanks everyone!

Some background context on this decision:

Place Block originally was added before 8.2.0 (along with Settings Tray, Datetime Range, and Content Moderation). At the time, we intended experimental modules to be pre-release code with no stability requirements. After 8.2.0, though, we realized that this could still cause a lot of disruption, so we amended the experimental module policy with this requirement before an experimental module is added:

Wherever possible, extension names, namespaces, plugin IDs, etc. should be valid and match the intended final names, to avoid unnecessary upgrade path issues.

We've realized by going through the experimental module process with this and other modules that this should specifically include whether the functionality is provided as a separate module at all. Place Block was a good test for the experimental module process in this way.

Updating the summary based on the decision.

I certainly agree that the goal has always been to merge it on core block module, so this decision seems a reasonable way forward given where things stand today.

Opened #2898267: Mark Place Block as a hidden module per #43

Was just updating the core experimental modules page. It still says this work is ongoing, but in practice not true. So updated that page for reality. https://www.drupal.org/node/2657056/revisions/view/11033414/11033417

Layout builder superseded this module/functionality so we should not be merging it anymore. See #3062281: Deprecate block_place module for removal in Drupal 9.