On Mon, Jan 11, 2016 at 2:00 PM, [email protected] <[email protected]> wrote:
> Hi Marius, > > I prefer to think in term of use cases. Here are the ones I see as > important on this topic and that I think we need to ensure that we > implement: > > UC1: Ability for admins to install an extension that contributes a new > editor > UC2: Ability for admins to select which editor is the default editor for > their users in a given wiki (note that ideally this configuration should be > per wiki for the farm use case) > UC3: Ability for admins to decide which editors are active (i.e. which > editors users will be able to configure or use). For example it should be > possible to completely replace the GWT-based WYSIWYG by CKEeditor and > preventing any user from using the GWT-based WYSIWYG editor. > UC4: Ability for a user (simple or advanced) to explicitly decide which > default editors he/she’ll use (in his/her user profile probably). Should > override the editor selected in UC2 (but they should only see editors that > are active, cf UC3) > UC5: Ability for an advanced user to choose on the spot (on-demand) the > editor to use to edit a given page, bypassing the default editor. Should > override the editor selected in UC4. > > WDYT? > All these use cases are covered by both A and B so it doesn't help me choose one or the other. My question is more how to implement these use cases: using A or B? > > Thanks > -Vincent > > On 11 Jan 2016 at 12:31:12, Marius Dumitru Florea ( > [email protected](mailto:[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) > > > > 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) > > > > 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
