Improvements to the default skin and Iceberg color theme

[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!