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

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

Reply via email to