Hi again, I’ve thought more about it (and discussed it with Jean Simard) and here’s my new take: - There are different use cases: ** The case of the AllDocs page where it’s important to display the location since it’s used for navigation ** The case of an App that creates only terminal pages. In this case we shouldn’t display the location since it’s not needed. ** The case of an App that allows to create non terminal pages (e.g. A Project Application which allows you to create projects inside projects inside projects, etc). In this case it’s useful to be able to display the location *relative* to the top level Space in which the App is located. - Thus it’s important to be able to configure how you wish to display an xproperty of type “Document Reference”. Thus, ideally, we need to find a way to pass some configuration data to the “Document Reference” property Displayer and to configure that in the livetable macro. - The alternative, which is fine with me, is to have a computed “Location” xproperty (which is computed from a “Document Reference” xproperty) and the declaration of the “Location” xproperty metadata would define how it’s displayed (full reference, reference relative to a given reference, etc), and the Displayer for “Location” would use that. This means always using a “Location” column in LT when you wish to display the path. This last solution is probably the simplest and should solve the 3 UCs I’ve listed above. WDYT? Thanks -Vincent On 2 Jul 2015 at 00:33:23, vincent@massol.net (vincent@massol.net(mailto:vincent@massol.net)) wrote:

Hi Caty,

Thanks for the design page!

Some remarks:

* For Sol2 do you mean you just display the parent and not the full hierarchy? So for example for A.B.C.D.WebHome you’d display parent = D only? Thus sol2 wouldn’t allow to understand the location of a page. * My preference goes to Sol3 with the full hierarchy displayed and with a filter allowing to search in either the page name/title and/or the hierarchy. It should solve the 3 listed UCs * We could imagine variations of sol3 depending on the use case by showing/hiding the hierarchy and if hidden then it would be shown on hover (but the filter should allow to filter on it) * I think we need to work on the filter UI so that it allows to search only on the name+title or only on the hierarchy or on both. It could be 2 filter fields or one field that searches on all with options (as in google search or solr search) to specify to search only in the title, only in the page name, only in the hierarchy: -title:xxx, +title:xxx, +name=xxx, -name:xxx, +location:xxx, -location:xxx), etc. * If we display page titles, we’ll need to implement that famous title cache we’ve been wanting to have for such a long time now… ;) http://jira.xwiki.org/browse/XWIKI-1253

Thanks -Vincent

On 2 Jul 2015 at 00:04:36, Ecaterina Moraru (Valica) (valicac@gmail.com(mailto:valicac@gmail.com)) wrote:

...

Hi,

I've added some ideas on how to display 'Space' column in the AllDocs page: http://design.xwiki.org/xwiki/bin/view/Proposal/NestedLivetable

Let me know what you think and if there are other ideas.

Thanks, Caty

Hi, Summary for the expressed opinions: [Iteration 1] Sol1: +0 Gabi, +0 Jean (with modifications) Sol2: +1 Caty, +0 Gabi, +0 Jean (with modifications) Sol3: +1 Vincent, +1 Jean, +1 Gabi (with modifications) Sol4: +0 Caty, +0 Jean [Iteration 2] Sol 2.1.3: +1 Caty On Fri, Jul 3, 2015 at 8:04 PM, Ecaterina Moraru (Valica) <valicac@gmail.com

wrote:

Hi,

Thanks for all the feedback received.

Since the received feedback favored Sol 2 and Sol 3, I've iterated a bit on them, see http://design.xwiki.org/xwiki/bin/view/Proposal/NestedLivetable#HIteration2

Thanks, Caty

On Fri, Jul 3, 2015 at 6:48 PM, vincent@massol.net <vincent@massol.net> wrote:

...

Hi again,

I’ve thought more about it (and discussed it with Jean Simard) and here’s my new take:

- There are different use cases: ** The case of the AllDocs page where it’s important to display the location since it’s used for navigation ** The case of an App that creates only terminal pages. In this case we shouldn’t display the location since it’s not needed. ** The case of an App that allows to create non terminal pages (e.g. A Project Application which allows you to create projects inside projects inside projects, etc). In this case it’s useful to be able to display the location *relative* to the top level Space in which the App is located.

- Thus it’s important to be able to configure how you wish to display an xproperty of type “Document Reference”. Thus, ideally, we need to find a way to pass some configuration data to the “Document Reference” property Displayer and to configure that in the livetable macro.

- The alternative, which is fine with me, is to have a computed “Location” xproperty (which is computed from a “Document Reference” xproperty) and the declaration of the “Location” xproperty metadata would define how it’s displayed (full reference, reference relative to a given reference, etc), and the Displayer for “Location” would use that. This means always using a “Location” column in LT when you wish to display the path.

This last solution is probably the simplest and should solve the 3 UCs I’ve listed above.

WDYT?

Thanks -Vincent

On 2 Jul 2015 at 00:33:23, vincent@massol.net (vincent@massol.net(mailto: vincent@massol.net)) wrote:

...

Hi Caty,

Thanks for the design page!

Some remarks:

* For Sol2 do you mean you just display the parent and not the full hierarchy? So for example for A.B.C.D.WebHome you’d display parent = D only? Thus sol2 wouldn’t allow to understand the location of a page. * My preference goes to Sol3 with the full hierarchy displayed and with a filter allowing to search in either the page name/title and/or the hierarchy. It should solve the 3 listed UCs * We could imagine variations of sol3 depending on the use case by showing/hiding the hierarchy and if hidden then it would be shown on hover (but the filter should allow to filter on it) * I think we need to work on the filter UI so that it allows to search only on the name+title or only on the hierarchy or on both. It could be 2 filter fields or one field that searches on all with options (as in google search or solr search) to specify to search only in the title, only in the page name, only in the hierarchy: -title:xxx, +title:xxx, +name=xxx, -name:xxx, +location:xxx, -location:xxx), etc. * If we display page titles, we’ll need to implement that famous title cache we’ve been wanting to have for such a long time now… ;) http://jira.xwiki.org/browse/XWIKI-1253

Thanks -Vincent

On 2 Jul 2015 at 00:04:36, Ecaterina Moraru (Valica) (valicac@gmail.com (mailto:valicac@gmail.com)) wrote:

...

Hi,

I've added some ideas on how to display 'Space' column in the AllDocs page: http://design.xwiki.org/xwiki/bin/view/Proposal/NestedLivetable

Let me know what you think and if there are other ideas.

Thanks, Caty

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

Note: we currently have not the ability to filter on documents' title. The livetable performs queries on the database level. In the database, the title is stored as raw content and so is not rendered (it could be a velocity code that displays a translation key for example). Even if we add a title cache, we would still not be able to filter on it and on the database in the same time. Unless we store this title cache on the database, which may not be desirable. Anyway, this modification seems too important for the 7.2rc1 time frame. So I suggest to not display the page title on the livetable. It means we cannot implement the solution 2.1.2 and 2.1.3 yet. WDYT? Thanks, -- Guillaume Delhumeau (gdelhumeau@xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

On 2 Jul 2015 at 11:06:42, Jean SIMARD (jean.simard@xwiki.com(mailto:jean.simard@xwiki.com)) wrote:

Nice work.

However, something stroke me when reading that, why do we still want livetable with nested? The tree seems the best way to represent hierarchical structure of documents (as you say in sol4) so I'm not sure to understand the real reason to try to keep a livetable and not completely drop it and focus on tree view. OK, that is my opinion.

That’s an interesting idea but how do you present data (the other columns) in a tree view, with filters? Thanks -Vincent

Now, to talk about your proposition, I guess sol2 or sol3 are fine (I would go more for sol3).

For another solution, maybe you could mixin sol3 with a bit of sol1. Let me explain. Use Sol3 but instead of displaying only parent, display the minify breadcrumb. And fall back to "only parent" on mobile with a small icon next to it to display the complete path in a popup or something similar (or use this icon on every device and forget about minify breadcrumb). Don't know if it makes sense.

Hope this helps.

On 02/07/2015 00:04, Ecaterina Moraru (Valica) wrote:

...

Hi,

I've added some ideas on how to display 'Space' column in the AllDocs page: http://design.xwiki.org/xwiki/bin/view/Proposal/NestedLivetable

Let me know what you think and if there are other ideas.

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

-- Jean Simard jean.simard@xwiki.com Research engineer at XWiki SAS http://www.xwiki.com Committer on the XWiki.org project http://www.xwiki.org _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

On 2 Jul 2015 at 11:37:49, Jean SIMARD (jean.simard@xwiki.com(mailto:jean.simard@xwiki.com)) wrote:

Filters seems a good idea.

For example, I'm pretty sure I've almost never used this livetable without typing something into the search fields of one of the columns. It means that first I'm filtering, and then I'm browsing. Therefore, filtering the tree view first and then browse as a tree would be pretty in line with this workflow. It indeed means that you don't display data (author and date mainly) but you filter on them.

But the main point of LT in general is to display these data! :) Ok maybe you were talking about a tree *only* for this page, while I’m talking about LT in general for all use cases. If you don’t display them you loose the rationale and you loose the ability to decide on what to filter too…

But of course, I'm aware that the work on trees may be more complex, more difficult to do. So livetable could be considered as a viable temporary solution (let's choose one of the solution that doesn't imply a lot of work in this case ^^).

I don’t see it as temporary, at least not till someone proposes something better :) Thanks -Vincent

On 02/07/2015 11:17, vincent@massol.net wrote:

...

On 2 Jul 2015 at 11:06:42, Jean SIMARD (jean.simard@xwiki.com(mailto:jean.simard@xwiki.com)) wrote:

...

Nice work.

However, something stroke me when reading that, why do we still want livetable with nested? The tree seems the best way to represent hierarchical structure of documents (as you say in sol4) so I'm not sure to understand the real reason to try to keep a livetable and not completely drop it and focus on tree view. OK, that is my opinion.

That’s an interesting idea but how do you present data (the other columns) in a tree view, with filters?

Thanks -Vincent

...

Now, to talk about your proposition, I guess sol2 or sol3 are fine (I would go more for sol3).

For another solution, maybe you could mixin sol3 with a bit of sol1. Let me explain. Use Sol3 but instead of displaying only parent, display the minify breadcrumb. And fall back to "only parent" on mobile with a small icon next to it to display the complete path in a popup or something similar (or use this icon on every device and forget about minify breadcrumb). Don't know if it makes sense.

Hope this helps.

On 02/07/2015 00:04, Ecaterina Moraru (Valica) wrote:

...

Hi,

I've added some ideas on how to display 'Space' column in the AllDocs page: http://design.xwiki.org/xwiki/bin/view/Proposal/NestedLivetable

Let me know what you think and if there are other ideas.

Thanks, Caty

On 2 Jul 2015 at 13:49:01, Jean SIMARD (jean.simard@xwiki.com(mailto:jean.simard@xwiki.com)) wrote:

As an end-user, I mainly used LT to *find* elements (usually a document) and therefore, as a developer, I always used LT to provide a tool for end-users to access elements. In order for them to find these elements, either you display the data and then the end-user try to find what he's looking for (the way LT works today) or you provide a search engine (these filters we talked about).

So for example how would you imagine http://extensions.xwiki.org ? Right now it has a LT that can be used both for navigating to extensions and for searching. If you need searching in the content then you use the search page. I find that quite convenient. Thanks -Vincent

What do you think? LT is more a *find* tool or a *display* tool?

On 02/07/2015 11:41, vincent@massol.net wrote:

...

On 2 Jul 2015 at 11:37:49, Jean SIMARD (jean.simard@xwiki.com(mailto:jean.simard@xwiki.com)) wrote:

...

Filters seems a good idea.

For example, I'm pretty sure I've almost never used this livetable without typing something into the search fields of one of the columns. It means that first I'm filtering, and then I'm browsing. Therefore, filtering the tree view first and then browse as a tree would be pretty in line with this workflow. It indeed means that you don't display data (author and date mainly) but you filter on them.

But the main point of LT in general is to display these data! :)

Ok maybe you were talking about a tree *only* for this page, while I’m talking about LT in general for all use cases.

If you don’t display them you loose the rationale and you loose the ability to decide on what to filter too…

...

But of course, I'm aware that the work on trees may be more complex, more difficult to do. So livetable could be considered as a viable temporary solution (let's choose one of the solution that doesn't imply a lot of work in this case ^^).

I don’t see it as temporary, at least not till someone proposes something better :)

Thanks -Vincent

...

On 02/07/2015 11:17, vincent@massol.net wrote:

...

On 2 Jul 2015 at 11:06:42, Jean SIMARD (jean.simard@xwiki.com(mailto:jean.simard@xwiki.com)) wrote:

...

Nice work.

However, something stroke me when reading that, why do we still want livetable with nested? The tree seems the best way to represent hierarchical structure of documents (as you say in sol4) so I'm not

sure

...

...

to understand the real reason to try to keep a livetable and not completely drop it and focus on tree view. OK, that is my opinion.

That’s an interesting idea but how do you present data (the other columns) in a tree view, with filters?

Thanks -Vincent

...

Now, to talk about your proposition, I guess sol2 or sol3 are fine (I would go more for sol3).

For another solution, maybe you could mixin sol3 with a bit of sol1. Let me explain. Use Sol3 but instead of displaying only parent, display the minify breadcrumb. And fall back to "only parent" on mobile with a small icon next to it to display the complete path in a popup or something similar (or use this icon on every device and forget about minify breadcrumb). Don't know if it makes sense.

Hope this helps.

On 02/07/2015 00:04, Ecaterina Moraru (Valica) wrote:

...

Hi,

I've added some ideas on how to display 'Space' column in the AllDocs page: http://design.xwiki.org/xwiki/bin/view/Proposal/NestedLivetable

Let me know what you think and if there are other ideas.

Thanks, Caty

-- Jean Simard jean.simard@xwiki.com Research engineer at XWiki SAS http://www.xwiki.com Committer on the XWiki.org project http://www.xwiki.org _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Hi Jean, See below On 2 Jul 2015 at 15:43:56, Jean SIMARD (jean.simard@xwiki.com(mailto:jean.simard@xwiki.com)) wrote:

This is an interesting example. Let's get back a few seconds on the first mail of this thread. The topic was about how to integrate the nested concept into LT. If I paraphrase what I understand: how to display the complete path to a document in a LT (list of all spaces from ROOT to the document). But in this example (LT of extensions), the path is not an interesting information. I don't really care where this page is stored into the wiki (and I guess, you don't too, right?). What's important is the name of the extension, the category and a few other information.

So maybe the real question is: do we care about displaying "path" of a document in a LT? (and not, do we care to keep LT like I first said). It's still a bit fuzzy in my head but this is how I think about that at the moment: path is a technical information (therefore, useless for the end-user), but title of the page, category, author, etc. are meaningful information to the end-user. Does it make any sense to you?

Trying to imagine some use cases where this path is useful to the end-user (and not just technical), I got some (see below) but as you'll see, I'm not sure it should be the way to implement them:

1) Using Task Manager Application with Project Management Application, you could store all tasks of a project into a subspace (therefore the name of the subspace could be the name of the project 1.problem) Title of the project is probably already a field into the Project Management AWM and what you really want in the LT is this title, not the name of the sub-space (sub-space is only a technical solution to store tasks without colliding between projects)

2) With Blog Application, you store articles in a hierarchy of year/month/day. 2.problem) Indeed, the date is useful information but here again, I guess that you can already get the date from the document itself and therefore, it's only a technical solution for storage which is not very useful to the end-user.

Can you think about a real use case where you need this path? (I guess my brain is already to biased on the topic so help me!!!).

You need this path for all use cases actually since this is the only way you can identify the document name or title you’re looking at. If you have a document with the “Team” title, how do you know what it means? Is this the HR Team, the Product Team, the Research Team, etc. The only way to identify a document is by looking at its path. Otherwise you’re forced to have unique names and this is not something we wish to have. Thanks -Vincent

On 02/07/2015 14:08, vincent@massol.net wrote:

...

On 2 Jul 2015 at 13:49:01, Jean SIMARD (jean.simard@xwiki.com(mailto:jean.simard@xwiki.com)) wrote:

...

As an end-user, I mainly used LT to *find* elements (usually a document) and therefore, as a developer, I always used LT to provide a tool for end-users to access elements. In order for them to find these elements, either you display the data and then the end-user try to find what he's looking for (the way LT works today) or you provide a search engine (these filters we talked about).

So for example how would you imagine http://extensions.xwiki.org ?

Right now it has a LT that can be used both for navigating to extensions and for searching. If you need searching in the content then you use the search page.

I find that quite convenient.

Thanks -Vincent

...

What do you think? LT is more a *find* tool or a *display* tool?

On 02/07/2015 11:41, vincent@massol.net wrote:

...

On 2 Jul 2015 at 11:37:49, Jean SIMARD (jean.simard@xwiki.com(mailto:jean.simard@xwiki.com)) wrote:

...

Filters seems a good idea.

For example, I'm pretty sure I've almost never used this livetable without typing something into the search fields of one of the columns. It means that first I'm filtering, and then I'm browsing. Therefore, filtering the tree view first and then browse as a tree would be pretty in line with this workflow. It indeed means that you don't display data (author and date mainly) but you filter on them.

But the main point of LT in general is to display these data! :)

Ok maybe you were talking about a tree *only* for this page, while I’m talking about LT in general for all use cases.

If you don’t display them you loose the rationale and you loose the ability to decide on what to filter too…

...

But of course, I'm aware that the work on trees may be more complex, more difficult to do. So livetable could be considered as a viable temporary solution (let's choose one of the solution that doesn't imply a lot of work in this case ^^).

I don’t see it as temporary, at least not till someone proposes something better :)

Thanks -Vincent

...

On 02/07/2015 11:17, vincent@massol.net wrote:

...

On 2 Jul 2015 at 11:06:42, Jean SIMARD (jean.simard@xwiki.com(mailto:jean.simard@xwiki.com)) wrote:

> Nice work. > > However, something stroke me when reading that, why do we still want > livetable with nested? The tree seems the best way to represent > hierarchical structure of documents (as you say in sol4) so I'm not

sure

...

> to understand the real reason to try to keep a livetable and not > completely drop it and focus on tree view. OK, that is my opinion.

That’s an interesting idea but how do you present data (the other columns) in a tree view, with filters?

Thanks -Vincent

> Now, to talk about your proposition, I guess sol2 or sol3 are

fine (I

...

...

...

> would go more for sol3). > > For another solution, maybe you could mixin sol3 with a bit of sol1. > Let me explain. Use Sol3 but instead of displaying only parent, display > the minify breadcrumb. And fall back to "only parent" on mobile with a > small icon next to it to display the complete path in a popup or > something similar (or use this icon on every device and forget about > minify breadcrumb). Don't know if it makes sense. > > Hope this helps. > > > On 02/07/2015 00:04, Ecaterina Moraru (Valica) wrote: > > Hi, > > > > I've added some ideas on how to display 'Space' column in the AllDocs page: > > http://design.xwiki.org/xwiki/bin/view/Proposal/NestedLivetable > > > > Let me know what you think and if there are other ideas. > > > > Thanks, > > Caty

On 3 Jul 2015 at 11:22:52, Jean SIMARD (jean.simard@xwiki.com(mailto:jean.simard@xwiki.com)) wrote:

See below.

On 03/07/2015 09:56, vincent@massol.net wrote:

...

Hi Jean,

See below

On 2 Jul 2015 at 15:43:56, Jean SIMARD (jean.simard@xwiki.com(mailto:jean.simard@xwiki.com)) wrote:

...

This is an interesting example. Let's get back a few seconds on the first mail of this thread. The topic was about how to integrate the nested concept into LT. If I paraphrase what I understand: how to display the complete path to a document in a LT (list of all spaces from ROOT to the document). But in this example (LT of extensions), the path is not an interesting information. I don't really care where this page is stored into the wiki (and I guess, you don't too, right?). What's important is the name of the extension, the category and a few other information.

So maybe the real question is: do we care about displaying "path" of a document in a LT? (and not, do we care to keep LT like I first said). It's still a bit fuzzy in my head but this is how I think about that at the moment: path is a technical information (therefore, useless for the end-user), but title of the page, category, author, etc. are meaningful information to the end-user. Does it make any sense to you?

Trying to imagine some use cases where this path is useful to the end-user (and not just technical), I got some (see below) but as you'll see, I'm not sure it should be the way to implement them:

1) Using Task Manager Application with Project Management Application, you could store all tasks of a project into a subspace (therefore the name of the subspace could be the name of the project 1.problem) Title of the project is probably already a field into the Project Management AWM and what you really want in the LT is this title, not the name of the sub-space (sub-space is only a technical solution to store tasks without colliding between projects)

2) With Blog Application, you store articles in a hierarchy of year/month/day. 2.problem) Indeed, the date is useful information but here again, I guess that you can already get the date from the document itself and therefore, it's only a technical solution for storage which is not very useful to the end-user.

Can you think about a real use case where you need this path? (I guess my brain is already to biased on the topic so help me!!!).

You need this path for all use cases actually since this is the only way you can identify the document name or title you’re looking at. If you have a document with the “Team” title, how do you know what it means? Is this the HR Team, the Product Team, the Research Team, etc. The only way to identify a document is by looking at its path.

I don't understand. If these Team documents are different documents, even if the document name (not title) is the same (only the path differs), they will have different objects and/or have same objects (with different values in properties) and/or different titles. It is these information that you want to display in order to differentiate the lines in your livetable. If these document are exactly the same, I don't see the point to have clones of documents in a wiki (ok, it could happen but I don't feel like we should support this use case).

I think we might be talking about different things. I’m talking about the Index Main LT ATM. We don’t display objects in that table! And no objects is not what would differentiate those pages. It’s the content that would differentiate them in the majority of use cases. I’m really sorry but I fail to understand your points (been trying hard I assure you :)). And no, we’re not going to display all page contents in the LT just for the sake of identifying the documents! TBH I’m not sure anymore what’s your proposal about: - If your proposal is that LT can be replaced by Trees in general then I completely fail to see how that would be possible and you have shown a proposal that would work. - If your proposal is to replace only the Index Main LT by a Tree then I also fail to see what you would propose specifically. And note that we already have a Tree view in the Index page… - If your proposal is to say that the we don’t need to display the Path in the LT field that displays Document names, then I’m -1 because that’s the only way I know to fully identify the document (we could decide not to show it by default, to display it only on hover, etc but it has to be possible and easy for the user to see it). Thanks -Vincent

...

Otherwise you’re forced to have unique names and this is not something we wish to have.

Thanks -Vincent

...

On 02/07/2015 14:08, vincent@massol.net wrote:

...

On 2 Jul 2015 at 13:49:01, Jean SIMARD (jean.simard@xwiki.com(mailto:jean.simard@xwiki.com)) wrote:

...

As an end-user, I mainly used LT to *find* elements (usually a

document)

...

...

and therefore, as a developer, I always used LT to provide a tool for end-users to access elements. In order for them to find these elements, either you display the data and then the end-user try to find what he's looking for (the way LT works today) or you provide a search engine (these filters we talked about).

So for example how would you imagine http://extensions.xwiki.org ?

Right now it has a LT that can be used both for navigating to extensions and for searching. If you need searching in the content then you use the search page.

I find that quite convenient.

Thanks -Vincent

...

What do you think? LT is more a *find* tool or a *display* tool?

On 02/07/2015 11:41, vincent@massol.net wrote:

...

On 2 Jul 2015 at 11:37:49, Jean SIMARD (jean.simard@xwiki.com(mailto:jean.simard@xwiki.com)) wrote:

> Filters seems a good idea. > > For example, I'm pretty sure I've almost never used this livetable > without typing something into the search fields of one of the

columns.

...

> It means that first I'm filtering, and then I'm browsing. Therefore, > filtering the tree view first and then browse as a tree would be pretty > in line with this workflow. It indeed means that you don't display data > (author and date mainly) but you filter on them.

But the main point of LT in general is to display these data! :)

Ok maybe you were talking about a tree *only* for this page, while I’m talking about LT in general for all use cases.

If you don’t display them you loose the rationale and you loose the ability to decide on what to filter too…

> But of course, I'm aware that the work on trees may be more complex, > more difficult to do. So livetable could be considered as a viable > temporary solution (let's choose one of the solution that doesn't imply > a lot of work in this case ^^).

I don’t see it as temporary, at least not till someone proposes something better :)

Thanks -Vincent

> On 02/07/2015 11:17, vincent@massol.net wrote: > > > > On 2 Jul 2015 at 11:06:42, Jean SIMARD > > (jean.simard@xwiki.com(mailto:jean.simard@xwiki.com)) wrote: > > > >> Nice work. > >> > >> However, something stroke me when reading that, why do we still want > >> livetable with nested? The tree seems the best way to represent > >> hierarchical structure of documents (as you say in sol4) so I'm not sure > >> to understand the real reason to try to keep a livetable and not > >> completely drop it and focus on tree view. OK, that is my opinion. > > > > That’s an interesting idea but how do you present data (the other > > columns) in a tree view, with filters? > > > > Thanks > > -Vincent > > > >> Now, to talk about your proposition, I guess sol2 or sol3 are fine (I > >> would go more for sol3). > >> > >> For another solution, maybe you could mixin sol3 with a bit of sol1. > >> Let me explain. Use Sol3 but instead of displaying only parent, display > >> the minify breadcrumb. And fall back to "only parent" on mobile with a > >> small icon next to it to display the complete path in a popup or > >> something similar (or use this icon on every device and forget about > >> minify breadcrumb). Don't know if it makes sense. > >> > >> Hope this helps. > >> > >> > >> On 02/07/2015 00:04, Ecaterina Moraru (Valica) wrote: > >> > Hi, > >> > > >> > I've added some ideas on how to display 'Space' column in the > > AllDocs page: > >> > http://design.xwiki.org/xwiki/bin/view/Proposal/NestedLivetable > >> > > >> > Let me know what you think and if there are other ideas. > >> > > >> > Thanks, > >> > Caty

-- Jean Simard