Thanks @CharpentierLucas !
+1 for the names. Out of curiosity, where do you place the code macro that have typed content but a generated (highlighting) output?
For I3, it is not clear to me what happens when a macro has mandatory parameters? Is it excluded from quick actions?
It also feels in contradiction with I5 since displaying the modal shouldn’t be conditioned by how a macro is inserted.
For E1 I would rephrase to mention
- Never show an empty area
- Never show a technical error (or only as a secondary debug helper)
- If the actual rendering cannot be displayed in edit mode, provide information detailing which macro it is and what it will display.
For C4 I would extend it to user assistance more generally:
- The user must never have to type by hand something that can be suggested (e.g., a document reference through a picker)
- But, always make it possible to do so (e.g., pasting a document reference as a string from the clipboard).
Some other criteria we could consider:
- Early validation: Always raise an error for inconsistencies and invalid values that can be caught before submitting (E2 is still needed for users not using WYSIWYG).
- Rights: A variant is to not propose to users macros that they can’t use because of their rights (and by extension, hide properties a given user can’t use because of their rights)
- Dependencies: A field whose value or relevance depends on another field is hidden or disabled until that field is filled.