Your XWiki usability pain points

[dknt]

Hi mflorea,

I am fully aware that you can not simply go and “fix” everything, but thank you for listening and considering (any of it)!

@mflorea

Yes, because when you tell the tree to open to a specific wiki page (e.g. the current wiki page) it makes a few asynchronous requests, after the current wiki page is loaded, to open all the tree nodes up to the target page. We can fix that by passing more information to the tree on page load, e.g. the open to path along with the sibling nodes for each path element. With this tree will open instantly, but the page load may be delayed a bit, depending on the size of the page hierarchy. A further step, but I’m not sure it’s needed, is to store the navigation tree data (JSON) on browser local storage so that on page load we can display it right away. The outdated information would be fixed with some asynchronous requests and merging.

Ok, sounds like a plan. I am not against such tree-structure menus. If it feels smooth and is usable, I am very ok with that. One minor thing is that the font size of the current menu is a little bit on the smaller side, while our users demographic is more - well a tad more on the older side. But I guess this can be easily tweaked with CSS(by ourselves)

@mflorea

The accordion you see in the administration doesn’t scale. It fits well for two levels, but it’s not suited for any number of levels. I don’t see how we could use it for the navigation panel, unless we go for a solution where we display only two levels of hierarchy at a time (and some link to go back up the tree, like cd ..)

I am not sure what can be done with the implementation you have at hand, but here are two examples of accordion menus which can be nested pretty deep:
[https://codepen.io/dantel35/pen/JjrWqVP]
[https://codyhouse.co/demo/multi-level-accordion-menu/index.html]
But I actually think that “unlimited” nesting is not the best thing, as it gets confusing pretty quickly. Collapsing some of the levels after a certain depth with a “cd …” option sounds really good.
As said, I am not all for accordion, tree structures can do the job as well with a little bit polish.

@mflorea

The toolbar I see in your screenshot is too crowded for my taste

This part of the toolbar actually only appears in the confluence editor when you are dealing with tables and is invisible otherwise, it is context sensitive. So it is not that full all the time. But I also think that this is not the non plus ultra design.

@mflorea

The toolbar I see in your screenshot is too crowded for my taste. What we can do (and it wouldn’t be too complex) is to create a Balloon Toolbar - CKEditor 4 Documentation with the table features. This toolbar would be visible (floating) when the caret / selection is inside a table.

This actually sounds very good. If you could eliminate the need to dive into submenus with such a baloon toolbar (one on top/bottom for the rows, right/left for the columns - or something along those lines), this could make things much more fluid in this regard.

PS.

@mflorea

Try https://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide/Features/Navigate/#HJumpToPage .

Thanks, this is a really good tip! Very nice for power users.

[mflorea]

@dknt

One minor thing is that the font size of the current menu is a little bit on the smaller side, while our users demographic is more - well a tad more on the older side. But I guess this can be easily tweaked with CSS(by ourselves)

Regarding this, the Navigation Panel uses the same font size as the other panes (Applications, Tips, My Recent Modifications). So this is a global style. Now, if you want a bigger font size (globally) one quick option is to “Enable extra accessibility features” in your user profile. It does a little more than increasing the font size though. See if you like it.