RFC: Allow Node properties to appear in the Creation Dialog


(Bastian Waidelich) #1

TL;DR

Should the showInCreationDialog option get a core feature for the upcoming Neos version?

Background:

I brought up this topic before (see Slack history) and created a ticket for this.

But as it seems to be a little bit controversial, I’d like to get your opinions on whether this could be a core feature for Neos 4.2.

@dimaip had the following concerns

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.

…and suggested to use the Flowpack.NodeTemplates package instead, but:

Why not use the NodeTemplates package?

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 :slight_smile:
  • 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?

Shoot!


(Aske Ertmann) #2

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.


(Bastian Waidelich) #3

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.


(Aske Ertmann) #4

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.


(Dmitri Pisarev) #5

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:

  1. Inconsistent state and validation. Some properties need to be set before the node can be published.
  2. 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:

  1. Validation of inline properties + allow to bring some structured properties from inspector inline (aka structured editing)
  2. 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?


(Bastian Waidelich) #6

Thanks for the feedback!

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 :raising_hand_man:).

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


(Dmitri Pisarev) #7

Thanks for your feedback to my feedback! =)

Why? I’m only concerned by misuse of your feature, which is quite tempting to misuse it :slight_smile:

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.


Team Tiga | Team Meeting | 2018-09-12
Team Tiga | Team Meeting | 2018-09-19
(Jon Uhlmann) #8

Quite a lot to read. :wink: 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!


(Thomas Heilmann) #9

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 :wink:). 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.