Hi, IMO, option B feels like "the right way". It's clean and does not affect the productivity of neither advanced users, since just like the fact that not all advanced users are developers, neither are they all testers :)
Additionally, option B also intorduces a nice structure in the UIXs of the editors which would become very handy for the developers of future editors. Right now, it's just a pile of editors (no grouping), while we have clearly identified "categories" for editors (WYSIWYG, Wiki source, object, class, etc.). I also realize that the effort in having B done right is considerably larger than doing A so maybe another (less ideal but more realistic) option would be to aim/plan for B in future iterations and just do A for now, since resources are limited. Regarding the name for the old WYSIWYG editor... we`re lucky right now that only advanced users might be exposed to whatever we come up with :) Thanks, Eduard On Mon, Jan 11, 2016 at 4:53 PM, Ecaterina Moraru (Valica) < [email protected]> wrote: > On Mon, Jan 11, 2016 at 4:09 PM, [email protected] <[email protected]> > wrote: > > > > > > > > > On 11 Jan 2016 at 15:08:12, [email protected] ([email protected] > (mailto: > > [email protected])) wrote: > > > > > Note that if the admin doesn’t want to show multiple editors to its > > user, he should not install multiple editors either :) > > > > > > (ofc there’s a problem right now in that the current editor is not an > > extension that you can uninstall). > > > > > > For advanced users, I still think it’s best to show all the active > > editors (in addition to the default which is set by the admin - We could > > have “(Default)” next to it in the menu. With UC3 the admin can decide > > whether he wants to make only 1 editor avail or several. > > > > Which is kind of nice if you want to let your users testdrive some new > > editor (such as the Realtime one for example - it’d be a pain to have to > go > > back to the your profile and constantly switch back and forth between > > editors) > > > > The purpose of users is to get the job done, not test and experiment with > different editors. > > Thanks, > Caty > > > > > > Thanks > > Vincent > > > > > Thanks > > > -Vincent > > > > > > > > > On 11 Jan 2016 at 14:52:46, Ecaterina Moraru (Valica) ( > [email protected] > > (mailto:[email protected])) wrote: > > > > > > > Hi, > > > > > > > > I prefer B: I prefer to have things simpler for the user, while > > providing > > > > power to the administrator. > > > > > > > > There can be multiple extensions that integrate themselves inside > that > > menu > > > > (like the real-time editor) but I don't see that as a benefit for the > > user, > > > > but more confusing about all the types of editors. > > > > > > > > We already have 3 modes: WYSIWYG, Wiki, Inline + Objects + Class .... > > we > > > > need to find ways to simplify that, rather than adding more things in > > the > > > > menu (even if only for advanced users). > > > > > > > > The administrator should select the preferred editor from > > Configuration - > > > > Edit Mode Settings - Editor - Default Editor (for the farm or per > > wiki). > > > > The user will use the default value provided by admin or overwrite it > > from > > > > his User Preferences (if he is advanced and knows about the existence > > of > > > > multiple editors). > > > > By default we should select the recommended editor to be used and > this > > > > should be changed just in exceptional / desired cases. > > > > > > > > Having multiple editors available is not something a normal user > would > > care > > > > about and doesn't provide additional/different benefits for the user. > > > > Important is to provide the best tool by default. > > > > > > > > When adding the CKEditor first you will need to configure the wiki in > > order > > > > to use it. After a testing period we can change the default editor if > > we'd > > > > like. > > > > > > > > Off topic: I think that the Page syntax preference in the Document > > > > Information should be removed. There are not that many variations > > between > > > > 2.0 and 2.1 and I don't see why a normal user would care or want to > > chance > > > > the syntax. The users should rely on the default/recommended and the > > > > default is configured from Administration. > > > > > > > > Comment A: "GWT WYSIWYG" that would look super cryptic :) > > > > > > > > Thanks, > > > > Caty > > > > > > > > > > > > > > > > > > > > On Mon, Jan 11, 2016 at 3:27 PM, [email protected] > > > > wrote: > > > > > > > > > > > > > > > > > > > On 11 Jan 2016 at 14:16:40, Marius Dumitru Florea ( > > > > > [email protected](mailto: > [email protected] > > )) > > > > > wrote: > > > > > > > > > > > On Mon, Jan 11, 2016 at 2:00 PM, [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? > > > > > > > > > > Ok cool if they’re covered by A and B (it wasn’t mentioned in your > > email…). > > > > > > > > > > Note that currently there’s no default choice anymore for advanced > > users > > > > > when they edit a page and we’d need to put that back (that’s UC4). > > > > > > > > > > Apart from this, I think I prefer A) than B). > > > > > > > > > > Thanks > > > > > -Vincent > > > > > > > > > > > > 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 > > > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
