Proposed UI for widget selection and drag-n-drop

[dtwist]

Is this a bug report or feature request? (choose one)

Other

💻 Version of CKEditor

CKEditor 5.x

Proposal

I had an idea while noodling on some ideas for tables in this issue that apply more generally to widgets.

The problem of how to select the whole table for copying, deleting and dragging came up. It occurred to me that this seems to be an unsolved problem for widgets in general, and it would be good to come up with an idea that is more generally usable than just for tables. Here's a rough prototype of the idea I came up with:

The tab attaches to the top-left corner of the widget highlight and includes the icon used to insert the given widget (in this case a table) along with some indication it can be moved. ( see additional variations below, including some that omit the widget icon).

Clicking on the tab selects the whole widget, allowing it to be copied or deleted. Dragging it ghosts out the widget and uses the magic-line feature to drop it in another location, using the tab as a stand-in for the whole widget.

Variations on the look of the tab icon

I can provide a sketch file if this looks worth pursuing to the CKS team.

[oleq]

The designs are super-cool!

Until we implement widget drag&drop, though, we should consider widget selection only. Something similar to widget selection in v4 https://ckeditor.com/ckeditor-4/ (hover the image in the content).

Another thing is that although the UI looks great, I'm afraid it might a tad too big. It's nearly 2 line heights which I think might be a problem when the spacing around the widget is not that generous; e.g. when the widget is the first item of the content or there's a content preceding the widget that user wants to select.

[dtwist]

@oleq thanks, it's a pleasure to contribute to a project that has set such a high bar. 😄

Indeed, I didn't expect this proposal to be practical for the immediate future; it does need drag and drop working to be fully applicable.

As for how to handle full widget selection in the immediate term—the v4 click-to-select interaction works perfectly well, so long as the widget (or at least the bulk of it) is not itself editable, such as images. When a widget is primarily composed of editable elements though, such as with a table, that no longer works. That was the main problem I was trying to solve for with this element. Does it work without the drag component, at this stage in CKE5's evolution? Maybe, if you omit the "drag" handle and just use the widget icon…

You bring up some good and valid considerations.

On sizing, I stuck to the sizes already established for icons (20px square) and buttons (~30px) in the interface you've already designed. Making an element like this much smaller may be problematic for usability reasons (Fitts’s Law), but I'd be curious to see what you come up with!

I hadn't considered a widget being the first item in an editor window… Looking at the sample CKE5 editors now though, I don't think it needs to be a big concern; if you place an image first-most, it's existing balloon toolbar can overlap the main toolbar on a classic editor, and that feels just fine. This tab could do the same without apparent issue. Likewise, in practice I don't think you need worry about overlapping a small amount of content preceding the widget—just click anywhere outside of the widget before selecting that text (or hit up-arrow to get out of the widget).

The goals I started from were:

• allow selection of whole widget
• facilitate dragging of widget
• do not obstruct any part of the widget content itself
• do not use any screen real-estate to the left or right of editable area
• make the interface as obvious and discoverable as possible
• make it clear this is a different aspect of the UI than widget tools/settings
• consider usability on mobile
• keep interface hidden until interacting with widget

I tried a few other approaches that I didn't think worked as well. Ultimately, attaching the UI element to the widget highlight rect was far more obvious than any other. I can post those here too though if you like.

[oleq]

The feature requested in #1401.

[cruznik]

@dtwist Hi men, we are currently planning to upgrade our ckeditor to 5. The most important feature that we want to introduce as part of the migration process is drag and drop. We want to be able to drag n drop items into the canvas (eg. button) and later on be able to drag and drop the element inside the canvas. (move it to a different position). i will appreciate any suggestions for implementing that

[oleq]

@cruznik What do you mean by "canvas" here? Can you tell us more about your use–case?

[KidHowren]

@oleq Any updates on this? My organization also needs drag/drop functionality for widgets. The user needs to be able to drag content into the editor and drop it at any position they want (w/the text caret moving in real time) and after it has been dropped into the editor the user also needs to be able to drag the widget to a new position.

Here is our implementation of this feature using Ckeditor4.

[oleq]

@KidHowren The feature is definitely on our TODO list but, as of today, I can't promise any ETA. Stay tuned.

[Reinmar]

The "umbrella" ticket for drag&drop: #2664. 

My biggest problem with a UI similar to the one that @dtwist proposed is how to translate that to all kinds of blocks 🤔 . If we'd go with "C" + "D" from #2664 (comment), then we'd need to find consistent styles for both.

[HugoBeleza]

@Reinmar @oleq would this feature also work within nested tables?

[jodator]

@Reinmar @oleq would this feature also work within nested tables?

Hard to tell. We officially do not support nested tables. They kinda work if you unblock it, but as for now nested tables are out of the scope.

[oleq]

If we'd go with "C" + "D" from #2664 (comment), then we'd need to find consistent styles for both.

@Reinmar @oleq would this feature also work within nested tables?

We need to find a universal solution to all types of drag&drop so yes, nested tables are just one of the use-cases. It's the 

(D) Drag and drop of any block(s) in the editor.

that worries me a lot, though because there are so many scenarios to think through.

[CKEditorBot]

There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may be relevant, so if you're interested in the solution, leave a comment or reaction under this issue.

[CKEditorBot]

There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may still be relevant, so if you're interested in the solution, leave a comment or reaction under this issue.

[CKEditorBot]

We've closed your issue due to inactivity over the last year. We understand that the issue may still be relevant. If so, feel free to open a new one (and link this issue to it).