Create experimental module for place block on any page feature

This is great to see :) Thanks for working on this!

Great first step/prototype! :)

I was going to say: I'd remove the toolbar changes. I'd just make this always available., but that clearly does not work, since the PoC demo video in Dries' keynote showed "plus icons" to add blocks upon hover, which does not work when using touch.

This beautifully demonstrates what IMHO one of the key problems is: the fact that some regions completely disappear if there are no blocks in them. This screenshot for example clearly shows how problematic that is for the "Highlighted" and "Featured top" regions:

We could fix this for particular themes, but we can't force this on themes, at least not in D8, that'd be a BC break.

There is an existing issue that relates to this #2513520: Add a contextual link to add a block to a region

Should we close that one as a duplicate?

@pwolanin I love the idea but I think it is a little confusing to be directed the main blocks layout page and then have to click "Back to Site" to see the block in place. Especially if you were new to Drupal.

What if changed the workflow to

1. Click "Place Block" in toolbar
2. Page reload with "Place Block" links in each region
3. Click "Place Block" in a region
4. Select Block in modal
5. 2nd modal: Drag and drop to re-order block in relation to only blocks that appear in same region
6. Click "Save Blocks" in modal
7. Redirected to original page with new block visible

Step #5 would look something like

Starting from step 5 it would be different from existing steps. I think since this module idea seems to be target at the new comer to make it easier to know how to get a block on the page it would be nice if they quickly saw it on the page they originally were on without having to see the main blocks layout page.

this is in overlay modal in bartik, safari 9. vertical tabs show css break. this will be a basic issue in many themes as inheritances collide.

if http://caniuse.com/#feat=style-scoped can be added to the modal it would help.

<style scoped>
.overlay .vertical-tab li a {
  position:relative;
}
</style>

(just a random example)

EDIT
----------------
.vertical-tabs__menu-item {left:230px}
seems to fix this for each li tag

Re #17, shouldn't need additional CSS, I'm guessing something just isn't being loaded.

Re #16, I think what @tedbow proposes is a good second step, but for the initial flow I'd probably just skip the reordering bit completely, and just have it added to the top or bottom of the region, wherever the button is. Then we can iterate on other ideas for reordering from the front end in general.

this is NOT the vertical tabs issue, but for the yellow bar cutoff. tabs issue is not clear.

should be tested against a variety of themes.

Ok here is a patch for my suggestion in #16. without the re-ordering as @tim.plunkett suggested.

only diff from #20:
This moves link into demo-block header, which is more similar to to block layout page. Also gives better spacer for Trobber gif. overall more compact on page.

sorry, i missed adding the composer.json change.

@SKAUGHT, can you please provide interdiffs for future changes?

I'm attaching one for the changes between #20 and #24.

Here are some minor tweaks to things to bring it up to core standards.

The feadmin module also allows for dragging blocks from a sidebar onto the page into both existing and non-existing (Edit: Currently occupied by a block v empty) regions. Not the same form of interactivity as the modal, and much more dependent on having a mouse. I would think this MVP could potentially be a better solution on tablets and mobile. NTM it is much less complex than the contrib module mentioned.

#27. i had that thought as well.

I think one of the general concerns with feadmin (and Panels) using drop and drag is the difficulty to make accessible. where as this a smaller starting point still will be more UX/a11y friendly. A drop and drag component should come next, not first. @progressive enhancement.

edit
---
i've cleaning looked at feadmin (currently rc5). yes, cool but visually jumpy in this current state. certainly lacks degrade. uses it's own message notification popup (screen bottom). doesn't seem to let you add new blocks, just move around current context. not mobile friendly.

#32 Agreed. Definitely not calling for adding JS or Drag and Drop to this patch. Just wanted to ensure everyone working on it was aware of other solutions coming out of contrib.

edit, because I now see the #32 edit:
---

While feadmin does allow for adding blocks (check the "blocks" checkbox in its sidebar, unfold the list of blocks, drag one onto a region) it is an interactivity pattern that again relies on Drag and Drop, which is not a11y friendly.

i was always fond of https://www.drupal.org/project/bud (has d8 dev, i haven't looked at this in a while)

Additionally, re: #32, Panels has made great strides towards a11y/mobile friendly interactivity via the Panels IPE. Again, a much more robust solution. But the blanket statement that Panels != a11y should be alleviated a bit by this video that was created recently.

https://www.youtube.com/watch?v=WLcXgJXxU2E&feature=youtu.be

random thoughts:

certainly is nice to see the +/- in panels. but certainly that not the only a11y issue against panels. The whole drawer up idea lends to accessibility/usability/mobileUX concerns. i haven't been keeping up on that corner of things myself lately. when it's closer to an RC, it'll be nice too. Certainly panels is still a mouse-first/desktop site building tool. @peace with panels!! amen.

With/when layouts plugin get into core, and i'll have to assume that work on layout [builder] gets picked back up.

It'll be very interesting to see how drop 'n drag will be introduced. of course, it will happen somehow.

• https://www.drupal.org/node/1840500
• https://www.drupal.org/project/empty_page
• https://www.drupal.org/project/page_manager

i've made an icon for the toolbar. icons turns white when active.

#13 missing regions if empty.

also missing: "A place for JavaScript status messages".
As feadmin modules demonstrates by making their own solution (or even, panels should have an action complete notice) a common approach from core is needed for ajax messeage, as will be for drop 'n drag event notices.

adding link: https://www.drupal.org/sandbox/phenaproxima/2237839 i haven't tested yet myself.

Can you open a separate issue to discuss other solutions or future iterations? It'd be nice to keep this issue on track.

#42++ should move all of this stuff about other modules into some kind of meta issue or book page.

of course, the most basic aspects of this ticket request are now complete.

i'm not otherwise aware of how/where to open a book page -- if my account can? sorry, i'm not familiar with that process.

That toggle and text change is still there. Now with the addition of a lighter coloured custom icon.

OFF mode

ON mode

Hi all!
I just wanted to add some thoughts on what has been said here, mainly regarding comparison with feadmin module.

I just did feadmin module on a couple of days when I had time, to try-out Dries inside-out approach. It is a POC and does not aimed to be usable yet. Unfortunately I did not had time yet to explore it as much as I would like to. Here are some comments though.

@SKAUGHT: from your comment #32 ( saying "visually jumpy") I suppose you tried rc5, not latest dev, since I came up with the same conclusion and another approach.
@brantwynn: Indeed, it relies to much on mouse interaction to be mobile friendly. The whole point is that this module is about administering Drupal from front, not just blocks. It took this mouse interaction as an assertion to explore as discussed with @yoroy on IRC. But this approach highlighted more issues then it solved indeed.

I guess it is wrong to compare this module to feadmin. The purpose is different for me. Here, I see this module as a replacement for admin/structure/block/demo/bartik. This in the same way, let's you visualize your theme region, plus let's you add blocks in it like admin/structure/block page does. In the same way, it also takes a full page reload to visualize the regions.

On the other end, feadmin aims to explore a way to define ONE interaction scheme to administer (ie add, but also edit, move, delete) VARIOUS core concepts, such as blocks, but also menu items, fields, etc... Of course, the drag&drop interaction scheme it currently offers is bad in many ways, but I don't think it serves the same purpose (though I could be wrong). I would be more then happy to expand on the goals of feadmin, the challenge it hightlights, like the necessity of #77245: Provide a common API for displaying JavaScript messages and others, but I guess it is not the proper issue to do so !

That being said, once more I love this, as a replacement or an extension of admin/structure/block/demo/bartik.

If you intend however to complete this by adding solutions to truly administer your blocks, then I would love to combine this with feadmin, for it could thus become one tool available for feadmin among the others. Moreover, this could be made as a global interaction scheme to let others (including other feadmin plugins) to also define similar tools for other concepts, once more, menu items, fields, etc...

That being said, once more I love this, as a replacement or an extension of admin/structure/block/demo/bartik.

just remember this already works with ANY theme. i've tested with zircon, paxton, drupal8_zymphonies_theme & adminimal_theme (just as random themes to try) and works well. some minor issues depending on that themes style base... but to be expected.

certainly, more flexibility will come as a roadmap for this progresses. I think the key to remember is to keep it progressively enhanced. especially with all conversations/issues about adding in a JS framework (bigpipe, refresh-less).. and whatever/when a revamp of the theme system will probably occur. [personally, i think the Drupal prototype and Drupal.behaviors need to be promoted differently.. we already have a steady base.]

at this time, this ticket has a limited scope.. and that good. start small.

next to step would be (which then basically is feadmin):

• order blocks in place.
• move blocks between regions. (*when to clone to a new block)

but the think to keep in mind is what other contexts that block is used in. for most Site Admin, it's not clear that *'this block is here an this content type' and 'another block variant is used on another' so that will be the issue in working with sites with many landing pages, deeply nested pages, many block everywhere from custom blocks, programmatic blocks, view block, panels... and layouts coming..

#50 point 2. i'm not sure what your testing (or just looking directly at code..) patch in #38 does return to original destination. that link is to call the block admin page in the modal. that is correct. and links will degrade to standard page loads without JS.

of course, the module does not currently 'set block to this page' directly. but the for block visibility are steps in the general workflow from that point. IMO: it should be as such. The user will have a better since of what blocks are where on their site and if they are want to deal with paths and wildcards, node id's vs content types. Over assuming they want it 'only on this page'. what if it was a multilingual site? only this language?? logic spiral.

as for point 1: perhaps would should point this out to Wim.

re: vertical tabs. perhaps increasing the breakpoint for vertical tabs would help. secondly, making the modal narrower (i'm in favour of changing the breakpoint.)
As #17 moving left only fixes bartik -- then breaks every other theme.

i noticed the edit getting triggered. i took a quick look through edit but couldn't see why that would be. it would make since for Toolbar to support right-side/left-side items. This module as a POC, left if fine, but right would be better. ):

otherwise, current patch seem good. However, we do need a vertical tab fix before it can move on.

i'm a strong fan of 'on the right' -- also has rtl to float:left
also, adds overall gradient to active state, adjusts color (i had used the color from the second line icons, oops). and removes 'Generator: illustrator' comment from .svg's

#59 could it be: it's switching to Seven because the Block Layout is an admin route. thus defaults to using Seven.

hiding old files

Migrate test failure flux continues.

Works great!

There's a few things we can simplify though.

The "place block" link in toolbar is an anti-pattern. Left-hand side stuff in toolbar is navigation not page manipulation. There are at least two other ways to handle this:
Show "place blocks" links when edit is toggled on
Follow Preston So's suggestion of having a "build" toggle next to the "edit" toggle, and show place blocks links when that is toggled on
With either of these we can also show the "place block" links on hover even when "edit" or "build" is not toggled on.

It is not difficult to accomplish this, I hacked it quickly together in chrome inspector with this CSS:

.demo-block { /* altered */
    /* background: #ffff66; */
    /* border: 1px dotted #9f9e00; */
    /* color: #000; */
    /* font: 90% "Lucida Grande","Lucida Sans Unicode",sans-serif; */
    /* margin: 5px; */
    padding: 0;
    text-align: center;
    text-shadow: none;
    height: 0;
    overflow: hidden;
    transition: all 1s;
 }

 .region:hover > .demo-block { /* added */
    height: 50px;
    min-height: 0px;
    overflow: visible;
}

This also took out a lot of the extraneous styling from "demonstrate regions" which IMO should be disabled if this module is enabled.

I would also suggest that we could further simplify the design by putting the region name in the button eg. [Place block in header]

Lastly, the "add custom block" link in the modal should bring the user back to the place block modal and then to the page they started on when the custom block has been created. If that's not possible, then the link should not be there.

we can't assume Edit will be active to be used to trigger Place Block. Edit has already established an (anti-)pattern. it has made it 'right side changes things on this page' --- sorry, also patch on #60 moves back to right side.
Aside: I would hope this module is more directly included into the full Block module.

I'm not sure 'build' is as clear a term.. we're not building Views... not building Layouts... not building entities nor forms. we are just placing blocks.

my own concern (form your video clip) is any time we 'hide' something and hope a user will do something find it..it's just not usable. secondly, using css hover it won't be mobile/table responsive building friendly. of course JS could do it, none the less we're just hiding things.

putting the region name in the button eg. [Place block in header]

i do like the idea. but region name are in code and not translatable. And often region names are 'strange' (see below) As this is now, the name then the btn is as the /admin/structure/block is... so it's familiar.

add custom block...

i'm not found it that button, but at this time this modules is simply calling the 'choose block' utility that already exists in core. But really, a User may just want to place a custom block.. we shouldn't limit that ability here.

  panel_first_1: 'Panel first col 1'
  panel_second_1: 'Panel second col 1'
  panel_second_2: 'Panel second col 2'
  panel_second_3: 'Panel second col 3'
  panel_second_4: 'Panel second col 4'

We discussed this patch over the UX-team hours (webchick, yoroy, cosmicdreams, bojhan, tim, gabor).

During this review we had the following understanding:

Out of scope
The space that this patch is trying to resolve is riddled with huge challenges, that deserve a in-depth design process to be resolved. There has already been a lot of great thinking on this from the in-context, ipe, panels, etc. approaches.

For this patch to continue without being derailed we believe, some challenges need to be descoped:

• Do not add a "add block" to contextual links. This opens a can of worms, with not being able to move the block form the dialog, and technically not being able to trigger contextual links on "empty regions". While valuable this should be explored in a separate issue.
• Do not redesign the "toolbar" to have a new concept for triggering edit modes (as suggested by Dom and Kevin). This is a core challenge, but also incredibly hard to resolve easily - requiring more design exploration to fit other "modes".
• Do not support the re-ordering. This will also open a can of worms, as we do not have an existing pattern for this and will likely require much design detail work to fit well.

Removing this from the scope allows us to make a first step of bringing in-context interactions into core. We obviously need to iron out many challenges, but the point of experimental modules is being able to do this in core.

What's needed for this to become a experimental module
We are already quite close to including this in core. The patch needs additional front-end and back-end review, to go in - but the bigger concepts have reached agreement.

• Fix the Bartik dialog issue with a gray pane overlapping visibility settings
• Clearly outline the follow-up for solving the larger "edit modes" trigger

patch on #60 moves back to right side.

Much better

I'm not sure 'build' is as clear a term.. we're not building Views... not building Layouts... not building entities nor forms. we are just placing blocks.

We are just placing blocks *now* but I think we should build this so that it could gracefully scale up into a modal state for handling any block and layout related tasks in-place. I can see that even in that case "build" might not be right but I don't have any other ideas just yet.

my own concern (form your video clip) is any time we 'hide' something and hope a user will do something find it..it's just not usable. secondly, using css hover it won't be mobile/table responsive building friendly. of course JS could do it, none the less we're just hiding things.

Of course. My assumption was that we would treat the same as we do with contrextual links: show on hover but toggle on with the "build" toggle.

Ideally I'd like the "place" buttons to be just plus buttons with no text at all like in the mockups I made for Dries blog post, but I feel like that may need to be a later addition. Perhaps we can remove region names altogether since the region name will be in the modal anyway?

i do like the idea. but region name are in code and not translatable.

This is essentially a big part of the problem. The region names are a construct that the user should not need if they have a way to simply "put the thing here."

a User may just want to place a custom block.. we shouldn't limit that ability here.

I agree, but we can't then strand them back in the block UI to find their own way back. :)

#2513520: Add a contextual link to add a block to a region for exploring the use of contextual links to provide the 'add block' option

@bojhan

That assessment of scope sounds right to me. I *think* that my comment above fits within scope but let me know if you agree.

Adding another issue for the designing global view/edit/build toggle.

@Kevin: Removing the region names sounds good, it's not very useful information because you can add in place, so the location is always “Right here” :)

Add block buttons are ok for now, it's consistent with current blocks page. Plus-icons could be an option, maybe explore that in #2513520: Add a contextual link to add a block to a region.

@tkoleary
i was just re-looking over the add custom block action link. Even on the base Block Layout page; it is very odd that once you hit 'place block' we then get the Action link to add custom..user adds title/body..another screen where user sets vertical tabs -- then again is asked what region to place custom block. Even though they already selected a region on step 1.

/core/modules/block/src/Controller/BlockLibraryController.php 
lines 94-96

I am now thinking this should just be removed for both the Block Layout overlay and this module. It's true, it works poorly across the board.

#68 address vertical-tab position while in modal, as an approach.

#2727523: Bartik's '.header .demo-block' needlessly sets width should be reviewed/committed as well. this issue is outstanding apart from this ticket.

this includes an actual .library.yml to add css for block-place. ensures 'yellow background' of region name on all themes. also prevents button wrapping seen in some breakpoints.

button wrap example:

triggering test bot

@skaught

i was just re-looking over the add custom block action link...

Yes, it is sub optimal in all cases.

#68 address vertical-tab position while in modal, as an approach.

Awesome. I had noticed that bug but forgot to mention.

this includes an actual .library.yml to add css for block-place. ensures 'yellow background' of region name on all themes.

God that yellow background is screaming at me. If we are going to leave it in we should tone it down a bit.

@bojhan Isn't there a softer yellow in the Seven style guide?

@SKAUGHT

If I want to quickly spin this up in simplytest.me which patches should I include?

Yes, it is sub optimal in all cases.

ticket opened, tim has already suggested fixing over killing.. so we're see as it goes.

that yellow background is screaming at me

it is the yellow from block.admin itself -- in various themes it will, at least, stand apart (: but, as a developer i'm happy to stand out of color discussions.

@kevin There is, I think this is adjusted to Bartik though.

sorry, pre wasn't firm enough!

#82
block.admin and bartik (demo-block.css) are using the same yellow: ffff66.

@pwolanin #84
vertical tabs issue only occurs with bartik, other contrib themes i've tested are fine!

fail note: 77 was cancelled.

@tkoleary #80
-- all my patches are whole commits. please now use #83. [i promise i won't add else anything for..at least now (: ]

i'm not sure why this test is failing. i'll see if i can figure it out later today.. i think is just need to add an override library to Stable.

@SKAUGHT

A couple of notes on the toggle.

1. The "cancel place block" state is an anti-pattern to the way "edit" works (Edit does not say "stop editing" when toggled on). The text should not change just the visual state of the button.
2. The icon does not provide affordance to the action of placing a block. Below is an icon I created that encompasses the concepts of "block", "add", and "drop zone" which all offer cues to the idea that you are adding a block to the page in a particular area or zone. Use of the plus in the icon negates the need for "place" and since the modal offers both "add new" and "place existing" there's no disambiguation problem.
3. Additionally the toggles for edit and place need to be mutually exclusive or else the page will be too confusing to parse.

Icon and state:

I can provide SVGs if we like this.

When blocks are being placed the affordances for the regions are confusing. The fact that the buttons are inside the div that contains the region name suggests that what is "in the yellow area" is the region, which is not the case.

We need to clearly delineate the regions with the same type of wrapping affordance that we use in Edit module for fields (in fact we should just use the same CSS).

Current patch

Suggested

We will probably also need to put a background just on the region name so it is visible in any theme.

perhaps a dashed grey line -- blue is too much Drupal/bartik centric, this is for all themes. Actually, this might be better for future, once drag-ordering becomes a thing.

also to note: once we get into adding borders, we could start breaking the styling/layout of those actual blocks. creating other visual disturbances while in 'place mode'

• i'm fine with removing 'cancel place black' phase change. It was inherited from earlier patches..i wasn't really liking it either.
• The icon: then shouldn't edit also use this type of generic action icon? otherwise, all other icon are pictorial representation of their item.. A plus sign jumps far from that, and all other toolbar icons. I made the lego-like icon as it was the simplest 2d image representing block-building, which i think i more generally friendly, as represents blocks.. whereas Edit's pencil represents content..

from Bojhan #68

Clearly outline the follow-up for solving the larger "edit modes" trigger

for both these i think this is what he is talking about. in so, shouldn't Edit's icon reflect on/off status?? -- this is a larger discussion.

In the modal the focus is in the wrong place and the order of elements does not match the 80% use case (place).

The focus should be on filter (see below). I *think* the tabbing manager can be used to change the focus with the aria role data attribute. The "add custom block" button can be simply floated right (see below) to make it a secondary read.

Current patch

Proposed

#95
yes.. however this should be an issue against Block.module itself -- as we're just re-implementing one controller.

@SKAUGHT

perhaps a dashed grey line -- blue is too much Drupal/bartik centric, this is for all themes.

The solid blue outline style from fields in quick edit is what I was suggesting for outlining regions. That color, weight and other CSS—like the fact that it uses box shadow so that it does not displace other items in flow—were all very carefully considered and tested for the express purpose of working well with any theme. Let's not re-invent that wheel. :)

The icon: then shouldn't edit also use this type of generic action icon?

It is not a "generic" action icon. Generic plus (add) icons are generally in circles:

The dotted line square with plus is very specifically designed to echo a drop zone which almost always has a dashed border, and always suggests "a place to add something to a page" which is what the user is doing here.

I could perhaps make it more clear by adding a radius to the corners of the square which is also a common affordance.

my general worry is a plus sign doesn't flow into the rest of the toolbar icons.



and when in a mobile viewport -- it would just be + sign -- which looses all context.

The suggestion in #93 does also re-use an existing core pattern, which is Quick Edit module. If that's by chance fairly easy to do, that would look approximately 786 billion times more awesome. If it's not, it could be done as a follow-up though. I agree that I'd like to get this in sooner and have more opportunities to iterate on it over time rather than make it 100% in one go.

+1 to Angie.

Even with the suggestions above this is *very far* from the vision in Dries's keynote, has already been carefully scoped down by the UX team and is very much an MVP.

I think we need to clarify, though, that an experimental module is not something that is "built without design" then committed to core for live user testing, it should be well designed, but Minimally Viable. The lean loop is "build, measure, learn" not "learn, measure, build." Everything we do in an experiment should be a well considered hypothesis about how the module will be used that's validated by users who install it. If we just push things out without really rethinking them we squander that learning opportunity.

Anyway we're not talking about massive changes here. All of the above involve very few lines of code, mostly CSS, and I've already created the SVG for the icon.

@SKAUGHT

Revised icon with radius corners.

looses all context.

The same could be said of many of the icons, including the lego block. The assumption is that the user on mobile is also a desktop user and there's a level of accumulated memory.

only change in this version: remove 'close' from 'close place block'.

more importantly:
i'm stabbing at this test error. i can't get this test to run even before patching for this on my local machine -- i'm having trouble running certain tests. This makes no sense to me, as this test is matching twig templates, which there is no override in Stable, as we have no templates... i've added in a library override in Stable, maybe it is matching libraries and i don't see it.

arggh. forgot to check own test. luckily the Stable side is clear?

sorry, late in day error ):
also retesting #83

my change in Stable's library override proves to be a good guess.
Cheers.

Both design suggestions of "borders around the whole region instead of yellow bars on top" and the updated icon are worthwhile to pursue within the scope of this issue. The borders have a working implementation as pointed out in #96, the icon is mostly replacing an existing graphic, no?

My own very loose rule of thumb is that ±150 comments is ok for a single issue. If we go too far beyond that we're not focussed enough. I don't know how far along the actual code is (good enough for experimental?). If the code is as good as done then it would be good to try and incorporate the proposed design changes. Kevin is right in that we want to test a deliberate and considered design instead of a bare functional implementation.

Also: @SKAUGHT thanks for working on this and pushing it forward, very much appreciated!

Adding a section to the issue summary outlining the required followups after commit as experimental.

#110 --re: icons. yes, replacing 2sets of active/inactive icons would do the trick.

as for a shift toward bordering/outline. I'ld still say keep it grey (wireframey) as yes, edit is using blue, but then with block place and edit both On -- then thats a whole lot of blue lines. and again, blue is very Drupaly...be not afraid to move away form it! IMO, most contrib and custom project themes will flow well with grey's. A/B test away!

See #92

Additionally the toggles for edit and place need to be mutually exclusive or else the page will be too confusing to parse.

Edit and Block placement would never be on at the same time. Regardless, lets not get hung up on the color of borders please :-)

@SKAUGHT

but then with block place and edit both On --

As I suggested in #92 having both edit and place block active at once will be *really* confusing to users and I strongly advise that they be mutually exclusive.

If we do that then there is no need to disambiguate the borders of regions and fields with color. In fact here is a strong argument to be made that they should be the same so that the user has a consistent experience of "blue outlines signify areas that have been 'activated' for editing" not to mention the fact that we don't need to do any additional user or a11y testing because we already have done this for the blue borders from quickedit.

Just realized Roy said essentially the same thing. :)

this intermix of tasks is going to happen. Of course, don't underestimate, nor overpredict the User.

Edit does toggle on to 'show context links' in its own. so it does happen. then, the users temptation to mix activities is real.

i have run though this in my own testing.

i spend a bit of time this morn playing with the border idea too. and after playing with various contrib themes i still do feel the yellow bar is clearer to use than bordering regions.

please run your models with other contrib themes. bartik isn't even enough to evaluate

i had not seen the keynote till last night..so now that i've seen dries's demo i get the hide/reveal in hover concept source. i do still believe hiding things is a negitive. i think thats why Edit forces display of context links.. we could just let people hover about -- but its not clear, even to those who are visually capable --desktop-- sitebuilders

Edit does toggle on to 'show context links' in its own. so it does happen. then, the users temptation to mix activities is real.

What I am saying is that we should *explicitly* force that not to happen by making the action of toggling on "blocks" also toggle off "edit." I suspect that what you are talking about is behavior that happens when you use contextual links

without

toggling it on. eg.

1. I toggle on "blocks"
2. I hover over a contextual link and click quick edit
3. Now I see outlines for both block placement and fields

This would, of course, be bad and I think it should also be prevented. To do that we would need to disable contextual links completely when "blocks" is toggled on, which I think is a reasonable approach.

This also permits us to deal with the labels in a way that is more in line with the affordances for edit. For example:

If contextual links are disabled now we can put region labels in their place! What's more we could also position them absolute (as the contextual links are) and then not "push apart" the theme in such an awkward way eg.

Here's my CSS from chrome inspector:

/* first remove button classes from "place block" link */
/* then change styles for demo block */

.demo-block {
    background: #fff;
    color: #555;
    border: 1px solid #ddd;
    font: 80% "Lucida Grande","Lucida Sans Unicode",sans-serif;
    margin: 5px;
    z-index: 500;
    padding-right: 8px;
    padding-left: 8px;
    text-shadow: none;
    box-shadow: 2px 1px 1px rgba(0, 0, 0, 0.15);
    border-radius: 50px;
    position: absolute;
    right: 0;
}

Of course I would like to see the blue borders as well, but with the above approach I think you might only need to see them on hover and focus which would be much less obtrusive while still instructive about where the block will go.

@SKAUGHT

i had not seen the keynote till last night..so now that i've seen dries's demo i get the hide/reveal in hover concept source. i do still believe hiding things is a negitive. i think thats why Edit forces display of context links.. we could just let people hover about -- but its not clear, even to those who are visually capable --desktop-- sitebuilders

This was already de-scoped by UX team IIRC.

your designing for implementing in Bartik when getting into float the region name and button to the right.

attaching my screen grabs of various contrib themes 1) with yellow bar 2) outlined for each. (toolbar is disabled just so i can use a dumb screen grab tool)

missed one Space. which is also a good example of a dark theme.

#118 --just that, i now that i've seen the presentation. of course, it's been a view all of us have (:

@SKAUGHT

Ah, now I see what you mean. The problem there is that the styles are not sufficiently comprehensive and namespaced to wall them off from theme styles bleeding through.

In quickedit we went to a lot of trouble to do this and you will find (in most cases) that the contextual link and quickedit toolbar styling does not change from theme to theme. That is what we should do here as well, existing contextual link styling providing a very good starting point.

Here's the contextual link styling for example. Notice that it uses .trigger and not .button which would expose it to inheritance of any number of attributes from the front-end theme's .button styles as has happened in the examples you list above.

.contextual .trigger {
    background-attachment: scroll;
    background-color: #fff;
    border: 1px solid #ccc;
    border-radius: 13px;
    float: right;
    margin: 0;
    overflow: hidden;
    padding: 0 2px;
    position: relative;
    right: 6px;
    cursor: pointer;
}

As far as "float" is concerned, the second screenshot, which is my recommendation is using position; absolute; right; 0; not float, which would be more unpredictable as you suggest.

i don't know Edit's codebase/js well enough to jump on to that.

@wimleers could you weigh in on this?

sufficiently comprehensive and namespaced

we all wait for Web Components and browsers to support Scoped CSS

we all wait for Web Components and browsers to support Scoped CSS

Indeed. :)

Meanwhile we take baby steps in that direction #2702061: Unify & simplify render & theme system: component-based rendering (enables pattern library, style guides, interface previews, client-side re-rendering)

In order to reduce the visual wording of region names as seen in contrib themes especially in breakpoints, this removes the region name previous to the Place Block button and sets it as visually-hidden phrase (and add title attribute with same phrase):
IE: Place block<span class="visually-hidden"> in the <em class="placeholder">Highlighted</em> region</span>

test changed to check for div[class] / a['Place block' ] // em[%region_name]

Also adds access check to remove from toolbar tab from admin paths and all natural block demo pages, as the intent is for public spaces in a project (like Edit's tab).

update summary image

+++ b/core/modules/block_place/block_place.module
@@ -48,16 +49,23 @@ function block_place_toolbar() {
+  $route_name = \Drupal::request()->get(RouteObjectInterface::ROUTE_NAME);
+  $admin_demo = ($route_name == 'block.admin_demo') ? TRUE : FALSE;

Should just be $admin_demo = \Drupal::routeMatch()->getRouteName() === 'block.admin_demo';

cheers tim. changed.
also touches up small css whitespace.

sorry, i've just realize i've messed up the all numbers on the interdiff names today. they are paired correctly

Looking at #2566831: Remove user.icons.admin library from core CSS I suppose css should live in stable but library defined in module

#131
IMO hiding the region names
a. works better in mobile viewports (especially with contrib themes where names get odd/long)
b. with the assumption the User 'just wants to place a block' he doesn't really care what a theme calls that region. Even, he already knows

The css location is just kinda 'like the others are'. ie: Editor is like this too, agmonst others. also the icon are in /core/misc for that same reason. yes, a bad druaplism.

the css that's in the actually module is there as the 'correct base sample you would override'. it is then picked up in Stark to carry forward.

#132
i've come across several issue about icon/css/js locations like this over time..

the problem is, these sort of location issues are common in core. i'm not sure if we should worry about straightnen them all out in this module.

 core/misc/icons/bebebe/place-block.svg             |  14 +++
 core/misc/icons/ffffff/place-block.svg             |  14 +++
 .../src/Controller/BlockLibraryController.php      |   4 +
...
 core/modules/toolbar/css/toolbar.icons.theme.css   |   6 +
 .../css/components/vertical-tabs.component.css     |   5 +
 core/themes/stable/css/block_place/block-place.css |   9 ++
 .../stable/css/toolbar/toolbar.icons.theme.css     |  16 +++
 .../images/core/icons/bebebe/place-block.svg       |  14 +++
 .../images/core/icons/ffffff/place-block.svg       |  14 +++
 core/themes/stable/stable.info.yml                 |   4 +

This should really only be adding files, and changing composer.json
The BlockLibraryController change should ideally be in a standalone issue with dedicated test coverage

This thing really works, so cool! :-)

Looks like we can start to move from building into shipping mode:

- @pwolanin and @tim.plunkett have been reviewing already, looks like we're almost at the "good enough for now" state.
- Make sure the necessary followup issues are opened and defined
- Get committer feedback on product, release and framework (I remember talking with Alex Pott in New Orleans about name-spacing, i.e. will this module be the container for more user facing block handling features?)

it's just that the css & icon locations are shared like this. the css is in toolbar.. and the icons are in misc

bartik does inherit from stable. off hand, Stable has this same type of override thing with block css..and i believe that theme developers are encouraged
to work from stable.. no?

in my testing with other
contib theme adding to Stable
was beneficial to maintain the expected look, even though it is very simple at this point

i cant review your patch right now..i happen to be in moving right now.

There are now two #attached in the patch (which is correct). The other was in PlaceBlockPageVariant::build().

@pwolanin

What do others think? Maybe that's just because I'm use to thinking about the regions as named.

To the user who wants to place a block the region names are largely irrelevant as long as they can clearly see the area that the region encompasses. This is why the outlines are important.

Please forgive the size of this patch, I did things in the wrong order (not used to rolling patches). I didn't commit after applying the patch from 138 so this one has all the tests in it as well.

Key things I did were:

1. Created a new class for the container so (place-block-region) so it's CSS doesn't affect the region demo page.
2. Added the new SVG icons
3. Removed the overriding CSS from Stable
4. Added all the new affordances for dotted border and hover effects to match quickedit

:/ Failed in simplytest.me. Rerolling

I had to test the patch twice before I found the place blocks button on the toolbar. I do really really like this but it needs to have some detailed instructions because I can see a lot of people getting lost and thinking this just doesn't work.

I think this one's cleaner.

Ok let's try this again.

Fixed broken svg link in toolbar

@pwolanin

The last one (152) is working now

@ipwa

I had to test the patch twice before I found the place blocks button on the toolbar. I do really really like this but it needs to have some detailed instructions because I can see a lot of people getting lost and thinking this just doesn't work.

True. Quickedit has the same issue, but:

1. it's a lot more discoverable than finding it under admin/structure/block-layout/place-block
2. Once the user discovers it the first time they know where it is

Your comment points more to the fact that there's no general orientation tour of the front page when you install. But I think there is an issue to create one.

Setting these to needs review to trigger tests

This is exactly what we should not be doing at 150 comments in :-(

@tkoleary I fully agree with you that this needs a lot of design love still and your changes make it look a lot better, but we're also opening up another can of CSS worms to review it seems.

Lets keep in mind that committing this patch does not equal shipping the feature (to the larger audience at least). We have until october to get it right. It's super uncomfortable for many of us to go and commit this minimal, not-even-sure-it's-viable piece of product, but if we start polishing this now, in here, we're giving in to our old (current) mindset of polishing before publishing and that's exactly the thing we want to change. (I know design is more than polish of course, but what can you do if coders start patching quicker than we can design :-)

Lets make sure the right followups are in place, that it is clear they are required for this experimental module to graduate to core for real, etc. but for this issue here, lets only do the things necessary to get the raw functionality in.

If these latest CSS changes can be whipped into good enough shape quickly, all the better, but I'd rather be uncomfortable with the intial commit of this and start a fresh in a new issue than stretching out this issue.

@yoroy, thank you, that is exactly what I've been hoping to post on this issue, but explained much more effectively. :)

This is the initial prototype of an experimental module. Design work is required for the prototype to become shippable. However, it should happen after this prototyping issue.

So we need to halt the polishing of the UI here, narrow the scope of the patch, and create a plan of followups.

Spun off #2739075: [plan] Make Place Blocks module functionality part of the Block module (etc.) as a starting point to deal with required/desired follow-ups from this issue.

Nice work everyone. I just want to leave a little note that Drupal usually use following pattern v/adj noun i.e. quickedit, responsive_image, automated_cron, basic_auth and maybe block_content so I think it should be place block not block place.

@yoroy

If these latest CSS changes can be whipped into good enough shape quickly, all the better, but I'd rather be uncomfortable with the intial commit of this and start a fresh in a new issue than stretching out this issue.

Ok. Let's RTBC this then and put the CSS in a follow up.

1. +++ b/core/modules/block/src/Controller/BlockLibraryController.php
   @@ -107,6 +107,7 @@ public function listBlocks(Request $request, $theme) {
   +    $destination = $request->query->get('destination');
   
   @@ -132,6 +133,9 @@ public function listBlocks(Request $request, $theme) {
   +      if ($destination) {
   +        $links['add']['query']['destination'] = $destination;
   +      }
   

   This change should likely go in a dedicated issue that blocks this one. But even if that is determined to be too strict, this still needs explicit test coverage alongside the change.

2. +++ b/core/themes/bartik/css/components/vertical-tabs.component.css
   @@ -14,3 +14,8 @@
   +/* Fix vertical tabs rendered in a dialog from the main theme. */
   +.ui-dialog .vertical-tabs__menu li {
   +  left: 230px;
   +}
   

   I don't know if this is how we usually document CSS. But either way, this needs signoff from a Bartik or CSS maintainer.

3. +++ b/core/themes/stable/stable.info.yml
   @@ -13,6 +13,15 @@ libraries-override:
   +  block_place/drupal.block_place:
   +    css:
   +      theme:
   +        css/block-place.css: css/block_place/block-place.css
   +  block_place/drupal.block_place.icons:
   +    css:
   +      theme:
   +        css/block-place.icons.theme.css: css/block_place/block-place.icons.theme.css
   

   Why are we changing Stable here?