UI considerations for drag and drop restrictions

[ltk]

CK imposes rules around what block types and how many blocks you can gave as children of a given block. How do we reflect these constraints within the drag and drop interface?

In the demo below, the dark grey section is full, so the item can't be moved within. Should we try to surface a message that says why the block can't be dropped in a particular location?

[mackermedia]

Would it be crazy to show all available drop zones and ones that aren't droppable have them have hatch marks or some other indicator?

On Wed, Oct 7, 2015 at 10:43 AM, Lawson Kurtz notifications@github.com wrote:

CK imposes rules around what block types and how many blocks you can gave as children of a given block. How do we reflect these constraints within the drag and drop interface?

In the demo below, the dark grey section is full, so the item can't be moved within. Should we try to surface a message that says why the block can't be dropped in a particular location? [image: demo] https://camo.githubusercontent.com/db4a0e56940a0af0fa661c4fa0397ad65c35e115/68747470733a2f2f73332e616d617a6f6e6177732e636f6d2f7669676573686172696e672d69732d76696765636172696e672f6c6b7572747a2f636b2d647261676f6e2d64656d6f2d66756c6c2d73656374696f6e2e676966

— Reply to this email directly or view it on GitHub https://github.com/vigetlabs/colonel-kurtz/issues/112.

[nhunzaker]

Ah... this was one of the major reasons we dropped drag and drop in 2.0 (in addition to some other UX issues). I like the idea of showing a message

[ltk]

okay, a good combo might to show disallowed drop zones with a different border color/style, and insert a message about the reason for disallowal into the middle of the zone. I'll work this.

[ltk]

[cwmanning]

What about cursor: no-drop; on disallowed areas? I think it's already used on areas when you've reached the max number of allowed children.

[nhunzaker]

Going to close this out, but let's pick it back up if we ever get into drag and drop again.