Theme Editing UI Improvements

Development
,
1

Hello everyone! :waving_hand: I’m here to discuss the theme editing UI and how we can improve it.

To check out

I’ve added 2 polls at the end of the post that will help us get more structured global feedback in the long run. If you make it until there, thanks a lot in advance!! :face_holding_back_tears:

Some definitions

  • theme element = the menu items (Logos, Base colors, Typography)

  • theme property = Table background, table row on hover, etc.

  • theme variable = @table-bg , @table-hover-bg

Current situation

image
image2704×1483 359 KB

Issues

#1 Not all theme properties have their color code present in the input.

  • I assume this is because they have the values from the Bootstrap theme, but a new user to XWiki (technical or non-technical) doesn’t know our stack and, even if he knows, maybe is not even used to Bootstrap variables.

#2 Theme properties don’t have an actual name, they just have the theme variable shown.

#3 No explanation or context is given for each theme property. The user can’t understand only from the variable what UI element is affected by the color he chose

#4 The variables sometimes affect UI elements that are not present on the pages that are user-created. Thus, the user can’t quickly observe the changes he makes in the theme

#5 The preview of the wiki makes the interface scale down to its tablet view. To see the panels too, one has to zoom out the entire page, possibly affecting accessibility.

#6 After modifying a color, there’s no way for the user to know the initial value or the default value.

Effects of these problems

They decrease the perceived value and quality of the product for new users. Theme customization is a very basic thing in most software and users expect it to be very simple, straightforward.

They decrease the chance of non-technical open-source contributions to our themes as the current UI relies on technical knowledge or XWiki-specific knowledge.

New design :light_blue_heart:

image
image1920×1134 157 KB

Changes made

#1 We stop organizing things into clearly bordered panels (Variables, Preview) to reduce used space (space-saving)

#2 We reduce the amount of strong borders to make the UI less overwhelming and more breathable. (breathability)

#3 The menu in the left is more cohesive with the one proposed both for Global Admin and the one for Profile Page. (cohesion)

#4 We make the variables’ menu slightly narrower to allow for more width on the preview (space-saving)

#5 We keep all actions related to the preview on one single line together with the “Preview” title (space-saving)

#6 We introduce Zoom in, Zoom out buttons that scale only the preview of the wiki to let the user see how the wiki looks like on multiple screen sizes with the new changes done (on the largest screen size they will be able to see their side panels)

#7 Each theme property has a name present instead of just its variable.

#8 Each theme property is expandable. Clicking on the info icon, expands info about the theme property:

  • which UI element is affected - this is done just by naming the UI and, if it’s the case, its specific state (hover/focused/…)

  • where to find an example of this UI element - this is done by an anchor link to a section of the Sandbox page (which should be updated, see #9)

  • the theme variable - for technical users that may still want to reference it somewhere else

After clicking on it, the info icon gets the color gray. Clicking on it again, we collapse the details and make the info icon blue again.

#9 We modify the “Sandbox” page to have UI elements relevant for each theme property. This is the page that will be shown first in the preview for the wiki theme configurations. The user can navigate from this page to any other of his liking. For page theme configurations, this page will NOT be used.

  • For example, in the Sandbox page, a heading named “Tables” will introduce a hover table populated with some random data, so the user can see how his color choices look like for all states of the table.

#10 We change the way we display the color and the code. The color swatch comes first in a circle, followed by the HEX code. This order is similar to popular design tools and no-code tools (Figma, Webflow).

#11 For any theme property, the color code and swatch will be present, regardless if their value is the same with the ones from Bootstrap.

12 The gray line that separates the menu from the overview transforms into a scroll bar when it is necessary to do so.

#13 When deleting the value in the input of each theme property color, the color resets to the Bootstrap theme value.

#14 We add a Reset all button on the same line with the title of the theme element. Clicking it will open a modal for confirmation. Confirming will reset all the values of the theme properties (example: Hovered Row Color) associated with the current theme element (example: Tables)

Scroll bar view

image
image1920×1134 158 KB

Polls

#1 What do you think of these changes?

  • I agree with most or all points
  • More work is needed
  • The current UI is good enough, I don’t think we should change it
  • I’d advocate for a more extreme revamp, the whole process of theme editing should be changed
0 voters

#2 How’d you evaluate the effort needed to implement this proposal?

  • Reasonable, shouldn’t take too long
  • Quite intensive, but worth it
  • Quite intensive and NOT worth it
0 voters

#3 How big of a priority do you see the implementation?

  • High priority (tell us why in the comments)
  • Medium priority (tell us why in the comments)
  • Low priority (tell us why in the comments)
0 voters
1 Like
2

I really like the proposal! I think it would enhance the usability of the feature, and also participate in a better onboarding (customization being a part of it IMO).

I just have a suggestion on the color variables, do you think it would be interesting to have a color-picker to facilitate the choice of the color for users not used to HEX?

3

Hi!

Thank you for starting this proposal.

Note that IMO it’s even more of an issue on the development side. Because there’s no semantics given to these variables, there’s a few places in old code where they are used purely for the color they provided, without regards to the actual meaning of the variable. This means that whenever we update them in what should be a minor and correct change, a lot of tests need to be done or things might break in unexpected places.

  1. It depends on the screen size you’re working with :wink:
  2. Panels can be seen even in tablet view under the main content.

The theme page has an history like any other page, and the bootstrap defaults can be obtained by leaving the field empty. The second one is a bit difficult to know without experience though :slight_smile:

Note that at least from my point of view so far I assumed the users handling color themes were Admin users that could handle a bit of technical complexity if needed.

____

New design

Shouldn’t this be a caret or arrow to convey that you’re opening a collapsed section?

The caret would rotate depending on the state of the details section.

Not that making this exhaustive would be unrealistic. Extensions use these variables and I doubt we can expect anyone to document under a certain format how they use all of those variables.

+1, but knowing if we want to implement this ourselves by relying on native features or using a library (in this case, which one?) is something we should think about carefully.

Like I said above, this is technically what is happening. Now the info is not clear so we should probably think of a way to make it clearer. Personally I like to have an empty field instead of one that gets populated with a value that pops out of thin air. This way it’s easy to see what values are overridden by the current colorTheme.

Maybe that “empty field“ default value could be given in the theme property details.

I’m not sure what reset means in this case. E.g. I click on the reset on the Iceberg colortheme. I could expect at least three different things to happen:

  • Reset to bootstrap defaults. Every field is emptied out.
  • Reset to Iceberg colorTheme defaults. They were stored in the background and I get the same Iceberg colorTheme as the one in XS.
  • Reset to where I last saved the colortheme. The page is reloaded without a save.

I’m not sure the standard options for saving your page at the bottom of the page are lacking much here. Note that resetting to bootstrap defaults can be easily done by creating a new colorTheme.

____

Probably a bad idea, but adding a highlight on the changing element in the preview could be cool. Right now my way to check what’s changing when I want to understand where a variable is used is to first set my theme variable to a neon green or something completely off, and scroll through the preview to see where’s the neon green. Maybe a toggle in the details of each property next to the example of UI link would work.

____

Details on my answer: most things shouldn’t take too long, since AFAICS most of the structure is the same, it’s mostly a matter of CSS. But the swatches for colors could be troublesome to integrate correctly.

____

IMO medium priority since most users won’t ever get on this UI. But this is a bit biased: if the UI was better, more users would play with it and make colorthemes for their own sections of wikis. There might be a technical reason behind why we wouldn’t want low right users to create and edit colorthemes though (e.g. if custom LESS in the advanced section was a security liability) :slight_smile:

4

Don’t forget that the priority means vs other things we need/want to do. For me, the Theme UI is already very functional and usable (and is actually one of our good/best UIs already with a live preview :)). So I see it as a low priority in the roadmap vs other things we need to work on:

  • security
  • important bug fixes
  • accessibility
  • performance
  • new features (innovation) like xobject edition in LDs, Block editor, more modern UI (Cristal merge), etc
  • usability of existing features, such as the Rights UI which has a much older UI that is very hard to use and understand.

Now, if the implementation of the proposal is low (I haven’t read the proposal yet TBH so can’t comment on that) then even if the priority is low, it could still get implemented quickly.

Thanks

1 Like