See below. On 03/07/2015 09:56, [email protected] wrote: > Hi Jean, > > See below > > On 2 Jul 2015 at 15:43:56, Jean SIMARD > ([email protected](mailto:[email protected])) 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). > > 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, [email protected] wrote: >> > >> > >> > On 2 Jul 2015 at 13:49:01, Jean SIMARD >> > ([email protected](mailto:[email protected])) 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, [email protected] wrote: >> >> > >> >> > >> >> > On 2 Jul 2015 at 11:37:49, Jean SIMARD >> >> > ([email protected](mailto:[email protected])) 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, [email protected] wrote: >> >> >> > >> >> >> > On 2 Jul 2015 at 11:06:42, Jean SIMARD >> >> >> > ([email protected](mailto:[email protected])) 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 [email protected] Research engineer at XWiki SAS http://www.xwiki.com Committer on the XWiki.org project http://www.xwiki.org _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
