Reduce visual clutter of Place Block module

Hi! I'm going to do a little bit of this at the DrupalCorn Sprint:

• Get rid of the yellow
• Change out the Place Block text for a "new" "plus" icon

I have a few questions/concerns about my very basic changes.

1. I'm making it transparent white on hover - but I think that could be a problem with actual white backgrounded regions
2. I don't know if there is a standard for how the colors/transparency are used
3. Finally, the plus button, I copied the core/misc/icons/bebebe/ex.svg and rotated - the new svg will be in the core/modules/block_place/icons/bebebe/

Not done, but I am in the middle of the CSS/button.

#2784495: Normalize block place and outside-in experiences might be a duplicate?

I've updated the css to use the outside-in dashed outlines, moved "Place block" into visually-hidden, and added two plus images, #bebebe to match the mockups, and black for the hover effect.

Here's a gif of the resulting interaction:

I think the hover effect should have some kind of boarder around the whole region as we have in HEAD now, but looking for feedback from @tkoleary

Interesting. Moving from the Modal/overlay to the tray will be making Place Black dependent on Outside In

@DyanneNova

Looks good. My only comment would be to match the size, color and hover effects of contextual links so there's a consistent experience when both are visible, which will happen in outside-in edit mode.

I'm even leaning towards positioning them to the right so the user can more easily scan down that edge of the page, but I'd like to hear more opinions on that before we do it.

@skaught

Interesting. Moving from the Modal/overlay to the tray will be making Place Black dependent on Outside In

If I understand correctly outside-in will look for place block and then alter it to use the tray ajax instead of modal. So neither would depend on the other.

@pwolanin

I think the hover effect should have some kind of boarder around the whole region as we have in HEAD now, but looking for feedback from @tkoleary

That's correct (sort of) .region should have a border when place block is toggled on, .place-block-region should have the same background effect on hover that .outside-in-editable has in outsidein module.

@tkoleary #20

more to my thought: the tray should become a core element sooner rather than later; so that it's just another tool OF core for modules to use.

also then, we can focus on ux(breakpoint) and a11y issues of the tray itself.

logic based on 'if this other experimental module is active' is layering complexity when the whole UX tool that the tray adds...is awesome. (:

Changing the modal dialog is out of scope for what we are trying to do in the patch here. That needs to be a follow-up

..scope. (:

Updating tests.

@skaught

more to my thought: the tray should become a core element sooner rather than later; so that it's just another tool OF core for modules to use.

Absolutely.

@pwolanin

Changing the modal dialog is out of scope for what we are trying to do in the patch here. That needs to be a follow-up

Yes. It's already another follow-up issue related to outside-in.

I've standardized the plus button size and changed the plus hover color from black to #787878 to match the pencil hover. There was some confusion here about where to implement the border and hover background color, so I tried a few variations and tested them with @lizzjoy to get a better idea of a content editor's expectations.

Here is an interaction with the region area surrounded by a dashed border, and highlighting the place block area with a background color on hover. In testing, the plus button was difficult to find and then understand. The border seemed to indicate that it related to the current content.

Here is an interaction with the place block area surrounded by a dashed border, and highlighting the region with a background color on hover. In testing, the region background on hover was confusing. Before the region background appeared the plus seemed like the right option, but that changed when the background appeared on the region. That seemed to indicate that the current content would be changed.

Here is an interaction that highlights the plus button, with no region highlight. This was the easiest to understand.

This patch is for the last interaction.

I had a similar concern.
Placing a block may become so easy, ... that people try to use it for content.

The dashed boarders (visual indication), with the plus sign getting louder (growing/changing to higher contrast colors) on hover seems like it is the clearest. With that also, it may be most flexible for different colored backgrounds people have in their theme... if the plus sign has an edge color (A) and a fill color (B) (and the plus sign color same as edge?) so that A and B have high contrast with each other.

Would a block icon with a plus sign in it remind people they are adding blocks?

When did you want accessibility feedback? I have a few thoughts already, but dont want to give them before you are ready.

@DyanneNova user tested these options with me, and I agree with @YesCT that the plus side getting more prominent feels like the most usable thing. Providing a background color on hover suggests to me that the entire area is clickable, whereas having the add button getting larger is nice.

The yellow background option doesn't offend me; it felt familiar to the D7 display regions interface.

In order to support user expectations that the place block wold place the block at the top of the region.

Adding this task for block module to make the needed changes to core to support this: #2787641: Add non-UI mechanism for setting block weight through block forms

@dyannenova

Before the region background appeared the plus seemed like the right option, but that changed when the background appeared on the region. That seemed to indicate that the current content would be changed.

That makes sense. The border around the whole region when you toggle 'place block' on indicates 'here are regions where you can place blocks' the hover background effect on only .place-block-region div at the top tells the user 'the block will go here'. Putting the background effect on the entire region would be confusing.

re: #28
color's are a great issue. As these mocks are only in bartik, isn't not going to highlight just home much of an issue outlining regions, dimming backgrounds and the icon swell is only just effecting as a visual* aid. that was the strength of the old yellow color (which simple came from the block demo page) -- no one uses yellow.
        * of course, some general true a11y issues pre-stand

hopefully as a constructive suggestion: i often use http://www.html-color-names.com/khaki.php to help clarify things for content editors and site admins in my projects..and i've had positive feed bad from those clients for it. regardless of their actual theme design and palette.

• the icon swell is not smooth and of-centers while the animation is running. I was testing some css animation tricks myself and couldn't clean it up either, background are tricky.. Perhaps this should be a color switch (ie: swap black/white) rather than a grow effect.
• throbber placement needs attention.

What's the throbber placement you mention?

If it's existing modal code, that's out of scope. All this patch changes is CSS, essentially.

throbber is falling to the bottom of the plus sign. Forces the icon to shift to the right -- lost of visual jumping.
Throbber itself is cut off on the right side (width too narrow).

@miwayha

Providing a background color on hover suggests to me that the entire area is clickable,

Actually, assuming we want to make this consistent with outside-in, the entire area *should* be clickable.

We should be testing the block place feature and outside-in with both toggled on to make sure all of the interactions are consistent.

@pwolanin

If it's existing modal code, that's out of scope. All this patch changes is CSS, essentially.

The throbber is positioned with CSS, so I don't see how that's out of scope.
@skaught

throbber is falling to the bottom of the plus sign. Forces the icon to shift to the right -- lost of visual jumping.

I agree. I have been messing around with a way to fix that by absolutely positioning the throbber on top of the button, like this:

With this CSS:

.block-place-region a.button {
  /* Absolute, top and right positioning match contextual links. */
  position: absolute; 
  top: 6px; 
  right: 6px; 
  background: url(../../../misc/icons/bebebe/plus.svg) #ffffff center center / 16px 16px no-repeat;
  border: 1px solid #cccccc;
  box-sizing: border-box;
  font-size: 1rem;
  padding: 0;
  height: 26px;
  width: 26px;
  white-space: nowrap;
}

.block-place-region {
  outline: 1px dashed rgba(0,0,0,0.5);
  /* Reset the context so button and throbber can be positioned absolutely like contextual links. */ position: relative; 
  /* Making position relative causes the div to collapse so we add back a fixed height of 36px, 
   * 26px for the hight of the button plus 4px space top and 4px space bottom, and 1px top and bottom 
   * for the width of the border 
   */
  height: 36px; 
  box-shadow: 0 0 0 1px rgba(255,255,255,0.7);
  margin: 1em 0;
  /* Padding replaced by absolute position and height. */
  padding: 0;
  text-align: center;
  text-shadow: none;
}
/* This rule matches the styling of contextual links. */
.block-place-region .ajax-progress {
  position: absolute;
  top: 6px; 
  right: 6px;
  height: 26px;
  width: 26px;
  border: 1px solid #ddd;
  padding: 0;
  background-color: #fff;
  border-radius: 100px;
}

.ajax-progress-throbber .throbber {  
  background: transparent url(../../../images/core/throbber-active.gif) no-repeat center center;
  display: block;
  padding: 3px; /* Prevents the throbber being clipped. */
}

Of course this also assumes we position the plus button to the right, which when you look at it with edit mode toggled on seems to make more sense.

The only drawback is that if the positioning shifts you might see the button peek out from under the throbber, but perhaps we could hide the button with js when the throbber is active.

@DyanneNova, @miwayha

Nice work. It's great that you usability tested it, but i'd suggest we need a little more validation on the expanding icon interaction since we don't use that anywhere else in core. For this issue I think we should keep the hover effect consistent with contextual module by just removing these attributes:

.block-place-region:hover a.button, .block-place-region:focus a.button {
    background-image: url(../../../misc/icons/787878/plus.svg);
-  background-size: 19px 19px;
-  height: 30px;
-  width: 30px;
    transition: all 0.25s ease;
}

Then we can open a meta issue for more discoverable hover afforadances for things that are editable on the front end. That would apply to place-block, quick-edit, and outside-in as well as any other contrib module that does "front-end" things and wants to leverage it eg. Panels IPE, Scald, etc.

From the usability testing, as a content editor, I found that the region highlighting was confusing but the increasing size of the plus sign when I hovered on it was more clear and an improvement. I like the differentiation on placement of the plus sign (centered) and the icon for editing (right) because of the clear difference in functionality of placing a block and editing the block itself.

@lizzjoy

I found that the region highlighting was confusing but the increasing size of the plus sign when I hovered on it was more clear and an improvement. I like the differentiation on placement of the plus sign (centered) and the icon for editing...

I'm not discounting your experience but, did you test it with both block-place and outside-in enabled and toggled on at the same time or while quick-editing a node? Those will be experiences that we need to cover.

What I'm saying is that we can't look at this module in isolation. It needs a holistic approach.

Also, while your experience is a valuable data point, we also need to test on users who are a "blank slate" ie. have never used Drupal, to cancel out the curse of knowledge effect.

#36.
+1 -- i do think i like all being set to the right. should make it easier to flip for RTL with throbber too.

again, i think killing the css grow effect for a negitive would be a good cue and now, bypass re-positioning with throbber overtop.

Given that webchick felt the current design could not ship and we are nearly at the point of releasing 8.2.0, I suggest the improvements by @DyanneNova should be committed and a new issue replace this for additional refinement and user testing.

@pwolanin

I'm ok with RTBC as long as there's a new patch that removes the "expanding icon" attributes pointed out in #37 and seconded in #40.

I'm ok with pushing the ajax throbber stuff to a follow up.

What about fixing this the other way, and making the entire region a link, including the button?

+1

We can definitively do this, but I am not quite sure for a small improvement we should also change the entire interaction pattern (expanding the button and region). Lets make it a followup and explore it, its quite an interesting idea.

Discussed this at UX meeting:

Lets create a patch that removes the scaling/expanding bit and commit this otherwise excellent design update.
Expanding the box the + button is in is an interesting idea that we can consider but would be good to do that in a separate issue. Lets get this design update committed without introducing this a new pattern.

Can somebody remove that bit from the patch?

Making the whole region clickable is a good idea, lets do a follow up for that as well. There might be technical implications for why this is not the case.

The "button" is simply a link. If we wanted to make the whole inserted block clickable it would need to be changed to an A tag displayed as block, and then the "button" would just be some decoration in the middle. This seems like it might be rather theme specific to work right, so I'm a bit reluctant.

@webchick yes, that is correct about #27. The highlighting made it appear that it would be possible to edit content within the existing blocks.

@pwolanin

As @yoroy summarized from UX meeting, making the entire area a button can be a follow-up issue.

The only thing blocking commit right now is removing the attributes mentioned in #37. Could you roll a new patch with that change and then we can put this back to RTBC?

Here's a patch to remove the expansion of the button.

Just to clarify, we were doing testing with Outside In enabled. We did have one user, @faalbane, who is just now learning what Drupal is and didn't know what a content type was while testing. I have more notes written up on that, but will need to find the relevant issues, since they are out of scope for this.

The best Inline editing interface for Drupal was (now it is not on sale) in D7 SIMPLR Builer module:
https://www.youtube.com/watch?v=yitq5iIq-xM

This module was predecessor of MD AweContent - Page Builder for Drupal
http://demo.awecontent.com/drupal7/user (login: demo / pass: demo)

The best of these 2 modules plus Inline editing UX of Sitefinity CMS (look the video on homepage) for my opinion is the best examples for "Outside-in" features in D8.

Will be in D8 flexible, inline placeble and editable Grid, which is need BEFORE placing blocks?
It is very important!

@DyanneNova

we were doing testing with Outside In enabled. We did have one user, @faalbane, who is just now learning what Drupal is and didn't know what a content type was while testing. I have more notes written up on that

Awesome! I'd love to have a look at the full report since I'm already working on next gen prototypes to place 'between any two blocks' as well as drag position.

@profiweb

Interesting, but layout is not in the scope of this issue. That has it's own initiative (blocks and layouts). This is simply about getting a minimally viable solution to place blocks in core.

Applied the last patch - it works as requested, though I still think there should be more of a visual hover effect since the scaling was removed which was very eye catching.

Let's consider options as a follow-up though.

Working on #2787641: Add non-UI mechanism for setting block weight through block forms to enable placing the block where expected.

@pwolanin

Working on #2787641: Support setting block weight through place block modal dialogs and BlockForm to enable placing the block where expected.

Great, but can you pause on implementing that? I have designs to review.

@tokleary - the change I'm proposing has no impact on the UI of the modals, only passes data along in the query string. Check out the patch.