[xwiki-devs] [Proposal] Wiki 2.0 Menu
Hi, Please give feedback on the menu iteration. You can view the mockups at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin20Menu 1. We need to decide the way we handle the actions we are able to do (depending on the rights we have): enable/disable them or hide them. 2. You can select to have an simple or advanced menu (View and Edit submenus affected) Thanks, Caty
On Tue, Aug 11, 2009 at 3:12 PM, Ecaterina Valica<[email protected]> wrote:
Hi,
Please give feedback on the menu iteration. You can view the mockups at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin20Menu
I think we should rename "Actions" back to "More Actions" since the second is more common (I can think of gmail for example).
1. We need to decide the way we handle the actions we are able to do (depending on the rights we have): enable/disable them or hide them.
Why do we keep the "view" entry ? I personally use "edit" to see the source of a page, may be others do the same. Anyway it's still useful to people without edit rights, in this case we could keep "edit" activated and display the source with a message saying something like "You need to login to edit this page, etc" or "You're not allowed to edit this page" depending on the situation.
2. You can select to have an simple or advanced menu (View and Edit submenus affected)
I wouldn't like that we use a tab layout for buttons that are actually not tabs, for example "view" and "edit" in simple mode. The menu must be revamped but I'd prefer that we stick to the dropdown layout since it allows: - to mix single buttons and dropdown lists - to use icons more easily - to create categories more easily (for example in "Actions") Thanks, JV.
I think we should rename "Actions" back to "More Actions" since the second is more common (I can think of gmail for example).
i'm ok with that. I would also like to have "Create" instead of the "Add" action. You can *add * comments and tags, but I think it's more appropriate to *create* pages.
1. We need to decide the way we handle the actions we are able to do (depending on the rights we have): enable/disable them or hide them.
Why do we keep the "view" entry ? I personally use "edit" to see the source of a page, may be others do the same. Anyway it's still useful to people without edit rights, in this case we could keep "edit" activated and display the source with a message saying something like "You need to login to edit this page, etc" or "You're not allowed to edit this page" depending on the situation.
I was thinking with Marta and G, would it be ok to add "History" and "Information" to the "View" submenu? Something like http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20Menu/view... Information in this case has been rename in "Related Pages".
2. You can select to have an simple or advanced menu (View and Edit submenus
affected)
I wouldn't like that we use a tab layout for buttons that are actually not tabs, for example "view" and "edit" in simple mode.
In simple mode "view" and "edit" are not buttons, but actually tabs, you change the view (tab) from one action to another, they aren't form buttons.
The menu must be revamped but I'd prefer that we stick to the dropdown layout since it allows: - to mix single buttons and dropdown lists
in my opinion is the same thing, just the aligment (horizontally, vertically) is different. The problems with dropdowns I understood that it's not well supported if you don't have JS activated, and also dropdowns can block some of the page content. The advantage of the dropdown is when you have many items in the menu - but it's not really the case and anyway menus that are very crowded are hard to use. Another thing is that using this kind of menu, you integrate the tabs in Edit (Wiki, WYSYWIG, Objects ...) with the menu, instead of having the panel. This way you give an unique access point to the editing. - to use icons more easily in the mockups icons are not presented, but I don't see how the dropdown menu can have a better support for icons than then horizontal menu. it's the same thing, we could have also icons in this kind of menu.
- to create categories more easily (for example in "Actions")
you can have categories also in horizontal menus. Thanks for all your comments, Caty
On Tue, Aug 11, 2009 at 6:18 PM, Ecaterina Valica<[email protected]> wrote:
I think we should rename "Actions" back to "More Actions" since the second is more common (I can think of gmail for example).
i'm ok with that.
I would also like to have "Create" instead of the "Add" action. You can *add * comments and tags, but I think it's more appropriate to *create* pages.
Yes create is better than "Add".
1. We need to decide the way we handle the actions we are able to do (depending on the rights we have): enable/disable them or hide them.
Why do we keep the "view" entry ? I personally use "edit" to see the source of a page, may be others do the same. Anyway it's still useful to people without edit rights, in this case we could keep "edit" activated and display the source with a message saying something like "You need to login to edit this page, etc" or "You're not allowed to edit this page" depending on the situation.
I was thinking with Marta and G, would it be ok to add "History" and "Information" to the "View" submenu? Something like http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20Menu/view...
Information in this case has been rename in "Related Pages".
2. You can select to have an simple or advanced menu (View and Edit submenus
affected)
I wouldn't like that we use a tab layout for buttons that are actually not tabs, for example "view" and "edit" in simple mode.
In simple mode "view" and "edit" are not buttons, but actually tabs, you change the view (tab) from one action to another, they aren't form buttons.
Right they aren't form buttons, they are links. They aren't actually tabs since the view and edit layouts are different. If I imagine the menu proposal in the skin 2.0 proposal I can get that using the same layout for content actions (view, edit) and meta-actions (comments, attachments) would look nice but IMO it's not logical. For example "Export" and "More Action" are not only about the content of the page, but that's how it would look like.
The menu must be revamped but I'd prefer that we stick to the dropdown layout since it allows: - to mix single buttons and dropdown lists
in my opinion is the same thing, just the aligment (horizontally, vertically) is different. The problems with dropdowns I understood that it's not well supported if you don't have JS activated, and also dropdowns can block some of the page content.
Would your proposal be working without JS ?
The advantage of the dropdown is when you have many items in the menu - but it's not really the case and anyway menus that are very crowded are hard to use.
With icons and categories I don't find that having a lot of items is a problem, I also think that "More actions" could end up quite crowded.
Another thing is that using this kind of menu, you integrate the tabs in Edit (Wiki, WYSYWIG, Objects ...) with the menu, instead of having the panel. This way you give an unique access point to the editing.
- to use icons more easily
in the mockups icons are not presented, but I don't see how the dropdown menu can have a better support for icons than then horizontal menu. it's the same thing, we could have also icons in this kind of menu.
- to create categories more easily (for example in "Actions")
you can have categories also in horizontal menus.
I'm not saying that you can't, I'm saying that being able to use more space (at least AFAICS) with a vertical layout makes things easier. Thanks, JV.
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
On Wed, Aug 12, 2009 at 09:34, Niels Mayer <[email protected]> wrote:
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.
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/genera... More about the skin proposal at http://markmail.org/message/nagihrc2xqpzw4dz
On Aug 12, 2009, at 11:46 AM, Ecaterina Valica wrote:
On Wed, Aug 12, 2009 at 09:34, Niels Mayer <[email protected]> wrote:
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.
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/genera...
Nice. Some questions: * Shouldn't we also display the creation date next to "Created by" at the bottom of the page? * There's no longer any way to quickly jump to History or Information tabs when you're at the top of the page (and especially for long pages)? Thanks -Vincent
More about the skin proposal at http://markmail.org/message/nagihrc2xqpzw4dz
* Shouldn't we also display the creation date next to "Created by" at the bottom of the page?
We should decide if we display it or not. This info could be available in the Information tab.
* There's no longer any way to quickly jump to History or Information tabs when you're at the top of the page (and especially for long pages)?
Please take a look at http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/pageVi... I've added the History and the Related Pages (ex Information) to the menu. This way you have an easy-top access to it. We still need to think about the naming of the "Create" submenu. Create - Page - Space ? - Office Document - replaced with "Import page"? this also could enable the importing from other files
Hi, On Wed, Aug 12, 2009 at 3:44 PM, Ecaterina Valica <[email protected]> wrote:
* Shouldn't we also display the creation date next to "Created by" at the bottom of the page?
I also think keeping the date next to the creation date would be better as it provides valuable information about the "freshness" of the page + it's consistent with having the date next to the last edit. We should decide if we display it or not. This info could be available in
the Information tab.
* There's no longer any way to quickly jump to History or Information tabs when you're at the top of the page (and especially for long pages)?
Please take a look at
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/pageVi... I've added the History and the Related Pages (ex Information) to the menu. This way you have an easy-top access to it.
We still need to think about the naming of the "Create" submenu. Create - Page - Space ? - Office Document - replaced with "Import page"? this also could enable the importing from other files
I think it would be better to keep the "create space" on the wiki homepage only as it helps avoiding creating too many unnecessary spaces in a wiki, thus preventing "space clutter". Additionally, creating a space is a "big" action that has nothing to do with the current page while creating a children page does have a link to the current page. In the near future importing other types of files (specifically pages from other wikis) will be done by the administrator, not by all users. We might reconsider this at a later stage though... As for its name, I still think we could call it "Add" (add -> children page , add -> imported office document) rather than "create" as "add" is more generic but it's not a blocker for me. Guillaume
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
* Shouldn't we also display the creation date next to "Created by" at the bottom of the page?
I also think keeping the date next to the creation date would be better as it provides valuable information about the "freshness" of the page + it's consistent with having the date next to the last edit.
Again, if we add the date we gonna have problems on 1024 with number Tags displayed
participants (5)
-
Ecaterina Valica -
Guillaume Lerouge -
Jean-Vincent Drean -
Niels Mayer -
Vincent Massol