CreationDialog is meant for input of properties that are needed on node creation, it’s not an alternative UI to the inspector. I think it would actually screw up the UX if people would get used to editing the same information from multiple places. If entering information in the inspector is not convinient enough, we should fix it there, rather than providing a workaround. E.g. structured editing + guided input could help.
I didn’t use the package in production yet, but it seems to be very powerful.
But for the simple and common use case above it seems to be a little over-sophisticated and it’s not as easy to add properties with mapping etc.
Besides I really think that we should refrain from using Fusion (or Eel) outside of Fusion files. We already do that for the label property, but IMO that should be deprecated in favor of specifying a Fusion prototype name.
However, I had a quick look at the source and it’s not too much code. So maybe we could implement a combination in the core
Todo
The following tasks would need to be tackled in order to include the functionality to the core:
Agree about the suggestion
The code probably needs a little cleanup
Error handling - what if property mapping fails for example (but that’s probably also an issue in the regular inspector)
Make all (core) editors work. Currently the media browser can’t be opened from the create dialog for example
Possibly add (some) features of the NodeTemplates package, too?
Good question. I think @dimaip’s concern is very on point here.
I’m missing the reasoning why you prefer moving some properties from being entered in the inspector after the element is inserted, to before the element is inserted in the creation dialog. Is it to put focus on required ones? Or to simplify the UI as the inspector has lots of other properties?
For the node templates package, it has the ability to insert multiple elements and thus it’s necessary or can be an convenience to require information when inserting elements.
Mainly to avoid inconsistent state.
For example: Imagine you have a NewsArticle NodeType and the properties title and date are required as per specification. Currently there is no way to avoid that some user inserts the article node but does not set these properties.
But even for optional properties it can make a lot of sense to give them more “emphasis” by adding them to the creation process.
To me the Inspector is more of a “power tool”, similar to the Structure Tree. IMO the Backend should be usable without both for the most common scenarios. Having more editors “inline” (or as some call it: structured editing) is a very good idea. But still: In many cases I want to explicitly include some properties in the creation process of a node.
Thanks for elaborating. I definitely can see the use case make sense. Personally wouldn’t object to including that option in the core.
I remember the NodeTemplates stuff was originally intended to be a core feature, but then pulled out and turned into a independent package. I agree the it’s kinda a power tool and configuring it isn’t a straight forward thing like the showInCreationDialog option would be.
Hi there Bastian!
I think there concerns that your RFC is trying to solve are very valid and should be addressed and I think we should spend a bit more time brainstorming here together, because I have a concern that this small feature would open a whole Pandora box.
So my concerns again: we are basically forking editor experience, the way you input information on first creation would be drastically different from how you edit the same information later. I think it’s unavoidable that the editors will start asking for a way to trigger the wizard already after the node has been created.
To start with, let’s sum up the current UX problems:
Inconsistent state and validation. Some properties need to be set before the node can be published.
Guided input. Editors prefer clear, step-by-step input to just a bunch of options scattered throughout the screen.
Allow me to propose a few possible solutions:
Validation of inline properties + allow to bring some structured properties from inspector inline (aka structured editing)
Allow to define a guided input, e.g. Neos would focus mandatory fields one after another in steps.
But in any case, I’m not an UX expert here. What do more UX-minded people think? @rasmusskjoldan? @wrybit?
I’m still a bit surprised that you see it as a main issue to be honest. But very good idea to include Jens and Rasmus into the discussion (hi by the way ).
Of course people could misuse the feature and use it for properties that are just as well inline editable. But those are not my major concern. It’s especially useful for properties like images, references, dates, … Those are not inline editable by default and thus the editor experience (pun intended) is literally the same.
Yes, hopefully we’ll have more options to edit even those inline and then this flag might not be required any more for those fields. But there are more cases where it makes sense.
Think of a Person component for example that renders the full name but has individual properties (and validation rules) for first and last name. For me it would be perfectly fine if the editor needs to switch to the Property Inspector to change the first or last name because that’s not very common. But I don’t want nodes without those properties to exist.
I don’t know how that should work in practice since we don’t have the explicit Apply interaction there (i.e. how can you prevent someone from entering a string that is too short). Besides it doesn’t really solve the value is always required case, does it?
Also a nice idea IMO!
But probably quite hard to achieve at least in the default editing mode. And it still doesn’t prevent the inconsistent node to exist
Why? I’m only concerned by misuse of your feature, which is quite tempting to misuse it
I think we should have a global validation state that would include the inline editors. While there are errors you just wouldn’t be able to publish. I sincerely believe that it would feel much better UX-wise.
Yep, that targeted the second point about having guided input.
Quite a lot to read. I’ve used Flowpack.NodeTemplates and also Wwwision.Neos.CreationDialogProperties in quite a few projects now. I even use both of them in the same project. Why that? The reason is quite simple: I want to provide the editor with a nice experience. So, if he adds a new date for an event/workshop (for example), he gets a nice dialog where he can define the specific date. In this case, I don’t create child nodes. So I use the package from @bwaidelich. Another case: He wants to use a slider. He just put some images on the dialog and the child nodes a created automatically. In this case, I use the package from @dimaip.
I like the way that I can add properties in an easy, understandable with the option showInCreationDialog : true. It is fast and easy; I don’t have to repeat myself. If I need more power, I use Flowpack.NodeTemplates.
In the end, it is about the editor: Make him his life as comfortable as possible. And I got some lovely feedback from them about precisely the usage of the creation dialog.
Conclusion:
I would love to see this functionality in the neos core. Yes, it would need some polish, of course. Yes, perhaps people would use it in a way, we think it is not correct. But this is the risk with everything.
Another thing about structured editing: I’m a big fan of this. Really. But we have quite a few customers who wouldn’t like it. They would stick to the standard view. Which is ok.
Just my two cents
Last words: Thanks @bwaidelich and @dimaip for this great packages! They made a tremendous improvement!
Although I agree with @dimaip that we should try to keep editing experience consistent, I also see the need to avoid an inconsistent state as pointed out by @bwaidelich. Actually, I already use the creation dialog in some cases like intended by @bwaidelich’s package (although I use the NodeTemplates package ). We do it for the title property - why not use it for similar cases?
One benefit of moving @bwaidelich’s package to the core: We could set the showInCreationDialog option for the title property and remove the current code that sets the title. Apart from this, I see no need to move it to the core.
I just wanted to point out that the property mapping will become part of the UI / creationDialog itself (see https://github.com/neos/neos-ui/issues/2100). So setting properties will become easier via the NodeTemplates package, too.
Hello everyone
This discussion seems to have had no outcome so far. I recently discovered Bastian’s package. Before I only used the creationDialog together with NodeTemplates and while I like the new possibilies introduced with the creationDialog, I think it’s a bit cumbersome to configure.
As we promote to create different Document Node Types for different types of “pages”, I made the experience in Neos projects that it’s good to prompt users for the must-have properties in the creationDialog. So e.g. for a teacher, I want separate first and last name fields, for a news article, I want a publication date etc…
As far as I understand, we have a lack of consensus here because @dimaip is arguing that we should not have two interfaces at different places for prompting the same properties. I’m not a UX expert, but based on my experience with other software it’s quite usual (which of course still doesn’t mean that it’s a good practise) to prompt some basic data in a creation dialog.
E.g. in Photoshop, settings like the canvas size, color space etc. are selected in the creation dialog and can later be edited in different interfaces.
I agree that for simple data structures (such as a time entry in Toggl) it doesn’t make sense to have a different UX for creating and editing. But in case of a Neos node, I go with @bwaidelich by seeing the inspector more as a “power tool”, especially once there is a new way of structured editing (as “previewed” at Neoscon).
Hi!
If so many people see the possibility of editing properties in a wizard so appealing I in no way want to be blocking it, just shared my concerns.
Btw, now it’s possible to use validation inline: https://github.com/neos/neos-ui/pull/2538
Just a little reminder: We already have this UX for document nodes where the user is asked to enter a title before creation and can change it afterwards in the inspector (or inline if the template provides this)
I love that new feature and I think it’s totally in line. Because previously you could require a property via the CreationDialog but the editor could reset it if it was inline editable.
For me it is not a replacement though, especially for properties that are not inline editable.
Yeah, for the reason that we need it for uriPathSegment generation, would love if it wasn’t necessary and we would just generate that path segment on first publish
Anyways, I think it’s quite clear that the majority of us want this feature, so I’m stepping aside with my arguments
After failing to find a common solution i also came to the conclusion that the solution of CreationDialogProperties should be a core feature while nodeTemplates has an advanced featureset and is provided by a package.
The only question to me is which key to use? options.showInCreationDialog is obviously not correct for a core-feature maybe ui.showInCreationDialog . That looks a bit better to me but it does not make clear that it copies values from ``ui.inspector` .
I’m finally able to excavate this one again and want to prepare a PR to (hopefully) included into Neos 5.1.
There are some more caveats (like editors with modals not working yet) but that is indeed the main question…
Currently we have: properties.<propertyName>.options.showInCreationDialog but that was obviously just a work around to get this feature in without having to change the schema.
I would go for properties.<propertyName>.ui.showInCreationDialog for now:
).
I’ve used 