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" <[email protected]> To: "XWiki Users" <[email protected]> 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/RefineyourSearchforLearni...
On Thu, Apr 9, 2009 at 12:28 AM, Manfred <[email protected]> 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
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 <[email protected]> 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 running out of memory i java); streaming attachment downloading (for large streaming media files), and database management/partitioning/backup issues caused by having large media files included in the document database. And of course, changing the tooltips implementation to incrementally compute tooltips as they are displayed. -- Niels http://nielsmayer.com
participants (2)
-
Manfred -
Niels Mayer