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, vincent(a)massol.net <vincent(a)massol.net>
wrote:
On 17 Sep 2015 at 13:32:28, Eduard Moraru (enygma2002(a)gmail.com(mailto:
enygma2002(a)gmail.com)) 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_T…
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs