You can also check the options button on a notification, this is also a btn-xs, here in the screenshot the button in the lower right corner:
So it seems that for small size buttons, 7px might seem a bit too round and, thus, unpolished (the roundness doesn’t seem intentional). I feel like 3px is a bit low for this kind of button and a 5px border-radius would work best.
From my own observation this kind of small button is an exception so we can make a special case for it.
Looks good. I’m fine with 7px for large UI elements and 5px for smaller ones, but better have a rule, i.e. define more precisely what means small.
Thanks,
Marius
Agreed, we need a precise rule.
Otherwise, the proposal sounds good to me.
Thanks
Yep, a rule would help. I’ll make an “audit” of general elements that we have in our UI and then based on that decide which takes which values and what size category do they go in to make a general rule for future usecases
1 Like
+1 LGTM
Note that this button is slightly too small to achieve the WCAG 2.2 criterion SC 2.5.8:Target Size (Minimum) without using an exception (22 * 24 instead of minimum 24 * 24 ). Reported the issue: XWIKI-21204
For the small category, you might want to consider the elements in the lightbox (appears on image hover) and the document tags. 
We already have a couple sizes that could be used as thresholds for this rule, see CSS recommendation: pointer targets are large enough .
Thank you for your work on the proposal! It’s really nice to see all the different variations at a glance.
Lucas C.
Thanks a lot for this! I’ll take this into consideration when making the audit
Hello @amilica , all,
The first question I have that we probably should look at when looking at corner rounding is:
should the radius be a fixed size or a proportion of the size of the element whose borders are round?
My view on it:
- if the objective is to obtain circles like google search input, then it needs to be a proportion
- if the objective is to soften a sharp edge, then it can be a fixed size.
Design system’s view on it:
Bootstrap 3 (the one we use) actually has 3 radius sizes:
- a base
- a small one
- a large one
and I imagine it may use a different radius size depending on the element.
See Customize and download · Bootstrap (these are awfully hardcoded in pixels in bootstrap 3 but well, then again, everything is hardcoded in bootstrap 3 
).
From my point of view, the choice we make here should be implementable uniquely by adjusting the defaults of these variables of bootstrap, which has the great benefit of allowing whoever customizes a color theme for XWiki to set them all to other values to obtain a different look (e.g. I set them often all to 0 these days ).
Thus, in order to see how an adjustment of corners would look on the various elements of XWiki, I think we’d need to check which elements use which size of radius from bootstrap, as their look may adjust differently (and not be 7px everywhere). For example, I can expect that a well (the warning) has a large radius while a button has a base radius (but I don’t know exactly, it needs to be checked).
Thanks,
Anca
Also, I haven’t mentioned it explicitly here:
I don’t find very rounded corners very appealing personally today, but it’s a matter of aesthetic and fashion (I cannot explain it).
Also, I see / know that there are lots of applications that are now using perfectly sharp corners (0 rounding) - for example the forum we’re on right now - I was wondering how does this trend / principle play with the idea that “round corners are easier on our eyes, thus helping us scan content easier” that you mentioned? All these people that make sharp corners just don’t care? Is there literature on the topic that so many people decide to ignore this?
Thanks,
Anca
For a pill shape like the google search input, it’s actually a fixed size too, bigger than the smallest dimension of the element
See https://codepen.io/sereza7/pen/wvQZVwy for an example
Proportional border-radius just look ‘special’ on anything that’s not square shaped.
Here, the border radius is 24px, which is higher than half the height of the div (46px / 2), so it’s a perfectly round pill end
fixed to a size that needs to be more than half of the size of the actual element is proportional to me, regardless of how the rule is actually written. Since you cannot write a universal rule that would apply to all elements regardless of their size (or can you max it?), it’s still proportional, as a principle…
1 Like
If we are reffering to pill-like shapes, this can be achieved with setting the border-radius to 999px or 3vmin, like discussed here:
Thing is, apart from tags / badges, we might not need this kind of thing. At a quick glance, another place where I could see pill-shapes useful would be text fields, but this would be better to talk if we ever decide to revamp live tables.
this would mostly be the case
Yep, I’ve said in an earlier reply that I’ll make an audit of elements and see which elements would get what size. It’s a good idea to see which sizes Bootstrap 5 implements for border-radius of all of their elements
As mentioned twice here, yep, there definetly is scientific literature on this. One of the papers is available online, but is pretty stuffy.
Some more details on the quote I provided in the start of the discussion:
2 scientific papers which clearly explain the relationship between the roundness of objects and the way humans perceive them. The first one was published in 2008 by the Barrow Neurological Institute in Phoenix, Arizona [1] which has scientifically proven that the perceived brightness of corners is linearly related to the sharpness of corner angle, so basically the sharper an angle is, the brighter it appears to the human eye.
Now, at this point maybe we could connect the dots ourselves and assume that brighter objects are probably less comfortable on the eyes, after all, dark mode has probably gained a lot of popularity recently for the same reason. However, some scientists at the Barrow Neurological Institute have luckily published another paper in 2019 [2] measuring the exact amount of neural response when the eye sees an object based on the corner angle of this object, and the results as the graph below shows that the smaller the corner angle of an object (the shaper, more pointy), the more neural spikes it elicits in the neurons of the visual system. Hence, rounder shapes are more comfortable for the brain and consume less energy to grasp.
Now, people may choose sharp corners in an attempt to make certain elements feel more obvious/ more important. Thing is, when everything has sharp corners this effect is lost.
Moreover, because of the visual comfort they add, rounded corners are also making the interface friendlier to the user. As we make software for people that are working everyday with our software, it’s important that XWiki doesn’t feel like a boring day of work, but, at the very least, like a decently pleasant experience
As the forum is an utilitarian tool, it was probably thought that sharp corners would go better with the idea of being objective, neutral, straight to the point.
Also, as is the the case with many open-source projects, UI/UX falls on the second place, functionality having the spotlight (as it should, of course).
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 https://try.discourse.org/ ).
Also, UX is functionality, so there is nothing “normal” about functionality taking the spotlight over UX…
Thanks,
Anca
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!
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.
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.
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 
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:
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