9 Apr
2009
9 Apr
'09
9:28 a.m.
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" <ludovic(a)xwiki.org>
To: "XWiki Users" <users(a)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/RefineyourSearchforLearn…
11 Apr
11 Apr
7:44 a.m.
New subject: [xwiki-users] How to navigate user pages as tree structure from main page?
On Thu, Apr 9, 2009 at 12:28 AM, Manfred <manonintex(a)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
8:05 a.m.
New subject: [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 <manonintex(a)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 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
5774
days inactive
5776
days old
2 comments
2 participants
participants (2)
-
Manfred -
Niels Mayer