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