Improve the listing of XClass in the XClass picker

Development
1

Hello all,

Let’s start with an example. A project manager created an AWM to list product meetings.
Now, in a “December 2025 summary” page, they want to insert a dynamic listing of all the meetings help in December, sorted by date and labeled as performance.

The first step is to select the “Meeting” XClass, using the XClass picker. In the proposal I want to focus on the end-user (i.e., non-advanced, non-technical) use case. While keeping in mind the two other cases where XClass picker (Velocity classPicker macro) is used currently:

  • In the XObjects editor, to select XClasses
  • In the XClass editor, to navigate to another XClass

The current implementation has several limitations, leading to a poor user experience:

  • There is no notion of visibility: all the XClasses the user can view are listed
  • There is no distinction between technical XClasses and XClasses created by end users (e.g., through awm)
  • The provided details about the XClass are minimal and technical: space reference + page title of the class
  • The notions of XClass and XObject are technical and a probably poorly understood by end-users

Note: in the current proposal I’ll focus on the first two point and put aside the third and fourth ones for separate discussions.

What I think we need to achieve, is to allow end-users to have a listing of business XClasses (in opposition to technical XClasses).
I also think that this concept needs to be separated from AWM.
Of course, we need to keep in mind backward compatibility as well as the extensible nature of XWiki.

Option 1 - using hidden

Non advanced users see XClasses if they are not hidden, advanced users see all the XClasses.

Pros:

  • No new technical concept to introduce

I’m mixed about that one. In their current form. The pages containing an XClass are hidden and even with an XClass sheet applied, the result stays technical.
In addition, XClasses are often located in a Code space that is itself hidden.

But, when I look at Notion and Confluence, the closest equivalent, namely Databases, treated as a sibling concept to pages.
A navigation tree can contain pages, nested pages, and databases. Therefore, they are openly visible to anyone.

So the concept of only listing non-hidden pages with an XClass definition for non-advanced users would work only if:

  1. The content presented in the sheet is friendly to non-technical users
  2. They are located in a hierarchy of non-hidden pages (and this could be a migration challenge for AWM).

Option 2 - Using a “technical” concept

XClasses flagged as “technical” are considered as advanced and are hidden for non-advanced users.
Advanced users see all the XClasses.

Pros:

  • Non-technical XClasses are clearly annotated with an AWM independent concept

Cons:

  • Introduces yet another notion that we’ll have to maintain
  • We’ll need to update existing XClasses and extensions will need to be gradually updated too.

I find this approach interesting as it doesn’t prevent XClass pages to be hidden or not.
The XClass sheet could be improved/adapted to the presence of the “technical” flag, and propose a less-technical XClass editing UX when the flag is set to false (or missing).

  • 2.1 the flag is a XObject to add
  • 2.1 the flag is a BaseClass meta-property

Option 3 - All pages are “technical” by default

That’s the symmetrical appraoch to Option 2, technical pages are opt out instead of opt in.
The main difference is that existing XClass would be hidden to non-advanced users by default.

I’m -1 as I think it’s better to show to much and to hide that to hide too much by default.

Option 4 - do nothing

We consider all XClass are visible to all users, and instead solely improve the UI to search for XClass.

I’m -1 for that one as we already know that some concepts (e.g., rights XObjects) are technical (and eve, should be hidden to users based on the rights).

Conclusion

I’m +1 for option 2.2 as I think making the concept core is the cleanest approach.
+0 for option 2.1 if we want to stay with an easier implementation.

cc @lucaa as this is part of the larger discussion for Loading...

PS: follow-up proposals I’ll post later:

  • What additional information would be beneficial in the XClass picker (e.g., count of xobjects, additinal xclass hint, list of property names,…)
  • Use of the picker in a macro that would let users insert a list of XObjects as presented in the motivational use case
2

Hi,

thanks for opening that discussion, the picker would indeed need some love.

Now I’m currently not a big fan of the proposed solutions: AFAIK the xclass picker is mostly used in the object editor which is itself and advanced concept, so hiding technical xclasses based on advanced user or not doesn’t really make sense here IMO.

Another approach that I would find more interesting maybe, would be to have another picker UI allowing to better filtering of the xclass, and maybe that way we could emphasize the xclass that are in the current hierarchy. E.g. I’m in the space of my AWM, the picker propose directly the xclass found in the same hierarchy, so you don’t have to browse all of them.

We could also have categories, like we have for selecting a macro. So generally speaking I’d be currently -0 for all the proposals of hiding, and I’d be more in favor of exploring changes in the XClass ui picker.

3

A point that might not be so clear from my initial proposal is that I pla

4

A point that might not be so clear in my first message is that I plan to use the XClass picker for more use cases, in particular cases involving non-technical users.

In the cases of the class and object editors, it is probably best to force the editor in advanced mode.

This is interesting. Do you have mind mode a way to sort properties by their proximity to the current page?

This is also interesting. Note that I’m about to post another proposal to improve the data presented to users when picking a XClass.
A non-exhaustive list is:

  • An XClass description
  • The list of property names
  • The number of existing XObjects

Though, I still believe that hiding technical XClasses to users is beneficial. For instance the comments or rights XObjects are purely technical and there is no point in showing them to non-advanced users.

5

Do you have examples of such UC? That would help to see the usage for hiding xclasses.

Not really, I was only thinking about querying the parent space. But we probably could have better heuristics.

Yeah that was my understanding that you were planning another proposal.

6

FTR we had a quick call with @mleduc where he showed me an example of a UC which is about using the picker in a macro to list objects of a “business” xclass.

After discussion I still believe it would be better on the long run to be able to define labels on the xclasses and use those labels to filter the picker automatically and to present the results.

7

A use case that I will also present in another proposal is the need for a macro allowing non-technical users to pick an XClass, then select a list of properties, sorting criteria and filters. The macro then displays a Live Data.

In this concept, non-technical users are likely going to be confused if the list contains technical concepts.

Going back to this idea, let’s propose option 5.

Option 5 - introduce a notion categories for XClasses

This is close to option 5, but instead of a single boolean, it is possible to define a set of categories for a given XClass.

I suggest following the same conventions as the ones we use for the macros categories:

  • Two special categories exist: internal and deprecated, both are hidden for non-technical users
  • XClasses without one of these categories are considered as non-technical

In term of UI this implies have a way to filter by categories:

  • Option 5.1: a second filtering field
  • Option 5.2: a special category: prefix. For instance, category:photography, or meetings category:projectmanagement. The first query returns any XClass with the photography category, the second query returns any XClass with a name containing meetings and part of the projectmanagement category

In term of migration we’ll also need to discuss which categories to add on existing XClasses.

I’m +1 for 5.2 as it is less space consuming and I believe we want to keep the XClass picker compact.