On 11 Jan 2016 at 14:16:40, Marius Dumitru Florea (mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) wrote:

On Mon, Jan 11, 2016 at 2:00 PM, vincent@massol.net 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 ( mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) 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

Regarding the configuration options we could use select > optgroup in order to list multiple WYSIWYG editors, or just simply list their names. Thanks, Caty On Mon, Jan 11, 2016 at 3:52 PM, Ecaterina Moraru (Valica) < valicac@gmail.com> 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, vincent@massol.net <vincent@massol.net> wrote:

...

On 11 Jan 2016 at 14:16:40, Marius Dumitru Florea ( mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) wrote:

...

On Mon, Jan 11, 2016 at 2:00 PM, vincent@massol.net 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 ( mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com )) 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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

On 11 Jan 2016 at 15:08:12, vincent@massol.net (vincent@massol.net(mailto:vincent@massol.net)) 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) Thanks Vincent

Thanks -Vincent

On 11 Jan 2016 at 14:52:46, Ecaterina Moraru (Valica) (valicac@gmail.com(mailto:valicac@gmail.com)) 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, vincent@massol.net wrote:

...

On 11 Jan 2016 at 14:16:40, Marius Dumitru Florea ( mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) wrote:

...

On Mon, Jan 11, 2016 at 2:00 PM, vincent@massol.net 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 ( mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) 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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

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) < valicac@gmail.com> wrote:

On Mon, Jan 11, 2016 at 4:09 PM, vincent@massol.net <vincent@massol.net> wrote:

...

On 11 Jan 2016 at 15:08:12, vincent@massol.net (vincent@massol.net

(mailto:

...

vincent@massol.net)) 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) (

valicac@gmail.com

...

(mailto:valicac@gmail.com)) 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, vincent@massol.net wrote:

...

On 11 Jan 2016 at 14:16:40, Marius Dumitru Florea ( mariusdumitru.florea@xwiki.com(mailto:

mariusdumitru.florea@xwiki.com ))

...

wrote:

...

On Mon, Jan 11, 2016 at 2:00 PM, vincent@massol.net 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 ( > mariusdumitru.florea@xwiki.com(mailto: mariusdumitru.florea@xwiki.com)) > 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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

On Mon, Jan 11, 2016 at 3:52 PM, Ecaterina Moraru (Valica) < valicac@gmail.com> 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.

As I said in my initial mail, if we choose B then we need multiple configuration properties, not just one: * when you choose "Wiki" (edit mode) from the Edit menu, XWiki will have to see what editor is the default Wiki editor (Standard Wiki Editor, Real-time Wiki Editor) * when you choose "WYSIWYG" (edit mode) from the Edit menu, XWiki will have to see what editor is the default WYSIWYG editor (Standard WYSIWYG Editor, CKEditor, Real-time WYSIWYG Editor) * when you choose "Edit" (default edit action) from the Edit menu, XWiki will have to see what is the default edit mode, and then see what is the default editor for that mode. An administrator/user will have to configure this. What I don't like at B is that it's hard to discover new editors. What I don't like at A is that the entry name that will appear in the Edit menu can be cryptic (e.g. I not sure how to name the current WYSIWYG editor, that's why I put "GWT WYSIWYG" but it's obviously not good). Thanks, Marius

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, vincent@massol.net <vincent@massol.net> wrote:

...

On 11 Jan 2016 at 14:16:40, Marius Dumitru Florea ( mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) wrote:

...

On Mon, Jan 11, 2016 at 2:00 PM, vincent@massol.net 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 ( mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com )) 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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

  On 11 Jan 2016 at 18:14:32, Marius Dumitru Florea (mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) wrote:

On Mon, Jan 11, 2016 at 3:52 PM, Ecaterina Moraru (Valica) < valicac@gmail.com> 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.

As I said in my initial mail, if we choose B then we need multiple configuration properties, not just one:

* when you choose "Wiki" (edit mode) from the Edit menu, XWiki will have to see what editor is the default Wiki editor (Standard Wiki Editor, Real-time Wiki Editor) * when you choose "WYSIWYG" (edit mode) from the Edit menu, XWiki will have to see what editor is the default WYSIWYG editor (Standard WYSIWYG Editor, CKEditor, Real-time WYSIWYG Editor) * when you choose "Edit" (default edit action) from the Edit menu, XWiki will have to see what is the default edit mode, and then see what is the default editor for that mode.

An administrator/user will have to configure this.

What I don't like at B is that it's hard to discover new editors. What I don't like at A is that the entry name that will appear in the Edit menu can be cryptic (e.g. I not sure how to name the current WYSIWYG editor, that's why I put "GWT WYSIWYG" but it's obviously not good).

Note that this name is independent of A) or B). In any case we’ll need to give it a name so that the user or admin can choose it or not :) Also note that it’s as hard to choose the name of the new WYSIWYG editor because: * either mentioning the underlying tech is ok and in this case GWT is ok * or we don’t use the the underlying tech and in this case CKEditor is not correct either ;) An easy option is to have: * WYSIWYG 1.0 == Tiny MCE of before * WYSIWYG 2.0 == GWT-based WYSIWYG * WYSIWYG 3.0 == CKEditor-based WYSIWYG * WYSIWYG 4.0 == Realtime+CKEditor-based WYSIWYG If we base it on a characteristic of the editor it’s really hard (I’d say impossible) to choose a name… (only Realtime would make sense but even that is not correct because if we then have a new editor in the future, say, based on TinyMCE, then we cannot say “Realtime” anymore since it’s been used already for the version working on CKEditor. Thus so far the only thing that makes sense is the technology or the version (and the RT one would be named “Realtime CKEditor WYSIWYG”). Thanks -Vincent

Thanks, Marius

...

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, vincent@massol.net wrote:

...

On 11 Jan 2016 at 14:16:40, Marius Dumitru Florea ( mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) wrote:

...

On Mon, Jan 11, 2016 at 2:00 PM, vincent@massol.net 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 ( mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com )) 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

  On 11 Jan 2016 at 17:57:21, Marius Dumitru Florea (mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) wrote:

On Mon, Jan 11, 2016 at 3:27 PM, vincent@massol.net wrote:

...

On 11 Jan 2016 at 14:16:40, Marius Dumitru Florea ( mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) wrote:

...

On Mon, Jan 11, 2016 at 2:00 PM, vincent@massol.net 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).

There is, http://platform.xwiki.org/xwiki/bin/view/Features/PageEditing#HAdvancedMode . The first entry in the Edit menu is "Edit" which leads to the default edit mode. Of course, it's not as in Colibri, you still need to open the menu.

ok my bad then, I thought we had removed it. Thanks -Vincent

...

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 ( mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) 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

Hi Marius, On 12 Jan 2016 at 07:30:34, Marius Dumitru Florea (mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) wrote:

On Mon, Jan 11, 2016 at 1:31 PM, Marius Dumitru Florea < mariusdumitru.florea@xwiki.com> 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).

...

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.

Even though I know you already said that the use cases I defined are taken into account for (A), (B) and (C), I don’t see it in the Needs section of the 3 solutions, and I’d like to make extra sure we’re all in agreement. Specifically it’s missing the new Admin UI property for selecting which editors are available. This is "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.” I know for a fact that some users have already expressed this need. Thanks -Vincent

I'm ok with both A and C.

Thanks, Marius

...

I'm leaning towards option (A). WDYT?

Thanks, Marius

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

On Tue, Jan 12, 2016 at 9:18 AM, vincent@massol.net <vincent@massol.net> wrote:

On 12 Jan 2016 at 07:30:34, Marius Dumitru Florea ( mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) wrote:

...

On Mon, Jan 11, 2016 at 1:31 PM, Marius Dumitru Florea < mariusdumitru.florea@xwiki.com> 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/developerP...) 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). 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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

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, vincent@massol.net <vincent@massol.net> wrote:

Hi Caty,

On 12 Jan 2016 at 15:53:35, Ecaterina Moraru (Valica) (valicac@gmail.com (mailto:valicac@gmail.com)) wrote:

...

On Tue, Jan 12, 2016 at 9:18 AM, vincent@massol.net wrote:

...

On 12 Jan 2016 at 07:30:34, Marius Dumitru Florea ( mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) wrote:

...

On Mon, Jan 11, 2016 at 1:31 PM, Marius Dumitru Florea < mariusdumitru.florea@xwiki.com> 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/developerP... )

...

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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs