Replace the “WYSIWYG” link to use the inplace editor and not the standalone one
Add a menu level named “Content” and move the “WYSIWYG” and “Wiki” entries under it, to make it clearer that they are about editing the content only.
Add a menu level named “Form” that replaces “Inline form” and under it add an entry “WYSIWYG” that you’d choose for form editing with the standalone WYSIWYG editor.
This will allow to add 2 entries for the Blocknote editor: one under “Content” and one under “Form” and the label could be “BlockNote” or “BlockNote WYSIWYG”.
I’d be -1 for this: whenever I go in the advanced edit menu to click in “WYSIWYG” it’s actually to get access to the standalone wysiwyg editor, since the Edit button by default leads to the inplace wysiwyg editor.
Now it would probably make sense for consistency to see both of them in this menu: so I’d be ok to see a supplementary entry, and it would make sense if e.g. a user has configured their editor to use the wiki editor by default and wants to access inplace or standalone wysiwyg editor.
+0 for this but then IMO we’d need a menu level for class/object editors for consistency.
Ok @mflorea has explained more to me and I now understand that my proposal cannot work for the inplace editor part. The reason is that we cannot have the inplace editor used to just edit the content as it works on top of the view mode (which applies sheets). Even if imagined introducing a view mode with some URL parameter to not apply sheets, then we would have 2 problems: 1) the view mode would look weird and not what users expect to see for a wysiwyg mode and 2) it would be dangerous (take the example of an app that uses page content to hold groovy script examples and the sheet puts a {{code}} macro around the examples).
Add a menu level named “Content” and move the “WYSIWYG” and “Wiki” entries under it, to make it clearer that they are about editing the content only.
Rename “WYSIWYG” into “Standalone WYSIWYG” to make it consistent with “In-place WYSIWYG” (see below)
Add a menu level named “Form” that replaces “Inline form” and under it add an entry “Standalone WYSIWYG” that you’d choose for form editing with the standalone WYSIWYG editor.
Add a new “In-place WYSIWYG” entry under “Form” for the cases when the user’s default editor is not the inplace one. Note: We could decide to display that entry only the default editor is NOT the inplace one.
(optional) Remove the “Standalone WYSIWYG” entry under “Form” when the page has no sheet. I’ve always found it strange to click that mode when there’s no sheet. You just view something but you cannot edit anything and you have the save buttons and all. I just hope it’s not costly to find out that there’s no form.
Add a “MetaData” menu entry and move “Objects” and “Class” under it.
This would allow to add 2 entries for the Blocknote editor: one under “Content” and one under “Form” and the label could be “BlockNote” or “BlockNote WYSIWYG”.
WDYT?
PS: I’m so used to what we have now that it feels a bit strange but 1) this is for advanced users and 2) what we have is not very consistent and with the introduction of BlockNote it might be even weirder to not change anything.
There’s no “In-place WYSIWYG” under the “Content” menu level? Honestly I’m not quite sure to see the distinction between the “Standalone WYSIWYG” you have under “Form” and the one you have under “Content” but that might be because I almost never used Inline form option…
Generally speaking I wouldn’t change the options based on the default preferences of the user or the wiki: AFAIK we always displayed the Wiki entry even if the wiki was configured to use wiki editor by default and I think it’s good for users: if you use different wikis with different values of default editor at least you’re not lost in the menu.
We cannot edit the page content with the inplace editor (as I’ve tried to explain above the new proposal).
“Form” might not be the best wording but the idea is to say that you’re editing with sheets applied (but it’s too technical to use “Sheets”). If you can find a better word, please suggest it.
So to clarify a bit: we can edit the page content with the inplace editor when the page doesn’t have a sheet used. And it’s actually the default behaviour when you edit e.g. Sandbox or Home. So I would display that entry under Content when there’s no sheet.
On the other hand, when there’s no sheet, the full “Form” category shouldn’t be used at all, so we could decide to not have it in such case.
Note that we should probably always displays the options in the menu entry but just disable the buttons, maybe with a bit of explanations in the title. We might need some @tkrieck input here.
Honestly for now, it’s probably simpler to just list all enabled editors, after all it’s only for advanced users, so I would expect having everything to be a bit less confusing for those (but of course it’s good to improve a bit how the list is organized, and the editors display names, to be a bit less messy).
We should disable when something is only temporarily unavailable, meaning that the user can do something in the document and then these options would be enabled.
Otherwise, completely hiding these options would be best to clean the menu. Permissions don’t allow the user to interact with these options, for example.
Regarding the proposal, I’m ok with it since it’s for advanced users only. For regular users, the concepts of WYSIWYG, in-place vs standalone would be very confusing.
If we name one editor in this menu, I would also name the alternative to it. Meaning that we get a BlockNote entry and a CK entry as well. I would also state which is the default one. This ensures that the user is seeing an alternative to the default editor, defined in the Admin sections.
Examples: “CK Editor (default)”, “BlockNote” OR “Standalone CK Editor (default)”, “Standalone Block Note”. The "standalone” string might get the menu too large IMO, though, with or without the editor name.
Don’t know if the users need to know the implementation detail and it’s not like we’ll have tons of different wysiwyg editors. So one option is to use “Block WYSIWYG” to indicate a Block editor, which is the main differentiating characteristic with the inplace and standalone editors.
Now I think it’s also fine to name the editor by the implementation especially since in the Admin UI you get to choose which wysiwyg editor to use and there we specify CKEditor and BlockNote. So it makes sense to be consistent.
So, all in all, it’s probably best to use the later with:
CKEditor Standalone
CKEditor In-Place
BlockNote
Wiki
Adding the “WYSIWYG” suffix could be nice but is probably too long, right?
I agree, I mentioned CK because you had BlockNote in place, but perhaps they can be changed to something like “Standard Editor” and “Block Editor”. The main point is for them to remain consistently named.
Yes, I guess so. I’m not a big fan of the WYSIWYG acronym, but for an advanced user’s feature, perhaps it’s not too bad.
If you ask me, the ways in which you can edit a wiki page are:
Inplace (directly from view mode):
for a plain wiki page (no sheet applied): the page title and content are made editable in view mode
for a structured page (sheet applied): there is an edit icon after the property label to edit that property alone
Form (edit mode, usually different from view mode):
default form, allows editing the page title and content, used by plain wiki pages (no sheet applied)
custom form, used by structured pages that have a sheet applied
objects form
class form
We basically have multiple forms that allow us to edit various fields of a wiki page:
Inplace form, using view mode, when no sheet is applied, allowing to edit the title and the content
Default form, using edit mode, when no sheet is applied, allowing to edit the title and the content
Custom form, using an edit mode that mimics the view mode, when a sheet is applied, allowing to edit whatever fields are exposed by the sheet
Objects form
Class form
When no sheet is applied, the options are:
Inplace form
Default form
Objects form
Class form
When a sheet is applied the options are:
Custom form
Objects form
Class form
Some of the fields included in these forms require a special widget / picker to simplify the way we input their values. Moreover, for some fields, such as the page content field, we can have multiple pickers to chose from (e.g. plain text, CKEditor, BlockNote). Users can configure the preferred picker, but that’s not enough. We want advanced users to open one of the previously listed forms using a different picker than the preferred one. On top of this, for some fields, we group the picker options into categories (e.g. Wiki and WYSIWYG). This obviously creates a lot of complexity in the Edit menu:
Default form with preferred content picker (i.e. using the preferred category and the preferred picker from that category)
(overwrite the category)
Default form with preferred content picker from Wiki category
Default form with preferred content picker from WYSIWYG category
(overwrite the actual picker)
Default form with plain textarea as content picker
Default form with CKEditor as content picker
Default form with BlockNote as content picker
Now imagine we introduce a new title picker, besides the plain text one. Do we start exposing all possible combinations of title and content pickers in the Edit menu, for all forms that include the title and the content fields?
The content field is of course the most important one, so it deserves some shortcuts in the Edit menu, but we should be aware that this approach is not scalable if we apply it to other fields as well.
The way I see it, the Edit menu could look like this:
when no sheet is applied and there is a single WYSIWYG editor available:
Thanks @mflorea for taking the time to brainstorm about this.
ok that’s one way of seeing it (a technical one). But that just means that everything is a form and thus the form term is no longer a discriminator and shouldn’t be used IMO as it’s technical and doesn’t bring value. It can be replaced by “Editor” which is a lot more user-friendly (and which I prefer over “Mode” which is less precise).
Good point. In theory indeed, we could have several edit pickers for a given form input type (like several date pickers for example). But we’re not going to let the user hand pick each editor to use for each input type. So I’m fine with what we do, which is to call “Editor” a selection of input pickers. And then only offer the most obvious Editors in the list. Note that an editor could make its pickers configurable in the User Profile and/or Admin UI. My point is just that you wouldn’t select them at the time of Edit.
Sounds good but I’d bring some minor changes:
Replace “form” with “Editor” (and use the plural, i.e. “Editors”)
Use “In-place” instead of “Inplace”. Note that in the new doc we use “in-place” (haven’t checked what we used in the old doc)
I find it hard to understand “In-place” vs “Default” for users. Right we differentiate them by using In-place vs Standalone. Note that we don’t call the wiki editor “Standalone” because there’s no in-place wiki editor, but we could call it that. So I’d be in favor of continuing to use “Standalone” to mean an editor that has its own fullscreen UI (ie you have to navigate to it).
Sounds good but for consistency, I’d use WYSIWYG (BlockNote) instead of BlockNote.
Some remarks/questions:
As mentioned above, I’d use “Custom Editor”. However this is a relatively large change from “Inline/Form”. We’d need to rewrite a lot of doc parts to use “Custom Editor” instead. I’m not against it though.
Re “Blog Post”, I guess it’s an example of a page that has a Sheet binding bound to the Blog Post Class, right? And if the page has multiple Sheet binding to different xclasses then we would list all of them, right? Sounds nice.
More questions:
When there’s a sheet, are you sure that there’s no use case where we could want to edit just the title or content without going through the Custom Editors? For example imagine a sheet that doesn’t use the content (it uses only xobjects) and you want to edit the content to write something in it for some reason.
The problem I have with “Editor” is that we use it often to refer also to the picker used for a given field, like the content field. For instance, “WYSIWYG editor” can mean:
the actual widget / picker used to edit the content of the page (e.g. CKEditor and BlockNote are WYSIWYG editors)
the default form where the content field is using a WYSIWYG editor (like CKEditor or BlockNote)
If we use editor instead of form then something like this will sound confusing:
The default editor can use either the WYSIWYG editor or the Wiki editor for editing the page content
vs.
The default edit form can use either the WYSIWYG editor or the Wiki editor for editing the page content
I’m fine with this if we accept the confusion I mentioned above.
No problem.
I’m OK with this. So what you’re proposing instead is basically:
Yes. We’d have to see how the “Blog Post” label is computed from the sheet (e.g. if we use a property on the sheet, or if we take it from the template provider).
For this, we can:
either replace “In-place Editors” with “Custom Editors” when there’s a sheet, keeping the rest
or introduce a way to force viewing a page without any sheet, as if it were a plain wiki page; from that view you would get the Edit menu for a plain wiki page.
There are 2 standalone editors that can be used to edit the page content: the WYSIWYG editor or the Wiki editor.
I think it’s fine to use “Editor” as the context should clarify what we mean. And we really rarely talk about a picker being an editor (that’s for devs mostly).
Exactly
Ok for me. I’d also be ok to not have those entries (for clarity and improved usability) since the use cases to force editing just the content when there’s a form are probably pretty low, but we’d need a way through the URL for ex to force it.
I think that’s what I was discussing above and that’s way too dangerous to me:
