Global Administration UI Revamp

It’s not about responsiveness but about the space it takes on the screen and the fact that the more elements you add the more cumbersome it is.

What I also don’t like is the submenus shown in the page content. I think it’s cumbersome to fold/unfold an entry.

Overall I feel that the current menu is a better UI that is easier to understand and navigate. The downside is that it takes more horizontal space but ATM I haven’t seen a proposal where I thought to myself that the tradeoff was better. It’s good to have more horizontal space but not at the expense of usability.

I’ve never liked option 1! For the same reason mentioned above. I don’t understand at all the need to have the submenus in the main content area since there’s a menu on the left. You loose everything! Both screen estate and usability.

What I said I like the best so far is option 1, but without the extra menu in the content area (what I call the submenus), which is what we have now basically but with a difference: directly navigate to a subsection and display its content, ie no special home page for the Admin UI.

I currently really don’t like the accordions used for the submenus, in the main content area.

One alternative that wasn’t shown I think, is the ability to somehow fold/hide the current menu when you’re on a topic, with the ability to hover over (or something like this) to unfold/unhide it and navigate to some other section.

I also want to mention that when I talked to you about improving the Admin UI, it was mostly about changing/removing the main content area (which currently duplicates what’s in the menu and should be removed IMO), more than other changes (I find the current menu to be really nice and usable).

Thanks!

Okay, so at last, I came back on this.

I tried to reunite the feedback of everyone and take into consideration what everyone what liked and didn’t.

I hope this is a good compromise.

Default state / Initial view of Global Administration

first view of global Admin

Explanations:

  • when the user enters GA he sees the info box pointing him to documentation, forum and a FAQ
  • the menu is not yet opened
  • the menu main-sections don’t have a border
  • the menu main-sections have bolded text for better visual hierarchy
  • the menu occupies only 1/5 of the available space (in this panel configuration - probably the most common)
  • the search bar doesn’t have a shadow in the default state
  • the search bar has light font-weight to differentiate better from the menu sections.

User clicks a sub-section of the menu

selected sub-menu

Explanations:

  • the friendly/expanded title of the sub-section gets rendered above the actual content. Why?
    • to improve visual hierarchy
    • to make very clear which sub-section is clicked (the current way this is shown in the menu is not ideal. The most prominent element is the main section, not the sub-section clicked)
  • there is an easily available link to documentation for the specific section
  • the menu can be collapsed
  • if the user hovers over the icon besides “Global Adminstration”, a tooltip will appear on top of the content with the info box from default box
  • the sub-sections in the menu have a border unlike the main sections

User collapses the menu

  • note: the chevron needed to be reversed in the mock-up (will update the final proposal on the design wiki)

collapsed menu

Visual explanations (if you need more)

analisys

Advantages of this version

  • doesn’t duplicate the content (as the current version does)
  • it enables to view the content in a larger space if the user wants that
  • makes product information easier to access
  • doesn’t change a lot of things
  • the changes are not very hard to implement
    • the menu look can be updated based on CSS (probably even just from Advanced Customization)
    • the state of the menu (collapsed or not) doesn’t need to be retained if the page is reloaded, so the collapse button essentially just hides the menu and resets the width of the content to take the whole available space (and reverse)
    • the tooltip is… a tooltip, so hopefully it doesn’t imply any difficulties (if we don’t like tooltips, we can always go with a modal appearing if the user clicks the icon)
    • the title of the sub-section and the documentation link need to be rendered based on the sub-section clicked, but, as we only have a limited number of subsections, it’s just a static list of info.

What do you think?

Thanks a lot for reading this and let me know your thoughts on this version! :blush:
I’d really want to get a decision on this proposal until the end of the month. ^^

Tagging the people that already got involved a lot in this proposal (lots of thanks again): @watery , @nikpetrenko , @vmassol , @tkrieck , @CharpentierLucas , @pjeanjean

1 Like

Thanks @amilica

Some thoughts:

  • Sounds good
  • Still wondering if we could display something more interesting in the GA home page than documentation links. Admin-only news might be more interesting, idk (this would be what can be seen at https://www.xwiki.org/xwiki/bin/view/Blog/What's%20New%20for%20XWiki%3A%20Admin%20User ).
    • At least that will let admins know about new releases (of XWiki and extensions). My only hesitation is that this info is already available in the what’s new feature (but not just admin news there, even if currently most news are admin news).
  • I’d point to the Administration Guide instead of general documentation.
  • I think we need to discuss more globally your idea of putting question mark icons after the title (and doc link to the right of level 2 headings) since this is not something we’re doing elsewhere AFAIK and if we want to go in this direction, we need to generalize it (for example, in user profiles view just to name one other place).
  • If I understand correctly, when clicking a section (like “Users & Rights”), the “Welcome to Global Administration” box will appear or remain, right? And users need to click a subsection to see the content change.

Thanks

Looks good to me overall :+1:

I have a couple small comments though:

For the style used for the expand/collapse button. IMO we should use standard button styles, i.e. rounded corners and default colors. Nothing prevents us from putting the text into the button itself, to get a final style similar to the page create button:
image

The tooltip is displayed on hover but we should also give a way to display it for keyboard only users (or any user that can’t hover, like a touchscreen user). This is a detail that might come only for implementation but I figured it’s still important to mentation. This activation could be on focus or when pressing enter (“clicking” the button with the keyboard).

From what I remember one idea for Loading... was to create a Panel and just put this panel in the drawer. We could use a similar panel in the GA Home Page. We can probably use the time spent to make a panel for both :+1:

Some thoughts on this:

From what I experienced, our current navigation in the administration is not easy to discover for users. New users I watched were using the icons in the main part of the screen, not the menu on the left. Maybe removing the entries in the main part helps to put focus on the navigation, but I’m not sure. Maybe this kind of UI pattern is not obvious/well known enough? In that same direction, I’m wondering if that “Collapse menu” link is discoverable enough and if users will easily find how to expand the menu again. Also, this link seems to take quite some vertical space also for the main content. How would this collapse menu button work on mobile?

The white space left of the “info box” and the white space inside the info box looks quite strange. How would this white space change depending on the screen size?

Also, I’m missing the use of common design system. For example, you suggest removing a shadow from the search bar. In my opinion, we should keep this consistent with all other inputs in XWiki - we could change them, but then we need to change all of them. Same for the placeholder. XWiki needs to have a consistent look and feel to be recognizable as one application and not a mix of many independently designed components.

This is not true. Extensions can add their own subsections. We need a proposal how the documentation link should be provided.