Structured Editing within CKE5

Creating Neos & Flow Code
1

While preparing for their talk, Piotrek Koszuliński and @sebastian have created a mind-blowing prototype that shows how to edit structured data within CKE5: https://github.com/Reinmar/ckeditor5-structured-editing

I must say I’m completely stunned by what Piotrek managed to do for us in such short amount of time (thank you!!!) and I’m super excited about our collaboration!
I can’t wait to start integrating this prototype into Neos, but for that I need some brainpower.

What we want to achieve: edit whole content collections within CKE5, and not just individual nodes. It would solve our long-standing UX issues like the pain of inserting images in between existing text etc. See the talk for more details: https://youtu.be/HtZcqtTFXRg?t=3667
Prior context: Structured editing and tighter integration with CKE5

Now let’s go through the integration challenges:

  1. to co-exist with traditional content collections, we can have some helper Fusion object that would initialize an editable content collection, similar to the way we init editables now. Everything inside it would be rendered inside one CKE5 instance.
  2. to get data into CKE now we need structured data instead of pre-rendered editables like before. That information is already available in our redux store, as it’s loaded from inline script tags when the page loads. So far so good.
  3. CKE5 has to know how to render nodes from their properties. I think there should be two modes for rendering:
    a) synchronous, where we define a JS function that takes node’s properties and returns a DOM node. Or maybe even a string with placeholders that could be statically generated from Fusion on the server-side. Dunno. The obvious limitation for such client-side rendered nodes, is that they should not have some kind of server-side processing, so it would be possible to create them optimistically. Probably we should also disallow childNodes for them.
    Also we’d generate uuid’s client side, and it should be possible to persist the nodes under these pre-generated identifiers. Is it already possible with our current API?
    b) async, by making an ajax request to our out-of-band rendering endpoint. That’s needed for nodetypes that require some server-side processing (e.g. images). Piotrek, do you think it would be hard to add this possibility to your prototype? I guess we can just make a generic API for the render function to always return a promise, but for synchronous content it would resolve right away.
  4. I have no idea if it’s possible to implement nested ContentCollections with this approach (Piotrek, any ideas?). We can start without them. But it would actually be cool to support things like grids.
  5. To get data out of CKE5, we have a number of events (update, remove, create, select) that map to our API pretty well. The only thing is that we need to convert them from being index-based to being identifier-based. (Piotrek, is it possible to adjust your prototype to use identifiers and fire multiple remove events instead of one event with a range?)

Ideas? Feedback? Anyone wants to join the efforts?

1 Like
2

I like the “ideal world” thought of @christianm
The result will eventually be visual and tangible.

I propose: let’s do a couple of use cases or visual examples of structured content and layouts, so we get and idea of what we’re dealing with, what the solution should enable an editor or designer to do, the ramifications and which approach would satisfy the requirements for that in terms of
a) strategy / user experience
b) implementation in code.

3

First ideas

4

@dimaip here is a proposal for improvement of your existing Structured Editing package.

Place editing buttons directly available on hover either above or, as in this example, overlaid over the image without the need for clicking on an edit button. The cropping functionality can even be implemented as immediately accessible handles on the image’s edges.

2019-11-26_203011
2019-11-26_203011.png960×768 582 KB

5

The trick is that my implementation has to be agnostic to the editor type, it should work with dates and any other editors.
Of course it would be ideal to develop a dedicated version of each editor with UX tailored to inline usage, but I just didn’t have the resources to do it when developing that package (in fact I developed it overnight before my Neoscon talk!).

1 Like
6

And another tricky thing is that we don’t have any control over rendering of e.g. images, we have no idea what their dimensions are, how they are represented in the markup etc etc. That makes doing proper UX for such things much harder.

7

Yes, this would be possible only with a Neos provided widget, where you know what to expect.

8

I was watching some neos videos on youtube and was really amazed by the flawless usability experience of this demo: https://youtu.be/fVcV_KnynGE

I really like how everything is right in time and without the need to apply changes. (I now because this demo doesnt use sever side rendering … but still ^^)

Is there any update on the idea? I would love this or a similar feature ; )

2 Likes