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.

tedbow’s picture

Assigned: cperera » Unassigned

@cperera just unassigning you so others don't overlook this issue. If you have time/desire to work on the issue though that would be great.

singh_haneet’s picture

Assigned: Unassigned » singh_haneet

Assigning to myself, will be working on this.

singh_haneet’s picture

Status: Needs work » Needs review
FileSize
2.14 KB
83.75 KB

Uploaded patch for adding overlay when item is in editable mode with active item highlighted. Also other blocks can be selected without closing the edit tray.

Status: Needs review » Needs work

The last submitted patch, 18: 2822932-18.patch, failed testing.

SKAUGHT’s picture

very nice overall.

from attached image. although i am editing the Tools menu block, the Search Block has a lightened state as well. other blocks also have this ghosting, but as less noticeable as they (in Bartik regions) have black and blue background.

--edit--
quick editing the Page Title block this area doesn't have any highlighting.

--edit2--
after a little more playing.. i'm not sure if this ghosting is due to other regions being 'editible by clicking'.

singh_haneet’s picture

from attached image. although i am editing the Tools menu block, the Search Block has a lightened state as well. other blocks also have this ghosting, but as less noticeable as they (in Bartik regions) have black and blue background.

Unselected blocks are given opacity=0.25 in order to distinguish from active block
As mentioned in #5 and quoted in #14

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

the blocks had to be placed over overlay in order to be selectable without closing the tray. These blocks have defined (or may have) background and color properties and it would be difficult to override those, so opacity for those is added.

SKAUGHT’s picture

It was clearer after playing with it for a bit. this patch increases the overlay darkness and adds hover state and cursor change to help make it clearer that clicking other blocks will envoke settings tray

SKAUGHT’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 22: 2822932#22-Make-selected-items-more visually-obvious.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 25: 2822932-25-Make-selected-items-more-visually-obvious.patch, failed testing.

tedbow’s picture

Issue tags: +Needs reroll
singh_haneet’s picture

Status: Needs work » Needs review
FileSize
2.43 KB

Rerolled patch

Status: Needs review » Needs work

The last submitted patch, 28: 2822932-28.patch, failed testing.

SKAUGHT’s picture

Assigned: singh_haneet » Unassigned
Status: Needs work » Needs review

i believe this is CI testing issues. patch does apply fine with simplytest.me

un-assigning & marking for review.

Jo Fitzgerald’s picture

Issue tags: -Needs reroll

Please remember to remove the "Needs Reroll" tag after re-rolling.