Design intuitive affordances for Layout Builder (for illustrating which parts of the page are editable in a given context)

This probably needs accessibility review, once we have some design suggestions.

Take care to avoid affordances which rely on colour alone, see WCAG Use of Color

In the ux call today we discussed graying out the background and disabling any interaction outside of the content area until Save, Cancel, or one of the other local task tabs is selected. Here's the mockup we discussed:

On the call, we agreed that this should behave in the same way as any other modal in the system, so it should have a similar level of accessibility as current modals.

There are likely be some huge gotchas with #7. I'll tentatively say that's a no-go for accessibility, and certainly too ambitious to be done by this March for the first stable version of Layout Builder.

disabling any interaction outside of the content area until Save, Cancel, or one of the other local task tabs is selected

The layout builder currently is a page in it's own right, with a URL in the browser toolbar. That's totally different from dialogs, which are on top of a page. Or, if you like, dialogs are part of a page, in the sense that they are invoked from a control on that page. Dialogs don't have their own URL (as far as the browser history goes; ignore the ajax implementation aspect). You navigate from one page to another page; not from one page directly to a dialog on another page.

If a user chooses a primary tab, they expect to arrive at another page - because it's a link, conveyed as such by assistive tech, and that's how it works on all the other parts of Drupal. If they arrive on a page, but a modal dialog-like behaviour is already active, and some of the consistent (on-page) site-wide navigation mechanisms are inert or hidden, that could be very confusing. For example the admin toolbar, local tasks (primary tabs), breadcrumb, and arbitrary menu blocks, are all navigation landmarks that assistive tech users can find quickly. We haven't had any testing of the layout builder by users with disabilities yet, so I'm very wary of disabling any established site-wide UI which users are familiar with.

If the layout builder wasn't what they wanted, it amounts to taking a wrong turn and falling into to a trap. Of course they can still back out using the (off-page) browser history, but the experience seems a bit like "Oh no, run away".

On the call, we agreed that this should behave in the same way as any other modal in the system, so it should have a similar level of accessibility as current modals.

But here's a key difference: the layout builder also invokes off-canvas dialogs for most of it's tasks.

So, first the layout builder has restricted access to parts of the page, in a modal dialog-like way. Then the user presses "add block". Now an off-canvas dialog appears, and we are talking about dialogs on top of dialogs. The assumption that this has the same accessibility as current modals doesn't hold.

Visually the two dialogs may be side-by-side, but conceptually they are stacked; a dialog invoked from inside a dialog. The accessibility considerations are making my mind reel. This situation is rare in web applications, and I have no idea if there is any accessible prior work. Dialogs-on-dialogs are uncommon in native desktop applications too. Where they do appear it usually wraps a single control, like a confirm/cancel step (ARIA provides for this with the separate alertdialog role). Desktop applications don't generally stack complex dialogs with multiple options.

The screenshot in #7 looks a lot like the overlay design in D7, where we had to build a per-user setting to disable it. We got rid of the overlay module/concept, so it's worth looking back over that discussion to see if it any of it applies here.

@DyanneNova thanks for posting these designs

@andrewmacpherson thanks the accessibility feedback.

From the issue summary, part of the goal of this issue is

help site builders avoid making potentially regrettable decisions about their site architecture, permission setup, etc

I think one thing that could be very confusing to site builders is that

1. Using the Layout Builder, Layouts are populated with blocks
2. You can configure blocks you add and existing blocks in the layout
3. You configure the existing blocks in the Layout Builder via contextual links
4. There will usually be other blocks on the page, but out of the Layout Builder controlled sections
5. For the blocks outside of the sections: You(if you have permission) also configure these blocks in the Layout Builder via contextual links
6. If you have Setting Tray enabled configuring the non-Layout Builder blocks happens in the same place as Layout Builder blocks

I think especially if you are configuring a layout override, say for a node, the user may expect that changes they make to any blocks when using the Layout Builder would be overrides just for that node.

But of course if they configure any block not controlled by Layout Builder, say a search block in a sidebar region, this will be global change and has nothing to do with the Layout override.

So hopefully we can at least say
When a user is configuring a layout in Layout Builder they should not be able to edit blocks not controlled by Layout Builder.

I don't think this would really a burden for users and would remove a lot of confusion.

A simple way to do this, but does not give the nice visual queues that @DyanneNova's design, would be to remove all block contextual links form blocks not controlled by Layout Builder during layout administration.

I think is important because the whole idea of contextual links is that you can make changes in a given context. So I think it would reasonable for the user to assume they can edit blocks "in the context of the layout"(whether default or override).

remove all block contextual links form blocks not controlled by Layout Builder during layout administration.

Yep, worth exploring that one as a quick win for the meantime. Should include some text about it in the hook_help for LB and/or contextual (and/or the new help_topics).

@andrewmacpherson I don't think that this would need to be implemented in a dialog if that's problematic, it was just the first thing that came to mind for everyone discussing the pattern. I agree that it should continue to be an actual page that's navigated to, with its own url. Also, the admin toolbar and local tasks shouldn't be disabled. The only menu items that would be inaccessible would be non-administrative navigation. I'm not sure that there are better design solutions for conveying this information to sighted users, so I'm wondering if there are things that we can do to provide a similar experience to non-sighted users.

Would it make sense to hide the non-layoutable page content completely from screen readers when on the Layout page and instead provide some text explaining what is being edited, ex: "You are now editing the layout for this content only. Blocks outside of the main content area will remain as they were."?

The only menu items that would be inaccessible would be non-administrative navigation.

I don't think that "non-administrative navigation" is easy to distinguish. For instance, the main menu and breadcrumb are things an editor can reasonably expect to use to find their way around the site content, but can be outside the layout builder area. Likewise for the Tools menu block enabled in Standard profile. Intranets sometimes have custom administrative menu blocks much more elaborate than that.

I'm not sure that there are better design solutions for conveying this information to sighted users, so I'm wondering if there are things that we can do to provide a similar experience to non-sighted users.

As in similarly frustrating. The design above presents an accessibility problem for sighted users. The grey overlay can obscure operable controls (by lowering text contrast). This isn't a problem with Views UI dialogs, because they have all the expected dialog behaviour (notably a visible close button), and users don't expected to interact with anything outside the dialog, unless they dismiss the dialog.

The breadcrumb and Tools menu block are example of things which will be obscured by this grey overlay, and are useful to editors.

Would it make sense to hide the non-layoutable page content completely from screen readers when on the Layout page and instead provide some text explaining what is being edited, ex: "You are now editing the layout for this content only. Blocks outside of the main content area will remain as they were."?

No, I don't think there is any need or benefit to hide any content at all from screen readers. That creates inequality by putting some users in a silo. "Screen reader user" is being conflated with "non-sighted user" here.

Ted's idea of removing the contextual links from blocks outside the layout builder is better. Every thing will still work, except the one thing that you're trying to prevent.

A piece of text about the layout builder behaviour may help, as long as it is discoverable. But it will be helpful for all users, and should be visible; the design at #2935779-18: Come up with an affordance for what parts of the page are/are not affected by Layout Builder will suffice. Screen reader users will be able to discover it if we include it in the custom landmark region required by #2917777: Improvements to the styling, grouping, etc. of the Layout Builder UI actions form.

The most important place to convey that layout builder is active, for helping screen reader users in particular, is the <title> in the HTML head. (Update, I just checked that, the layout builder begins with "Edit layout..." for entity bundle and per-entity cases. It doesn't distinguish between view modes though, so that could be improved.)

@DyanneNova brought this to UX meeting this week, to enquire about whether or not we could drop this as a stable blocker from Layout Builder, given the (extremely valid) concerns in #12. I think those concerns make it clear that if we are going to solve this, the mockup in #7 isn't a viable solution, at least not without a TON of attention paid to details such as how to navigate back out of Layout Builder, how to navigate between two dialogs in the same interface, etc. I'm not sure the "win" there is worth it, as nice as that looks.

I do still think it's worth some sort of visual affordance, however. Because if you look at a typical Drupal page, let's say... https://www.drupal.org/documentation ... only a tiny portion of the page—relative to all of the surrounding area—is actually editable from a layout POV:

(Note this might not be technically accurate for this one particular page on this one particular site, but in general this is the default editable region on a site like this.)

However, without some visual way to note this, content authors are going to assume "layout" refers to the "page" which is everything from the top left to the bottom right of the screen. And similarly very likely going to assume Drupal's being super buggy and broken when they try to click and drag, say, a header or sidebar block coming from the theme, and can't. Frustration ensues.

So while I definitely don't want to tank this entire initiative over this one aspect, and I agree with Andrew that the current design doesn't look workable, it does nevertheless feel very important to have some visual indicator as to what of the "page layout" is actually editable.

I'm willing to grit my teeth together really hard and demote this from stable blocker (since I'd much rather people have this feature at all than for it to be "perfect"), but before doing that, I would really love if we could take at least one more crack design-wise at this ... maybe borrowing affordances from Quick Edit or something, which is already in core (a simple blue outline that doesn't have any greying out / pseudo-dialog concerns)? Because I strongly suspect that with real-world use, this is going to inevitably come up, and later become a major/critical UX bug to fix, which then causes a major visual change to a stably released thing, which causes forced updates to documentation, videos, user training, etc. Best if we can finalize the visuals before stability, if it's possible.

Weird. No idea what happened with the tag there, sorry!

Here is a mockup using the blue outline that we discussed on the ux call. I did a quick round of testing on a single content editor who has not used Layout Builder before. That editor found the other design (graying out the background) to be more intuitive, but was still able to understand what areas of the page were editable with this design. He did point out that without his glasses on he would not have noticed the outline and then he would have expected that he could edit the "More Recipes" block that is outside of the main content area.

Yeah, good to see a different idea in #15, that direction could work.

The challenging part of putting a border around it is colour contrast. It's another one of those "admin tools which sit on top of an arbitrary front end theme". There isn't any colour that will be discernable against literally any front-end theme. Would it be up to the front end themes to implement this themselves? (Pessimistic-me thinks few will do so.) Or would layout builder provide a generic admin style, like Toolbar/Off-canvas? The only robust way I can see is to use a dark+light double border trick.

I'm uncertain if a grouping border like this would be subject to WCAG 1.4.11 Non-text contrast:

• I'm pretty sure it doesn't come under the definition of "user interface component" since it's a grouping element, not an operable control.
• However it might count as a "graphical object ... required to understand the content", the point being that it matters whether something is inside or outside of the line.

Linking a similar issue, which also tries to highlight an active region.

a simple blue outline that doesn't have any greying out / pseudo-dialog concerns

Agreed, those concerns would be gone.

@DyanneNova showed #15 off during UX meeting this week. There was one concern raised by @ckrina about what happens if the layout extends the full width of the screen, such that the borders are not visible; however that seems like an okay situation, since that successfully indicates that the entire region is "layoutable." (One other nit was a bit more margin between the top border and the buttons, though that's more a stylistic thing.) There was also the concern about what that colour would look like on various front-end themes; @tedbow pointed out that this change could be accompanied by a themer guide or something in 8.7 to help front-end themers account for this.

In any event, this affordance is following an existing core pattern from Quick Edit module, so I can't see holding it up for that... if there are accessibility / themability problems, it seems like we should fix them in a more holistic way (I seem to recall some kind of fancy-pants stuff in Bartik's Colour module integration back in the day to account for light+dark backgrounds, but details are escaping me).

TL;DR: +1 from the UX team, and since it's re-using an existing core UI pattern, hoping this is sufficient for a11y gate as well.

It looks like there are some implementation obstacles with the current design, as there's no guarantee local tasks and the layout builder form will be adjacent to each other, nor are they enclosed in a containing element that groups them together.

Here's an example of breadcrumbs shimmying in between local tasks and layout builder with the design from #15.

After discovering the issue in #20, @tedbow suggested fully outlining the "Layout" local task and content area, since there's no guarantee of them being connected. Below is a potential implementation of that solution that can be evaluated.

I tried to find a solution that would work well with margin-separated tabs such as those in Bartik and directly-adjacent tabs such as those in Umami's theme. While it's not necessary to support themes outside of core, Umami's local task styling is not uncommon and I'm partial to an approach that accommodates differing tab styles.

One visual drawback of the approach in the patch is that using outline instead of border means the outline doesn't adhere to the rounded corners of Bartik's tabs. This can be changed, but using borders would require several extra selectors of CSS specificity, potentially alters the dimensions of local task links, and presents the additional challenge pictured here:

1. +++ b/core/modules/layout_builder/css/layout-builder.css
   @@ -114,3 +114,24 @@
   +@media screen and (max-width: 37.5em) {
   +  [data-drupal-selector$="layout-builder-form"] {
   +    padding-left: 12px;
   +    padding-right: 12px;
   +  }
   +}
   

   Two questions: How was this max-width value chosen? And, is it okay to mix ems and pixels like this?

2. +++ b/core/modules/layout_builder/css/layout-builder.css
   @@ -114,3 +114,24 @@
   +.tabs .primary a.is-active {
   +  outline: 3px solid #2f91da;
   +  outline-offset: -3px;
   +}
   

   I think there is an issue open to make LB work independent of tabs -- should we maybe link to that issue here?

Brought this to the UX meeting and the plan is now to highlight the content area but not the local task.
One of the benefits of this approach is that it matches existing patterns such as the ones used by Quick Edit.

Next steps

• Modify patch in #22 to only highlight content area
• Based on #22.1: either add a comment explaining how that media query is the same as the one used by Bartik's mobile nav, or possibly find a better approach to responsive padding that isn't beholden to Bartik's media queries.
• Update issue summary

1. Per the decisions made at the Feb 26 2018 UX meeting, this has been changed so only the content area is outlined
2. At the same meeting, this solution got accessibility signoff from @andrewmacpherson
3. Added a class to distinguish the entity override layout form from the layout default form, since the outline is not necessary on layout default forms. CSS was refactored to use this new class as the selector
4. #22.1 was addressed by switching to ems + the media query was changed and has an explanation
5. #22.2 addressed because requirements changed and local tasks/tabs do not need styling anymore.
6. Added before/after screenshots of the changes in Umami and Bartik.

1. +++ b/core/modules/layout_builder/css/layout-builder.css
   @@ -114,3 +114,24 @@
   +.layout-builder-overrides-entity-form {
   +  background-color: #fff;
   +  outline: 3px solid #2f91da;
   +  margin-bottom: .5em;
   +  padding-left: 3em;
   +  padding-right: 3em;
   +  padding-bottom: 1em;
   +}
   

   Two questions here: does this need to use BEM, and does it need an RTL counterpart?

2. +++ b/core/modules/layout_builder/css/layout-builder.css
   @@ -114,3 +114,24 @@
   +/*
   + * Using 48em as breakpoint to match the one used by the dialog system to expand
   + * dialog widths.
   + */
   

   Is there some other code, file, or URL we can refer to? A @see might be helpful here.

Re #26.1

does this need to use BEM

I don't believe so - this is my rationale just in case I'm misunderstanding BEM: The form this class is added to does not have any other consistent classes (the other classes are entity type/bundle specific) so it wouldn't require the modifier pattern, and it's the top level element of the build, so it wouldn't be an element of anything.

does it need an RTL counterpart?

The only RTL-relevant styling would be the padding which is equal on the right and left, so this shouldn't be necessary.

Re #26.2
Very good point regarding the @see. This has been added.

Fixing tags

Well, I tested this briefly in Chrome on a Mac, with both Standard (Bartik) and Umami. Screenshots attached, and added to the IS; looked pretty good to me. So does the code.

One thing I wondered is if it makes sense to put the Save/Discard/Revert buttons inside the editable area, rather than outside of it. They're not editable, so do they really belong there?

Since defaults are also shown in the front end theme, why isn't this also added for those?

Additionally, there is already .layout-builder for the UI, why not use that selector?

Has the benefit of not including the buttons...

Re #30

Since defaults are also shown in the front end theme, why isn't this also added for those?

Additionally, there is already .layout-builder for the UI, why not use that selector?

Those are the right questions to ask - those were no-longer-relevant artifacts of previous iterations and I'm glad you caught them. Changed the selector to .layout-builder has several benefits. Another benefit is that without buttons in the outline area, the padding can be the same in mobile and desktop, which means less CSS and more space for Layout Builder.

Should mention that this does deviate from all the designs that have received UX signoff. All of those designs included the buttons inside the outlined area. While I'm reasonably sure this will be accepted as the better solution, it's enough of a change to warrant another round of UX approval. I'll take this to the next UX meeting.

Presented these changes at the March 5 2019 UX Meeting and confirmed UX signoff is still valid.

I think we'll need to update the screenshots because we have removed the buttons from the outlined area, but otherwise it's RTBC as far as I can tell.

Added screenshots for IS.

Perfect.

Cut and print!

Tagging

Reviewed the past few UX meetings where we talked about this... everyone actively discussing seems to be in the credit list with the exception of @benjifisher (added) who drove the demo on 2/26. (Thank you!)

THANK YOU for your patience and persistence with all of the rigamarole here. This issue really highlighted the need for closer collaboration between the UX and a11y teams, because lack of that coordination led to some "wild goose-chasing" up above when UX team said "OMG PRETTY! SHIP IT!" without adequately determining feasibility. I'm really sorry for that, and will work on this collaboration going forward to help cut down on these types of instances.

However, the end result is simple, follows existing core patterns, and does the trick to communicate to end users what is "layout-able." Great work!

Committed and pushed to 8.7.x. Thanks!

The styles are not rendered correctly in IE11 because it doesn't support outline-offset. Maybe we could solve this in a follow-up?

Screenshot from IE11:

Borders with negative margins are an alternative to outline-offset which can work for IE.

Created followup #3038413: Replace editable-area negative-offset outline with something that IE11 can handle.