[xwiki-devs] [Proposal] Introduce the notion of Nested Documents
Hello XWiki committers. Vincent have proposed the development of nested spaces for 7.2 and some of us have already agreed. But the concept of nested spaces introduces a problem that Denis have mentioned during some internal discussions at XWiki SAS, and that I am going to report here.
From a UI perspective, differentiating pages `A.B.C.WebHome` and `A.B.C` could become very difficult.
Moreover, we know that a lot of users do not understand the notion of spaces, and they are lost when you look at them during usability sessions. The situation is even worse if you consider the notion of parent/child documents, which is completely unrelated to the actual hierarchy. It creates confusion! To fix these problems, we propose to introduce the notion of "nested documents", i.e. the ability to create documents inside documents. Say differently, if a page `A.B.C` exists, nothing should stop the user to create the document `A.B.C.D`. In JCR[1], there is only one concept: the "node". A node can have a content, and a list of child nodes. In XWiki, documents could become a kind of nodes, and we do not need spaces anymore. If we don't have space anymore, we could ask ourselves: "How the rights will be propagated to the children documents? How do we distinguish rights applied to the documents and the rights applied to the children?" I think the easiest solution is to inherit the rights from the parent to the children, unless an object prevent it. We already have this kind of mechanism with XWikiRights and XWikiGlobalRights. XWikiRights would be applied for the current document, and XWikiGlobalRights for the document and its children. But changing the XWiki model is a lot of work, that we don't have time to achieve for 7.2. So we propose to make it step by step. The first step is to change the UI to hide the notion of space to the users. Concretely, each time a user wants to create a page called `A`, we actually create the document `A.WebHome`. So any child of this page would be created in the `A` space, like `A.Child`. But this child would be in a space too, so it would be `A.Child.WebHome` actually. Then, when we display the `A.WebHome` page, we remove all mentions to the `WebHome` name. In the UI, it will just be presented as the document `A`. This is a good point, knowing the fact that the term `WebHome` have no sense for the user, neither in English or in other languages. Again, these changes are only for the UI. For the applications, it is the developer's job to decide if the app will create documents like `Document.WebHome` or basic documents just as before. The question of what to do with AWM comes up. When a user creates an entry, should it be a new-kind-of-document (`AppSpace.Entry.WebHome`) or an old-kind-of-document (`AppSpace.Entry`)? The first option is good for consistency and for the new possibilities it offers, but the second is better for retro-compatibility. And the question will be the same for all existing applications that create pages. I believe we should answer these questions on a case-by-case basis and deserve their own mail threads. This proposal also implies to change some macros, like the {{space}} one, and some panels. But I believe there is no blocking-point there. Finally, after these steps are accomplished in 7.2 and polished until the end of the 7.x cycle, we will refactor the XWiki model (something we dream about for years). To sum up, the idea we propose is: On the short run: - Hide the notion of space in the UI. - Hide the `WebHome` name in the UI. - When a user creates a page from the UI, it actually creates a space with a WebHome. - Remove the current parent/child mechanism which is outdated (and confusing) compared to the new hierarchy. On the long run: - Remove the notion of space in the model, and replace it by "nested documents". - Tune the rights system to inherit rights from parents to children. Of course, we can discuss the technical details and the implementation strategies. But for now, we need to know if you accept the general idea (nested documents). So, I hope you will like this proposal, and here is my +1. Thanks, Guillaume D. [1] JCR: https://en.wikipedia.org/wiki/Content_repository_API_for_Java -- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
There is an important point missing in your proposal: how to you link/include/target such "pages" that actually ends up as space being the scene ? Right now with what you propose you will have to write [[A.Child.WebHome]] or {{include reference="A.Child.WebHome"/}} even if the UI is teling all the way you that you have a "A.Child" page. On Wed, Jun 3, 2015 at 4:10 PM, Guillaume "Louis-Marie" Delhumeau <[email protected]> wrote:
Hello XWiki committers.
Vincent have proposed the development of nested spaces for 7.2 and some of us have already agreed. But the concept of nested spaces introduces a problem that Denis have mentioned during some internal discussions at XWiki SAS, and that I am going to report here.
From a UI perspective, differentiating pages `A.B.C.WebHome` and `A.B.C` could become very difficult.
Moreover, we know that a lot of users do not understand the notion of spaces, and they are lost when you look at them during usability sessions.
The situation is even worse if you consider the notion of parent/child documents, which is completely unrelated to the actual hierarchy. It creates confusion!
To fix these problems, we propose to introduce the notion of "nested documents", i.e. the ability to create documents inside documents.
Say differently, if a page `A.B.C` exists, nothing should stop the user to create the document `A.B.C.D`.
In JCR[1], there is only one concept: the "node". A node can have a content, and a list of child nodes. In XWiki, documents could become a kind of nodes, and we do not need spaces anymore.
If we don't have space anymore, we could ask ourselves: "How the rights will be propagated to the children documents? How do we distinguish rights applied to the documents and the rights applied to the children?"
I think the easiest solution is to inherit the rights from the parent to the children, unless an object prevent it. We already have this kind of mechanism with XWikiRights and XWikiGlobalRights. XWikiRights would be applied for the current document, and XWikiGlobalRights for the document and its children.
But changing the XWiki model is a lot of work, that we don't have time to achieve for 7.2. So we propose to make it step by step.
The first step is to change the UI to hide the notion of space to the users. Concretely, each time a user wants to create a page called `A`, we actually create the document `A.WebHome`. So any child of this page would be created in the `A` space, like `A.Child`. But this child would be in a space too, so it would be `A.Child.WebHome` actually.
Then, when we display the `A.WebHome` page, we remove all mentions to the `WebHome` name. In the UI, it will just be presented as the document `A`. This is a good point, knowing the fact that the term `WebHome` have no sense for the user, neither in English or in other languages.
Again, these changes are only for the UI. For the applications, it is the developer's job to decide if the app will create documents like `Document.WebHome` or basic documents just as before.
The question of what to do with AWM comes up. When a user creates an entry, should it be a new-kind-of-document (`AppSpace.Entry.WebHome`) or an old-kind-of-document (`AppSpace.Entry`)? The first option is good for consistency and for the new possibilities it offers, but the second is better for retro-compatibility. And the question will be the same for all existing applications that create pages. I believe we should answer these questions on a case-by-case basis and deserve their own mail threads.
This proposal also implies to change some macros, like the {{space}} one, and some panels. But I believe there is no blocking-point there.
Finally, after these steps are accomplished in 7.2 and polished until the end of the 7.x cycle, we will refactor the XWiki model (something we dream about for years).
To sum up, the idea we propose is:
On the short run:
- Hide the notion of space in the UI.
- Hide the `WebHome` name in the UI.
- When a user creates a page from the UI, it actually creates a space with a WebHome.
- Remove the current parent/child mechanism which is outdated (and confusing) compared to the new hierarchy.
On the long run:
- Remove the notion of space in the model, and replace it by "nested documents".
- Tune the rights system to inherit rights from parents to children.
Of course, we can discuss the technical details and the implementation strategies. But for now, we need to know if you accept the general idea (nested documents).
So, I hope you will like this proposal, and here is my +1.
Thanks,
Guillaume D.
[1] JCR: https://en.wikipedia.org/wiki/Content_repository_API_for_Java
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Hi Guillaume, On 3 Jun 2015 at 16:10:36, Guillaume Louis-Marie Delhumeau ([email protected](mailto:[email protected])) wrote: [snip]
On the short run:
- Hide the notion of space in the UI.
- Hide the `WebHome` name in the UI.
- When a user creates a page from the UI, it actually creates a space with a WebHome.
- Remove the current parent/child mechanism which is outdated (and confusing) compared to the new hierarchy.
On the long run:
- Remove the notion of space in the model, and replace it by "nested documents".
- Tune the rights system to inherit rights from parents to children.
Of course, we can discuss the technical details and the implementation strategies. But for now, we need to know if you accept the general idea (nested documents).
So, I hope you will like this proposal, and here is my +1.
Note: I believe this email could have been a VOTE since it’s a very important concept change and we don’t vote on proposal. Let’s consider it as a brainstorming idea ATM which could lead to a VOTE later on if need be. I’m globally +1 to both hiding the concept of Space from the UI and to later on remove it from the model. Some comments: * Regarding the Nested Spaces proposal, see http://design.xwiki.org/xwiki/bin/view/Proposal/NestedSpaces * About hiding WebHome from the UI. This is something we should already be doing now even without the notion of Nested Spaces. Nothing is preventing us from doing it now. * Regarding permissions, since we want to keep the ability to programatically create pages named other than WebHome for now (till we modify the model) we’ll need to do the following: Do not show the page permission menu entry when a user is on a WebHome page (unless there’s already a Right xobject) * Regarding the current breadcrumb, in order to ease the migration, I’d propose to make it configurable in the config: either to use the old style breadcrumb based on parent/child relationships or the new breadcrumb based on Document References. When the old mode is on, editing a page should show the parent relationship field as now. We have to remember that people switching to XWiki 7.2 will not have deep hierarchies set up on their docs (and not many pages named WebHome). * I think we’ll need to go even more in the direction defined in the “conclusion” section of http://design.xwiki.org/xwiki/bin/view/Proposal/ExtendedBreadcrumb, i.e. ** Just a drawer-menu on the right (as proposed for the Macaw skin) ** A breadcrumb based on Document References (+ possibly the ability to execute some actions at each level) * We should probably keep the notion of Wiki even though it could be argued that wikis could be top level documents with some xobject in them. * Regarding Thomas's comment about creating wiki links, yes we might want to do the following: ** When rendering [[label>>A.B.C]] we could check if a page named C exists and if so link to it. If not, check if a page named C.WebHome exists and if so link to it. Otherwise make it a wanted link (ie display a “?”). This would be a similar logic than for URLs (supporting A/B/C as well as A/B/C/WebHome or A/B/C/) Thanks -Vincent
Thanks,
Guillaume D.
[1] JCR: https://en.wikipedia.org/wiki/Content_repository_API_for_Java
-- Guillaume Delhumeau ([email protected])
On Wed, Jun 3, 2015 at 5:10 PM, Guillaume "Louis-Marie" Delhumeau <[email protected]> wrote:
Hello XWiki committers.
Vincent have proposed the development of nested spaces for 7.2 and some of us have already agreed. But the concept of nested spaces introduces a problem that Denis have mentioned during some internal discussions at XWiki SAS, and that I am going to report here.
From a UI perspective, differentiating pages `A.B.C.WebHome` and `A.B.C` could become very difficult.
Moreover, we know that a lot of users do not understand the notion of spaces, and they are lost when you look at them during usability sessions.
I'm not sure about this statement. My feeling is that many users understand spaces as "folders" (they make the analogy with the file system). Moreover, whenever we display a space in the XWiki UI we use the folder icon, so we encourage the users to make this analogy.
The situation is even worse if you consider the notion of parent/child documents, which is completely unrelated to the actual hierarchy. It creates confusion!
To fix these problems, we propose to introduce the notion of "nested documents", i.e. the ability to create documents inside documents.
What's the difference at a *conceptual* level between the notion of parent/child we have right now and the notion of nested documents you propose? I don't see it. You even use "parent" and "child" words below to explain the "nested" notion. The word "nested" sounds very technical to me. I don't know about French, but in my native language the translation for "nested" is not a commonly used word, unlike parent and child. It seems easier to me to explan to a user that a document can have a parent document and some child documents (the parent / child relationship) then to explain them that a document can be "nested" inside another document and can "nest" other documents too.
Say differently, if a page `A.B.C` exists, nothing should stop the user to create the document `A.B.C.D`.
You mentioned JCR on the next paragraph. Are JCR nodes identified by the position (path) in the tree? I think we should make a distinction between the way we identify a document and the way we access that document. I like the fact that currently when you change the parent of a document the document identifier (reference) stays the same.
In JCR[1], there is only one concept: the "node". A node can have a content, and a list of child nodes. In XWiki, documents could become a kind of nodes, and we do not need spaces anymore.
If we don't have space anymore, we could ask ourselves: "How the rights will be propagated to the children documents? How do we distinguish rights applied to the documents and the rights applied to the children?"
I think the easiest solution is to inherit the rights from the parent to the children, unless an object prevent it. We already have this kind of mechanism with XWikiRights and XWikiGlobalRights. XWikiRights would be applied for the current document, and XWikiGlobalRights for the document and its children.
But changing the XWiki model is a lot of work, that we don't have time to achieve for 7.2. So we propose to make it step by step.
The first step is to change the UI to hide the notion of space to the users. Concretely, each time a user wants to create a page called `A`, we actually create the document `A.WebHome`. So any child of this page would be created in the `A` space, like `A.Child`. But this child would be in a space too, so it would be `A.Child.WebHome` actually.
I find this 'A.WebHome' thing too complex. Look at the document hierarchy tree http://extensions.xwiki.org/xwiki/bin/view/Extension/Document+Tree+Macro#HDo... . We can hide the spaces already by relying on the parent / child relationship.
Then, when we display the `A.WebHome` page, we remove all mentions to the `WebHome` name. In the UI, it will just be presented as the document `A`. This is a good point, knowing the fact that the term `WebHome` have no sense for the user, neither in English or in other languages.
Again, these changes are only for the UI. For the applications, it is the developer's job to decide if the app will create documents like `Document.WebHome` or basic documents just as before.
The question of what to do with AWM comes up. When a user creates an entry, should it be a new-kind-of-document (`AppSpace.Entry.WebHome`) or an old-kind-of-document (`AppSpace.Entry`)? The first option is good for consistency and for the new possibilities it offers, but the second is better for retro-compatibility. And the question will be the same for all existing applications that create pages. I believe we should answer these questions on a case-by-case basis and deserve their own mail threads.
This proposal also implies to change some macros, like the {{space}} one, and some panels. But I believe there is no blocking-point there.
Finally, after these steps are accomplished in 7.2 and polished until the end of the 7.x cycle, we will refactor the XWiki model (something we dream about for years).
To sum up, the idea we propose is:
On the short run:
- Hide the notion of space in the UI.
- Hide the `WebHome` name in the UI.
- When a user creates a page from the UI, it actually creates a space with a WebHome.
- Remove the current parent/child mechanism which is outdated (and confusing) compared to the new hierarchy.
On the long run:
- Remove the notion of space in the model, and replace it by "nested documents".
- Tune the rights system to inherit rights from parents to children.
Of course, we can discuss the technical details and the implementation strategies. But for now, we need to know if you accept the general idea (nested documents).
So, I hope you will like this proposal, and here is my +1.
I'm not convinced. I don't see why we should drop the parent/child relationship in order to introduce something similar but more complex. Thanks, Marius
Thanks,
Guillaume D.
[1] JCR: https://en.wikipedia.org/wiki/Content_repository_API_for_Java
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Marius, On 4 Jun 2015 at 18:16:03, Marius Dumitru Florea ([email protected](mailto:[email protected])) wrote:
On Wed, Jun 3, 2015 at 5:10 PM, Guillaume "Louis-Marie" Delhumeau wrote:
Hello XWiki committers.
Vincent have proposed the development of nested spaces for 7.2 and some of us have already agreed. But the concept of nested spaces introduces a problem that Denis have mentioned during some internal discussions at XWiki SAS, and that I am going to report here.
From a UI perspective, differentiating pages `A.B.C.WebHome` and `A.B.C` could become very difficult.
Moreover, we know that a lot of users do not understand the notion of spaces, and they are lost when you look at them during usability sessions.
I'm not sure about this statement. My feeling is that many users understand spaces as "folders" (they make the analogy with the file system). Moreover, whenever we display a space in the XWiki UI we use the folder icon, so we encourage the users to make this analogy.
I agree with Guillaume here. We’ve seen it on this list but more importantly Caty has done some recorded usability sessions and if I remember correctly it was clearly showing the problem. And users don’t understand that Spaces are like Folders which is why we also had this discussion on the list at one point about renaming them as Folder. In any case, removing one concept can only be simpler IMO. I find it simpler to have 2 concepts (Wiki, Pages: A wiki is a set of pages) instead of 3 (Wiki, Spaces, Pages: a wiki is a set of spaces, which each one containing pages).
The situation is even worse if you consider the notion of parent/child documents, which is completely unrelated to the actual hierarchy. It creates confusion!
To fix these problems, we propose to introduce the notion of "nested documents", i.e. the ability to create documents inside documents.
What's the difference at a *conceptual* level between the notion of parent/child we have right now and the notion of nested documents you propose? I don't see it.
Yes it’s the same thing from a User POV. One difference is that we want a reference to contain the full path of a doc. Right now you’d need to transport the (Doc Reference + the full Breadcrumb) to represent the same thing. But I agree that it’s the same concept, it’s just a different implementation. That’s why I’m proposing to drop the parent/child fields as we have them now since it’s just duplicating the concepts (and it’s confusing for users), and to reimplement the Breadcrumb UI using Doc References. Note that having the full location in the reference also allows to have URLs containing the full path which is interesting (for knowing where you are by looking at the URL: http://.../view/Space.Page1, http://.../view/Space.Page2 doesn’t indicate anything about the relationship between Page1 and Page2 when Page1 could the parent of Page2). It’s also interesting for SEO.
You even use "parent" and "child" words below to explain the "nested" notion. The word "nested" sounds very technical to me. I don't know about French, but in my native language the translation for "nested" is not a commonly used word, unlike parent and child. It seems easier to me to explan to a user that a document can have a parent document and some child documents (the parent / child relationship) then to explain them that a document can be "nested" inside another document and can "nest" other documents too.
I don’t think GL has suggested to use the word Nested anywhere in the UI… It’s just a word we use internally to describe the feature. I’m fine to continue using the terminology Parent and Children.
Say differently, if a page `A.B.C` exists, nothing should stop the user to create the document `A.B.C.D`.
You mentioned JCR on the next paragraph. Are JCR nodes identified by the position (path) in the tree?
Yes. They call it Path (we call it a Document Reference).
I think we should make a distinction between the way we identify a document and the way we access that document.
This means using unique ids for identifying docs (and this is what we already have in the DB except the Id is based on its path in the DB but this could be changed and this is our problem). Of course in the UI we should never display these ids.
I like the fact that currently when you change the parent of a document the document identifier (reference) stays the same.
It’s not fully true. When we rename a doc the doc id is modified. What would be interesting would be the ability to have several Document References for a given doc (with one being the default probably). This is something I’ve been interested in implementing for a long time but it would probably require some model changes and it’s not for XWiki 7.x IMO. We could discuss it when we talk about XWiki 8.x and the new model in general. See also http://design.xwiki.org/xwiki/bin/view/Design/XWikiModel20 (on that page I had put: “Ability to have multiple references pointing to the same entity” and yes this is also supported by the JCR API).
In JCR[1], there is only one concept: the "node". A node can have a content, and a list of child nodes. In XWiki, documents could become a kind of nodes, and we do not need spaces anymore.
If we don't have space anymore, we could ask ourselves: "How the rights will be propagated to the children documents? How do we distinguish rights applied to the documents and the rights applied to the children?"
I think the easiest solution is to inherit the rights from the parent to the children, unless an object prevent it. We already have this kind of mechanism with XWikiRights and XWikiGlobalRights. XWikiRights would be applied for the current document, and XWikiGlobalRights for the document and its children.
But changing the XWiki model is a lot of work, that we don't have time to achieve for 7.2. So we propose to make it step by step.
The first step is to change the UI to hide the notion of space to the users. Concretely, each time a user wants to create a page called `A`, we actually create the document `A.WebHome`. So any child of this page would be created in the `A` space, like `A.Child`. But this child would be in a space too, so it would be `A.Child.WebHome` actually.
I find this 'A.WebHome' thing too complex. Look at the document hierarchy tree http://extensions.xwiki.org/xwiki/bin/view/Extension/Document+Tree+Macro#HDo... . We can hide the spaces already by relying on the parent / child relationship.
A.WebHome is too complex which is exactly why Guillaume is sending this proposal about Nested Documents. The idea is that the doc will be seen as “A" for the user (and implemented technically as A.WebHome till we update the DB to remove the “space” field, which would make the impl much simpler).
Then, when we display the `A.WebHome` page, we remove all mentions to the `WebHome` name. In the UI, it will just be presented as the document `A`. This is a good point, knowing the fact that the term `WebHome` have no sense for the user, neither in English or in other languages.
Again, these changes are only for the UI. For the applications, it is the developer's job to decide if the app will create documents like `Document.WebHome` or basic documents just as before.
The question of what to do with AWM comes up. When a user creates an entry, should it be a new-kind-of-document (`AppSpace.Entry.WebHome`) or an old-kind-of-document (`AppSpace.Entry`)? The first option is good for consistency and for the new possibilities it offers, but the second is better for retro-compatibility. And the question will be the same for all existing applications that create pages. I believe we should answer these questions on a case-by-case basis and deserve their own mail threads.
This proposal also implies to change some macros, like the {{space}} one, and some panels. But I believe there is no blocking-point there.
Finally, after these steps are accomplished in 7.2 and polished until the end of the 7.x cycle, we will refactor the XWiki model (something we dream about for years).
To sum up, the idea we propose is:
On the short run:
- Hide the notion of space in the UI.
- Hide the `WebHome` name in the UI.
- When a user creates a page from the UI, it actually creates a space with a WebHome.
- Remove the current parent/child mechanism which is outdated (and confusing) compared to the new hierarchy.
On the long run:
- Remove the notion of space in the model, and replace it by "nested documents".
- Tune the rights system to inherit rights from parents to children.
Of course, we can discuss the technical details and the implementation strategies. But for now, we need to know if you accept the general idea (nested documents).
So, I hope you will like this proposal, and here is my +1.
I'm not convinced. I don't see why we should drop the parent/child relationship in order to introduce something similar but more complex.
I’d say mostly because we need to transport the full location in the Doc Reference, which allows us to do lots of things: - display it in the URL - no need to recompute the breadcrumb every time we need to display the hierarchy (which is the case now and it doesn’t scale) - ability in the future to have several references for a single doc - consistency: there’s no reason that the space would be in the reference but not the parent… ATM we have two concurrent concepts which makes it impossible for users to understand the difference between Spaces and child/parent relationships. Thanks -Vincent
Thanks, Marius
Thanks,
Guillaume D.
[1] JCR: https://en.wikipedia.org/wiki/Content_repository_API_for_Java
-- Guillaume Delhumeau ([email protected])
On 6 Jun 2015 at 14:20:46, [email protected] ([email protected](mailto:[email protected])) wrote:
Hi Marius,
On 4 Jun 2015 at 18:16:03, Marius Dumitru Florea ([email protected](mailto:[email protected])) wrote:
On Wed, Jun 3, 2015 at 5:10 PM, Guillaume "Louis-Marie" Delhumeau wrote:
Hello XWiki committers.
Vincent have proposed the development of nested spaces for 7.2 and some of us have already agreed. But the concept of nested spaces introduces a problem that Denis have mentioned during some internal discussions at XWiki SAS, and that I am going to report here.
From a UI perspective, differentiating pages `A.B.C.WebHome` and `A.B.C` could become very difficult.
Moreover, we know that a lot of users do not understand the notion of spaces, and they are lost when you look at them during usability sessions.
I'm not sure about this statement. My feeling is that many users understand spaces as "folders" (they make the analogy with the file system). Moreover, whenever we display a space in the XWiki UI we use the folder icon, so we encourage the users to make this analogy.
I agree with Guillaume here. We’ve seen it on this list but more importantly Caty has done some recorded usability sessions and if I remember correctly it was clearly showing the problem. And users don’t understand that Spaces are like Folders which is why we also had this discussion on the list at one point about renaming them as Folder.
In any case, removing one concept can only be simpler IMO. I find it simpler to have 2 concepts (Wiki, Pages: A wiki is a set of pages) instead of 3 (Wiki, Spaces, Pages: a wiki is a set of spaces, which each one containing pages).
The situation is even worse if you consider the notion of parent/child documents, which is completely unrelated to the actual hierarchy. It creates confusion!
To fix these problems, we propose to introduce the notion of "nested documents", i.e. the ability to create documents inside documents.
What's the difference at a *conceptual* level between the notion of parent/child we have right now and the notion of nested documents you propose? I don't see it.
Yes it’s the same thing from a User POV. One difference is that we want a reference to contain the full path of a doc. Right now you’d need to transport the (Doc Reference + the full Breadcrumb) to represent the same thing.
But I agree that it’s the same concept, it’s just a different implementation. That’s why I’m proposing to drop the parent/child fields as we have them now since it’s just duplicating the concepts (and it’s confusing for users), and to reimplement the Breadcrumb UI using Doc References.
Note that having the full location in the reference also allows to have URLs containing the full path which is interesting (for knowing where you are by looking at the URL: http://.../view/Space.Page1, http://.../view/Space.Page2 doesn’t indicate anything about the relationship between Page1 and Page2 when Page1 could the parent of Page2). It’s also interesting for SEO.
You even use "parent" and "child" words below to explain the "nested" notion. The word "nested" sounds very technical to me. I don't know about French, but in my native language the translation for "nested" is not a commonly used word, unlike parent and child. It seems easier to me to explan to a user that a document can have a parent document and some child documents (the parent / child relationship) then to explain them that a document can be "nested" inside another document and can "nest" other documents too.
I don’t think GL has suggested to use the word Nested anywhere in the UI… It’s just a word we use internally to describe the feature. I’m fine to continue using the terminology Parent and Children.
Say differently, if a page `A.B.C` exists, nothing should stop the user to create the document `A.B.C.D`.
You mentioned JCR on the next paragraph. Are JCR nodes identified by the position (path) in the tree?
Yes. They call it Path (we call it a Document Reference).
I think we should make a distinction between the way we identify a document and the way we access that document.
This means using unique ids for identifying docs (and this is what we already have in the DB except the Id is based on its path in the DB but this could be changed and this is our problem). Of course in the UI we should never display these ids.
I like the fact that currently when you change the parent of a document the document identifier (reference) stays the same.
It’s not fully true. When we rename a doc the doc id is modified.
What would be interesting would be the ability to have several Document References for a given doc (with one being the default probably). This is something I’ve been interested in implementing for a long time but it would probably require some model changes and it’s not for XWiki 7.x IMO. We could discuss it when we talk about XWiki 8.x and the new model in general. See also http://design.xwiki.org/xwiki/bin/view/Design/XWikiModel20 (on that page I had put: “Ability to have multiple references pointing to the same entity” and yes this is also supported by the JCR API).
Also note the idea of "An Entity can be a pointer to another Entity (e.g of use case: rename, aliases)” from that doc. This should be not to hard to implement using our current model by adding a Type field in the DB. But it’s a breaking change that would require 8.x (because current apps doing queries on the doc table would get the “pointer” Types which should be excluded, unless we add a filter to search*() APIs + the Query API). Thanks -Vincent
In JCR[1], there is only one concept: the "node". A node can have a content, and a list of child nodes. In XWiki, documents could become a kind of nodes, and we do not need spaces anymore.
If we don't have space anymore, we could ask ourselves: "How the rights will be propagated to the children documents? How do we distinguish rights applied to the documents and the rights applied to the children?"
I think the easiest solution is to inherit the rights from the parent to the children, unless an object prevent it. We already have this kind of mechanism with XWikiRights and XWikiGlobalRights. XWikiRights would be applied for the current document, and XWikiGlobalRights for the document and its children.
But changing the XWiki model is a lot of work, that we don't have time to achieve for 7.2. So we propose to make it step by step.
The first step is to change the UI to hide the notion of space to the users. Concretely, each time a user wants to create a page called `A`, we actually create the document `A.WebHome`. So any child of this page would be created in the `A` space, like `A.Child`. But this child would be in a space too, so it would be `A.Child.WebHome` actually.
I find this 'A.WebHome' thing too complex. Look at the document hierarchy tree http://extensions.xwiki.org/xwiki/bin/view/Extension/Document+Tree+Macro#HDo... . We can hide the spaces already by relying on the parent / child relationship.
A.WebHome is too complex which is exactly why Guillaume is sending this proposal about Nested Documents. The idea is that the doc will be seen as “A" for the user (and implemented technically as A.WebHome till we update the DB to remove the “space” field, which would make the impl much simpler).
Then, when we display the `A.WebHome` page, we remove all mentions to the `WebHome` name. In the UI, it will just be presented as the document `A`. This is a good point, knowing the fact that the term `WebHome` have no sense for the user, neither in English or in other languages.
Again, these changes are only for the UI. For the applications, it is the developer's job to decide if the app will create documents like `Document.WebHome` or basic documents just as before.
The question of what to do with AWM comes up. When a user creates an entry, should it be a new-kind-of-document (`AppSpace.Entry.WebHome`) or an old-kind-of-document (`AppSpace.Entry`)? The first option is good for consistency and for the new possibilities it offers, but the second is better for retro-compatibility. And the question will be the same for all existing applications that create pages. I believe we should answer these questions on a case-by-case basis and deserve their own mail threads.
This proposal also implies to change some macros, like the {{space}} one, and some panels. But I believe there is no blocking-point there.
Finally, after these steps are accomplished in 7.2 and polished until the end of the 7.x cycle, we will refactor the XWiki model (something we dream about for years).
To sum up, the idea we propose is:
On the short run:
- Hide the notion of space in the UI.
- Hide the `WebHome` name in the UI.
- When a user creates a page from the UI, it actually creates a space with a WebHome.
- Remove the current parent/child mechanism which is outdated (and confusing) compared to the new hierarchy.
On the long run:
- Remove the notion of space in the model, and replace it by "nested documents".
- Tune the rights system to inherit rights from parents to children.
Of course, we can discuss the technical details and the implementation strategies. But for now, we need to know if you accept the general idea (nested documents).
So, I hope you will like this proposal, and here is my +1.
I'm not convinced. I don't see why we should drop the parent/child relationship in order to introduce something similar but more complex.
I’d say mostly because we need to transport the full location in the Doc Reference, which allows us to do lots of things: - display it in the URL - no need to recompute the breadcrumb every time we need to display the hierarchy (which is the case now and it doesn’t scale) - ability in the future to have several references for a single doc - consistency: there’s no reason that the space would be in the reference but not the parent… ATM we have two concurrent concepts which makes it impossible for users to understand the difference between Spaces and child/parent relationships.
Thanks -Vincent
Thanks, Marius
Thanks,
Guillaume D.
[1] JCR: https://en.wikipedia.org/wiki/Content_repository_API_for_Java
-- Guillaume Delhumeau ([email protected])
Hi, Going on the "node" architecture, where we have only documents and child documents, here's something interesting that pops up as "the way to go" when storing a tree structure in SQL [1]: Closure Table [2]. It seems to cover pretty much all use cases, as solution 1 (Path Enumeration - what we are doing with the "space" document field) is limited [3] when it comes to changes in the tree structure (i.e. renaming/moving a document). Note: There is also the extension [4] that includes a depth column which would be most useful as well. Basically, getting the list of parents of a document would cost only 1 query, sorting by depth to preserve hierarchy. Of course, all this requires an extra table in the database for storing the hierarchy relationship. WDYT? Thanks, Eduard ---------- [1] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/48 [2] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/68 [3] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/77 [4] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/76 On Sat, Jun 6, 2015 at 3:38 PM, [email protected] <[email protected]> wrote:
On 6 Jun 2015 at 14:20:46, [email protected] ([email protected](mailto: [email protected])) wrote:
Hi Marius,
On 4 Jun 2015 at 18:16:03, Marius Dumitru Florea ( [email protected](mailto:[email protected])) wrote:
On Wed, Jun 3, 2015 at 5:10 PM, Guillaume "Louis-Marie" Delhumeau wrote:
Hello XWiki committers.
Vincent have proposed the development of nested spaces for 7.2 and some of us have already agreed. But the concept of nested spaces introduces a problem that Denis have mentioned during some internal discussions at XWiki SAS, and that I am going to report here.
From a UI perspective, differentiating pages `A.B.C.WebHome` and `A.B.C` could become very difficult.
Moreover, we know that a lot of users do not understand the notion of spaces, and they are lost when you look at them during usability sessions.
I'm not sure about this statement. My feeling is that many users understand spaces as "folders" (they make the analogy with the file system). Moreover, whenever we display a space in the XWiki UI we use the folder icon, so we encourage the users to make this analogy.
I agree with Guillaume here. We’ve seen it on this list but more importantly Caty has done some recorded usability sessions and if I remember correctly it was clearly showing the problem. And users don’t understand that Spaces are like Folders which is why we also had this discussion on the list at one point about renaming them as Folder.
In any case, removing one concept can only be simpler IMO. I find it simpler to have 2 concepts (Wiki, Pages: A wiki is a set of pages) instead of 3 (Wiki, Spaces, Pages: a wiki is a set of spaces, which each one containing pages).
The situation is even worse if you consider the notion of parent/child documents, which is completely unrelated to the actual hierarchy. It creates confusion!
To fix these problems, we propose to introduce the notion of "nested documents", i.e. the ability to create documents inside documents.
What's the difference at a *conceptual* level between the notion of parent/child we have right now and the notion of nested documents you propose? I don't see it.
Yes it’s the same thing from a User POV. One difference is that we want a reference to contain the full path of a doc. Right now you’d need to transport the (Doc Reference + the full Breadcrumb) to represent the same thing.
But I agree that it’s the same concept, it’s just a different implementation. That’s why I’m proposing to drop the parent/child fields as we have them now since it’s just duplicating the concepts (and it’s confusing for users), and to reimplement the Breadcrumb UI using Doc References.
Note that having the full location in the reference also allows to have URLs containing the full path which is interesting (for knowing where you are by looking at the URL: http://.../view/Space.Page1, http://.../view/Space.Page2 doesn’t indicate anything about the relationship between Page1 and Page2 when Page1 could the parent of Page2). It’s also interesting for SEO.
You even use "parent" and "child" words below to explain the "nested" notion. The word "nested" sounds very technical to me. I don't know about French, but in my native language the translation for "nested" is not a commonly used word, unlike parent and child. It seems easier to me to explan to a user that a document can have a parent document and some child documents (the parent / child relationship) then to explain them that a document can be "nested" inside another document and can "nest" other documents too.
I don’t think GL has suggested to use the word Nested anywhere in the UI… It’s just a word we use internally to describe the feature. I’m fine to continue using the terminology Parent and Children.
Say differently, if a page `A.B.C` exists, nothing should stop the user to create the document `A.B.C.D`.
You mentioned JCR on the next paragraph. Are JCR nodes identified by the position (path) in the tree?
Yes. They call it Path (we call it a Document Reference).
I think we should make a distinction between the way we identify a document and the way we access that document.
This means using unique ids for identifying docs (and this is what we already have in the DB except the Id is based on its path in the DB but this could be changed and this is our problem). Of course in the UI we should never display these ids.
I like the fact that currently when you change the parent of a document the document identifier (reference) stays the same.
It’s not fully true. When we rename a doc the doc id is modified.
What would be interesting would be the ability to have several Document References for a given doc (with one being the default probably). This is something I’ve been interested in implementing for a long time but it would probably require some model changes and it’s not for XWiki 7.x IMO. We could discuss it when we talk about XWiki 8.x and the new model in general. See also http://design.xwiki.org/xwiki/bin/view/Design/XWikiModel20 (on that page I had put: “Ability to have multiple references pointing to the same entity” and yes this is also supported by the JCR API).
Also note the idea of "An Entity can be a pointer to another Entity (e.g of use case: rename, aliases)” from that doc. This should be not to hard to implement using our current model by adding a Type field in the DB. But it’s a breaking change that would require 8.x (because current apps doing queries on the doc table would get the “pointer” Types which should be excluded, unless we add a filter to search*() APIs + the Query API).
Thanks -Vincent
In JCR[1], there is only one concept: the "node". A node can have a content, and a list of child nodes. In XWiki, documents could become a kind of nodes, and we do not need spaces anymore.
If we don't have space anymore, we could ask ourselves: "How the rights will be propagated to the children documents? How do we distinguish rights applied to the documents and the rights applied to the children?"
I think the easiest solution is to inherit the rights from the parent to the children, unless an object prevent it. We already have this kind of mechanism with XWikiRights and XWikiGlobalRights. XWikiRights would be applied for the current document, and XWikiGlobalRights for the document and its children.
But changing the XWiki model is a lot of work, that we don't have time to achieve for 7.2. So we propose to make it step by step.
The first step is to change the UI to hide the notion of space to the users. Concretely, each time a user wants to create a page called `A`, we actually create the document `A.WebHome`. So any child of this page would be created in the `A` space, like `A.Child`. But this child would be in a space too, so it would be `A.Child.WebHome` actually.
I find this 'A.WebHome' thing too complex. Look at the document hierarchy tree http://extensions.xwiki.org/xwiki/bin/view/Extension/Document+Tree+Macro#HDo... . We can hide the spaces already by relying on the parent / child relationship.
A.WebHome is too complex which is exactly why Guillaume is sending this proposal about Nested Documents. The idea is that the doc will be seen as “A" for the user (and implemented technically as A.WebHome till we update the DB to remove the “space” field, which would make the impl much simpler).
Then, when we display the `A.WebHome` page, we remove all mentions to the `WebHome` name. In the UI, it will just be presented as the document `A`. This is a good point, knowing the fact that the term `WebHome` have no sense for the user, neither in English or in other languages.
Again, these changes are only for the UI. For the applications, it is the developer's job to decide if the app will create documents like `Document.WebHome` or basic documents just as before.
The question of what to do with AWM comes up. When a user creates an entry, should it be a new-kind-of-document (`AppSpace.Entry.WebHome`) or an old-kind-of-document (`AppSpace.Entry`)? The first option is good for consistency and for the new possibilities it offers, but the second is better for retro-compatibility. And the question will be the same for all existing applications that create pages. I believe we should answer these questions on a case-by-case basis and deserve their own mail threads.
This proposal also implies to change some macros, like the {{space}} one, and some panels. But I believe there is no blocking-point there.
Finally, after these steps are accomplished in 7.2 and polished until the end of the 7.x cycle, we will refactor the XWiki model (something we dream about for years).
To sum up, the idea we propose is:
On the short run:
- Hide the notion of space in the UI.
- Hide the `WebHome` name in the UI.
- When a user creates a page from the UI, it actually creates a space with a WebHome.
- Remove the current parent/child mechanism which is outdated (and confusing) compared to the new hierarchy.
On the long run:
- Remove the notion of space in the model, and replace it by "nested documents".
- Tune the rights system to inherit rights from parents to children.
Of course, we can discuss the technical details and the implementation strategies. But for now, we need to know if you accept the general idea (nested documents).
So, I hope you will like this proposal, and here is my +1.
I'm not convinced. I don't see why we should drop the parent/child relationship in order to introduce something similar but more complex.
I’d say mostly because we need to transport the full location in the Doc Reference, which allows us to do lots of things: - display it in the URL - no need to recompute the breadcrumb every time we need to display the hierarchy (which is the case now and it doesn’t scale) - ability in the future to have several references for a single doc - consistency: there’s no reason that the space would be in the reference but not the parent… ATM we have two concurrent concepts which makes it impossible for users to understand the difference between Spaces and child/parent relationships.
Thanks -Vincent
Thanks, Marius
Thanks,
Guillaume D.
[1] JCR:
https://en.wikipedia.org/wiki/Content_repository_API_for_Java
-- Guillaume Delhumeau ([email protected])
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, Since we discussed so many things lately and there are many technical constrain that we are facing, I'm going to try to get some conclusions from the UI perspective: First of all there was the discussion about the usability tests. It's true that users are confused that we provide 2 levels of hierarchy (wiki/space/page and parent/child). If we can switch to just one it would be great since it will simplify the user's mental model. Another problem they had was with the naming, since wiki/space/page does not ring any folder/page bell, even with the icon usage. That's why I like the concept of nodes and only one type of entities that can have children. Since we are on the Web, I think the most likely entity name we could use is 'page', similar to content-page, web-page, wiki-page (even if technically is a space or a document). Having only one type of entity, I agree to the fact that we should remove the space notion. We still have complexity, since we will have main-wiki, wikis*, pages* (child-pages). I also agree to remove the notion of 'WebHome' from UI. We can still use it technically to differentiate old spaces from pages, but for the user doesn't mean anything, except looking technical. Regarding the global-menu, we need to remove the wiki>space>page+actions display since it is not scalable. This means that the current breadcrumb zone will display the hierarchy. This is perfectly normal with the current navigation patterns used all over the Web. Note that classical breadcrumb do not display entity-type or actions. We shouldn't either. This means (as stated on http://design.xwiki.org/xwiki/bin/view/Proposal/ExtendedBreadcrumb) that we need to provide a Drawer + Move actions inside the content-menu. Regarding actions, since we will have just one entity-type (not sure what we do with the wikis) we will need to standardize the entity actions. Currently we provide just 'Delete' for spaces, but if we don't display Spaces differently and they are just nodes, this means that we will need to implement or normalize the available actions. No matter what type it is technically, the user should be able to: Add (child), Edit, Delete, View, Administer, Copy, Rename, Move, Export, Watch, View History, View Informations, View Attachments, View Comments, View Rights, View Objects, etc. Now, what I really don't like are the long URL. For me this is the most bad decision we can make. Nobody uses long URL on the web. I really like the way our current parent/child works, it provides the hierarchy in the UI, invisible in the URL (keeping it relevant to the current page). Hierarchy anyway should we displayed in Trees, not linear in URLs, since it's hard to read. People like short URL. They are easier to share, easier to scan, easier to understand what the content is about. We have the breadcrumbs for navigation, the URL is for identification. Thanks, Caty On Mon, Jun 8, 2015 at 11:40 AM, Eduard Moraru <[email protected]> wrote:
Hi,
Going on the "node" architecture, where we have only documents and child documents, here's something interesting that pops up as "the way to go" when storing a tree structure in SQL [1]: Closure Table [2]. It seems to cover pretty much all use cases, as solution 1 (Path Enumeration - what we are doing with the "space" document field) is limited [3] when it comes to changes in the tree structure (i.e. renaming/moving a document).
Note: There is also the extension [4] that includes a depth column which would be most useful as well. Basically, getting the list of parents of a document would cost only 1 query, sorting by depth to preserve hierarchy.
Of course, all this requires an extra table in the database for storing the hierarchy relationship.
WDYT?
Thanks, Eduard
---------- [1] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/48 [2] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/68 [3] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/77 [4] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/76
On Sat, Jun 6, 2015 at 3:38 PM, [email protected] <[email protected]> wrote:
On 6 Jun 2015 at 14:20:46, [email protected] ([email protected]
(mailto:
[email protected])) wrote:
Hi Marius,
On 4 Jun 2015 at 18:16:03, Marius Dumitru Florea ( [email protected](mailto:[email protected])) wrote:
On Wed, Jun 3, 2015 at 5:10 PM, Guillaume "Louis-Marie" Delhumeau wrote:
Hello XWiki committers.
Vincent have proposed the development of nested spaces for 7.2 and some of us have already agreed. But the concept of nested spaces introduces a problem that Denis have mentioned during some internal discussions at XWiki SAS, and that I am going to report here.
From a UI perspective, differentiating pages `A.B.C.WebHome` and `A.B.C` could become very difficult.
Moreover, we know that a lot of users do not understand the notion of spaces, and they are lost when you look at them during usability sessions.
I'm not sure about this statement. My feeling is that many users understand spaces as "folders" (they make the analogy with the file system). Moreover, whenever we display a space in the XWiki UI we use the folder icon, so we encourage the users to make this analogy.
I agree with Guillaume here. We’ve seen it on this list but more importantly Caty has done some recorded usability sessions and if I remember correctly it was clearly showing the problem. And users don’t understand that Spaces are like Folders which is why we also had this discussion on the list at one point about renaming them as Folder.
In any case, removing one concept can only be simpler IMO. I find it simpler to have 2 concepts (Wiki, Pages: A wiki is a set of pages) instead of 3 (Wiki, Spaces, Pages: a wiki is a set of spaces, which each one containing pages).
The situation is even worse if you consider the notion of parent/child documents, which is completely unrelated to the actual hierarchy. It creates confusion!
To fix these problems, we propose to introduce the notion of "nested documents", i.e. the ability to create documents inside documents.
What's the difference at a *conceptual* level between the notion of parent/child we have right now and the notion of nested documents you propose? I don't see it.
Yes it’s the same thing from a User POV. One difference is that we want a reference to contain the full path of a doc. Right now you’d need to transport the (Doc Reference + the full Breadcrumb) to represent the same thing.
But I agree that it’s the same concept, it’s just a different implementation. That’s why I’m proposing to drop the parent/child fields as we have them now since it’s just duplicating the concepts (and it’s confusing for users), and to reimplement the Breadcrumb UI using Doc References.
Note that having the full location in the reference also allows to have URLs containing the full path which is interesting (for knowing where you are by looking at the URL: http://.../view/Space.Page1, http:// .../view/Space.Page2 doesn’t indicate anything about the relationship between Page1 and Page2 when Page1 could the parent of Page2). It’s also interesting for SEO.
You even use "parent" and "child" words below to explain the "nested" notion. The word "nested" sounds very technical to me. I don't know about French, but in my native language the translation for "nested" is not a commonly used word, unlike parent and child. It seems easier to me to explan to a user that a document can have a parent document and some child documents (the parent / child relationship) then to explain them that a document can be "nested" inside another document and can "nest" other documents too.
I don’t think GL has suggested to use the word Nested anywhere in the UI… It’s just a word we use internally to describe the feature. I’m fine to continue using the terminology Parent and Children.
Say differently, if a page `A.B.C` exists, nothing should stop the user to create the document `A.B.C.D`.
You mentioned JCR on the next paragraph. Are JCR nodes identified by the position (path) in the tree?
Yes. They call it Path (we call it a Document Reference).
I think we should make a distinction between the way we identify a document and the way we access that document.
This means using unique ids for identifying docs (and this is what we already have in the DB except the Id is based on its path in the DB but this could be changed and this is our problem). Of course in the UI we should never display these ids.
I like the fact that currently when you change the parent of a document the document identifier (reference) stays the same.
It’s not fully true. When we rename a doc the doc id is modified.
What would be interesting would be the ability to have several Document References for a given doc (with one being the default probably). This is something I’ve been interested in implementing for a long time but it would probably require some model changes and it’s not for XWiki 7.x IMO. We could discuss it when we talk about XWiki 8.x and the new model in general. See also http://design.xwiki.org/xwiki/bin/view/Design/XWikiModel20 (on that page I had put: “Ability to have multiple references pointing to the same entity” and yes this is also supported by the JCR API).
Also note the idea of "An Entity can be a pointer to another Entity (e.g of use case: rename, aliases)” from that doc. This should be not to hard to implement using our current model by adding a Type field in the DB. But it’s a breaking change that would require 8.x (because current apps doing queries on the doc table would get the “pointer” Types which should be excluded, unless we add a filter to search*() APIs + the Query API).
Thanks -Vincent
In JCR[1], there is only one concept: the "node". A node can have a content, and a list of child nodes. In XWiki, documents could become a kind of nodes, and we do not need spaces anymore.
If we don't have space anymore, we could ask ourselves: "How the rights will be propagated to the children documents? How do we distinguish rights applied to the documents and the rights applied to the children?"
I think the easiest solution is to inherit the rights from the parent to the children, unless an object prevent it. We already have this kind of mechanism with XWikiRights and XWikiGlobalRights. XWikiRights would be applied for the current document, and XWikiGlobalRights for the document and its children.
But changing the XWiki model is a lot of work, that we don't have time to achieve for 7.2. So we propose to make it step by step.
The first step is to change the UI to hide the notion of space to the users. Concretely, each time a user wants to create a page called `A`, we actually create the document `A.WebHome`. So any child of this page would be created in the `A` space, like `A.Child`. But this child would be in a space too, so it would be `A.Child.WebHome` actually.
I find this 'A.WebHome' thing too complex. Look at the document hierarchy tree
http://extensions.xwiki.org/xwiki/bin/view/Extension/Document+Tree+Macro#HDo...
. We can hide the spaces already by relying on the parent / child relationship.
A.WebHome is too complex which is exactly why Guillaume is sending this proposal about Nested Documents. The idea is that the doc will be seen as “A" for the user (and implemented technically as A.WebHome till we update the DB to remove the “space” field, which would make the impl much simpler).
Then, when we display the `A.WebHome` page, we remove all mentions to the `WebHome` name. In the UI, it will just be presented as the document `A`. This is a good point, knowing the fact that the term `WebHome` have no sense for the user, neither in English or in other languages.
Again, these changes are only for the UI. For the applications, it is the developer's job to decide if the app will create documents like `Document.WebHome` or basic documents just as before.
The question of what to do with AWM comes up. When a user creates an entry, should it be a new-kind-of-document (`AppSpace.Entry.WebHome`) or an old-kind-of-document (`AppSpace.Entry`)? The first option is good for consistency and for the new possibilities it offers, but the second is better for retro-compatibility. And the question will be the same for all existing applications that create pages. I believe we should answer these questions on a case-by-case basis and deserve their own mail threads.
This proposal also implies to change some macros, like the {{space}} one, and some panels. But I believe there is no blocking-point there.
Finally, after these steps are accomplished in 7.2 and polished until the end of the 7.x cycle, we will refactor the XWiki model (something we dream about for years).
To sum up, the idea we propose is:
On the short run:
- Hide the notion of space in the UI.
- Hide the `WebHome` name in the UI.
- When a user creates a page from the UI, it actually creates a space with a WebHome.
- Remove the current parent/child mechanism which is outdated (and confusing) compared to the new hierarchy.
On the long run:
- Remove the notion of space in the model, and replace it by "nested documents".
- Tune the rights system to inherit rights from parents to children.
Of course, we can discuss the technical details and the implementation strategies. But for now, we need to know if you accept the general idea (nested documents).
So, I hope you will like this proposal, and here is my +1.
I'm not convinced. I don't see why we should drop the parent/child relationship in order to introduce something similar but more complex.
I’d say mostly because we need to transport the full location in the Doc Reference, which allows us to do lots of things: - display it in the URL - no need to recompute the breadcrumb every time we need to display the hierarchy (which is the case now and it doesn’t scale) - ability in the future to have several references for a single doc - consistency: there’s no reason that the space would be in the reference but not the parent… ATM we have two concurrent concepts which makes it impossible for users to understand the difference between Spaces and child/parent relationships.
Thanks -Vincent
Thanks, Marius
Thanks,
Guillaume D.
[1] JCR:
https://en.wikipedia.org/wiki/Content_repository_API_for_Java
-- Guillaume Delhumeau ([email protected])
_______________________________________________ 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, Jun 10, 2015 at 6:36 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
Hi,
Since we discussed so many things lately and there are many technical constrain that we are facing, I'm going to try to get some conclusions from the UI perspective:
First of all there was the discussion about the usability tests. It's true that users are confused that we provide 2 levels of hierarchy (wiki/space/page and parent/child). If we can switch to just one it would be great since it will simplify the user's mental model. Another problem they had was with the naming, since wiki/space/page does not ring any folder/page bell, even with the icon usage. That's why I like the concept of nodes and only one type of entities that can have children. Since we are on the Web, I think the most likely entity name we could use is 'page', similar to content-page, web-page, wiki-page (even if technically is a space or a document).
Having only one type of entity, I agree to the fact that we should remove the space notion. We still have complexity, since we will have main-wiki, wikis*, pages* (child-pages).
I also agree to remove the notion of 'WebHome' from UI. We can still use it technically to differentiate old spaces from pages, but for the user doesn't mean anything, except looking technical.
Regarding the global-menu, we need to remove the wiki>space>page+actions display since it is not scalable. This means that the current breadcrumb zone will display the hierarchy. This is perfectly normal with the current navigation patterns used all over the Web. Note that classical breadcrumb do not display entity-type or actions. We shouldn't either. This means (as stated on http://design.xwiki.org/xwiki/bin/view/Proposal/ExtendedBreadcrumb) that we need to provide a Drawer + Move actions inside the content-menu.
Regarding actions, since we will have just one entity-type (not sure what we do with the wikis) we will need to standardize the entity actions. Currently we provide just 'Delete' for spaces, but if we don't display Spaces differently and they are just nodes, this means that we will need to implement or normalize the available actions. No matter what type it is technically, the user should be able to: Add (child), Edit, Delete, View, Administer, Copy, Rename, Move, Export, Watch, View History, View Informations, View Attachments, View Comments, View Rights, View Objects, etc.
Now, what I really don't like are the long URL. For me this is the most bad decision we can make. Nobody uses long URL on the web. I really like the way our current parent/child works, it provides the hierarchy in the UI, invisible in the URL (keeping it relevant to the current page). Hierarchy anyway should we displayed in Trees, not linear in URLs, since it's hard to read. People like short URL. They are easier to share, easier to scan, easier to understand what the content is about. We have the breadcrumbs for navigation, the URL is for identification.
+1, I don't like long URLs either. Thanks, Marius
Thanks, Caty
On Mon, Jun 8, 2015 at 11:40 AM, Eduard Moraru <[email protected]> wrote:
Hi,
Going on the "node" architecture, where we have only documents and child documents, here's something interesting that pops up as "the way to go" when storing a tree structure in SQL [1]: Closure Table [2]. It seems to cover pretty much all use cases, as solution 1 (Path Enumeration - what we are doing with the "space" document field) is limited [3] when it comes to changes in the tree structure (i.e. renaming/moving a document).
Note: There is also the extension [4] that includes a depth column which would be most useful as well. Basically, getting the list of parents of a document would cost only 1 query, sorting by depth to preserve hierarchy.
Of course, all this requires an extra table in the database for storing the hierarchy relationship.
WDYT?
Thanks, Eduard
---------- [1] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/48 [2] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/68 [3] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/77 [4] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/76
On Sat, Jun 6, 2015 at 3:38 PM, [email protected] <[email protected]> wrote:
On 6 Jun 2015 at 14:20:46, [email protected] ([email protected]
(mailto:
[email protected])) wrote:
Hi Marius,
On 4 Jun 2015 at 18:16:03, Marius Dumitru Florea ( [email protected](mailto:[email protected])) wrote:
On Wed, Jun 3, 2015 at 5:10 PM, Guillaume "Louis-Marie" Delhumeau wrote:
Hello XWiki committers.
Vincent have proposed the development of nested spaces for 7.2 and some of us have already agreed. But the concept of nested spaces introduces a problem that Denis have mentioned during some internal discussions at XWiki SAS, and that I am going to report here.
From a UI perspective, differentiating pages `A.B.C.WebHome` and `A.B.C` could become very difficult.
Moreover, we know that a lot of users do not understand the notion of spaces, and they are lost when you look at them during usability sessions.
I'm not sure about this statement. My feeling is that many users understand spaces as "folders" (they make the analogy with the file system). Moreover, whenever we display a space in the XWiki UI we use the folder icon, so we encourage the users to make this analogy.
I agree with Guillaume here. We’ve seen it on this list but more importantly Caty has done some recorded usability sessions and if I remember correctly it was clearly showing the problem. And users don’t understand that Spaces are like Folders which is why we also had this discussion on the list at one point about renaming them as Folder.
In any case, removing one concept can only be simpler IMO. I find it simpler to have 2 concepts (Wiki, Pages: A wiki is a set of pages) instead of 3 (Wiki, Spaces, Pages: a wiki is a set of spaces, which each one containing pages).
The situation is even worse if you consider the notion of parent/child documents, which is completely unrelated to the actual hierarchy. It creates confusion!
To fix these problems, we propose to introduce the notion of "nested documents", i.e. the ability to create documents inside documents.
What's the difference at a *conceptual* level between the notion of parent/child we have right now and the notion of nested documents you propose? I don't see it.
Yes it’s the same thing from a User POV. One difference is that we want a reference to contain the full path of a doc. Right now you’d need to transport the (Doc Reference + the full Breadcrumb) to represent the same thing.
But I agree that it’s the same concept, it’s just a different implementation. That’s why I’m proposing to drop the parent/child fields as we have them now since it’s just duplicating the concepts (and it’s confusing for users), and to reimplement the Breadcrumb UI using Doc References.
Note that having the full location in the reference also allows to have URLs containing the full path which is interesting (for knowing where you are by looking at the URL: http://.../view/Space.Page1, http:// .../view/Space.Page2 doesn’t indicate anything about the relationship between Page1 and Page2 when Page1 could the parent of Page2). It’s also interesting for SEO.
You even use "parent" and "child" words below to explain the "nested" notion. The word "nested" sounds very technical to me. I don't know about French, but in my native language the translation for "nested" is not a commonly used word, unlike parent and child. It seems easier to me to explan to a user that a document can have a parent document and some child documents (the parent / child relationship) then to explain them that a document can be "nested" inside another document and can "nest" other documents too.
I don’t think GL has suggested to use the word Nested anywhere in the UI… It’s just a word we use internally to describe the feature. I’m fine to continue using the terminology Parent and Children.
Say differently, if a page `A.B.C` exists, nothing should stop the user to create the document `A.B.C.D`.
You mentioned JCR on the next paragraph. Are JCR nodes identified by the position (path) in the tree?
Yes. They call it Path (we call it a Document Reference).
I think we should make a distinction between the way we identify a document and the way we access that document.
This means using unique ids for identifying docs (and this is what we already have in the DB except the Id is based on its path in the DB but this could be changed and this is our problem). Of course in the UI we should never display these ids.
I like the fact that currently when you change the parent of a document the document identifier (reference) stays the same.
It’s not fully true. When we rename a doc the doc id is modified.
What would be interesting would be the ability to have several Document References for a given doc (with one being the default probably). This is something I’ve been interested in implementing for a long time but it would probably require some model changes and it’s not for XWiki 7.x IMO. We could discuss it when we talk about XWiki 8.x and the new model in general. See also http://design.xwiki.org/xwiki/bin/view/Design/XWikiModel20 (on that page I had put: “Ability to have multiple references pointing to the same entity” and yes this is also supported by the JCR API).
Also note the idea of "An Entity can be a pointer to another Entity (e.g of use case: rename, aliases)” from that doc. This should be not to hard to implement using our current model by adding a Type field in the DB. But it’s a breaking change that would require 8.x (because current apps doing queries on the doc table would get the “pointer” Types which should be excluded, unless we add a filter to search*() APIs + the Query API).
Thanks -Vincent
In JCR[1], there is only one concept: the "node". A node can have a content, and a list of child nodes. In XWiki, documents could become a kind of nodes, and we do not need spaces anymore.
If we don't have space anymore, we could ask ourselves: "How the rights will be propagated to the children documents? How do we distinguish rights applied to the documents and the rights applied to the children?"
I think the easiest solution is to inherit the rights from the parent to the children, unless an object prevent it. We already have this kind of mechanism with XWikiRights and XWikiGlobalRights. XWikiRights would be applied for the current document, and XWikiGlobalRights for the document and its children.
But changing the XWiki model is a lot of work, that we don't have time to achieve for 7.2. So we propose to make it step by step.
The first step is to change the UI to hide the notion of space to the users. Concretely, each time a user wants to create a page called `A`, we actually create the document `A.WebHome`. So any child of this page would be created in the `A` space, like `A.Child`. But this child would be in a space too, so it would be `A.Child.WebHome` actually.
I find this 'A.WebHome' thing too complex. Look at the document hierarchy tree
http://extensions.xwiki.org/xwiki/bin/view/Extension/Document+Tree+Macro#HDo...
. We can hide the spaces already by relying on the parent / child relationship.
A.WebHome is too complex which is exactly why Guillaume is sending this proposal about Nested Documents. The idea is that the doc will be seen as “A" for the user (and implemented technically as A.WebHome till we update the DB to remove the “space” field, which would make the impl much simpler).
Then, when we display the `A.WebHome` page, we remove all mentions to the `WebHome` name. In the UI, it will just be presented as the document `A`. This is a good point, knowing the fact that the term `WebHome` have no sense for the user, neither in English or in other languages.
Again, these changes are only for the UI. For the applications, it is the developer's job to decide if the app will create documents like `Document.WebHome` or basic documents just as before.
The question of what to do with AWM comes up. When a user creates an entry, should it be a new-kind-of-document (`AppSpace.Entry.WebHome`) or an old-kind-of-document (`AppSpace.Entry`)? The first option is good for consistency and for the new possibilities it offers, but the second is better for retro-compatibility. And the question will be the same for all existing applications that create pages. I believe we should answer these questions on a case-by-case basis and deserve their own mail threads.
This proposal also implies to change some macros, like the {{space}} one, and some panels. But I believe there is no blocking-point there.
Finally, after these steps are accomplished in 7.2 and polished until the end of the 7.x cycle, we will refactor the XWiki model (something we dream about for years).
To sum up, the idea we propose is:
On the short run:
- Hide the notion of space in the UI.
- Hide the `WebHome` name in the UI.
- When a user creates a page from the UI, it actually creates a space with a WebHome.
- Remove the current parent/child mechanism which is outdated (and confusing) compared to the new hierarchy.
On the long run:
- Remove the notion of space in the model, and replace it by "nested documents".
- Tune the rights system to inherit rights from parents to children.
Of course, we can discuss the technical details and the implementation strategies. But for now, we need to know if you accept the general idea (nested documents).
So, I hope you will like this proposal, and here is my +1.
I'm not convinced. I don't see why we should drop the parent/child relationship in order to introduce something similar but more complex.
I’d say mostly because we need to transport the full location in the Doc Reference, which allows us to do lots of things: - display it in the URL - no need to recompute the breadcrumb every time we need to display the hierarchy (which is the case now and it doesn’t scale) - ability in the future to have several references for a single doc - consistency: there’s no reason that the space would be in the reference but not the parent… ATM we have two concurrent concepts which makes it impossible for users to understand the difference between Spaces and child/parent relationships.
Thanks -Vincent
Thanks, Marius
Thanks,
Guillaume D.
[1] JCR:
https://en.wikipedia.org/wiki/Content_repository_API_for_Java
-- Guillaume Delhumeau ([email protected])
_______________________________________________ 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
+1, with the same opinion on long URLs. So we need a way to have a document hierarchy without impacting the URL scheme, unless the admins of the wiki explicitly want to configure it that way. This means, as Caty suggested in an offline discussion, not doing the proposed item: "- Remove the current parent/child mechanism which is outdated (and confusing) compared to the new hierarchy." We still need the parent/child mechanism, but we could disable it by default and allow admins that create a new wiki or that migrate from a previous XWiki version that does not have ND to preserve their hierarchy and not change their URLs. The direction would obviously be to encourage the creation of Nested Documents, while still keeping the option of having shorter URLs (using parent-child). Note: If we keep both relationships (space-page and parent-child) the create/move/etc UIs will need to check if the parent-child relationship is enabled and provide a field to set/alter that too. Thanks, Eduard On Thu, Jun 11, 2015 at 12:54 PM, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Jun 10, 2015 at 6:36 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
Hi,
Since we discussed so many things lately and there are many technical constrain that we are facing, I'm going to try to get some conclusions from the UI perspective:
First of all there was the discussion about the usability tests. It's true that users are confused that we provide 2 levels of hierarchy (wiki/space/page and parent/child). If we can switch to just one it would be great since it will simplify the user's mental model. Another problem they had was with the naming, since wiki/space/page does not ring any folder/page bell, even with the icon usage. That's why I like the concept of nodes and only one type of entities that can have children. Since we are on the Web, I think the most likely entity name we could use is 'page', similar to content-page, web-page, wiki-page (even if technically is a space or a document).
Having only one type of entity, I agree to the fact that we should remove the space notion. We still have complexity, since we will have main-wiki, wikis*, pages* (child-pages).
I also agree to remove the notion of 'WebHome' from UI. We can still use it technically to differentiate old spaces from pages, but for the user doesn't mean anything, except looking technical.
Regarding the global-menu, we need to remove the wiki>space>page+actions display since it is not scalable. This means that the current breadcrumb zone will display the hierarchy. This is perfectly normal with the current navigation patterns used all over the Web. Note that classical breadcrumb do not display entity-type or actions. We shouldn't either. This means (as stated on http://design.xwiki.org/xwiki/bin/view/Proposal/ExtendedBreadcrumb) that we need to provide a Drawer + Move actions inside the content-menu.
Regarding actions, since we will have just one entity-type (not sure what we do with the wikis) we will need to standardize the entity actions. Currently we provide just 'Delete' for spaces, but if we don't display Spaces differently and they are just nodes, this means that we will need to implement or normalize the available actions. No matter what type it is technically, the user should be able to: Add (child), Edit, Delete, View, Administer, Copy, Rename, Move, Export, Watch, View History, View Informations, View Attachments, View Comments, View Rights, View Objects, etc.
Now, what I really don't like are the long URL. For me this is the most bad decision we can make. Nobody uses long URL on the web. I really like the way our current parent/child works, it provides the hierarchy in the UI, invisible in the URL (keeping it relevant to the current page). Hierarchy anyway should we displayed in Trees, not linear in URLs, since it's hard to read. People like short URL. They are easier to share, easier to scan, easier to understand what the content is about. We have the breadcrumbs for navigation, the URL is for identification.
+1, I don't like long URLs either.
Thanks, Marius
Thanks, Caty
On Mon, Jun 8, 2015 at 11:40 AM, Eduard Moraru <[email protected]>
wrote:
Hi,
Going on the "node" architecture, where we have only documents and child documents, here's something interesting that pops up as "the way to go" when storing a tree structure in SQL [1]: Closure Table [2]. It seems to cover pretty much all use cases, as solution 1 (Path Enumeration - what
we
are doing with the "space" document field) is limited [3] when it comes to changes in the tree structure (i.e. renaming/moving a document).
Note: There is also the extension [4] that includes a depth column which would be most useful as well. Basically, getting the list of parents of a document would cost only 1 query, sorting by depth to preserve hierarchy.
Of course, all this requires an extra table in the database for storing the hierarchy relationship.
WDYT?
Thanks, Eduard
---------- [1] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/48 [2] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/68 [3] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/77 [4] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/76
On Sat, Jun 6, 2015 at 3:38 PM, [email protected] <[email protected]> wrote:
On 6 Jun 2015 at 14:20:46, [email protected] ([email protected]
(mailto:
[email protected])) wrote:
Hi Marius,
On 4 Jun 2015 at 18:16:03, Marius Dumitru Florea ( [email protected](mailto:[email protected] )) wrote:
On Wed, Jun 3, 2015 at 5:10 PM, Guillaume "Louis-Marie" Delhumeau wrote: > Hello XWiki committers. > > > Vincent have proposed the development of nested spaces for 7.2 and some of > us have already agreed. But the concept of nested spaces introduces a > problem that Denis have mentioned during some internal discussions at XWiki > SAS, and that I am going to report here. > > > From a UI perspective, differentiating pages `A.B.C.WebHome` and `A.B.C` > could become very difficult. > >
> Moreover, we know that a lot of users do not understand the notion of > spaces, and they are lost when you look at them during usability sessions.
I'm not sure about this statement. My feeling is that many users understand spaces as "folders" (they make the analogy with the file system). Moreover, whenever we display a space in the XWiki UI we use the folder icon, so we encourage the users to make this analogy.
I agree with Guillaume here. We’ve seen it on this list but more importantly Caty has done some recorded usability sessions and if I remember correctly it was clearly showing the problem. And users don’t understand that Spaces are like Folders which is why we also had this discussion on the list at one point about renaming them as Folder.
In any case, removing one concept can only be simpler IMO. I find it simpler to have 2 concepts (Wiki, Pages: A wiki is a set of pages) instead of 3 (Wiki, Spaces, Pages: a wiki is a set of spaces, which each one containing pages).
> The situation is even worse if you consider the notion of parent/child > documents, which is completely unrelated to the actual hierarchy. It > creates confusion! > >
> To fix these problems, we propose to introduce the notion of "nested > documents", i.e. the ability to create documents inside documents.
What's the difference at a *conceptual* level between the notion of parent/child we have right now and the notion of nested documents you propose? I don't see it.
Yes it’s the same thing from a User POV. One difference is that we want a reference to contain the full path of a doc. Right now you’d need to transport the (Doc Reference + the full Breadcrumb) to represent the same thing.
But I agree that it’s the same concept, it’s just a different implementation. That’s why I’m proposing to drop the parent/child fields as we have them now since it’s just duplicating the concepts (and it’s confusing for users), and to reimplement the Breadcrumb UI using Doc References.
Note that having the full location in the reference also allows to have URLs containing the full path which is interesting (for knowing where you are by looking at the URL: http://.../view/Space.Page1, http:// .../view/Space.Page2 doesn’t indicate anything about the relationship between Page1 and Page2 when Page1 could the parent of Page2). It’s also interesting for SEO.
You even use "parent" and "child" words below to explain the "nested" notion. The word "nested" sounds very technical to me. I don't know about French, but in my native language the translation for "nested" is not a commonly used word, unlike parent and child. It seems easier to me to explan to a user that a document can have a parent document and some child documents (the parent / child relationship) then to explain them that a document can be "nested" inside another document and can "nest" other documents too.
I don’t think GL has suggested to use the word Nested anywhere in the UI… It’s just a word we use internally to describe the feature. I’m fine to continue using the terminology Parent and Children.
> Say differently, if a page `A.B.C` exists, nothing should stop the user to > create the document `A.B.C.D`.
You mentioned JCR on the next paragraph. Are JCR nodes identified by the position (path) in the tree?
Yes. They call it Path (we call it a Document Reference).
I think we should make a distinction between the way we identify a document and the way we access that document.
This means using unique ids for identifying docs (and this is what we already have in the DB except the Id is based on its path in the DB but this could be changed and this is our problem). Of course in the UI we should never display these ids.
I like the fact that currently when you change the parent of a document the document identifier (reference) stays the same.
It’s not fully true. When we rename a doc the doc id is modified.
What would be interesting would be the ability to have several Document References for a given doc (with one being the default probably). This is something I’ve been interested in implementing for a long time but it would probably require some model changes and it’s not for XWiki 7.x IMO. We could discuss it when we talk about XWiki 8.x and the new model in general. See also http://design.xwiki.org/xwiki/bin/view/Design/XWikiModel20 (on that page I had put: “Ability to have multiple references pointing to the same entity” and yes this is also supported by the JCR API).
Also note the idea of "An Entity can be a pointer to another Entity (e.g of use case: rename, aliases)” from that doc. This should be not to hard to implement using our current model by adding a Type field in the DB. But it’s a breaking change that would require 8.x (because current apps doing queries on the doc table would get the “pointer” Types which should be excluded, unless we add a filter to search*() APIs + the Query API).
Thanks -Vincent
> In JCR[1], there is only one concept: the "node". A node can have a > content, and a list of child nodes. In XWiki, documents could become a kind > of nodes, and we do not need spaces anymore. > > > If we don't have space anymore, we could ask ourselves: "How the rights > will be propagated to the children documents? How do we distinguish rights > applied to the documents and the rights applied to the children?" > > > I think the easiest solution is to inherit the rights from the parent to > the children, unless an object prevent it. We already have this kind of > mechanism with XWikiRights and XWikiGlobalRights. XWikiRights would be > applied for the current document, and XWikiGlobalRights for the document and > its children. > > > But changing the XWiki model is a lot of work, that we don't have time to > achieve for 7.2. So we propose to make it step by step. > > > The first step is to change the UI to hide the notion of space to the > users. Concretely, each time a user wants to create a page called `A`, we > actually create the document `A.WebHome`. So any child of this page would > be created in the `A` space, like `A.Child`. But this child would be in a > space too, so it would be `A.Child.WebHome` actually.
I find this 'A.WebHome' thing too complex. Look at the document hierarchy tree
http://extensions.xwiki.org/xwiki/bin/view/Extension/Document+Tree+Macro#HDo...
. We can hide the spaces already by relying on the parent / child relationship.
A.WebHome is too complex which is exactly why Guillaume is sending this proposal about Nested Documents. The idea is that the doc will be seen as “A" for the user (and implemented technically as A.WebHome till we update the DB to remove the “space” field, which would make the impl much simpler).
> Then, when we display the `A.WebHome` page, we remove all mentions to the > `WebHome` name. In the UI, it will just be presented as the document `A`. > This is a good point, knowing the fact that the term `WebHome` have no > sense for the user, neither in English or in other languages. > > > Again, these changes are only for the UI. For the applications, it is the > developer's job to decide if the app will create documents like > `Document.WebHome` or basic documents just as before. > > > The question of what to do with AWM comes up. When a user creates an entry, > should it be a new-kind-of-document (`AppSpace.Entry.WebHome`) or an > old-kind-of-document (`AppSpace.Entry`)? The first option is good for > consistency and for the new possibilities it offers, but the second is > better for retro-compatibility. And the question will be the same for all > existing applications that create pages. I believe we should answer these > questions on a case-by-case basis and deserve their own mail threads. > > > This proposal also implies to change some macros, like the {{space}} one, > and some panels. But I believe there is no blocking-point there. > > > Finally, after these steps are accomplished in 7.2 and polished until the > end of the 7.x cycle, we will refactor the XWiki model (something we dream > about for years). > > > To sum up, the idea we propose is: > > > On the short run: > > - Hide the notion of space in the UI. > > - Hide the `WebHome` name in the UI. > > - When a user creates a page from the UI, it actually creates a space with > a WebHome. > > - Remove the current parent/child mechanism which is outdated (and > confusing) compared to the new hierarchy. > > > On the long run: > > - Remove the notion of space in the model, and replace it by "nested > documents". > > - Tune the rights system to inherit rights from parents to children. > > > Of course, we can discuss the technical details and the implementation > strategies. But for now, we need to know if you accept the general idea > (nested documents). > >
> So, I hope you will like this proposal, and here is my +1.
I'm not convinced. I don't see why we should drop the parent/child relationship in order to introduce something similar but more complex.
I’d say mostly because we need to transport the full location in the Doc Reference, which allows us to do lots of things: - display it in the URL - no need to recompute the breadcrumb every time we need to display the hierarchy (which is the case now and it doesn’t scale) - ability in the future to have several references for a single doc - consistency: there’s no reason that the space would be in the reference but not the parent… ATM we have two concurrent concepts which makes it impossible for users to understand the difference between Spaces and child/parent relationships.
Thanks -Vincent
Thanks, Marius
> > > Thanks, > > Guillaume D. > > > > [1] JCR: https://en.wikipedia.org/wiki/Content_repository_API_for_Java > > > > > -- > Guillaume Delhumeau ([email protected])
_______________________________________________ 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 Devs, After discussing with Anca about this she raised an idea which I find interesting and that I’d like to discuss. * We all agree about Nested Spaces so that’s a given. * Now for Nested Document it’s less obvious. Some of us (most) believe that the way forward is to drop the concept of Spaces not only in the UI but also in the DB. However some others (Denis for example) believe that we shouldn’t change the model because it’ll be reused for implementing other features in the future (translations, permissions on xobjects, etc). Some (me included) are expressing doubts that we’ll be able to move to Nested Docs in the model any time soon. * Anca pointed out that Nested Documents in the UI is just a special view of Nested Spaces. A bit similar to the Simple/Advanced user feature or the Show Hidden Documents one. She argues that the concept of spaces, if it exists in the model (which is the case ATM), will surface to the users when they start writing scripts for example. * Said differently she believes that the UI should be in accordance with the model and that it’s a bit utopian to think that users will never see it. But she also acknowledges that it could be interesting for some users or xwiki instances to have a simplified view. * Thus Anca is asking us to think about the possibility to view Nested Documents as an **option** that can be turned on/off (could be implemented as a different skin or possibly better as options of the current skin). * Breadcrumb and menu modifications would still be done since they’re related to Nested Spaces and not Nested Documents, etc. Only the features purely related to Nested Documents would need to be able to be turned on/off (there are also plenty of places where we can find a common UI for both NS and ND). To be honest, I’m not 100% sure how ND would be received by users and it’s possible that it won’t be the best choice in the end and that we wish to change it in the future. I would find it interesting to be able to implement the UI for NS and be able to turn on ND if need be (or the other way around). I’m thus proposing to evaluate how complex it would be to display both a NS UI and a ND UI, based on some config options. Note that it’s possible that by trying to list all places that would be different, in the end, we could come up with very little places and thus there would be only a small/reasonable overhead of keeping the 2 options. I can think of Add > Page (note that Add > Space could be removed IMO and let the user be able to create a Space when adding a page only, which would remove one difference). WDYT? Thanks -Vincent On 11 Jun 2015 at 17:28:11, Eduard Moraru ([email protected](mailto:[email protected])) wrote:
+1, with the same opinion on long URLs.
So we need a way to have a document hierarchy without impacting the URL scheme, unless the admins of the wiki explicitly want to configure it that way. This means, as Caty suggested in an offline discussion, not doing the proposed item: "- Remove the current parent/child mechanism which is outdated (and confusing) compared to the new hierarchy."
We still need the parent/child mechanism, but we could disable it by default and allow admins that create a new wiki or that migrate from a previous XWiki version that does not have ND to preserve their hierarchy and not change their URLs. The direction would obviously be to encourage the creation of Nested Documents, while still keeping the option of having shorter URLs (using parent-child).
Note: If we keep both relationships (space-page and parent-child) the create/move/etc UIs will need to check if the parent-child relationship is enabled and provide a field to set/alter that too.
Thanks, Eduard
On Thu, Jun 11, 2015 at 12:54 PM, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Jun 10, 2015 at 6:36 PM, Ecaterina Moraru (Valica) wrote:
Hi,
Since we discussed so many things lately and there are many technical constrain that we are facing, I'm going to try to get some conclusions from the UI perspective:
First of all there was the discussion about the usability tests. It's true that users are confused that we provide 2 levels of hierarchy (wiki/space/page and parent/child). If we can switch to just one it would be great since it will simplify the user's mental model. Another problem they had was with the naming, since wiki/space/page does not ring any folder/page bell, even with the icon usage. That's why I like the concept of nodes and only one type of entities that can have children. Since we are on the Web, I think the most likely entity name we could use is 'page', similar to content-page, web-page, wiki-page (even if technically is a space or a document).
Having only one type of entity, I agree to the fact that we should remove the space notion. We still have complexity, since we will have main-wiki, wikis*, pages* (child-pages).
I also agree to remove the notion of 'WebHome' from UI. We can still use it technically to differentiate old spaces from pages, but for the user doesn't mean anything, except looking technical.
Regarding the global-menu, we need to remove the wiki>space>page+actions display since it is not scalable. This means that the current breadcrumb zone will display the hierarchy. This is perfectly normal with the current navigation patterns used all over the Web. Note that classical breadcrumb do not display entity-type or actions. We shouldn't either. This means (as stated on http://design.xwiki.org/xwiki/bin/view/Proposal/ExtendedBreadcrumb) that we need to provide a Drawer + Move actions inside the content-menu.
Regarding actions, since we will have just one entity-type (not sure what we do with the wikis) we will need to standardize the entity actions. Currently we provide just 'Delete' for spaces, but if we don't display Spaces differently and they are just nodes, this means that we will need to implement or normalize the available actions. No matter what type it is technically, the user should be able to: Add (child), Edit, Delete, View, Administer, Copy, Rename, Move, Export, Watch, View History, View Informations, View Attachments, View Comments, View Rights, View Objects, etc.
Now, what I really don't like are the long URL. For me this is the most bad decision we can make. Nobody uses long URL on the web. I really like the way our current parent/child works, it provides the hierarchy in the UI, invisible in the URL (keeping it relevant to the current page). Hierarchy anyway should we displayed in Trees, not linear in URLs, since it's hard to read. People like short URL. They are easier to share, easier to scan, easier to understand what the content is about. We have the breadcrumbs for navigation, the URL is for identification.
+1, I don't like long URLs either.
Thanks, Marius
Thanks, Caty
On Mon, Jun 8, 2015 at 11:40 AM, Eduard Moraru
wrote:
Hi,
Going on the "node" architecture, where we have only documents and child documents, here's something interesting that pops up as "the way to go" when storing a tree structure in SQL [1]: Closure Table [2]. It seems to cover pretty much all use cases, as solution 1 (Path Enumeration - what
we
are doing with the "space" document field) is limited [3] when it comes to changes in the tree structure (i.e. renaming/moving a document).
Note: There is also the extension [4] that includes a depth column which would be most useful as well. Basically, getting the list of parents of a document would cost only 1 query, sorting by depth to preserve hierarchy.
Of course, all this requires an extra table in the database for storing the hierarchy relationship.
WDYT?
Thanks, Eduard
---------- [1] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/48 [2] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/68 [3] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/77 [4] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/76
On Sat, Jun 6, 2015 at 3:38 PM, [email protected] wrote:
On 6 Jun 2015 at 14:20:46, [email protected] ([email protected]
(mailto:
[email protected])) wrote:
Hi Marius,
On 4 Jun 2015 at 18:16:03, Marius Dumitru Florea ( [email protected](mailto:[email protected] )) wrote:
> On Wed, Jun 3, 2015 at 5:10 PM, Guillaume "Louis-Marie" Delhumeau > wrote: > > Hello XWiki committers. > > > > > > Vincent have proposed the development of nested spaces for 7.2 and some of > > us have already agreed. But the concept of nested spaces introduces a > > problem that Denis have mentioned during some internal discussions at XWiki > > SAS, and that I am going to report here. > > > > > > From a UI perspective, differentiating pages `A.B.C.WebHome` and `A.B.C` > > could become very difficult. > > > > > > > Moreover, we know that a lot of users do not understand the notion of > > spaces, and they are lost when you look at them during usability sessions. > > I'm not sure about this statement. My feeling is that many users > understand spaces as "folders" (they make the analogy with the file > system). Moreover, whenever we display a space in the XWiki UI we use > the folder icon, so we encourage the users to make this analogy.
I agree with Guillaume here. We’ve seen it on this list but more importantly Caty has done some recorded usability sessions and if I remember correctly it was clearly showing the problem. And users don’t understand that Spaces are like Folders which is why we also had this discussion on the list at one point about renaming them as Folder.
In any case, removing one concept can only be simpler IMO. I find it simpler to have 2 concepts (Wiki, Pages: A wiki is a set of pages) instead of 3 (Wiki, Spaces, Pages: a wiki is a set of spaces, which each one containing pages).
> > The situation is even worse if you consider the notion of parent/child > > documents, which is completely unrelated to the actual hierarchy. It > > creates confusion! > > > > > > > To fix these problems, we propose to introduce the notion of "nested > > documents", i.e. the ability to create documents inside documents. > > What's the difference at a *conceptual* level between the notion of > parent/child we have right now and the notion of nested documents you > propose? I don't see it.
Yes it’s the same thing from a User POV. One difference is that we want a reference to contain the full path of a doc. Right now you’d need to transport the (Doc Reference + the full Breadcrumb) to represent the same thing.
But I agree that it’s the same concept, it’s just a different implementation. That’s why I’m proposing to drop the parent/child fields as we have them now since it’s just duplicating the concepts (and it’s confusing for users), and to reimplement the Breadcrumb UI using Doc References.
Note that having the full location in the reference also allows to have URLs containing the full path which is interesting (for knowing where you are by looking at the URL: http://.../view/Space.Page1, http:// .../view/Space.Page2 doesn’t indicate anything about the relationship between Page1 and Page2 when Page1 could the parent of Page2). It’s also interesting for SEO.
> You even use "parent" and "child" words below > to explain the "nested" notion. The word "nested" sounds very > technical to me. I don't know about French, but in my native language > the translation for "nested" is not a commonly used word, unlike > parent and child. It seems easier to me to explan to a user that a > document can have a parent document and some child documents (the > parent / child relationship) then to explain them that a document can > be "nested" inside another document and can "nest" other documents > too.
I don’t think GL has suggested to use the word Nested anywhere in the UI… It’s just a word we use internally to describe the feature. I’m fine to continue using the terminology Parent and Children.
> > Say differently, if a page `A.B.C` exists, nothing should stop the user to > > create the document `A.B.C.D`. > > You mentioned JCR on the next paragraph. Are JCR nodes identified by > the position (path) in the tree?
Yes. They call it Path (we call it a Document Reference).
> I think we should make a distinction > between the way we identify a document and the way we access that > document.
This means using unique ids for identifying docs (and this is what we already have in the DB except the Id is based on its path in the DB but this could be changed and this is our problem). Of course in the UI we should never display these ids.
> I like the fact that currently when you change the parent of > a document the document identifier (reference) stays the same.
It’s not fully true. When we rename a doc the doc id is modified.
What would be interesting would be the ability to have several Document References for a given doc (with one being the default probably). This is something I’ve been interested in implementing for a long time but it would probably require some model changes and it’s not for XWiki 7.x IMO. We could discuss it when we talk about XWiki 8.x and the new model in general. See also http://design.xwiki.org/xwiki/bin/view/Design/XWikiModel20 (on that page I had put: “Ability to have multiple references pointing to the same entity” and yes this is also supported by the JCR API).
Also note the idea of "An Entity can be a pointer to another Entity (e.g of use case: rename, aliases)” from that doc. This should be not to hard to implement using our current model by adding a Type field in the DB. But it’s a breaking change that would require 8.x (because current apps doing queries on the doc table would get the “pointer” Types which should be excluded, unless we add a filter to search*() APIs + the Query API).
Thanks -Vincent
> > In JCR[1], there is only one concept: the "node". A node can have a > > content, and a list of child nodes. In XWiki, documents could become a kind > > of nodes, and we do not need spaces anymore. > > > > > > If we don't have space anymore, we could ask ourselves: "How the rights > > will be propagated to the children documents? How do we distinguish rights > > applied to the documents and the rights applied to the children?" > > > > > > I think the easiest solution is to inherit the rights from the parent to > > the children, unless an object prevent it. We already have this kind of > > mechanism with XWikiRights and XWikiGlobalRights. XWikiRights would be > > applied for the current document, and XWikiGlobalRights for the document and > > its children. > > > > > > But changing the XWiki model is a lot of work, that we don't have time to > > achieve for 7.2. So we propose to make it step by step. > > > > > > The first step is to change the UI to hide the notion of space to the > > users. Concretely, each time a user wants to create a page called `A`, we > > actually create the document `A.WebHome`. So any child of this page would > > be created in the `A` space, like `A.Child`. But this child would be in a > > space too, so it would be `A.Child.WebHome` actually. > > I find this 'A.WebHome' thing too complex. Look at the document > hierarchy tree
http://extensions.xwiki.org/xwiki/bin/view/Extension/Document+Tree+Macro#HDo...
> . We can hide the spaces already by relying on the parent / child > relationship.
A.WebHome is too complex which is exactly why Guillaume is sending this proposal about Nested Documents. The idea is that the doc will be seen as “A" for the user (and implemented technically as A.WebHome till we update the DB to remove the “space” field, which would make the impl much simpler).
> > Then, when we display the `A.WebHome` page, we remove all mentions to the > > `WebHome` name. In the UI, it will just be presented as the document `A`. > > This is a good point, knowing the fact that the term `WebHome` have no > > sense for the user, neither in English or in other languages. > > > > > > Again, these changes are only for the UI. For the applications, it is the > > developer's job to decide if the app will create documents like > > `Document.WebHome` or basic documents just as before. > > > > > > The question of what to do with AWM comes up. When a user creates an entry, > > should it be a new-kind-of-document (`AppSpace.Entry.WebHome`) or an > > old-kind-of-document (`AppSpace.Entry`)? The first option is good for > > consistency and for the new possibilities it offers, but the second is > > better for retro-compatibility. And the question will be the same for all > > existing applications that create pages. I believe we should answer these > > questions on a case-by-case basis and deserve their own mail threads. > > > > > > This proposal also implies to change some macros, like the {{space}} one, > > and some panels. But I believe there is no blocking-point there. > > > > > > Finally, after these steps are accomplished in 7.2 and polished until the > > end of the 7.x cycle, we will refactor the XWiki model (something we dream > > about for years). > > > > > > To sum up, the idea we propose is: > > > > > > On the short run: > > > > - Hide the notion of space in the UI. > > > > - Hide the `WebHome` name in the UI. > > > > - When a user creates a page from the UI, it actually creates a space with > > a WebHome. > > > > - Remove the current parent/child mechanism which is outdated (and > > confusing) compared to the new hierarchy. > > > > > > On the long run: > > > > - Remove the notion of space in the model, and replace it by "nested > > documents". > > > > - Tune the rights system to inherit rights from parents to children. > > > > > > Of course, we can discuss the technical details and the implementation > > strategies. But for now, we need to know if you accept the general idea > > (nested documents). > > > > > > > So, I hope you will like this proposal, and here is my +1. > > I'm not convinced. I don't see why we should drop the parent/child > relationship in order to introduce something similar but more complex.
I’d say mostly because we need to transport the full location in the Doc Reference, which allows us to do lots of things: - display it in the URL - no need to recompute the breadcrumb every time we need to display the hierarchy (which is the case now and it doesn’t scale) - ability in the future to have several references for a single doc - consistency: there’s no reason that the space would be in the reference but not the parent… ATM we have two concurrent concepts which makes it impossible for users to understand the difference between Spaces and child/parent relationships.
Thanks -Vincent
> Thanks, > Marius > > > > > > > Thanks, > > > > Guillaume D. > > > > > > > > [1] JCR: https://en.wikipedia.org/wiki/Content_repository_API_for_Java > > > > > > > > > > -- > > Guillaume Delhumeau ([email protected])
_______________________________________________ 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
On Fri, Jun 12, 2015 at 6:22 PM, [email protected] <[email protected]> wrote:
Hi Devs,
After discussing with Anca about this she raised an idea which I find interesting and that I’d like to discuss.
* We all agree about Nested Spaces so that’s a given. * Now for Nested Document it’s less obvious. Some of us (most) believe that the way forward is to drop the concept of Spaces not only in the UI but also in the DB. However some others (Denis for example) believe that we shouldn’t change the model because it’ll be reused for implementing other features in the future (translations, permissions on xobjects, etc). Some (me included) are expressing doubts that we’ll be able to move to Nested Docs in the model any time soon. * Anca pointed out that Nested Documents in the UI is just a special view of Nested Spaces. A bit similar to the Simple/Advanced user feature or the Show Hidden Documents one. She argues that the concept of spaces, if it exists in the model (which is the case ATM), will surface to the users when they start writing scripts for example. * Said differently she believes that the UI should be in accordance with the model and that it’s a bit utopian to think that users will never see it. But she also acknowledges that it could be interesting for some users or xwiki instances to have a simplified view. * Thus Anca is asking us to think about the possibility to view Nested Documents as an **option** that can be turned on/off (could be implemented as a different skin or possibly better as options of the current skin). * Breadcrumb and menu modifications would still be done since they’re related to Nested Spaces and not Nested Documents, etc. Only the features purely related to Nested Documents would need to be able to be turned on/off (there are also plenty of places where we can find a common UI for both NS and ND).
To be honest, I’m not 100% sure how ND would be received by users and it’s possible that it won’t be the best choice in the end and that we wish to change it in the future. I would find it interesting to be able to implement the UI for NS and be able to turn on ND if need be (or the other way around).
I’m thus proposing to evaluate how complex it would be to display both a NS UI and a ND UI, based on some config options.
Note that it’s possible that by trying to list all places that would be different, in the end, we could come up with very little places and thus there would be only a small/reasonable overhead of keeping the 2 options.
I can think of Add > Page (note that Add > Space could be removed IMO and let the user be able to create a Space when adding a page only, which would remove one difference).
WDYT?
+1, I'm currently working on http://jira.xwiki.org/browse/XWIKI-12173 and I've added a parameter "showSpaceAsDocument" to the document tree. Thanks, Marius
Thanks -Vincent
On 11 Jun 2015 at 17:28:11, Eduard Moraru ([email protected](mailto:[email protected])) wrote:
+1, with the same opinion on long URLs.
So we need a way to have a document hierarchy without impacting the URL scheme, unless the admins of the wiki explicitly want to configure it that way. This means, as Caty suggested in an offline discussion, not doing the proposed item: "- Remove the current parent/child mechanism which is outdated (and confusing) compared to the new hierarchy."
We still need the parent/child mechanism, but we could disable it by default and allow admins that create a new wiki or that migrate from a previous XWiki version that does not have ND to preserve their hierarchy and not change their URLs. The direction would obviously be to encourage the creation of Nested Documents, while still keeping the option of having shorter URLs (using parent-child).
Note: If we keep both relationships (space-page and parent-child) the create/move/etc UIs will need to check if the parent-child relationship is enabled and provide a field to set/alter that too.
Thanks, Eduard
On Thu, Jun 11, 2015 at 12:54 PM, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Jun 10, 2015 at 6:36 PM, Ecaterina Moraru (Valica) wrote:
Hi,
Since we discussed so many things lately and there are many technical constrain that we are facing, I'm going to try to get some conclusions from the UI perspective:
First of all there was the discussion about the usability tests. It's true that users are confused that we provide 2 levels of hierarchy (wiki/space/page and parent/child). If we can switch to just one it would be great since it will simplify the user's mental model. Another problem they had was with the naming, since wiki/space/page does not ring any folder/page bell, even with the icon usage. That's why I like the concept of nodes and only one type of entities that can have children. Since we are on the Web, I think the most likely entity name we could use is 'page', similar to content-page, web-page, wiki-page (even if technically is a space or a document).
Having only one type of entity, I agree to the fact that we should remove the space notion. We still have complexity, since we will have main-wiki, wikis*, pages* (child-pages).
I also agree to remove the notion of 'WebHome' from UI. We can still use it technically to differentiate old spaces from pages, but for the user doesn't mean anything, except looking technical.
Regarding the global-menu, we need to remove the wiki>space>page+actions display since it is not scalable. This means that the current breadcrumb zone will display the hierarchy. This is perfectly normal with the current navigation patterns used all over the Web. Note that classical breadcrumb do not display entity-type or actions. We shouldn't either. This means (as stated on http://design.xwiki.org/xwiki/bin/view/Proposal/ExtendedBreadcrumb) that we need to provide a Drawer + Move actions inside the content-menu.
Regarding actions, since we will have just one entity-type (not sure what we do with the wikis) we will need to standardize the entity actions. Currently we provide just 'Delete' for spaces, but if we don't display Spaces differently and they are just nodes, this means that we will need to implement or normalize the available actions. No matter what type it is technically, the user should be able to: Add (child), Edit, Delete, View, Administer, Copy, Rename, Move, Export, Watch, View History, View Informations, View Attachments, View Comments, View Rights, View Objects, etc.
Now, what I really don't like are the long URL. For me this is the most bad decision we can make. Nobody uses long URL on the web. I really like the way our current parent/child works, it provides the hierarchy in the UI, invisible in the URL (keeping it relevant to the current page). Hierarchy anyway should we displayed in Trees, not linear in URLs, since it's hard to read. People like short URL. They are easier to share, easier to scan, easier to understand what the content is about. We have the breadcrumbs for navigation, the URL is for identification.
+1, I don't like long URLs either.
Thanks, Marius
Thanks, Caty
On Mon, Jun 8, 2015 at 11:40 AM, Eduard Moraru
wrote:
Hi,
Going on the "node" architecture, where we have only documents and child documents, here's something interesting that pops up as "the way to go" when storing a tree structure in SQL [1]: Closure Table [2]. It seems to cover pretty much all use cases, as solution 1 (Path Enumeration - what
we
are doing with the "space" document field) is limited [3] when it comes to changes in the tree structure (i.e. renaming/moving a document).
Note: There is also the extension [4] that includes a depth column which would be most useful as well. Basically, getting the list of parents of a document would cost only 1 query, sorting by depth to preserve hierarchy.
Of course, all this requires an extra table in the database for storing the hierarchy relationship.
WDYT?
Thanks, Eduard
---------- [1] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/48 [2] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/68 [3] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/77 [4] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/76
On Sat, Jun 6, 2015 at 3:38 PM, [email protected] wrote:
On 6 Jun 2015 at 14:20:46, [email protected] ([email protected]
(mailto:
[email protected])) wrote:
> Hi Marius, > > On 4 Jun 2015 at 18:16:03, Marius Dumitru Florea ( [email protected](mailto:[email protected] )) wrote: > > > On Wed, Jun 3, 2015 at 5:10 PM, Guillaume "Louis-Marie" Delhumeau > > wrote: > > > Hello XWiki committers. > > > > > > > > > Vincent have proposed the development of nested spaces for 7.2 and some of > > > us have already agreed. But the concept of nested spaces introduces a > > > problem that Denis have mentioned during some internal discussions at XWiki > > > SAS, and that I am going to report here. > > > > > > > > > From a UI perspective, differentiating pages `A.B.C.WebHome` and `A.B.C` > > > could become very difficult. > > > > > > > > > > > Moreover, we know that a lot of users do not understand the notion of > > > spaces, and they are lost when you look at them during usability sessions. > > > > I'm not sure about this statement. My feeling is that many users > > understand spaces as "folders" (they make the analogy with the file > > system). Moreover, whenever we display a space in the XWiki UI we use > > the folder icon, so we encourage the users to make this analogy. > > I agree with Guillaume here. We’ve seen it on this list but more importantly Caty has done some recorded usability sessions and if I remember correctly it was clearly showing the problem. And users don’t understand that Spaces are like Folders which is why we also had this discussion on the list at one point about renaming them as Folder. > > In any case, removing one concept can only be simpler IMO. I find it simpler to have 2 concepts (Wiki, Pages: A wiki is a set of pages) instead of 3 (Wiki, Spaces, Pages: a wiki is a set of spaces, which each one containing pages). > > > > The situation is even worse if you consider the notion of parent/child > > > documents, which is completely unrelated to the actual hierarchy. It > > > creates confusion! > > > > > > > > > > > To fix these problems, we propose to introduce the notion of "nested > > > documents", i.e. the ability to create documents inside documents. > > > > What's the difference at a *conceptual* level between the notion of > > parent/child we have right now and the notion of nested documents you > > propose? I don't see it. > > Yes it’s the same thing from a User POV. One difference is that we want a reference to contain the full path of a doc. Right now you’d need to transport the (Doc Reference + the full Breadcrumb) to represent the same thing. > > But I agree that it’s the same concept, it’s just a different implementation. That’s why I’m proposing to drop the parent/child fields as we have them now since it’s just duplicating the concepts (and it’s confusing for users), and to reimplement the Breadcrumb UI using Doc References. > > Note that having the full location in the reference also allows to have URLs containing the full path which is interesting (for knowing where you are by looking at the URL: http://.../view/Space.Page1, http:// .../view/Space.Page2 doesn’t indicate anything about the relationship between Page1 and Page2 when Page1 could the parent of Page2). It’s also interesting for SEO. > > > You even use "parent" and "child" words below > > to explain the "nested" notion. The word "nested" sounds very > > technical to me. I don't know about French, but in my native language > > the translation for "nested" is not a commonly used word, unlike > > parent and child. It seems easier to me to explan to a user that a > > document can have a parent document and some child documents (the > > parent / child relationship) then to explain them that a document can > > be "nested" inside another document and can "nest" other documents > > too. > > I don’t think GL has suggested to use the word Nested anywhere in the UI… It’s just a word we use internally to describe the feature. I’m fine to continue using the terminology Parent and Children. > > > > Say differently, if a page `A.B.C` exists, nothing should stop the user to > > > create the document `A.B.C.D`. > > > > You mentioned JCR on the next paragraph. Are JCR nodes identified by > > the position (path) in the tree? > > Yes. They call it Path (we call it a Document Reference). > > > I think we should make a distinction > > between the way we identify a document and the way we access that > > document. > > This means using unique ids for identifying docs (and this is what we already have in the DB except the Id is based on its path in the DB but this could be changed and this is our problem). Of course in the UI we should never display these ids. > > > I like the fact that currently when you change the parent of > > a document the document identifier (reference) stays the same. > > It’s not fully true. When we rename a doc the doc id is modified. > > What would be interesting would be the ability to have several Document References for a given doc (with one being the default probably). This is something I’ve been interested in implementing for a long time but it would probably require some model changes and it’s not for XWiki 7.x IMO. We could discuss it when we talk about XWiki 8.x and the new model in general. See also http://design.xwiki.org/xwiki/bin/view/Design/XWikiModel20 (on that page I had put: “Ability to have multiple references pointing to the same entity” and yes this is also supported by the JCR API).
Also note the idea of "An Entity can be a pointer to another Entity (e.g of use case: rename, aliases)” from that doc. This should be not to hard to implement using our current model by adding a Type field in the DB. But it’s a breaking change that would require 8.x (because current apps doing queries on the doc table would get the “pointer” Types which should be excluded, unless we add a filter to search*() APIs + the Query API).
Thanks -Vincent
> > > In JCR[1], there is only one concept: the "node". A node can have a > > > content, and a list of child nodes. In XWiki, documents could become a kind > > > of nodes, and we do not need spaces anymore. > > > > > > > > > If we don't have space anymore, we could ask ourselves: "How the rights > > > will be propagated to the children documents? How do we distinguish rights > > > applied to the documents and the rights applied to the children?" > > > > > > > > > I think the easiest solution is to inherit the rights from the parent to > > > the children, unless an object prevent it. We already have this kind of > > > mechanism with XWikiRights and XWikiGlobalRights. XWikiRights would be > > > applied for the current document, and XWikiGlobalRights for the document and > > > its children. > > > > > > > > > But changing the XWiki model is a lot of work, that we don't have time to > > > achieve for 7.2. So we propose to make it step by step. > > > > > > > > > The first step is to change the UI to hide the notion of space to the > > > users. Concretely, each time a user wants to create a page called `A`, we > > > actually create the document `A.WebHome`. So any child of this page would > > > be created in the `A` space, like `A.Child`. But this child would be in a > > > space too, so it would be `A.Child.WebHome` actually. > > > > I find this 'A.WebHome' thing too complex. Look at the document > > hierarchy tree
http://extensions.xwiki.org/xwiki/bin/view/Extension/Document+Tree+Macro#HDo...
> > . We can hide the spaces already by relying on the parent / child > > relationship. > > A.WebHome is too complex which is exactly why Guillaume is sending this proposal about Nested Documents. The idea is that the doc will be seen as “A" for the user (and implemented technically as A.WebHome till we update the DB to remove the “space” field, which would make the impl much simpler). > > > > Then, when we display the `A.WebHome` page, we remove all mentions to the > > > `WebHome` name. In the UI, it will just be presented as the document `A`. > > > This is a good point, knowing the fact that the term `WebHome` have no > > > sense for the user, neither in English or in other languages. > > > > > > > > > Again, these changes are only for the UI. For the applications, it is the > > > developer's job to decide if the app will create documents like > > > `Document.WebHome` or basic documents just as before. > > > > > > > > > The question of what to do with AWM comes up. When a user creates an entry, > > > should it be a new-kind-of-document (`AppSpace.Entry.WebHome`) or an > > > old-kind-of-document (`AppSpace.Entry`)? The first option is good for > > > consistency and for the new possibilities it offers, but the second is > > > better for retro-compatibility. And the question will be the same for all > > > existing applications that create pages. I believe we should answer these > > > questions on a case-by-case basis and deserve their own mail threads. > > > > > > > > > This proposal also implies to change some macros, like the {{space}} one, > > > and some panels. But I believe there is no blocking-point there. > > > > > > > > > Finally, after these steps are accomplished in 7.2 and polished until the > > > end of the 7.x cycle, we will refactor the XWiki model (something we dream > > > about for years). > > > > > > > > > To sum up, the idea we propose is: > > > > > > > > > On the short run: > > > > > > - Hide the notion of space in the UI. > > > > > > - Hide the `WebHome` name in the UI. > > > > > > - When a user creates a page from the UI, it actually creates a space with > > > a WebHome. > > > > > > - Remove the current parent/child mechanism which is outdated (and > > > confusing) compared to the new hierarchy. > > > > > > > > > On the long run: > > > > > > - Remove the notion of space in the model, and replace it by "nested > > > documents". > > > > > > - Tune the rights system to inherit rights from parents to children. > > > > > > > > > Of course, we can discuss the technical details and the implementation > > > strategies. But for now, we need to know if you accept the general idea > > > (nested documents). > > > > > > > > > > > So, I hope you will like this proposal, and here is my +1. > > > > I'm not convinced. I don't see why we should drop the parent/child > > relationship in order to introduce something similar but more complex. > > I’d say mostly because we need to transport the full location in the Doc Reference, which allows us to do lots of things: > - display it in the URL > - no need to recompute the breadcrumb every time we need to display the hierarchy (which is the case now and it doesn’t scale) > - ability in the future to have several references for a single doc > - consistency: there’s no reason that the space would be in the reference but not the parent… ATM we have two concurrent concepts which makes it impossible for users to understand the difference between Spaces and child/parent relationships. > > Thanks > -Vincent > > > Thanks, > > Marius > > > > > > > > > > > Thanks, > > > > > > Guillaume D. > > > > > > > > > > > > [1] JCR: https://en.wikipedia.org/wiki/Content_repository_API_for_Java > > > > > > > > > > > > > > > -- > > > Guillaume Delhumeau ([email protected]) >
_______________________________________________ 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
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
+1 On Fri, Jun 12, 2015 at 5:22 PM, [email protected] <[email protected]> wrote:
Hi Devs,
After discussing with Anca about this she raised an idea which I find interesting and that I’d like to discuss.
* We all agree about Nested Spaces so that’s a given. * Now for Nested Document it’s less obvious. Some of us (most) believe that the way forward is to drop the concept of Spaces not only in the UI but also in the DB. However some others (Denis for example) believe that we shouldn’t change the model because it’ll be reused for implementing other features in the future (translations, permissions on xobjects, etc). Some (me included) are expressing doubts that we’ll be able to move to Nested Docs in the model any time soon. * Anca pointed out that Nested Documents in the UI is just a special view of Nested Spaces. A bit similar to the Simple/Advanced user feature or the Show Hidden Documents one. She argues that the concept of spaces, if it exists in the model (which is the case ATM), will surface to the users when they start writing scripts for example. * Said differently she believes that the UI should be in accordance with the model and that it’s a bit utopian to think that users will never see it. But she also acknowledges that it could be interesting for some users or xwiki instances to have a simplified view. * Thus Anca is asking us to think about the possibility to view Nested Documents as an **option** that can be turned on/off (could be implemented as a different skin or possibly better as options of the current skin). * Breadcrumb and menu modifications would still be done since they’re related to Nested Spaces and not Nested Documents, etc. Only the features purely related to Nested Documents would need to be able to be turned on/off (there are also plenty of places where we can find a common UI for both NS and ND).
To be honest, I’m not 100% sure how ND would be received by users and it’s possible that it won’t be the best choice in the end and that we wish to change it in the future. I would find it interesting to be able to implement the UI for NS and be able to turn on ND if need be (or the other way around).
I’m thus proposing to evaluate how complex it would be to display both a NS UI and a ND UI, based on some config options.
Note that it’s possible that by trying to list all places that would be different, in the end, we could come up with very little places and thus there would be only a small/reasonable overhead of keeping the 2 options.
I can think of Add > Page (note that Add > Space could be removed IMO and let the user be able to create a Space when adding a page only, which would remove one difference).
WDYT?
Thanks -Vincent
On 11 Jun 2015 at 17:28:11, Eduard Moraru ([email protected](mailto:[email protected])) wrote:
+1, with the same opinion on long URLs.
So we need a way to have a document hierarchy without impacting the URL scheme, unless the admins of the wiki explicitly want to configure it that way. This means, as Caty suggested in an offline discussion, not doing the proposed item: "- Remove the current parent/child mechanism which is outdated (and confusing) compared to the new hierarchy."
We still need the parent/child mechanism, but we could disable it by default and allow admins that create a new wiki or that migrate from a previous XWiki version that does not have ND to preserve their hierarchy and not change their URLs. The direction would obviously be to encourage the creation of Nested Documents, while still keeping the option of having shorter URLs (using parent-child).
Note: If we keep both relationships (space-page and parent-child) the create/move/etc UIs will need to check if the parent-child relationship is enabled and provide a field to set/alter that too.
Thanks, Eduard
On Thu, Jun 11, 2015 at 12:54 PM, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Jun 10, 2015 at 6:36 PM, Ecaterina Moraru (Valica) wrote:
Hi,
Since we discussed so many things lately and there are many technical constrain that we are facing, I'm going to try to get some conclusions from the UI perspective:
First of all there was the discussion about the usability tests. It's true that users are confused that we provide 2 levels of hierarchy (wiki/space/page and parent/child). If we can switch to just one it would be great since it will simplify the user's mental model. Another problem they had was with the naming, since wiki/space/page does not ring any folder/page bell, even with the icon usage. That's why I like the concept of nodes and only one type of entities that can have children. Since we are on the Web, I think the most likely entity name we could use is 'page', similar to content-page, web-page, wiki-page (even if technically is a space or a document).
Having only one type of entity, I agree to the fact that we should remove the space notion. We still have complexity, since we will have main-wiki, wikis*, pages* (child-pages).
I also agree to remove the notion of 'WebHome' from UI. We can still use it technically to differentiate old spaces from pages, but for the user doesn't mean anything, except looking technical.
Regarding the global-menu, we need to remove the wiki>space>page+actions display since it is not scalable. This means that the current breadcrumb zone will display the hierarchy. This is perfectly normal with the current navigation patterns used all over the Web. Note that classical breadcrumb do not display entity-type or actions. We shouldn't either. This means (as stated on http://design.xwiki.org/xwiki/bin/view/Proposal/ExtendedBreadcrumb) that we need to provide a Drawer + Move actions inside the content-menu.
Regarding actions, since we will have just one entity-type (not sure what we do with the wikis) we will need to standardize the entity actions. Currently we provide just 'Delete' for spaces, but if we don't display Spaces differently and they are just nodes, this means that we will need to implement or normalize the available actions. No matter what type it is technically, the user should be able to: Add (child), Edit, Delete, View, Administer, Copy, Rename, Move, Export, Watch, View History, View Informations, View Attachments, View Comments, View Rights, View Objects, etc.
Now, what I really don't like are the long URL. For me this is the most bad decision we can make. Nobody uses long URL on the web. I really like the way our current parent/child works, it provides the hierarchy in the UI, invisible in the URL (keeping it relevant to the current page). Hierarchy anyway should we displayed in Trees, not linear in URLs, since it's hard to read. People like short URL. They are easier to share, easier to scan, easier to understand what the content is about. We have the breadcrumbs for navigation, the URL is for identification.
+1, I don't like long URLs either.
Thanks, Marius
Thanks, Caty
On Mon, Jun 8, 2015 at 11:40 AM, Eduard Moraru
wrote:
Hi,
Going on the "node" architecture, where we have only documents and child documents, here's something interesting that pops up as "the way to go" when storing a tree structure in SQL [1]: Closure Table [2]. It seems to cover pretty much all use cases, as solution 1 (Path Enumeration - what
we
are doing with the "space" document field) is limited [3] when it comes to changes in the tree structure (i.e. renaming/moving a document).
Note: There is also the extension [4] that includes a depth column which would be most useful as well. Basically, getting the list of parents of a document would cost only 1 query, sorting by depth to preserve hierarchy.
Of course, all this requires an extra table in the database for storing the hierarchy relationship.
WDYT?
Thanks, Eduard
---------- [1] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/48 [2] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/68 [3] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/77 [4] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/76
On Sat, Jun 6, 2015 at 3:38 PM, [email protected] wrote:
On 6 Jun 2015 at 14:20:46, [email protected] ([email protected]
(mailto:
[email protected])) wrote:
> Hi Marius, > > On 4 Jun 2015 at 18:16:03, Marius Dumitru Florea ( [email protected](mailto:[email protected] )) wrote: > > > On Wed, Jun 3, 2015 at 5:10 PM, Guillaume "Louis-Marie" Delhumeau > > wrote: > > > Hello XWiki committers. > > > > > > > > > Vincent have proposed the development of nested spaces for 7.2 and some of > > > us have already agreed. But the concept of nested spaces introduces a > > > problem that Denis have mentioned during some internal discussions at XWiki > > > SAS, and that I am going to report here. > > > > > > > > > From a UI perspective, differentiating pages `A.B.C.WebHome` and `A.B.C` > > > could become very difficult. > > > > > > > > > > > Moreover, we know that a lot of users do not understand the notion of > > > spaces, and they are lost when you look at them during usability sessions. > > > > I'm not sure about this statement. My feeling is that many users > > understand spaces as "folders" (they make the analogy with the file > > system). Moreover, whenever we display a space in the XWiki UI we use > > the folder icon, so we encourage the users to make this analogy. > > I agree with Guillaume here. We’ve seen it on this list but more importantly Caty has done some recorded usability sessions and if I remember correctly it was clearly showing the problem. And users don’t understand that Spaces are like Folders which is why we also had this discussion on the list at one point about renaming them as Folder. > > In any case, removing one concept can only be simpler IMO. I find it simpler to have 2 concepts (Wiki, Pages: A wiki is a set of pages) instead of 3 (Wiki, Spaces, Pages: a wiki is a set of spaces, which each one containing pages). > > > > The situation is even worse if you consider the notion of parent/child > > > documents, which is completely unrelated to the actual hierarchy. It > > > creates confusion! > > > > > > > > > > > To fix these problems, we propose to introduce the notion of "nested > > > documents", i.e. the ability to create documents inside documents. > > > > What's the difference at a *conceptual* level between the notion of > > parent/child we have right now and the notion of nested documents you > > propose? I don't see it. > > Yes it’s the same thing from a User POV. One difference is that we want a reference to contain the full path of a doc. Right now you’d need to transport the (Doc Reference + the full Breadcrumb) to represent the same thing. > > But I agree that it’s the same concept, it’s just a different implementation. That’s why I’m proposing to drop the parent/child fields as we have them now since it’s just duplicating the concepts (and it’s confusing for users), and to reimplement the Breadcrumb UI using Doc References. > > Note that having the full location in the reference also allows to have URLs containing the full path which is interesting (for knowing where you are by looking at the URL: http://.../view/Space.Page1, http:// .../view/Space.Page2 doesn’t indicate anything about the relationship between Page1 and Page2 when Page1 could the parent of Page2). It’s also interesting for SEO. > > > You even use "parent" and "child" words below > > to explain the "nested" notion. The word "nested" sounds very > > technical to me. I don't know about French, but in my native language > > the translation for "nested" is not a commonly used word, unlike > > parent and child. It seems easier to me to explan to a user that a > > document can have a parent document and some child documents (the > > parent / child relationship) then to explain them that a document can > > be "nested" inside another document and can "nest" other documents > > too. > > I don’t think GL has suggested to use the word Nested anywhere in the UI… It’s just a word we use internally to describe the feature. I’m fine to continue using the terminology Parent and Children. > > > > Say differently, if a page `A.B.C` exists, nothing should stop the user to > > > create the document `A.B.C.D`. > > > > You mentioned JCR on the next paragraph. Are JCR nodes identified by > > the position (path) in the tree? > > Yes. They call it Path (we call it a Document Reference). > > > I think we should make a distinction > > between the way we identify a document and the way we access that > > document. > > This means using unique ids for identifying docs (and this is what we already have in the DB except the Id is based on its path in the DB but this could be changed and this is our problem). Of course in the UI we should never display these ids. > > > I like the fact that currently when you change the parent of > > a document the document identifier (reference) stays the same. > > It’s not fully true. When we rename a doc the doc id is modified. > > What would be interesting would be the ability to have several Document References for a given doc (with one being the default probably). This is something I’ve been interested in implementing for a long time but it would probably require some model changes and it’s not for XWiki 7.x IMO. We could discuss it when we talk about XWiki 8.x and the new model in general. See also http://design.xwiki.org/xwiki/bin/view/Design/XWikiModel20 (on that page I had put: “Ability to have multiple references pointing to the same entity” and yes this is also supported by the JCR API).
Also note the idea of "An Entity can be a pointer to another Entity (e.g of use case: rename, aliases)” from that doc. This should be not to hard to implement using our current model by adding a Type field in the DB. But it’s a breaking change that would require 8.x (because current apps doing queries on the doc table would get the “pointer” Types which should be excluded, unless we add a filter to search*() APIs + the Query API).
Thanks -Vincent
> > > In JCR[1], there is only one concept: the "node". A node can have a > > > content, and a list of child nodes. In XWiki, documents could become a kind > > > of nodes, and we do not need spaces anymore. > > > > > > > > > If we don't have space anymore, we could ask ourselves: "How the rights > > > will be propagated to the children documents? How do we distinguish rights > > > applied to the documents and the rights applied to the children?" > > > > > > > > > I think the easiest solution is to inherit the rights from the parent to > > > the children, unless an object prevent it. We already have this kind of > > > mechanism with XWikiRights and XWikiGlobalRights. XWikiRights would be > > > applied for the current document, and XWikiGlobalRights for the document and > > > its children. > > > > > > > > > But changing the XWiki model is a lot of work, that we don't have time to > > > achieve for 7.2. So we propose to make it step by step. > > > > > > > > > The first step is to change the UI to hide the notion of space to the > > > users. Concretely, each time a user wants to create a page called `A`, we > > > actually create the document `A.WebHome`. So any child of this page would > > > be created in the `A` space, like `A.Child`. But this child would be in a > > > space too, so it would be `A.Child.WebHome` actually. > > > > I find this 'A.WebHome' thing too complex. Look at the document > > hierarchy tree
http://extensions.xwiki.org/xwiki/bin/view/Extension/Document+Tree+Macro#HDo...
> > . We can hide the spaces already by relying on the parent / child > > relationship. > > A.WebHome is too complex which is exactly why Guillaume is sending this proposal about Nested Documents. The idea is that the doc will be seen as “A" for the user (and implemented technically as A.WebHome till we update the DB to remove the “space” field, which would make the impl much simpler). > > > > Then, when we display the `A.WebHome` page, we remove all mentions to the > > > `WebHome` name. In the UI, it will just be presented as the document `A`. > > > This is a good point, knowing the fact that the term `WebHome` have no > > > sense for the user, neither in English or in other languages. > > > > > > > > > Again, these changes are only for the UI. For the applications, it is the > > > developer's job to decide if the app will create documents like > > > `Document.WebHome` or basic documents just as before. > > > > > > > > > The question of what to do with AWM comes up. When a user creates an entry, > > > should it be a new-kind-of-document (`AppSpace.Entry.WebHome`) or an > > > old-kind-of-document (`AppSpace.Entry`)? The first option is good for > > > consistency and for the new possibilities it offers, but the second is > > > better for retro-compatibility. And the question will be the same for all > > > existing applications that create pages. I believe we should answer these > > > questions on a case-by-case basis and deserve their own mail threads. > > > > > > > > > This proposal also implies to change some macros, like the {{space}} one, > > > and some panels. But I believe there is no blocking-point there. > > > > > > > > > Finally, after these steps are accomplished in 7.2 and polished until the > > > end of the 7.x cycle, we will refactor the XWiki model (something we dream > > > about for years). > > > > > > > > > To sum up, the idea we propose is: > > > > > > > > > On the short run: > > > > > > - Hide the notion of space in the UI. > > > > > > - Hide the `WebHome` name in the UI. > > > > > > - When a user creates a page from the UI, it actually creates a space with > > > a WebHome. > > > > > > - Remove the current parent/child mechanism which is outdated (and > > > confusing) compared to the new hierarchy. > > > > > > > > > On the long run: > > > > > > - Remove the notion of space in the model, and replace it by "nested > > > documents". > > > > > > - Tune the rights system to inherit rights from parents to children. > > > > > > > > > Of course, we can discuss the technical details and the implementation > > > strategies. But for now, we need to know if you accept the general idea > > > (nested documents). > > > > > > > > > > > So, I hope you will like this proposal, and here is my +1. > > > > I'm not convinced. I don't see why we should drop the parent/child > > relationship in order to introduce something similar but more complex. > > I’d say mostly because we need to transport the full location in the Doc Reference, which allows us to do lots of things: > - display it in the URL > - no need to recompute the breadcrumb every time we need to display the hierarchy (which is the case now and it doesn’t scale) > - ability in the future to have several references for a single doc > - consistency: there’s no reason that the space would be in the reference but not the parent… ATM we have two concurrent concepts which makes it impossible for users to understand the difference between Spaces and child/parent relationships. > > Thanks > -Vincent > > > Thanks, > > Marius > > > > > > > > > > > Thanks, > > > > > > Guillaume D. > > > > > > > > > > > > [1] JCR: https://en.wikipedia.org/wiki/Content_repository_API_for_Java > > > > > > > > > > > > > > > -- > > > Guillaume Delhumeau ([email protected]) >
_______________________________________________ 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
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
I've created a design page: http://design.xwiki.org/xwiki/bin/view/Proposal/NestedDocuments For the cost of having Nested Documents as an option in the UI, I see the following points: - 2 versions of the top level menu. - 2 versions of the create page form. - 2 versions of the create page panel. - What about the *spaces* macro? 2 different behaviors? If not, should the space macro be used in the default Dashboard? Some questions: - What do we do with the most edited spaces panel? - What do we do with the space documents panel (display all documents of the current space)? 2015-06-15 10:59 GMT+02:00 Thomas Mortagne <[email protected]>:
+1
On Fri, Jun 12, 2015 at 5:22 PM, [email protected] <[email protected]> wrote:
Hi Devs,
After discussing with Anca about this she raised an idea which I find interesting and that I’d like to discuss.
* We all agree about Nested Spaces so that’s a given. * Now for Nested Document it’s less obvious. Some of us (most) believe that the way forward is to drop the concept of Spaces not only in the UI but also in the DB. However some others (Denis for example) believe that we shouldn’t change the model because it’ll be reused for implementing other features in the future (translations, permissions on xobjects, etc). Some (me included) are expressing doubts that we’ll be able to move to Nested Docs in the model any time soon. * Anca pointed out that Nested Documents in the UI is just a special view of Nested Spaces. A bit similar to the Simple/Advanced user feature or the Show Hidden Documents one. She argues that the concept of spaces, if it exists in the model (which is the case ATM), will surface to the users when they start writing scripts for example. * Said differently she believes that the UI should be in accordance with the model and that it’s a bit utopian to think that users will never see it. But she also acknowledges that it could be interesting for some users or xwiki instances to have a simplified view. * Thus Anca is asking us to think about the possibility to view Nested Documents as an **option** that can be turned on/off (could be implemented as a different skin or possibly better as options of the current skin). * Breadcrumb and menu modifications would still be done since they’re related to Nested Spaces and not Nested Documents, etc. Only the features purely related to Nested Documents would need to be able to be turned on/off (there are also plenty of places where we can find a common UI for both NS and ND).
To be honest, I’m not 100% sure how ND would be received by users and it’s possible that it won’t be the best choice in the end and that we wish to change it in the future. I would find it interesting to be able to implement the UI for NS and be able to turn on ND if need be (or the other way around).
I’m thus proposing to evaluate how complex it would be to display both a NS UI and a ND UI, based on some config options.
Note that it’s possible that by trying to list all places that would be different, in the end, we could come up with very little places and thus there would be only a small/reasonable overhead of keeping the 2 options.
I can think of Add > Page (note that Add > Space could be removed IMO and let the user be able to create a Space when adding a page only, which would remove one difference).
WDYT?
Thanks -Vincent
On 11 Jun 2015 at 17:28:11, Eduard Moraru ([email protected](mailto: [email protected])) wrote:
+1, with the same opinion on long URLs.
So we need a way to have a document hierarchy without impacting the URL scheme, unless the admins of the wiki explicitly want to configure it that way. This means, as Caty suggested in an offline discussion, not doing the proposed item: "- Remove the current parent/child mechanism which is outdated (and confusing) compared to the new hierarchy."
We still need the parent/child mechanism, but we could disable it by default and allow admins that create a new wiki or that migrate from a previous XWiki version that does not have ND to preserve their hierarchy and not change their URLs. The direction would obviously be to encourage the creation of Nested Documents, while still keeping the option of having shorter URLs (using parent-child).
Note: If we keep both relationships (space-page and parent-child) the create/move/etc UIs will need to check if the parent-child relationship is enabled and provide a field to set/alter that too.
Thanks, Eduard
On Thu, Jun 11, 2015 at 12:54 PM, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Jun 10, 2015 at 6:36 PM, Ecaterina Moraru (Valica) wrote:
Hi,
Since we discussed so many things lately and there are many technical constrain that we are facing, I'm going to try to get some conclusions from the UI perspective:
First of all there was the discussion about the usability tests. It's true that users are confused that we provide 2 levels of hierarchy (wiki/space/page and parent/child). If we can switch to just one it would be great since it will simplify the user's mental model. Another problem they had was with the naming, since wiki/space/page does not ring any folder/page bell, even with the icon usage. That's why I like the concept of nodes and only one type of entities that can have children. Since we are on the Web, I think the most likely entity name we could use is 'page', similar to content-page, web-page, wiki-page (even if technically is a space or a document).
Having only one type of entity, I agree to the fact that we should remove the space notion. We still have complexity, since we will have main-wiki, wikis*, pages* (child-pages).
I also agree to remove the notion of 'WebHome' from UI. We can still use it technically to differentiate old spaces from pages, but for the user doesn't mean anything, except looking technical.
Regarding the global-menu, we need to remove the wiki>space>page+actions display since it is not scalable. This means that the current breadcrumb zone will display the hierarchy. This is perfectly normal with the current navigation patterns used all over the Web. Note that classical breadcrumb do not display entity-type or actions. We shouldn't either. This means (as stated on http://design.xwiki.org/xwiki/bin/view/Proposal/ExtendedBreadcrumb) that we need to provide a Drawer + Move actions inside the content-menu.
Regarding actions, since we will have just one entity-type (not sure what we do with the wikis) we will need to standardize the entity actions. Currently we provide just 'Delete' for spaces, but if we don't display Spaces differently and they are just nodes, this means that we will need to implement or normalize the available actions. No matter what type it is technically, the user should be able to: Add (child), Edit, Delete, View, Administer, Copy, Rename, Move, Export, Watch, View History, View Informations, View Attachments, View Comments, View Rights, View Objects, etc.
Now, what I really don't like are the long URL. For me this is the most bad decision we can make. Nobody uses long URL on the web. I really like the way our current parent/child works, it provides the hierarchy in the UI, invisible in the URL (keeping it relevant to the current page). Hierarchy anyway should we displayed in Trees, not linear in URLs, since it's hard to read. People like short URL. They are easier to share, easier to scan, easier to understand what the content is about. We have the breadcrumbs for navigation, the URL is for identification.
+1, I don't like long URLs either.
Thanks, Marius
Thanks, Caty
On Mon, Jun 8, 2015 at 11:40 AM, Eduard Moraru
wrote:
Hi,
Going on the "node" architecture, where we have only documents and
child
documents, here's something interesting that pops up as "the way to go" when storing a tree structure in SQL [1]: Closure Table [2]. It seems to cover pretty much all use cases, as solution 1 (Path Enumeration - what we are doing with the "space" document field) is limited [3] when it comes to changes in the tree structure (i.e. renaming/moving a document).
Note: There is also the extension [4] that includes a depth column which would be most useful as well. Basically, getting the list of parents of a document would cost only 1 query, sorting by depth to preserve hierarchy.
Of course, all this requires an extra table in the database for storing the hierarchy relationship.
WDYT?
Thanks, Eduard
---------- [1] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/48 [2] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/68 [3] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/77 [4] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/76
On Sat, Jun 6, 2015 at 3:38 PM, [email protected] wrote:
> > > > > > On 6 Jun 2015 at 14:20:46, [email protected] ( [email protected] (mailto: > [email protected])) wrote: > > > Hi Marius, > > > > On 4 Jun 2015 at 18:16:03, Marius Dumitru Florea ( > [email protected](mailto: [email protected] )) > wrote: > > > > > On Wed, Jun 3, 2015 at 5:10 PM, Guillaume "Louis-Marie" Delhumeau > > > wrote: > > > > Hello XWiki committers. > > > > > > > > > > > > Vincent have proposed the development of nested spaces for 7.2 and > some of > > > > us have already agreed. But the concept of nested spaces introduces a > > > > problem that Denis have mentioned during some internal discussions > at XWiki > > > > SAS, and that I am going to report here. > > > > > > > > > > > > From a UI perspective, differentiating pages `A.B.C.WebHome` and > `A.B.C` > > > > could become very difficult. > > > > > > > > > > > > > > > Moreover, we know that a lot of users do not understand the notion of > > > > spaces, and they are lost when you look at them during usability > sessions. > > > > > > I'm not sure about this statement. My feeling is that many users > > > understand spaces as "folders" (they make the analogy with the file > > > system). Moreover, whenever we display a space in the XWiki UI we use > > > the folder icon, so we encourage the users to make this analogy. > > > > I agree with Guillaume here. We’ve seen it on this list but more > importantly Caty has done some recorded usability sessions and if I > remember correctly it was clearly showing the problem. And users don’t > understand that Spaces are like Folders which is why we also had this > discussion on the list at one point about renaming them as Folder. > > > > In any case, removing one concept can only be simpler IMO. I find it > simpler to have 2 concepts (Wiki, Pages: A wiki is a set of pages) instead > of 3 (Wiki, Spaces, Pages: a wiki is a set of spaces, which each one > containing pages). > > > > > > The situation is even worse if you consider the notion of > parent/child > > > > documents, which is completely unrelated to the actual hierarchy. It > > > > creates confusion! > > > > > > > > > > > > > > > To fix these problems, we propose to introduce the notion of "nested > > > > documents", i.e. the ability to create documents inside documents. > > > > > > What's the difference at a *conceptual* level between the notion of > > > parent/child we have right now and the notion of nested documents you > > > propose? I don't see it. > > > > Yes it’s the same thing from a User POV. One difference is that we want > a reference to contain the full path of a doc. Right now you’d need to > transport the (Doc Reference + the full Breadcrumb) to represent the same > thing. > > > > But I agree that it’s the same concept, it’s just a different > implementation. That’s why I’m proposing to drop the parent/child fields as > we have them now since it’s just duplicating the concepts (and it’s > confusing for users), and to reimplement the Breadcrumb UI using Doc > References. > > > > Note that having the full location in the reference also allows to have > URLs containing the full path which is interesting (for knowing where you > are by looking at the URL: http://.../view/Space.Page1, http:// .../view/Space.Page2 > doesn’t indicate anything about the relationship between Page1 and Page2 > when Page1 could the parent of Page2). It’s also interesting for SEO. > > > > > You even use "parent" and "child" words below > > > to explain the "nested" notion. The word "nested" sounds very > > > technical to me. I don't know about French, but in my native language > > > the translation for "nested" is not a commonly used word, unlike > > > parent and child. It seems easier to me to explan to a user that a > > > document can have a parent document and some child documents (the > > > parent / child relationship) then to explain them that a document can > > > be "nested" inside another document and can "nest" other documents > > > too. > > > > I don’t think GL has suggested to use the word Nested anywhere in the > UI… It’s just a word we use internally to describe the feature. I’m fine to > continue using the terminology Parent and Children. > > > > > > Say differently, if a page `A.B.C` exists, nothing should stop the > user to > > > > create the document `A.B.C.D`. > > > > > > You mentioned JCR on the next paragraph. Are JCR nodes identified by > > > the position (path) in the tree? > > > > Yes. They call it Path (we call it a Document Reference). > > > > > I think we should make a distinction > > > between the way we identify a document and the way we access that > > > document. > > > > This means using unique ids for identifying docs (and this is what we > already have in the DB except the Id is based on its path in the DB but > this could be changed and this is our problem). Of course in the UI we > should never display these ids. > > > > > I like the fact that currently when you change the parent of > > > a document the document identifier (reference) stays the same. > > > > It’s not fully true. When we rename a doc the doc id is modified. > > > > What would be interesting would be the ability to have several Document > References for a given doc (with one being the default probably). This is > something I’ve been interested in implementing for a long time but it would > probably require some model changes and it’s not for XWiki 7.x IMO. We > could discuss it when we talk about XWiki 8.x and the new model in general. > See also http://design.xwiki.org/xwiki/bin/view/Design/XWikiModel20 (on > that page I had put: “Ability to have multiple references pointing to the > same entity” and yes this is also supported by the JCR API). > > Also note the idea of "An Entity can be a pointer to another Entity (e.g > of use case: rename, aliases)” from that doc. This should be not to hard to > implement using our current model by adding a Type field in the DB. But > it’s a breaking change that would require 8.x (because current apps doing > queries on the doc table would get the “pointer” Types which should be > excluded, unless we add a filter to search*() APIs + the Query API). > > Thanks > -Vincent > > > > > In JCR[1], there is only one concept: the "node". A node can have a > > > > content, and a list of child nodes. In XWiki, documents could become > a kind > > > > of nodes, and we do not need spaces anymore. > > > > > > > > > > > > If we don't have space anymore, we could ask ourselves: "How the > rights > > > > will be propagated to the children documents? How do we distinguish > rights > > > > applied to the documents and the rights applied to the children?" > > > > > > > > > > > > I think the easiest solution is to inherit the rights from the > parent to > > > > the children, unless an object prevent it. We already have this kind > of > > > > mechanism with XWikiRights and XWikiGlobalRights. XWikiRights would > be > > > > applied for the current document, and XWikiGlobalRights for the > document and > > > > its children. > > > > > > > > > > > > But changing the XWiki model is a lot of work, that we don't have > time to > > > > achieve for 7.2. So we propose to make it step by step. > > > > > > > > > > > > The first step is to change the UI to hide the notion of space to the > > > > users. Concretely, each time a user wants to create a page called > `A`, we > > > > actually create the document `A.WebHome`. So any child of this page > would > > > > be created in the `A` space, like `A.Child`. But this child would be > in a > > > > space too, so it would be `A.Child.WebHome` actually. > > > > > > I find this 'A.WebHome' thing too complex. Look at the document > > > hierarchy tree >
http://extensions.xwiki.org/xwiki/bin/view/Extension/Document+Tree+Macro#HDo...
> > > . We can hide the spaces already by relying on the parent / child > > > relationship. > > > > A.WebHome is too complex which is exactly why Guillaume is sending this > proposal about Nested Documents. The idea is that the doc will be seen as > “A" for the user (and implemented technically as A.WebHome till we update > the DB to remove the “space” field, which would make the impl much simpler). > > > > > > Then, when we display the `A.WebHome` page, we remove all mentions > to the > > > > `WebHome` name. In the UI, it will just be presented as the document > `A`. > > > > This is a good point, knowing the fact that the term `WebHome` have > no > > > > sense for the user, neither in English or in other languages. > > > > > > > > > > > > Again, these changes are only for the UI. For the applications, it > is the > > > > developer's job to decide if the app will create documents like > > > > `Document.WebHome` or basic documents just as before. > > > > > > > > > > > > The question of what to do with AWM comes up. When a user creates an > entry, > > > > should it be a new-kind-of-document (`AppSpace.Entry.WebHome`) or an > > > > old-kind-of-document (`AppSpace.Entry`)? The first option is good for > > > > consistency and for the new possibilities it offers, but the second > is > > > > better for retro-compatibility. And the question will be the same > for all > > > > existing applications that create pages. I believe we should answer > these > > > > questions on a case-by-case basis and deserve their own mail threads. > > > > > > > > > > > > This proposal also implies to change some macros, like the {{space}} > one, > > > > and some panels. But I believe there is no blocking-point there. > > > > > > > > > > > > Finally, after these steps are accomplished in 7.2 and polished > until the > > > > end of the 7.x cycle, we will refactor the XWiki model (something we > dream > > > > about for years). > > > > > > > > > > > > To sum up, the idea we propose is: > > > > > > > > > > > > On the short run: > > > > > > > > - Hide the notion of space in the UI. > > > > > > > > - Hide the `WebHome` name in the UI. > > > > > > > > - When a user creates a page from the UI, it actually creates a > space with > > > > a WebHome. > > > > > > > > - Remove the current parent/child mechanism which is outdated (and > > > > confusing) compared to the new hierarchy. > > > > > > > > > > > > On the long run: > > > > > > > > - Remove the notion of space in the model, and replace it by "nested > > > > documents". > > > > > > > > - Tune the rights system to inherit rights from parents to children. > > > > > > > > > > > > Of course, we can discuss the technical details and the > implementation > > > > strategies. But for now, we need to know if you accept the general > idea > > > > (nested documents). > > > > > > > > > > > > > > > So, I hope you will like this proposal, and here is my +1. > > > > > > I'm not convinced. I don't see why we should drop the parent/child > > > relationship in order to introduce something similar but more complex. > > > > I’d say mostly because we need to transport the full location in the Doc > Reference, which allows us to do lots of things: > > - display it in the URL > > - no need to recompute the breadcrumb every time we need to display the > hierarchy (which is the case now and it doesn’t scale) > > - ability in the future to have several references for a single doc > > - consistency: there’s no reason that the space would be in the > reference but not the parent… ATM we have two concurrent concepts which > makes it impossible for users to understand the difference between Spaces > and child/parent relationships. > > > > Thanks > > -Vincent > > > > > Thanks, > > > Marius > > > > > > > > > > > > > > > Thanks, > > > > > > > > Guillaume D. > > > > > > > > > > > > > > > > [1] JCR: > https://en.wikipedia.org/wiki/Content_repository_API_for_Java > > > > > > > > > > > > > > > > > > > > -- > > > > Guillaume Delhumeau ([email protected]) > > > > _______________________________________________ > 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
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
On 17 Jun 2015 at 17:59:56, Guillaume Louis-Marie Delhumeau ([email protected](mailto:[email protected])) wrote:
I've created a design page: http://design.xwiki.org/xwiki/bin/view/Proposal/NestedDocuments
For the cost of having Nested Documents as an option in the UI, I see the following points:
- 2 versions of the top level menu.
Why 2 versions? I see only one.
- 2 versions of the create page form. - 2 versions of the create page panel.
I agree. We could think about dropping that Create Page Panel BTW. We kept it for backward compat reasons with older skins which didn’t have the Add menu but now that we’ve had skins that added this button for several cycles we could maybe make that panel optional as an extension on e.x.o.
- What about the *spaces* macro? 2 different behaviors? If not, should the space macro be used in the default Dashboard?
I think we could have a Document Tree instead of the Spaces list by default, possibly with the ability to do some actions on spaces (like space index as it’s done for the current spaces macro). WDYT?
Some questions:
- What do we do with the most edited spaces panel?
I think that any panel that manages spaces but not used by default could stay as they are (provided we hide the WebHome). They don’t have to be used and someone configuring his wiki to not show spaces would just not use it.
- What do we do with the space documents panel (display all documents of the current space)?
Same answer as above. WDYT? Thanks -Vincent
2015-06-15 10:59 GMT+02:00 Thomas Mortagne :
+1
On Fri, Jun 12, 2015 at 5:22 PM, [email protected] wrote:
Hi Devs,
After discussing with Anca about this she raised an idea which I find interesting and that I’d like to discuss.
* We all agree about Nested Spaces so that’s a given. * Now for Nested Document it’s less obvious. Some of us (most) believe that the way forward is to drop the concept of Spaces not only in the UI but also in the DB. However some others (Denis for example) believe that we shouldn’t change the model because it’ll be reused for implementing other features in the future (translations, permissions on xobjects, etc). Some (me included) are expressing doubts that we’ll be able to move to Nested Docs in the model any time soon. * Anca pointed out that Nested Documents in the UI is just a special view of Nested Spaces. A bit similar to the Simple/Advanced user feature or the Show Hidden Documents one. She argues that the concept of spaces, if it exists in the model (which is the case ATM), will surface to the users when they start writing scripts for example. * Said differently she believes that the UI should be in accordance with the model and that it’s a bit utopian to think that users will never see it. But she also acknowledges that it could be interesting for some users or xwiki instances to have a simplified view. * Thus Anca is asking us to think about the possibility to view Nested Documents as an **option** that can be turned on/off (could be implemented as a different skin or possibly better as options of the current skin). * Breadcrumb and menu modifications would still be done since they’re related to Nested Spaces and not Nested Documents, etc. Only the features purely related to Nested Documents would need to be able to be turned on/off (there are also plenty of places where we can find a common UI for both NS and ND).
To be honest, I’m not 100% sure how ND would be received by users and it’s possible that it won’t be the best choice in the end and that we wish to change it in the future. I would find it interesting to be able to implement the UI for NS and be able to turn on ND if need be (or the other way around).
I’m thus proposing to evaluate how complex it would be to display both a NS UI and a ND UI, based on some config options.
Note that it’s possible that by trying to list all places that would be different, in the end, we could come up with very little places and thus there would be only a small/reasonable overhead of keeping the 2 options.
I can think of Add > Page (note that Add > Space could be removed IMO and let the user be able to create a Space when adding a page only, which would remove one difference).
WDYT?
Thanks -Vincent
On 11 Jun 2015 at 17:28:11, Eduard Moraru ([email protected](mailto: [email protected])) wrote:
+1, with the same opinion on long URLs.
So we need a way to have a document hierarchy without impacting the URL scheme, unless the admins of the wiki explicitly want to configure it that way. This means, as Caty suggested in an offline discussion, not doing the proposed item: "- Remove the current parent/child mechanism which is outdated (and confusing) compared to the new hierarchy."
We still need the parent/child mechanism, but we could disable it by default and allow admins that create a new wiki or that migrate from a previous XWiki version that does not have ND to preserve their hierarchy and not change their URLs. The direction would obviously be to encourage the creation of Nested Documents, while still keeping the option of having shorter URLs (using parent-child).
Note: If we keep both relationships (space-page and parent-child) the create/move/etc UIs will need to check if the parent-child relationship is enabled and provide a field to set/alter that too.
Thanks, Eduard
On Thu, Jun 11, 2015 at 12:54 PM, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Jun 10, 2015 at 6:36 PM, Ecaterina Moraru (Valica) wrote:
Hi,
Since we discussed so many things lately and there are many technical constrain that we are facing, I'm going to try to get some conclusions from the UI perspective:
First of all there was the discussion about the usability tests. It's true that users are confused that we provide 2 levels of hierarchy (wiki/space/page and parent/child). If we can switch to just one it would be great since it will simplify the user's mental model. Another problem they had was with the naming, since wiki/space/page does not ring any folder/page bell, even with the icon usage. That's why I like the concept of nodes and only one type of entities that can have children. Since we are on the Web, I think the most likely entity name we could use is 'page', similar to content-page, web-page, wiki-page (even if technically is a space or a document).
Having only one type of entity, I agree to the fact that we should remove the space notion. We still have complexity, since we will have main-wiki, wikis*, pages* (child-pages).
I also agree to remove the notion of 'WebHome' from UI. We can still use it technically to differentiate old spaces from pages, but for the user doesn't mean anything, except looking technical.
Regarding the global-menu, we need to remove the wiki>space>page+actions display since it is not scalable. This means that the current breadcrumb zone will display the hierarchy. This is perfectly normal with the current navigation patterns used all over the Web. Note that classical breadcrumb do not display entity-type or actions. We shouldn't either. This means (as stated on http://design.xwiki.org/xwiki/bin/view/Proposal/ExtendedBreadcrumb) that we need to provide a Drawer + Move actions inside the content-menu.
Regarding actions, since we will have just one entity-type (not sure what we do with the wikis) we will need to standardize the entity actions. Currently we provide just 'Delete' for spaces, but if we don't display Spaces differently and they are just nodes, this means that we will need to implement or normalize the available actions. No matter what type it is technically, the user should be able to: Add (child), Edit, Delete, View, Administer, Copy, Rename, Move, Export, Watch, View History, View Informations, View Attachments, View Comments, View Rights, View Objects, etc.
Now, what I really don't like are the long URL. For me this is the most bad decision we can make. Nobody uses long URL on the web. I really like the way our current parent/child works, it provides the hierarchy in the UI, invisible in the URL (keeping it relevant to the current page). Hierarchy anyway should we displayed in Trees, not linear in URLs, since it's hard to read. People like short URL. They are easier to share, easier to scan, easier to understand what the content is about. We have the breadcrumbs for navigation, the URL is for identification.
+1, I don't like long URLs either.
Thanks, Marius
Thanks, Caty
On Mon, Jun 8, 2015 at 11:40 AM, Eduard Moraru
wrote:
> Hi, > > Going on the "node" architecture, where we have only documents and
child
> documents, here's something interesting that pops up as "the way to go" > when storing a tree structure in SQL [1]: Closure Table [2]. It seems to > cover pretty much all use cases, as solution 1 (Path Enumeration - what we > are doing with the "space" document field) is limited [3] when it comes to > changes in the tree structure (i.e. renaming/moving a document). > > Note: There is also the extension [4] that includes a depth column which > would be most useful as well. Basically, getting the list of parents of a > document would cost only 1 query, sorting by depth to preserve hierarchy. > > Of course, all this requires an extra table in the database for storing the > hierarchy relationship. > > WDYT? > > Thanks, > Eduard > > ---------- > [1] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/48 > [2] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/68 > [3] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/77 > [4] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/76 > > On Sat, Jun 6, 2015 at 3:38 PM, [email protected] > wrote: > > > > > > > > > > > > > On 6 Jun 2015 at 14:20:46, [email protected] ( [email protected] > (mailto: > > [email protected])) wrote: > > > > > Hi Marius, > > > > > > On 4 Jun 2015 at 18:16:03, Marius Dumitru Florea ( > > [email protected](mailto: [email protected] )) > > wrote: > > > > > > > On Wed, Jun 3, 2015 at 5:10 PM, Guillaume "Louis-Marie" Delhumeau > > > > wrote: > > > > > Hello XWiki committers. > > > > > > > > > > > > > > > Vincent have proposed the development of nested spaces for 7.2 and > > some of > > > > > us have already agreed. But the concept of nested spaces > introduces a > > > > > problem that Denis have mentioned during some internal discussions > > at XWiki > > > > > SAS, and that I am going to report here. > > > > > > > > > > > > > > > From a UI perspective, differentiating pages `A.B.C.WebHome` and > > `A.B.C` > > > > > could become very difficult. > > > > > > > > > > > > > > > > > > > Moreover, we know that a lot of users do not understand the notion > of > > > > > spaces, and they are lost when you look at them during usability > > sessions. > > > > > > > > I'm not sure about this statement. My feeling is that many users > > > > understand spaces as "folders" (they make the analogy with the file > > > > system). Moreover, whenever we display a space in the XWiki UI we use > > > > the folder icon, so we encourage the users to make this analogy. > > > > > > I agree with Guillaume here. We’ve seen it on this list but more > > importantly Caty has done some recorded usability sessions and if I > > remember correctly it was clearly showing the problem. And users don’t > > understand that Spaces are like Folders which is why we also had this > > discussion on the list at one point about renaming them as Folder. > > > > > > In any case, removing one concept can only be simpler IMO. I find it > > simpler to have 2 concepts (Wiki, Pages: A wiki is a set of pages) > instead > > of 3 (Wiki, Spaces, Pages: a wiki is a set of spaces, which each one > > containing pages). > > > > > > > > The situation is even worse if you consider the notion of > > parent/child > > > > > documents, which is completely unrelated to the actual hierarchy. > It > > > > > creates confusion! > > > > > > > > > > > > > > > > > > > To fix these problems, we propose to introduce the notion of > "nested > > > > > documents", i.e. the ability to create documents inside documents. > > > > > > > > What's the difference at a *conceptual* level between the notion of > > > > parent/child we have right now and the notion of nested documents you > > > > propose? I don't see it. > > > > > > Yes it’s the same thing from a User POV. One difference is that we want > > a reference to contain the full path of a doc. Right now you’d need to > > transport the (Doc Reference + the full Breadcrumb) to represent the same > > thing. > > > > > > But I agree that it’s the same concept, it’s just a different > > implementation. That’s why I’m proposing to drop the parent/child fields > as > > we have them now since it’s just duplicating the concepts (and it’s > > confusing for users), and to reimplement the Breadcrumb UI using Doc > > References. > > > > > > Note that having the full location in the reference also allows to have > > URLs containing the full path which is interesting (for knowing where you > > are by looking at the URL: http://.../view/Space.Page1, http:// > .../view/Space.Page2 > > doesn’t indicate anything about the relationship between Page1 and Page2 > > when Page1 could the parent of Page2). It’s also interesting for SEO. > > > > > > > You even use "parent" and "child" words below > > > > to explain the "nested" notion. The word "nested" sounds very > > > > technical to me. I don't know about French, but in my native language > > > > the translation for "nested" is not a commonly used word, unlike > > > > parent and child. It seems easier to me to explan to a user that a > > > > document can have a parent document and some child documents (the > > > > parent / child relationship) then to explain them that a document can > > > > be "nested" inside another document and can "nest" other documents > > > > too. > > > > > > I don’t think GL has suggested to use the word Nested anywhere in the > > UI… It’s just a word we use internally to describe the feature. I’m fine > to > > continue using the terminology Parent and Children. > > > > > > > > Say differently, if a page `A.B.C` exists, nothing should stop the > > user to > > > > > create the document `A.B.C.D`. > > > > > > > > You mentioned JCR on the next paragraph. Are JCR nodes identified by > > > > the position (path) in the tree? > > > > > > Yes. They call it Path (we call it a Document Reference). > > > > > > > I think we should make a distinction > > > > between the way we identify a document and the way we access that > > > > document. > > > > > > This means using unique ids for identifying docs (and this is what we > > already have in the DB except the Id is based on its path in the DB but > > this could be changed and this is our problem). Of course in the UI we > > should never display these ids. > > > > > > > I like the fact that currently when you change the parent of > > > > a document the document identifier (reference) stays the same. > > > > > > It’s not fully true. When we rename a doc the doc id is modified. > > > > > > What would be interesting would be the ability to have several Document > > References for a given doc (with one being the default probably). This is > > something I’ve been interested in implementing for a long time but it > would > > probably require some model changes and it’s not for XWiki 7.x IMO. We > > could discuss it when we talk about XWiki 8.x and the new model in > general. > > See also http://design.xwiki.org/xwiki/bin/view/Design/XWikiModel20 (on > > that page I had put: “Ability to have multiple references pointing to the > > same entity” and yes this is also supported by the JCR API). > > > > Also note the idea of "An Entity can be a pointer to another Entity (e.g > > of use case: rename, aliases)” from that doc. This should be not to hard > to > > implement using our current model by adding a Type field in the DB. But > > it’s a breaking change that would require 8.x (because current apps doing > > queries on the doc table would get the “pointer” Types which should be > > excluded, unless we add a filter to search*() APIs + the Query API). > > > > Thanks > > -Vincent > > > > > > > In JCR[1], there is only one concept: the "node". A node can have a > > > > > content, and a list of child nodes. In XWiki, documents could > become > > a kind > > > > > of nodes, and we do not need spaces anymore. > > > > > > > > > > > > > > > If we don't have space anymore, we could ask ourselves: "How the > > rights > > > > > will be propagated to the children documents? How do we distinguish > > rights > > > > > applied to the documents and the rights applied to the children?" > > > > > > > > > > > > > > > I think the easiest solution is to inherit the rights from the > > parent to > > > > > the children, unless an object prevent it. We already have this > kind > > of > > > > > mechanism with XWikiRights and XWikiGlobalRights. XWikiRights would > > be > > > > > applied for the current document, and XWikiGlobalRights for the > > document and > > > > > its children. > > > > > > > > > > > > > > > But changing the XWiki model is a lot of work, that we don't have > > time to > > > > > achieve for 7.2. So we propose to make it step by step. > > > > > > > > > > > > > > > The first step is to change the UI to hide the notion of space to > the > > > > > users. Concretely, each time a user wants to create a page called > > `A`, we > > > > > actually create the document `A.WebHome`. So any child of this page > > would > > > > > be created in the `A` space, like `A.Child`. But this child would > be > > in a > > > > > space too, so it would be `A.Child.WebHome` actually. > > > > > > > > I find this 'A.WebHome' thing too complex. Look at the document > > > > hierarchy tree > > >
http://extensions.xwiki.org/xwiki/bin/view/Extension/Document+Tree+Macro#HDo...
> > > > . We can hide the spaces already by relying on the parent / child > > > > relationship. > > > > > > A.WebHome is too complex which is exactly why Guillaume is sending this > > proposal about Nested Documents. The idea is that the doc will be seen as > > “A" for the user (and implemented technically as A.WebHome till we update > > the DB to remove the “space” field, which would make the impl much > simpler). > > > > > > > > Then, when we display the `A.WebHome` page, we remove all mentions > > to the > > > > > `WebHome` name. In the UI, it will just be presented as the > document > > `A`. > > > > > This is a good point, knowing the fact that the term `WebHome` have > > no > > > > > sense for the user, neither in English or in other languages. > > > > > > > > > > > > > > > Again, these changes are only for the UI. For the applications, it > > is the > > > > > developer's job to decide if the app will create documents like > > > > > `Document.WebHome` or basic documents just as before. > > > > > > > > > > > > > > > The question of what to do with AWM comes up. When a user creates > an > > entry, > > > > > should it be a new-kind-of-document (`AppSpace.Entry.WebHome`) or > an > > > > > old-kind-of-document (`AppSpace.Entry`)? The first option is good > for > > > > > consistency and for the new possibilities it offers, but the second > > is > > > > > better for retro-compatibility. And the question will be the same > > for all > > > > > existing applications that create pages. I believe we should answer > > these > > > > > questions on a case-by-case basis and deserve their own mail > threads. > > > > > > > > > > > > > > > This proposal also implies to change some macros, like the > {{space}} > > one, > > > > > and some panels. But I believe there is no blocking-point there. > > > > > > > > > > > > > > > Finally, after these steps are accomplished in 7.2 and polished > > until the > > > > > end of the 7.x cycle, we will refactor the XWiki model (something > we > > dream > > > > > about for years). > > > > > > > > > > > > > > > To sum up, the idea we propose is: > > > > > > > > > > > > > > > On the short run: > > > > > > > > > > - Hide the notion of space in the UI. > > > > > > > > > > - Hide the `WebHome` name in the UI. > > > > > > > > > > - When a user creates a page from the UI, it actually creates a > > space with > > > > > a WebHome. > > > > > > > > > > - Remove the current parent/child mechanism which is outdated (and > > > > > confusing) compared to the new hierarchy. > > > > > > > > > > > > > > > On the long run: > > > > > > > > > > - Remove the notion of space in the model, and replace it by > "nested > > > > > documents". > > > > > > > > > > - Tune the rights system to inherit rights from parents to > children. > > > > > > > > > > > > > > > Of course, we can discuss the technical details and the > > implementation > > > > > strategies. But for now, we need to know if you accept the general > > idea > > > > > (nested documents). > > > > > > > > > > > > > > > > > > > So, I hope you will like this proposal, and here is my +1. > > > > > > > > I'm not convinced. I don't see why we should drop the parent/child > > > > relationship in order to introduce something similar but more > complex. > > > > > > I’d say mostly because we need to transport the full location in the > Doc > > Reference, which allows us to do lots of things: > > > - display it in the URL > > > - no need to recompute the breadcrumb every time we need to display the > > hierarchy (which is the case now and it doesn’t scale) > > > - ability in the future to have several references for a single doc > > > - consistency: there’s no reason that the space would be in the > > reference but not the parent… ATM we have two concurrent concepts which > > makes it impossible for users to understand the difference between Spaces > > and child/parent relationships. > > > > > > Thanks > > > -Vincent > > > > > > > Thanks, > > > > Marius > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Guillaume D. > > > > > > > > > > > > > > > > > > > > [1] JCR: > > https://en.wikipedia.org/wiki/Content_repository_API_for_Java > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Guillaume Delhumeau ([email protected]) > > > > > > > _______________________________________________ > > 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
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
2015-06-17 18:17 GMT+02:00 [email protected] <[email protected]>:
On 17 Jun 2015 at 17:59:56, Guillaume Louis-Marie Delhumeau ( [email protected](mailto:[email protected])) wrote:
I've created a design page: http://design.xwiki.org/xwiki/bin/view/Proposal/NestedDocuments
For the cost of having Nested Documents as an option in the UI, I see the following points:
- 2 versions of the top level menu.
Why 2 versions? I see only one.
Because the actions for spaces are not the same than the actions for pages. If the concept of spaces is removed (ND enabled), then we must re-organize these actions. Unless we implement the menu designed by Caty: http://design.xwiki.org/xwiki/bin/view/Proposal/MacawSkin I love this idea.
- 2 versions of the create page form. - 2 versions of the create page panel.
I agree. We could think about dropping that Create Page Panel BTW. We kept it for backward compat reasons with older skins which didn’t have the Add menu but now that we’ve had skins that added this button for several cycles we could maybe make that panel optional as an extension on e.x.o.
- What about the *spaces* macro? 2 different behaviors? If not, should the space macro be used in the default Dashboard?
I think we could have a Document Tree instead of the Spaces list by default, possibly with the ability to do some actions on spaces (like space index as it’s done for the current spaces macro). WDYT?
Some questions:
- What do we do with the most edited spaces panel?
I think that any panel that manages spaces but not used by default could stay as they are (provided we hide the WebHome). They don’t have to be used and someone configuring his wiki to not show spaces would just not use it.
- What do we do with the space documents panel (display all documents of the current space)?
Same answer as above.
WDYT?
Thanks -Vincent
2015-06-15 10:59 GMT+02:00 Thomas Mortagne :
+1
On Fri, Jun 12, 2015 at 5:22 PM, [email protected] wrote:
Hi Devs,
After discussing with Anca about this she raised an idea which I find interesting and that I’d like to discuss.
* We all agree about Nested Spaces so that’s a given. * Now for Nested Document it’s less obvious. Some of us (most) believe that the way forward is to drop the concept of Spaces not only in the UI but also in the DB. However some others (Denis for example) believe that we shouldn’t change the model because it’ll be reused for implementing other features in the future (translations, permissions on xobjects, etc). Some (me included) are expressing doubts that we’ll be able to move to Nested Docs in the model any time soon. * Anca pointed out that Nested Documents in the UI is just a special view of Nested Spaces. A bit similar to the Simple/Advanced user feature or the Show Hidden Documents one. She argues that the concept of spaces, if it exists in the model (which is the case ATM), will surface to the users when they start writing scripts for example. * Said differently she believes that the UI should be in accordance with the model and that it’s a bit utopian to think that users will never see it. But she also acknowledges that it could be interesting for some users or xwiki instances to have a simplified view. * Thus Anca is asking us to think about the possibility to view Nested Documents as an **option** that can be turned on/off (could be implemented as a different skin or possibly better as options of the current skin). * Breadcrumb and menu modifications would still be done since they’re related to Nested Spaces and not Nested Documents, etc. Only the features purely related to Nested Documents would need to be able to be turned on/off (there are also plenty of places where we can find a common UI for both NS and ND).
To be honest, I’m not 100% sure how ND would be received by users and it’s possible that it won’t be the best choice in the end and that we wish to change it in the future. I would find it interesting to be able to implement the UI for NS and be able to turn on ND if need be (or the other way around).
I’m thus proposing to evaluate how complex it would be to display both a NS UI and a ND UI, based on some config options.
Note that it’s possible that by trying to list all places that would be different, in the end, we could come up with very little places and thus there would be only a small/reasonable overhead of keeping the 2 options.
I can think of Add > Page (note that Add > Space could be removed IMO and let the user be able to create a Space when adding a page only, which would remove one difference).
WDYT?
Thanks -Vincent
On 11 Jun 2015 at 17:28:11, Eduard Moraru ([email protected] (mailto: [email protected])) wrote:
+1, with the same opinion on long URLs.
So we need a way to have a document hierarchy without impacting the URL scheme, unless the admins of the wiki explicitly want to configure it that way. This means, as Caty suggested in an offline discussion, not doing the proposed item: "- Remove the current parent/child mechanism which is outdated (and confusing) compared to the new hierarchy."
We still need the parent/child mechanism, but we could disable it by default and allow admins that create a new wiki or that migrate from a previous XWiki version that does not have ND to preserve their hierarchy and not change their URLs. The direction would obviously be to encourage the creation of Nested Documents, while still keeping the option of having shorter URLs (using parent-child).
Note: If we keep both relationships (space-page and parent-child) the create/move/etc UIs will need to check if the parent-child relationship is enabled and provide a field to set/alter that too.
Thanks, Eduard
On Thu, Jun 11, 2015 at 12:54 PM, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Jun 10, 2015 at 6:36 PM, Ecaterina Moraru (Valica) wrote: > Hi, > > Since we discussed so many things lately and there are many technical > constrain that we are facing, I'm going to try to get some conclusions from > the UI perspective: > > First of all there was the discussion about the usability tests. It's true > that users are confused that we provide 2 levels of hierarchy > (wiki/space/page and parent/child). If we can switch to just one it would > be great since it will simplify the user's mental model. Another problem > they had was with the naming, since wiki/space/page does not ring any > folder/page bell, even with the icon usage. That's why I like the concept > of nodes and only one type of entities that can have children. Since we are > on the Web, I think the most likely entity name we could use is 'page', > similar to content-page, web-page, wiki-page (even if technically is a > space or a document). > > Having only one type of entity, I agree to the fact that we should remove > the space notion. We still have complexity, since we will have main-wiki, > wikis*, pages* (child-pages). > > I also agree to remove the notion of 'WebHome' from UI. We can still use it > technically to differentiate old spaces from pages, but for the user > doesn't mean anything, except looking technical. > > Regarding the global-menu, we need to remove the wiki>space>page+actions > display since it is not scalable. This means that the current breadcrumb > zone will display the hierarchy. This is perfectly normal with the current > navigation patterns used all over the Web. Note that classical breadcrumb > do not display entity-type or actions. We shouldn't either. This means (as > stated on
http://design.xwiki.org/xwiki/bin/view/Proposal/ExtendedBreadcrumb)
> that we need to provide a Drawer + Move actions inside the content-menu. > > Regarding actions, since we will have just one entity-type (not sure what > we do with the wikis) we will need to standardize the entity actions. > Currently we provide just 'Delete' for spaces, but if we don't display > Spaces differently and they are just nodes, this means that we will need to > implement or normalize the available actions. No matter what type it is > technically, the user should be able to: Add (child), Edit, Delete, View, > Administer, Copy, Rename, Move, Export, Watch, View History, View > Informations, View Attachments, View Comments, View Rights, View Objects, > etc. >
> Now, what I really don't like are the long URL. For me this is the most bad > decision we can make. Nobody uses long URL on the web. I really like the > way our current parent/child works, it provides the hierarchy in the UI, > invisible in the URL (keeping it relevant to the current page). Hierarchy > anyway should we displayed in Trees, not linear in URLs, since it's hard to > read. People like short URL. They are easier to share, easier to scan, > easier to understand what the content is about. We have the breadcrumbs for > navigation, the URL is for identification.
+1, I don't like long URLs either.
Thanks, Marius
> > Thanks, > Caty > > > > On Mon, Jun 8, 2015 at 11:40 AM, Eduard Moraru wrote: > >> Hi, >> >> Going on the "node" architecture, where we have only documents and child >> documents, here's something interesting that pops up as "the way to go" >> when storing a tree structure in SQL [1]: Closure Table [2]. It seems to >> cover pretty much all use cases, as solution 1 (Path Enumeration - what we >> are doing with the "space" document field) is limited [3] when it comes to >> changes in the tree structure (i.e. renaming/moving a document). >> >> Note: There is also the extension [4] that includes a depth column which >> would be most useful as well. Basically, getting the list of parents of a >> document would cost only 1 query, sorting by depth to preserve hierarchy. >> >> Of course, all this requires an extra table in the database for storing the >> hierarchy relationship. >> >> WDYT? >> >> Thanks, >> Eduard >> >> ---------- >> [1]
http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/48
>> [2]
http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/68
>> [3]
http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/77
>> [4]
http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/76
>> >> On Sat, Jun 6, 2015 at 3:38 PM, [email protected] >> wrote: >> >> > >> > >> > >> > >> > >> > On 6 Jun 2015 at 14:20:46, [email protected] ( [email protected] >> (mailto: >> > [email protected])) wrote: >> > >> > > Hi Marius, >> > > >> > > On 4 Jun 2015 at 18:16:03, Marius Dumitru Florea ( >> > [email protected](mailto: [email protected] )) >> > wrote: >> > > >> > > > On Wed, Jun 3, 2015 at 5:10 PM, Guillaume "Louis-Marie" Delhumeau >> > > > wrote: >> > > > > Hello XWiki committers. >> > > > > >> > > > > >> > > > > Vincent have proposed the development of nested spaces for 7.2 and >> > some of >> > > > > us have already agreed. But the concept of nested spaces >> introduces a >> > > > > problem that Denis have mentioned during some internal discussions >> > at XWiki >> > > > > SAS, and that I am going to report here. >> > > > > >> > > > > >> > > > > From a UI perspective, differentiating pages `A.B.C.WebHome` and >> > `A.B.C` >> > > > > could become very difficult. >> > > > > >> > > > > >> > > > >> > > > > Moreover, we know that a lot of users do not understand the notion >> of >> > > > > spaces, and they are lost when you look at them during usability >> > sessions. >> > > > >> > > > I'm not sure about this statement. My feeling is that many users >> > > > understand spaces as "folders" (they make the analogy with the file >> > > > system). Moreover, whenever we display a space in the XWiki UI we use >> > > > the folder icon, so we encourage the users to make this analogy. >> > > >> > > I agree with Guillaume here. We’ve seen it on this list but more >> > importantly Caty has done some recorded usability sessions and if I >> > remember correctly it was clearly showing the problem. And users don’t >> > understand that Spaces are like Folders which is why we also had this >> > discussion on the list at one point about renaming them as Folder. >> > > >> > > In any case, removing one concept can only be simpler IMO. I find it >> > simpler to have 2 concepts (Wiki, Pages: A wiki is a set of pages) >> instead >> > of 3 (Wiki, Spaces, Pages: a wiki is a set of spaces, which each one >> > containing pages). >> > > >> > > > > The situation is even worse if you consider the notion of >> > parent/child >> > > > > documents, which is completely unrelated to the actual hierarchy. >> It >> > > > > creates confusion! >> > > > > >> > > > > >> > > > >> > > > > To fix these problems, we propose to introduce the notion of >> "nested >> > > > > documents", i.e. the ability to create documents inside documents. >> > > > >> > > > What's the difference at a *conceptual* level between the notion of >> > > > parent/child we have right now and the notion of nested documents you >> > > > propose? I don't see it. >> > > >> > > Yes it’s the same thing from a User POV. One difference is that we want >> > a reference to contain the full path of a doc. Right now you’d need to >> > transport the (Doc Reference + the full Breadcrumb) to represent the same >> > thing. >> > > >> > > But I agree that it’s the same concept, it’s just a different >> > implementation. That’s why I’m proposing to drop the parent/child fields >> as >> > we have them now since it’s just duplicating the concepts (and it’s >> > confusing for users), and to reimplement the Breadcrumb UI using Doc >> > References. >> > > >> > > Note that having the full location in the reference also allows to have >> > URLs containing the full path which is interesting (for knowing where you >> > are by looking at the URL: http://.../view/Space.Page1, http:// >> .../view/Space.Page2 >> > doesn’t indicate anything about the relationship between Page1 and Page2 >> > when Page1 could the parent of Page2). It’s also interesting for SEO. >> > > >> > > > You even use "parent" and "child" words below >> > > > to explain the "nested" notion. The word "nested" sounds very >> > > > technical to me. I don't know about French, but in my native language >> > > > the translation for "nested" is not a commonly used word, unlike >> > > > parent and child. It seems easier to me to explan to a user that a >> > > > document can have a parent document and some child documents (the >> > > > parent / child relationship) then to explain them that a document can >> > > > be "nested" inside another document and can "nest" other documents >> > > > too. >> > > >> > > I don’t think GL has suggested to use the word Nested anywhere in the >> > UI… It’s just a word we use internally to describe the feature. I’m fine >> to >> > continue using the terminology Parent and Children. >> > > >> > > > > Say differently, if a page `A.B.C` exists, nothing should stop the >> > user to >> > > > > create the document `A.B.C.D`. >> > > > >> > > > You mentioned JCR on the next paragraph. Are JCR nodes identified by >> > > > the position (path) in the tree? >> > > >> > > Yes. They call it Path (we call it a Document Reference). >> > > >> > > > I think we should make a distinction >> > > > between the way we identify a document and the way we access that >> > > > document. >> > > >> > > This means using unique ids for identifying docs (and this is what we >> > already have in the DB except the Id is based on its path in the DB but >> > this could be changed and this is our problem). Of course in the UI we >> > should never display these ids. >> > > >> > > > I like the fact that currently when you change the parent of >> > > > a document the document identifier (reference) stays the same. >> > > >> > > It’s not fully true. When we rename a doc the doc id is modified. >> > > >> > > What would be interesting would be the ability to have several Document >> > References for a given doc (with one being the default probably). This is >> > something I’ve been interested in implementing for a long time but it >> would >> > probably require some model changes and it’s not for XWiki 7.x IMO. We >> > could discuss it when we talk about XWiki 8.x and the new model in >> general. >> > See also http://design.xwiki.org/xwiki/bin/view/Design/XWikiModel20 (on >> > that page I had put: “Ability to have multiple references pointing to the >> > same entity” and yes this is also supported by the JCR API). >> > >> > Also note the idea of "An Entity can be a pointer to another Entity (e.g >> > of use case: rename, aliases)” from that doc. This should be not to hard >> to >> > implement using our current model by adding a Type field in the DB. But >> > it’s a breaking change that would require 8.x (because current apps doing >> > queries on the doc table would get the “pointer” Types which should be >> > excluded, unless we add a filter to search*() APIs + the Query API). >> > >> > Thanks >> > -Vincent >> > >> > > > > In JCR[1], there is only one concept: the "node". A node can have a >> > > > > content, and a list of child nodes. In XWiki, documents could >> become >> > a kind >> > > > > of nodes, and we do not need spaces anymore. >> > > > > >> > > > > >> > > > > If we don't have space anymore, we could ask ourselves: "How the >> > rights >> > > > > will be propagated to the children documents? How do we distinguish >> > rights >> > > > > applied to the documents and the rights applied to the children?" >> > > > > >> > > > > >> > > > > I think the easiest solution is to inherit the rights from the >> > parent to >> > > > > the children, unless an object prevent it. We already have this >> kind >> > of >> > > > > mechanism with XWikiRights and XWikiGlobalRights. XWikiRights would >> > be >> > > > > applied for the current document, and XWikiGlobalRights for the >> > document and >> > > > > its children. >> > > > > >> > > > > >> > > > > But changing the XWiki model is a lot of work, that we don't have >> > time to >> > > > > achieve for 7.2. So we propose to make it step by step. >> > > > > >> > > > > >> > > > > The first step is to change the UI to hide the notion of space to >> the >> > > > > users. Concretely, each time a user wants to create a page called >> > `A`, we >> > > > > actually create the document `A.WebHome`. So any child of this page >> > would >> > > > > be created in the `A` space, like `A.Child`. But this child would >> be >> > in a >> > > > > space too, so it would be `A.Child.WebHome` actually. >> > > > >> > > > I find this 'A.WebHome' thing too complex. Look at the document >> > > > hierarchy tree >> > >>
http://extensions.xwiki.org/xwiki/bin/view/Extension/Document+Tree+Macro#HDo...
>> > > > . We can hide the spaces already by relying on the parent / child >> > > > relationship. >> > > >> > > A.WebHome is too complex which is exactly why Guillaume is sending this >> > proposal about Nested Documents. The idea is that the doc will be seen as >> > “A" for the user (and implemented technically as A.WebHome till we update >> > the DB to remove the “space” field, which would make the impl much >> simpler). >> > > >> > > > > Then, when we display the `A.WebHome` page, we remove all mentions >> > to the >> > > > > `WebHome` name. In the UI, it will just be presented as the >> document >> > `A`. >> > > > > This is a good point, knowing the fact that the term `WebHome` have >> > no >> > > > > sense for the user, neither in English or in other languages. >> > > > > >> > > > > >> > > > > Again, these changes are only for the UI. For the applications, it >> > is the >> > > > > developer's job to decide if the app will create documents like >> > > > > `Document.WebHome` or basic documents just as before. >> > > > > >> > > > > >> > > > > The question of what to do with AWM comes up. When a user creates >> an >> > entry, >> > > > > should it be a new-kind-of-document (`AppSpace.Entry.WebHome`) or >> an >> > > > > old-kind-of-document (`AppSpace.Entry`)? The first option is good >> for >> > > > > consistency and for the new possibilities it offers, but the second >> > is >> > > > > better for retro-compatibility. And the question will be the same >> > for all >> > > > > existing applications that create pages. I believe we should answer >> > these >> > > > > questions on a case-by-case basis and deserve their own mail >> threads. >> > > > > >> > > > > >> > > > > This proposal also implies to change some macros, like the >> {{space}} >> > one, >> > > > > and some panels. But I believe there is no blocking-point there. >> > > > > >> > > > > >> > > > > Finally, after these steps are accomplished in 7.2 and polished >> > until the >> > > > > end of the 7.x cycle, we will refactor the XWiki model (something >> we >> > dream >> > > > > about for years). >> > > > > >> > > > > >> > > > > To sum up, the idea we propose is: >> > > > > >> > > > > >> > > > > On the short run: >> > > > > >> > > > > - Hide the notion of space in the UI. >> > > > > >> > > > > - Hide the `WebHome` name in the UI. >> > > > > >> > > > > - When a user creates a page from the UI, it actually creates a >> > space with >> > > > > a WebHome. >> > > > > >> > > > > - Remove the current parent/child mechanism which is outdated (and >> > > > > confusing) compared to the new hierarchy. >> > > > > >> > > > > >> > > > > On the long run: >> > > > > >> > > > > - Remove the notion of space in the model, and replace it by >> "nested >> > > > > documents". >> > > > > >> > > > > - Tune the rights system to inherit rights from parents to >> children. >> > > > > >> > > > > >> > > > > Of course, we can discuss the technical details and the >> > implementation >> > > > > strategies. But for now, we need to know if you accept the general >> > idea >> > > > > (nested documents). >> > > > > >> > > > > >> > > > >> > > > > So, I hope you will like this proposal, and here is my +1. >> > > > >> > > > I'm not convinced. I don't see why we should drop the parent/child >> > > > relationship in order to introduce something similar but more >> complex. >> > > >> > > I’d say mostly because we need to transport the full location in the >> Doc >> > Reference, which allows us to do lots of things: >> > > - display it in the URL >> > > - no need to recompute the breadcrumb every time we need to display the >> > hierarchy (which is the case now and it doesn’t scale) >> > > - ability in the future to have several references for a single doc >> > > - consistency: there’s no reason that the space would be in the >> > reference but not the parent… ATM we have two concurrent concepts which >> > makes it impossible for users to understand the difference between Spaces >> > and child/parent relationships. >> > > >> > > Thanks >> > > -Vincent >> > > >> > > > Thanks, >> > > > Marius >> > > > >> > > > > >> > > > > >> > > > > Thanks, >> > > > > >> > > > > Guillaume D. >> > > > > >> > > > > >> > > > > >> > > > > [1] JCR: >> > https://en.wikipedia.org/wiki/Content_repository_API_for_Java >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > -- >> > > > > Guillaume Delhumeau ([email protected]) >> > > >> > >> > _______________________________________________ >> > 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
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
On 17 Jun 2015 at 18:26:46, Guillaume Louis-Marie Delhumeau ([email protected](mailto:[email protected])) wrote:
2015-06-17 18:17 GMT+02:00 [email protected] :
On 17 Jun 2015 at 17:59:56, Guillaume Louis-Marie Delhumeau ( [email protected](mailto:[email protected])) wrote:
I've created a design page: http://design.xwiki.org/xwiki/bin/view/Proposal/NestedDocuments
For the cost of having Nested Documents as an option in the UI, I see the following points:
- 2 versions of the top level menu.
Why 2 versions? I see only one.
Because the actions for spaces are not the same than the actions for pages. If the concept of spaces is removed (ND enabled), then we must re-organize these actions.
Unless we implement the menu designed by Caty: http://design.xwiki.org/xwiki/bin/view/Proposal/MacawSkin I love this idea.
Yes me too because: - it reduces the clutter - it’s the same for NS and ND (only change is the Add Page screen which can be different based on some config) - we keep the breadcrumb (and possibly extend it with actions or easy navigation to siblings and children - See the other thread where this is discussed) Thanks -Vincent
- 2 versions of the create page form. - 2 versions of the create page panel.
I agree. We could think about dropping that Create Page Panel BTW. We kept it for backward compat reasons with older skins which didn’t have the Add menu but now that we’ve had skins that added this button for several cycles we could maybe make that panel optional as an extension on e.x.o.
- What about the *spaces* macro? 2 different behaviors? If not, should the space macro be used in the default Dashboard?
I think we could have a Document Tree instead of the Spaces list by default, possibly with the ability to do some actions on spaces (like space index as it’s done for the current spaces macro). WDYT?
Some questions:
- What do we do with the most edited spaces panel?
I think that any panel that manages spaces but not used by default could stay as they are (provided we hide the WebHome). They don’t have to be used and someone configuring his wiki to not show spaces would just not use it.
- What do we do with the space documents panel (display all documents of the current space)?
Same answer as above.
WDYT?
Thanks -Vincent
2015-06-15 10:59 GMT+02:00 Thomas Mortagne :
+1
On Fri, Jun 12, 2015 at 5:22 PM, [email protected] wrote:
Hi Devs,
After discussing with Anca about this she raised an idea which I find interesting and that I’d like to discuss.
* We all agree about Nested Spaces so that’s a given. * Now for Nested Document it’s less obvious. Some of us (most) believe that the way forward is to drop the concept of Spaces not only in the UI but also in the DB. However some others (Denis for example) believe that we shouldn’t change the model because it’ll be reused for implementing other features in the future (translations, permissions on xobjects, etc). Some (me included) are expressing doubts that we’ll be able to move to Nested Docs in the model any time soon. * Anca pointed out that Nested Documents in the UI is just a special view of Nested Spaces. A bit similar to the Simple/Advanced user feature or the Show Hidden Documents one. She argues that the concept of spaces, if it exists in the model (which is the case ATM), will surface to the users when they start writing scripts for example. * Said differently she believes that the UI should be in accordance with the model and that it’s a bit utopian to think that users will never see it. But she also acknowledges that it could be interesting for some users or xwiki instances to have a simplified view. * Thus Anca is asking us to think about the possibility to view Nested Documents as an **option** that can be turned on/off (could be implemented as a different skin or possibly better as options of the current skin). * Breadcrumb and menu modifications would still be done since they’re related to Nested Spaces and not Nested Documents, etc. Only the features purely related to Nested Documents would need to be able to be turned on/off (there are also plenty of places where we can find a common UI for both NS and ND).
To be honest, I’m not 100% sure how ND would be received by users and it’s possible that it won’t be the best choice in the end and that we wish to change it in the future. I would find it interesting to be able to implement the UI for NS and be able to turn on ND if need be (or the other way around).
I’m thus proposing to evaluate how complex it would be to display both a NS UI and a ND UI, based on some config options.
Note that it’s possible that by trying to list all places that would be different, in the end, we could come up with very little places and thus there would be only a small/reasonable overhead of keeping the 2 options.
I can think of Add > Page (note that Add > Space could be removed IMO and let the user be able to create a Space when adding a page only, which would remove one difference).
WDYT?
Thanks -Vincent
On 11 Jun 2015 at 17:28:11, Eduard Moraru ([email protected] (mailto: [email protected])) wrote:
+1, with the same opinion on long URLs.
So we need a way to have a document hierarchy without impacting the URL scheme, unless the admins of the wiki explicitly want to configure it that way. This means, as Caty suggested in an offline discussion, not doing the proposed item: "- Remove the current parent/child mechanism which is outdated (and confusing) compared to the new hierarchy."
We still need the parent/child mechanism, but we could disable it by default and allow admins that create a new wiki or that migrate from a previous XWiki version that does not have ND to preserve their hierarchy and not change their URLs. The direction would obviously be to encourage the creation of Nested Documents, while still keeping the option of having shorter URLs (using parent-child).
Note: If we keep both relationships (space-page and parent-child) the create/move/etc UIs will need to check if the parent-child relationship is enabled and provide a field to set/alter that too.
Thanks, Eduard
On Thu, Jun 11, 2015 at 12:54 PM, Marius Dumitru Florea < [email protected]> wrote:
> On Wed, Jun 10, 2015 at 6:36 PM, Ecaterina Moraru (Valica) > wrote: > > Hi, > > > > Since we discussed so many things lately and there are many technical > > constrain that we are facing, I'm going to try to get some conclusions > from > > the UI perspective: > > > > First of all there was the discussion about the usability tests. It's > true > > that users are confused that we provide 2 levels of hierarchy > > (wiki/space/page and parent/child). If we can switch to just one it would > > be great since it will simplify the user's mental model. Another problem > > they had was with the naming, since wiki/space/page does not ring any > > folder/page bell, even with the icon usage. That's why I like the concept > > of nodes and only one type of entities that can have children. Since we > are > > on the Web, I think the most likely entity name we could use is 'page', > > similar to content-page, web-page, wiki-page (even if technically is a > > space or a document). > > > > Having only one type of entity, I agree to the fact that we should remove > > the space notion. We still have complexity, since we will have main-wiki, > > wikis*, pages* (child-pages). > > > > I also agree to remove the notion of 'WebHome' from UI. We can still use > it > > technically to differentiate old spaces from pages, but for the user > > doesn't mean anything, except looking technical. > > > > Regarding the global-menu, we need to remove the wiki>space>page+actions > > display since it is not scalable. This means that the current breadcrumb > > zone will display the hierarchy. This is perfectly normal with the > current > > navigation patterns used all over the Web. Note that classical breadcrumb > > do not display entity-type or actions. We shouldn't either. This means > (as > > stated on > http://design.xwiki.org/xwiki/bin/view/Proposal/ExtendedBreadcrumb) > > that we need to provide a Drawer + Move actions inside the content-menu. > > > > Regarding actions, since we will have just one entity-type (not sure what > > we do with the wikis) we will need to standardize the entity actions. > > Currently we provide just 'Delete' for spaces, but if we don't display > > Spaces differently and they are just nodes, this means that we will need > to > > implement or normalize the available actions. No matter what type it is > > technically, the user should be able to: Add (child), Edit, Delete, View, > > Administer, Copy, Rename, Move, Export, Watch, View History, View > > Informations, View Attachments, View Comments, View Rights, View Objects, > > etc. > > > > > Now, what I really don't like are the long URL. For me this is the most > bad > > decision we can make. Nobody uses long URL on the web. I really like the > > way our current parent/child works, it provides the hierarchy in the UI, > > invisible in the URL (keeping it relevant to the current page). Hierarchy > > anyway should we displayed in Trees, not linear in URLs, since it's hard > to > > read. People like short URL. They are easier to share, easier to scan, > > easier to understand what the content is about. We have the breadcrumbs > for > > navigation, the URL is for identification. > > +1, I don't like long URLs either. > > Thanks, > Marius > > > > > Thanks, > > Caty > > > > > > > > On Mon, Jun 8, 2015 at 11:40 AM, Eduard Moraru > wrote: > > > >> Hi, > >> > >> Going on the "node" architecture, where we have only documents and child > >> documents, here's something interesting that pops up as "the way to go" > >> when storing a tree structure in SQL [1]: Closure Table [2]. It seems to > >> cover pretty much all use cases, as solution 1 (Path Enumeration - what > we > >> are doing with the "space" document field) is limited [3] when it comes > to > >> changes in the tree structure (i.e. renaming/moving a document). > >> > >> Note: There is also the extension [4] that includes a depth column which > >> would be most useful as well. Basically, getting the list of parents of > a > >> document would cost only 1 query, sorting by depth to preserve > hierarchy. > >> > >> Of course, all this requires an extra table in the database for storing > the > >> hierarchy relationship. > >> > >> WDYT? > >> > >> Thanks, > >> Eduard > >> > >> ---------- > >> [1] > http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/48 > >> [2] > http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/68 > >> [3] > http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/77 > >> [4] > http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/76 > >> > >> On Sat, Jun 6, 2015 at 3:38 PM, [email protected] > >> wrote: > >> > >> > > >> > > >> > > >> > > >> > > >> > On 6 Jun 2015 at 14:20:46, [email protected] ( [email protected] > >> (mailto: > >> > [email protected])) wrote: > >> > > >> > > Hi Marius, > >> > > > >> > > On 4 Jun 2015 at 18:16:03, Marius Dumitru Florea ( > >> > [email protected](mailto: [email protected] > )) > >> > wrote: > >> > > > >> > > > On Wed, Jun 3, 2015 at 5:10 PM, Guillaume "Louis-Marie" Delhumeau > >> > > > wrote: > >> > > > > Hello XWiki committers. > >> > > > > > >> > > > > > >> > > > > Vincent have proposed the development of nested spaces for 7.2 > and > >> > some of > >> > > > > us have already agreed. But the concept of nested spaces > >> introduces a > >> > > > > problem that Denis have mentioned during some internal > discussions > >> > at XWiki > >> > > > > SAS, and that I am going to report here. > >> > > > > > >> > > > > > >> > > > > From a UI perspective, differentiating pages `A.B.C.WebHome` and > >> > `A.B.C` > >> > > > > could become very difficult. > >> > > > > > >> > > > > > >> > > > > >> > > > > Moreover, we know that a lot of users do not understand the > notion > >> of > >> > > > > spaces, and they are lost when you look at them during usability > >> > sessions. > >> > > > > >> > > > I'm not sure about this statement. My feeling is that many users > >> > > > understand spaces as "folders" (they make the analogy with the > file > >> > > > system). Moreover, whenever we display a space in the XWiki UI we > use > >> > > > the folder icon, so we encourage the users to make this analogy. > >> > > > >> > > I agree with Guillaume here. We’ve seen it on this list but more > >> > importantly Caty has done some recorded usability sessions and if I > >> > remember correctly it was clearly showing the problem. And users don’t > >> > understand that Spaces are like Folders which is why we also had this > >> > discussion on the list at one point about renaming them as Folder. > >> > > > >> > > In any case, removing one concept can only be simpler IMO. I find it > >> > simpler to have 2 concepts (Wiki, Pages: A wiki is a set of pages) > >> instead > >> > of 3 (Wiki, Spaces, Pages: a wiki is a set of spaces, which each one > >> > containing pages). > >> > > > >> > > > > The situation is even worse if you consider the notion of > >> > parent/child > >> > > > > documents, which is completely unrelated to the actual > hierarchy. > >> It > >> > > > > creates confusion! > >> > > > > > >> > > > > > >> > > > > >> > > > > To fix these problems, we propose to introduce the notion of > >> "nested > >> > > > > documents", i.e. the ability to create documents inside > documents. > >> > > > > >> > > > What's the difference at a *conceptual* level between the notion > of > >> > > > parent/child we have right now and the notion of nested documents > you > >> > > > propose? I don't see it. > >> > > > >> > > Yes it’s the same thing from a User POV. One difference is that we > want > >> > a reference to contain the full path of a doc. Right now you’d need to > >> > transport the (Doc Reference + the full Breadcrumb) to represent the > same > >> > thing. > >> > > > >> > > But I agree that it’s the same concept, it’s just a different > >> > implementation. That’s why I’m proposing to drop the parent/child > fields > >> as > >> > we have them now since it’s just duplicating the concepts (and it’s > >> > confusing for users), and to reimplement the Breadcrumb UI using Doc > >> > References. > >> > > > >> > > Note that having the full location in the reference also allows to > have > >> > URLs containing the full path which is interesting (for knowing where > you > >> > are by looking at the URL: http://.../view/Space.Page1, http:// > >> .../view/Space.Page2 > >> > doesn’t indicate anything about the relationship between Page1 and > Page2 > >> > when Page1 could the parent of Page2). It’s also interesting for SEO. > >> > > > >> > > > You even use "parent" and "child" words below > >> > > > to explain the "nested" notion. The word "nested" sounds very > >> > > > technical to me. I don't know about French, but in my native > language > >> > > > the translation for "nested" is not a commonly used word, unlike > >> > > > parent and child. It seems easier to me to explan to a user that a > >> > > > document can have a parent document and some child documents (the > >> > > > parent / child relationship) then to explain them that a document > can > >> > > > be "nested" inside another document and can "nest" other documents > >> > > > too. > >> > > > >> > > I don’t think GL has suggested to use the word Nested anywhere in > the > >> > UI… It’s just a word we use internally to describe the feature. I’m > fine > >> to > >> > continue using the terminology Parent and Children. > >> > > > >> > > > > Say differently, if a page `A.B.C` exists, nothing should stop > the > >> > user to > >> > > > > create the document `A.B.C.D`. > >> > > > > >> > > > You mentioned JCR on the next paragraph. Are JCR nodes identified > by > >> > > > the position (path) in the tree? > >> > > > >> > > Yes. They call it Path (we call it a Document Reference). > >> > > > >> > > > I think we should make a distinction > >> > > > between the way we identify a document and the way we access that > >> > > > document. > >> > > > >> > > This means using unique ids for identifying docs (and this is what > we > >> > already have in the DB except the Id is based on its path in the DB > but > >> > this could be changed and this is our problem). Of course in the UI we > >> > should never display these ids. > >> > > > >> > > > I like the fact that currently when you change the parent of > >> > > > a document the document identifier (reference) stays the same. > >> > > > >> > > It’s not fully true. When we rename a doc the doc id is modified. > >> > > > >> > > What would be interesting would be the ability to have several > Document > >> > References for a given doc (with one being the default probably). > This is > >> > something I’ve been interested in implementing for a long time but it > >> would > >> > probably require some model changes and it’s not for XWiki 7.x IMO. We > >> > could discuss it when we talk about XWiki 8.x and the new model in > >> general. > >> > See also http://design.xwiki.org/xwiki/bin/view/Design/XWikiModel20 > (on > >> > that page I had put: “Ability to have multiple references pointing to > the > >> > same entity” and yes this is also supported by the JCR API). > >> > > >> > Also note the idea of "An Entity can be a pointer to another Entity > (e.g > >> > of use case: rename, aliases)” from that doc. This should be not to > hard > >> to > >> > implement using our current model by adding a Type field in the DB. > But > >> > it’s a breaking change that would require 8.x (because current apps > doing > >> > queries on the doc table would get the “pointer” Types which should be > >> > excluded, unless we add a filter to search*() APIs + the Query API). > >> > > >> > Thanks > >> > -Vincent > >> > > >> > > > > In JCR[1], there is only one concept: the "node". A node can > have a > >> > > > > content, and a list of child nodes. In XWiki, documents could > >> become > >> > a kind > >> > > > > of nodes, and we do not need spaces anymore. > >> > > > > > >> > > > > > >> > > > > If we don't have space anymore, we could ask ourselves: "How the > >> > rights > >> > > > > will be propagated to the children documents? How do we > distinguish > >> > rights > >> > > > > applied to the documents and the rights applied to the > children?" > >> > > > > > >> > > > > > >> > > > > I think the easiest solution is to inherit the rights from the > >> > parent to > >> > > > > the children, unless an object prevent it. We already have this > >> kind > >> > of > >> > > > > mechanism with XWikiRights and XWikiGlobalRights. XWikiRights > would > >> > be > >> > > > > applied for the current document, and XWikiGlobalRights for the > >> > document and > >> > > > > its children. > >> > > > > > >> > > > > > >> > > > > But changing the XWiki model is a lot of work, that we don't > have > >> > time to > >> > > > > achieve for 7.2. So we propose to make it step by step. > >> > > > > > >> > > > > > >> > > > > The first step is to change the UI to hide the notion of space > to > >> the > >> > > > > users. Concretely, each time a user wants to create a page > called > >> > `A`, we > >> > > > > actually create the document `A.WebHome`. So any child of this > page > >> > would > >> > > > > be created in the `A` space, like `A.Child`. But this child > would > >> be > >> > in a > >> > > > > space too, so it would be `A.Child.WebHome` actually. > >> > > > > >> > > > I find this 'A.WebHome' thing too complex. Look at the document > >> > > > hierarchy tree > >> > > >> >
http://extensions.xwiki.org/xwiki/bin/view/Extension/Document+Tree+Macro#HDo...
> >> > > > . We can hide the spaces already by relying on the parent / child > >> > > > relationship. > >> > > > >> > > A.WebHome is too complex which is exactly why Guillaume is sending > this > >> > proposal about Nested Documents. The idea is that the doc will be > seen as > >> > “A" for the user (and implemented technically as A.WebHome till we > update > >> > the DB to remove the “space” field, which would make the impl much > >> simpler). > >> > > > >> > > > > Then, when we display the `A.WebHome` page, we remove all > mentions > >> > to the > >> > > > > `WebHome` name. In the UI, it will just be presented as the > >> document > >> > `A`. > >> > > > > This is a good point, knowing the fact that the term `WebHome` > have > >> > no > >> > > > > sense for the user, neither in English or in other languages. > >> > > > > > >> > > > > > >> > > > > Again, these changes are only for the UI. For the applications, > it > >> > is the > >> > > > > developer's job to decide if the app will create documents like > >> > > > > `Document.WebHome` or basic documents just as before. > >> > > > > > >> > > > > > >> > > > > The question of what to do with AWM comes up. When a user > creates > >> an > >> > entry, > >> > > > > should it be a new-kind-of-document (`AppSpace.Entry.WebHome`) > or > >> an > >> > > > > old-kind-of-document (`AppSpace.Entry`)? The first option is > good > >> for > >> > > > > consistency and for the new possibilities it offers, but the > second > >> > is > >> > > > > better for retro-compatibility. And the question will be the > same > >> > for all > >> > > > > existing applications that create pages. I believe we should > answer > >> > these > >> > > > > questions on a case-by-case basis and deserve their own mail > >> threads. > >> > > > > > >> > > > > > >> > > > > This proposal also implies to change some macros, like the > >> {{space}} > >> > one, > >> > > > > and some panels. But I believe there is no blocking-point there. > >> > > > > > >> > > > > > >> > > > > Finally, after these steps are accomplished in 7.2 and polished > >> > until the > >> > > > > end of the 7.x cycle, we will refactor the XWiki model > (something > >> we > >> > dream > >> > > > > about for years). > >> > > > > > >> > > > > > >> > > > > To sum up, the idea we propose is: > >> > > > > > >> > > > > > >> > > > > On the short run: > >> > > > > > >> > > > > - Hide the notion of space in the UI. > >> > > > > > >> > > > > - Hide the `WebHome` name in the UI. > >> > > > > > >> > > > > - When a user creates a page from the UI, it actually creates a > >> > space with > >> > > > > a WebHome. > >> > > > > > >> > > > > - Remove the current parent/child mechanism which is outdated > (and > >> > > > > confusing) compared to the new hierarchy. > >> > > > > > >> > > > > > >> > > > > On the long run: > >> > > > > > >> > > > > - Remove the notion of space in the model, and replace it by > >> "nested > >> > > > > documents". > >> > > > > > >> > > > > - Tune the rights system to inherit rights from parents to > >> children. > >> > > > > > >> > > > > > >> > > > > Of course, we can discuss the technical details and the > >> > implementation > >> > > > > strategies. But for now, we need to know if you accept the > general > >> > idea > >> > > > > (nested documents). > >> > > > > > >> > > > > > >> > > > > >> > > > > So, I hope you will like this proposal, and here is my +1. > >> > > > > >> > > > I'm not convinced. I don't see why we should drop the parent/child > >> > > > relationship in order to introduce something similar but more > >> complex. > >> > > > >> > > I’d say mostly because we need to transport the full location in the > >> Doc > >> > Reference, which allows us to do lots of things: > >> > > - display it in the URL > >> > > - no need to recompute the breadcrumb every time we need to display > the > >> > hierarchy (which is the case now and it doesn’t scale) > >> > > - ability in the future to have several references for a single doc > >> > > - consistency: there’s no reason that the space would be in the > >> > reference but not the parent… ATM we have two concurrent concepts > which > >> > makes it impossible for users to understand the difference between > Spaces > >> > and child/parent relationships. > >> > > > >> > > Thanks > >> > > -Vincent > >> > > > >> > > > Thanks, > >> > > > Marius > >> > > > > >> > > > > > >> > > > > > >> > > > > Thanks, > >> > > > > > >> > > > > Guillaume D. > >> > > > > > >> > > > > > >> > > > > > >> > > > > [1] JCR: > >> > https://en.wikipedia.org/wiki/Content_repository_API_for_Java > >> > > > > > >> > > > >
So we really need to start deciding what will be the differences from a user POV about the “Nested Spaces” view and the “Nested Documents” view. There are 2 possibilities I can think ok. Assumptions: - In both cases we assume that by default XE is in “Nested Documents” view when you install it and that going to the “Nested Spaces” view is an advanced and technical option. - In both cases we implement the hiding of WebHome everywhere in the UI by assimilating WebHome and the Space it’s in. Option 1 ======== Concept: We clearly show the differences between Spaces and Documents in the UI * Have an checkbox option in the user profile that is named something like “Show the Space concept” * Everywhere in the UI where we display spaces (and there are lots of places), we display them differently than documents. Some examples: ** In the Document Tree the icon used to display spaces is different than the one used to display documents ** In the Index application we would need to either have 2 tabs: one for Documents and one for Spaces or a single one but in this case the Livetable column should be named “Document and Spaces” and both entities should be displayed differently (I’m assuming we want a single column, see T13 at http://design.xwiki.org/xwiki/bin/view/Proposal/NestedSpaces#HOriginallistof...) ** The Add button would list 2 actions: Add > Page and Add > Space ** In the Main Wiki administration UI we have a “Select Space to Administer” label to choose the space to administer ** In the Add Page UI we ask the user to select both the document name and the space in which it’s located ** We can keep the “Space List” on the home page’s dashboard Option 2 ======== Concept: We show Spaces and Documents as similarly as possible in the UI to have the same UI as much as possible between “Nested Spaces” and “Nested Documents”. * In the user profile, we would have a checkbox option named something like “Ability to create several Documents in the same Space” * Everywhere in the UI we don’t differentiate Spaces and Documents. The same examples as above would become: ** In the Document Tree we use the same icon (a node icon) to display either spaces or documents ** In the Index Application, we have a single Document tab and in the Livetable column is named “Location” (or “Document Names”) and the reference is displayed but without showing different icons for Spaces or Documents. ** The Add > Space menu entry could be removed and only an Add > Page entry would stay but when you click on it, you’d still have the ability to create new Spaces. Basically we ask the user to select both the document name and the space in which it’s located ** We replace the “Space List” on the home page’s dashboard by a “Document List” widget (showing both spaces and pages). In summary, option 2 reduces the difference between Nested Documents and Nested Spaces to the Add > Page UI. Pros/Cons ========= * Option 1: ** Strong difference between Space/Documents in the UI ** Hard to implement: lots of places need to have different behavior depending on whether the user profile option is turned on or off ** Existing extensions don’t need to be modified to feel natural if you’re in the “Nested Spaces” mode. However note that since we want to have Nested Documents by default these extensions must be updated ASAP anyway to reflect that. * Option 2: ** Smaller difference between Space/Document in the UI ** Easy to implement since the only UI ** Existing extensions may not feel natural (until they’re updated for Nested Documents but we need to do that anyway) WDYT? I’m worried that Option 1 is going to be costly to develop and maintain. Anca, since you were the one who raised this idea of keeping both “Nested Spaces” and “Nested Documents” in the UI, what’s your POV? Thanks -Vincent On 17 Jun 2015 at 20:32:39, [email protected] ([email protected](mailto:[email protected])) wrote:
On 17 Jun 2015 at 18:26:46, Guillaume Louis-Marie Delhumeau ([email protected](mailto:[email protected])) wrote:
2015-06-17 18:17 GMT+02:00 [email protected] :
On 17 Jun 2015 at 17:59:56, Guillaume Louis-Marie Delhumeau ( [email protected](mailto:[email protected])) wrote:
I've created a design page: http://design.xwiki.org/xwiki/bin/view/Proposal/NestedDocuments
For the cost of having Nested Documents as an option in the UI, I see the following points:
- 2 versions of the top level menu.
Why 2 versions? I see only one.
Because the actions for spaces are not the same than the actions for pages. If the concept of spaces is removed (ND enabled), then we must re-organize these actions.
Unless we implement the menu designed by Caty: http://design.xwiki.org/xwiki/bin/view/Proposal/MacawSkin I love this idea.
Yes me too because: - it reduces the clutter - it’s the same for NS and ND (only change is the Add Page screen which can be different based on some config) - we keep the breadcrumb (and possibly extend it with actions or easy navigation to siblings and children - See the other thread where this is discussed)
Thanks -Vincent
- 2 versions of the create page form. - 2 versions of the create page panel.
I agree. We could think about dropping that Create Page Panel BTW. We kept it for backward compat reasons with older skins which didn’t have the Add menu but now that we’ve had skins that added this button for several cycles we could maybe make that panel optional as an extension on e.x.o.
- What about the *spaces* macro? 2 different behaviors? If not, should the space macro be used in the default Dashboard?
I think we could have a Document Tree instead of the Spaces list by default, possibly with the ability to do some actions on spaces (like space index as it’s done for the current spaces macro). WDYT?
Some questions:
- What do we do with the most edited spaces panel?
I think that any panel that manages spaces but not used by default could stay as they are (provided we hide the WebHome). They don’t have to be used and someone configuring his wiki to not show spaces would just not use it.
- What do we do with the space documents panel (display all documents of the current space)?
Same answer as above.
WDYT?
Thanks -Vincent
2015-06-15 10:59 GMT+02:00 Thomas Mortagne :
+1
On Fri, Jun 12, 2015 at 5:22 PM, [email protected] wrote:
Hi Devs,
After discussing with Anca about this she raised an idea which I find interesting and that I’d like to discuss.
* We all agree about Nested Spaces so that’s a given. * Now for Nested Document it’s less obvious. Some of us (most) believe that the way forward is to drop the concept of Spaces not only in the UI but also in the DB. However some others (Denis for example) believe that we shouldn’t change the model because it’ll be reused for implementing other features in the future (translations, permissions on xobjects, etc). Some (me included) are expressing doubts that we’ll be able to move to Nested Docs in the model any time soon. * Anca pointed out that Nested Documents in the UI is just a special view of Nested Spaces. A bit similar to the Simple/Advanced user feature or the Show Hidden Documents one. She argues that the concept of spaces, if it exists in the model (which is the case ATM), will surface to the users when they start writing scripts for example. * Said differently she believes that the UI should be in accordance with the model and that it’s a bit utopian to think that users will never see it. But she also acknowledges that it could be interesting for some users or xwiki instances to have a simplified view. * Thus Anca is asking us to think about the possibility to view Nested Documents as an **option** that can be turned on/off (could be implemented as a different skin or possibly better as options of the current skin). * Breadcrumb and menu modifications would still be done since they’re related to Nested Spaces and not Nested Documents, etc. Only the features purely related to Nested Documents would need to be able to be turned on/off (there are also plenty of places where we can find a common UI for both NS and ND).
To be honest, I’m not 100% sure how ND would be received by users and it’s possible that it won’t be the best choice in the end and that we wish to change it in the future. I would find it interesting to be able to implement the UI for NS and be able to turn on ND if need be (or the other way around).
I’m thus proposing to evaluate how complex it would be to display both a NS UI and a ND UI, based on some config options.
Note that it’s possible that by trying to list all places that would be different, in the end, we could come up with very little places and thus there would be only a small/reasonable overhead of keeping the 2 options.
I can think of Add > Page (note that Add > Space could be removed IMO and let the user be able to create a Space when adding a page only, which would remove one difference).
WDYT?
Thanks -Vincent
On 11 Jun 2015 at 17:28:11, Eduard Moraru ([email protected] (mailto: [email protected])) wrote:
> +1, with the same opinion on long URLs. > > So we need a way to have a document hierarchy without impacting the URL > scheme, unless the admins of the wiki explicitly want to configure it that > way. This means, as Caty suggested in an offline discussion, not doing the > proposed item: > "- Remove the current parent/child mechanism which is outdated (and > confusing) compared to the new hierarchy." > > We still need the parent/child mechanism, but we could disable it by > default and allow admins that create a new wiki or that migrate from a > previous XWiki version that does not have ND to preserve their hierarchy > and not change their URLs. The direction would obviously be to encourage > the creation of Nested Documents, while still keeping the option of having > shorter URLs (using parent-child). > > Note: If we keep both relationships (space-page and parent-child) the > create/move/etc UIs will need to check if the parent-child relationship is > enabled and provide a field to set/alter that too. > > Thanks, > Eduard > > On Thu, Jun 11, 2015 at 12:54 PM, Marius Dumitru Florea < > [email protected]> wrote: > > > On Wed, Jun 10, 2015 at 6:36 PM, Ecaterina Moraru (Valica) > > wrote: > > > Hi, > > > > > > Since we discussed so many things lately and there are many technical > > > constrain that we are facing, I'm going to try to get some conclusions > > from > > > the UI perspective: > > > > > > First of all there was the discussion about the usability tests. It's > > true > > > that users are confused that we provide 2 levels of hierarchy > > > (wiki/space/page and parent/child). If we can switch to just one it would > > > be great since it will simplify the user's mental model. Another problem > > > they had was with the naming, since wiki/space/page does not ring any > > > folder/page bell, even with the icon usage. That's why I like the concept > > > of nodes and only one type of entities that can have children. Since we > > are > > > on the Web, I think the most likely entity name we could use is 'page', > > > similar to content-page, web-page, wiki-page (even if technically is a > > > space or a document). > > > > > > Having only one type of entity, I agree to the fact that we should remove > > > the space notion. We still have complexity, since we will have main-wiki, > > > wikis*, pages* (child-pages). > > > > > > I also agree to remove the notion of 'WebHome' from UI. We can still use > > it > > > technically to differentiate old spaces from pages, but for the user > > > doesn't mean anything, except looking technical. > > > > > > Regarding the global-menu, we need to remove the wiki>space>page+actions > > > display since it is not scalable. This means that the current breadcrumb > > > zone will display the hierarchy. This is perfectly normal with the > > current > > > navigation patterns used all over the Web. Note that classical breadcrumb > > > do not display entity-type or actions. We shouldn't either. This means > > (as > > > stated on > > http://design.xwiki.org/xwiki/bin/view/Proposal/ExtendedBreadcrumb) > > > that we need to provide a Drawer + Move actions inside the content-menu. > > > > > > Regarding actions, since we will have just one entity-type (not sure what > > > we do with the wikis) we will need to standardize the entity actions. > > > Currently we provide just 'Delete' for spaces, but if we don't display > > > Spaces differently and they are just nodes, this means that we will need > > to > > > implement or normalize the available actions. No matter what type it is > > > technically, the user should be able to: Add (child), Edit, Delete, View, > > > Administer, Copy, Rename, Move, Export, Watch, View History, View > > > Informations, View Attachments, View Comments, View Rights, View Objects, > > > etc. > > > > > > > > Now, what I really don't like are the long URL. For me this is the most > > bad > > > decision we can make. Nobody uses long URL on the web. I really like the > > > way our current parent/child works, it provides the hierarchy in the UI, > > > invisible in the URL (keeping it relevant to the current page). Hierarchy > > > anyway should we displayed in Trees, not linear in URLs, since it's hard > > to > > > read. People like short URL. They are easier to share, easier to scan, > > > easier to understand what the content is about. We have the breadcrumbs > > for > > > navigation, the URL is for identification. > > > > +1, I don't like long URLs either. > > > > Thanks, > > Marius > > > > > > > > Thanks, > > > Caty > > > > > > > > > > > > On Mon, Jun 8, 2015 at 11:40 AM, Eduard Moraru > > wrote: > > > > > >> Hi, > > >> > > >> Going on the "node" architecture, where we have only documents and child > > >> documents, here's something interesting that pops up as "the way to go" > > >> when storing a tree structure in SQL [1]: Closure Table [2]. It seems to > > >> cover pretty much all use cases, as solution 1 (Path Enumeration - what > > we > > >> are doing with the "space" document field) is limited [3] when it comes > > to > > >> changes in the tree structure (i.e. renaming/moving a document). > > >> > > >> Note: There is also the extension [4] that includes a depth column which > > >> would be most useful as well. Basically, getting the list of parents of > > a > > >> document would cost only 1 query, sorting by depth to preserve > > hierarchy. > > >> > > >> Of course, all this requires an extra table in the database for storing > > the > > >> hierarchy relationship. > > >> > > >> WDYT? > > >> > > >> Thanks, > > >> Eduard > > >> > > >> ---------- > > >> [1] > > http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/48 > > >> [2] > > http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/68 > > >> [3] > > http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/77 > > >> [4] > > http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/76 > > >> > > >> On Sat, Jun 6, 2015 at 3:38 PM, [email protected] > > >> wrote: > > >> > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > On 6 Jun 2015 at 14:20:46, [email protected] ( [email protected] > > >> (mailto: > > >> > [email protected])) wrote: > > >> > > > >> > > Hi Marius, > > >> > > > > >> > > On 4 Jun 2015 at 18:16:03, Marius Dumitru Florea ( > > >> > [email protected](mailto: [email protected] > > )) > > >> > wrote: > > >> > > > > >> > > > On Wed, Jun 3, 2015 at 5:10 PM, Guillaume "Louis-Marie" Delhumeau > > >> > > > wrote: > > >> > > > > Hello XWiki committers. > > >> > > > > > > >> > > > > > > >> > > > > Vincent have proposed the development of nested spaces for 7.2 > > and > > >> > some of > > >> > > > > us have already agreed. But the concept of nested spaces > > >> introduces a > > >> > > > > problem that Denis have mentioned during some internal > > discussions > > >> > at XWiki > > >> > > > > SAS, and that I am going to report here. > > >> > > > > > > >> > > > > > > >> > > > > From a UI perspective, differentiating pages `A.B.C.WebHome` and > > >> > `A.B.C` > > >> > > > > could become very difficult. > > >> > > > > > > >> > > > > > > >> > > > > > >> > > > > Moreover, we know that a lot of users do not understand the > > notion > > >> of > > >> > > > > spaces, and they are lost when you look at them during usability > > >> > sessions. > > >> > > > > > >> > > > I'm not sure about this statement. My feeling is that many users > > >> > > > understand spaces as "folders" (they make the analogy with the > > file > > >> > > > system). Moreover, whenever we display a space in the XWiki UI we > > use > > >> > > > the folder icon, so we encourage the users to make this analogy. > > >> > > > > >> > > I agree with Guillaume here. We’ve seen it on this list but more > > >> > importantly Caty has done some recorded usability sessions and if I > > >> > remember correctly it was clearly showing the problem. And users don’t > > >> > understand that Spaces are like Folders which is why we also had this > > >> > discussion on the list at one point about renaming them as Folder. > > >> > > > > >> > > In any case, removing one concept can only be simpler IMO. I find it > > >> > simpler to have 2 concepts (Wiki, Pages: A wiki is a set of pages) > > >> instead > > >> > of 3 (Wiki, Spaces, Pages: a wiki is a set of spaces, which each one > > >> > containing pages). > > >> > > > > >> > > > > The situation is even worse if you consider the notion of > > >> > parent/child > > >> > > > > documents, which is completely unrelated to the actual > > hierarchy. > > >> It > > >> > > > > creates confusion! > > >> > > > > > > >> > > > > > > >> > > > > > >> > > > > To fix these problems, we propose to introduce the notion of > > >> "nested > > >> > > > > documents", i.e. the ability to create documents inside > > documents. > > >> > > > > > >> > > > What's the difference at a *conceptual* level between the notion > > of > > >> > > > parent/child we have right now and the notion of nested documents > > you > > >> > > > propose? I don't see it. > > >> > > > > >> > > Yes it’s the same thing from a User POV. One difference is that we > > want > > >> > a reference to contain the full path of a doc. Right now you’d need to > > >> > transport the (Doc Reference + the full Breadcrumb) to represent the > > same > > >> > thing. > > >> > > > > >> > > But I agree that it’s the same concept, it’s just a different > > >> > implementation. That’s why I’m proposing to drop the parent/child > > fields > > >> as > > >> > we have them now since it’s just duplicating the concepts (and it’s > > >> > confusing for users), and to reimplement the Breadcrumb UI using Doc > > >> > References. > > >> > > > > >> > > Note that having the full location in the reference also allows to > > have > > >> > URLs containing the full path which is interesting (for knowing where > > you > > >> > are by looking at the URL: http://.../view/Space.Page1, http:// > > >> .../view/Space.Page2 > > >> > doesn’t indicate anything about the relationship between Page1 and > > Page2 > > >> > when Page1 could the parent of Page2). It’s also interesting for SEO. > > >> > > > > >> > > > You even use "parent" and "child" words below > > >> > > > to explain the "nested" notion. The word "nested" sounds very > > >> > > > technical to me. I don't know about French, but in my native > > language > > >> > > > the translation for "nested" is not a commonly used word, unlike > > >> > > > parent and child. It seems easier to me to explan to a user that a > > >> > > > document can have a parent document and some child documents (the > > >> > > > parent / child relationship) then to explain them that a document > > can > > >> > > > be "nested" inside another document and can "nest" other documents > > >> > > > too. > > >> > > > > >> > > I don’t think GL has suggested to use the word Nested anywhere in > > the > > >> > UI… It’s just a word we use internally to describe the feature. I’m > > fine > > >> to > > >> > continue using the terminology Parent and Children. > > >> > > > > >> > > > > Say differently, if a page `A.B.C` exists, nothing should stop > > the > > >> > user to > > >> > > > > create the document `A.B.C.D`. > > >> > > > > > >> > > > You mentioned JCR on the next paragraph. Are JCR nodes identified > > by > > >> > > > the position (path) in the tree? > > >> > > > > >> > > Yes. They call it Path (we call it a Document Reference). > > >> > > > > >> > > > I think we should make a distinction > > >> > > > between the way we identify a document and the way we access that > > >> > > > document. > > >> > > > > >> > > This means using unique ids for identifying docs (and this is what > > we > > >> > already have in the DB except the Id is based on its path in the DB > > but > > >> > this could be changed and this is our problem). Of course in the UI we > > >> > should never display these ids. > > >> > > > > >> > > > I like the fact that currently when you change the parent of > > >> > > > a document the document identifier (reference) stays the same. > > >> > > > > >> > > It’s not fully true. When we rename a doc the doc id is modified. > > >> > > > > >> > > What would be interesting would be the ability to have several > > Document > > >> > References for a given doc (with one being the default probably). > > This is > > >> > something I’ve been interested in implementing for a long time but it > > >> would > > >> > probably require some model changes and it’s not for XWiki 7.x IMO. We > > >> > could discuss it when we talk about XWiki 8.x and the new model in > > >> general. > > >> > See also http://design.xwiki.org/xwiki/bin/view/Design/XWikiModel20 > > (on > > >> > that page I had put: “Ability to have multiple references pointing to > > the > > >> > same entity” and yes this is also supported by the JCR API). > > >> > > > >> > Also note the idea of "An Entity can be a pointer to another Entity > > (e.g > > >> > of use case: rename, aliases)” from that doc. This should be not to > > hard > > >> to > > >> > implement using our current model by adding a Type field in the DB. > > But > > >> > it’s a breaking change that would require 8.x (because current apps > > doing > > >> > queries on the doc table would get the “pointer” Types which should be > > >> > excluded, unless we add a filter to search*() APIs + the Query API). > > >> > > > >> > Thanks > > >> > -Vincent > > >> > > > >> > > > > In JCR[1], there is only one concept: the "node". A node can > > have a > > >> > > > > content, and a list of child nodes. In XWiki, documents could > > >> become > > >> > a kind > > >> > > > > of nodes, and we do not need spaces anymore. > > >> > > > > > > >> > > > > > > >> > > > > If we don't have space anymore, we could ask ourselves: "How the > > >> > rights > > >> > > > > will be propagated to the children documents? How do we > > distinguish > > >> > rights > > >> > > > > applied to the documents and the rights applied to the > > children?" > > >> > > > > > > >> > > > > > > >> > > > > I think the easiest solution is to inherit the rights from the > > >> > parent to > > >> > > > > the children, unless an object prevent it. We already have this > > >> kind > > >> > of > > >> > > > > mechanism with XWikiRights and XWikiGlobalRights. XWikiRights > > would > > >> > be > > >> > > > > applied for the current document, and XWikiGlobalRights for the > > >> > document and > > >> > > > > its children. > > >> > > > > > > >> > > > > > > >> > > > > But changing the XWiki model is a lot of work, that we don't > > have > > >> > time to > > >> > > > > achieve for 7.2. So we propose to make it step by step. > > >> > > > > > > >> > > > > > > >> > > > > The first step is to change the UI to hide the notion of space > > to > > >> the > > >> > > > > users. Concretely, each time a user wants to create a page > > called > > >> > `A`, we > > >> > > > > actually create the document `A.WebHome`. So any child of this > > page > > >> > would > > >> > > > > be created in the `A` space, like `A.Child`. But this child > > would > > >> be > > >> > in a > > >> > > > > space too, so it would be `A.Child.WebHome` actually. > > >> > > > > > >> > > > I find this 'A.WebHome' thing too complex. Look at the document > > >> > > > hierarchy tree > > >> > > > >> > >
http://extensions.xwiki.org/xwiki/bin/view/Extension/Document+Tree+Macro#HDo...
> > >> > > > . We can hide the spaces already by relying on the parent / child > > >> > > > relationship. > > >> > > > > >> > > A.WebHome is too complex which is exactly why Guillaume is sending > > this > > >> > proposal about Nested Documents. The idea is that the doc will be > > seen as > > >> > “A" for the user (and implemented technically as A.WebHome till we > > update > > >> > the DB to remove the “space” field, which would make the impl much > > >> simpler). > > >> > > > > >> > > > > Then, when we display the `A.WebHome` page, we remove all > > mentions > > >> > to the > > >> > > > > `WebHome` name. In the UI, it will just be presented as the > > >> document > > >> > `A`. > > >> > > > > This is a good point, knowing the fact that the term `WebHome` > > have > > >> > no > > >> > > > > sense for the user, neither in English or in other languages. > > >> > > > > > > >> > > > > > > >> > > > > Again, these changes are only for the UI. For the applications, > > it > > >> > is the > > >> > > > > developer's job to decide if the app will create documents like > > >> > > > > `Document.WebHome` or basic documents just as before. > > >> > > > > > > >> > > > > > > >> > > > > The question of what to do with AWM comes up. When a user > > creates > > >> an > > >> > entry, > > >> > > > > should it be a new-kind-of-document (`AppSpace.Entry.WebHome`) > > or > > >> an > > >> > > > > old-kind-of-document (`AppSpace.Entry`)? The first option is > > good > > >> for > > >> > > > > consistency and for the new possibilities it offers, but the > > second > > >> > is > > >> > > > > better for retro-compatibility. And the question will be the > > same > > >> > for all > > >> > > > > existing applications that create pages. I believe we should > > answer > > >> > these > > >> > > > > questions on a case-by-case basis and deserve their own mail > > >> threads. > > >> > > > > > > >> > > > > > > >> > > > > This proposal also implies to change some macros, like the > > >> {{space}} > > >> > one, > > >> > > > > and some panels. But I believe there is no blocking-point there. > > >> > > > > > > >> > > > > > > >> > > > > Finally, after these steps are accomplished in 7.2 and polished > > >> > until the > > >> > > > > end of the 7.x cycle, we will refactor the XWiki model > > (something > > >> we > > >> > dream > > >> > > > > about for years). > > >> > > > > > > >> > > > > > > >> > > > > To sum up, the idea we propose is: > > >> > > > > > > >> > > > > > > >> > > > > On the short run: > > >> > > > > > > >> > > > > - Hide the notion of space in the UI. > > >> > > > > > > >> > > > > - Hide the `WebHome` name in the UI. > > >> > > > > > > >> > > > > - When a user creates a page from the UI, it actually creates a > > >> > space with > > >> > > > > a WebHome. > > >> > > > > > > >> > > > > - Remove the current parent/child mechanism which is outdated > > (and > > >> > > > > confusing) compared to the new hierarchy. > > >> > > > > > > >> > > > > > > >> > > > > On the long run: > > >> > > > > > > >> > > > > - Remove the notion of space in the model, and replace it by > > >> "nested > > >> > > > > documents". > > >> > > > > > > >> > > > > - Tune the rights system to inherit rights from parents to > > >> children. > > >> > > > > > > >> > > > > > > >> > > > > Of course, we can discuss the technical details and the > > >> > implementation > > >> > > > > strategies. But for now, we need to know if you accept the > > general > > >> > idea > > >> > > > > (nested documents). > > >> > > > > > > >> > > > > > > >> > > > > > >> > > > > So, I hope you will like this proposal, and here is my +1. > > >> > > > > > >> > > > I'm not convinced. I don't see why we should drop the parent/child > > >> > > > relationship in order to introduce something similar but more > > >> complex. > > >> > > > > >> > > I’d say mostly because we need to transport the full location in the > > >> Doc > > >> > Reference, which allows us to do lots of things: > > >> > > - display it in the URL > > >> > > - no need to recompute the breadcrumb every time we need to display > > the > > >> > hierarchy (which is the case now and it doesn’t scale) > > >> > > - ability in the future to have several references for a single doc > > >> > > - consistency: there’s no reason that the space would be in the > > >> > reference but not the parent… ATM we have two concurrent concepts > > which > > >> > makes it impossible for users to understand the difference between > > Spaces > > >> > and child/parent relationships. > > >> > > > > >> > > Thanks > > >> > > -Vincent > > >> > > > > >> > > > Thanks, > > >> > > > Marius > > >> > > > > > >> > > > > > > >> > > > > > > >> > > > > Thanks, > > >> > > > > > > >> > > > > Guillaume D. > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > [1] JCR: > > >> > https://en.wikipedia.org/wiki/Content_repository_API_for_Java > > >> > > > > > > >> > > > >
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (6)
-
Ecaterina Moraru (Valica) -
Eduard Moraru -
Guillaume "Louis-Marie" Delhumeau -
Marius Dumitru Florea -
Thomas Mortagne -
vincent＠massol.net