UI for Managing user and groups

[tkrieck]

Hey everyone, I would like to put for discussion a UI proposal for managing the users and groups in Cristal. Overall, it should function a lot like the one in XWiki Standard, but there are some differences.

Screen Layout

The layout of this screen follows the general structure used across other content pages, with a few key differences:

• Introduction Line: Instead of the usual info line (which includes author, likes, comments, etc.), this screen features a description line that provides a brief introduction to the page.
• Create Page Button: The create page button, commonly seen on other screens, should be hidden on these Admin screens.

Content Structure

As the name implies, this screen is designed as a standard interface for managing users and groups within a selected backend. It can serve as a foundational template for similar future screens. Key elements of the screen include:

1. User/Group Selection: Allows users to toggle between managing either users or groups.

2. Primary “New” Button: A button for creating new users or groups.

3. Backend Selection: Allows the user to select a backend. This may either be:

   1. A standard dialog or dropdown for backend selection,
      OR
   2. A Link to another admin screen enabling the switch backends

---

Honestly, from these two options, I am not sure which one is best for our use case. Analyzing the pros and cons I came up with:

• Enable editing users from other backends, via the selection proposed:
  • PRO: Direct access to other users making the job of an Admin with multiple backends easier
  • CON Potential point of confusion. Did it change my whole instance to a new backend? Or did it change only for this screen?
• Enable editing users only from the current selected backend. Changing backends will happen only on one place:
  • PRO: Less points of confusion, backend changes happens only in one place in the UI
  • CON: To manage users from different backends the Admin will need to constantly change pages

---

4. LiveData Table: The main content area displays dynamic data and includes the following columns:
   • For Users:
     • Avatar
     • Username (with a filter option)
     • First Name (with a filter option)
     • Last Name (with a filter option)
     • Actions (e.g., edit, delete)
   • For Groups:
     • Group Name (with a filter option)
     • Member Count
     • Actions (e.g., edit, delete)

• Row Interaction: Clicking on any row within the table will open the edit screen for the selected user or group.

• Action Button: Each row contains an action button with the following options:
  • Edit: Opens the edit screen (the same as clicking on the row).
  • Delete: Prompts a confirmation dialog before deletion.
  • Why a button and not all actions exposed?
    • Easier to standardize. This list can be bigger on other areas
    • Less clutter on the UI
    • Easier to make mobile friendly
    • Exception: If only one action is provided, then there’s no need for the action button and the action can be exposed directly.

Admin Layout

The admin layout for this screen is designed to help users focus on administrative tasks by providing a separate workspace. This is being proposed in another discussion, but I will post here the main idea behind it:

• Dedicated Space: When users access Global Administration, the screen opens in a separate space where the main wiki navigation is unavailable. This prevents distractions and maximizes screen space for managing tasks.
• Return to Main Navigation: To return to the main wiki navigation, users will need to click an easily accessible “Go back” button.
  This layout and behavior helps to create a more focused experience in administrative tasks.

---

I think my main questions on this proposal is:

• Grouped actions on the Live Data, yes or no?
• Should we allow the backend selection on this screen?
  • If positive, will it change the context of the whole app?
  • If negative, perhaps we should give a quick switch UI for changing the backend globally

What do you all think?

[vmassol]

Just replying on this point:

@tkrieck

Should we allow the backend selection on this screen?

• If positive, will it change the context of the whole app?
• If negative, perhaps we should give a quick switch UI for changing the backend globally

This feels strange to me as the backend selection should be something that applies to the whole wiki and to all the actions. If we allow choosing the backend at this level (instead of a ore generic switch at the instance level), then we also need to do for all other admin actions.

So my preference would go to a global backend switch (which we already have in the UI, no? Maybe it’s visible only in view and not admin, I don’t recall TBH?).

Thanks

EDIT: I don’t think that having and wanting to manage multiple backends at the same time will be a very common use case. Thus I don’t think we should make it a priority in the UI. I’d prefer a leaner UI for the main use cases.

[tkrieck]

@vmassol

So my preference would go to a global backend switch (which we already have in the UI, no?

We do, but it is in a temporary place right now. It’s the cog icon besides the user avatar.

[mleduc]

Thanks for working on this!

@tkrieck

Primary “New” Button: A button for creating new users or groups.

Note: this is not going to be implemented for now. But looks good. I guess we’ll need some additional work to design the user creation form, which will highly depend on the backend.

@tkrieck

Enable editing users only from the current selected backend. Changing backends will happen only on one place:

• PRO: Less points of confusion, backend changes happens only in one place in the UI
• CON: To manage users from different backends the Admin will need to constantly change pages

+1 for that option. I don’t think managing users for several backends is a main use case. And admins will still have access to the “cog” from the admin pages already.

@tkrieck

Grouped actions on the Live Data, yes or no?

Could we consider a notion of main and secondary actions? Main actions would always be displayed as separate buttons, while the secondary actions would always be grouped under a “…actions” button.
I think this is useful to save a click for major actions like “edit”.

@tkrieck

Should we allow the backend selection on this screen?

Answered above, I’m -1.

Last one points. I think this proposal is missing details about pagination, which is an important part of the table Ui. Unless we have a more generic design rule somewhere but I don’t remember it.

[tkrieck]

Hi everyone, a long time has passed since the introduction of this proposal. The focus of the Cristal project right now is the integration with XWiki itself, so I guess this discussion might be outdated. Perhaps this proposal can still be referenced in the future, only for Cristal standalone, for simpler backends, IDK.

Nevertheless, I’d like to update this design with points that were discussed above and close this topic.

Below you can see both images updated, the main changes are the removal of the backend selection, adding pagination, and also providing a main action on each cell.

Users

Groups

Again, thanks for the attention.

[vmassol]

@tkrieck

The focus of the Cristal project right now is the integration with XWiki itself, so I guess this discussion might be outdated.

Anything that goes in Cristal also goes in XWiki (almost, there are features that are only for Cristal standalone but very few and mostly backends and offline).

If your proposal is the best design for users and rights, I guess we should have it in XWiki too, no?

As we discussed in the past, any proposal for XWiki needs to take Cristal into account and vice versa. If Cristal was modified to apply your proposed UI, then it would automatically find its way into XWiki when we switch the XWiki UI to the Cristal UI. Said differently, we need a UI for users an groups using Cristal technologies, so that when we switch XWiki to use the cristal UI, we can create users and groups.

Thx!