Allow to define a dialog which will be shown on node creation for each node type.
The input submitted in that dialog may be used in postprocessor to configure the new node, or to batch-create multiple nodes.
Configuration of the UI elements of this dialog will be the same as of inspector (under ui.dialog in nodetypes configuration yaml).
Use cases:
Grid. When creating a grid, you will select a number of columns and possibly default values for those columns, then the the grid row with desired number of columns is selected. This will allow not to abuse childNodes property for things where those child nodes are not really bound to the parent that created them, e.g. you could remove or add more columns.
Carousel, tabs etc.
Inserting multiple images/assets. Multi-select a bunch of images from media module (or multi-upload), then for each image new image node is created, with title set to the title from the media module. Later the titles may be edited to differ from the information from media module (sometimes it makes sense to have a different caption for the same image in different contexts).
When creating a new document node, prompt for a title, instead of entering it in the tree. That would solve a UI issue when you switch to another tab to copy-paste the new page title, and the page gets created without a name.
I somehow agree to christophers comment that this will need some good UX thinking. On the other hand I fear that we also started discussing this feature about 2 years ago and then said the same…
Maybe you can ask Christoph to make some wireframes? But + from my side, we recognize the usecase over and over in projects. And count me in for collaboration
I think this would be a great feature and I also agree to Christophers point.
Some thoughts from the top of my head:
I think the behavior should be “baked into” the current node create dialog, so that the wizard basically becomes multi-step (whether we’ll ever need more than 2 steps is another question).
Maybe we can improve the behavior of the wizard at the same time:
If you are only allowed to create nodes of a single type at a certain location (e.g. due to ACL- or node-constraints) the wizard should be skipped (or display the 1st “options dialog” if one is configured)…
That would be neat!
EDIT: I called the InsertNodePanel “node creation wizard” which was misleading
So taking into account what Christopher and Bastian said:
Clicking on a nodetype name in InsertNodePanel dialog may optionally offer extra step with some input components (reusing those from inspector). UI-wise that would be cool if it just happens in the same modal, acting like a 2-step wizard. So if you clicked on a wrong type you always have the option going back to nodetype selection.
But I really don’t think we should allow this “wizard” to have more than one extra step. Can you think of a use case where that may be really necessary?
Once we agree on a function, I’ll ping Christoph if he agrees to give helping hand with design.
I could imagine some complex node types that have options depending on each other. That would allow for reducing the initial amount of nodes to be shown in the dialog and have more generic main types (e.g. “Carousel” > “Type Images/Texts” > “Upload initial image” / “Add initial text”). But that’s just a very rough thought and I totally agree that we should not implement this until we need it
We have for example a node type that creates a schedule for a day of the conference. In that schedule every row can have a speaker and documents. Every time slot is a child node.
Having the wizard with 1 page would easily allow selecting the number of slots for the day, but then the editor would still have to select every time slot and configure things and upload papers.
If we would allow the 2nd (or later) step to be loaded using an ajax call I can imagine having a ‘fast editing’ screen for immediately typing the times, upload all papers at once, and so on. But for that we would need to have the ‘InsertNodePanel’ configurable in such a way that one could render his own wizard step.
Full-blown multi-step wizard.
Pros: allows to do crazy shit.
Cons: in use case that Rens defined, it virtually becomes an editing mode, substituting inline and structured modes. In such case it should be possible to run the wizard again on already existing nodes etc. I think this option is overly complex and should better be traded for improved structured editing mode.
Just add one optional step with input that can be processed in postprocessors, nothing fancy.
This option would be complementary to existing editing modes and not try to become yet another editing mode, but it would allow to query user for input that affects the process of node creation itself (number of child nodes, batch creating image nodes etc ) .
So whenever you want an extra step in this node creation wizard it probably either means you’re trying to use it for editing or trying to do a lot of unrelated things with one node type. In latter case it should be better to just split this nodetype into two.
And this option is a lot easier to implement too.
No, I don’t agree. I actually think I either didn’t express myself correctly or you misunderstood The result of the wizard is a node structure that can then be edited afterwards. It’s about feeding the node creation step with enough information to actually create that structure.
I really think option 2 is too limited to me. Of course it would be a good step, but as I tend to run into edge cases by nature I’m pretty sure I’ll deem it too limited rather soon And I also don’t think it’s just about my opinion here, also spoke to other people that would find option 2 too limited.
I think the best approach is creating option 2 first with option 1 in mind, and then extend it afterwards when we run into the usecase.
Why is that so complex to you? Would you rather require heavy javascripting to make field dependencies in the wizard? I think that’s for more complex and the way we would force integrators to go then
But as said, building the first option first makes sense so we can see in real life if we hit limitations with the single step approach.
I created a ticket for skipping the panel when only one option some time ago https://jira.neos.io/browse/NEOS-604… Rasmus also thought it was good to do.
For the wizard inputs we should refactor and reuse inspector controls. Configure them in ui.wizard?
Postprocessors as they are allow only to dynamically change nodetype configuration, but not do anything fancy like create other nodes. Possible solutions:
a. Do custom actions when catching a BeforeNodeCreate signal?
b. Extend postprcessors to be able to perform those actions
c. Introduce a yaml format for describing actions, similar to migration transformations.
a. and b. feels to low-level too me, as they require writing PHP code by inegrators, I’m in favor of c.
Examples of possible actions:
Set a property of a new node (e.g. prompt for title on node creation)
Create n nodes of certain type inside given node. Possibly also with certain properties set. (grid, tabs etc)
Create bunch of nodes based on array of data (e.g. multi-upload images and create Image nodes for each)
Re Option 1 described by @dimaip: don’t think that it becomes replacement editing mode. I’m siding with Rens here: it’s just a step(s) to feed the created node with sub-nodes and initial content.
It could work that you define arbitrary number of steps in wizard. You’ll define one anyway, so why not more? It could be stupid simple: next screen is fed with what’s provided in previous step, nothing more, nothing less.
Why I think it is important (to have more then one step)? If we go back to @bwaidelich Carousel example:
Carousel
Screen 1: Images xor Texts
Screen 2: Images carousel
Upload initial images
Add initial text
Screen 2: Text carousel
Add initial contents
Even a “simple” UI component like carousel can fork into totally different output, depending on what’s the user’s answer.
I agree we should NOT complicate things, but I believe we can simplify them (by having an ability to define arbitrary number of steps) and make this functionality totally extendable (idea Rens mentioned: by ability to specify post-processing script which would render the screen for you?)
One more thing: I needed sth similar for Typostrap, to pre-configure/add any nodes on node creation and came up with simple solution like here (I called it assistance nodes ;-):
Maybe something from it can be re-used…
PS. I hit unexpected limitation with that approach if I decided to create sibling nodes (before/after). For example, if I want to create a modal window, I also create a button which will trigger that modal and I want it after the modal element. Unfortunately, that extra before/after node won’t be rendered, full page reload is required. Something to keep in mind.
Thomas will code backend side (actions) and I will take care of the wizard interface
The wizard as a default implementation will be single step for now. For advanced usecase we allow for custom implementations to replace the default one.
We are still collecting good usecases for multi-step wizards
The result of the wizard is a node structure that can then be edited afterwards. It’s about feeding the node creation step with enough information to actually create that structure.
