24 Jun
2015
24 Jun
'15
3:55 p.m.
Hi,
On Wed, Jun 24, 2015 at 9:28 AM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
On 24 Jun 2015 at 07:45:20, vincent(a)massol.net (vincent(a)massol.net(mailto:
vincent(a)massol.net)) wrote:
give
only have
1 breadcrumb at a time!
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.
If I understood your intent correctly, this was one of the first ideas I
discussed with Caty as well. Basically, the highlights were:
1. Do not migrate
** => Preserves URLs
** => Preserves existing internal hierarchy/structure
2. Change the way breadcrumbs work by rebranding the "parent-child"
relationship to "parent override"
** By default, we show the NS path in the breadcrumbs, but still allow
setting a parent (in edit mode) to be able to override the breadcrumbs.
*** This allows existing (not migrated) documents to keep their breadcrumbs
that were created only with parent-child
*** New documents go with the default but, if the user really wants to, he
can short-circuit the displayed breadcrumbs by setting a parent override
*** The downside of this is that the work needed to display the breadcrumbs
will be a bit more costly, since we need to consider path overrides when
walking up the path hierarchy, for each element of the path, while also
avoiding possible cycles.
**** E.g: X > Y > B > C is computed by looking at C's parent. If it is not
set, walk up the path hierarchy to B (C's space in NS or C's parent
document in ND). For B, look at its parent. If it is set to (Y), display
it. Now look at Y's parent, which is not set so walk up Y's path hierarchy
and reach and display X. In this example, C's full path was A.B.C, meaning
that B's parent override (Y) has overridden the breadcrumbs of C from A>B>C
(based only on the path/NS) to X>Y>B>C (computed from path + parent
override).
*** The second downside of this is that, for an app, it becomes more
complicated to get the parent of a document. Which parent does it get, the
path parent or the user-percieved parent (which includes overrides and
which are costly to compute?).
On 23 Jun 2015 at 17:44:01, Ecaterina Moraru (Valica) (valicac(a)gmail.com
(mailto:valicac@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 > 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.
one has to
go away and since we’ve agreed on NS, it has to be Parent/Child
going away.
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
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 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 From a user's POV, it`s quite a nice compromise,
specially when considering
upgrades/migrations. It might also be interesting from a
technical POV, but
I`ll let you be the judges of that.
You can also see this as a breadcrumbs customization tool that has the
added benefit that it solves the migration issues. You can also see it as
an option (parent editing) that is disabled by default, but can be enabled
by admins that are migrating.
Just detailing it to better see the implications of this approach.
Thanks,
Eduard
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Please cast your votes / add comments.
Thank you,
Caty
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs