[xwiki-devs] The future of the Spaces macro in the context of Nested Spaces/Documents
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) (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. WDYT? Thanks, Marius
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
Hi Marius, On 12 Jun 2015 at 12:30:28, Marius Dumitru Florea ([email protected](mailto:[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)
-0. BTW I’ve fixed the Spaces macro so that it doesn’t fail when used for NS (see http://jira.xwiki.org/browse/XWIKI-12354).
(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.
WDYT?
+1 for (2). (3) However we may also stop displaying a navigation widget in the Dashboard since we’re going to have another way for navigation soon, see http://markmail.org/message/vzjcdr7fgewe4m7j My only worry is that it’s likely that the chosen solution will be sol5 + sol6 and thus less visible for users who don’t know how to use it a first. This could be solved by using the Tour application for first time users I guess and showing them the UI through a Tour overlay. So I’m also +1 for (3) FTR this discussion is related to issue http://jira.xwiki.org/browse/XWIKI-12362 which we may close as won’t fix depending on the result of this discussion. Thanks -Vincent
Hello Marius, 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)
-0 for (1), because even though it takes less time to display a list of top level nodes, I don't think it's achieving the concept of Nested Spaces (Documents), since what will be shown it is what is shown now, without the Nested Spaces concept implemented.
(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.
+1 for (2), because this is what we want in the end, to see (or at least to have the possibility to visualize) a hierarchy of Nested Spaces (Documents)
WDYT?
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Thanks, Gabriela
Hi Gaby, On 7 Aug 2015 at 10:40:51, Gabriela Smeria ([email protected](mailto:[email protected])) wrote:
Hello Marius,
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)
-0 for (1), because even though it takes less time to display a list of top level nodes, I don't think it's achieving the concept of Nested Spaces (Documents), since what will be shown it is what is shown now, without the Nested Spaces concept implemented.
(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.
+1 for (2), because this is what we want in the end, to see (or at least to have the possibility to visualize) a hierarchy of Nested Spaces (Documents)
See also my proposal (3) in my previous answer on this thread. WDYT about it? Thanks -Vincent
WDYT?
Thanks, Marius
Thanks, Gabriela
Hello Vincent, I'm +0 for (3), because as you said, sol5+sol6 it's more likely to be chosen, but I think this will not be sufficient. Displaying a (future) Document Tree Macro on Dashboard it will help a lot the users to find out where are the documents localized in the hierarchy or at least have a big picture about it, without entering every page and check the breadcrumb. And they can't use the Go To functionality if they don't know previously where the document is localized. But that's just my opinion. Thanks, Gabriela *Gabriela Smeria* *Web Developer* [email protected] skype: smeria.gabriela On Fri, Aug 7, 2015 at 12:42 PM, [email protected] <[email protected]> wrote:
Hi Gaby,
On 7 Aug 2015 at 10:40:51, Gabriela Smeria ([email protected] (mailto:[email protected])) wrote:
Hello Marius,
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)
-0 for (1), because even though it takes less time to display a list of top level nodes, I don't think it's achieving the concept of Nested Spaces (Documents), since what will be shown it is what is shown now, without the Nested Spaces concept implemented.
(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.
+1 for (2), because this is what we want in the end, to see (or at least to have the possibility to visualize) a hierarchy of Nested Spaces (Documents)
See also my proposal (3) in my previous answer on this thread.
WDYT about it?
Thanks -Vincent
WDYT?
Thanks, Marius
Thanks, Gabriela
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, IMO, we can use the document tree macro to achieve both usecases of the previous documents and spaces macros, so no need to have more than 1 navigation macro for this. +1 for (2) Re (3), we could wait and see how the tree navigation works out and, if users find that to be easy enough, we could eventually do (3). For now however, having some navigation in the dashboard is in line with the "overview" nature of the dashboard itself, so I think we could keep it. Thanks, Eduard On Fri, Aug 7, 2015 at 3:15 PM, Gabriela Smeria <[email protected]> wrote:
Hello Vincent,
I'm +0 for (3), because as you said, sol5+sol6 it's more likely to be chosen, but I think this will not be sufficient. Displaying a (future) Document Tree Macro on Dashboard it will help a lot the users to find out where are the documents localized in the hierarchy or at least have a big picture about it, without entering every page and check the breadcrumb. And they can't use the Go To functionality if they don't know previously where the document is localized. But that's just my opinion.
Thanks, Gabriela
*Gabriela Smeria* *Web Developer* [email protected] skype: smeria.gabriela
On Fri, Aug 7, 2015 at 12:42 PM, [email protected] <[email protected]> wrote:
Hi Gaby,
On 7 Aug 2015 at 10:40:51, Gabriela Smeria ([email protected] (mailto:[email protected])) wrote:
Hello Marius,
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)
-0 for (1), because even though it takes less time to display a list of top level nodes, I don't think it's achieving the concept of Nested Spaces (Documents), since what will be shown it is what is shown now, without the Nested Spaces concept implemented.
(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.
+1 for (2), because this is what we want in the end, to see (or at least to have the possibility to visualize) a hierarchy of Nested Spaces (Documents)
See also my proposal (3) in my previous answer on this thread.
WDYT about it?
Thanks -Vincent
WDYT?
Thanks, Marius
Thanks, Gabriela
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Everyone seems to agree, so far, that the spaces macro can be replaced by the document tree macro. We'll have to decide whether we keep this macro in the Index Application or we move it to contrib (so that anyone that wants to use it can install it). I guess we can leave it in the Index Application for 7.x. As for showing navigation information (i.e. the document tree) on the dashboard, most of you seem to find it useful. My only worry is that we'll provide multiple ways to do the same thing: * document index tree * breadcrumb tree (probably) * dashboard document tree Moreover, Caty's initial design of the Home page for Flamingo didn't include the spaces macro http://design.xwiki.org/xwiki/bin/view/Improvements/Skin4xHomepage . There may be more important information to display on the home page instead of the document tree (which you can access from the Document Index). On Mon, Aug 10, 2015 at 10:59 AM, Eduard Moraru <[email protected]> wrote:
Hi,
IMO, we can use the document tree macro to achieve both usecases of the previous documents and spaces macros, so no need to have more than 1 navigation macro for this.
+1 for (2)
Re (3), we could wait and see how the tree navigation works out and, if users find that to be easy enough, we could eventually do (3). For now however, having some navigation in the dashboard is in line with the "overview" nature of the dashboard itself, so I think we could keep it.
Thanks, Eduard
On Fri, Aug 7, 2015 at 3:15 PM, Gabriela Smeria <[email protected]> wrote:
Hello Vincent,
I'm +0 for (3), because as you said, sol5+sol6 it's more likely to be chosen, but I think this will not be sufficient. Displaying a (future) Document Tree Macro on Dashboard it will help a lot the users to find out where are the documents localized in the hierarchy or at least have a big picture about it, without entering every page and check the breadcrumb. And they can't use the Go To functionality if they don't know previously where the document is localized. But that's just my opinion.
Thanks, Gabriela
*Gabriela Smeria* *Web Developer* [email protected] skype: smeria.gabriela
On Fri, Aug 7, 2015 at 12:42 PM, [email protected] <[email protected]> wrote:
Hi Gaby,
On 7 Aug 2015 at 10:40:51, Gabriela Smeria ([email protected] (mailto:[email protected])) wrote:
Hello Marius,
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)
-0 for (1), because even though it takes less time to display a list of top level nodes, I don't think it's achieving the concept of Nested Spaces (Documents), since what will be shown it is what is shown now, without the Nested Spaces concept implemented.
(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.
+1 for (2), because this is what we want in the end, to see (or at least to have the possibility to visualize) a hierarchy of Nested Spaces (Documents)
See also my proposal (3) in my previous answer on this thread.
WDYT about it?
Thanks -Vincent
WDYT?
Thanks, Marius
Thanks, Gabriela
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Wed, Aug 19, 2015 at 11:29 AM, Marius Dumitru Florea < [email protected]> wrote:
Everyone seems to agree, so far, that the spaces macro can be replaced by the document tree macro. We'll have to decide whether we keep this macro in the Index Application or we move it to contrib (so that anyone that wants to use it can install it). I guess we can leave it in the Index Application for 7.x.
As for showing navigation information (i.e. the document tree) on the dashboard, most of you seem to find it useful. My only worry is that we'll provide multiple ways to do the same thing:
* document index tree * breadcrumb tree (probably) * dashboard document tree
Moreover, Caty's initial design of the Home page for Flamingo didn't include the spaces macro http://design.xwiki.org/xwiki/bin/view/Improvements/Skin4xHomepage . There may be more important information to display on the home page instead of the document tree (which you can access from the Document Index).
The focus of Flamingo proposal was not the Homepage. I've included the macro in the proposals for Workspaces http://design.xwiki.org/xwiki/bin/download/Improvements/WorkspaceHomepage/Ho... http://design.xwiki.org/xwiki/bin/download/Improvements/WorkspaceHomepage/Wo... with their main purpose as light navigation. Still these proposals are focused for the Groupware Flavor. In documentations the Trees are very important. I think the breadcrumb tree will be enough for a Groupware Flavor, but we will need to test it. Thanks, Caty
On Mon, Aug 10, 2015 at 10:59 AM, Eduard Moraru <[email protected]> wrote:
Hi,
IMO, we can use the document tree macro to achieve both usecases of the previous documents and spaces macros, so no need to have more than 1 navigation macro for this.
+1 for (2)
Re (3), we could wait and see how the tree navigation works out and, if users find that to be easy enough, we could eventually do (3). For now however, having some navigation in the dashboard is in line with the "overview" nature of the dashboard itself, so I think we could keep it.
Thanks, Eduard
On Fri, Aug 7, 2015 at 3:15 PM, Gabriela Smeria < [email protected]> wrote:
Hello Vincent,
I'm +0 for (3), because as you said, sol5+sol6 it's more likely to be chosen, but I think this will not be sufficient. Displaying a (future) Document Tree Macro on Dashboard it will help a lot the users to find out where are the documents localized in the hierarchy or at least have a big picture about it, without entering every page and check the breadcrumb. And they can't use the Go To functionality if they don't know previously where the document is localized. But that's just my opinion.
Thanks, Gabriela
*Gabriela Smeria* *Web Developer* [email protected] skype: smeria.gabriela
On Fri, Aug 7, 2015 at 12:42 PM, [email protected] <[email protected]
wrote:
Hi Gaby,
On 7 Aug 2015 at 10:40:51, Gabriela Smeria ([email protected] (mailto:[email protected])) wrote:
Hello Marius,
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)
-0 for (1), because even though it takes less time to display a list of top level nodes, I don't think it's achieving the concept of Nested Spaces (Documents), since what will be shown it is what is shown now, without the Nested Spaces concept implemented.
(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.
+1 for (2), because this is what we want in the end, to see (or at least to have the possibility to visualize) a hierarchy of Nested Spaces (Documents)
See also my proposal (3) in my previous answer on this thread.
WDYT about it?
Thanks -Vincent
WDYT?
Thanks, Marius
Thanks, Gabriela
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hello all, The final decision for this thread will also affect Notes application, which uses Space Index macro. So please consider this thing too. See http://jira.xwiki.org/browse/NOTES-2. I've already thought of a solution, but the final decision from here will influence a lot the fix . Thanks, Gabriela *Gabriela Smeria* *Web Developer* [email protected] skype: smeria.gabriela On Wed, Aug 19, 2015 at 12:36 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:
On Wed, Aug 19, 2015 at 11:29 AM, Marius Dumitru Florea < [email protected]> wrote:
Everyone seems to agree, so far, that the spaces macro can be replaced by the document tree macro. We'll have to decide whether we keep this macro in the Index Application or we move it to contrib (so that anyone that wants to use it can install it). I guess we can leave it in the Index Application for 7.x.
As for showing navigation information (i.e. the document tree) on the dashboard, most of you seem to find it useful. My only worry is that we'll provide multiple ways to do the same thing:
* document index tree * breadcrumb tree (probably) * dashboard document tree
Moreover, Caty's initial design of the Home page for Flamingo didn't include the spaces macro http://design.xwiki.org/xwiki/bin/view/Improvements/Skin4xHomepage . There may be more important information to display on the home page instead of the document tree (which you can access from the Document Index).
The focus of Flamingo proposal was not the Homepage. I've included the macro in the proposals for Workspaces
http://design.xwiki.org/xwiki/bin/download/Improvements/WorkspaceHomepage/Ho...
http://design.xwiki.org/xwiki/bin/download/Improvements/WorkspaceHomepage/Wo... with their main purpose as light navigation.
Still these proposals are focused for the Groupware Flavor. In documentations the Trees are very important.
I think the breadcrumb tree will be enough for a Groupware Flavor, but we will need to test it.
Thanks, Caty
On Mon, Aug 10, 2015 at 10:59 AM, Eduard Moraru <[email protected]> wrote:
Hi,
IMO, we can use the document tree macro to achieve both usecases of the previous documents and spaces macros, so no need to have more than 1 navigation macro for this.
+1 for (2)
Re (3), we could wait and see how the tree navigation works out and, if users find that to be easy enough, we could eventually do (3). For now however, having some navigation in the dashboard is in line with the "overview" nature of the dashboard itself, so I think we could keep it.
Thanks, Eduard
On Fri, Aug 7, 2015 at 3:15 PM, Gabriela Smeria < [email protected]> wrote:
Hello Vincent,
I'm +0 for (3), because as you said, sol5+sol6 it's more likely to be chosen, but I think this will not be sufficient. Displaying a (future) Document Tree Macro on Dashboard it will help a lot the users to find out where are the documents localized in the hierarchy or at least have a big picture about it, without entering every page and check the
breadcrumb.
And they can't use the Go To functionality if they don't know previously where the document is localized. But that's just my opinion.
Thanks, Gabriela
*Gabriela Smeria* *Web Developer* [email protected] skype: smeria.gabriela
On Fri, Aug 7, 2015 at 12:42 PM, [email protected] < [email protected]
wrote:
Hi Gaby,
On 7 Aug 2015 at 10:40:51, Gabriela Smeria ( [email protected] (mailto:[email protected])) wrote:
Hello Marius,
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) >
-0 for (1), because even though it takes less time to display a list of top level nodes, I don't think it's achieving the concept of Nested Spaces (Documents), since what will be shown it is what is shown now, without the Nested Spaces concept implemented.
> (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. >
+1 for (2), because this is what we want in the end, to see (or at least to have the possibility to visualize) a hierarchy of Nested Spaces (Documents)
See also my proposal (3) in my previous answer on this thread.
WDYT about it?
Thanks -Vincent
> WDYT? > > Thanks, > Marius
Thanks, Gabriela
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Gaby, On 24 Aug 2015 at 10:02:43, Gabriela Smeria ([email protected](mailto:[email protected])) wrote:
Hello all,
The final decision for this thread will also affect Notes application, which uses Space Index macro.
Indeed we also need to decide what to do about the {{spaceindex}} macro (which lists all document in a space). IMO we should use the {{documentTree}} macro using the “root” parameter instead. I’ve modified the title of http://jira.xwiki.org/browse/XWIKI-12362 to include the Space Index macro. So my take is: * Keep those 2 macros for now for backward-compatibility reasons * Just make sure they don’t break with Nested Spaces/Documents * Don’t improve them and instead recommend in the documentation to use the DocumentTree macro WDYT? Thanks -Vincent
So please consider this thing too. See http://jira.xwiki.org/browse/NOTES-2. I've already thought of a solution, but the final decision from here will influence a lot the fix .
Thanks, Gabriela
*Gabriela Smeria* *Web Developer* [email protected] skype: smeria.gabriela
On Wed, Aug 19, 2015 at 12:36 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:
On Wed, Aug 19, 2015 at 11:29 AM, Marius Dumitru Florea < [email protected]> wrote:
Everyone seems to agree, so far, that the spaces macro can be replaced by the document tree macro. We'll have to decide whether we keep this macro in the Index Application or we move it to contrib (so that anyone that wants to use it can install it). I guess we can leave it in the Index Application for 7.x.
As for showing navigation information (i.e. the document tree) on the dashboard, most of you seem to find it useful. My only worry is that we'll provide multiple ways to do the same thing:
* document index tree * breadcrumb tree (probably) * dashboard document tree
Moreover, Caty's initial design of the Home page for Flamingo didn't include the spaces macro http://design.xwiki.org/xwiki/bin/view/Improvements/Skin4xHomepage . There may be more important information to display on the home page instead of the document tree (which you can access from the Document Index).
The focus of Flamingo proposal was not the Homepage. I've included the macro in the proposals for Workspaces
http://design.xwiki.org/xwiki/bin/download/Improvements/WorkspaceHomepage/Ho...
http://design.xwiki.org/xwiki/bin/download/Improvements/WorkspaceHomepage/Wo... with their main purpose as light navigation.
Still these proposals are focused for the Groupware Flavor. In documentations the Trees are very important.
I think the breadcrumb tree will be enough for a Groupware Flavor, but we will need to test it.
Thanks, Caty
On Mon, Aug 10, 2015 at 10:59 AM, Eduard Moraru wrote:
Hi,
IMO, we can use the document tree macro to achieve both usecases of the previous documents and spaces macros, so no need to have more than 1 navigation macro for this.
+1 for (2)
Re (3), we could wait and see how the tree navigation works out and, if users find that to be easy enough, we could eventually do (3). For now however, having some navigation in the dashboard is in line with the "overview" nature of the dashboard itself, so I think we could keep it.
Thanks, Eduard
On Fri, Aug 7, 2015 at 3:15 PM, Gabriela Smeria < [email protected]> wrote:
Hello Vincent,
I'm +0 for (3), because as you said, sol5+sol6 it's more likely to be chosen, but I think this will not be sufficient. Displaying a (future) Document Tree Macro on Dashboard it will help a lot the users to find out where are the documents localized in the hierarchy or at least have a big picture about it, without entering every page and check the
breadcrumb.
And they can't use the Go To functionality if they don't know previously where the document is localized. But that's just my opinion.
Thanks, Gabriela
*Gabriela Smeria* *Web Developer* [email protected] skype: smeria.gabriela
On Fri, Aug 7, 2015 at 12:42 PM, [email protected] < [email protected]
wrote:
Hi Gaby,
On 7 Aug 2015 at 10:40:51, Gabriela Smeria ( [email protected] (mailto:[email protected])) wrote:
> Hello Marius, > > > 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) > > > > -0 for (1), because even though it takes less time to display a list of top > level nodes, I don't think it's achieving the concept of Nested Spaces > (Documents), since what will be shown it is what is shown now, without the > Nested Spaces concept implemented. > > > > (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. > > > > +1 for (2), because this is what we want in the end, to see (or at least to > have the possibility to visualize) a hierarchy of Nested Spaces (Documents)
See also my proposal (3) in my previous answer on this thread.
WDYT about it?
Thanks -Vincent
> > WDYT? > > > > Thanks, > > Marius
> Thanks, > Gabriela
On Mon, Aug 24, 2015 at 1:14 PM, [email protected] <[email protected]> wrote:
Hi Gaby,
On 24 Aug 2015 at 10:02:43, Gabriela Smeria ([email protected](mailto:[email protected])) wrote:
Hello all,
The final decision for this thread will also affect Notes application, which uses Space Index macro.
Indeed we also need to decide what to do about the {{spaceindex}} macro (which lists all document in a space).
IMO we should use the {{documentTree}} macro using the “root” parameter instead.
By replacing the live table with a tree the users won't be able to: * see directly the author/creator and the last modification / creation date * filter by page name or author * sort by creation / modification date I'd rather make the space index a "localized" version of the wiki document index, i.e. limited to a specified space (nested document). The user should at least be able to choose between tree view and list view. Thanks, Marius
I’ve modified the title of http://jira.xwiki.org/browse/XWIKI-12362 to include the Space Index macro.
So my take is:
* Keep those 2 macros for now for backward-compatibility reasons * Just make sure they don’t break with Nested Spaces/Documents * Don’t improve them and instead recommend in the documentation to use the DocumentTree macro
WDYT?
Thanks -Vincent
So please consider this thing too. See http://jira.xwiki.org/browse/NOTES-2. I've already thought of a solution, but the final decision from here will influence a lot the fix .
Thanks, Gabriela
*Gabriela Smeria* *Web Developer* [email protected] skype: smeria.gabriela
On Wed, Aug 19, 2015 at 12:36 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:
On Wed, Aug 19, 2015 at 11:29 AM, Marius Dumitru Florea < [email protected]> wrote:
Everyone seems to agree, so far, that the spaces macro can be replaced by the document tree macro. We'll have to decide whether we keep this macro in the Index Application or we move it to contrib (so that anyone that wants to use it can install it). I guess we can leave it in the Index Application for 7.x.
As for showing navigation information (i.e. the document tree) on the dashboard, most of you seem to find it useful. My only worry is that we'll provide multiple ways to do the same thing:
* document index tree * breadcrumb tree (probably) * dashboard document tree
Moreover, Caty's initial design of the Home page for Flamingo didn't include the spaces macro http://design.xwiki.org/xwiki/bin/view/Improvements/Skin4xHomepage . There may be more important information to display on the home page instead of the document tree (which you can access from the Document Index).
The focus of Flamingo proposal was not the Homepage. I've included the macro in the proposals for Workspaces
http://design.xwiki.org/xwiki/bin/download/Improvements/WorkspaceHomepage/Ho...
http://design.xwiki.org/xwiki/bin/download/Improvements/WorkspaceHomepage/Wo... with their main purpose as light navigation.
Still these proposals are focused for the Groupware Flavor. In documentations the Trees are very important.
I think the breadcrumb tree will be enough for a Groupware Flavor, but we will need to test it.
Thanks, Caty
On Mon, Aug 10, 2015 at 10:59 AM, Eduard Moraru wrote:
Hi,
IMO, we can use the document tree macro to achieve both usecases of the previous documents and spaces macros, so no need to have more than 1 navigation macro for this.
+1 for (2)
Re (3), we could wait and see how the tree navigation works out and, if users find that to be easy enough, we could eventually do (3). For now however, having some navigation in the dashboard is in line with the "overview" nature of the dashboard itself, so I think we could keep it.
Thanks, Eduard
On Fri, Aug 7, 2015 at 3:15 PM, Gabriela Smeria < [email protected]> wrote:
Hello Vincent,
I'm +0 for (3), because as you said, sol5+sol6 it's more likely to be chosen, but I think this will not be sufficient. Displaying a (future) Document Tree Macro on Dashboard it will help a lot the users to find out where are the documents localized in the hierarchy or at least have a big picture about it, without entering every page and check the
breadcrumb.
And they can't use the Go To functionality if they don't know previously where the document is localized. But that's just my opinion.
Thanks, Gabriela
*Gabriela Smeria* *Web Developer* [email protected] skype: smeria.gabriela
On Fri, Aug 7, 2015 at 12:42 PM, [email protected] < [email protected]
wrote:
> Hi Gaby, > > On 7 Aug 2015 at 10:40:51, Gabriela Smeria ( [email protected] > (mailto:[email protected])) wrote: > > > Hello Marius, > > > > > > 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) > > > > > > > -0 for (1), because even though it takes less time to display a list of > top > > level nodes, I don't think it's achieving the concept of Nested Spaces > > (Documents), since what will be shown it is what is shown now, without > the > > Nested Spaces concept implemented. > > > > > > > (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. > > > > > > > +1 for (2), because this is what we want in the end, to see (or at least > to > > have the possibility to visualize) a hierarchy of Nested Spaces > (Documents) > > See also my proposal (3) in my previous answer on this thread. > > WDYT about it? > > Thanks > -Vincent > > > > WDYT? > > > > > > Thanks, > > > Marius > > > Thanks, > > Gabriela
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 24 Aug 2015 at 13:34:29, Marius Dumitru Florea ([email protected](mailto:[email protected])) wrote:
On Mon, Aug 24, 2015 at 1:14 PM, [email protected] wrote:
Hi Gaby,
On 24 Aug 2015 at 10:02:43, Gabriela Smeria ([email protected](mailto:[email protected])) wrote:
Hello all,
The final decision for this thread will also affect Notes application, which uses Space Index macro.
Indeed we also need to decide what to do about the {{spaceindex}} macro (which lists all document in a space).
IMO we should use the {{documentTree}} macro using the “root” parameter instead.
By replacing the live table with a tree the users won't be able to:
I’ve never suggested that we should replace a LT by a Tree! :) I’ve said that we should replace the use of the {{spaceindex}} by {{documentTree}}. AFAIK Space Index Macro is not using a LT (See http://extensions.xwiki.org/xwiki/bin/view/Extension/SpaceIndex+Macro). Am I wrong? Thanks -Vincent
* see directly the author/creator and the last modification / creation date * filter by page name or author * sort by creation / modification date
I'd rather make the space index a "localized" version of the wiki document index, i.e. limited to a specified space (nested document). The user should at least be able to choose between tree view and list view.
Thanks, Marius
I’ve modified the title of http://jira.xwiki.org/browse/XWIKI-12362 to include the Space Index macro.
So my take is:
* Keep those 2 macros for now for backward-compatibility reasons * Just make sure they don’t break with Nested Spaces/Documents * Don’t improve them and instead recommend in the documentation to use the DocumentTree macro
WDYT?
Thanks -Vincent
So please consider this thing too. See http://jira.xwiki.org/browse/NOTES-2. I've already thought of a solution, but the final decision from here will influence a lot the fix .
Thanks, Gabriela
*Gabriela Smeria* *Web Developer* [email protected] skype: smeria.gabriela
On Wed, Aug 19, 2015 at 12:36 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:
On Wed, Aug 19, 2015 at 11:29 AM, Marius Dumitru Florea < [email protected]> wrote:
Everyone seems to agree, so far, that the spaces macro can be replaced by the document tree macro. We'll have to decide whether we keep this macro in the Index Application or we move it to contrib (so that anyone that wants to use it can install it). I guess we can leave it in the Index Application for 7.x.
As for showing navigation information (i.e. the document tree) on the dashboard, most of you seem to find it useful. My only worry is that we'll provide multiple ways to do the same thing:
* document index tree * breadcrumb tree (probably) * dashboard document tree
Moreover, Caty's initial design of the Home page for Flamingo didn't include the spaces macro http://design.xwiki.org/xwiki/bin/view/Improvements/Skin4xHomepage . There may be more important information to display on the home page instead of the document tree (which you can access from the Document Index).
The focus of Flamingo proposal was not the Homepage. I've included the macro in the proposals for Workspaces
http://design.xwiki.org/xwiki/bin/download/Improvements/WorkspaceHomepage/Ho...
http://design.xwiki.org/xwiki/bin/download/Improvements/WorkspaceHomepage/Wo... with their main purpose as light navigation.
Still these proposals are focused for the Groupware Flavor. In documentations the Trees are very important.
I think the breadcrumb tree will be enough for a Groupware Flavor, but we will need to test it.
Thanks, Caty
On Mon, Aug 10, 2015 at 10:59 AM, Eduard Moraru wrote:
Hi,
IMO, we can use the document tree macro to achieve both usecases of the previous documents and spaces macros, so no need to have more than 1 navigation macro for this.
+1 for (2)
Re (3), we could wait and see how the tree navigation works out and, if users find that to be easy enough, we could eventually do (3). For now however, having some navigation in the dashboard is in line with the "overview" nature of the dashboard itself, so I think we could keep it.
Thanks, Eduard
On Fri, Aug 7, 2015 at 3:15 PM, Gabriela Smeria < [email protected]> wrote:
> Hello Vincent, > > I'm +0 for (3), because as you said, sol5+sol6 it's more likely to be > chosen, but I think this will not be sufficient. Displaying a (future) > Document Tree Macro on Dashboard it will help a lot the users to find out > where are the documents localized in the hierarchy or at least have a big > picture about it, without entering every page and check the
breadcrumb.
> And they can't use the Go To functionality if they don't know previously > where the document is localized. > But that's just my opinion. > > Thanks, > Gabriela > > *Gabriela Smeria* > *Web Developer* > [email protected] > skype: smeria.gabriela > > On Fri, Aug 7, 2015 at 12:42 PM, [email protected] < [email protected]
> wrote: > > > Hi Gaby, > > > > On 7 Aug 2015 at 10:40:51, Gabriela Smeria ( [email protected] > > (mailto:[email protected])) wrote: > > > > > Hello Marius, > > > > > > > > > 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) > > > > > > > > > > -0 for (1), because even though it takes less time to display a list of > > top > > > level nodes, I don't think it's achieving the concept of Nested Spaces > > > (Documents), since what will be shown it is what is shown now, without > > the > > > Nested Spaces concept implemented. > > > > > > > > > > (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. > > > > > > > > > > +1 for (2), because this is what we want in the end, to see (or at > least > > to > > > have the possibility to visualize) a hierarchy of Nested Spaces > > (Documents) > > > > See also my proposal (3) in my previous answer on this thread. > > > > WDYT about it? > > > > Thanks > > -Vincent > > > > > > WDYT? > > > > > > > > Thanks, > > > > Marius > > > > > Thanks, > > > Gabriela
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Mon, Aug 24, 2015 at 2:37 PM, [email protected] <[email protected]> wrote:
On 24 Aug 2015 at 13:34:29, Marius Dumitru Florea ([email protected](mailto:[email protected])) wrote:
On Mon, Aug 24, 2015 at 1:14 PM, [email protected] wrote:
Hi Gaby,
On 24 Aug 2015 at 10:02:43, Gabriela Smeria ([email protected](mailto:[email protected])) wrote:
Hello all,
The final decision for this thread will also affect Notes application, which uses Space Index macro.
Indeed we also need to decide what to do about the {{spaceindex}} macro (which lists all document in a space).
IMO we should use the {{documentTree}} macro using the “root” parameter instead.
By replacing the live table with a tree the users won't be able to:
I’ve never suggested that we should replace a LT by a Tree! :)
I’ve said that we should replace the use of the {{spaceindex}} by {{documentTree}}.
AFAIK Space Index Macro is not using a LT (See http://extensions.xwiki.org/xwiki/bin/view/Extension/SpaceIndex+Macro). Am I wrong?
The space index (Main.SpaceIndex) is using a live table (the {{documents}} macro). If the Space Index macro is not used on the actual space index then ok.
Thanks -Vincent
* see directly the author/creator and the last modification / creation date * filter by page name or author * sort by creation / modification date
I'd rather make the space index a "localized" version of the wiki document index, i.e. limited to a specified space (nested document). The user should at least be able to choose between tree view and list view.
Thanks, Marius
I’ve modified the title of http://jira.xwiki.org/browse/XWIKI-12362 to include the Space Index macro.
So my take is:
* Keep those 2 macros for now for backward-compatibility reasons * Just make sure they don’t break with Nested Spaces/Documents * Don’t improve them and instead recommend in the documentation to use the DocumentTree macro
WDYT?
Thanks -Vincent
So please consider this thing too. See http://jira.xwiki.org/browse/NOTES-2. I've already thought of a solution, but the final decision from here will influence a lot the fix .
Thanks, Gabriela
*Gabriela Smeria* *Web Developer* [email protected] skype: smeria.gabriela
On Wed, Aug 19, 2015 at 12:36 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:
On Wed, Aug 19, 2015 at 11:29 AM, Marius Dumitru Florea < [email protected]> wrote:
Everyone seems to agree, so far, that the spaces macro can be replaced by the document tree macro. We'll have to decide whether we keep this macro in the Index Application or we move it to contrib (so that anyone that wants to use it can install it). I guess we can leave it in the Index Application for 7.x.
As for showing navigation information (i.e. the document tree) on the dashboard, most of you seem to find it useful. My only worry is that we'll provide multiple ways to do the same thing:
* document index tree * breadcrumb tree (probably) * dashboard document tree
Moreover, Caty's initial design of the Home page for Flamingo didn't include the spaces macro http://design.xwiki.org/xwiki/bin/view/Improvements/Skin4xHomepage . There may be more important information to display on the home page instead of the document tree (which you can access from the Document Index).
The focus of Flamingo proposal was not the Homepage. I've included the macro in the proposals for Workspaces
http://design.xwiki.org/xwiki/bin/download/Improvements/WorkspaceHomepage/Ho...
http://design.xwiki.org/xwiki/bin/download/Improvements/WorkspaceHomepage/Wo... with their main purpose as light navigation.
Still these proposals are focused for the Groupware Flavor. In documentations the Trees are very important.
I think the breadcrumb tree will be enough for a Groupware Flavor, but we will need to test it.
Thanks, Caty
On Mon, Aug 10, 2015 at 10:59 AM, Eduard Moraru wrote: > Hi, > > IMO, we can use the document tree macro to achieve both usecases of the > previous documents and spaces macros, so no need to have more than 1 > navigation macro for this. > > +1 for (2) > > Re (3), we could wait and see how the tree navigation works out and, if > users find that to be easy enough, we could eventually do (3). For now > however, having some navigation in the dashboard is in line with the > "overview" nature of the dashboard itself, so I think we could keep it. > > Thanks, > Eduard > > On Fri, Aug 7, 2015 at 3:15 PM, Gabriela Smeria < [email protected]> > wrote: > >> Hello Vincent, >> >> I'm +0 for (3), because as you said, sol5+sol6 it's more likely to be >> chosen, but I think this will not be sufficient. Displaying a (future) >> Document Tree Macro on Dashboard it will help a lot the users to find out >> where are the documents localized in the hierarchy or at least have a big >> picture about it, without entering every page and check the
breadcrumb.
>> And they can't use the Go To functionality if they don't know previously >> where the document is localized. >> But that's just my opinion. >> >> Thanks, >> Gabriela >> >> *Gabriela Smeria* >> *Web Developer* >> [email protected] >> skype: smeria.gabriela >> >> On Fri, Aug 7, 2015 at 12:42 PM, [email protected] < [email protected] > >> wrote: >> >> > Hi Gaby, >> > >> > On 7 Aug 2015 at 10:40:51, Gabriela Smeria ( [email protected] >> > (mailto:[email protected])) wrote: >> > >> > > Hello Marius, >> > > >> > > >> > > 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) >> > > > >> > > >> > > -0 for (1), because even though it takes less time to display a list of >> > top >> > > level nodes, I don't think it's achieving the concept of Nested Spaces >> > > (Documents), since what will be shown it is what is shown now, without >> > the >> > > Nested Spaces concept implemented. >> > > >> > > >> > > > (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. >> > > > >> > > >> > > +1 for (2), because this is what we want in the end, to see (or at >> least >> > to >> > > have the possibility to visualize) a hierarchy of Nested Spaces >> > (Documents) >> > >> > See also my proposal (3) in my previous answer on this thread. >> > >> > WDYT about it? >> > >> > Thanks >> > -Vincent >> > >> > > > WDYT? >> > > > >> > > > Thanks, >> > > > Marius >> > >> > > Thanks, >> > > Gabriela
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (5)
-
Ecaterina Moraru (Valica) -
Eduard Moraru -
Gabriela Smeria -
Marius Dumitru Florea -
vincent＠massol.net