2 Jul
2015
2 Jul
'15
3:43 p.m.
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!!!).
On 02/07/2015 14:08, vincent(a)massol.net wrote:
On 2 Jul 2015 at 13:49:01, Jean SIMARD
(jean.simard@xwiki.com(mailto:jean.simard@xwiki.com)) wrote:
--
Jean Simard
jean.simard(a)xwiki.com
Research engineer at XWiki SAS
http://www.xwiki.com
Committer on the XWiki.org project
http://www.xwiki.org
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(a)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(a)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(a)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(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs