I think having simpler menus is better and easier for the user. For a period we had the Syntax 1.0 editor, but that was loading only if the page has syntax 1.0. Imagine if you'd see Editor 1.0 every time you click on Edit. Also if we were to apply an alphabetical order than that Editor 1.0 would be the first option and just after the Realtime, Wiki, WYSIWYG, etc. And if it's not alphabetic, than we already decide which is better / newer / etc.
I think we should decide and propose to the user the most updated and latest editor, and let him change this setting only if he really wants to. Thanks, Caty On Tue, Jan 12, 2016 at 7:08 PM, [email protected] <[email protected]> wrote: > Hi Caty, > > > On 12 Jan 2016 at 15:53:35, Ecaterina Moraru (Valica) ([email protected] > (mailto:[email protected])) wrote: > > > On Tue, Jan 12, 2016 at 9:18 AM, [email protected] > > wrote: > > > > > > > > > > > > > > On 12 Jan 2016 at 07:30:34, Marius Dumitru Florea ( > > > [email protected](mailto:[email protected])) > > > wrote: > > > > > > > On Mon, Jan 11, 2016 at 1:31 PM, Marius Dumitru Florea < > > > > [email protected]> wrote: > > > > > > > > > Hi devs, > > > > > > > > > > I'm working on integrating CKEditor in XWiki and I'm wondering how > the > > > > > Edit menu should reflect the fact that there are multiple editors > > > > > available. I see two options: > > > > > > > > > > (A) List all the available content editors in the Edit menu (note > that > > > the > > > > > menu is visible only for advanced users). E.g. Wiki, GWT WYSIWYG, > > > CKEditor > > > > > > > > > > PROS: > > > > > * easier to implement (because there is already an UIX for this) > > > > > * easier to discover new content editors (e.g. after an admin > installs > > > an > > > > > extension that provides a content editor) > > > > > * ability to try a different content editor than the one configured > > > (i.e. > > > > > without updating the configuration) > > > > > > > > > > CONS: > > > > > * the (advanced) user might not know, at first, which content > editor to > > > > > choose from the Edit menu > > > > > * once the user has a preferred editor the other content editor > entries > > > > > become noise (the user may want to hide them) > > > > > > > > > > (B) List only the edit modes in the Edit menu. E.g. Wiki, WYSIWYG > > > > > > > > > > PROS: > > > > > * easier to choose the edit mode (wiki/source vs. WYSIWYG) > > > > > * less crowded Edit menu (easier to scan, no noise) > > > > > > > > > > CONS: > > > > > * the user needs to edit his profile to discover the available > editors > > > for > > > > > Wiki/WYSIWYG modes > > > > > * harder to try the new content editors (you need to update the > > > > > configuration) > > > > > > > > > > > > > > While discussing with Caty and Edy on this topic, Caty suggested > another > > > > option: > > > > > > > > (C) Replace "Wiki" and "WYSIWYG" entries with a *single* entry > "Content", > > > > i.e. show only one entry in the Edit menu for editing the document > > > content. > > > > This is consistent with the existing entries "Access Rights", > "Objects", > > > > "Class". > > > > > > > > PROS > > > > * simplified and consistent Edit menu > > > > * easier to implement than B (similar difficulty as A probably) > > > > > > > > CONS > > > > * the user needs to edit his profile to discover the available > editors: > > > > Wiki, WYSIWYG, CKEditor, Real-time etc. > > > > * harder to try the new content editors (you need to update the > > > > configuration) > > > > * the developers will complain there's no direct link to Wiki editor > > > (which > > > > loads faster) but they can always configure their profile. Moreover, > the > > > > current WYSIWYG editor and the CKEditor offers a way to edit the > source, > > > > it's just that you need to wait longer for the editor to load > (because > > > the > > > > editor is heavier). > > > > > > At the very least, in this solution each available editor should have a > > > keyboard shortcut. > > > > > > I’m not fond of this option for advanced users (it’s ok for simple > users). > > > > > > > +1 for C > > > > For advanced users a solution would be to have the discusses Roles (like > > Developer role, see > > > http://design.xwiki.org/xwiki/bin/download/Improvements/UserRoles/developerPreferences.png > ) > > and decide on the best settings for advanced users (hidden, editor, etc.) > > and instead of manually selecting all the preferences, just loading the > > role settings. > > + the discussions when we provide another default user (not just Admin): > we > > could have a user for normal users and another user for developers > > (although maybe 3 default users is too much). > > So basically this would mean having a configuration option to allow to > choose between A) and C). > > Some remarks: > * We should not mix “developers” with “advanced user”. I can’t see on the > screenshot the various profile values. Is there an “Advanced User” profile? > * The problem will be the same IMO since we’d need to define a default for > the “Extra Editor Modes” property for the “developer” profile: > ** If it’s “true” by default then we have A) by default. It allows > advanced users who don’t want to see several editors to not see them (i.e. > C)) > ** If it’s “false” by default then we have C) by default and we loose > discoverability and advanced would need to turn it on to see several > editors (i.e. A)). > > At this point in time I have the feeling this config option would be > overkill. We should choose between A) and C). > > Could you explain again why you think that advanced users should not see > all the available editors? On my side, it seems logical that if there are > multiple editors available (i.e. set as available by the admin) then > advanced users should see them by default. > > Let’s see what others think. > > Thanks > -Vincent > > > > > Thanks, > > Caty > > > > > > > > > > > > It’s already a major PITA to switch on/off hidden docs, and I can > imagine > > > the same hassle for switching editors. As an advanced user, I > constantly > > > switch editors (wiki, wysiwyg). The shortcuts may offer a good-enough > > > alternative but it means each editor extension would need to come with > a > > > shortcut (or have some generic 3-letter shortcuts such as ctrl + E + 1 > for > > > editor 1, ctrl + E + 2 for editor 2, etc) and this is not that easy. > > > > > > Note that this issue with shortcuts also exists in the other solutions > (A). > > > > > > Thanks > > > -Vincent > > > > > > > > Let's see what we need for each option: > > > > > > > > > > (A) Needs: > > > > > * UIX in the Edit menu (already available) > > > > > * 1 configuration option ("editing.content.defaultEditor") to > configure > > > > > the default editor (at farm/wiki/space/user level). We can probably > > > extend > > > > > the "Default editor to use" preference from the user profile to > show > > > all > > > > > the available content editors. > > > > > > > > > > (B) Needs: > > > > > * 3 configuration options: > > > > > ** default edit mode (Wiki vs. WYSIWYG), already available in the > user > > > > > profile > > > > > ** default Wiki mode editor (only one editor for now so we can > skip it) > > > > > ** default WYSIWYG mode editor (GWT-based vs. CKEditor) > > > > > > > > > > > > > (C) Needs: > > > > * 1 configuration option ("editing.content.defaultEditor") to > configure > > > the > > > > default editor (at farm/wiki/space/user level). We can probably > extend > > > the > > > > "Default editor to use" preference from the user profile to show all > the > > > > available content editors. > > > > > > > > I'm ok with both A and C. > > > > > > > > Thanks, > > > > Marius > > > > > > > > > > > > > I'm leaning towards option (A). WDYT? > > > > > > > > > > Thanks, > > > > > Marius > > > > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
