On Thu, May 3, 2018 at 1:44 PM, Vincent Massol <[email protected]> wrote:
> > > > On 3 May 2018, at 12:32, Marius Dumitru Florea < > [email protected]> wrote: > > > > On Thu, May 3, 2018 at 11:58 AM, 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. > >> > > > > 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. > > > I’m seeing this a bit as a “hack" since the separation would exist in the > Nav panel but not elsewhere (AllDocs, other trees such as the Rename/Copy > ones, etc). > I don't get it. The blacklist / whitelist would be applied *only* to the navigation panel also so what you propose is not consistent either. > > I think if we want that separation we need to think about it more > globally. AFAIR we had some discussions about this separation already and > the proposed solution were different than the one proposed here. So if you > want to go in this direction, we need to review the previous proposals and > think more globally which IMO is going to take a lot of time. > > > I’m still thinking that we should allow users to define a white list and a > black list and that’s all. That will cover all use cases that a generic > platform requires. > Did you read the cons? Having to manually update the blacklist whenever you install an application is a pain. And what about the hidden pages? Don't you find it hard to manage a blacklist of 28+ excludes? Solution 4 doesn't require maintenance from an administrator. When you install an app it's top level pages are excluded automatically. When you create a top level page, it's shown automatically in the tree. > > Then we can work on optimizing this later on when we decide how we do the > separation between Content and apps and it’ll depend a lot on how we do it. > > If we don’t fo this we risk rushing into a suboptimal solution. > > WDYT? > > Thanks > -Vincent > > > > >> 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 > >
