Usability 10.x analysis and 11.x suggestions

There is another thread that discusses 11.x roadmap in more generic terms, but I wanted to be a bit more specific to Usability related issues in this thread (since that thread also contains technical challenges, etc.).

I’ve made a comparative analysis regarding the work done regarding Usability in 2018, compared to 2017. You can read it here:

I’ve also created a list of TOP 5 improvements / features we could consider for the 11.x cycle that could improve the usability of XWiki in my opinion. You can find the list here:

What do you think about the issues listed there? Do you see other issues more important and that need faster attention?

Thanks Caty.

Some comment:

We have a significant decrease of -48.72% percent of reported issues compared to last year.

that’s in red but it can be seen as green, less usabiltiy issues :slight_smile:

We have a significant decrease of -52.38% percent of reported issues compared to last year.

Normal since we have 50% less issues reoprted :wink:

From the top 10 at the bottom, seems that we worked on more important usability issues this year :slight_smile: (but there are only 3 listed for 9.x)

Also maybe some issues are missing the usability label?

@evalica Should this be a blog post with a call to action to ask users what are the most important usability issues they know about in XWiki 10.10+ and to ask them to mention ideas for the 11.x cycle at ?

Regarding my personal opinion is that not many of the items listed help newcomers. It would be great if we could simplify the XWiki UI even more since right now the main feedback I hear is still that XWiki is too complex to get started in general. Maybe there are more stuff we could hide by default (either under advanced users profiles or other places), and that could be discovered later on. Another feedback I got some time ago is that some user do not understand that they can create pages in pages and they’re looking for ways to create a folder and cannot find it.

I will post a general summary bog post of the 10.x cycle in December.

Regarding the issues selection, indeed it does not contain only newcomers issues, but has at least 2 (the logo and the create button). The selection is a top, but I agree it would be nice to make XWiki as easy as possible for newcomers.

What about working on the “Rights” entry in menu, see here: ?

1 Like


Are there any plans to adjust the edit macro form? I’ve had users asking me if it’s possible to resize some of the input fields. The code macro is a popular example. The size of the form seems to work OK on low resolution screens but doesn’t scale proportionally on larger screens. A full screen option might be useful too.

Suggested inputs would also help, or drop down menus in some instances. An AppInMinutes form like creation toolbox would be great for prospective macro writers.

What do you think?


If you are referring to this screen
The textarea element has a resize element in the bottom-right corner. This element’s display depends on the browser, but resizing is possible.

Indeed we could improve all the textarea elements in Edit Macro modal by making them to have a bigger default height, using the “rows” attribute (a good value would be 5-7). Would you like to create an issue with this improvement since it was your idea?
Still, even if the new height is not good enough for the users, the resize is still there and available.

Regarding the larger screens: we are using the Bootstrap 3.3.7’s modal, and this modal caps at a width of 600px for resolutions bigger than 768px. In Bootstrap 4.x, the modals get even smaller, capping at 500px. So the width of the modals and their content will be fixed and capped for now.

Regarding the full screen: since modals are on a different/upper layer than the main interface, adding an extra / additional layer on top of modal (in order to suggest the full-screen of textarea) can be confusing for the users. Going into more than 1 stacked layer assumes the users remember in what layer and at what level they are.
Technically I don’t know how hard would be to add full-screens to textareas in that modal. @mflorea might know more. But from an usability perspective it would be confusing.
Now, we worked on this topic (Inline Macro Content Editing, see in XWiki 10.10. Currently the inline editing is done only for a limited number of macros (box, info, etc.) but maybe code macro could also be a candidate. Being able to edit the content inside the page, even using the fullscreen of the editor, would be a better solution than providing fullscreen for individual textareas in modals.

Yes, I would like suggests, selects and default examples too. There is a proposal made (example, but we are not currently working on it, and I am not sure how hard it is to implement. Ideally, we should provide examples and good defaults for the macros so that the user can just select or even just press enter when wanting a macro.

I am not sure what this means :slight_smile: maybe you can give more details.

FYI we are currently working on suggests for macro parameters that are references (like the reference or document parameters for the include/display macros). See for details.

Now we’ll need to work on other macro field types in the future too.

1 Like

Thanks for the reply Caty.

Sounds like inline editing is the way to go. It would make life much easier when editing word heavy macros like the code macro. Big fan of editing in context so you have my full support! From a user perspective, will it be possible to create custom macros that can be edited inline?

For now:

The large option here feels better on my desktop. But if this is going to shrink anyway then maybe it’s not worth it.

This doesn’t seem to work in IE11. Jira raised:

Done. See

I don’t know. Maybe mflorea or someone else knows more about this.

Currently we are not supporting Bootstrap 4 and don’t quite plan for supporting it (since they are backwards incompatible with their 3.x cycle). We could maybe develop a custom size for the modals, but this is not planned.

Thanks for the issue reporting.

It is, you can see the documentation there:


Interesting! thank you.

That’s for the rendering macros implemented in Java. For wiki-based rendering macros there’s currently some limitation, see .

11.X Suggestion: Support nested tag taxonomies

Rationale for need: We are trying to organize technical design guide pages by company group, but there is a lot of overlapping / common topics. For example, we can have content related to bearing design under the Machines group as well as the Turbine group. We’re using the tag construct as a topical grouping mechanism; however, we have so many tags that we would like to be able to organize a taxonomy such as:
– rolling element
– journal
– etc.

You might find useful this extension

Thanks for reporting