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