On 24 Jun 2015 at 07:45:20, vinc...@massol.net
(vinc...@massol.net(mailto:vinc...@massol.net)) wrote:
>
>
>
>
>
> On 23 Jun 2015 at 17:44:01, Ecaterina Moraru (Valica)
> (vali...@gmail.com(mailto:vali...@gmail.com)) wrote:
>
> > Hi devs,
> >
> > So after discussing the topic of Nested in several mails, we need to reach
> > a conclusion in order to start implementing.
> >
> > There are several open questions that I will summarize. Please cast your
> > votes in order to advance on some topics and maybe discover what we still
> > need to agree on.
> >
> > Q0. **Nested Spaces in model**
> >
> > No matter the UI decisions we still need to take, we are implementing
> > Nested Spaces for 7.2 roadmap. The future is still uncertain regarding
> > changing the model to accommodate Nested Documents, since we can simulate
> > ND using NS.
>
> Already decided, +1
>
> > Q1. **NS vs ND in the UI**
> >
> > Q1.1 The majority agreed that since the final purpose are ND, we should
> > display ND in the UI, since it simplifies the mental model of the user.
> > This implies removing the Space concept from the UI.
>
> Already decided, +1
>
> > Q1.1.1 A consequence is hiding the 'WebHome' name in the UI.
>
> Already decided, +1
>
> > Q1.2 Although the default should be ND, the question is if we want to give
> > the option to display NS in the UI. This would be implemented as an
> > advanced and technical option. The main problem is that we might need to
> > provide UI alternatives for several components (menus, create step, etc.)
>
> -0 but would like to have Anca’s opinion on the related thread.
>
> > Q2. **Parent/Child**
> >
> > Q2.1 Deprecate the notion of Parent/Child.
>
> +1 because it’s too confusing to have both the NS and Parent/Child so one has
> to go away and since we’ve agreed on NS, it has to be Parent/Child going away.
>
> Note that deprecating doesn’t mean removing it! It just tells users that they
> need to move away from it over time as it’s no longer the way to do it.
>
> > Q2.1.1 Provide a migration to transform the relation into NS/ND. Problem:
> > the old URLs[A] (bookmarks) are broken + the user is stuck with long
> > URLs[B] if he wants to keep the hierarchy. Additionally we might need to
> > provide an extension/configuration to transform into short URLs [B -> C].
>
> +1, we need to help users migrate from Parent/Child to NS anyway since we’ve
> agreed about NS. However this is not au automated migration; it would be some
> scripts that users can run if they want to.
>
> > Q2.1.2 Don't migrate: the parent/child hierarchy will be lost but the old
> > URLs[A] (bookmarks) will be kept. The user needs to use NS/ND to create
> > hierarchies.
> >
> > Q2.2 Don't deprecate the notion of Parent/Child.
>
> -0 as I said it’s too confusing to have both at the same time and we can only
> have 1 breadcrumb at a time!
>
> > Q2.2.1 Provide a configuration in the Administration to switch the
> > breadcrumbs between displaying Parent/Child or NS/ND. We might need to
> > provide UI alternatives for several components (tree, breadcrumb
> > navigation, create, etc.)
>
> +1 to let users time to migrate.
>
> I don’t agree with the reasoning of “let’s keep parent/child and have NS at
> the same time”. It’s just too confusing and we’ll need to fix this before we
> can consider the feature finished anyway (like having a breadcrumb based on
> NS).
The problem with having the breadcrumb based on parent/child is that when you
create a new document inside a nested space and you save you see an empty
breadcrumb and you have to set the parent explicitly thus duplicating the
effort.
One idea to help with this could be to use NS in the breadcrumb when the
current doc doesn’t have any parent set. This would let users migrate more
smoothly, although it could increase confusion. To help, we could display two
different icons in the breadcrumb to show when it’s based on NS and when it’s
based on Parent/Child.
Thanks
-Vincent
>
> I’m fine to do it later in 7.2 but IMO it has to be done un 7.2 because we
> don’t want *new* users to start using parent/child relationship once NS is
> implemented.
>
> We have to bite the bullet and better sooner than later.
>
> Thanks
> -Vincent
>
> > Please cast your votes / add comments.
> >
> > Thank you,
> > Caty
> _______________________________________________
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
