24 Jun
2015
24 Jun
'15
3:29 p.m.
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*
gabriela.smeria(a)xwiki.com
skype: smeria.gabriela
On Wed, Jun 24, 2015 at 3:41 PM, Ecaterina Moraru (Valica) <
valicac(a)gmail.com> wrote:
On Tue, Jun 23, 2015 at 6:43 PM, Ecaterina Moraru
(Valica) <
valicac(a)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.
+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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs