3 May
2018
3 May
'18
2:01 p.m.
Hi Marius,
See below
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.
On 3 May 2018, at 13:24, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
On Thu, May 3, 2018 at 1:44 PM, Vincent Massol <vincent(a)massol.net> wrote:
don't
also
content
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.
On 3 May 2018, at 12:32, Marius Dumitru Florea
<
mariusdumitru.florea(a)xwiki.com> wrote:
On Thu, May 3, 2018 at 11:58 AM, Ecaterina Moraru (Valica) <
valicac(a)gmail.com> wrote:
> On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea <
> mariusdumitru.florea(a)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 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 >> 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 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?
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