Note: to be honest, I'm not really sure a mobile browser is the best place to display a very big, rich and deep tree as the all docs index ... I suppose ideally it would be more ergonomic to display something like vertically stacked list boxes, one list for each "level" of the tree, and update the childs dynamically when a level item is selected... To be really really honest, I'm not sure I like ANY tree based UI when the tree is very big and deep (dealing with windows explorer is enough trees for the rest of my day) ;-) IMO as long as you start needing to scroll to see an element and its root parent, it starts becoming slightly painful. Saying that from a "basic user" POV, obviously as a dev I'd love a very big tree from wiki/space/page down to class and objects properties ;-)
2014-09-26 11:44 GMT+02:00 Jeremie BOUSQUET <[email protected]>: > Hi, > > Just a note, did you also check how those trees behave on a mobile browser > ? > I just quickly opened the jsTree demo on my mobile (in a Chrome browser), > and I quickly stopped trying to unfold items before throwing my mobile away > as it was very frustrating. > At least during my quick test, it was very difficult to correctly tap the > tiny arrow icons, and most of the time it would select the line instead of > unfolding content. > Also I don't know if this demo tree was lazily loaded, but it took few > seconds sometimes to unfold after you tap, without any visual clue of > something happening. > With fancytree unfolding was far easier, but lazy loading just didn't work > in my case (or maybe was too slow). > > This is in no way an exhaustive test and I don't want (and I can't) say > that jsTree doesn't behave correctly on mobiles browsers, maybe there are > better configurations to apply than the demo, more appropriate for mobiles, > maybe should try with another browser, etc... But my feeling is that if you > intend to have a responsive UI for xwiki, and usable on browsers, IMHO it > should be taken into account when choosing JS libraries and plugins. > > <off topic> > Personally for my apps my favorite tree is the MKTree application [1], > even if it doesn't even compete of course in terms of features with the > others. It has the advantage of not requiring any javascript writing, you > just put a structure of <ul><li> and it's done. In case the tree doesn't > require to be dynamic, it's easier for any user to edit the page as the > tree structure is very readable in the source. It also degrades nicely in > case of javascript not activated, thanks to that. And contrarily to what is > said on the extension page, I could use it with a page in syntax 2.1 - I > just couldn't make work the expand all / collapse all links for now, but I > didn't investigate much on it. > It's a very K.I.S.S. alternative ;-) > > [1] - > http://extensions.xwiki.org/xwiki/bin/view/Extension/Mktree+Application > </off topic> > > BR, > Jeremie > > > 2014-09-26 11:01 GMT+02:00 Marius Dumitru Florea < > [email protected]>: > >> Hi Denis, >> >> On Fri, Sep 26, 2014 at 10:23 AM, Denis Gervalle <[email protected]> wrote: >> > Hi Marius, >> > >> >> > Have you also tried other solution ? >> >> It depends what you understand by "tried". I have *investigated* other >> solutions of course, not all of them obviously. I've chosen jsTree for >> the File Manager and I didn't have any issues. >> >> > , and from the popular I know, >> > FancyTree (successor of DynaTree) https://github.com/mar10/fancytree/ >> look >> > like a good candidate ? >> >> Yes, it does look like a good tree, but I haven't used it so I can't >> tell how it works in a real project, beyond a simple demo. >> >> The first "issue" I've seen is that the documentation is not very >> clean on how you can control the node icon from the data source. This >> http://wwwendt.de/tech/fancytree/doc/jsdoc/global.html#NodeData >> doesn't include an "icon" property, but I've seen: >> >> // Append a new child node >> activeNode.addChildren({ >> title: "Document using a custom icon", >> icon: "customdoc1.gif" >> }); >> >> on https://github.com/mar10/fancytree/wiki#api-access (putting aside >> the fact that "children" is plural so I would expect to receive an >> array not a map). >> >> > Its community looks comparable but it is a bit less popular. >> >> > Demonstrated features are equivalent and potentially better >> >> Can you tell me what features of FancyTree that are missing from >> jsTree are important for us in XWiki or for applications written on >> top of XWiki? >> >> > (my feeling with the demo of >> > jsTree was bad, could be the demo settings however). >> >> Can you give us more details?.. What was bad? What didn't work? >> >> > But, more importantly, its browser support seems to be taken more >> > seriously. >> >> > I have seen couple of issue, event recently with IE support in >> > JsTree, >> >> Can you give us some examples? At least to understand if those issues >> are important for us in XWiki. Also, have you tried to report those >> issues to jsTree? Are you sure the jsTree community is not willing to >> fix those issues? >> >> > like if IE was just tested at the end, and their support moto "All >> > modern browsers are supported, as well as IE8" is not really engaging. >> The >> > compatibility of FancyTree see far better for IE (IE from 6 to 11). >> >> Are you saying this from your experience with FancyTree or just by >> reading the documentation? On extensions.xwiki.org there are currently >> 3 extensions that use jsTree and none that use FancyTree. Among those >> that use jsTree there is Dynamic Hierarchy Tree which is used, AFAIK, >> on production on some XWiki installations. I'm not aware of IE issues >> there with jsTree, but I'll double check. >> >> > Since, >> > we have not finished our discussion regarding IE support, I am not >> > confortable with JsTree if we continue support for IE < 9. >> >> Again, if you don't mention exactly what IE issues you have >> encountered with jsTree, then I feel that your worries are not really >> justified. >> >> > At least, it >> > would be good to compare these two and have other arguments then >> popularity >> > to choose JsTree IMO. >> >> Popularity is very important. >> >> Thanks, >> Marius >> >> > >> > Regards, >> > >> > On Thu, Sep 25, 2014 at 12:11 PM, Marius Dumitru Florea < >> > [email protected]> wrote: >> > >> >> Hi devs, >> >> >> >> There are a couple of places in XWiki were a tree widget is used or >> >> needed: document index, WYSIWYG editor wiki page linking, XAR import, >> >> navigation panel, database tree list, report step of Distribution >> >> Wizard, extension upgrade when asking confirmation to clean unused >> >> pages, etc. But we don't have a standard / recommended tree widget / >> >> library. We use either SmartClient which is very heavy or a custom >> >> tree based on Prototype.js. >> >> >> >> Since we want to ditch the heavy SmartClient tree and we decided to >> >> move away from the dead Prototype.js to jQuery I propose to use jsTree >> >> ( http://www.jstree.com/ ) as the standard / recommended library for >> >> creating trees in XWiki. >> >> >> >> It is one of the best and most used tree widgets written using jQuery. >> >> I have used jsTree on the File Manager ( >> >> >> >> >> http://extensions.xwiki.org/xwiki/bin/view/Extension/File+Manager+Application >> >> ) and it was a positive experience. Moreover, there are other >> >> extensions based on, like the Dynamic Hierarchy Macro ( >> >> >> >> >> http://extensions.xwiki.org/xwiki/bin/view/Extension/Dynamic+Hierarchy+Macro >> >> ). >> >> >> >> My plan is: >> >> * include jsTree in the default distribution (through a webjar >> >> dependency); it won't be loaded by default, obviously; you'll have to >> >> use Require.js to load it. >> >> * start rewriting the current trees using jsTree >> >> >> >> Here's my +1. >> >> >> >> Thanks, >> >> Marius >> >> _______________________________________________ >> >> devs mailing list >> >> [email protected] >> >> http://lists.xwiki.org/mailman/listinfo/devs >> >> >> > >> > >> > >> > -- >> > Denis Gervalle >> > SOFTEC sa - CEO >> > _______________________________________________ >> > devs mailing list >> > [email protected] >> > http://lists.xwiki.org/mailman/listinfo/devs >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
