Hi, On Fri, Jun 12, 2015 at 1:30 PM, Marius Dumitru Florea < [email protected]> wrote:

Hi guys,

The wiki home page displays, by default, the list of spaces that exist in the wiki (hidden or not, depending on the user profile settings). This is done using the http://extensions.xwiki.org/xwiki/bin/view/Extension/Spaces+Macro . As we have started to work on adding support for nested spaces/documents, we need to review the purpose of this macro. Is it still relevant to display a list of spaces when there is a tree hierarchy? It only makes sense if you want to display just the list of direct children of a given node.

I see the following options:

(1) Display the list of top level nodes (space/document) on the wiki home page. No tree. The rationale is that loading the tree (even if done lazy) is more expensive that displaying a static list of links. For this we can extend the Spaces Macro with a parameter to specify the parent node. When this parameter is not specified the macro will list the top level nodes. (In the context of nested documents we could introduce a new macro Document List instead)

This direction could mean something like this: - Main Wiki: http://design.xwiki.org/xwiki/bin/download/Improvements/WorkspaceHomepage/Ho... - Subwiki (+ Nested Space): http://design.xwiki.org/xwiki/bin/download/Improvements/WorkspaceHomepage/Wo... So for example the main wiki display the list of wikis, while the subwiki list the immediate spaces. If you want to go to the nested spaces structure you would need to enter the wanted spaces in order to see it's children. My main problem with this approach is that this works when we have dedicated WebHomes, like until now. With Nested Documents, the document will not be hubs anymore (listing children and activity), but they could be content documents where the spaces macro has no point in being displayed. Another usage of this macro was when importing the Dashboard inside a space and it listed the 'Documents in space X' + Activity Stream. This view mode was an alternative in providing a livetable. The main advantage of this macro was the ability to create spaces. Not sure how many users created spaces this way or accessed the Administration and Document Index shortcuts. ---- So let's say we don't need to have actions and create and we will use the macro just for navigation.

(2) Display the tree hierarchy on the wiki home page, using http://extensions.xwiki.org/xwiki/bin/view/Extension/Document+Tree+Macro .Of course, the tree will be lazy loaded, and only the top level nodes are displayed initially. If we do this then we can probably deprecate the Spaces Macro and advice the users to use the Document Tree Macro instead.

With nested documents and without the actions, I find the Document Tree Macro to be more powerful, since it's not restricting you to load a page in order to see it's children. You can browse easy the structure. I see the Document Tree Macro as a more modern version of the Spaces Macro, so I am ok to deprecate it. (We need to make sure what we do with Tags Application and Information Tab in docextra, since we could make some changes also there). My comment regarding the document tree is would it be useful inside the content. Since we will not have WebHomes anymore we will have less demand for spaces dashboards. There was an older idea of creating a left panels switch for appbar and hierarchical navigation, see http://design.xwiki.org/xwiki/bin/view/Proposal/AppBar#HFunctionalityExtensi... This would imply moving the Spaces Functionality from content to panels. ---- Conclusion: - With nested documents there will be a less demand for WebHomes dashboard since they will be replaced with content. - Modifying Spaces Macro with a parent parameter is not the only change this macro will need, since we would need to also normalize the 'Administration', 'Document Index', 'Create' actions; - We will still have the wikis dashboards that can list hierarchy, activity, members; - We could display Document Tree in the content as a replacement for Spaces Macro, or we could make the panels more easily configurable / switchable between 'AppBar'/'Hierarchy'/'Custom Content'. Thanks, Caty

WDYT?

Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs