Proposal for UI improvements on the Extension Manager

Hi everyone, I would like to propose some changes to the current layout of the extension manager. This post is a summary of the changes, and a bit more detail can be found on the proposal itself. https://design.xwiki.org/xwiki/bin/view/Proposal/ImprovementstotheExtensionManagerUI#HOptimizeLayoutforEfficientSpaceUtilizationandReadability

Addressing Current Issues

Background Color on Mouse Over

The current background color change upon mouse hover across the extension area can be misleading, as it suggests an interactive element even when none exists. Proposal: Remove the background color change on mouse over.

Differentiating Installed and Available Extensions

The simultaneous display of installed and available extensions can clutter the user interface. Proposal: Separate installed and available extensions into two distinct sections.

The installed extensions section would be the default view, featuring a primary button to “Discover New Extensions.” This dedicated button promotes visibility for exploring new extensions, while keeping the installed ones easily discoverable.

When in the installed extensions view, the search bar will be simplified, omitting filters such as “Indexed,” “Compatible Only,” and “Supported Only,” which are more relevant for new extension discovery.

Activating “Discover New Extensions” will transition the user to a filtered view of available extensions, which is currently the default. This view will include the complete set of search filters and a back button to return to the installed extensions page.

Lack of Extension Voting

The current star rating system for extensions is largely ineffective, as most extensions have no votes, and even the most-voted extensions have minimal engagement (e.g., three votes).

Proposal: Eliminate the star rating system entirely.

Streamlining the Extension Installation Process

The current extension installation process involves multiple, often unclearly labeled steps, leading to a disjointed user experience.

Ideal Scenario (One-Click Install)

Proposal: Implement a single “Install” action that initiates and completes the process without requiring intermediate steps. A unified progress bar would display the entire installation progress (currently divided into two discrete steps). All necessary dependencies would be automatically installed. To enhance clarity, a title (e.g., “Checking dependencies” / “Installing”) would appear above the progress bar, describing the current step.

Screenshot 2025-05-29 at 14.45.13

Alternative (Improved Multi-Step Process)

If a multi-step process remains necessary, we propose clear, action-oriented labeling for each step:

  • “Install” → “Add to XWiki”: This label would indicate the initiation of the process, clarifying that no installation has occurred yet.
  • “Continue” → “Install”: This step would clearly indicate the actual installation action. The progress bar would remain unified across these steps but would pause while awaiting user interaction (e.g., clicking the “Continue” button).

install step 1


install step 2


install step 3


install step 4


User Control and Interface Optimization

Progressive Disclosure for Technical Details

Excessive technical details are currently displayed by default during installation/uninstallation, potentially overwhelming non-technical users.

Proposal: Hide detailed technical information by default. This information would only be shown when user interaction is required, such as when the uninstallation process warns of page deletions. This aligns with the principle of progressive disclosure, presenting only essential information initially and allowing users to access further details if needed.

Cancellation of In-Progress Installations

Users are currently unable to cancel an installation once it has begun, limiting their control over the system.

Proposal: Provide a clearly visible “Cancel” button or option during the installation process. This empowers users with control and allows them to exit unintended or lengthy operations.

Standardizing Iconography

Inconsistent use of icons, deviating from the established IconTheme.

Proposal: Replace custom or non-standard icons with equivalents from the IconTheme wherever possible to ensure visual consistency.

Optimizing Layout for Space and Readability

The current layout utilizes space inefficiently, causing extension descriptions to truncate prematurely, particularly on smaller viewports. The search bar header can get improvements.

Proposal:

  • Relocate the “Install” (Add to XWiki) and detail buttons to their own row.
  • Remove the star ratings.
  • Remove icons from extension titles, as most extensions use the same icon, diminishing their utility. A new layout for the header containing the search bar is also proposed, adapting its filters based on whether the user is in the “Installed Extensions” or “Available Extensions” section.

extension item (1)

As always, I invite you to provide feedback on the proposed changes. Thank you very much!

The back button here looks confusing to me. It’s not easy to understand what is the step before Available Extensions. I’d rather have another button with an explicit label to switch the mode back: Installed Extensions.

Note that those star displays have been coded a long time ago and were a pain to update for accessibility. They are hard coded using pictures and do not really fit well with the vector based iconthemes like Font Awesome 4. Removing them would also mean reducing technical debt.

See Loading... :+1:

I’m not sure why we’d keep multi-step installs if we implement cancelling installation.
This is just my opinion, but I think Add to XWiki is not a good action name, especially when all we do is check for dependencies. I think we can be a bit more technical than usual with button names since this is an Admin UI. IMO Check for dependencies + Install with <X> missing dependencies is a long but descriptive combination of buttons.


Thanks for starting this proposal!
Lucas C.

1 Like

Not a problem, we could name it Installed Extensions and also provide a back icon.

Sometimes the dependencies check can take a long time and seems to be stuck.

I must be honest that I had trouble finding something for this action, lol. I wanted something that indicated “Cool, I want to try this extension” but without the technicalities. “Check Dependencies” is very dev oriented (even for an Admin UI) and doesn’t convey the action that the user might want, I guess that’s why it’s called “Install” currently, even if it doesn’t install anything right away.?

Thanks for the feedback!

Hello! Thank you for this proposal, it is very needed! :star_struck: :star_struck:

I have some quick notes on it:

  • We should really try to implement one-click Install

  • I’m all for eliminating the star system rating

  • The new search input looks really great!

  • Does this proposal include the usage of Pro Apps in it or just focuses on the open source apps?

  • Could we rename extensions to apps? Everyone these days refers to extensions as plug-ins or apps.

  • Once the user installs an app, I really think he’ll revisit it only to update or uninstall it or, in the case of a pro app, extend its license. Thus, we don’t need to showcase all details for installed apps. Keeping them collapsed would be better, I think, for space-saving.

  • The action buttons would look better …

    • …on the same line with the title in the top right (I understand that for mobile this doesn’t work great, but I think we can apply some rules so we make the buttons go on a separate line after the content for smaller screens)
    • or
    • …left aligned under everything (left-alignment stays consistent with the F reading pattern)

…and one bigger note:

Better discoverability

While I think it’s great that we unite the UIs for installed apps and discoverable apps, I think discoverability of apps should be prioritized in terms of order and space ocuppation on the screen as apps/extensions are a big selling point of XWiki.

In your proposal, the discoverability of the apps is encouraged only through a button, but the main initial UI is occupied by installed apps (if I understood correctly)

Suggestion:

Splitting the page in 2:

  1. A “teaser” for discoverable apps - Some example of apps. No need for all details, just a name and a short description would be enough. Somewhere a button that leads to the full page with all apps and their details as you designed it.

  2. Installed apps with expandable details

A quick mockup of these ideas:

Note: I used some Pro Apps as examples in the Discover new apps section, but it can work with any XS apps, obviously

There’s no knowledge of “pro apps” on this forum so for the readers, @amilica is referring to https://store.xwiki.com/ which is an offer from a sponsoring company, see https://www.xwiki.org/xwiki/bin/view/Main/Supporters/SponsoringCompanies/ (and https://dev.xwiki.org/xwiki/bin/view/Community/Governance).

@amilica note that apps on https://store.xwiki.com/ are all 100% open source. The code is available at XWiki SAS · GitHub

In XWiki terminology an Extension can be an Application (ie having a visual aspect) but also an API, a Color Theme, a Macro, etc. See some known values there: https://extensions.xwiki.org/xwiki/bin/view/Extension/Repository%20Application#HCategories

Renaming to plugins would be possible but I’d be -1 and in any case it’s almost impossible to do (would cost way too much, you cannot imagine how many places we’d need to change). I prefer personally Extension to plugins.

See also:

Extensions are designed to extend/modify the functionality of your website while plugins perform a particular task or set of tasks.

source: https://brightplugins.com/plugins-and-extensions-difference/

PS: “Pro apps’” is a misnamer, it should e “Pro Extensions”. It happens that most (if not all) of them are currently applications but that’s still not the right name IMO.