On Wed, Jun 24, 2015 at 4:55 PM, Eduard Moraru <[email protected]> wrote:
> Hi, > > On Wed, Jun 24, 2015 at 9:28 AM, [email protected] <[email protected]> > wrote: > > > > > > > > > On 24 Jun 2015 at 07:45:20, [email protected] ([email protected] > (mailto: > > [email protected])) wrote: > > > > > > > > > > > > > > > > > > > > On 23 Jun 2015 at 17:44:01, Ecaterina Moraru (Valica) ( > [email protected] > > (mailto:[email protected])) 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. > > > > > 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?). > > 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. > So this idea solve some of the technical problems: like migrations and keeps the parent/child data, but I think is too complex from the user point of view. It will be super magic ... and no one will know what partial path they need to fix if there is a problem in the hierarchy. Hierarchies should use just one type of relation in order to be correctly displayed. There might be some wikis that have the parent/child data created by accident and without value to the user and we might display it. Anyway, our main problem is that we don't have enough parent/child relation usage. Thanks, Caty > > 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 > > > > > > > Please cast your votes / add comments. > > > > > > > > Thank you, > > > > Caty > > > _______________________________________________ > > > devs mailing list > > > [email protected] > > > http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
