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