Refine dragging behavior and design in Layers menu

This seems related to #3470602: [PP-1] Consider using SortableJS spill plugin when dragging sections into layout?

#3458503: Improve the page hierarchy display is in!

The red color is kind of confusing. I'm not really sure what it's supposed to indicate. That you can't drag it into that location? I'm not sure if that's the best affordance. It might make sense to just show the closest place where it can be dragged to and avoid showing where it cannot be dragged. I think we should talk to Renee and Jillian from Acquia UX folks to find a solution to this 😇

@hooroomoo: deprioritizing per #3454094-77: Milestone 0.1.0: Experience Builder Demo.

#15: 🤣 I was hoping you'd say that 😆

Follow-up idea to elevate the layers UX even more: use actual component previews instead of abstract ghosts when dragging — i.e. like the ones in #3469856-52: The component preview should have a background: include theme's global asset libraries for component preview.

Initially I thought that I'm against the idea at #21. I was testing this today for the first time on my own, and I thought that the layer tab is a very good tool for power users and people who need accessible technologies - and this is especially because of being visually cleaner.

But if it would be a per user setting to show or hide previews then it would be an improvement. Another improvement IMO would be to allow navigating from layers to props and back using the keyboard.

Relevant innovations and lessons learned in dragging would be welcome at #2920006: Research accessibility of drag-and-drop grid interfaces.

Tried out the interactions on with the current branch and found a few oddities/areas that could be improved. An overall issue I encountered is that it wasn't clear where things could be dropped because there's not a great indicator to tell where valid drop zones are for slots vs a component vs two components next to each other

• It's confusing that reordering and dropping into a slot have the same styles. I would expect the slot to highlight in someway if a component is going to be placed in it
• When dropping a component into a closed slot it'd probably be better if that slot opened when a component is placed in it
• Hovering over a closed slot should open it so I can drop a component deeper into the tree without having to open it first
• (end-with-slot.mp4)Things get twitchy when trying to drag a component into a slot or to the end of a list when there is an expanded component containing a slot at the end of the list
• (expanded-no-move.mp4)It's hard to tell if an expanded component will be placed in the same spot because the indicator appears at the bottom of the expanded tree for the component
• (move-far.mp4)With an expanded tree the indicator can unexpectedly jump quite far down because it's the closest drop target
• (general-weirdness.mp4)There's some general weirdness with the indicator jumping around
• The placement indicator isn't visible when it is before/after a selected component

It would be interesting to know if you can set the e.dataTransfer.setDragImage to point to an iFrame (one that has been scaled too) to achieve the functionality described in #21.

I would be concerned though what we be able to show when dragging empty elements etc once we have the ability to build components. We would still need to be able to fall back to something more abstract like we have now.

Btw the white box with plain text in it that we have now could certainly be styled to look nicer (unless that already happened in the last few days, I've not actually checked!)