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#HDocumentHierarchyTree
> > . 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
