Improve the information presented in the XClass picker

Development
1

Hello all,

This proposal is related to Improve the listing of XClass in the XClass picker and place itself in the context of a non-technical user with the need of picking an XClass.

Note that I will not discuss the need to avoid presenting the technical notions of XClass/XObject to end users. That’s going to be for another discussion.

Currently, the information presented to users is the following:

  • Spaces
  • Page title

The XClasses are grouped by space.

image
image1366×980 58.6 KB

In my option, the proposed information could be improved to

  • Help distinguish between different choices
  • More easily find and discover the available XClasses

To give a broad idea of what we aim for, see the screenshot below, that I’ll detail afterward. Take the visual with a grain of salt, this is not fully accurate.

image
image990×1030 77.6 KB

Other UX aspects to consider (mainly for @tkrieck)

UX1 scroll or pagination + display of the count and advanced toggle at the bottom.

Currently, the list can simply be scrolled down when there are more results that the vertical size can fit.
If we wish to display something at the bottom, we could

  1. display them at a fixed position at the bottom and keep the scrolling for the XClass listing
  2. Add a “more…” button at the bottom to add more entries

Conclusion

I’m +1 for I1, I2.
I’m +1 for I3 if it is not too slow to execute (since we’ll probably need to take into account the view rights of the current user, which can add complexity). But I’d like to validate that we find this information useful first.
I’m +0 for I4. We usually don’t offer a toggle to switch to advanced. But, it might be useful in cases where the user looks for something, and can’t find it because it is considered advanced for some reason.

UX1.1 seems good enough for me.

Thanks for reading.
WDYT?

2

Thx for working on this. Before replying, I’d need a bit more context (sorry for not having followed).

I see that we had already a design page for https://design.xwiki.org/xwiki/bin/view/Proposal/XClassPicker

I don’t see it referenced from your https://design.xwiki.org/xwiki/bin/view/Proposal/XClassPickerImprovements

Did you review it and took its content into account for your new design?

Was there some discussions with @tkrieck done already (usually Thiago helps us doing the UI/UX analysis upfront), and with some stakeholders?

Thanks

PS: I think you’re missing I0 which is the XClass title

3

The use case that motivates improving the XClass picker is the design of a new macro that would allow non-technical users to pick and xclass, define the properties they like to display, define sort/filter setting. And, get a Live Data displayed.
The goal is to make this macro easily usable by non-technical users.

Thanks, I had indeed missed it. I’ll read it.

I discussed it with Thiago indeed. Stakeholder will be involved (cc @caubin and @lucaa).

4

Thanks for mentioning this page @vmassol, very interesting read. See below a

Where the two design pages aligns:

  • The need of classes description
  • The need for categories for classes. Discussed in a separate proposal, the main difference being that I think we need to be able to have several categories per XClass (e.g., Development, Internal).

What was missing in my initial proposal:

  • Issues with Nested Spaces, broking the alphabetical listing of the classes. Thought it never felt like an issue when using the picker for me, but I’d like other opinions.
  • No highlight of the searched word. I indeed think this is interesting in terms of UX.

What’s not clear to me:

  • “No preview for the end result” I’m not sure what kind of preview is expected, an XClass can be used in very various ways and picking one and representing it visually feels difficult
  • “No consistency in the way we add different entity types”

New concepts we can postpone:

  • “No listing for related classes”. While this feels interesting, in don’t have supporting use cases in mind

What I disagree with:

  • “No link to the class documentation” In several other discussions we reach the conclusion that UIs needs to be self-contains and self-explainable, and that linking to external documentation is a maintenance burden and does not work for instances with no internal connection.
  • The idea of moving to a modal instead of a picker: nesting modals is a pain and the picker is likely to already be integrated in modals. So I’m in favor of staying with the current picker/dropdown UX
  • Displaying the count of classes per-categories. I’m not sure if this brings useful information. Also, it raises the same scaling issues as the other counts when we start taking into account user rights.
5

One point that was considered in the 2018 proposal: consistency with Macro dialog, and possible future such pickers for Panels, Dashboard Gadgets, etc. I feel this could be important and it would be nice to have similar/same UIs for all these use cases.

WDYT?

I’m pretty sure Caty was thinking about something like an image to show what it would do. I think she was thinking in more generic terms than just the XClass picker, like when you pick a Panel, a Gadget or a Macro, it’s easy to imagine an image showing what it would look like (at least through a static image, possibly a live one but that’s harder). I don’t think it’s very different for the Object editor, where we could show an image of the rendered sheet associated with the class (if any).

Now, 1) this is not so easy to do and 2) since the XClass picker is meant to be generic and thus the images would need to be defined per use case (ie at the usage location), which makes it even harder.

Thus I think we should postpone this for now BUT if we use the same UI component for the picker of various stuff (Panels, Gadgets, Macros, XClass, etc), then we may want to have some optional images allowed.