Re: [xwiki-users] How to navigate user pages as tree structure from main page?
Hi Niels, Thanks for the extensive exposition on tooltips and breadcrumbs. Will concede the technical aspects are a bit whoa for me, but I'm confident the Xwiki developers will know what you're on about ;-) Initial discussion topic was around ways to improve / provide a hierarchical page navigation tree, AFAIK no mention was made of tooltips - so that functionality may not even be on the agenda for Xwiki or I don't know at least. Its just that one of the developers mentioned an example page using Curriki to illustrate a point, so I gave some feedback round that. I then visited said page and the tree navigation structure of it I quite like, it was the other 'features' that irritated me, so I put in my 0.03 in case the xwiki developers were thinking of doing something similar, so that they at least have 1 user input of hopefully what not to do. I'm sure your input will be valuable to them as well, I did look at your xwiki site and I see how you've done it - the first page of the space you have created a TOC for the docs in it, it appears. Of course that works, but what I was asking for was an xwiki generated space aware, tree like hierarchical nested wiki page navigation structure to this which fits in the navigation, recently modified, etc area of the xwiki browser page rather than me needing to occupy the space page with a TOC or provide hyperlinks elsewhere, etc. Cheers ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] How to navigate user pages as tree structure from main page?
I mentioned the curriki tooltips issue because you noted performance issues in waiting for certain actions in curriki's navigation. Ludovic gave the example http://www.curriki.org/xwiki/bin/view/Coll_curriki/RefineyourSearchforLearningResources?bc=;Coll_curriki.CurrikiHelp;Coll_curriki.HowtoSearchBrowseCurriki_0-- note the extensive use of tooltips on each item as you hover over them in the navigation. IMHO, this is the reason for the perfomance issues: You noted: 1. The noticeable lag between clicking on a tree link and the next level opening. My internet connection isnt *that* slow and I'd guess even at intranet speeds it would still be noticeable. Taking a guess maybe the page needs to have the tree/toc preloaded/cached to avoid this lag or some other approach, but the pregnant pause waiting for the toc/tree part of the screen to redraw is somewhat disconcerting. The point of my message was to point out that some of the widgetry you were looking at might perform differently in a different environment that doesn't burden the browser with as much work. Because of the particular tooltips approach used, JavaScript and the user's browser can be a potential performance bottleneck. A generalized imlementation of the navigation Ludovic pointed out might want to skip some of these performance bottlenecks, rather than replicating them. Or solve the issue by coming up with an incremental approach for tooltips. For example, using the hover timeout to fetch and compute the individual toolktip HTML for the item one's mouse is over, as opposed to having to precompute all the tooltips each time you expand a level in the navigation. Regarding your navigation needs, have you considered using (or modifying) Main.Dashboard or Main.SpaceIndex? The code snippet I put in the WebHome page of most spaces created on my site comes from Main.SpaceIndex, (usage example: /xwiki/bin/view/Main/SpaceIndex?space=Main ). Additionally, the code in Main.Dashboard indicates it can be used on a per-space basis: ## This dashboard can be used for both wikis (Main.WebHome) ## and spaces (*.WebHome). ## #set($isSpaceDashboard = false) #if($doc.space != Main) #set($isSpaceDashboard = true) #end However, it sounds lke you're looking for something closer to Panels.Navigation, Panels.Spaces. or Panels.SpaceDocs ... Niels http://nielsmayer.com On Tue, Apr 14, 2009 at 2:36 AM, Manfred manonin...@gmail.com wrote: Hi Niels, Thanks for the extensive exposition on tooltips and breadcrumbs. Will concede the technical aspects are a bit whoa for me, but I'm confident the Xwiki developers will know what you're on about ;-) Initial discussion topic was around ways to improve / provide a hierarchical page navigation tree, AFAIK no mention was made of tooltips - so that functionality may not even be on the agenda for Xwiki or I don't know at least. Its just that one of the developers mentioned an example page using Curriki to illustrate a point, so I gave some feedback round that. I then visited said page and the tree navigation structure of it I quite like, it was the other 'features' that irritated me, so I put in my 0.03 in case the xwiki developers were thinking of doing something similar, so that they at least have 1 user input of hopefully what not to do. I'm sure your input will be valuable to them as well, I did look at your xwiki site and I see how you've done it - the first page of the space you have created a TOC for the docs in it, it appears. Of course that works, but what I was asking for was an xwiki generated space aware, tree like hierarchical nested wiki page navigation structure to this which fits in the navigation, recently modified, etc area of the xwiki browser page rather than me needing to occupy the space page with a TOC or provide hyperlinks elsewhere, etc. Cheers ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] How to navigate user pages as tree structure from main page?
sorry, i spaz'd and accidentally sent the previous message before I finished composing or spellchecking... here's what I intended to send. (oops) On Thu, Apr 9, 2009 at 12:28 AM, Manfred manonin...@gmail.com wrote: Yes the hierarchical design used by Curriki would work for me, the layout is fine, but the implementation is a bit disconcerting, so if there is a way to work round the negative UI issues... The aspects that I find are disconcerting and would be disorienting or frustrating for users with the example Curriki page is: 1. The noticeable lag between clicking on a tree link and the next level opening. My internet connection isnt *that* slow and I'd guess even at intranet speeds it would still be noticeable. Taking a guess maybe the page needs to have the tree/toc preloaded/cached to avoid this lag or some other approach, but the pregnant pause waiting for the toc/tree part of the screen to redraw is somewhat disconcerting. 2. Also the links themselves - one appears to need to click on a very specific location to get the link to open to the next level (and you know as well as I do that some users have trouble controlling their mice) - i.e. the little arrow, but if one clicks on the folder icon it also opens albeit slower, but if one goes a little bit further then one sees a popup tooltip obscuring the text and when one clicks on the text it goes to that linked page. Really its not immediately clear to a user what to click on to get the tree to open - if it works like Windoze (file) explorer then its probably an approach familiar to most GUI users. If you intend to implement tooltips IMO definitely include an option to disable them because power/frequent wiki users will get irritated by them quickly. I wonder if the lag in you're seeing in Curriki is caused by the tooltips. The curriki tooltip implementation walks the entire DOM for a given document in order to find items that require tooltips. This becomes a problem with long documents, or documents that contain lots of HTML but hide much of it via Javascript. The issue is that tooltips are computed for the entire document only after the entire document is loaded into the browser. This pretty much wrecks the incremental page display that distinguished modern browsers from early implementations like netscape. The lack of incremental display puts an outrageous strain on a Curriki user's browser and makes page display exceptionally slow: (1) tooltips and tooltip text are generated for parts of a document that are not visible via javascript (e.g. hide/show, collapse/expand/etc); (2) tooltips and tooltip text are generated for the entire document at load-time, even if the majority of the document is scrolled off screen; (3) even if a user never uses tooltips, the actual text/html content of all the tooktips for a given document are loaded into the browser via javascript invoked by adding $xwiki.addTooltipJS() to the end of a document. Although a significant amount of extra tooltip data is added to the browser on each curriki page, the slowdown is not caused by transferring the extra tooltip data to the browser. Rather, it is entirely caused by how slowly the browser walks the entire DOM of the given document in order to find the tooltips, as well as the time to dynamically generate the tooltip HTML for the entire document (in javascript). It difficult to characterize the O(n) performance degradation on document length caused by curriki tooltips, as it ultimately depends on the structure and complexity of the document DOM that must be walked, the size of the total tooltips added per page, etc. The problem is especially bad if the DOM is generated from a database query of unscoped length. You won't see the page until the last of the query is dislayed, even if incremental results are available right away. Regarding the breadcrumbs, i think that it introduces more problems than it solves. The curriki breadcrumbs are perhaps helpful for purely static documents. For documents containing forms or any amount of nonstatic UI, there can be issues with the tooltips allowing going back even in cases where it may be inappropriate. For example, when forms submission brings you to another document -- for example as you click next proceeding through a multi-page wizard where each next brings you to a new document: startdoc---(select WizA)-- WizA --(next)--- WizB --(next)--- WizC --(next)--- ... Would the breadcrumb for WizC look like startdoc-WizA-WizB-WizC or startdoc-WizC ?? In a wizard you may not want to allow the user to go back via the breadcrumbs, just through the next/prev entries in the wizard. Also, why is revamping Xwiki's breadcrumbs being given priority? I can think of a long list of improvements and bugfixes that would be preferable, including one that would IMHO help out curriki and many Xwiki users a lot more than something trivial like breadcrumbs -- streaming attachment uploading (unllimited size attachments w/o
Re: [xwiki-users] How to navigate user pages as tree structure from main page?
On Thu, Apr 9, 2009 at 12:28 AM, Manfred manonin...@gmail.com wrote: Yes the hierarchical design used by Curriki would work for me, the layout is fine, but the implementation is a bit disconcerting, so if there is a way to work round the negative UI issues... The aspects that I find are disconcerting and would be disorienting or frustrating for users with the example Curriki page is: 1. The noticeable lag between clicking on a tree link and the next level opening. My internet connection isnt *that* slow and I'd guess even at intranet speeds it would still be noticeable. Taking a guess maybe the page needs to have the tree/toc preloaded/cached to avoid this lag or some other approach, but the pregnant pause waiting for the toc/tree part of the screen to redraw is somewhat disconcerting. 2. Also the links themselves - one appears to need to click on a very specific location to get the link to open to the next level (and you know as well as I do that some users have trouble controlling their mice) - i.e. the little arrow, but if one clicks on the folder icon it also opens albeit slower, but if one goes a little bit further then one sees a popup tooltip obscuring the text and when one clicks on the text it goes to that linked page. Really its not immediately clear to a user what to click on to get the tree to open - if it works like Windoze (file) explorer then its probably an approach familiar to most GUI users. If you intend to implement tooltips IMO definitely include an option to disable them because power/frequent wiki users will get irritated by them quickly. I wonder if the lag in you're seeing in Curriki is caused by the tooltips. The curriki tooltip implementation walks the entire DOM for a given document in order to find items that require tooltips. This becomes a problem with long documents, or documents that contain lots of HTML but hide much of it via Javascript. The issue is that tooltips are computed for the entire document only after the entire document is loaded into the browser. This pretty much wrecks the incremental page display that distinguished modern browsers from early implementations like netscape. The lack of incremental display puts an outrageous strain on a Curriki user's browser and makes page display exceptionally slow: (1) tooltips and tooltip text are generated for parts of a document that are not visible via javascript (e.g. hide/show, collapse/expand/etc); (2) tooltips and tooltip text are generated for the entire document at load-time, even if the majority of the document is scrolled off screen; (3) even if a user never uses tooltips, the actual text/html content of all the tooktips for a given document are loaded into the browser via javascript invoked by adding $xwiki.addTooltipJS() to the end of a document. ALthough a significant amount of extra tooltip data is added to the browser on each curriki page, the slowdown is not caused by transferring the extra tooltip data to the browser. Rather, it is entirly caused by how slowly the browser walks the entire DOM of the given document in order to find the tooltips, as well as the time to dynamicaly generate the tooltip HTML for the entire document. It difficult to characterize the O(n) performance degradation on document length caused by curriki tooltips, as it ultimately depends on the structure and complexity of the document DOM that must be walked, the size of the total tooltips added per page. The problem is especially bad if the DOM is generated from a database query of unscoped length. You won't see the page until the last of the query is dislayed, even if incremental results are available right away. Regarding the breadcrumbs, i think that it introduces more problems than it solves. The curriki breadcrumbs are perhaps helpful for purely static documents. FOr documents containining forms or any amount of nonstatic UI, there can be issues with the tooltips allowing going back even in cases where it may be inappropriate. For example, when forms submission brings you to another document -- for example as you click next proceeding through a multi-page wizard where each next brings you to a new document: startdoc---(select WizA)-- WizA --(next)--- WizB --(next)--- WizC --(next)--- ... would the breadcrumb for WizC look like startdoc-WizA-WizB-WizC or startdoc-WizC ?? And ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] How to navigate user pages as tree structure from main page?
Hi Ludovic, Yes the hierarchical design used by Curriki would work for me, the layout is fine, but the implementation is a bit disconcerting, so if there is a way to work round the negative UI issues... The aspects that I find are disconcerting and would be disorienting or frustrating for users with the example Curriki page is: 1. The noticeable lag between clicking on a tree link and the next level opening. My internet connection isnt *that* slow and I'd guess even at intranet speeds it would still be noticeable. Taking a guess maybe the page needs to have the tree/toc preloaded/cached to avoid this lag or some other approach, but the pregnant pause waiting for the toc/tree part of the screen to redraw is somewhat disconcerting. 2. Also the links themselves - one appears to need to click on a very specific location to get the link to open to the next level (and you know as well as I do that some users have trouble controlling their mice) - i.e. the little arrow, but if one clicks on the folder icon it also opens albeit slower, but if one goes a little bit further then one sees a popup tooltip obscuring the text and when one clicks on the text it goes to that linked page. Really its not immediately clear to a user what to click on to get the tree to open - if it works like Windoze (file) explorer then its probably an approach familiar to most GUI users. If you intend to implement tooltips IMO definitely include an option to disable them because power/frequent wiki users will get irritated by them quickly. 3. Maybe my eyes are being deceived by the very obvious screen refresh/redraw delay but it almost seems as if the web page contents moves up or down depending on which tree link one clicks on. IMO if the user expects a page to open then the menu must remain in a static position on the screen and the link they clicked on mustnt suddenly move a few cm up or down the screen because that is disorienting, rather leave it to the user to scroll up or down the page from their last viewing position if they want to. If the xwiki team can work around the issues exhibited by Curriki, in their Xwiki implementation, I think it would be very usable. I look forward to seeing the results of your efforts. Thanks for your interest, Cheers - Original Message - From: Ludovic Dubost ludo...@xwiki.org To: XWiki Users users@xwiki.org Sent: Wednesday, April 8, 2009 11:19:53 PM GMT +02:00 Harare / Pretoria Subject: Re: [xwiki-users] How to navigate user pages as tree structure from main page? I'm currently working on some different ways to implement the breadcrumb and a Table of Content on a project. It's using some of the ideas that are currently implemented in Curriki. See this example: http://www.curriki.org/xwiki/bin/view/Coll_curriki/RefineyourSearchforLearningResources?bc=;Coll_curriki.CurrikiHelp;Coll_curriki.HowtoSearchBrowseCurriki_0 ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] How to navigate user pages as tree structure from main page?
Hi JV and Vincent Fabulous to hear :-) Yes that's IMO useful as a tree index and would also be workable but it would be clumsy for what I really desire as a wiki nested page navigation menu. To be workable from the main page or subpages IMO one needs a subset of this in the side panel to work as a hierarchical table of contents - think like the windows explorer file manager view when it shows directories - the drive letters and names would be the spaces, then the next link down would be the first wiki page of that space and then the next drill down would be the next wiki page below the first wiki page. As one navigates to the first wiki page further deeper wiki page levels would be shown. The way it works with Dekiwiki is as one drills deeper the upper levels displayed are closed - i.e all upper levels are indented to the 0 position - so that the hierarchy width doesnt grow wider than the initial panel size. Also looking at the tree display currently in XE 1.8, to be practical and not confuse users when used as a sidebar, the wiki page navigation panel one would need the option of hiding certain spaces. Many of the spaces created by the application import for example one doesnt necessarily want to display, often just the user spaces would be what is desired to display. So if one creates say a 'department' space then a user might want to browse around in that to navigate to a specific page they want quickly. Really what I mean is like in XE we have spaces which in turn have pages, I'd like within each space to have subpages of main pages which are intuitive for users to navigate, almost like subspaces within a main space. At present it appears to me as if all wiki pages within a space are at the same hierarchical level, which of course makes managing multiple pages on a certain topic/theme a bit of a challenge. Also having this tree space context aware would be wonderful so that if one is in a space then the tree sidebar navigator shows only the pages in the space. One could have a main menu option so that a user can always get back to the home/main page but then again the quicklinks could also be used for that, but it might be more intuitive if its listed on the tree sidebar right as the first entry as well. I did attach an example jpg to this mail but it appears it didnt get through so hopefully you don't mind that I have emailed it directly FYI. I can create a short video clip of it if you want as well to show how one can navigate pages easily in this manner. Thanks for your interest. Integrating such a feature in the main sidebar would make Xwiki wiki pages considerably more navigable. Thanks, Cheers We are actively working of an improved version of the treeview. It will be shipped with XE 1.8.1. Here's a preview: http://www.jean-vincent.org/xwiki/bin/download/Main/Screenshots/treeview.jpg Is this what you had in mind ? Note that this tree is highly customizable and that it will be possible to put it in a side panel. ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] How to navigate user pages as tree structure from main page?
Hi, I'm currently working on some different ways to implement the breadcrumb and a Table of Content on a project. It's using some of the ideas that are currently implemented in Curriki. See this example: http://www.curriki.org/xwiki/bin/view/Coll_curriki/RefineyourSearchforLearningResources?bc=;Coll_curriki.CurrikiHelp;Coll_curriki.HowtoSearchBrowseCurriki_0 One of the differences for breadcrumbs and toc in curriki is that your context depends on your navigation (in addition to the parent child relationships of pages). This is necessary because in Curriki pages can have multiple parents and you would like to keep the breadcrumb and TOC of where you came from (the actual parent is the default). It's the bc= parameter in the URL that keeps the navigation context. Also in Curriki the breadcrumb and the TOC has an entry point. In Curriki it is Collections that serve as entry points. The TOC or BC will always start from such a page. In the other project I'm working on we also have such a structure that serves as the entry point. It's actually important to have such a structure to decide when to stop going up the parent child relationship. Otherwise you could get a pretty huge TOC. Maybe we would need to have a special parameter for pages that we can check to decide this is such a page which would be the top of a TOC. Or we could decide that spaces home pages are such pages. This is the main problem to solve. Once you have this you can play around with AJAX trees to have nice open/close status of the tree itself and you can nicely see your page in the context of your tree. Indeed this is key to great navigation inside your wiki. I should soon be able to share the special breadcrumb and TOC code (it's not AJAX at this point). Ludovic Manfred a écrit : Hi JV and Vincent Fabulous to hear :-) Yes that's IMO useful as a tree index and would also be workable but it would be clumsy for what I really desire as a wiki nested page navigation menu. To be workable from the main page or subpages IMO one needs a subset of this in the side panel to work as a hierarchical table of contents - think like the windows explorer file manager view when it shows directories - the drive letters and names would be the spaces, then the next link down would be the first wiki page of that space and then the next drill down would be the next wiki page below the first wiki page. As one navigates to the first wiki page further deeper wiki page levels would be shown. The way it works with Dekiwiki is as one drills deeper the upper levels displayed are closed - i.e all upper levels are indented to the 0 position - so that the hierarchy width doesnt grow wider than the initial panel size. Also looking at the tree display currently in XE 1.8, to be practical and not confuse users when used as a sidebar, the wiki page navigation panel one would need the option of hiding certain spaces. Many of the spaces created by the application import for example one doesnt necessarily want to display, often just the user spaces would be what is desired to display. So if one creates say a 'department' space then a user might want to browse around in that to navigate to a specific page they want quickly. Really what I mean is like in XE we have spaces which in turn have pages, I'd like within each space to have subpages of main pages which are intuitive for users to navigate, almost like subspaces within a main space. At present it appears to me as if all wiki pages within a space are at the same hierarchical level, which of course makes managing multiple pages on a certain topic/theme a bit of a challenge. Also having this tree space context aware would be wonderful so that if one is in a space then the tree sidebar navigator shows only the pages in the space. One could have a main menu option so that a user can always get back to the home/main page but then again the quicklinks could also be used for that, but it might be more intuitive if its listed on the tree sidebar right as the first entry as well. I did attach an example jpg to this mail but it appears it didnt get through so hopefully you don't mind that I have emailed it directly FYI. I can create a short video clip of it if you want as well to show how one can navigate pages easily in this manner. Thanks for your interest. Integrating such a feature in the main sidebar would make Xwiki wiki pages considerably more navigable. Thanks, Cheers We are actively working of an improved version of the treeview. It will be shipped with XE 1.8.1. Here's a preview: http://www.jean-vincent.org/xwiki/bin/download/Main/Screenshots/treeview.jpg Is this what you had in mind ? Note that this tree is highly customizable and that it will be possible to put it in a side panel. ___ users mailing list users@xwiki.org
[xwiki-users] How to navigate user pages as tree structure from main page?
Hi, One aspect thats driving me a little scatty - and I have to date installed XE, XEM and Chronopolys and XW - so far only Chrono seems pretty intuitive for me to drive out the box - is having a way for a user to see the pages they have created in some sort of hierarchy but built into the menu of the page or the quick links section or some such for easy page navigation and knowing where they are in the wiki. e.g. I can see the page breadcrumbs allow one to move backwards to a higher level page, but how does one move forward or see that there is a fwd page short of placing a hyperlink to the next page on the current page or expecting users to click on information tab of the current page to find its children I mean in Dekiwiki this is built into it so was positively elementary so I'm frustrated that I don't seem to be able to do this in Xwiki. What am I missing? I was hoping the Document index tree could be used for this by say finding a way to display it as part of the Quicklinks or similar dashlet on the dashboard, but the script to do this doesnt appear to work for user pages I'm finding and it appears this issue is regarded as a minor script issue by the developers, and even if it were to work I'm guessing that being a separate page to browse to its not really what I was hoping to see. I can create something like this (I'll use the Xwiki terms (in parentheses) as I understand them for what I'd like to do) and write the page names in UPPERCASE and use some hypothetical names. Using XEM where I have created Wiki: MAIN_HOME (as the first wiki of the farm) I would like to use and navigate something like this ito user page hierarchy: (Wiki) MAIN_HOME (Wiki) -- |--Departments(Space) |-- Planning (Page) | --Planning projects (Page) | -- Efficiency project (Page) | -- Warehouse project (Page) | -- ISO 9000 (Page) | -- Production (Page) | -- Downtime (Page) | -- Utilisation (Page) | -- ISO 14000 (Page) | -- Finance (Page) | Budgets (Page) | Guidelines (Page) | Safety (Space) | Weekly topic (Page) | Safety projects (Page) | Training (Space) | Agenda (Page) etc Can this type of thing be done in Xwiki or do I misunderstand something fundamental in how to use it? I realise the XE product is intended to be basic out the box and must be customised and isnt a universal plug and go solution but I'm wrestling with what I thought should be simple to achieve so I'm wondering. I really like the way Xwiki converts pages to PDF stripping out all the Wiki clutter and the Edit, Show print bar that hide a lot of clutter that other Wikis put and print on the wiki page, but the Xwiki created user page navigation is less than intuitive and if I'm struggling then the most users our side will be completely lost so I need to resolve this aspect first if its possible. Is there a way - a plugin maybe? Thanks Cheers ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] How to navigate user pages as tree structure from main page?
On Tue, Apr 7, 2009 at 5:07 PM, Manfred manonin...@gmail.com wrote: I mean in Dekiwiki this is built into it so was positively elementary so I'm frustrated that I don't seem to be able to do this in Xwiki. What am I missing? I was hoping the Document index tree could be used for this by say finding a way to display it as part of the Quicklinks or similar dashlet on the dashboard, but the script to do this doesnt appear to work for user pages I'm finding and it appears this issue is regarded as a minor script issue by the developers, and even if it were to work I'm guessing that being a separate page to browse to its not really what I was hoping to see. Hi, We are actively working of an improved version of the treeview. It will be shipped with XE 1.8.1. Here's a preview: http://www.jean-vincent.org/xwiki/bin/download/Main/Screenshots/treeview.jpg Is this what you had in mind ? Note that this tree is highly customizable and that it will be possible to put it in a side panel. Thanks, JV. ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] How to navigate user pages as tree structure from main page?
On Apr 7, 2009, at 6:00 PM, Jean-Vincent Drean wrote: On Tue, Apr 7, 2009 at 5:07 PM, Manfred manonin...@gmail.com wrote: I mean in Dekiwiki this is built into it so was positively elementary so I'm frustrated that I don't seem to be able to do this in Xwiki. What am I missing? I was hoping the Document index tree could be used for this by say finding a way to display it as part of the Quicklinks or similar dashlet on the dashboard, but the script to do this doesnt appear to work for user pages I'm finding and it appears this issue is regarded as a minor script issue by the developers, and even if it were to work I'm guessing that being a separate page to browse to its not really what I was hoping to see. Hi, We are actively working of an improved version of the treeview. It will be shipped with XE 1.8.1. Here's a preview: http://www.jean-vincent.org/xwiki/bin/download/Main/Screenshots/treeview.jpg Is this what you had in mind ? Note that this tree is highly customizable and that it will be possible to put it in a side panel. How will it work in a side panel? When you expand a node it takes space horizontally and a horizontal scrollbar in a panel doesn't seem very nice to me. Thanks -Vincent ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] How to navigate user pages as tree structure from main page?
On Tue, Apr 7, 2009 at 6:14 PM, Vincent Massol vinc...@massol.net wrote: How will it work in a side panel? When you expand a node it takes space horizontally and a horizontal scrollbar in a panel doesn't seem very nice to me. Indeed it won't allow to display lots of levels. I've made a quick test with a panel displaying pages in the current space: http://www.jean-vincent.org/xwiki/bin/download/Main/Screenshots/treeviewpanel.jpg I think this is usable with small-medium sized hierarchies. JV. ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
