Problem/Motivation

Users still are not necessarily clear as to what part of the page is being edited when settings tray is open and as we look to add different levels of scope eg. layouts for the entire page vs layout for the fields of a node, we need a better way to clearly show this.

Proposed resolution

Create an "isolation mode" that darkens all items on the page that are not in the context being edited.

Remaining tasks

Contributor tasks needed
Task Novice task? Contributor instructions Complete?
Create a patch Instructions no

User interface changes

When the settings tray is open everything outside the selected item will be darkened.

API changes

?

Data model changes

?

Comments

tkoleary created an issue. See original summary.

tkoleary’s picture

Issue summary: View changes
tkoleary’s picture

Issue summary: View changes
tkoleary’s picture

Issue summary: View changes
tkoleary’s picture

Issue summary: View changes

Notes on implementation.

Drupal already provides us with the markup for the dark overlay in dialo.ajax.js

 // Provide a known 'drupal-modal' DOM element for Drupal-based modal
 // dialogs. Non-modal dialogs are responsible for creating their own
 // elements, since there can be multiple non-modal dialogs at a time.
  if (!$('#drupal-modal').length) {
 // Add 'ui-front' jQuery UI class so jQuery UI widgets like autocomplete
 // sit on top of dialogs. For more information see
 // http://api.jqueryui.com/theming/stacking-elements/.
 $('<div id="drupal-modal" class="ui-front"/>').hide().appendTo('body');
 }

When a jquery dialog is invoked it gets the class .ui-widget-overlay

When we look at this in Bartik it's very dark (0.7 opacity) which is bad for this purpose since we don't want to completely obscure what's underneathe because users should be able to select other blocks without closing the tray.

Unfortunately Bartik adds this override to the jquery attributes. What that means in this case is that if we want to make the overlay lighter we will need to do that with javascript.

I tested the overlay with 0.4 opacity which is transparent enough to see and select blocks.

So if we use the overlay widget we will just need to get the the selected block (or whatever is selected) above the overlay by adding a z-index of 499 on click. The blocks need a z-index of 499 to sit below the toolbar at 502 and the tray which at 501. The overlay widget will need z-index of 488 to sit below the blocks, the tray and the contextual links which are at 500.

To recap that's:
502: toolbar
501: tray
500: contextual links
499: selected block
498: overlay widget

There is one potential snag in this if the selected block has a background color of transparent. We could add a background color of white to the block but that doesn't work if, for example, the background of the underlying region is a dark color and the text in the block is white. We may need to use js to find the next parent that has a background that is not transparent, grab that color and pass it to the block.

The last thing is to remove the current highlighting of the background of the selected block. We can leave the hover highlighting on unselected blocks.

tkoleary’s picture

Issue summary: View changes
tkoleary’s picture

Issue tags: +Usability, +JavaScript
tedbow’s picture

SKAUGHT’s picture

a difficult request. i've had this for projects..

the trouble is css layers don't support 'knockout': to actually do this, you basically need to clone out the object (and related css that is acting on it.. to maintain shape/size) and place it on top of the darkened overlay layer, while monitoring it's position (assuming a responsive desktop layout -- that 'may be' resized while open).

OR

have the model overlay actually be 4 layers positioned a top, right, bottom & left of the position of the Un-darkened element. again, deal with re-poisitoning/size of these 4 'darkened' layers as needed.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

cperera’s picture

Assigned: Unassigned » cperera
yoroy’s picture

Looking forward to see this in action!

cperera’s picture

Upload patch.

The patch have the number 12 of comment. This comment is 13. I'm sorry!!!

yoroy’s picture

Status: Needs review » Needs work
FileSize
100.83 KB

That was quick! No worries about issue comment numbering, you're working on a patch, that's great :-) Thank you for working on this @cperera.

I tested it on https://simplytest.me/project and noticed that:

1. Yes, the screen gets darker when you click an item to edit with the settings tray: success!
2. But: the "active" item itself is not highlighted.

I think that's what #5 mentions:

There is one potential snag in this if the selected block has a background color of transparent. We could add a background color of white to the block but that doesn't work if, for example, the background of the underlying region is a dark color and the text in the block is white. We may need to use js to find the next parent that has a background that is not transparent, grab that color and pass it to the block.

3. Also from #5:

we don't want to completely obscure what's underneathe because users should be able to select other blocks without closing the tray.

It doesn't look like I can click other elements and configure those in the settings tray.

cperera’s picture

Ok, thank you, I'm still work on the job.