> On 25 Apr 2017, at 18:46, Ecaterina Moraru (Valica) <[email protected]> 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 <[email protected]> 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 <[email protected]> >> wrote: >> >>> Hi Caty, >>> >>>> On 4 Apr 2017, at 17:56, Ecaterina Moraru (Valica) <[email protected]> >>> 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 >>> >>> >>
