Separate Content spaces from Application spaces in the Spaces gadget

I think this one is more than related to XWIKI-7927, isn't it a duplicate ?

This one is strictly related to the "Spaces" gadget, while the other ( XWIKI-7927 ) is more generic (there are several ways that it can be implemented: app directory, panel, etc. - see also http://incubator.myxwiki.org/xwiki/bin/download/Improvements/HelpCenter/userAppBar.png)

IMHO most app spaces are already separated in the space gadget, since they are hidden (Stats, Scheduler, etc).
Indeed for XWIKI-7927 the easiest is to have a panel listing all the applications.

now depends what we consider an app? is blog an app? is the dashboard an app? etc.

Yes, I consider Blog and Dashboard as applications.
Now there are problems, for example we could hide all the pages in the Blog space and put it in the list of applications ... but once a user writes a blog post the space becomes visible (because there's a page not hidden in the Blog space). I don't see a good solution to separate content and app spaces yet.

Could you provide a filter option in the Spaces gadget for users to specify which spaces not to list? Users do not add applications frequently, so maintaining the filter would not be an issue.

We could do that but in that case:

• the list would have to be manually maintained
• very few users would discover the filter option
• the spaces filtered from the space gadget would still be available everywhere else (search, WYSIWYG, tree)

Caty, what's your take on this ?

If you display hidden pages, the Spaces gadgets lists: 'AnnotationCode', 'AppWithinMinutes', 'Blog', 'ColorThemes', 'Dashboard', 'Invitation', 'Main', 'Panels', 'Sandbox', 'Scheduler', 'Stats', 'XWiki'. In this case the Spaces gadgets make sense because it shows all the spaces that exists in XWiki.

Right now on a fresh instance the Spaces gadgets lists: 'Blog', 'Main', 'Sandbox', 'XWiki'.
The Applications panel lists: 'Blog', 'Dashboard', 'User Directory' + links to AppWithinMinutes and Extension Manager.
IMO it shouldn't list 'Blog' because I consider it to be an application, and it shouldn't list 'XWiki' because I actually can't access it and I shouldn't care about it since mostly it contains hidden pages.
It will be left with 'Main' and 'Sandbox' which could be considered Content spaces.
All new spaces created by user that contain normal pages should be listed in the Spaces gadget, all the new applications created by user should be listed in the Applications panel.
This could be one use case and this issue has been created with this use case in mind.

Another use case, the one that you are talking about: 'a filterable Space gadget'. IMO this is very similar to a Favorites gadget.
In the configuration area you should have a list with all the Spaces and with 2 states: 'Show' / 'Hide' (just like for Gmail's Labels).
Initially all the spaces that are hidden will be defaulted to 'Hide', but in some cases the user could override and make visible even some hidden spaces if he wants to.
As JV said this 'Show'/'Hide' option would 'affect' just the Spaces gadget. The spaces and pages will be available and visible (or hidden in the Search, Tree, etc.) accordingly to their Hidden Documents state. Actually right now Hide / Hidden is a bit confusing, so maybe .... in the Space gadget we should have 'Favorite': 'Yes'/'No' instead of 'Show'/'Hide' with the same remarks as above.

IMO it shouldn't list 'Blog'

I assume you are referring to the Spaces gadget, right? If so, I agree.

Now the problem is how to configure this. Right now we only have the notion of hidden documents. Of course we could modify the Blog app to create blog posts as hidden but that's not good because they wouldn't appear in search for example.

Thus, IMO we need another way. This could be a new XObject attached to a space WebPreferences page and the Spaces macro would not display spaces that have this XObject.

it shouldn't list 'XWiki' because I actually can't access it and I shouldn't care about it since mostly it contains hidden pages.

Not quite. It contains all XWiki users which is why it's not hidden. The solution I've listed a few lines above would solve this too.

IMO allowing the user to configure the list of spaces to see/not see is another feature which can be implemented on top of my solution. We would still need a default solution and we need new extension to define how they consider their spaces by default. The XObject attached to WebPreferences allow for this.

WDYT?

For me sounds ok, waiting for JV's opinion. Also we could add an object that says that the space is an application, and this relates to XWIKI-7925 .

So Vincent you suggest having a specific XClass allowing to filter spaces out of the spaces macro. This would allow us to hide spaces from it without having to ask the user to manually handle it, and yet the application data pages (blog posts, users, etc) would be searchable and linkable (from the WYSIWYG). While I don't think having XObjects in WebPreferences for a specific macro is perfect ... I can't think of a better solution.

@JV, yes you got it. And no, the XClass wouldn't be directly tied to the macro. It would just be an XClass to say: "This space is an application space". That would work right?

Yep that would work, the spaces macro would depend on the application manager which is fine. Now it certainly means that we should discuss about XWIKI-7925 (the app descriptor could declare a list of spaces as being its own), which is a touchy cross-topic between AWM and the extension manager