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).
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(a)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(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