On Mon, Jan 11, 2016 at 4:09 PM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
On 11 Jan 2016 at 15:08:12, vincent(a)massol.net (vincent(a)massol.net(mailto:
vincent(a)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(a)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(a)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(a)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(a)xwiki.com(mailto:
mariusdumitru.florea(a)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(a)xwiki.org
> >
http://lists.xwiki.org/mailman/listinfo/devs
> >
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
>
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs