Hi,
I've been thinking a lot about this (while also considering the discussion
about the "Main" space in the other discussion thread). To me, ideally,
there is one and only one hierarchy, which is consistent everywhere. As
discussed at length already, this poses a challenge for at several reasons:
1. Technically, there is no hierarchy relationship between the main wiki
and sub-wikis. However, in practice the main wiki often plays the role of a
portal.
1. This means that rights will not be inherited between the main wiki
and sub-wikis, which poses a coherency issue
2. Having a global breadcrumb puts 2 different things at the same level
under the home page of the main wiki: top-level spaces in the main wiki on
one hand, sub-wiki home pages on the other hand
1. This is solved for some implementations by simply having one wiki,
without any sub-wikis, and relying only on the nested spaces mechanism to
handle things
2. A potential converse would be to have just a global home page,
then use sub-wikis for everything (effectively eliminating the
portal), but
this would cause myriad of issues when using the global search, accessing
user profiles and so on.
In the end, I think what this boils down to is an ongoing conflict between
2 ways of organizing information inside of XWiki:
1. The Farm paradigm, where you create sub-wikis for everything
2. The Nested Spaces paradigm, where you have just one big wiki with
spaces, sub-spaces and so on
On a daily basis, it's already difficult to tell users when they should
create a sub-wiki versus a space. This is going to be even harder with
Nested Spaces. In my view, many of our discussions come from a tension
between these 2 ways of organizing content inside of XWiki.
Obviously, going all in for one of these 2 ways would make choices much
simpler for the future but cause a retro-compatibility nightmare... All
this to say that I'm not sure which compromise is best for the breadcrumb
:-)
Food for thought,
Guillaume
On Wed, Sep 2, 2015 at 5:07 PM, Eduard Moraru <[email protected]> wrote:
> Because of the "Subwikis" pseudo-element? Even so, still looks better in
> that direction.
>
> In any way, I am not sure we even want to (or even can) be 100% consistent
> with the breadcrumbs, because the breadcrumbs only show a single path in
> the tree and does not care about scaling horizontally in the tree hierarchy
> (i.e. siblings). However, an actual tree view would suffer from the
> scalability issues you`ve mentioned because the root can have both subwikis
> and documents as it's first level children, so I believe a compromise is
> inevitable.
>
> ATM we have these 2 options:
>
> 1. Lose the hierarchy between the main wiki and display it as a regular
> subwiki, and the user should guess (or find out through some visual cues,
> like an icon or something... or simply because of the name) that one of
> them is the main wiki. There would also be scalability issues in finding
> the main wiki amongst 30 other wikis. Sure, search/filtering would be a
> solution, but I am afraid that such an operation would be language
> dependent (searching for a translated string).
> 1.1 Note that we would also lose the breadcrumb's hierarchy information for
> subwikis, since we would not be showing the main wiki in te breadcrumbs any
> more, to be consistent with the tree. A sort of revert to what we were
> previously doing.
>
> 2. Lose a fraction of the consistency by having the extra "Subwikis" (or
> call it whatever we want) pseudo-element showing up in the tree that will
> not be displayed in the breadcrumbs, though I am not sure anybody would
> want/like to see such an entry in the breadcrumbs of any subwiki document.
>
> Other ideas?
>
> That's all I got right now.
>
> Thanks,
> Eduard
>
> On Wed, Sep 2, 2015 at 4:19 PM, Marius Dumitru Florea <
> [email protected]> wrote:
>
> > On Wed, Sep 2, 2015 at 4:15 PM, Eduard Moraru <[email protected]>
> > wrote:
> > > Would this be viewed as an improvement?
> > >
> > > Home
> > > |-- Subwikis
> > > |---- Sub Wiki 1
> > > |---- Sub Wiki 2
> > > |---- ...
> > > |---- Sub Wiki N
> > > |-- Document 1
> > > |-- Document 2
> > > |-- ...
> > > |-- Document N
> > >
> > > ...same logic we apply for objects, and attachments in a document.
> >
> > Still not consistent with the breadcrumb.
> >
> > >
> > > Of course, when displaying the tree only for Sub Wiki X (isolated),
> there
> > > would be no "Subwikis" entry as first child. That would be the
> difference
> > > when displaying a subwiki or when displaying the main wiki.
> > >
> > > I`m not 100% on this, just mentioning a possibility.
> > >
> > > Thanks,
> > > Eduard
> > >
> > > On Wed, Sep 2, 2015 at 3:22 PM, [email protected] <[email protected]
> >
> > > wrote:
> > >
> > >>
> > >>
> > >>
> > >> On 2 Sep 2015 at 13:34:27, Marius Dumitru Florea (
> > >> [email protected]) wrote:
> > >>
> > >> On Mon, Aug 24, 2015 at 4:09 PM, [email protected] <
> [email protected]
> > >
> > >> wrote:
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On 24 Aug 2015 at 14:21:19, Marius Dumitru Florea (
> > >> [email protected](mailto:[email protected]
> ))
> > >> wrote:
> > >> >
> > >> >> Hi devs,
> > >> >>
> > >> >> I recently discussed with Edy about how the breadcrumb should look
> > and
> > >> >> there may be an inconsistency with the hierarchy displayed by the
> > >> >> document tree.
> > >> >>
> > >> >> Breadcrumb on the main wiki:
> > >> >>
> > >> >> Home Icon (pointing to the main wiki home page) / MDoc1 / MDoc2 /
> > ... /
> > >> MDocX
> > >> >>
> > >> >> Breadcrumb on a subwiki (that has only global users):
> > >> >>
> > >> >> Home Icon (pointing to the main wiki home page) / Subwiki Pretty
> Name
> > >> >> (pointing to the subwiki home page) / SDoc1 / SDoc2 / ... / SDocX
> > >> >>
> > >> >> After seeing the breadcrumbs both on the main wiki and on a subwiki
> > >> >> the user might think that the document MDoc1 and the wiki "Subwiki
> > >> >> Pretty Name" are on the same level: both children of the main wiki.
> > >> >>
> > >> >> Next if the user tries the document tree macro using:
> > >> >>
> > >> >> {{documentTree showWikis="true" /}}
> > >> >>
> > >> >> he will notice that "Subwiki Pretty Name" is not actually a child
> of
> > >> >> the main wiki but a top level node (a child of the "farm"), on the
> > >> >> same level with the main wiki.
> > >> >>
> > >> >> Can this be considered as an inconsistency? In our model (e.g.
> > >> >> document reference) there is no hierarchy between wikis, although,
> as
> > >> >> Edy pointed out, there are places where we consider the main wiki
> to
> > >> >> be the "parent" of the subwikis (e.g. in the authorization module,
> by
> > >> >> inheriting access rights from the main wiki).
> > >> >>
> > >> >> WDYT? Is the main wiki the parent of the subwikis or just a
> sibling?
> > >> >
> > >> > Good question and indeed we need to decide what we want to do since
> we
> > >> have the 2 options.
> > >> >
> > >> > Personally I think it’s interesting to mark the main wiki as special
> > >> since it is special (accounts there are different than on subwikis) so
> > I’d
> > >> be in favor of considering subwikis as children of the main wiki.
> > >> >
> > >> >> Should the breadcrumb be synchronized with the tree?
> > >> >
> > >>
> > >> > I’d say the other way around. The tree should probably show the main
> > >> wiki as the parent of all subwikis. And when there’s only one wiki (ie
> > the
> > >> main wiki), we could simply not show the wiki level for simplicity. We
> > >> could also decide to open the tree to the level below the main wiki by
> > >> default so that users don’t have to open it themselves.
> > >>
> > >> I find it strange to display:
> > >>
> > >> Home
> > >> |-- Sub Wiki 1
> > >> |-- Sub Wiki 2
> > >> |-- ...
> > >> |-- Sub Wiki N
> > >> |-- Document 1
> > >> |-- Document 2
> > >> |-- ...
> > >> |-- Document N
> > >>
> > >> Not to mention the pagination. If there are too many subwikis then you
> > >> may not see the documents initially. I much prefer the current
> > >> display.
> > >> I would find it painful to have to open the tree for nodes that you
> need
> > >> to open anyway.
> > >>
> > >> Another idea: when you click on Document Index from a menu, the Tree
> > opens
> > >> on the current doc.
> > >>
> > >> Thanks
> > >>
> > >> -Vincent
> > >>
> > >>
> > >>
> > >> Thanks,
> > >> Marius
> > >>
> > >> >
> > >> > Thanks
> > >> > -Vincent
> > >> >
> > >> >>
> > >> >> Thanks,
> > >> >> Marius
> > >> _______________________________________________
> > >> devs mailing list
> > >> [email protected]
> > >> http://lists.xwiki.org/mailman/listinfo/devs
> <https://mailtrack.io/trace/link/5cdaba15b1a0ee796e40340be950c6540850990f?url=http%3A%2F%2Flists.xwiki.org%2Fmailman%2Flistinfo%2Fdevs&signature=5e2b6f767b5ff9fb>
> > >>
> > > _______________________________________________
> > > devs mailing list
> > > [email protected]
> > > http://lists.xwiki.org/mailman/listinfo/devs
> <https://mailtrack.io/trace/link/5cdaba15b1a0ee796e40340be950c6540850990f?url=http%3A%2F%2Flists.xwiki.org%2Fmailman%2Flistinfo%2Fdevs&signature=5e2b6f767b5ff9fb>
> > _______________________________________________
> > devs mailing list
> > [email protected]
> > http://lists.xwiki.org/mailman/listinfo/devs
> <https://mailtrack.io/trace/link/5cdaba15b1a0ee796e40340be950c6540850990f?url=http%3A%2F%2Flists.xwiki.org%2Fmailman%2Flistinfo%2Fdevs&signature=5e2b6f767b5ff9fb>
> >
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
> <https://mailtrack.io/trace/link/5cdaba15b1a0ee796e40340be950c6540850990f?url=http%3A%2F%2Flists.xwiki.org%2Fmailman%2Flistinfo%2Fdevs&signature=5e2b6f767b5ff9fb>
>
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
