On Thu, May 3, 2018 at 11:58 AM, Ecaterina Moraru (Valica) < vali...@gmail.com> wrote:
> On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < > mariusdumitru.flo...@xwiki.com> 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 > > > > > > S1: This solution is good if users would work in isolation or in the > evaluation period, but for team and multiple people sharing spaces, I don't > see this as a valid solution. > The Content space is for all users, shared. This is not about having a separate space for each user. > -0 > > > > > > Solution 2: Blacklisting > > > > Add support for specifying a list of (top level) pages to exclude from > the > > navigation panel. > > > > 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 > > * 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 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. > > > > > S2: I see the blacklist solution more as a hack for things in XWiki that > should be fixed (have users outside XWiki space, move Sandbox into Help > space, hide Help pages and provide a dedicated Help entry in the User menu, > etc.) but we don't have the time to do it. > -0 in an ideal state > > > > > > Solution 3: Whitelisting > > > > Add support for controlling the list of top level pages that are > displayed > > in the navigation panel. > > > > 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. > > * the whitelist controls only the first level in the tree. The next > levels > > will be dynamic (database queries) and with the default order. > > > > S3: I prefer this solution, but with the ability to also display some > dynamic pattern, something like: display X, Y and all children of Z, or > all pages starting with A, or all pages created by group N :) (they are > just ideas, I know some are very hard to implement). > +1 > > > > > > > > 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). > > > > 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 > > > > > > S4: I don't know if for our users this separation between apps and content > is very clear. I think our users (or their administrators at least) want to separate the applications from the content. So I think it would be good to have something dedicated to applications, the application panel, and something dedicated to content, the navigation panel. > Also they might create their own apps and they will want > those to be part of the navigation. They would want to have an entry in the application panel like the rest of the apps I think. > The ideal navigation should be able to > state some important pages to be shown (static aspect), order that list in > terms of priority, and later contain and navigate to pages created by the > user or team (dynamic aspect). Adding metadatas to pages and creating apps > on top of content is a major feature of XWiki and I don't want to remove > these pages from the navigation. > -0 > > I prefer solution 3, but with the ability to sort and also to include some > dynamic parts :) is this possible? > > Thanks, > Caty > > > > > > I prefer solution 4. > > > > WDYT? > > > > Thanks, > > Marius > > >
