Hi Caty, > On 3 May 2018, at 12:14, Ecaterina Moraru (Valica) <[email protected]> wrote: > > On Thu, May 3, 2018 at 12:07 PM, Vincent Massol <[email protected]> wrote: > >> >> >>> On 3 May 2018, at 10:58, Ecaterina Moraru (Valica) <[email protected]> >> wrote: >>> >>> On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < >>> [email protected]> 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. >>> -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 >> >> What you’re saying is that users will always want to show the full tree in >> the Navigation panel and that there are no use cases where they’ll want to >> hide some parts (that they have created). I believe that this use case >> exists. >> > > If they want to hide something, they have the Hidden pages mechanism.
I’m trying to read between the lines and I guess you mean this because you assume that users will want the Navigation Panel in sync with the rest of the features of XWiki, i.e. for ex that when they search they don’t see results that don’t appear in the Nav panel, right? So you’re saying in essence that you want the Nav panel to represent exactly what the users sees in this wiki…. However if that were true, we wouldn’t be having this discussion that we have now… It’s because users want to control the navigation panel content that we’re discussing this ;) You mention below that you like the whitelist, but you’ll get exactly the same “discrepancy" issue: when you search users will find pages not listed in the nav panel! Also this is really not reasonable to say “users should use the hide page mechanism” because 1) it’ll mean those pages won’t be found in the search for example 2) it’s just impossibly hard to use to hide a full page and all its children (it works at a page level) and 3) you can hide some pages but as soon as someone adds a new page in that space, it’ll appear in the Nav Panel. So, I don’t believe they can use the Hidden pages mechanism. Do you agree? Thanks -Vincent > > >> >> This is why we need to agree about the use cases first before even >> discussing solutions! >> >> And this is why in my previous reply I’ve put what I consider to be the >> use cases we need to implement. Pasting it again here: >> >> “ >> * I believe we need to satisfy **all** the following generic use cases >> (with the whitelist taking precedence for example): >> ** Be able for the admin user to black list some nodes and children >> ** Be able for the admin user to white list some nodes and children >> “ >> >> So first let’s agree or disagree that these are real use cases we need to >> satisfy for a generic platform such as XWiki :) >> >> WDYT? >> >> Thanks >> -Vincent >> >>> >>>> >>>> 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. Also they might create their own apps and they will want >>> those to be part of the navigation. 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
