as part of the work on refactoring the Macro Config UI I discovered that currently we are automatically hiding from the Macro Config modal any parameter that can be edited in-place in the editor.
So for example, if you’re typing /warning in the editor for inserting a new warning box macro, and hit enter, then you have the warning box macro inserted with the possibility to insert a content immediately in the editor.
I personally find it disturbing that the list of parameters displayed in the modal change depending on what can be edited in-place. I think that the modal should always display all the parameters that can be edited, even if some can also be edited directly through the editor.
Note that however as @mflorea mentioned on the chat the modal won’t have same editing capabilities, especially for the content where it’s only displaying the wiki editor (no wysiwyg).
wdyt, should we change current behaviour to always show all parameters even those that can be edited in-place?
I’m OK with both concepts (maybe with a slight preference for not crowding the modal by default).
But the fact that setting the title in the model make it “disappear” from the modal is quite a WTF for me. Everything which is supported by in-place editing should ideally always be supported (even if empty), and then it won’t be displayed in the modal from the start.
Yeah the problem is that when you insert the macro it’s {{warning}} so we don’t display the div for the title, and when you start putting a title it becomes {{warning title=""}} and AFAIK we don’t test that the title value is actually empty to remove the parameter, so the div for the title is displayed even if the parameter is empty.
I prefer the current behavior because, as Thomas said, it declutters a bit the macro edit modal.
The problem is that the macro code can decide to hide from the output the part that corresponds to a parameter when the value of that parameter satisfies some condition (e.g. is not set or empty). The WYSIWYG editor doesn’t know which parameters are editable in-line until it gets the macro output. So the macro output dictates which parameters are editable in-line. But when you insert a new macro you don’t have the output yet. You have it only when editing an existing macro.
Both are okay for me, with a slight preference for consistency in the edit UI (and creating a bit of clutter). IMO if we want to keep things as they are, we need to take more care about the user experience. When showing everything, no matter the situation and macro, the user experience will be at worst “okay”. Not perfect but not too bad either. Right now, probably because we don’t spend enough time updating/bugfixing it, the UX was confusing.
AFAIK, usually there’s only “content” and sometimes one other parameter that are inline editable. Adding one or two important parameters to the edit modal is not creating much clutter.
TLDR: Always showing every parameter is not much clutter IMO and does not degrade the UX as fast if not maintained, so it’s probably a better overall UX on the long term.
Personally I don’t use the WYSIWYG editor much (as a user I have a preference for wiki editing), and I got confused a few times because some macros I could edit their content from the edit modal, while most macros I needed to close the edit modal in order to edit the content. The difference between the two macros (one is inline editable and not the other) is not straightforward to link to this difference in content of the edition modal.
I have to say that I find the current behavior annoying. When inserting macros where I want to insert, e.g., some formatting or another macro in the content or a parameter, and I know that something can be edited inline, I frequently insert some dummy text that I replace once the macro has been inserted. To me, this shows that the current workflow isn’t good.
Maybe we could introduce metadata to indicate that a certain parameter or the content can be edited inside the editor, and then hide them from the macro dialog? A problem is of course that this could depend on other parameters. Also, we still don’t support content editing for inline macros.
I think what makes this problem even worse is that we cannot use the WYSIWYG editor for editing the content or parameters with wiki type, which makes the experience in the macro dialog much worse. While this might be a separate problem, I think it is connected - if the experience wasn’t worse, there would be less reason to hide them. Maybe that’s something that could be solved with a new editor?
Another aspect that I see is that if a large part of the page is wrapped in a macro, it really doesn’t make much sense to have that large part of the page content in the dialog.
Maybe a middle ground could be to:
Introduce a way for macros to indicate if their content can be edited inline.
Hide the content right from the start when the macro indicates that it can be edited inline.
If the macro doesn’t indicate anything, keep the current behavior for the content, i.e., display it initially and hide it later when it can be edited.
Basically, the aim would be to gradually get to a state where you never write the content in the macro dialog but always inline.
For parameters, I think I would prefer to always show them.
