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 _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
