On Thu, Sep 17, 2015 at 3:59 PM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
On 17 Sep 2015 at 14:51:32, Eduard Moraru (enygma2002(a)gmail.com(mailto:
enygma2002(a)gmail.com)) 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=…
* Subspace(s): 830,000 results
https://www.google.com/webhp?hl=en#safe=off&hl=en&q=%2B%28%22subspa…
* define: subspace
https://www.google.com/search?q=define&ie=utf-8&oe=utf-8#safe=off&a…
* 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, 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
>
> > 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs