The proximity or default actions associated with the menus "edit" "show"
"print" "action" or "watch" are often accidentally triggered by careless
mouse-clicks intended for the "browser-tabs" or "toolbar", usually situated
directly above the document in many browsers. I also think it is unaesthetic
to have the current menus overlay"active space" in the LHS panels. It seems
like the new design still has a lot of action very "close" to the
browser-tabs and toolbar, which can lead to unintended browser accidents.
I'd like to see the menu positioned away from the very top of the window,
and instead, be placed at the bottom ofthe 220x70
header-image /xwiki/bin/download/XWiki/DefaultSkin/*.jpg, over the
"breadcrumbs" displaying the
path to the document. Alternately, consider that the right-hand-side of the
top of the document is under-used, and the left-hand-side is cluttered: you
end up overlaying menus on the left-had-side column should that feature be
enabled.
Since the header-image aleady marks off a "halfway point" of the document
content area, what about having the menu items in a column to the right side
of the 220x70 header-image. The remaining space from 250 pixels to the
right-hand-side would be available for Xwiki menus which would accordion-out
to the right, and "auto-scroll". The overall positioning with respect to the
page of the Xwiki menus wouldn't change as much since the menus are
basically attached to the middle-to-right-hand-side of the contents window,
rather than the leftmost edge. For example, this is what it would look like
with the mouse cursor (XX) at "Print" and the Actions/Print menu accordioned
to the right. (Administration would accordion to the left).:
............................................................................................
| || ..............
|| Xwiki Admin
| Edit || || Administrtion
|| Logout
| || ...............
|| ..
| Show ||
|| ..
|............................................................................||
| Actions/Print |||||<-- (XX) Print || Export PDF || Export HTML ... ||
-->>||
|````````````````````````````````````````````````````````````````````````````||
| Watch |
||
.............................................................................................
^
^
\--- 220x70 header image aligned to LHS of content area RHS
column for panels -----/
(no left hand side column for panels displaying)
Regarding a small incremental improvement to the current menus: Having the
ability to turn off the default action associated with these menus would be
a useful addition if the current menus are kept in the design. It is less
annoying and potentially loss-inducing to have an extra menu pop up by
accident. The problem is that just clicking in the menus triggers a default
action as some kind of shortcut. However, for me, on edit, this shortcut is
almost always the wrong thing,. 2.0 has taken a special predilection to
proudly rendering programming I'm doing in the WYSIWYG, simply because it
can... :-)
Fortunately, the browser "back" works correctly with Xwiki form contents, so
you often don't have to lose anything but time for mis-clicking. The
potential for such "human error" should be considered in placing controls in
the window at close proximity to browser controls.
The other thing is that if there is some intractable performance issue,
like the way the current menus "flicker" as you scroll on Linux/Firefox,
such issues were taken into account in the design so that they don't "bite"
when it's already too late. And if they can't be solved, some of the fancier
uses of transparency, etc need to be dropped in terms of working on the
lowest common denominator that will work consistently and with good
performance across all platforms.
Having live HTML mockups of pages would be very helpful to figure out what
actually works, versus what's going to turn into a wasteful use of time
fixing platform/incompatibility issues. Let the public test and report on
issues on the myriad of platforms they already use day-to-day. I have
noticed two platform-dependent issues on the old skin (1) flicker on scroll
only in linux/ff ; (2) on extremely long documents (longer than any document
anybody would use), on some platforms (windows?), the display seems to
silently run out of off-screen memory, or what ever it is they use to
smoothly scroll pages (double buffering for example). In Xwiki, ths means
extremely long documents might suddenly end up "all black"... the actual
text is there and can be transferred to the cut buffer. It's just gone
black-on-black. Again, these issues might not occur in a more simplistic
design, with an easy customization to getting background pixmaps and
transparency, but not as the default. Note that
http://www.google.com/ig?hl=en only skins and backgrounds the top of the
page and the left-hand-side nav. The actual "content" area has no
background, no transparencies, only rounded corner-boxes. I think this is
done for maximum "user experience" performance and avoiding cross-browser
issues.
Niels
http://nielsmayer.com
_______________________________________________
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
