Hi, Especially for a groupware/workspaces use case I think is very important to mark specially the main wiki, and display it as a parent for the other wikis. For a farm use case, the main wiki will not be displayed on subwikis and the home icon will represent the local wiki homepage (but in theory the main wiki is still a parent wiki). Regarding consistency, I think breadcrumbs and trees should reflect the same hierarchy. They should not be different and their representation should reinforce the organization of pages everytime an user is using one or the other. We cannot have discrepancies between them, because users will be confused and will always try to process why there are differences between the representations. Also is not like breadcrumbs and trees are distinct displayers. With the http://jira.xwiki.org/browse/XWIKI-12430 proposal, they will be tightly related so consistency is a must. Thanks, Caty On Mon, Aug 24, 2015 at 4:09 PM, vincent@massol.net <vincent@massol.net> wrote:

On 24 Aug 2015 at 14:21:19, Marius Dumitru Florea ( mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) 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.

Thanks -Vincent

...

Thanks, Marius

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

On 2 Sep 2015 at 13:34:27, Marius Dumitru Florea (mariusdumitru.florea@xwiki.com) wrote: On Mon, Aug 24, 2015 at 4:09 PM, vincent@massol.net <vincent@massol.net> wrote:

On 24 Aug 2015 at 14:21:19, Marius Dumitru Florea (mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) 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

On Wed, Sep 2, 2015 at 4:15 PM, Eduard Moraru <enygma2002@gmail.com> 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, vincent@massol.net <vincent@massol.net> wrote:

...

On 2 Sep 2015 at 13:34:27, Marius Dumitru Florea ( mariusdumitru.florea@xwiki.com) wrote:

On Mon, Aug 24, 2015 at 4:09 PM, vincent@massol.net <vincent@massol.net> wrote:

...

On 24 Aug 2015 at 14:21:19, Marius Dumitru Florea (

mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) 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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

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 <enygma2002@gmail.com> 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 < mariusdumitru.florea@xwiki.com> wrote:

...

On Wed, Sep 2, 2015 at 4:15 PM, Eduard Moraru <enygma2002@gmail.com> 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, vincent@massol.net <vincent@massol.net

...

wrote:

...

On 2 Sep 2015 at 13:34:27, Marius Dumitru Florea ( mariusdumitru.florea@xwiki.com) wrote:

On Mon, Aug 24, 2015 at 4:09 PM, vincent@massol.net <

vincent@massol.net

...

wrote:

...

On 24 Aug 2015 at 14:21:19, Marius Dumitru Florea (

mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com )) 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 devs@xwiki.org 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 devs@xwiki.org 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 devs@xwiki.org 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 devs@xwiki.org 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>

On Mon, Sep 14, 2015 at 6:36 PM, Guillaume "Louis-Marie" Delhumeau <gdelhumeau@xwiki.com> wrote:

2015-09-14 17:42 GMT+02:00 Guillaume Lerouge <guillaume@xwiki.com>:

...

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

That is wrong. The rights DO inherit between the main wiki sub-wikis, at least since the Denis' module has been written.

Yes rights are is inherited since 4.0. Most authenticators also usually fallback on main wiki. So right now there is a hierarchy relationship between main wiki and sub-wikis at least in several important places.

...

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 <enygma2002@gmail.com> 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 < mariusdumitru.florea@xwiki.com> wrote:

...

On Wed, Sep 2, 2015 at 4:15 PM, Eduard Moraru <enygma2002@gmail.com> 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, vincent@massol.net < vincent@massol.net

...

wrote:

...

On 2 Sep 2015 at 13:34:27, Marius Dumitru Florea ( mariusdumitru.florea@xwiki.com) wrote:

On Mon, Aug 24, 2015 at 4:09 PM, vincent@massol.net <

vincent@massol.net

...

wrote: > > > > > > On 24 Aug 2015 at 14:21:19, Marius Dumitru Florea ( mariusdumitru.florea@xwiki.com(mailto: mariusdumitru.florea@xwiki.com )) 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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs < https://mailtrack.io/trace/link/5cdaba15b1a0ee796e40340be950c6540850990f?url...

...

...

...

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs < https://mailtrack.io/trace/link/5cdaba15b1a0ee796e40340be950c6540850990f?url...

...

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs < https://mailtrack.io/trace/link/5cdaba15b1a0ee796e40340be950c6540850990f?url...

...

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs < https://mailtrack.io/trace/link/5cdaba15b1a0ee796e40340be950c6540850990f?url...

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

-- Guillaume Delhumeau (gdelhumeau@xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne

  On 15 Sep 2015 at 11:59:03, Ecaterina Moraru (Valica) (valicac@gmail.com(mailto:valicac@gmail.com)) wrote:

On Mon, Sep 14, 2015 at 6:42 PM, Guillaume Lerouge wrote:

...

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.

The reason IMO to want to create a sub-wiki is to have custom applications installed and isolate/dedicate the subwiki to a team. For any other reason, create a space :)

Another reason is if you want to delegate the administration (choose the skin, color theme, permissions, etc). Thanks -Vincent  

...

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 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 < mariusdumitru.florea@xwiki.com> wrote:

...

On Wed, Sep 2, 2015 at 4:15 PM, Eduard Moraru 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, vincent@massol.net < vincent@massol.net

...

wrote:

...

On 2 Sep 2015 at 13:34:27, Marius Dumitru Florea ( mariusdumitru.florea@xwiki.com) wrote:

On Mon, Aug 24, 2015 at 4:09 PM, vincent@massol.net <

vincent@massol.net

...

wrote: > > > > > > On 24 Aug 2015 at 14:21:19, Marius Dumitru Florea ( mariusdumitru.florea@xwiki.com(mailto: mariusdumitru.florea@xwiki.com )) 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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs < https://mailtrack.io/trace/link/5cdaba15b1a0ee796e40340be950c6540850990f?url...

...

...

...

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs < https://mailtrack.io/trace/link/5cdaba15b1a0ee796e40340be950c6540850990f?url...

...

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs < https://mailtrack.io/trace/link/5cdaba15b1a0ee796e40340be950c6540850990f?url...

...

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs < https://mailtrack.io/trace/link/5cdaba15b1a0ee796e40340be950c6540850990f?url...

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Hi, my main point was that in our current paradigm, there can be both spaces in the main wiki AND sub-wikis listed under the main wiki home page in the breadcrumb, which creates a consistency issue that isn't easy to fix. On Tue, Sep 15, 2015 at 1:03 PM, Guillaume "Louis-Marie" Delhumeau < gdelhumeau@xwiki.com> wrote:

2015-09-15 12:02 GMT+02:00 vincent@massol.net <vincent@massol.net>:

...

On 15 Sep 2015 at 11:59:03, Ecaterina Moraru (Valica) (valicac@gmail.com (mailto:valicac@gmail.com)) wrote:

...

On Mon, Sep 14, 2015 at 6:42 PM, Guillaume Lerouge wrote:

...

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

Thanks for the clarification on this, I didn't know that rights from the main wiki were inherited by subwikis.

...

...

...

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.

The reason IMO to want to create a sub-wiki is to have custom applications installed and isolate/dedicate the subwiki to a team. For any other reason, create a space :)

So if the marketing team wants their own app, they get a sub-wiki, but the sales team which didn't need an app got a space, and then you need to switch them to their own wiki?

...

Another reason is if you want to delegate the administration (choose the skin, color theme, permissions, etc).

Nope, you can do that in a space too.

To me it's still not so clear when one should be chosen and not the other :-) Guillaume

Thanks

...

-Vincent

...

...

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

[SNIP]