Ckeditor5: Proposed UI for widget selection and drag-n-drop

Created on 16 May 2018 · 11Comments · Source: ckeditor/ckeditor5

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:

widget-drag-n-drop

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.

clipboard widget magic discussion feature

Source

dtwist

👍17 🎉4

Most helpful comment

@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

cruznik on 31 Jan 2019

👍5

All 11 comments

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.

oleq on 22 May 2018

@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.

dtwist on 23 May 2018

👍4

The feature requested in https://github.com/ckeditor/ckeditor5/issues/1401.

oleq on 20 Dec 2018

cruznik on 31 Jan 2019

👍5

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

oleq on 31 Jan 2019

@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.

KidHowren on 13 Jan 2020

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

oleq on 20 Jan 2020

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 :thinking: . If we'd go with "C" + "D" from https://github.com/ckeditor/ckeditor5/issues/2664#issuecomment-635793428, then we'd need to find consistent styles for both.