Hello, Here are my votes:
Q0: +1 Q1.1: +1 Q1.1.1: +0 Q1.2: -0 Q2.1: -1 Q2.1.1: -1 Q2.1.2: +0 Q2.2: +1 Q2.2.1: +0 Thanks, Gabriela *Gabriela Smeria* *Web Developer* [email protected] skype: smeria.gabriela On Wed, Jun 24, 2015 at 3:41 PM, Ecaterina Moraru (Valica) < [email protected]> wrote: > On Tue, Jun 23, 2015 at 6:43 PM, Ecaterina Moraru (Valica) < > [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. > > > > +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. > > > > +1 > > > > Q1.1.1 A consequence is hiding the 'WebHome' name in the UI. > > > > +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 We would need to create UI alternatives for several components. This > means additional work for a feature that will be used by very few people, > but we would need to assure the testing of it. I think removing Space as a > concept from the UI will simplify the concepts. Extensions can be custom > developed and added in e.x.o, but I don't see why we should provide the > configuration by default. > > > > > > Q2. **Parent/Child** > > > > So apparently this is the main problem we still need to decide. The issue > is that maybe we have different definitions on the word 'deprecate'. > > > > > > Q2.1 Deprecate the notion of Parent/Child. > > 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 I don't agree to make this kind of migration automatically for all > users. As Vincent said maybe we could provide some optional script, but not > sure about that either. > > > > 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. > > 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.) > > > > -0 IMO this is not something that can be done very easy. With the current > UI proposal, if we replace the NS/ND hierarchy with the Parent/Child, and > without the global menu, the user will not know it's location (except by > looking at the URL). How will he navigate to its current wiki or space? > Magic like have a fallback on NS if Parent/Child is empty, will confuse the > user and won't provide additional insight. > > > So IMO there are 2 ways to view the Parent/Child deprecation: > 1. If we think only about Nested Documents, than the answer is straight > forward. Just deprecate the Parent/Child. There is no need to have 2 > concepts that do the same thing. > > 2. If we think about the long URL then the problem is a bit different. If > we deprecate the Parent/Child and we will want to switch to an ID > implementation and move the hierarchy to another metadata, than the > deprecation of Parent/Child field mean a step backwards towards this > direction. > > > What I know about 1) and Parent/Child is that: > We shouldn't display both concepts in the UI. This means the breadcrumbs > will display the NS/ND, but the Parent/Child data would still be preserved > in the database for backwards compatibility reasons. If someone used the > Parent/Child concept, he should develop additional extensions to present > this information. But at least the Parent/Child field will not be removed / > reused / transformed automatically in URLs. > > So I guess I'm voting +1 to Q2.2 Don't deprecate the notion of > Parent/Child: a.k.a do not consider it totally deprecated, but we should > NOT display it in the UI for the NS/ND implementation. Not sure if it makes > sense. > > Thanks, > Caty > > > > > > > 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
