[xwiki-devs] [Brainstorming] "Child/sibling/descendant page" vs "subpage"
With the introduction of Nested Spaces / Nested Documents, we find ourselves having to expand our terminology to accommodate the tree-like structure of spaces/documents that we are managing. IMO, we have started going in the wrong direction with using standard tree terminology directly in XWiki's UI, introducing new terms that simple users could be easily confused by or overwhelmed (this adding to the already existing ones). The specific issue I have in mind is how do we refer child entities for each concept (wiki, space, page) and how does this scale when the hierarchy increases. What I propose is that we Keep It SSimple (*™*) :) and just use the "sub" prefix for the concept at hand. Examples: * wiki -> subwiki (here we can continue using "wiki", as discussed previously [1], since we don`t actually support nested wikis yet, but if "subwiki" is used in a conversation it still makes perfect sense) * space -> subspace [2] * page -> subpage [3] The problem with the term "child", as pointed out by Marius in an offline chat, has indeed the issue that it can only be applied correctly for first level descendants, after which it becomes inaccurate, since starting with the second level the term "descendant" is more appropriate. All of this becomes unnecessarily complicated and, IMO, we should avoid dealing with it by using the "sub" prefix which is much easier to grasp and accept. On a similar note, I also find the term "nested" to be a bit unnecessarily complicated, specially for non-technical and non-english native users. WDYT? Thanks, Eduard ---------- [1] http://markmail.org/message/cehvpds5qmljq5f7 [2] https://en.wikipedia.org/wiki/Subspace [3] https://en.wikipedia.org/wiki/Subpage
On 17 Sep 2015 at 13:32:28, Eduard Moraru ([email protected](mailto:[email protected])) wrote:
With the introduction of Nested Spaces / Nested Documents, we find ourselves having to expand our terminology to accommodate the tree-like structure of spaces/documents that we are managing.
IMO, we have started going in the wrong direction with using standard tree terminology directly in XWiki's UI, introducing new terms that simple users could be easily confused by or overwhelmed (this adding to the already existing ones).
The specific issue I have in mind is how do we refer child entities for each concept (wiki, space, page) and how does this scale when the hierarchy increases.
What I propose is that we Keep It SSimple (*™*) :) and just use the "sub" prefix for the concept at hand. Examples: * wiki -> subwiki (here we can continue using "wiki", as discussed previously [1], since we don`t actually support nested wikis yet, but if "subwiki" is used in a conversation it still makes perfect sense) * space -> subspace [2] * page -> subpage [3]
The problem with the term "child", as pointed out by Marius in an offline chat, has indeed the issue that it can only be applied correctly for first level descendants, after which it becomes inaccurate, since starting with the second level the term "descendant" is more appropriate.
I’m not sure about this. I think Children could be used generically to mean any level of Children but would need to be checked.
All of this becomes unnecessarily complicated and, IMO, we should avoid dealing with it by using the "sub" prefix which is much easier to grasp and accept.
On a similar note, I also find the term "nested" to be a bit unnecessarily complicated, specially for non-technical and non-english native users.
WDYT?
I don’t like the “Sub" terminology because it’s incomplete. It’s not complete because you still need words for Parents, Siblings, Root, etc. I'd much prefer to use a standard Tree terminology: https://en.wikipedia.org/wiki/Tree_(data_structure)#Terminologies_used_in_Tr... BTW Terminal Page could be replaced by Leaf Page if we wanted too but maybe that’s too technical? I’d be ok to replace subwiki by Child Wiki/Children Wikis to be consistent. So overall I find Child/Children, Parent, and Siblings very easy to understand by any simple user. I find that using Sub, Parent, Siblings is not better (and it would certainly not replace Sibling). WDYT? Thanks -Vincent
Thanks, Eduard
---------- [1] http://markmail.org/message/cehvpds5qmljq5f7 [2] https://en.wikipedia.org/wiki/Subspace [3] https://en.wikipedia.org/wiki/Subpage
IMO the "sibling", "parent", "child", "leaf" terminology is too distracting since they are metaphors and, due to its real-world signification, some users might focus too much on that instead of simply focusing on the hierarchy aspect which is very simply communicated by the sub prefix. E.g. of a possible misinterpretation: A user wants to create a document under (sub) the structure of another document, he does not want to have his documents start giving "birth" to little baby (child) documents, and then those documents could have little baby brothers or sisters (siblings) and so on (descendants), thus creating a "dynasty" of documents, instead of a structure/hierarchy. Yes, that sounds weird, but that`s how it would sound like, IMO, to an English native speaker. As an exercise, try translating that terminology in another language (your native language preferably) and you will get a relatively similar result which is not really compatible IMO with "documents". The tree structure by itself is an extremely generic structure and could easily be mapped in certain implementations to these "dynasty" metaphors, however documents are pretty specific (not much room for interpretation and they are not living things) so using the "dynasty" approach feels a bit off. There is also the "child vs descendant" issue that I don`t think we want to start dealing with (differentiating) in our UIs. Just my concern or maybe I am being too picky, but it probably comes down to what we want to choose to ignore, as long as it is our intentional choice to do that. Thanks, Eduard On Thu, Sep 17, 2015 at 3:10 PM, [email protected] <[email protected]> wrote:
On 17 Sep 2015 at 13:32:28, Eduard Moraru ([email protected](mailto: [email protected])) wrote:
With the introduction of Nested Spaces / Nested Documents, we find ourselves having to expand our terminology to accommodate the tree-like structure of spaces/documents that we are managing.
IMO, we have started going in the wrong direction with using standard tree terminology directly in XWiki's UI, introducing new terms that simple users could be easily confused by or overwhelmed (this adding to the already existing ones).
The specific issue I have in mind is how do we refer child entities for each concept (wiki, space, page) and how does this scale when the hierarchy increases.
What I propose is that we Keep It SSimple (*™*) :) and just use the "sub" prefix for the concept at hand.
Examples: * wiki -> subwiki (here we can continue using "wiki", as discussed previously [1], since we don`t actually support nested wikis yet, but if "subwiki" is used in a conversation it still makes perfect sense) * space -> subspace [2] * page -> subpage [3]
The problem with the term "child", as pointed out by Marius in an offline chat, has indeed the issue that it can only be applied correctly for first level descendants, after which it becomes inaccurate, since starting with the second level the term "descendant" is more appropriate.
I’m not sure about this. I think Children could be used generically to mean any level of Children but would need to be checked.
All of this becomes unnecessarily complicated and, IMO, we should avoid dealing with it by using the "sub" prefix which is much easier to grasp
and
accept.
On a similar note, I also find the term "nested" to be a bit unnecessarily complicated, specially for non-technical and non-english native users.
WDYT?
I don’t like the “Sub" terminology because it’s incomplete. It’s not complete because you still need words for Parents, Siblings, Root, etc.
I'd much prefer to use a standard Tree terminology: https://en.wikipedia.org/wiki/Tree_(data_structure)#Terminologies_used_in_Tr...
BTW Terminal Page could be replaced by Leaf Page if we wanted too but maybe that’s too technical?
I’d be ok to replace subwiki by Child Wiki/Children Wikis to be consistent.
So overall I find Child/Children, Parent, and Siblings very easy to understand by any simple user. I find that using Sub, Parent, Siblings is not better (and it would certainly not replace Sibling).
WDYT?
Thanks -Vincent
Thanks, Eduard
---------- [1] http://markmail.org/message/cehvpds5qmljq5f7 [2] https://en.wikipedia.org/wiki/Subspace [3] https://en.wikipedia.org/wiki/Subpage
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 17 Sep 2015 at 14:51:32, Eduard Moraru ([email protected](mailto:[email protected])) wrote:
IMO the "sibling", "parent", "child", "leaf" terminology is too distracting since they are metaphors and, due to its real-world signification, some users might focus too much on that instead of simply focusing on the hierarchy aspect which is very simply communicated by the sub prefix.
E.g. of a possible misinterpretation: A user wants to create a document under (sub) the structure of another document, he does not want to have his documents start giving "birth" to little baby (child) documents, and then those documents could have little baby brothers or sisters (siblings) and so on (descendants), thus creating a "dynasty" of documents, instead of a structure/hierarchy.
Yes, that sounds weird, but that`s how it would sound like, IMO, to an English native speaker. As an exercise, try translating that terminology in another language (your native language preferably) and you will get a relatively similar result which is not really compatible IMO with "documents".
The tree structure by itself is an extremely generic structure and could easily be mapped in certain implementations to these "dynasty" metaphors, however documents are pretty specific (not much room for interpretation and they are not living things) so using the "dynasty" approach feels a bit off.
There is also the "child vs descendant" issue that I don`t think we want to start dealing with (differentiating) in our UIs.
Just my concern or maybe I am being too picky, but it probably comes down to what we want to choose to ignore, as long as it is our intentional choice to do that.
The world is all about metaphors and that’s good and what we want since that what makes something easy to memorize and understand. Look at those words: Space, Page, Document, Folder. They’re all metaphors. What’s important is to pick metaphors that people can understand. For example we know that Folder could possibly have been a better metaphor than Space. I find that Child/Children/Parent/Descendants/Siblings are perfect metaphores because people know them and use them daily. Subspace is not a well known metaphore. Nor is subpage. IMO… Thanks -Vincent
Thanks, Eduard
On Thu, Sep 17, 2015 at 3:10 PM, [email protected] wrote:
On 17 Sep 2015 at 13:32:28, Eduard Moraru ([email protected](mailto: [email protected])) wrote:
With the introduction of Nested Spaces / Nested Documents, we find ourselves having to expand our terminology to accommodate the tree-like structure of spaces/documents that we are managing.
IMO, we have started going in the wrong direction with using standard tree terminology directly in XWiki's UI, introducing new terms that simple users could be easily confused by or overwhelmed (this adding to the already existing ones).
The specific issue I have in mind is how do we refer child entities for each concept (wiki, space, page) and how does this scale when the hierarchy increases.
What I propose is that we Keep It SSimple (*™*) :) and just use the "sub" prefix for the concept at hand.
Examples: * wiki -> subwiki (here we can continue using "wiki", as discussed previously [1], since we don`t actually support nested wikis yet, but if "subwiki" is used in a conversation it still makes perfect sense) * space -> subspace [2] * page -> subpage [3]
The problem with the term "child", as pointed out by Marius in an offline chat, has indeed the issue that it can only be applied correctly for first level descendants, after which it becomes inaccurate, since starting with the second level the term "descendant" is more appropriate.
I’m not sure about this. I think Children could be used generically to mean any level of Children but would need to be checked.
All of this becomes unnecessarily complicated and, IMO, we should avoid dealing with it by using the "sub" prefix which is much easier to grasp
and
accept.
On a similar note, I also find the term "nested" to be a bit unnecessarily complicated, specially for non-technical and non-english native users.
WDYT?
I don’t like the “Sub" terminology because it’s incomplete. It’s not complete because you still need words for Parents, Siblings, Root, etc.
I'd much prefer to use a standard Tree terminology: https://en.wikipedia.org/wiki/Tree_(data_structure)#Terminologies_used_in_Tr...
BTW Terminal Page could be replaced by Leaf Page if we wanted too but maybe that’s too technical?
I’d be ok to replace subwiki by Child Wiki/Children Wikis to be consistent.
So overall I find Child/Children, Parent, and Siblings very easy to understand by any simple user. I find that using Sub, Parent, Siblings is not better (and it would certainly not replace Sibling).
WDYT?
Thanks -Vincent
Thanks, Eduard
---------- [1] http://markmail.org/message/cehvpds5qmljq5f7 [2] https://en.wikipedia.org/wiki/Subspace [3] https://en.wikipedia.org/wiki/Subpage
On Thu, Sep 17, 2015 at 3:59 PM, [email protected] <[email protected]> wrote:
On 17 Sep 2015 at 14:51:32, Eduard Moraru ([email protected](mailto: [email protected])) wrote:
IMO the "sibling", "parent", "child", "leaf" terminology is too distracting since they are metaphors and, due to its real-world signification, some users might focus too much on that instead of simply focusing on the hierarchy aspect which is very simply communicated by the sub prefix.
E.g. of a possible misinterpretation: A user wants to create a document under (sub) the structure of another document, he does not want to have his documents start giving "birth" to little baby (child) documents, and then those documents could have little baby brothers or sisters (siblings) and so on (descendants), thus creating a "dynasty" of documents, instead of a structure/hierarchy.
Yes, that sounds weird, but that`s how it would sound like, IMO, to an English native speaker. As an exercise, try translating that terminology in another language (your native language preferably) and you will get a relatively similar result which is not really compatible IMO with "documents".
The tree structure by itself is an extremely generic structure and could easily be mapped in certain implementations to these "dynasty" metaphors, however documents are pretty specific (not much room for interpretation and they are not living things) so using the "dynasty" approach feels a bit off.
There is also the "child vs descendant" issue that I don`t think we want to start dealing with (differentiating) in our UIs.
Just my concern or maybe I am being too picky, but it probably comes down to what we want to choose to ignore, as long as it is our intentional choice to do that.
The world is all about metaphors and that’s good and what we want since that what makes something easy to memorize and understand.
Look at those words: Space, Page, Document, Folder. They’re all metaphors.
What’s important is to pick metaphors that people can understand. For example we know that Folder could possibly have been a better metaphor than Space.
I find that Child/Children/Parent/Descendants/Siblings are perfect metaphores because people know them and use them daily.
I obviously agree with this.
Subspace is not a well known metaphore. Nor is subpage.
Just for the record, some numbers: * Nested Space(s): 15,100 results https://www.google.com/search?q=google+wars&ie=utf-8&oe=utf-8#safe=off&q=%28... * Subspace(s): 830,000 results https://www.google.com/webhp?hl=en#safe=off&hl=en&q=%2B%28%22subspace%22+OR+... * define: subspace https://www.google.com/search?q=define&ie=utf-8&oe=utf-8#safe=off&q=define:+... * wikipedia entry https://en.wikipedia.org/wiki/Subspace
IMO…
Technically I also side with the standard tree terminology, can`t really avoid that. I am just considering a non-technical view on it, as far as I can imagine it :) and trying to see if we can improve the presentation in any way. Thanks, Eduard
Thanks -Vincent
Thanks, Eduard
On Thu, Sep 17, 2015 at 3:10 PM, [email protected] wrote:
On 17 Sep 2015 at 13:32:28, Eduard Moraru ([email protected]
(mailto:
[email protected])) wrote:
With the introduction of Nested Spaces / Nested Documents, we find ourselves having to expand our terminology to accommodate the tree-like structure of spaces/documents that we are managing.
IMO, we have started going in the wrong direction with using standard tree terminology directly in XWiki's UI, introducing new terms that simple users could be easily confused by or overwhelmed (this adding to the already existing ones).
The specific issue I have in mind is how do we refer child entities for each concept (wiki, space, page) and how does this scale when the hierarchy increases.
What I propose is that we Keep It SSimple (*™*) :) and just use the "sub" prefix for the concept at hand.
Examples: * wiki -> subwiki (here we can continue using "wiki", as discussed previously [1], since we don`t actually support nested wikis yet, but if "subwiki" is used in a conversation it still makes perfect sense) * space -> subspace [2] * page -> subpage [3]
The problem with the term "child", as pointed out by Marius in an offline chat, has indeed the issue that it can only be applied correctly for first level descendants, after which it becomes inaccurate, since starting with the second level the term "descendant" is more appropriate.
I’m not sure about this. I think Children could be used generically to mean any level of Children but would need to be checked.
All of this becomes unnecessarily complicated and, IMO, we should
avoid
dealing with it by using the "sub" prefix which is much easier to grasp and accept.
On a similar note, I also find the term "nested" to be a bit unnecessarily complicated, specially for non-technical and non-english native users.
WDYT?
I don’t like the “Sub" terminology because it’s incomplete. It’s not complete because you still need words for Parents, Siblings, Root, etc.
I'd much prefer to use a standard Tree terminology:
https://en.wikipedia.org/wiki/Tree_(data_structure)#Terminologies_used_in_Tr...
BTW Terminal Page could be replaced by Leaf Page if we wanted too but maybe that’s too technical?
I’d be ok to replace subwiki by Child Wiki/Children Wikis to be
consistent.
So overall I find Child/Children, Parent, and Siblings very easy to understand by any simple user. I find that using Sub, Parent, Siblings
is
not better (and it would certainly not replace Sibling).
WDYT?
Thanks -Vincent
Thanks, Eduard
---------- [1] http://markmail.org/message/cehvpds5qmljq5f7 [2] https://en.wikipedia.org/wiki/Subspace [3] https://en.wikipedia.org/wiki/Subpage
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Thu, Sep 17, 2015 at 3:10 PM, [email protected] <[email protected]> wrote:
On 17 Sep 2015 at 13:32:28, Eduard Moraru ([email protected](mailto:[email protected])) wrote:
With the introduction of Nested Spaces / Nested Documents, we find ourselves having to expand our terminology to accommodate the tree-like structure of spaces/documents that we are managing.
IMO, we have started going in the wrong direction with using standard tree terminology directly in XWiki's UI, introducing new terms that simple users could be easily confused by or overwhelmed (this adding to the already existing ones).
The specific issue I have in mind is how do we refer child entities for each concept (wiki, space, page) and how does this scale when the hierarchy increases.
What I propose is that we Keep It SSimple (*™*) :) and just use the "sub" prefix for the concept at hand.
Examples: * wiki -> subwiki (here we can continue using "wiki", as discussed previously [1], since we don`t actually support nested wikis yet, but if "subwiki" is used in a conversation it still makes perfect sense) * space -> subspace [2] * page -> subpage [3]
The problem with the term "child", as pointed out by Marius in an offline chat, has indeed the issue that it can only be applied correctly for first level descendants, after which it becomes inaccurate, since starting with the second level the term "descendant" is more appropriate.
I’m not sure about this. I think Children could be used generically to mean any level of Children but would need to be checked.
All of this becomes unnecessarily complicated and, IMO, we should avoid dealing with it by using the "sub" prefix which is much easier to grasp and accept.
On a similar note, I also find the term "nested" to be a bit unnecessarily complicated, specially for non-technical and non-english native users.
WDYT?
I don’t like the “Sub" terminology because it’s incomplete. It’s not complete because you still need words for Parents, Siblings, Root, etc.
I'd much prefer to use a standard Tree terminology: https://en.wikipedia.org/wiki/Tree_(data_structure)#Terminologies_used_in_Tr...
BTW Terminal Page could be replaced by Leaf Page if we wanted too but maybe that’s too technical?
a node with no children != a node that can't have children Thanks, Marius
I’d be ok to replace subwiki by Child Wiki/Children Wikis to be consistent.
So overall I find Child/Children, Parent, and Siblings very easy to understand by any simple user. I find that using Sub, Parent, Siblings is not better (and it would certainly not replace Sibling).
WDYT?
Thanks -Vincent
Thanks, Eduard
---------- [1] http://markmail.org/message/cehvpds5qmljq5f7 [2] https://en.wikipedia.org/wiki/Subspace [3] https://en.wikipedia.org/wiki/Subpage
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 17 Sep 2015 at 16:44:28, Marius Dumitru Florea ([email protected](mailto:[email protected])) wrote:
On Thu, Sep 17, 2015 at 3:10 PM, [email protected] wrote:
On 17 Sep 2015 at 13:32:28, Eduard Moraru ([email protected](mailto:[email protected])) wrote:
With the introduction of Nested Spaces / Nested Documents, we find ourselves having to expand our terminology to accommodate the tree-like structure of spaces/documents that we are managing.
IMO, we have started going in the wrong direction with using standard tree terminology directly in XWiki's UI, introducing new terms that simple users could be easily confused by or overwhelmed (this adding to the already existing ones).
The specific issue I have in mind is how do we refer child entities for each concept (wiki, space, page) and how does this scale when the hierarchy increases.
What I propose is that we Keep It SSimple (*™*) :) and just use the "sub" prefix for the concept at hand.
Examples: * wiki -> subwiki (here we can continue using "wiki", as discussed previously [1], since we don`t actually support nested wikis yet, but if "subwiki" is used in a conversation it still makes perfect sense) * space -> subspace [2] * page -> subpage [3]
The problem with the term "child", as pointed out by Marius in an offline chat, has indeed the issue that it can only be applied correctly for first level descendants, after which it becomes inaccurate, since starting with the second level the term "descendant" is more appropriate.
I’m not sure about this. I think Children could be used generically to mean any level of Children but would need to be checked.
All of this becomes unnecessarily complicated and, IMO, we should avoid dealing with it by using the "sub" prefix which is much easier to grasp and accept.
On a similar note, I also find the term "nested" to be a bit unnecessarily complicated, specially for non-technical and non-english native users.
WDYT?
I don’t like the “Sub" terminology because it’s incomplete. It’s not complete because you still need words for Parents, Siblings, Root, etc.
I'd much prefer to use a standard Tree terminology: https://en.wikipedia.org/wiki/Tree_(data_structure)#Terminologies_used_in_Tr...
BTW Terminal Page could be replaced by Leaf Page if we wanted too but maybe that’s too technical?
a node with no children != a node that can't have children
Indeed good point, we could say that a Terminal Page is a special case of a Leaf Page :) Thanks -Vincent
Thanks, Marius
I’d be ok to replace subwiki by Child Wiki/Children Wikis to be consistent.
So overall I find Child/Children, Parent, and Siblings very easy to understand by any simple user. I find that using Sub, Parent, Siblings is not better (and it would certainly not replace Sibling).
WDYT?
Thanks -Vincent
Thanks, Eduard
---------- [1] http://markmail.org/message/cehvpds5qmljq5f7 [2] https://en.wikipedia.org/wiki/Subspace [3] https://en.wikipedia.org/wiki/Subpage
On Thu, Sep 17, 2015 at 3:10 PM, [email protected] <[email protected]> wrote:
On 17 Sep 2015 at 13:32:28, Eduard Moraru ([email protected](mailto:[email protected])) wrote:
With the introduction of Nested Spaces / Nested Documents, we find ourselves having to expand our terminology to accommodate the tree-like structure of spaces/documents that we are managing.
IMO, we have started going in the wrong direction with using standard tree terminology directly in XWiki's UI, introducing new terms that simple users could be easily confused by or overwhelmed (this adding to the already existing ones).
The specific issue I have in mind is how do we refer child entities for each concept (wiki, space, page) and how does this scale when the hierarchy increases.
What I propose is that we Keep It SSimple (*™*) :) and just use the "sub" prefix for the concept at hand.
Examples: * wiki -> subwiki (here we can continue using "wiki", as discussed previously [1], since we don`t actually support nested wikis yet, but if "subwiki" is used in a conversation it still makes perfect sense) * space -> subspace [2] * page -> subpage [3]
The problem with the term "child", as pointed out by Marius in an offline chat, has indeed the issue that it can only be applied correctly for first level descendants, after which it becomes inaccurate, since starting with the second level the term "descendant" is more appropriate.
I’m not sure about this. I think Children could be used generically to mean any level of Children but would need to be checked.
If you have A.B.C: * the "Children" viewer (live table) will show "B, C" for A * the "Siblings" viewer (live table) will show only "B" (or nothing?) for B So B and C are both children of A but are not siblings. That can be confusing. You need the tree view to see the actual hierarchy. Thanks, Marius
All of this becomes unnecessarily complicated and, IMO, we should avoid dealing with it by using the "sub" prefix which is much easier to grasp and accept.
On a similar note, I also find the term "nested" to be a bit unnecessarily complicated, specially for non-technical and non-english native users.
WDYT?
I don’t like the “Sub" terminology because it’s incomplete. It’s not complete because you still need words for Parents, Siblings, Root, etc.
I'd much prefer to use a standard Tree terminology: https://en.wikipedia.org/wiki/Tree_(data_structure)#Terminologies_used_in_Tr...
BTW Terminal Page could be replaced by Leaf Page if we wanted too but maybe that’s too technical?
I’d be ok to replace subwiki by Child Wiki/Children Wikis to be consistent.
So overall I find Child/Children, Parent, and Siblings very easy to understand by any simple user. I find that using Sub, Parent, Siblings is not better (and it would certainly not replace Sibling).
WDYT?
Thanks -Vincent
Thanks, Eduard
---------- [1] http://markmail.org/message/cehvpds5qmljq5f7 [2] https://en.wikipedia.org/wiki/Subspace [3] https://en.wikipedia.org/wiki/Subpage
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 18 Sep 2015 at 11:27:33, Marius Dumitru Florea ([email protected](mailto:[email protected])) wrote:
On Thu, Sep 17, 2015 at 3:10 PM, [email protected] wrote:
On 17 Sep 2015 at 13:32:28, Eduard Moraru ([email protected](mailto:[email protected])) wrote:
With the introduction of Nested Spaces / Nested Documents, we find ourselves having to expand our terminology to accommodate the tree-like structure of spaces/documents that we are managing.
IMO, we have started going in the wrong direction with using standard tree terminology directly in XWiki's UI, introducing new terms that simple users could be easily confused by or overwhelmed (this adding to the already existing ones).
The specific issue I have in mind is how do we refer child entities for each concept (wiki, space, page) and how does this scale when the hierarchy increases.
What I propose is that we Keep It SSimple (*™*) :) and just use the "sub" prefix for the concept at hand.
Examples: * wiki -> subwiki (here we can continue using "wiki", as discussed previously [1], since we don`t actually support nested wikis yet, but if "subwiki" is used in a conversation it still makes perfect sense) * space -> subspace [2] * page -> subpage [3]
The problem with the term "child", as pointed out by Marius in an offline chat, has indeed the issue that it can only be applied correctly for first level descendants, after which it becomes inaccurate, since starting with the second level the term "descendant" is more appropriate.
I’m not sure about this. I think Children could be used generically to mean any level of Children but would need to be checked.
If you have A.B.C:
* the "Children" viewer (live table) will show "B, C" for A
I think right now it also shows A but this could be fixed.
* the "Siblings" viewer (live table) will show only "B" (or nothing?) for B
There’s no sibling for C in your definition. If you had: A.B.C A.B.D A.E Then the sibling for A.B.C would be A.B.D. Thus if you’re on A.B.C and ask for Sibling you’ll see D in the LT. If you’re on A.B and ask for siblings you’ll see only E (and not E, C, D since C and D are not siblings of A.B). Thanks -Vincent
So B and C are both children of A but are not siblings. That can be confusing. You need the tree view to see the actual hierarchy.
Thanks, Marius
All of this becomes unnecessarily complicated and, IMO, we should avoid dealing with it by using the "sub" prefix which is much easier to grasp and accept.
On a similar note, I also find the term "nested" to be a bit unnecessarily complicated, specially for non-technical and non-english native users.
WDYT?
I don’t like the “Sub" terminology because it’s incomplete. It’s not complete because you still need words for Parents, Siblings, Root, etc.
I'd much prefer to use a standard Tree terminology: https://en.wikipedia.org/wiki/Tree_(data_structure)#Terminologies_used_in_Tr...
BTW Terminal Page could be replaced by Leaf Page if we wanted too but maybe that’s too technical?
I’d be ok to replace subwiki by Child Wiki/Children Wikis to be consistent.
So overall I find Child/Children, Parent, and Siblings very easy to understand by any simple user. I find that using Sub, Parent, Siblings is not better (and it would certainly not replace Sibling).
WDYT?
Thanks -Vincent
Thanks, Eduard
---------- [1] http://markmail.org/message/cehvpds5qmljq5f7 [2] https://en.wikipedia.org/wiki/Subspace [3] https://en.wikipedia.org/wiki/Subpage
_______________________________________________ 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, Sep 18, 2015 at 12:34 PM, [email protected] <[email protected]> wrote:
On 18 Sep 2015 at 11:27:33, Marius Dumitru Florea ([email protected](mailto:[email protected])) wrote:
On Thu, Sep 17, 2015 at 3:10 PM, [email protected] wrote:
On 17 Sep 2015 at 13:32:28, Eduard Moraru ([email protected](mailto:[email protected])) wrote:
With the introduction of Nested Spaces / Nested Documents, we find ourselves having to expand our terminology to accommodate the tree-like structure of spaces/documents that we are managing.
IMO, we have started going in the wrong direction with using standard tree terminology directly in XWiki's UI, introducing new terms that simple users could be easily confused by or overwhelmed (this adding to the already existing ones).
The specific issue I have in mind is how do we refer child entities for each concept (wiki, space, page) and how does this scale when the hierarchy increases.
What I propose is that we Keep It SSimple (*™*) :) and just use the "sub" prefix for the concept at hand.
Examples: * wiki -> subwiki (here we can continue using "wiki", as discussed previously [1], since we don`t actually support nested wikis yet, but if "subwiki" is used in a conversation it still makes perfect sense) * space -> subspace [2] * page -> subpage [3]
The problem with the term "child", as pointed out by Marius in an offline chat, has indeed the issue that it can only be applied correctly for first level descendants, after which it becomes inaccurate, since starting with the second level the term "descendant" is more appropriate.
I’m not sure about this. I think Children could be used generically to mean any level of Children but would need to be checked.
If you have A.B.C:
* the "Children" viewer (live table) will show "B, C" for A
I think right now it also shows A but this could be fixed.
* the "Siblings" viewer (live table) will show only "B" (or nothing?) for B
There’s no sibling for C in your definition.
Yes, I know what siblings are :) but I said "for B" not "for C".
If you had: A.B.C A.B.D A.E
Then the sibling for A.B.C would be A.B.D. Thus if you’re on A.B.C and ask for Sibling you’ll see D in the LT.
If you’re on A.B and ask for siblings you’ll see only E (and not E, C, D since C and D are not siblings of A.B).
So you don't think that the statement "E and C are both children of A but they are not siblings because they don't have he same parent" is confusing?
Thanks -Vincent
So B and C are both children of A but are not siblings. That can be confusing. You need the tree view to see the actual hierarchy.
Thanks, Marius
All of this becomes unnecessarily complicated and, IMO, we should avoid dealing with it by using the "sub" prefix which is much easier to grasp and accept.
On a similar note, I also find the term "nested" to be a bit unnecessarily complicated, specially for non-technical and non-english native users.
WDYT?
I don’t like the “Sub" terminology because it’s incomplete. It’s not complete because you still need words for Parents, Siblings, Root, etc.
I'd much prefer to use a standard Tree terminology: https://en.wikipedia.org/wiki/Tree_(data_structure)#Terminologies_used_in_Tr...
BTW Terminal Page could be replaced by Leaf Page if we wanted too but maybe that’s too technical?
I’d be ok to replace subwiki by Child Wiki/Children Wikis to be consistent.
So overall I find Child/Children, Parent, and Siblings very easy to understand by any simple user. I find that using Sub, Parent, Siblings is not better (and it would certainly not replace Sibling).
WDYT?
Thanks -Vincent
Thanks, Eduard
---------- [1] http://markmail.org/message/cehvpds5qmljq5f7 [2] https://en.wikipedia.org/wiki/Subspace [3] https://en.wikipedia.org/wiki/Subpage
_______________________________________________ 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 18 Sep 2015 at 11:51:21, Marius Dumitru Florea ([email protected](mailto:[email protected])) wrote:
On Fri, Sep 18, 2015 at 12:34 PM, [email protected] wrote:
On 18 Sep 2015 at 11:27:33, Marius Dumitru Florea ([email protected](mailto:[email protected])) wrote:
On Thu, Sep 17, 2015 at 3:10 PM, [email protected] wrote:
On 17 Sep 2015 at 13:32:28, Eduard Moraru ([email protected](mailto:[email protected])) wrote:
With the introduction of Nested Spaces / Nested Documents, we find ourselves having to expand our terminology to accommodate the tree-like structure of spaces/documents that we are managing.
IMO, we have started going in the wrong direction with using standard tree terminology directly in XWiki's UI, introducing new terms that simple users could be easily confused by or overwhelmed (this adding to the already existing ones).
The specific issue I have in mind is how do we refer child entities for each concept (wiki, space, page) and how does this scale when the hierarchy increases.
What I propose is that we Keep It SSimple (*™*) :) and just use the "sub" prefix for the concept at hand.
Examples: * wiki -> subwiki (here we can continue using "wiki", as discussed previously [1], since we don`t actually support nested wikis yet, but if "subwiki" is used in a conversation it still makes perfect sense) * space -> subspace [2] * page -> subpage [3]
The problem with the term "child", as pointed out by Marius in an offline chat, has indeed the issue that it can only be applied correctly for first level descendants, after which it becomes inaccurate, since starting with the second level the term "descendant" is more appropriate.
I’m not sure about this. I think Children could be used generically to mean any level of Children but would need to be checked.
If you have A.B.C:
* the "Children" viewer (live table) will show "B, C" for A
I think right now it also shows A but this could be fixed.
* the "Siblings" viewer (live table) will show only "B" (or nothing?) for B
There’s no sibling for C in your definition.
Yes, I know what siblings are :) but I said "for B" not "for C".
If you had: A.B.C A.B.D A.E
Then the sibling for A.B.C would be A.B.D. Thus if you’re on A.B.C and ask for Sibling you’ll see D in the LT.
If you’re on A.B and ask for siblings you’ll see only E (and not E, C, D since C and D are not siblings of A.B).
So you don't think that the statement
"E and C are both children of A but they are not siblings because they don't have he same parent"
is confusing?
I guess it depends how you consider Children. If you consider it to mean Children, grand-children, grand-grand-children, etc and use it as a general means, I guess it’s fine. I don’t know if this is acceptable in English or not. What I know is that if you say “Enfants” in French it can mean either immediate Children or all the children in the hierarchy (grand-children, grand-grand-children). Said differently, I have the feeling it’s better to have a More Actions menu entry named “Children” than having one named “Descendants” because I feel Children is a term more used. Thanks -Vincent
Thanks -Vincent
So B and C are both children of A but are not siblings. That can be confusing. You need the tree view to see the actual hierarchy.
Thanks, Marius
All of this becomes unnecessarily complicated and, IMO, we should avoid dealing with it by using the "sub" prefix which is much easier to grasp and accept.
On a similar note, I also find the term "nested" to be a bit unnecessarily complicated, specially for non-technical and non-english native users.
WDYT?
I don’t like the “Sub" terminology because it’s incomplete. It’s not complete because you still need words for Parents, Siblings, Root, etc.
I'd much prefer to use a standard Tree terminology: https://en.wikipedia.org/wiki/Tree_(data_structure)#Terminologies_used_in_Tr...
BTW Terminal Page could be replaced by Leaf Page if we wanted too but maybe that’s too technical?
I’d be ok to replace subwiki by Child Wiki/Children Wikis to be consistent.
So overall I find Child/Children, Parent, and Siblings very easy to understand by any simple user. I find that using Sub, Parent, Siblings is not better (and it would certainly not replace Sibling).
WDYT?
Thanks -Vincent
Thanks, Eduard
---------- [1] http://markmail.org/message/cehvpds5qmljq5f7 [2] https://en.wikipedia.org/wiki/Subspace [3] https://en.wikipedia.org/wiki/Subpage
In the XPath terminology for example, children are immediate descendant of a node. The grand-children and grand-grand-children (etc.) are called descendants. http://www.w3schools.com/xsl/xpath_nodes.asp My 2cts. PS: And in French, when you say "ce sont les enfants de M. Truc", it's only about immediate descendant, not about grand-children. On 18/09/2015 12:00, [email protected] wrote:
On 18 Sep 2015 at 11:51:21, Marius Dumitru Florea ([email protected](mailto:[email protected])) wrote:
On Fri, Sep 18, 2015 at 12:34 PM, [email protected] wrote:
On 18 Sep 2015 at 11:27:33, Marius Dumitru Florea ([email protected](mailto:[email protected])) wrote:
On Thu, Sep 17, 2015 at 3:10 PM, [email protected] wrote:
On 17 Sep 2015 at 13:32:28, Eduard Moraru ([email protected](mailto:[email protected])) wrote:
With the introduction of Nested Spaces / Nested Documents, we find ourselves having to expand our terminology to accommodate the tree-like structure of spaces/documents that we are managing.
IMO, we have started going in the wrong direction with using standard tree terminology directly in XWiki's UI, introducing new terms that simple users could be easily confused by or overwhelmed (this adding to the already existing ones).
The specific issue I have in mind is how do we refer child entities for each concept (wiki, space, page) and how does this scale when the hierarchy increases.
What I propose is that we Keep It SSimple (*™*) :) and just use the "sub" prefix for the concept at hand.
Examples: * wiki -> subwiki (here we can continue using "wiki", as discussed previously [1], since we don`t actually support nested wikis yet, but if "subwiki" is used in a conversation it still makes perfect sense) * space -> subspace [2] * page -> subpage [3]
The problem with the term "child", as pointed out by Marius in an offline chat, has indeed the issue that it can only be applied correctly for first level descendants, after which it becomes inaccurate, since starting with the second level the term "descendant" is more appropriate.
I’m not sure about this. I think Children could be used generically to mean any level of Children but would need to be checked.
If you have A.B.C:
* the "Children" viewer (live table) will show "B, C" for A
I think right now it also shows A but this could be fixed.
* the "Siblings" viewer (live table) will show only "B" (or nothing?) for B
There’s no sibling for C in your definition.
Yes, I know what siblings are :) but I said "for B" not "for C".
If you had: A.B.C A.B.D A.E
Then the sibling for A.B.C would be A.B.D. Thus if you’re on A.B.C and ask for Sibling you’ll see D in the LT.
If you’re on A.B and ask for siblings you’ll see only E (and not E, C, D since C and D are not siblings of A.B).
So you don't think that the statement
"E and C are both children of A but they are not siblings because they don't have he same parent"
is confusing?
I guess it depends how you consider Children. If you consider it to mean Children, grand-children, grand-grand-children, etc and use it as a general means, I guess it’s fine. I don’t know if this is acceptable in English or not. What I know is that if you say “Enfants” in French it can mean either immediate Children or all the children in the hierarchy (grand-children, grand-grand-children).
Said differently, I have the feeling it’s better to have a More Actions menu entry named “Children” than having one named “Descendants” because I feel Children is a term more used.
Thanks -Vincent
Thanks -Vincent
So B and C are both children of A but are not siblings. That can be confusing. You need the tree view to see the actual hierarchy.
Thanks, Marius
All of this becomes unnecessarily complicated and, IMO, we should avoid dealing with it by using the "sub" prefix which is much easier to grasp and accept.
On a similar note, I also find the term "nested" to be a bit unnecessarily complicated, specially for non-technical and non-english native users.
WDYT?
I don’t like the “Sub" terminology because it’s incomplete. It’s not complete because you still need words for Parents, Siblings, Root, etc.
I'd much prefer to use a standard Tree terminology: https://en.wikipedia.org/wiki/Tree_(data_structure)#Terminologies_used_in_Tr...
BTW Terminal Page could be replaced by Leaf Page if we wanted too but maybe that’s too technical?
I’d be ok to replace subwiki by Child Wiki/Children Wikis to be consistent.
So overall I find Child/Children, Parent, and Siblings very easy to understand by any simple user. I find that using Sub, Parent, Siblings is not better (and it would certainly not replace Sibling).
WDYT?
Thanks -Vincent
Thanks, Eduard
---------- [1] http://markmail.org/message/cehvpds5qmljq5f7 [2] https://en.wikipedia.org/wiki/Subspace [3] https://en.wikipedia.org/wiki/Subpage
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jean Simard [email protected] Research engineer at XWiki SAS http://www.xwiki.com Committer on the XWiki.org project http://www.xwiki.org
Hi Jean, On 18 Sep 2015 at 12:05:22, Jean SIMARD ([email protected](mailto:[email protected])) wrote:
In the XPath terminology for example, children are immediate descendant of a node. The grand-children and grand-grand-children (etc.) are called descendants.
http://www.w3schools.com/xsl/xpath_nodes.asp
My 2cts.
PS: And in French, when you say "ce sont les enfants de M. Truc", it's only about immediate descendant, not about grand-children.
Check definition 3 of https://fr.wiktionary.org/wiki/enfant "(Par extension) Descendant direct et indirect. Nous sommes tous enfants d’Adam.” Thanks -Vincent
On 18/09/2015 12:00, [email protected] wrote:
On 18 Sep 2015 at 11:51:21, Marius Dumitru Florea ([email protected](mailto:[email protected])) wrote:
On Fri, Sep 18, 2015 at 12:34 PM, [email protected] wrote:
On 18 Sep 2015 at 11:27:33, Marius Dumitru Florea ([email protected](mailto:[email protected])) wrote:
On Thu, Sep 17, 2015 at 3:10 PM, [email protected] wrote:
On 17 Sep 2015 at 13:32:28, Eduard Moraru ([email protected](mailto:[email protected])) wrote:
> With the introduction of Nested Spaces / Nested Documents, we find > ourselves having to expand our terminology to accommodate the tree-like > structure of spaces/documents that we are managing. > > IMO, we have started going in the wrong direction with using standard tree > terminology directly in XWiki's UI, introducing new terms that simple users > could be easily confused by or overwhelmed (this adding to the already > existing ones). > > The specific issue I have in mind is how do we refer child entities for > each concept (wiki, space, page) and how does this scale when the hierarchy > increases. > > What I propose is that we Keep It SSimple (*™*) :) and just use the "sub" > prefix for the concept at hand. > > Examples: > * wiki -> subwiki (here we can continue using "wiki", as discussed > previously [1], since we don`t actually support nested wikis yet, but if > "subwiki" is used in a conversation it still makes perfect sense) > * space -> subspace [2] > * page -> subpage [3] > > The problem with the term "child", as pointed out by Marius in an offline > chat, has indeed the issue that it can only be applied correctly for first > level descendants, after which it becomes inaccurate, since starting with > the second level the term "descendant" is more appropriate.
I’m not sure about this. I think Children could be used generically to mean any level of Children but would need to be checked.
If you have A.B.C:
* the "Children" viewer (live table) will show "B, C" for A
I think right now it also shows A but this could be fixed.
* the "Siblings" viewer (live table) will show only "B" (or nothing?) for B
There’s no sibling for C in your definition.
Yes, I know what siblings are :) but I said "for B" not "for C".
If you had: A.B.C A.B.D A.E
Then the sibling for A.B.C would be A.B.D. Thus if you’re on A.B.C and ask for Sibling you’ll see D in the LT.
If you’re on A.B and ask for siblings you’ll see only E (and not E, C, D since C and D are not siblings of A.B).
So you don't think that the statement
"E and C are both children of A but they are not siblings because they don't have he same parent"
is confusing?
I guess it depends how you consider Children. If you consider it to mean Children, grand-children, grand-grand-children, etc and use it as a general means, I guess it’s fine. I don’t know if this is acceptable in English or not. What I know is that if you say “Enfants” in French it can mean either immediate Children or all the children in the hierarchy (grand-children, grand-grand-children).
Said differently, I have the feeling it’s better to have a More Actions menu entry named “Children” than having one named “Descendants” because I feel Children is a term more used.
Thanks -Vincent
Thanks -Vincent
So B and C are both children of A but are not siblings. That can be confusing. You need the tree view to see the actual hierarchy.
Thanks, Marius
> > All of this becomes unnecessarily complicated and, IMO, we should avoid > dealing with it by using the "sub" prefix which is much easier to grasp and > accept. > > On a similar note, I also find the term "nested" to be a bit unnecessarily > complicated, specially for non-technical and non-english native users. > > WDYT?
I don’t like the “Sub" terminology because it’s incomplete. It’s not complete because you still need words for Parents, Siblings, Root, etc.
I'd much prefer to use a standard Tree terminology: https://en.wikipedia.org/wiki/Tree_(data_structure)#Terminologies_used_in_Tr...
BTW Terminal Page could be replaced by Leaf Page if we wanted too but maybe that’s too technical?
I’d be ok to replace subwiki by Child Wiki/Children Wikis to be consistent.
So overall I find Child/Children, Parent, and Siblings very easy to understand by any simple user. I find that using Sub, Parent, Siblings is not better (and it would certainly not replace Sibling).
WDYT?
Thanks -Vincent
> Thanks, > Eduard > > ---------- > [1] http://markmail.org/message/cehvpds5qmljq5f7 > [2] https://en.wikipedia.org/wiki/Subspace > [3] https://en.wikipedia.org/wiki/Subpage
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jean Simard [email protected] Research engineer at XWiki SAS http://www.xwiki.com Committer on the XWiki.org project http://www.xwiki.org _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 18/09/2015 12:08, [email protected] wrote:
Hi Jean,
On 18 Sep 2015 at 12:05:22, Jean SIMARD ([email protected](mailto:[email protected])) wrote:
In the XPath terminology for example, children are immediate descendant of a node. The grand-children and grand-grand-children (etc.) are called descendants.
http://www.w3schools.com/xsl/xpath_nodes.asp
My 2cts.
PS: And in French, when you say "ce sont les enfants de M. Truc", it's only about immediate descendant, not about grand-children.
Check definition 3 of https://fr.wiktionary.org/wiki/enfant
"(Par extension) Descendant direct et indirect. Nous sommes tous enfants d’Adam.” Yep, and also
2. Fils ou fille, de tout âge, par relation au père et à la mère, ou à l’un des deux seulement. So the meaning of "enfant" depends on the context and can be used in both cases (only immediate childrens or all the descendants). Just wanted to say to be careful to base a conclusion on an incomplete information.
Thanks -Vincent
On 18/09/2015 12:00, [email protected] wrote:
On 18 Sep 2015 at 11:51:21, Marius Dumitru Florea ([email protected](mailto:[email protected])) wrote:
On Fri, Sep 18, 2015 at 12:34 PM, [email protected] wrote:
On 18 Sep 2015 at 11:27:33, Marius Dumitru Florea ([email protected](mailto:[email protected])) wrote:
On Thu, Sep 17, 2015 at 3:10 PM, [email protected] wrote: > > > > > > On 17 Sep 2015 at 13:32:28, Eduard Moraru ([email protected](mailto:[email protected])) wrote: > >> With the introduction of Nested Spaces / Nested Documents, we find >> ourselves having to expand our terminology to accommodate the tree-like >> structure of spaces/documents that we are managing. >> >> IMO, we have started going in the wrong direction with using standard tree >> terminology directly in XWiki's UI, introducing new terms that simple users >> could be easily confused by or overwhelmed (this adding to the already >> existing ones). >> >> The specific issue I have in mind is how do we refer child entities for >> each concept (wiki, space, page) and how does this scale when the hierarchy >> increases. >> >> What I propose is that we Keep It SSimple (*™*) :) and just use the "sub" >> prefix for the concept at hand. >> >> Examples: >> * wiki -> subwiki (here we can continue using "wiki", as discussed >> previously [1], since we don`t actually support nested wikis yet, but if >> "subwiki" is used in a conversation it still makes perfect sense) >> * space -> subspace [2] >> * page -> subpage [3] >> >> The problem with the term "child", as pointed out by Marius in an offline >> chat, has indeed the issue that it can only be applied correctly for first >> level descendants, after which it becomes inaccurate, since starting with >> the second level the term "descendant" is more appropriate. >
> I’m not sure about this. I think Children could be used generically to mean any level of Children but would need to be checked.
If you have A.B.C:
* the "Children" viewer (live table) will show "B, C" for A
I think right now it also shows A but this could be fixed.
* the "Siblings" viewer (live table) will show only "B" (or nothing?) for B
There’s no sibling for C in your definition.
Yes, I know what siblings are :) but I said "for B" not "for C".
If you had: A.B.C A.B.D A.E
Then the sibling for A.B.C would be A.B.D. Thus if you’re on A.B.C and ask for Sibling you’ll see D in the LT.
If you’re on A.B and ask for siblings you’ll see only E (and not E, C, D since C and D are not siblings of A.B).
So you don't think that the statement
"E and C are both children of A but they are not siblings because they don't have he same parent"
is confusing?
I guess it depends how you consider Children. If you consider it to mean Children, grand-children, grand-grand-children, etc and use it as a general means, I guess it’s fine. I don’t know if this is acceptable in English or not. What I know is that if you say “Enfants” in French it can mean either immediate Children or all the children in the hierarchy (grand-children, grand-grand-children).
Said differently, I have the feeling it’s better to have a More Actions menu entry named “Children” than having one named “Descendants” because I feel Children is a term more used.
Thanks -Vincent
Thanks -Vincent
So B and C are both children of A but are not siblings. That can be confusing. You need the tree view to see the actual hierarchy.
Thanks, Marius
>> >> All of this becomes unnecessarily complicated and, IMO, we should avoid >> dealing with it by using the "sub" prefix which is much easier to grasp and >> accept. >> >> On a similar note, I also find the term "nested" to be a bit unnecessarily >> complicated, specially for non-technical and non-english native users. >> >> WDYT? > > I don’t like the “Sub" terminology because it’s incomplete. It’s not complete because you still need words for Parents, Siblings, Root, etc. > > I'd much prefer to use a standard Tree terminology: https://en.wikipedia.org/wiki/Tree_(data_structure)#Terminologies_used_in_Tr... > > BTW Terminal Page could be replaced by Leaf Page if we wanted too but maybe that’s too technical? > > I’d be ok to replace subwiki by Child Wiki/Children Wikis to be consistent. > > So overall I find Child/Children, Parent, and Siblings very easy to understand by any simple user. I find that using Sub, Parent, Siblings is not better (and it would certainly not replace Sibling). > > WDYT? > > Thanks > -Vincent > >> Thanks, >> Eduard >> >> ---------- >> [1] http://markmail.org/message/cehvpds5qmljq5f7 >> [2] https://en.wikipedia.org/wiki/Subspace >> [3] https://en.wikipedia.org/wiki/Subpage >
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jean Simard [email protected] Research engineer at XWiki SAS http://www.xwiki.com Committer on the XWiki.org project http://www.xwiki.org _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jean Simard [email protected] Research engineer at XWiki SAS http://www.xwiki.com Committer on the XWiki.org project http://www.xwiki.org
On 18 Sep 2015 at 12:15:19, Jean SIMARD ([email protected](mailto:[email protected])) wrote:
On 18/09/2015 12:08, [email protected] wrote:
Hi Jean,
On 18 Sep 2015 at 12:05:22, Jean SIMARD ([email protected](mailto:[email protected])) wrote:
In the XPath terminology for example, children are immediate descendant of a node. The grand-children and grand-grand-children (etc.) are called descendants.
http://www.w3schools.com/xsl/xpath_nodes.asp
My 2cts.
PS: And in French, when you say "ce sont les enfants de M. Truc", it's only about immediate descendant, not about grand-children.
Check definition 3 of https://fr.wiktionary.org/wiki/enfant
"(Par extension) Descendant direct et indirect. Nous sommes tous enfants d’Adam.” Yep, and also
You said “yep" but when you said “it's **only** about immediate descendant, **not** about grand-children.” then you didn’t agree obviously. So it’s good you changed your mind! :)
2. Fils ou fille, de tout âge, par relation au père et à la mère, ou à l’un des deux seulement.
So the meaning of "enfant" depends on the context and can be used in both cases (only immediate childrens or all the descendants). Just wanted to say to be careful to base a conclusion on an incomplete information.
err… I’ve mentioned this exactly in my previous answer, so I’m having a hard time to understand your point. I said: " I guess it depends how you consider Children. If you consider it to mean Children, grand-children, grand-grand-children, etc and use it as a general means, I guess it’s fine. I don’t know if this is acceptable in English or not. What I know is that if you say “Enfants” in French it can mean either immediate Children or all the children in the hierarchy (grand-children, grand-grand-children). Said differently, I have the feeling it’s better to have a More Actions menu entry named “Children” than having one named “Descendants” because I feel Children is a term more used. “ Am I missing something? :) Thanks -Vincent
Thanks -Vincent
On 18/09/2015 12:00, [email protected] wrote:
On 18 Sep 2015 at 11:51:21, Marius Dumitru Florea ([email protected](mailto:[email protected])) wrote:
On Fri, Sep 18, 2015 at 12:34 PM, [email protected] wrote:
On 18 Sep 2015 at 11:27:33, Marius Dumitru Florea ([email protected](mailto:[email protected])) wrote:
> On Thu, Sep 17, 2015 at 3:10 PM, [email protected] wrote: >> >> >> >> >> >> On 17 Sep 2015 at 13:32:28, Eduard Moraru ([email protected](mailto:[email protected])) wrote: >> >>> With the introduction of Nested Spaces / Nested Documents, we find >>> ourselves having to expand our terminology to accommodate the tree-like >>> structure of spaces/documents that we are managing. >>> >>> IMO, we have started going in the wrong direction with using standard tree >>> terminology directly in XWiki's UI, introducing new terms that simple users >>> could be easily confused by or overwhelmed (this adding to the already >>> existing ones). >>> >>> The specific issue I have in mind is how do we refer child entities for >>> each concept (wiki, space, page) and how does this scale when the hierarchy >>> increases. >>> >>> What I propose is that we Keep It SSimple (*™*) :) and just use the "sub" >>> prefix for the concept at hand. >>> >>> Examples: >>> * wiki -> subwiki (here we can continue using "wiki", as discussed >>> previously [1], since we don`t actually support nested wikis yet, but if >>> "subwiki" is used in a conversation it still makes perfect sense) >>> * space -> subspace [2] >>> * page -> subpage [3] >>> >>> The problem with the term "child", as pointed out by Marius in an offline >>> chat, has indeed the issue that it can only be applied correctly for first >>> level descendants, after which it becomes inaccurate, since starting with >>> the second level the term "descendant" is more appropriate. >> > >> I’m not sure about this. I think Children could be used generically to mean any level of Children but would need to be checked. > > If you have A.B.C: > > * the "Children" viewer (live table) will show "B, C" for A
I think right now it also shows A but this could be fixed.
> * the "Siblings" viewer (live table) will show only "B" (or nothing?) for B
There’s no sibling for C in your definition.
Yes, I know what siblings are :) but I said "for B" not "for C".
If you had: A.B.C A.B.D A.E
Then the sibling for A.B.C would be A.B.D. Thus if you’re on A.B.C and ask for Sibling you’ll see D in the LT.
If you’re on A.B and ask for siblings you’ll see only E (and not E, C, D since C and D are not siblings of A.B).
So you don't think that the statement
"E and C are both children of A but they are not siblings because they don't have he same parent"
is confusing?
I guess it depends how you consider Children. If you consider it to mean Children, grand-children, grand-grand-children, etc and use it as a general means, I guess it’s fine. I don’t know if this is acceptable in English or not. What I know is that if you say “Enfants” in French it can mean either immediate Children or all the children in the hierarchy (grand-children, grand-grand-children).
Said differently, I have the feeling it’s better to have a More Actions menu entry named “Children” than having one named “Descendants” because I feel Children is a term more used.
Thanks -Vincent
Thanks -Vincent
> So B and C are both children of A but are not siblings. That can be > confusing. You need the tree view to see the actual hierarchy. > > Thanks, > Marius > >>> >>> All of this becomes unnecessarily complicated and, IMO, we should avoid >>> dealing with it by using the "sub" prefix which is much easier to grasp and >>> accept. >>> >>> On a similar note, I also find the term "nested" to be a bit unnecessarily >>> complicated, specially for non-technical and non-english native users. >>> >>> WDYT? >> >> I don’t like the “Sub" terminology because it’s incomplete. It’s not complete because you still need words for Parents, Siblings, Root, etc. >> >> I'd much prefer to use a standard Tree terminology: https://en.wikipedia.org/wiki/Tree_(data_structure)#Terminologies_used_in_Tr... >> >> BTW Terminal Page could be replaced by Leaf Page if we wanted too but maybe that’s too technical? >> >> I’d be ok to replace subwiki by Child Wiki/Children Wikis to be consistent. >> >> So overall I find Child/Children, Parent, and Siblings very easy to understand by any simple user. I find that using Sub, Parent, Siblings is not better (and it would certainly not replace Sibling). >> >> WDYT? >> >> Thanks >> -Vincent >> >>> Thanks, >>> Eduard >>> >>> ---------- >>> [1] http://markmail.org/message/cehvpds5qmljq5f7 >>> [2] https://en.wikipedia.org/wiki/Subspace >>> [3] https://en.wikipedia.org/wiki/Subpage >>
Hello. I think it's a good topic to discuss. 2015-09-17 13:32 GMT+02:00 Eduard Moraru <[email protected]>:
With the introduction of Nested Spaces / Nested Documents, we find ourselves having to expand our terminology to accommodate the tree-like structure of spaces/documents that we are managing.
IMO, we have started going in the wrong direction with using standard tree terminology directly in XWiki's UI, introducing new terms that simple users could be easily confused by or overwhelmed (this adding to the already existing ones).
The specific issue I have in mind is how do we refer child entities for each concept (wiki, space, page) and how does this scale when the hierarchy increases.
What I propose is that we Keep It SSimple (*™*) :) and just use the "sub" prefix for the concept at hand.
Examples: * wiki -> subwiki (here we can continue using "wiki", as discussed previously [1], since we don`t actually support nested wikis yet, but if "subwiki" is used in a conversation it still makes perfect sense) * space -> subspace [2] * page -> subpage [3]
The problem with the term "child", as pointed out by Marius in an offline chat, has indeed the issue that it can only be applied correctly for first level descendants, after which it becomes inaccurate, since starting with the second level the term "descendant" is more appropriate.
Then we should use "descendant", because the concept of subpage, for me, does not necessary cover more than one level in the hierarchy. The subpage of a subpage become a "subsubpage". The term "descendant" does not have this problem.
All of this becomes unnecessarily complicated and, IMO, we should avoid dealing with it by using the "sub" prefix which is much easier to grasp and accept.
On a similar note, I also find the term "nested" to be a bit unnecessarily complicated, specially for non-technical and non-english native users.
WDYT?
Thanks, Eduard
---------- [1] http://markmail.org/message/cehvpds5qmljq5f7 [2] https://en.wikipedia.org/wiki/Subspace [3] https://en.wikipedia.org/wiki/Subpage _______________________________________________ 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 Sep 2015 at 13:32:28, Eduard Moraru ([email protected](mailto:[email protected])) wrote:
With the introduction of Nested Spaces / Nested Documents, we find ourselves having to expand our terminology to accommodate the tree-like structure of spaces/documents that we are managing.
IMO, we have started going in the wrong direction with using standard tree terminology directly in XWiki's UI, introducing new terms that simple users could be easily confused by or overwhelmed (this adding to the already existing ones).
The specific issue I have in mind is how do we refer child entities for each concept (wiki, space, page) and how does this scale when the hierarchy increases.
What I propose is that we Keep It SSimple (*™*) :) and just use the "sub" prefix for the concept at hand.
Examples: * wiki -> subwiki (here we can continue using "wiki", as discussed previously [1], since we don`t actually support nested wikis yet, but if "subwiki" is used in a conversation it still makes perfect sense) * space -> subspace [2] * page -> subpage [3]
The problem with the term "child", as pointed out by Marius in an offline chat, has indeed the issue that it can only be applied correctly for first level descendants, after which it becomes inaccurate, since starting with the second level the term "descendant" is more appropriate.
All of this becomes unnecessarily complicated and, IMO, we should avoid dealing with it by using the "sub" prefix which is much easier to grasp and accept.
On a similar note, I also find the term "nested" to be a bit unnecessarily complicated, specially for non-technical and non-english native users.
On this point, I find it nice to be able to say “Nested Spaces” and understand what it means. What’s your recommendation? Saying “A Space contained inside of other Spaces” is bit too verbose when talking about the feature. Similary saying “A space with subspaces” or “A Space inside a Space” are too verbose too. Hierarchical Spaces would be another valid term but I find Nested Spaces easier to pronounce and we’ve started using it across the board and I don’t feel the cost of changing everywhere would justify the move to Hierarchical Spaces :) In addition this is not a term used in the UI so it’s mostly an issue for documentation (which doesn’t mean it’s not important). Thanks -Vincent
WDYT?
Thanks, Eduard
---------- [1] http://markmail.org/message/cehvpds5qmljq5f7 [2] https://en.wikipedia.org/wiki/Subspace [3] https://en.wikipedia.org/wiki/Subpage
On Thu, Sep 17, 2015 at 3:54 PM, [email protected] <[email protected]> wrote:
On 17 Sep 2015 at 13:32:28, Eduard Moraru ([email protected](mailto: [email protected])) wrote:
With the introduction of Nested Spaces / Nested Documents, we find ourselves having to expand our terminology to accommodate the tree-like structure of spaces/documents that we are managing.
IMO, we have started going in the wrong direction with using standard tree terminology directly in XWiki's UI, introducing new terms that simple users could be easily confused by or overwhelmed (this adding to the already existing ones).
The specific issue I have in mind is how do we refer child entities for each concept (wiki, space, page) and how does this scale when the hierarchy increases.
What I propose is that we Keep It SSimple (*™*) :) and just use the "sub" prefix for the concept at hand.
Examples: * wiki -> subwiki (here we can continue using "wiki", as discussed previously [1], since we don`t actually support nested wikis yet, but if "subwiki" is used in a conversation it still makes perfect sense) * space -> subspace [2] * page -> subpage [3]
The problem with the term "child", as pointed out by Marius in an offline chat, has indeed the issue that it can only be applied correctly for first level descendants, after which it becomes inaccurate, since starting with the second level the term "descendant" is more appropriate.
All of this becomes unnecessarily complicated and, IMO, we should avoid dealing with it by using the "sub" prefix which is much easier to grasp and accept.
On a similar note, I also find the term "nested" to be a bit unnecessarily complicated, specially for non-technical and non-english native users.
On this point, I find it nice to be able to say “Nested Spaces” and understand what it means.
What’s your recommendation? Saying “A Space contained inside of other Spaces” is bit too verbose when talking about the feature. Similary saying “A space with subspaces” or “A Space inside a Space” are too verbose too.
Actually my intent was to minimise verbosity here as well. I was simply thinking of "subspace", since it is completely equivalent (in any way) with "Nested Space" and with the above mentioned verbose alternatives. Thanks, Eduard
Hierarchical Spaces would be another valid term but I find Nested Spaces easier to pronounce and we’ve started using it across the board and I don’t feel the cost of changing everywhere would justify the move to Hierarchical Spaces :)
In addition this is not a term used in the UI so it’s mostly an issue for documentation (which doesn’t mean it’s not important).
Thanks -Vincent
WDYT?
Thanks, Eduard
---------- [1] http://markmail.org/message/cehvpds5qmljq5f7 [2] https://en.wikipedia.org/wiki/Subspace [3] https://en.wikipedia.org/wiki/Subpage
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (5)
-
Eduard Moraru -
Guillaume "Louis-Marie" Delhumeau -
Jean SIMARD -
Marius Dumitru Florea -
vincent＠massol.net