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
