Rounder corners everywhere - Minimalist Skin 3

Development
, , ,
#21

I meant literature about why people that are making sharp corners are making sharp corners, not about the advantage of rounded ones.
On a quick look, I think I saw some form of sharp corners in material 2, but I am far from being knowledgeable of all design systems. I just remember that at some point corners were sharp on the web because technically we didn’t know better (until around 2010ish) and then they all became rounded (when it became technically feasible) and then I saw them going back to sharp again (like on this forum), I was wondering about this last switch to sharp, if there is any argumentation for it…

There are many things that I don’t agree with in this sentence, but I will focus on only one: my feeling is that sharp corners are intentional in many places today (including this forum), so I don’t think it’s just a side effect of an order of priority… (also, it appears they’re back rounded again in the latest version :slight_smile: https://try.discourse.org/ ).
Also, UX is functionality, so there is nothing “normal” about functionality taking the spotlight over UX…

Thanks,
Anca

#22

Hi @amilica I don’t believe this is correct and it’s not what we want to do for XWiki at least. UI/UX is paramount in importance and we’ve been trying to improve it continuously since the past 15 years or so. So, no, features should not have the spotlight, and as Anca said, UI/UX is a feature (a very very important one, probably more important than any other feature actually). This is why we need your help to help us improve UI/UX even more! :slight_smile:

Thx.

EDIT: If you think that XWiki lacks UI/UX quality, it’s not because we don’t want it or don’t consider it important, it’s because it’s a hard topic, and it’s hard to find developers/designers proficient in this domain. We definitely need to improve. And we want to.

#23

My comment wasn’t related to XWiki, but to the forum and other open source projects that I and many people encountered on the internet. I know the direction of XWiki and I know it puts an enhancing importance on polishing more and more the UI.

Totally aware of this.

#24

This forum (Discourse) is quite nice in term of UI/UX IMO. And if you asked them, I’m pretty sure they will say that they care about UI/UX and that it’s a first class feature for them. I don’t know many any open source project with a UI nowadays who don’t consider UI/UX as a very important feature (if not the most important one). Whether they succeed or not to have a good UI/UX is another matter :wink:

#25

I have tested on Iceberg with the following configuration:

@border-radius-base:             7px;
@border-radius-large:            10px;
@border-radius-small:            5px;

Here is a screenshot of a page in edit mode:
image

Some notes:

  • the following themes are with explicitly defined radius: Cerulean, Cosmo, Cyborg, Darkly, Flatly, Journal, Lumen, Paper, Readable, Sandstone, Simplex, Slate, Spacelab, Superhero, United, Yeti
  • some UI elements are not using the bootstrap radius, for instance the document tree (e.g., the navigation tree) use a fixed 2px radius. That one is easy to fix but I feel like with larger rounded corners, elements that are not using the same values become more visible
  • I also feel like the sharp edges of the panels are also more visible with the rest of the UI using larger rounded corners

Overall, I like the look and feel with larger rounded corners.

1 Like
#26

Thank you for pointing that out. While not the scope of the discussion or a priority in any way, many of the existing themes should be at some point updated (they have contrast issues or are not fully coherent in their own theme) or, even deleted in some cases. In the case of an update, we should probably remove explicitly defined radius.

If I got it correctly, you propose to change the border-radius of most elements, but not to all elements?

If yes:

While there are benefits to mixing straight (or straight-er) edges with rounder edges, we might lose a bit of cohesion between elements. What we gain in slightly better perception of important elements, we lose in esthetics and we lose the focus on the main thing - the document (main content area). In my opinion we should always aim to guide the eyes of the user towards the main content area, converge the vision, not diverge it in different directions of the screen.

I would include panels in the medium size elements category as I documented here and they would have a 7px border-radius.

I think this works pretty well. I’m having a bit of trouble deciding on 10px or on a bigger radius for large size. As you’ll see in this audit (not yet done), I’ve only included a few elements in this category. I’m trying to find more, but there’s not many of them in the XS.

I’ll have to come back on this after I post the discussion on the last sub-proposal regarding division between the panels and the main content.

#27

I’m saying that UI elements with non-standard border-radius are more visible if most of the UI is with larger radius.
Consequently, we’ll need to do some more work to make them uniform as well.

1 Like
#28

Okay, I understand.

I think it would still be a great improvement if we had most elements with rounder corners.

Eventually, we can uniformize everything in time.

#29

Here is the corresponding PR: XWIKI-21334: Uniformize the rounded edges of visual elements by manuelleduc · Pull Request #2385 · xwiki/xwiki-platform · GitHub

You can find some before/after screenshots on the PR. Let me know if you want the preview of some specific UI elements.

I only adapted the radius of the clicked element on document trees. The rest of the UI element are either with no border radius, or took into account the new values.

#30

Looks good to me! I think we might need tot modify certain elements that are enclosed into other rounded elements that may be hard coded. I tried adding your changes in the LESS of one of my instances and I saw that one case that may not be affected by the code is the dropdown menus from the Global Administration page (the gray rectangle doesn’t have the same radius as the enclosing rectangle). Let me know if I missed something.

image

I think these are the changes needed for this specific case:

.admin-menu .panel-heading.collapsed {
border-bottom-right-radius: @border-radius-base;
border-bottom-left-radius: @border-radius-base;
}

After changes:
image

Of course, we can make mroe updated at a later time too, so your changes are great (and ready to go, from my pov). Thank you so much for working on this! :partying_face: :partying_face:

#31

Good catch, thanks a lot. I’ll integrate that one in the current PR.
And indeed, we’ll need to create additional issues if we notice some other corners with unexpected radius later on.

2 Likes
#32

Hum actually the issue is larger than menu.
I looked and there is 48 CSS rules that are hardcoding the radius.

So we have to options.

Option 1:
Consider those as bugs, open issues for them and fix them separately

Option 2:
Manually fix them by replacing (search & replace) following the table below.
Still consider those hardcoded values as bugs and open issues to fix them separately.

Size Before After
Base 4px 7px
Large 6px 10px
Small 3px 5px

Note there is situations where the radius does not match any old value. In this case I suggest to handle them case by case.

#33

I think option 2 is good.

I’m not sure opening 48ish issues for border radius is really relevant, maybe it’s possible to only open 1 per file containing those hard-coded values.

We could update The CSS code style to include border radius in the values that should not be hard-coded:

" don’t hard code colors in properties - use ColorTheme variables"
→
" don’t hard code colors or border radius in properties - use ColorTheme variables"

Thank you!
Lucas

#34

I was thinking one issue per module, which should diminish the number of issues (but still a lot I agree)

+1

1 Like
#35

Most of the existing themes are themes from bootswatch ( https://bootswatch.com/ ) integrated into XWiki. This was done when we implemented bootstrap in XWiki, as a way to leverage the power of boostrap (“when you write on a known design system you get universal skinning for free”). While they are nice themes, I am less and less convinced that they should be in the standard distribution, especially as they pose other problems as well (there was one at least that was integrating a remote webfont from a cdn).
We could go back to what we used to do in the skin before Flamingo (which was Colibri), where we were providing 4 color variations as the default available color themes and then the users could make their own. But this would need to be a different forum topic.

I’m +1 for this.
I don’t see why we wouldn’t be able to use standard border radiuses or calculations of them. If we’re fixing them, let’s fix them right.

I think this section can be improved or transformed into a bigger section expressed something like: “code for all color themes” or “code for all the design system parameters” with the explanation that basically when you code something, you need to take into account that it may run in different conditions than the ones that you’re looking at (color-wise, size-wise, etc).

If you want to improve just that phrase, it should be “don’t hard code colors or sizes - use Bootstrap & Color theme variables”. It may be that this doc was written before Flamingo color themes, and back then color theme only had color vars, not size vars.

Thanks,
Anca

1 Like
#36

One cons I did not mention is that it makes the style inconsistent at time, with odd rounding here and there.
With option 2 we wouldn’t have this issue as all existing rounded corners would be updated to the right size (well, only for the themes using the default radius values I agree).

I have opened a separate discussion for this part CSS Best Practive - Generalize on hardcoding rule

#37

Hmm… I don’t understand, what style would be inconsistent?

What I understood from option 1 (and what I completed it with) is that the radius sizes that are hardcoded to pixels sizes would be transformed to be set as radius variables or fractions of them (depending on what the value is and what can we do to bring it back to standard size).
What I meant here is that if the hardcoded size corresponds to an existing border-radius variable, we use that one. If it doesn’t, we compute the fraction of the border-radius size that it represents and we set it with that proportion of that variable.
For example, if we find a hardcoded border radius of 3px, with this “Option 1” fix we’d make it @border-radius-base * 0.5 or @border-radius-small * 0.75 (I cannot tell you which one is best, we’ll need to decide on case by case, although I think it doesn’t really matter (as large and small are computed as proportions of -base anyway). Thus, with Option 1, this fixed border will keep its exact current size for the current radiuses so it will look the same in the current setting and it will adjust accordingly whenever a color theme sets other radius sizes or when we’ll change the defaults.
So I don’t really understand what style may become inconsistent?

Regarding “odd rounding”:
Of course all this usage of border radiuses based on 3 fixed sizes or proportions of them is somewhat “automatizing” the calculation of all radiuses and for some elements / boxes it can be perfectible if you went on and manually tweaked it, but tweaking everything manually is not an option so we’ll do our best to follow the rule of not hardcoding sizes :slight_smile: (especially as all this will depend on font size of the user’s computer, zoom level and all that).

Hope this helps,
Anca

#38

I went for the manual fix based on ratio (of 1.666…) (if not matching one of the expected radius size).

The PR is now merged, thanks all for the feedback.

2 Likes
#39

I don’t understand those commits, see XWIKI-21334: Uniformize the rounded edges of visual elements by manuelleduc · Pull Request #2385 · xwiki/xwiki-platform · GitHub .

It feels to me like we’re replacing hardcoded values with other hardcoded values instead of replacing hardcoded values with variables.
Maybe I missed an episode (in which case the episode should have been explained in comments of commits or code) but wasn’t the purpose to get rid of as much of the hardoded values as possible? This is what I was saying above in my comment…