24 Jun
2015
24 Jun
'15
4:54 p.m.
Hi,
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.
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.)
Tough choice... migrating or not simple documents to ND, either all at
once, or one by one as we need ND operations on them, etc... create or not
new simple documents, etc.
-0
Q2. **Parent/Child**
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].
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.)
Most likely, URLs are very important: bookmarks, SEO campaigns, etc. and we
can`t control their usage, so IMO we should focus on not forcing anyone to
change them.
For this, I would be more in favor of Q2.1.2 (+0.5).
Regarding the deprecation of P-C, i.e. stop using it in our UIs, stop
setting parents for new documents automatically, remove the UI option to
edit the parent, I would be in favor (+0.5) of that as well, of course,
unless we do the "path overrides" thing, which implies we don`t deprecate,
but re-purpose it.
Q2.2.1: More options is not always better, but it is always a source of
more possible bugs :) IMO the option we should focus on, if we go that
path, is between 2.1.1 and 2.1.2 and it should be made by the admin
upgrading, based on the usecase his wiki serves and on what is more
important to him. It is clear that we can not make the choice, since we
would end up losing data and that is never acceptable from an user's POV.
Thanks,
Eduard
Please cast your votes / add comments.
Thank you,
Caty
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs