Needed Improvements

  • Create/Add/New menu (discussed)
    • This is the more frequent queries from people arriving to XWiki on their own here. How do I create a new page?
    • Less visible in their current position
    • Content: Page, Page from Template, Page from Office Importer, Space, etc.
    • Naming for Create/Add/New Pages/Spaces/etc menu
      • Create:
        • You can add comments and tags, but I think it's more appropriate to create pages
        • XWiki implementation uses "create" action not add
      • Add:
        • "Add" (add -> children page, add -> imported office document) 
        • "Add" is more generic, widely used
      • New
        • like desktop applications
  • Naming of Wiki/Space menus are really difficult to understand for a user. Suggestion: Wiki (Wikiname) Space (Spacename)
    • I'm not sure using the database name as the menu name is a good idea. First, what do you do with a menu named GTLLMIPY? Second, how do you document it so that people can easily understand what you're talking about? Impatient people will just look at the pictures and see the XWIKI menu, which they don't have.
    • Usage of pretty names for wikis in wikis descriptors, instead of their technical wiki id.
    • Take into consideration menu in editing mode cancel Edit: WYWIWYG
    • Adding a visual sign between wiki|space in the global menu to imply hierarchy
  • Uppercase usage: "MySuperSpace" looks like "MYSPECIALSPACE"
    • Solution (for another skin): don't use capslock, but this shouldn't be changed for Colibri (Colibri uses uppercase for buttons, form label, menu, docextra)
  • Further separation: Wiki, Space, Page, Content actions 
  • Possible additions: "Send by email" (under More actions); "Dashboard", "Document Index" (under Wiki/Space)

Other Problems

  • Scrolling problem: need to scroll to the top of the page to see actions.
    • Solutions:
      • use shortcuts,
      • have a vertical icon menu floating next to the page content, on the left,
      • fix menu when scrolling
  • The icons are not suggestive enough. Why is Edit Class a box? Why is Export as RTF using the MSWord icon?
  • 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.
    • Solution (for another skin): Swap the position of global menu with the logo (see also variation)
  • Watch Toggle action is compartmental identified, the visual distinction from the other menu actions is low (ex Watch active/inactive state)
  • Better visual distinction for "implicit" menu item
    explicitHoverStates.png

Other Ideas

  • Way to handle the actions we are not able to do (depending on the rights we have): enable/disable them or hide them
  • Clear separation between (we need to document what goes where):
    • Advanced/Simple mode aka. User/Developer mode
    • Administrator 
    • have/not some rights (ex. copy needs programming; xar needs admin)
  • Administration option to hide/show menu icons
    • proposal with full/partial/no icons

ActionMenu elements we explicitly voted for / discussed

  • "More actions" instead of "Actions" 
  • No "View" menu, data now found in #document-info shortcuts
  • "Dropdown layout" (more extensible) preferred over "Tab layout"
  • Content action closer to content
  • Usage of full icons (versus partial or no icons)