[Proposal][UX] Bundle Menu app in XWiki

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Proposal][UX] Bundle Menu app in XWiki

Ecaterina Moraru (Valica)
Hi devs,

Another idea for this roadmap is if we want to bundle the Menu App inside
XWiki.

I've tried to list the current issues at:
http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaDefaultMenu
with a proposal for a default menu instance.

WDYT?

Thanks,
Caty
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal][UX] Bundle Menu app in XWiki

vmassol
Administrator
Hi Caty,

> On 4 Apr 2017, at 17:56, Ecaterina Moraru (Valica) <[hidden email]> wrote:
>
> Hi devs,
>
> Another idea for this roadmap is if we want to bundle the Menu App inside
> XWiki.
>
> I've tried to list the current issues at:
> http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaDefaultMenu
> with a proposal for a default menu instance.
>
> WDYT?

I‘m failing to understand the need for this menu by default. Could you explain it? Maybe add some info to the design page about it. The “Requirement” should be a real requirement, instead of saying “bundle the menu app by default”.

I understand that some users may want to have an horizontal menu but are you sure that this is true for all users? Do we consider that having a menu is something so common that we need to bundle the app by default?

Also is the primary need to have a horizontal menu or to be able to easily create a custom navigation panel?

And even if we bundle the app by default, should we activate it by default?

Couldn’t we have a link on the home page or in the Help Center to install it with one click should it be needed? Wouldn’t that be enough?

Now regarding the issues you listed, here’s my POV:
* I agree it’s not nice to see the entry in the App Panel by default and in the Navigation tree.
* I would rename the Menu space’s home page to “Menu” instead of “Menu Home”, to be consistent with other names.
* I would restrict the usage of it to Admin users by default (ie protect the Menu app space to admins by default)
* I also agree it’s not nice to see the Menu app in AWM. IMO it shouldn’t be an AWM app anymore if we bundle it. We had a similar issue with the Tour application (I don’t know how we solved it). I don’t think we want to have users making easily modifications to the Menu app. Thus it shouldn’t be listed in AWM apps IMO.
* It could be a good idea for the Menu app to have a sample menu activated by default when you install it (as you’ve shown in issue 3). But first I’d like to understand why we need to have the menu app by default and what we’re solving (the question I asked above).

Thanks!
-Vincent

> Thanks,
> Caty

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal][UX] Bundle Menu app in XWiki

Eduard Moraru
Indeed, the obvious need solved by the Menu application is Custom
Navigation.

With the introduction of Nested Pages, we have lost the ability to create
"shortcuts" in the hierarchy, something that we were previously able to do
with the explicit parent-child relationship, so now the storage and
navigation are the same. Relying on the Navigation panel, that expresses
all the content in a wiki, is impractical, and can only address the
"browsing" use case, something where the admin does not have control on
what the user is exposed to. Sure, a better content structuring might help,
but it can still easily get out of hand when everything you store is
considered navigation.

Writing a custom panel is a solution, however it may not be in the mental
model of someone new to XWiki, that is searching for the "menu section" to
define his custom navigation. Additionally, panels get a bit dirty by
mixing velocity (for the panel header) with wiki syntax and they might
intimidate users. They have a nice drag&drop wizard, which is great, but
I`m not sure how many admins actually edit/create panels. Finally, on a
multiwiki setup (like an intranet or even in our case, xwiki.org), relying
on a Panel for establishing a menu can be painful since you need to
configure each individual wiki to use the same, main-wiki defined, panel.

One big advantage of the Menu application is that you could create a menu,
which is basically an UIX, set it`s scope to Global and you are done. It
will be visible to all users, on all subwikis. One complication of the menu
app is that it`s designed as a user-centered application so regular users
could create their own menus as well. If we still want to leave it exposed
to users, we need to have it visible under the Applications panel. We could
rename it to "Custom Menu" application and protect the default menu to be
editable only by admins, thus trying to mitigate a bit of the confusion it
can cause to users. Even so, offering by default the ability for users to
define custom menus is not something you see often and it might do a bit
more harm than good.

One way to remove even more confusion (and I think it was mentioned) would
be to completely restrict the use of the bundled menu application to wiki
admins only and accessing the app from Administration instead (with the
configurable class mechanism).

As an alternative, we could even consider implementing a default Menu UIX
in XWiki, that admins could easily customize and that would have nothing to
do with the (custom) Menu application that is on contrib. I think I would
prefer this instead of dealing with all the complications of the menu app.

Thanks,
Eduard

On Wed, Apr 5, 2017 at 12:59 PM, Vincent Massol <[hidden email]> wrote:

> Hi Caty,
>
> > On 4 Apr 2017, at 17:56, Ecaterina Moraru (Valica) <[hidden email]>
> wrote:
> >
> > Hi devs,
> >
> > Another idea for this roadmap is if we want to bundle the Menu App inside
> > XWiki.
> >
> > I've tried to list the current issues at:
> > http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaDefaultMenu
> > with a proposal for a default menu instance.
> >
> > WDYT?
>
> I‘m failing to understand the need for this menu by default. Could you
> explain it? Maybe add some info to the design page about it. The
> “Requirement” should be a real requirement, instead of saying “bundle the
> menu app by default”.
>
> I understand that some users may want to have an horizontal menu but are
> you sure that this is true for all users? Do we consider that having a menu
> is something so common that we need to bundle the app by default?
>
> Also is the primary need to have a horizontal menu or to be able to easily
> create a custom navigation panel?
>
> And even if we bundle the app by default, should we activate it by default?
>
> Couldn’t we have a link on the home page or in the Help Center to install
> it with one click should it be needed? Wouldn’t that be enough?
>
> Now regarding the issues you listed, here’s my POV:
> * I agree it’s not nice to see the entry in the App Panel by default and
> in the Navigation tree.
> * I would rename the Menu space’s home page to “Menu” instead of “Menu
> Home”, to be consistent with other names.
> * I would restrict the usage of it to Admin users by default (ie protect
> the Menu app space to admins by default)
> * I also agree it’s not nice to see the Menu app in AWM. IMO it shouldn’t
> be an AWM app anymore if we bundle it. We had a similar issue with the Tour
> application (I don’t know how we solved it). I don’t think we want to have
> users making easily modifications to the Menu app. Thus it shouldn’t be
> listed in AWM apps IMO.
> * It could be a good idea for the Menu app to have a sample menu activated
> by default when you install it (as you’ve shown in issue 3). But first I’d
> like to understand why we need to have the menu app by default and what
> we’re solving (the question I asked above).
>
> Thanks!
> -Vincent
>
> > Thanks,
> > Caty
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal][UX] Bundle Menu app in XWiki

Ecaterina Moraru (Valica)
So we had some brainstorming in order to advance with the topic. Some
conclusions:
- We should bundle the Menu since users need a way to create custom
navigations
- We will not create a demo menu
- The bundled Menu App should not be visible by normal users, so the AppBar
and Navigation panel is not 'polluted' with it
-- We will provide some permissions so that the ApplicationEntryPoint is
visible only to Admins
-- The permission changes will be provided by the Flavor, leaving the
Contrib application the ability for normal users to create custom menus (in
case they install the app in an older instance or in sub-wikis)
-- In the future, we will provide an Administration entry for the Menu so
that the Admins can discover the feature and create global navigations.
--- In that case we will hide the AppEntryPoint from the AppBar and rely on
the Administration entry, in order to not have 2 ways to access the Menu
- We should rename the "Menu Home" to "Menu"

Let me know what you think.

Thanks,
Caty


On Mon, Apr 24, 2017 at 4:07 PM, Eduard Moraru <[hidden email]> wrote:

> Indeed, the obvious need solved by the Menu application is Custom
> Navigation.
>
> With the introduction of Nested Pages, we have lost the ability to create
> "shortcuts" in the hierarchy, something that we were previously able to do
> with the explicit parent-child relationship, so now the storage and
> navigation are the same. Relying on the Navigation panel, that expresses
> all the content in a wiki, is impractical, and can only address the
> "browsing" use case, something where the admin does not have control on
> what the user is exposed to. Sure, a better content structuring might help,
> but it can still easily get out of hand when everything you store is
> considered navigation.
>
> Writing a custom panel is a solution, however it may not be in the mental
> model of someone new to XWiki, that is searching for the "menu section" to
> define his custom navigation. Additionally, panels get a bit dirty by
> mixing velocity (for the panel header) with wiki syntax and they might
> intimidate users. They have a nice drag&drop wizard, which is great, but
> I`m not sure how many admins actually edit/create panels. Finally, on a
> multiwiki setup (like an intranet or even in our case, xwiki.org), relying
> on a Panel for establishing a menu can be painful since you need to
> configure each individual wiki to use the same, main-wiki defined, panel.
>
> One big advantage of the Menu application is that you could create a menu,
> which is basically an UIX, set it`s scope to Global and you are done. It
> will be visible to all users, on all subwikis. One complication of the menu
> app is that it`s designed as a user-centered application so regular users
> could create their own menus as well. If we still want to leave it exposed
> to users, we need to have it visible under the Applications panel. We could
> rename it to "Custom Menu" application and protect the default menu to be
> editable only by admins, thus trying to mitigate a bit of the confusion it
> can cause to users. Even so, offering by default the ability for users to
> define custom menus is not something you see often and it might do a bit
> more harm than good.
>
> One way to remove even more confusion (and I think it was mentioned) would
> be to completely restrict the use of the bundled menu application to wiki
> admins only and accessing the app from Administration instead (with the
> configurable class mechanism).
>
> As an alternative, we could even consider implementing a default Menu UIX
> in XWiki, that admins could easily customize and that would have nothing to
> do with the (custom) Menu application that is on contrib. I think I would
> prefer this instead of dealing with all the complications of the menu app.
>
> Thanks,
> Eduard
>
> On Wed, Apr 5, 2017 at 12:59 PM, Vincent Massol <[hidden email]>
> wrote:
>
> > Hi Caty,
> >
> > > On 4 Apr 2017, at 17:56, Ecaterina Moraru (Valica) <[hidden email]>
> > wrote:
> > >
> > > Hi devs,
> > >
> > > Another idea for this roadmap is if we want to bundle the Menu App
> inside
> > > XWiki.
> > >
> > > I've tried to list the current issues at:
> > > http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaDefaultMenu
> > > with a proposal for a default menu instance.
> > >
> > > WDYT?
> >
> > I‘m failing to understand the need for this menu by default. Could you
> > explain it? Maybe add some info to the design page about it. The
> > “Requirement” should be a real requirement, instead of saying “bundle the
> > menu app by default”.
> >
> > I understand that some users may want to have an horizontal menu but are
> > you sure that this is true for all users? Do we consider that having a
> menu
> > is something so common that we need to bundle the app by default?
> >
> > Also is the primary need to have a horizontal menu or to be able to
> easily
> > create a custom navigation panel?
> >
> > And even if we bundle the app by default, should we activate it by
> default?
> >
> > Couldn’t we have a link on the home page or in the Help Center to install
> > it with one click should it be needed? Wouldn’t that be enough?
> >
> > Now regarding the issues you listed, here’s my POV:
> > * I agree it’s not nice to see the entry in the App Panel by default and
> > in the Navigation tree.
> > * I would rename the Menu space’s home page to “Menu” instead of “Menu
> > Home”, to be consistent with other names.
> > * I would restrict the usage of it to Admin users by default (ie protect
> > the Menu app space to admins by default)
> > * I also agree it’s not nice to see the Menu app in AWM. IMO it shouldn’t
> > be an AWM app anymore if we bundle it. We had a similar issue with the
> Tour
> > application (I don’t know how we solved it). I don’t think we want to
> have
> > users making easily modifications to the Menu app. Thus it shouldn’t be
> > listed in AWM apps IMO.
> > * It could be a good idea for the Menu app to have a sample menu
> activated
> > by default when you install it (as you’ve shown in issue 3). But first
> I’d
> > like to understand why we need to have the menu app by default and what
> > we’re solving (the question I asked above).
> >
> > Thanks!
> > -Vincent
> >
> > > Thanks,
> > > Caty
> >
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal][UX] Bundle Menu app in XWiki

vmassol
Administrator

> On 25 Apr 2017, at 18:46, Ecaterina Moraru (Valica) <[hidden email]> wrote:
>
> So we had some brainstorming in order to advance with the topic. Some
> conclusions:
> - We should bundle the Menu since users need a way to create custom
> navigations
> - We will not create a demo menu
> - The bundled Menu App should not be visible by normal users, so the AppBar
> and Navigation panel is not 'polluted' with it
> -- We will provide some permissions so that the ApplicationEntryPoint is
> visible only to Admins

Not just the entry point but the whole Menu space should be protected so that only admins can see it by default.

> -- The permission changes will be provided by the Flavor, leaving the
> Contrib application the ability for normal users to create custom menus (in
> case they install the app in an older instance or in sub-wikis)
> -- In the future, we will provide an Administration entry for the Menu so
> that the Admins can discover the feature and create global navigations.

Note that it will also be listed in Application Index for discoverability but it may not be enough indeed.

> --- In that case we will hide the AppEntryPoint from the AppBar and rely on
> the Administration entry, in order to not have 2 ways to access the Menu
> - We should rename the "Menu Home" to “Menu"

Thanks
-Vincent

> Let me know what you think.
>
> Thanks,
> Caty
>
>
> On Mon, Apr 24, 2017 at 4:07 PM, Eduard Moraru <[hidden email]> wrote:
>
>> Indeed, the obvious need solved by the Menu application is Custom
>> Navigation.
>>
>> With the introduction of Nested Pages, we have lost the ability to create
>> "shortcuts" in the hierarchy, something that we were previously able to do
>> with the explicit parent-child relationship, so now the storage and
>> navigation are the same. Relying on the Navigation panel, that expresses
>> all the content in a wiki, is impractical, and can only address the
>> "browsing" use case, something where the admin does not have control on
>> what the user is exposed to. Sure, a better content structuring might help,
>> but it can still easily get out of hand when everything you store is
>> considered navigation.
>>
>> Writing a custom panel is a solution, however it may not be in the mental
>> model of someone new to XWiki, that is searching for the "menu section" to
>> define his custom navigation. Additionally, panels get a bit dirty by
>> mixing velocity (for the panel header) with wiki syntax and they might
>> intimidate users. They have a nice drag&drop wizard, which is great, but
>> I`m not sure how many admins actually edit/create panels. Finally, on a
>> multiwiki setup (like an intranet or even in our case, xwiki.org), relying
>> on a Panel for establishing a menu can be painful since you need to
>> configure each individual wiki to use the same, main-wiki defined, panel.
>>
>> One big advantage of the Menu application is that you could create a menu,
>> which is basically an UIX, set it`s scope to Global and you are done. It
>> will be visible to all users, on all subwikis. One complication of the menu
>> app is that it`s designed as a user-centered application so regular users
>> could create their own menus as well. If we still want to leave it exposed
>> to users, we need to have it visible under the Applications panel. We could
>> rename it to "Custom Menu" application and protect the default menu to be
>> editable only by admins, thus trying to mitigate a bit of the confusion it
>> can cause to users. Even so, offering by default the ability for users to
>> define custom menus is not something you see often and it might do a bit
>> more harm than good.
>>
>> One way to remove even more confusion (and I think it was mentioned) would
>> be to completely restrict the use of the bundled menu application to wiki
>> admins only and accessing the app from Administration instead (with the
>> configurable class mechanism).
>>
>> As an alternative, we could even consider implementing a default Menu UIX
>> in XWiki, that admins could easily customize and that would have nothing to
>> do with the (custom) Menu application that is on contrib. I think I would
>> prefer this instead of dealing with all the complications of the menu app.
>>
>> Thanks,
>> Eduard
>>
>> On Wed, Apr 5, 2017 at 12:59 PM, Vincent Massol <[hidden email]>
>> wrote:
>>
>>> Hi Caty,
>>>
>>>> On 4 Apr 2017, at 17:56, Ecaterina Moraru (Valica) <[hidden email]>
>>> wrote:
>>>>
>>>> Hi devs,
>>>>
>>>> Another idea for this roadmap is if we want to bundle the Menu App
>> inside
>>>> XWiki.
>>>>
>>>> I've tried to list the current issues at:
>>>> http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaDefaultMenu
>>>> with a proposal for a default menu instance.
>>>>
>>>> WDYT?
>>>
>>> I‘m failing to understand the need for this menu by default. Could you
>>> explain it? Maybe add some info to the design page about it. The
>>> “Requirement” should be a real requirement, instead of saying “bundle the
>>> menu app by default”.
>>>
>>> I understand that some users may want to have an horizontal menu but are
>>> you sure that this is true for all users? Do we consider that having a
>> menu
>>> is something so common that we need to bundle the app by default?
>>>
>>> Also is the primary need to have a horizontal menu or to be able to
>> easily
>>> create a custom navigation panel?
>>>
>>> And even if we bundle the app by default, should we activate it by
>> default?
>>>
>>> Couldn’t we have a link on the home page or in the Help Center to install
>>> it with one click should it be needed? Wouldn’t that be enough?
>>>
>>> Now regarding the issues you listed, here’s my POV:
>>> * I agree it’s not nice to see the entry in the App Panel by default and
>>> in the Navigation tree.
>>> * I would rename the Menu space’s home page to “Menu” instead of “Menu
>>> Home”, to be consistent with other names.
>>> * I would restrict the usage of it to Admin users by default (ie protect
>>> the Menu app space to admins by default)
>>> * I also agree it’s not nice to see the Menu app in AWM. IMO it shouldn’t
>>> be an AWM app anymore if we bundle it. We had a similar issue with the
>> Tour
>>> application (I don’t know how we solved it). I don’t think we want to
>> have
>>> users making easily modifications to the Menu app. Thus it shouldn’t be
>>> listed in AWM apps IMO.
>>> * It could be a good idea for the Menu app to have a sample menu
>> activated
>>> by default when you install it (as you’ve shown in issue 3). But first
>> I’d
>>> like to understand why we need to have the menu app by default and what
>>> we’re solving (the question I asked above).
>>>
>>> Thanks!
>>> -Vincent
>>>
>>>> Thanks,
>>>> Caty
>>>
>>>
>>

Loading...