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)
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
