Only support 3 color themes in XS

Development
1

Hi everyone,

we’re working a lot on improving the UI of XWiki lately, and in particular to improve accessibility. I noticed during discussions on the chat that we currently have a lot of themes in XWiki Standard (more than 15 and probably around 20, see: xwiki-platform/xwiki-platform-core/xwiki-platform-flamingo/xwiki-platform-flamingo-theme/xwiki-platform-flamingo-theme-bootswatch/src/main/resources/FlamingoThemes at master · xwiki/xwiki-platform · GitHub and https://extensions.xwiki.org/xwiki/bin/view/Extension/Flamingo%20Theme%20Application) and I don’t think it’s a good idea to keep them all.

We would benefit on getting rid on most of them to have less maintenance, to ensure that they’re all testing, and that accessibility is met on them. Currently we only test a very little subset (I’m not even sure more than 2 of them are tested), and I’m almost certain that accessibility is only met on one of them (to be confirmed by @CharpentierLucas).

So my proposal would be to only support 3 color theme:

  • a clear theme
  • a dark theme
  • a high contrast theme

Other themes can then be moved to an extension.

wdyt?

2 Likes
2

+1

3

:+1: Usually I only test with Iceberg. When I introduce non-trivial UI elements I also try to make sure they are compatible with Darkly (my personal reference for a dark theme). We don’t have any automated test for flamingo color themes except Iceberg.

In my opinion theme personnalisation is fairly easy as of now, and I doubt many administrators really make use of all the colortheme variations we support. All of those themes contain some custom styles that can make them heavy to maintain when operating UI changes. Most of these custom styles are very similar and often flood results when looking for a specific style in the codebase. E.g. Code search results · GitHub where the first 4 finds are actually what I would usually look for, and the 15 after that just barely used LESS from some color themes.

For the clear theme, I think keeping Iceberg is the obvious choice. For the dark theme, I propose to keep Cyborg (palette is more neutral than Darkly ^^’ ). AFAIK we don’t have anything close to a high contrast theme yet. The goal of a high contrast theme in my opinion would be to fulfill WCAG AAA level contrasts: 7 contrast ratio on regular texts and 4.5 for large texts. For reference, Iceberg right now in most places just has a 3.5 contrast ratio.

If we only keep three themes in xwiki-platform, it might make sense to rename them to easily understandable names. E.g. : Light, Dark & High Contrast.

:+1: from me, I don’t think it makes sense to keep all of those themes in the standard flavor.

Thank you for this proposal!
Lucas C.

2 Likes
4

+1

also +1 to this

5

Just an opinion from an admin (with no great requirements about ).

Wow, 20 are really a lot! I maybe checked one or two when I originally installed our instance (actually using Iceberg).

My two cents, maybe you could offer two themes for each category instead of one; in this way if one wants a dark theme she can chooose between two alternatives.

6

The github link shows 16 themes while the doc on exo says 21… And when testing in XS 15.10.x I get 21 themes. So the link to the theme is not complete.

EDIT: You’re actually missing all the non-bootswatch themes at xwiki-platform/xwiki-platform-core/xwiki-platform-flamingo/xwiki-platform-flamingo-theme/xwiki-platform-flamingo-theme-ui/src/main/resources/FlamingoThemes at d8832778fec9f6ba8f4af438654f2d6420bd91c7 · xwiki/xwiki-platform · GitHub (there are 5).

Caty worked a lot to include all these themes in the past, to provide a choice to our users. I think it’s a good thing. Up until now they didn’t cost us much in maintenance (close to zero actually). It’s just that we’ve now started to make them WCAG compliant, and we indeed need to make them be WCAG-compliant at maximum.

This is a problem :slight_smile: In the WCAG work, we need to make all our pages be WCAG compliant (unless there are good reasons not to - maybe it’s not possible to be WCAG-compliant for some themes?).

This is something we discussed and we even have a strategy for it. We discussed introducing some functional tests for WCAG purposes only. Here it’s very easy to introduce a test that sets all themes one after another (and thus Axe Core will be executed on the resulting HTML).

Whether we keep 3 themes or 21, we still need to do this.

I’d have said the opposite. I don’t think many users trouble themselves with customizing themes. IMO they pick one with the colors they like the most. And it’s quite nice when you use multiwikis to have several themes with different colors.

Also, supporting some themes which are essentially the same but with only color changes is not going to be costly at all (after the initial work of choosing the proper color contrast).

Are you referring to bootswatch themes vs the other 5 original themes? (see also https://extensions.xwiki.org/xwiki/bin/view/Extension/Bootswatch%20Themes%20for%20Flamingo).

So what I’m saying is that before we decide to drop them (always easy for us to decide this as devs since it simplifies our life :)), I’d like to make sure that:

  1. There are really themes not used by our users
  2. That the maintenance is really costly

If we move some themes to contrib, it’s the same as saying that we’re dropping them altogether since we’re not going to work on them (since the point is to reduce maintenance ;)), and nobody else will. So we really need to be sure they’re not useful.

So right now, I’m more -1 without having explored the 2 points above.

Note that we dropped supporting several skins because that’s too costly but we had several themes to compensate. Removing themes makes it harder for users to have easy variations in their L&F. In addition users will be tempted to edit the default themes which isn’t great as this can cause conflicts when we make changes to them.

Last, other tools like Notion offer tons of themes and reducing what we offer is not going in the right direction IMO. The only reason to do so would be our incapacity to maintain it, which is why I’m asking about the cost of maintenance, because if we can maintain them, then we should keep them IMO.

1 Like
7

As far as I know Notion is not a good example as it only support two themes: Light and Dark.

8

+1, but I think the category Clear theme and High Contrast theme need separate voting to make it clear which ONE theme belongs here. I’m using Readable and for me it’s theme clear and high-contrast.

9

I checked before mentioning it :slight_smile: and you have thousands of supported themes for Notions (not by Notion but it doesn’t matter, users still have a lot of supported themes available). My point was that moving the majority of our themes to contrib means that they won’t be supported anymore and the proposal is to end up with only 3 supported themes for XWiki users.

1 Like
10

To me, it’s more making official what is the current situation, as most themes have a lot of problems that we never fix.

11

My proposal is to fix them and at least to evaluate the cost of fixing them (i.e. that they pass WCAG tests) :slight_smile:

Now it’s not all or nothing. There could be some themes that are not used/interesting to keep, idk.

12

That’s what the proposal is about, deciding a shorter list of themes we can support and move the others.

13

The proposal was about “only support 3 color themes in XS”. My proposal is to continue to support all of them (and fix whatever needs to be fixed. ATM my only knowledge of things to fix are related to WCAG issues), and if there’s a specific theme to drop for some reason to do that as an exception (after ensuring that it’s not used and not worth keeping).

What I’d like to avoid is precisely what’s being discussed so far, i.e. drop almost everything for no reason other than “it’s easier for us to drop them as we won’t need to do the maintenance”.

14

So you mean start actually supporting them for real then ? I’m not as confident as you that this is realistic.

15

They are supported and that’s why there’s inside XS. It’s just that recently we decided to fix WCAG issues and thus we need to look at them. Apart from this I have no information that they’re not working.

My point is exactly what you’ve said: to evaluate the cost of fixing the WCAG issues and not to decide to drop them just because it’s easy to do so. My guess is that fixing one or fixing 20 is not that different (they are similar on several aspects), the main work is probably to choose colors with contrasts for the themes that need to respect WCAG (again, it’s very possible that some are not WCAG-compliant voluntarily).

16

To me, there shouldn’t be 3 themes for light/dark and high-contrast. Instead, there should be one theme that supports light and dark mode based on the user preference that is indicated by the browser (maybe with an additional option at user-level in XWiki to override the automatic choice). Similar, the theme should use high-contrast colors (or even low-contrast colors) when the browser indicates that the user wants them.

We could allow admins to basically configure three color themes for this that we then switch with CSS media queries if this should be possible (I haven’t checked), but I think it is important that we follow the user preferences that are communicated by the browser.

I’m +1 for having just three themes or, even better, one combined theme. We could leave the other themes on xwiki-contrib for those who want them. I don’t think it is feasible to maintain 20 color themes and I think there are better uses of our time than making 20 color themes WCAG-compliant.

17

I’ll repeat what I’ve said above:

  • This is a pretty bad question to ask for developers since developers will almost always want to reduce maintenance cost. The question is more for users and we need to check if our users use the various color themes we provide or not and if not, why. And then potentially remove some themes that are not used. A survey on the Help/Discuss forum category could achieve this.
  • In this whole thread, devs keep saying it’s costly to maintain themes but 1) I don’t believe this has been true for the past 10+ years (it cost almost nothing and there’s no important jira issues I know of for color themes) and 2) it would be nice to substantiate it with some tasks/estimations.
    • Actually I’ve checked jira and the only issue I’ve found related to a specific theme is Loading...
    • Choosing contrasted colors doesn’t seem that hard to me, am I missing something? And even if it were, that’s not a real problem if there’s no maintenance cost associated with it thereafter.
  • In addition, they may not need to be all WCAG-compliant. Doing so could remove some nice themes with color contrasts that are not high for example yet still attractive for some users. This is a choice to make.

Note that regarding the Bootswatch themes, there’s also Loading... opened by Anca, but her point is about the technology used by bootswatch themes, not to remove the feature (she’s suggesting to provide the different colors in standard color themes).

Globally my take is that removing almost all the various themes will remove some ease of use of XWiki. Note that if it’s so difficult to find the right colors for a theme then it won’t be easier for our users and thus we’ll decrease usability. Again, our competitions provide lots of already existing L&F options and I feel that removing our themes to keep only 3 goes in the wrong direction.

18

+1

I think there’s a big bias here: it costs nothing because it’s not tested and I strongly believe it’s almost not used so there’s no jira and no work to do on them.

I think several themes are entirely missing some variables: it works by falling back on standard color, but the result is probably really not nice.

I agree, but then we need to make it clear which one are WCAG compliant, and which ones are not.

I understand this, for me the question is more about testing: I do think providing 20 themes not tested and probably not working nicely is worst than providing only 3 that we’re maintaining properly. Now I entirely agree with you that we need to assess first that they are indeed not working properly, so we need people to test them.

19

FYI, I’m working on migrating from LESS to CSS variables. It was quite easy to make a basic migrator for all standard colortheme variables. However, migrating all the @lessCode from themes will take more time. Especially because of bootswatch themes that have a lot of hard coded variables and options in their @lessCode. About 1100 lines in the @lessCode for Cyborg… Even if I can use scripts to assist the migration, it’s a huge quantity of code changes and potential bugs. And this needs to be done before migrating any regular LESS sheet, because any migration without taking the lessCode would probably break part of the UI on those bootswatch themes (and I don’t want to test every style single change on 21 themes :upside_down_face: – covering all use cases even only on Iceberg can be quite tricky already).

Got invested into the topic again, wrote a bit about it. My point here wasn't to revive the topic but just share an info that might be of interest to people who participated on this topic :)

A problem with saying we support Cyborg at the same level as Iceberg is that it contains customizations of the bootstrap jumbotron. To be honest with you, I don’t know what it is and I don’t think we have time to fix bugs on this component. We don’t use it anywhere in XWiki.

It’s not official/voted, but IMO a lot of the Iceberg colorTheme is very close to a frontend API (we can’t just change it around because a lot of users rely on it heavily). If we ever want to make it more formal, we cannot say Cyborg is in our frontend API too (or not without a lot of work to update and maintain the colorThemes, but IMO it’s not worth investing that much time and facts show that noone took the time so far).

20

Note: This was done when updating doc for the 15.3 changes :+1:
https://extensions.xwiki.org/xwiki/bin/view/Extension/Flamingo%20Theme%20Application#HBundledthemes