Hi Marius, See below
> On 3 May 2018, at 13:24, Marius Dumitru Florea > <[email protected]> wrote: > > 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. In the end it boils down to how you view the Navigation panel I think. I view it as something that can be controlled by the user to decide what to see/not see. Deciding to see or not the apps is a choice. > >> 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. Only if you don’t want to see the app you added in the nav panel :) BTW I said that I find it ok to have this “app filter” but as one of the white list filters that can be applied. So I’m not against it if it’s configurable. > And what about the hidden pages? You mean the blacklisted pages? > Don't > you find it hard to manage a blacklist of 28+ excludes? Sure. And again I said I’m fine with with having this whitelist filter ;) > Solution 4 doesn't > require maintenance from an administrator. When you install an app it's top > level pages are excluded automatically. BTW I’m not sure that’s enough. For example several apps have subspaces such as a Data space and a Code space. This means that the Data space would be displayed and thus the app will be displayed in the nav panel, no? Another note: I’m probably not understanding something because I don’t see the point of hiding, say, ReleaseNotes.Archives when we’ll display ReleaseNotes.Data.*. It could even be seen as a regression (I’m assuming in this example that ReleaseNotes.Archives is a page of the ReleaseNotes app, which it isn’t FTM). I also fail to see how this will remove XWiki and Home from the Nav menu since they’re not apps/extensions… Last point: when you say “top level pages are excluded” you mean default extension pages, not top level pages created by the app when it’s used, right? > When you create a top level page, > it's shown automatically in the tree. Thanks -Vincent > > >> >> 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
