[Proposal] Solutions to hide some pages from the navigation panel

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Solutions to hide some pages from the navigation panel

Guillaume Delhumeau
I prefer solution 4, that's the more intuitive. You just should add a
button to enable/disable the filter, so if you really need to see
everything, you can. To me it's simple and cover 99% of everyday usages.

+1 for S4.

Thanks,

2018-05-03 17:20 GMT+02:00 Anca Luca <[hidden email]>:

> Hello all,
>
> so, if I remember correctly, the navigation panel is just a call to the
> documentsTree macro. Unless otherwise specified, my remarks below are about
> the documentTree macro features.
>
> On Wed, May 2, 2018 at 6:02 PM, Marius Dumitru Florea <
> [hidden email]> wrote:
>
> > Hi devs,
> >
> > Some users have complained that the navigation panel shows top level
> pages
> > that they don't need/want to navigate to, most importantly the XWiki
> page.
> >
> > There are multiple ways in which we can fix this.
> >
> > Solution 1: Content Page
> >
> > Create a top level "Content" page for user content and configure the
> > navigation panel to show the contents of this page.
> >
> > Pros:
> > * Namespace isolation (no conflicts between user pages and application
> > pages)
> >
> > Cons:
> > * The user may want to navigate to a top level application page (although
> > it's better to use the application panel for this instead)
> > * All the paths / references used to access the user content will start
> > with this "Content" page
> >
>
> The documentTree macro already has this feature, actually, to be able to
> start in a given root and I thought about this solution (manually
> implemented with a custom documentTree with a custom root).
> However, I think it's too restrictive (to force all content to be rooted in
> "Content") and in order to technically make it happen you'd need to change
> too many places of XWiki: the create, copy and move screens (when location
> is chosen) in order to make sure that user does not create content
> somewhere else.
>
>
> >
> >
> > Solution 2: Blacklisting
> >
> > Add support for specifying a list of (top level) pages to exclude from
> the
> > navigation panel.
> >
>
> Most of the usecases I had fall into this category, with blacklisting only
> at root level (if this makes it easier to implement or doesn't introduce
> perf. issues).
> So to me the pages to exclude would be a feature of the documentTree macro
> (which can also be used as a gadget on a dashboard).
>
>
> >
> > Pros:
> > * The user (top level) pages created later on will be visible in the
> > navigation panel
> > * The blacklist could be used to filter not only top level pages but also
> > any nested page from the navigation panel.
> >
> > Cons:
> > * The blacklist depends on the installed apps. The administrator may have
> > to update the blacklist when new applications are installed
> >
>
> Actually, this is a feature :) : any page (be it extension or user created
> content) is whitelisted until an administrator decides that it should not
> be in the tree. Note that it's the administrator that installs extensions
> on a wiki, and at least in theory it's not done every morning. For the
> management of the blacklists of the navigation panel (what navigation panel
> will pass to the documentTree macro), we can use an administration section,
> just like we do for what the applications panel displays by default :D. In
> addition, it would be consistent with what we already have!
>
>
> > * The blacklist depends on whether you view hidden pages or not. If you
> > don't view hidden pages then the blacklist probably contains 4 pages:
> Help,
> > Menu, Sandbox, XWiki (there is an application panel entry for each of
> them
> > except XWiki), which is manageable. If you view hidden pages then you
> need
> > to black list 28+ pages which is hard to manage and maintain.
> >
>
> The fact that you see too many pages when you activate hidden pages in your
> profile is a problem that is not specific to the tree, so it shouldn't
> surprise anyone that the tree also shows too many things.
> To me, seeing hidden pages is not a "regular user in production" setting,
> it's mostly for setup / development phase.
>
>
> > * The filtering needs to happen on the database (otherwise we break the
> > pagination) so the database queries will become a bit more complex, which
> > could led to some performance penalty, depending on how long the
> blacklist
> > is.
>
>
> >
> > Solution 3: Whitelisting
> >
> > Add support for controlling the list of top level pages that are
> displayed
> > in the navigation panel.
> >
>
> this is the same principle as blacklisting (only "reversed"), and as far as
> I can project now, it already has a workaround: having multiple
> documentTree calls with the root parameter set and showroots to true.
> Also, the default create button of the wiki creates pages on the root of
> the wiki, next to "Main" and this would mean that the administrator would
> need to update the navigation panel any time a page is created, which is
> way more often than "any time an extension is installed".
>
>
> >
> > Pros:
> > * the whitelist doesn't depend on the installed extensions or hidden
> pages
> > so it's easier to maintain.
> > * the whitelist can be used to order the top level pages visible in the
> > navigation panel.
> > * the whitelist can be used to show at the top level (for navigation
> > purpose) a page that is not really a top level page
> > * No performance penalty
> >
> > Cons:
> > * The user (top level) pages created later on will not be visible in the
> > navigation panel. The administrator will have to add them to the
> whitelist
> > if they are useful for the navigation. Although creating top level pages
> > should happen less often than creating nested pages under the existing
> top
> > level pages.
> >
>
> err, how? The create button displayed on the homepage - the only create
> button that you see when you start on an empty wiki - creates top level
> pages! (there's actually a bug in 9.11.3, I explicitly changed the location
> to the "Home" page, and it still created a toplevel page).
>
> Indeed, if the administrator has an idea about what would be put on the
> wiki, he can create the toplevel pages, but 1/ it's not always the case, 2/
> he might not want to, leaving users to organise their content as they wish.
>
>
> > * the whitelist controls only the first level in the tree. The next
> levels
> > will be dynamic (database queries) and with the default order.
> >
> >
> > Solution 4: Exclude extension pages
>
>
> > Exclude from the navigation panel the top level pages that belong to an
> > installed extension, allowing the administrator to make some exceptions
> > (e.g. keep the home page). The rationale is that if an installed
> extension
> > has a top level page then that page is most probably the application home
> > page which should be accessible from the application panel. This can be
> > implemented on top of solution 3 (the whitelist is basically dynamic: we
> > collect the top level pages that don't belong to an extension).
> >
>
> This is _very_ close to the cases I had, but the difference between
> "exactly" and "very close" is relevant, to me: obviously, some XWiki,
> Sandbox and other standard content needed to be removed, but also a custom
> page that I had created and manually put in the application panel.
>
> So, in my opinion, the work to do this is comparable to the work for
> implementing explicit blacklisted roots, so between this and 2, I choose 2.
>
> Long story short:
> I believe, as Vincent said, that we need to have the generic whitelist /
> blacklist parameters for the documentTree macro, in order to cover the
> maximum cases possible, and in my opinion, they all exist, because there is
> a great diversity in what users can do on the wiki but also in how they
> interpret some things: some people see applications as "special", some
> others don't, etc.
>
> For the navigation panel default blacklist we can make some dynamic
> computing of the parameters we pass to the documentTree call, e.g. all
> extensions, or some configuration in administration.
>
> As a priority choice between blacklist and whitelist, I would choose
> blacklist, as some sort of whitelist already exists, even if not fully
> complete and anyway it covers less "user content" cases than the blacklist
> one.
>
> Thanks,
> Anca
>
>
> >
> > Pros:
> > * It does a clear separation between applications (accessible from the
> > application panel) and content (accessible from the navigation panel).
> The
> > navigation panel is currently mixing application pages and (user) content
> > pages.
> > * The administrator doesn't need to update the navigation panel
> > configuration to exclude a top level application home page each time an
> > application is installed
> > * The hidden top level extension code pages are not shown even when "show
> > hidden pages" is set to true
> > * The user top level pages created later on appear in the tree
> > automatically
> >
> > Cons:
> > * The user won't be able to navigate easily to an application home page:
> > ** if the application panel is not shown
> > ** or if the application doesn't provide an application panel entry
> > ** or if the administrator has removed the entry from the application
> panel
>
>
> >
> > I prefer solution 4.
> >
> > WDYT?
> >
> > Thanks,
> > Marius
> >
>



--
Guillaume Delhumeau ([hidden email])
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
12