Improvements to the default skin and Iceberg color theme

[tkrieck]

Hi everyone, I come this time with a sort of big proposal of smaller changes that could improve the default experience a bit and hopefully improve feedback that we got in the past regarding the visual design.

The gist of these improvements is that they should be on the easier side (mostly CSS), at least in theory, let me know if that’s not the case for any of them.

I numbered each to make it easier to vote and discuss but if you feel that any of them should be opened as their own discussion, again, just let me know.

Link for the complete proposal: https://design.xwiki.org/xwiki/bin/view/Proposal/VisualImprovementsfortheDefaultExperience

At the end of the design page I also linked other proposals that could make the default experience better, I won’t replicate them here since they already have their own discussions in place.

Thanks for the feedback!

---

01 - Use system font stack

Related article: An ode to system fonts. Downloading fonts slows down a website… | by Felix Hoffmann | UX Collective

Pros:

• Improves speed by not downloading external fonts
• Feels similar to the OS the user is already using.

Cons:

• Less control of rendering, might cause visual bugs exclusive to some platforms
• Unpredictable updates when the OS vendor decides to update its fonts

Example:

body {
    font-family: ui-sans-serif,system-ui,-apple-system,BlinkMacSystemFont,Segoe UI,Roboto,Noto Sans,Ubuntu,Cantarell,Helvetica Neue,Arial,sans-serif,Apple Color Emoji,Segoe UI Emoji,Segoe UI Symbol,Noto Color emoji;
    -webkit-font-smoothing: antialiased;
    font-variation-settings: normal;
}

Current Font (open sans)

System Stack (MacOS)

At least in MacOs there’s not any big change, which is a very good thing.

02 - Update bold, semibold font variables

XWiki maps bold and semibold values respectively to 900 and 700. However, the real semibold values for most fonts is 600, leaving 700 to proper bold styles. 900 is extra bold, but we don’t have a mapping for this style.

Relevant doc: font-weight - CSS | MDN

Current

Proposal

03 - Update the default heading to use the updated semibold version

On long documents, with lots of heading, it might be difficult to visually distinguish each one. Using a semi-bold font-weight should improve this situation without taking too much extra space.

Example:

Current

Proposal

04 - Reduce button size on desktop

Note: This proposal is considering a desktop device with a mouse like pointer.

Button are using the default text size and a good chunk of space for padding.

• They could be switched to the smaller text variation, since they already stand out on their own in the UI.
• Reduce border-radius to 4px or the equivalent variable.
• Standardize on the grey OR white variant for all secondary buttons. Right now the main edit buttons are of one color and all the rest of the secondaries are white.

Context

Proposal

05 - New font size for modal headers

Currently, the modal header spacing and font size is very large, taking valuable space from the content of said dialog.

Current:

Here we have:

• a font size of 20px
• paddings of 15px in all sides Proposal

Changes:

• Font size is the same as the body text, font weight is semi-bold (using the new proposed value)
• Padding is asymmetric, using 8px for top and bottom and 16px side-to-side (to keep alignment with the content)

Current

Proposal

06 - Make the footer use the body background colour

With the current layout, the footer standout too much on shorter pages depending on the viewport. This abrupt cut in the middle of the screen gives a bad impression and a sensation of lack of polish to the UI.

Current

Proposal

Make the background colour transparent and default link colour to the version info

Alternative

Make the footer sticky to the bottom only when the page doesn’t have enough content to fill the whole viewport. This should be doable with flex or grid layouts in CSS, but it’s a deeper intervention.

07 - Default to an 8px grid whenever possible.

Currently, XWiki uses a 10px grid for most things. However, an 8px grid is ideal as shown in the article below. Basically, by making multiples of 4 we ensure that spacing and sizing is consistent with more viewport sizes.

Everything you should know about 8 point grid system in UX design

This is of course work that should be done in a case-by-case- scenario as it is very difficult to do it without using CSS variables throughout the whole UI.

08 - Livedata improvements

Livedata right now gives the impression of being unstyled and unpolished, while we do have a proposal for deeper improvements I’d like to propose smaller changes that could be made with very little effort.

Context

Proposal

Important: While the separator was made thinner and shorter, it was done via an :after pseudoclass declaration. The actual component should maintain the current size to make it easier to grab with a pointer device.

09 - Decouple the Content Menu buttons background color from the Breadcrumb background color

Currently, the buttons in the content menu inherit their background color from the breadcrumb background color, which creates inconsistency across buttons in XWiki. This also forces users to modify the breadcrumb background color variable to adjust button colors, which is unintuitive.

If this differentiation between “content menu buttons” and “all other buttons” is desirable, it would be better to have specific variables for these buttons.

Current

Proposal

10 - Combine the navigation button and item separator on the Breadcrumb

Currently, a lot of space is wasted in deep hierarchies with two buttons on the breadcrumb. We could combine these two since one of them is purely visual.

Current

Proposal

11 - Page notification configuration button to icon only (bell)

Currently, the page notification config button takes a lot of space (and possibly even more on other languages) for a secondary functionality. We could improve it by reducing to icon only describing the current effect of the configuration (receiving, not set and blocked) and using tooltips to better explain what’s going on (subscribed to page, subscribed to wiki, etc).

Current

Proposal

12 - Navigation Panel and Quicklinks

12.1 Remove item dots from the main navigation

They don’t bring much to the table and give the impression that something is unstyled.

12.2 Navigation Items span 100% of the panel width

This makes the items easier to hit with any pointer device.

12.3 Reduce the font size of panel titles

These titles compete with titles from the content, they take too much space and should not be the main focal point when using the sidebar.

12.4 Make the selected page font semi-bold

The current selected page style is very low contrast. We can improve it without taking too much space by making the font stand out a bit more.

All navigation sidebar changes combined:

Context

Proposal

13 - Updated visual design for errors in the notification icon

When there’s a problem that shows in the notification center, the current error color in the notification icon is very hard to see.

---

As always I welcome any feedback that you might have. Thank you very much.

[Simpel]

• 06 - Make the footer use the body background colour: I very like the alternative - the sticky one. We made our styling working like this.
• 12.2 Navigation Items span 100% of the panel width: we did this too

[mleduc]

@tkrieck

01 - Use system font stack

+1, see also Moving to a system font stack where the discussion was never really completed, but with 6 +1 for the proposal

@tkrieck

02 - Update bold, semibold font variables

+1, especially as it’s going to make the system font stack support more portable.

@tkrieck

03 - Update the default heading to use the updated semibold version

+1 for the same reasons

@tkrieck

04 - Reduce button size on desktop

+1 as long as it does not hurt accessibility.

@tkrieck

05 - New font size for modal headers

+1

@tkrieck

06 - Make the footer use the body background colour

+1 for the sticky footer options
+0 for the color change size, but I would only consider it if the sticky option leads to technical issues.

Also, does it have an impact on mobile where vertical space is scarce?

@tkrieck

07 - Default to an 8px grid whenever possible.

I trust you on that one

@tkrieck

08 - Livedata improvements

+1 as long as it does not hurt accessibility

@tkrieck

09 - Decouple the Content Menu buttons background color from the Breadcrumb background color

+1

@tkrieck

10 - Combine the navigation button and item separator on the Breadcrumb

I’m not sure to understand that one. If the unfold buttons are removed and clicking on the segment unfolds the tree instead. Are users still able to navigate to a given segment in a single click?

@tkrieck

11 - Page notification configuration button to icon only (bell)

+0, I would need @surli opinion on that one.

@tkrieck

12.1 Remove item dots from the main navigation

+1

@tkrieck

12.2 Navigation Items span 100% of the panel width

+1

@tkrieck

12.3 Reduce the font size of panel titles

+1

@tkrieck

All navigation sidebar changes combined:

Is the text in black for links just for the mockup, or is it part of your proposal?

[CharpentierLucas]

@tkrieck

01 - Use system font stack

-0, I assume the few fonts we use in XWiki are cached by the browsers anyways, so the download would not be very impactful on speed. I doubt the benefits outweight the maintenance time.

Edit: After taking a look at Manuel’s proposal, there’s https://systemfontstack.com/ available, it makes it easier to maintain. +0

@tkrieck

02 - Update bold, semibold font variables

My bad. I tried to map what we were hard-coding in XWiki before to a set of a few values. I think you told me about such issue before and that’s missing in our variables.
+1 to update it

@tkrieck

03 - Update the default heading to use the updated semibold version

+1, the proposal looks better IMO.
Did we use font-weight on headings before?

@tkrieck

04 - Reduce button size on desktop

@tkrieck

Note: This proposal is considering a desktop device with a mouse like pointer.

For reference, this can be done in CSS with a media query @media (min-width: 1200px)

@tkrieck

They could be switched to the smaller text variation, since they already stand out on their own in the UI.

-1, it’s important that those buttons are readable since they serve some of the most common actions. Note that there’s a special button class that we use regularly through the UI in places where space use is critical: btn-xs.

Those small buttons are used in the livedata pagination:

btn-xs buttons respect WCAG Target Size (Minimum) (Level AA)
Regular buttons do not respect WCAG Target Size (Level AAA) but it’d be good to keep them a bit larger than the required minimum ^^

@tkrieck

Reduce border-radius to 4px or the equivalent variable.

+0, not sure this change brings much

@tkrieck

Standardize on the grey OR white variant for all secondary buttons. Right now the main edit buttons are of one color and all the rest of the secondaries are white.

+1, not sure why we have a custom color on those top buttons anyways.

@tkrieck

05 - New font size for modal headers

Currently, the modal header spacing and font size is very large, taking valuable space from the content of said dialog.

From what I understand, in almost all cases, the modal is not tight for space and it doesn’t matter much what size it is.

I’m +1 for all the ideas proposed here, except reduced the font size to be the same as regular text. We can reduce it a bit, but IMO it’s good to have at least a bit of a difference.

@tkrieck

06 - Make the footer use the body background colour

+1, making the footer stay on the bottom of the page would definitely be the best option, but we need to make sure it behaves the same for longer pages. We’ll see if CSS allows that without a hack.

@tkrieck

07 - Default to an 8px grid whenever possible.

I feel like this should be a proposal for our CSS codestyles
I’m not against it, but there’s so many places… we need to improve things gradually.
+1 to be more consistent on this point

@tkrieck

08 - Livedata improvements

-1 for the new handle design. This only appears when hovering the column, so IMO it should be easy to spot. Using a color with less contrast and a reduced visual space would make it harder to spot for people with reduced vision.

@tkrieck

Important: While the separator was made thinner and shorter, it was done via an :after pseudoclass declaration. The actual component should maintain the current size to make it easier to grab with a pointer device.

Good idea! I just realized that this handle did not have any hacks to make its click zone larger. From what I remember, it wasn’t easy to make a hack like this because we need precise values for interaction. We can also try to use the same “hack” as the one I added to the panel resize handles (the handle background is a picture that’s more than half transparent).

@tkrieck

09 - Decouple the Content Menu buttons background color from the Breadcrumb background color

+1, this point was mentionned in proposal 4 and I agree. It might take a bit of time to get used to at first, but it’s more consistent overall.

@tkrieck

10 - Combine the navigation button and item separator on the Breadcrumb

@tkrieck

Currently, a lot of space is wasted in deep hierarchies with two buttons on the breadcrumb. We could combine these two since one of them is purely visual.

One is purely visual and the other comes with button semantics and an expected action. IMO it does not make much sense to combine them.
How will the new users learn that they can click on the / in the breadcrumb to get a tree?
-1 from me as it stands, if the fact that there’s a button is made clear, I’d be +1. The breadcrumb is a really interactive element, IMO it’s alright to give it some space. In this little box, there’s 10 things you can click to do 5 different actions (opening navigation trees) and 5 things you can click to move to 5 different places.

@tkrieck

11 - Page notification configuration button to icon only (bell)

-0, IMO there’s not much point to this and it feels like oversimplification. Laying info out can sometimes be more useful than hiding it. User feedback to back this change would be useful.

@tkrieck

12 - Navigation Panel and Quicklinks

12.1 Remove item dots from the main navigation

+1, Note that quite often, we have carets and not dots next to the items.

@tkrieck

12.2 Navigation Items span 100% of the panel width

+0

@tkrieck

12.3 Reduce the font size of panel titles

+1, but with similar concerns as proposal no. 5, I think it’s important to keep it at least a bit higher than the base text font-size.

@tkrieck

12.4 Make the selected page font semi-bold

+1, see Loading...

@tkrieck

All navigation sidebar changes combined:

Is the change of color accounted for? I believe we should keep the link color on all of these links.

PS Just saw Mleduc pointed it out too

@tkrieck

13 - Updated visual design for errors in the notification icon

+1 for the change.
Do you have a process to reproduce the error state in XS? I might be wrong but isn’t this error state specific to an extension/customization used on XWiki Cloud?

---

Thank you for researching all this!
Lucas C.

[mleduc]

@tkrieck

13 - Updated visual design for errors in the notification icon

Forgot to answer that one earlier.
Note that the bell icon can be with a notification number and the “error” state at the same time.

Unless I miss something, your current proposal makes them exclusive. Would it be possible to either display the warning (!) sign in another location, or to merge them nicely in the case when they are borth active?

[TomTheWise]

Hi, As a user in a organization that mainly uses windows: many changes looks nice and plausible but especially 10 would be a regression. Slash by itself never indicates to the user that an action is possible when clicking on it.

As alternative to 10:

How about removing slash as the separator to the right pointing version of the current arrow and when clicking on it and opening the tree on that position it switches to the current arrow (to bottom).

I think this would improve the design (only one symbol as separator and tree opener) and still be very intuitive.

[tkrieck]

@mleduc

+1 as long as it does not hurt accessibility.

It shouldn’t as it uses variables that we already use for smaller text.

@mleduc

Also, does it have an impact on mobile where vertical space is scarce?

No, this technique only applies when the content is smaller than the viewport, if the content is larger then it wouldn’t be different than how it currently looks.

@mleduc

I’m not sure to understand that one. If the unfold buttons are removed and clicking on the segment unfolds the tree instead. Are users still able to navigate to a given segment in a single click?

Yes, the separator between items would be the action button to show the page menu.

@mleduc

Is the text in black for links just for the mockup, or is it part of your proposal?

Ah you’re right, I was conducting some color tests at the same time. Personally, I like them black as it aligns with other software better, I consider the tree navigation a special case because it is so ingrained in day to day use that we don’t need to mark each item as a link (check Jira or this forum application for example). The hover styles also confirms that each item is actionable anyways.

---

@CharpentierLucas

-0, I assume the few fonts we use in XWiki are cached by the browsers anyways, so the download would not be very impactful on speed. I doubt the benefits outweight the maintenance time.

Not only download times but also rendering time and “flash of unstyled content" but I got your point, let’s wait for more opinions then =)

@CharpentierLucas

-1, it’s important that those buttons are readable since they serve some of the most common actions. Note that there’s a special button class that we use regularly through the UI in places where space use is critical: btn-xs.

I used XWiki’s `text-smaller` size as the basis of the font size, so it should be good on the accesibility side (we use it in a lot of places in the UI). It translates to 13px on a regular desktop.

I feel that btn-xs goes way too hard in the compactness direction to become regular buttons (12px).

Note that the proposal changes all regular sized buttons to this smaller version, it’s not a special case of only the content menu buttons being reduced.

@CharpentierLucas

+0, not sure this change brings much

It keeps buttons visually proportional on the smaller version proposed above, it’s not an isolated thing.

@CharpentierLucas

From what I understand, in almost all cases, the modal is not tight for space and it doesn’t matter much what size it is.

It depends on the viewport, on mobile it could be wasteful.

@CharpentierLucas

-1 for the new handle design. This only appears when hovering the column, so IMO it should be easy to spot. Using a color with less contrast and a reduced visual space would make it harder to spot for people with reduced vision.

Could it be turned into an option in the accessibility preferences? I really feel the current look and feel is not ideal.

@CharpentierLucas

Good idea! I just realized that this handle did not have any hacks to make its click zone larger. From what I remember, it wasn’t easy to make a hack like this because we need precise values for interaction. We can also try to use the same “hack” as the one I added to the panel resize handles (the handle background is a picture that’s more than half transparent).

It could be, I remember when we discussed these handlers for LD and at the time it was something that not occured to me but when testing for this proposal I was able to decouple the target area from the visual aspect.

@CharpentierLucas

How will the new users learn that they can click on the / in the breadcrumb to get a tree?

By experimentation mostly. It works the same way in Windows Explorer and lots of people are already exposed to this behaviour. I am not sure on Linux distributions. MacOs doen’t have this feature at all.

Also, see my reply to @TomTheWise below for an updated design.

@CharpentierLucas

-0, IMO there’s not much point to this and it feels like oversimplification. Laying info out can sometimes be more useful than hiding it. User feedback to back this change would be useful.

My justification is because it is a very secondary action/status. In the same way we have a kebab button for the “more” button and not one labelled “More” or “More Actions". This could also mitigate the visual break of buttons on different languages other than english. See the examples below, using a very common laptop viewport of 1366px width.

@CharpentierLucas

Is the change of color accounted for? I believe we should keep the link color on all of these links.

So, yeah as I replied above to @mleduc I forgot to add it to the proposal, but I like the black color on the nav tree. Take the example of file managers, this forum app, Jira and so on. It’s a very common UI pattern.

@mleduc

Unless I miss something, your current proposal makes them exclusive. Would it be possible to either display the warning (!) sign in another location, or to merge them nicely in the case when they are borth active?

Good point. In this proposal they are mutually exclusive with the error state taking precedence. The notification badge is not that important if you have something wrong stated, and you need to open it anyways to see both.

---

@TomTheWise

How about removing slash as the separator to the right pointing version of the current arrow and when clicking on it and opening the tree on that position it switches to the current arrow (to bottom).

I think this would improve the design (only one symbol as separator and tree opener) and still be very intuitive.

I like it! See an updated mockup below, let’s what others think of it.

Thank you all for taking your time to provide feedback!

[tkrieck]

Sorry, I forgot to reply to these

@CharpentierLucas

Do you have a process to reproduce the error state in XS? I might be wrong but isn’t this error state specific to an extension/customization used on XWiki Cloud?

I don’t know if this is specific, but indeed I tested it using a Pro App without a license.

@CharpentierLucas

I feel like this should be a proposal for our CSS codestyles
I’m not against it, but there’s so many places… we need to improve things gradually.
+1 to be more consistent on this point

That’s a nice idea. Yes, to update everything at once would be crazy work. But it would be nice to have a definition to go towards to.

[paulinebessoles]

+1 on Proposals 1, 2, 3, 4, 5,

@tkrieck

06 - Make the footer use the body background colour

+1 on the alternative sticky footer

+1 for Proposals 7,8,9,12,13

For proposal 10, I agree with this comment, and I like the new mockup you proposed with the right pointing arrows replacing the slash.

For proposal 11, not sure if it was not thought for a clarity reason, I would check the initial specs and discussions for changing this

[gabrielc]

Helloo!!

Thank you for working on this.

@tkrieck

01 - Use system font stack

+1

@tkrieck

02 - Update bold, semibold font variables

+1

@tkrieck

03 - Update the default heading to use the updated semibold version

+1

@tkrieck

04 - Reduce button size on desktop

+0

@tkrieck

05 - New font size for modal headers

+0

@tkrieck

06 - Make the footer use the body background colour

-0 for proposal, +1 for alternative.

I prefer the alternative approach of sticking the footer to the bottom of the page if there isn’t enough content. I think it looks better. But it may cause issues in some edge cases.

@tkrieck

07 - Default to an 8px grid whenever possible.

+1

@tkrieck

08 - Livedata improvements

+1

@tkrieck

09 - Decouple the Content Menu buttons background color from the Breadcrumb background color

+0

@tkrieck

10 - Combine the navigation button and item separator on the Breadcrumb

-0. I think the proposed version doesn’t make it obvious to the user that they can click on the “/”. But I do agree that the arrows take a lot of space.

Maybe leave the arrow only for the last element in the breadcrumb list?

@tkrieck

11 - Page notification configuration button to icon only (bell)

+1

@tkrieck

12.1 Remove item dots from the main navigation

+1

@tkrieck

12.2 Navigation Items span 100% of the panel width

+1

@tkrieck

12.3 Reduce the font size of panel titles

+1

@tkrieck

12.4 Make the selected page font semi-bold

+1

@tkrieck

13 - Updated visual design for errors in the notification icon

+1

Note: I’m not a contributor so +/- has no official value coming from me. These are just my opinions.

[gabrielc]

@tkrieck

@TomTheWise

Hi, As a user in a organization that mainly uses windows: many changes looks nice and plausible but especially 10 would be a regression. Slash by itself never indicates to the user that an action is possible when clicking on it.

As alternative to 10:

How about removing slash as the separator to the right pointing version of the current arrow and when clicking on it and opening the tree on that position it switches to the current arrow (to bottom).

I think this would improve the design (only one symbol as separator and tree opener) and still be very intuitive.

I like it! See an updated mockup below, let’s what others think of it.

For 10, I really like this mockup!

[mflorea]

@tkrieck

04 - Reduce button size on desktop

I don’t see what we gain by reducing the button size. I prefer the way it looks in the current screenshot. The buttons on the proposed screenshot appear to be rectangular (with very low border radius), and I remember that no long ago @amilica proposed to make the buttons more rounded Rounder corners everywhere - Minimalist Skin 3 . Are rectangular buttons back in trend?

@tkrieck

05 - New font size for modal headers

Again, I don’t see the benefit. I prefer the way it looks in the current screenshot. I find it strange that in the proposed screenshot the modal title has a lower font size than some of the text from the modal content.

@tkrieck

06 - Make the footer use the body background colour

I prefer the sticky alternative.

@tkrieck

10 - Combine the navigation button and item separator on the Breadcrumb

-1, it’s not obvious at all how you can open the navigation tree. As for using the right caret instead of the down caret + slash, I’m fine with it, but the right caret needs to be replaced with a down caret when the navigation tree is opened, to be consistent with the behavior from the administration categories and the navigation tree itself.

@tkrieck

12.1 Remove item dots from the main navigation

They don’t bring much to the table and give the impression that something is unstyled.

Well, those dots do have a role: to help you distinguish between a page and a new line from a long page name. You have it in your screenshot:

Migration Guide to
Nested Pages
Wiki vs. Nested Pages

It’s not easy to spot whether those are 3 pages or just 2.

Thanks,
Marius

[vmassol]

@mflorea

Well, those dots do have a role: to help you distinguish between a page and a new line from a long page name. You have it in your screenshot:

Migration Guide to
Nested Pages
Wiki vs. Nested Pages

It’s not easy to spot whether those are 3 pages or just 2.

I think @tkrieck will say that when the line overflows, the vertical spacing between the previous line and the next line is reduced, to make it easier to see it’s an overflow and not the next item.

This is what Thiago has used in his screenshot. I feel it’s ok. It’s less obvious than with bullet points but I think it’s ok fit the spacings are different enough.

[Simpel]

12.1 Remove item dots from the main navigation

Those dots help me to align pages of the same level. Pages with children will have a triangle before the title. Those dots are aligned with the triangles. This helps me scanning the navigation with long lists of articles in one level especially.

The impression of not being styled is more due to not changing the hovering background color on those dots and triangles I think. This could be more look like styled when changing the background color of the parent li element I guess.

Additional I like the idea to have smaller vertical spacing on overflowing / breaking items.

Simpel