Hi Caty, wrote: 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

On 25 Apr 2017, at 18:46, Ecaterina Moraru (Valica) <valicac(a)gmail.com> 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

-- 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 <enygma2002(a)gmail.com> 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 <vincent(a)massol.net> > wrote: > >> Hi Caty, >> >>> On 4 Apr 2017, at 17:56, Ecaterina Moraru (Valica) <valicac(a)gmail.com> >> 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 >> >> >