[kirigami] Do not use light font styles for headings (2/3)
ClosedPublic

Authored by filipf on Jan 1 2019, 9:50 PM.

Details

Summary

This patch turns off light font styles for some headings because they cause visual and legibility issues, as explained in the respective bug report.

CCBUG: 402730

FIXED-IN: 5.54

Test Plan

Worst case scenario testing - font does not have a "light" variant and falls back to using a thinner one such as "hairline"

Before:

After:

Plasma defaults testing

Before:

After:

Diff Detail

Repository
R169 Kirigami
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
filipf created this revision.Jan 1 2019, 9:50 PM
Restricted Application added a project: Kirigami. · View Herald TranscriptJan 1 2019, 9:50 PM
Restricted Application added a subscriber: plasma-devel. · View Herald Transcript
filipf requested review of this revision.Jan 1 2019, 9:50 PM
filipf edited the summary of this revision. (Show Details)Jan 1 2019, 9:56 PM
filipf edited the test plan for this revision. (Show Details)
filipf added reviewers: ngraham, Plasma, VDG.
filipf retitled this revision from [kirigami] Don't use light font styles for headings (2/3) to [kirigami] Do not use light font styles for headings (2/3).Jan 1 2019, 11:02 PM
filipf edited the summary of this revision. (Show Details)
ngraham accepted this revision.Jan 1 2019, 11:08 PM

Strongly approve for all the reasons given in https://bugs.kde.org/show_bug.cgi?id=402730.

Let's wait a bit though to make sure the Plasma developers have a chance to weigh in.

This revision is now accepted and ready to land.Jan 1 2019, 11:08 PM
filipf edited the test plan for this revision. (Show Details)Jan 2 2019, 1:21 PM
mart added a subscriber: mart.Jan 3 2019, 10:40 AM

I'm very much against this, I think it looks very bad :/

abetts added a subscriber: abetts.Jan 3 2019, 3:38 PM

Goodness, I think this is all about taste. I am more on the side that it looks good. It visually prioritizes hierarchy with labels. @mart Does it just look bad for you or do you think this will cause issues somewhere else?

filipf added a comment.Jan 3 2019, 4:15 PM
In D17906#385682, @mart wrote:

I'm very much against this, I think it looks very bad :/

I think the idea to have a light style for big titles is nice and could theoretically work, but in our case unfortunately fails in practice :/

The thing is, even if we didn't have a problem with fonts (btw defaults are not a guaranteed experience either, e.g. Fedora ships Plasma with "Sans") potentially failing, visual hierarchy is still something which doesn't work the best with the old code.

Attaching some screenshots from our main competitors for comparison's sake:

Notifications (D17905):

App stores:

  • Mac App Store

  • Windows Store

  • GNOME Software:

With the exception of the case of the Windows Store (which does nonetheless manage to achieve some visual hierarchy with different font sizes and colors), others mostly actually have an opposite approach and go the bold/semi-bold route for the more prominent titles, which makes sense - you want to highlight the information contained in them. But the point of this patch is to just make sure the most important information is not made less important or even illegible, which is guaranteed if the labels are "regular" style.

filipf added a subscriber: Frameworks.
ngraham added a subscriber: rooty.Jan 3 2019, 7:15 PM

Aesthetics are admittedly subjective, though I must note that pretty much all of VDG is in favor of moving away from light header text for aesthetic reasons. However there are other important technical arguments as well, which I will restate here:

  • Implementation inconsistency: Many fonts don't have a dedicated light style, many distros don't ship them if they do, and Qt < 5.12 doesn't use them even if they're there. As a result, the visual effect is hampered by an inability to consistently display it.
  • Usability problems: with many fonts, the light styles are very difficult to see. Fonts that do not have a dedicated light style often receive the ultra light variant instead, which is almost always borderline illegible. A great deal of text throughout Plasma and KDE apps use reduced opacity for de-emphasis or inactive text and in this case, using a light style results in the text often being actually illegible. @rooty has posted examples in this and other Phab tickets as well as in the linked bug.
  • Conceptually incorrect: It's incorrect to have headers use a reduced visual weight compared to the content below them. Headers are supposed to be bigger and bolder than the text in their content area. They're supposed to draw attention to themselves. That's their reason for existence. A header that tries to de-emphasize itself is a contradiction in terms.
mart added a comment.Jan 7 2019, 1:55 PM

With the exception of the case of the Windows Store (which does nonetheless manage to achieve some visual hierarchy with different font sizes and colors), others mostly actually have an opposite approach and go the bold/semi-bold route for the more prominent titles, which makes sense - you want to highlight the information contained in them. But the point of this patch is to just make sure the most important information is not made less important or even illegible, which is guaranteed if the labels are "regular" style.

of all of those the one i prefer by a long shot is indeed windows store which actually looks exactly like our graphics,

is not conceptually different from
in any way really.

the reason that in many places the visual hierarchy has been broken, like in plasma tooltips or calendar, is because the title text has been changed to be stupidly small, but the fact that it has been ruined, is not a good excuse to ruin it even more.

mart added a comment.Jan 7 2019, 1:56 PM
  • Implementation inconsistency: Many fonts don't have a dedicated light style, many distros don't ship them if they do, and Qt < 5.12 doesn't use them even if

nope, with the workaround used it works even with old versions

mart added a comment.Jan 7 2019, 1:58 PM

in the end i *may* accept non light titles, even tough i still very much don't like the idea, but what i don't want to never, ever see in any circumstance is bold titles, anything of that will just be reverted.

mart added a comment.Jan 7 2019, 2:17 PM

can we still keep as light the first level of heading, which is huge (and use that sparsingly) and go to levels from 2 onwards where needed smaller and bigger?

filipf added a comment.EditedJan 7 2019, 2:40 PM

I was actually just going to reply that light titles could work theoretically well with level 1 headings before I saw your last comment. For this to work right, for me it would mean:

  • certain adjustments for visual hierarchy; big headings must still retain visual priority-> e.g. the application's description in Discover would need to have some opacity
  • Qt using only the "light" font style and not falling back to styles such as "hairline" or "ultrathin"

Although you then still have the problem of potentially too thin "light" styles with some fonts + not being able to guarantee your effect if the font doesn't have the light style. So the latter also means if you fix point no. 1 I mentioned, you get super in your face titles because the font is now regular.

Have you managed to test the current solution with some other fonts maybe? With more testing we could see for how many it works in the first place and how many are troublesome (e.g. DejaVu Sans).

rooty added a comment.EditedJan 7 2019, 2:44 PM
In D17906#388052, @mart wrote:

can we still keep as light the first level of heading, which is huge (and use that sparsingly) and go to levels from 2 onwards where needed smaller and bigger?

very much against this idea... it might work if we used segoe ui, but that's about the only instance in which it would

  • Usability problems: with many fonts, the light styles are very difficult to see. Fonts that do not have a dedicated light style often receive the ultra light variant instead, which is almost always borderline illegible. A great deal of text throughout Plasma and KDE apps use reduced opacity for de-emphasis or inactive text and in this case, using a light style results in the text often being actually illegible. @rooty has posted examples in this and other Phab tickets as well as in the linked bug.

+1

filipf added a comment.Jan 7 2019, 2:53 PM
In D17906#388052, @mart wrote:

can we still keep as light the first level of heading, which is huge (and use that sparsingly) and go to levels from 2 onwards where needed smaller and bigger?

nope, very much against this idea... it might work if we used segoe ui, but that's about the only instance in which it would

Not true, it might work with Noto Sans and with adjustments, but the problem is we dont lock people into using the same font. They have an easier job in Windows and co.

filipf added a comment.EditedJan 7 2019, 5:55 PM

Updating an another computer to Frameworks 5.53 and Qt 5.12 I get the same problem.

For me this represented a massive regression, and there's bound to be more people in a similar situation. We can't have this happening.


In this one, the fact that it's a header is connoted by its much larger font size and wider character width and spacing. It feels "bigger" in every way than the text beneath it. It looks good.

This photo is quite different. Here the header text is no larger or barely larger than the text beneath it, and its line weight is lighter. Also, it's very visually disconnected from the thing it's a header for, since it's stuck up in the top-right corner of a visually superfluous stock photo. Nothing about the header text tells my eye "I'm a header!"

mart added a comment.Jan 9 2019, 9:48 AM

Updating an another computer to Frameworks 5.53 and Qt 5.12 I get the same problem.

For me this represented a massive regression, and there's bound to be more people in a similar situation. We can't have this happening.

uuh, that's the wrong color.. that's seriously weird?
that's on same version how i get notifications on a dark color scheme

mart added a comment.Jan 9 2019, 9:55 AM


In this one, the fact that it's a header is connoted by its much larger font size and wider character width and spacing. It feels "bigger" in every way than the text beneath it. It looks good.

This photo is quite different. Here the header text is no larger or barely larger than the text beneath it, and its line weight is lighter. Also, it's very visually disconnected from the thing it's a header for, since it's stuck up in the top-right corner of a visually superfluous stock photo. Nothing about the header text tells my eye "I'm a header!"

it's exactly 180% the notmal font. It was bigger, I was told to shrink it

The HIG states: "When the visual design calls for an area of exceptional focus, a larger typeface size may be used. In this case use a Light typeface weight to keep the stroke width similar to other styles throughout the interface"

I think, if you want to have something like

you should use your own special sized label. And if you want to add so much focus on a text, it can be unique in its font size.

To me it seams the predefined Header[1-4] are mainly to be used for regular content and chrome?

Updating an another computer to Frameworks 5.53 and Qt 5.12 I get the same problem.

For me this represented a massive regression, and there's bound to be more people in a similar situation. We can't have this happening.

You are not using the default font, are you?

You are not using the default font, are you?

In D17906#389713, @mart wrote:

uuh, that's the wrong color.. that's seriously weird?
that's on same version how i get notifications on a dark color scheme

This the "Qt will use whichever light font style is present" problem.

It says "Light", but is actually "Hairline". On both of my machines the font got installed this way.

As I said, light titlebars don't work great with Noto now either, but can even fall apart more with other fonts.

  • Roboto has a really thin "Light" variant:

  • DejaVu Sans only has an "ExtraLight" variant:

mart accepted this revision.Jan 9 2019, 3:29 PM

bah, seems very tricky to make it work properly across distributions.

to me, it speaks mostly as a failure for us to control the look of our product, due to broken fonts in distros and qt font rendering still buggy, issue that unfortunately the vertical platforms like Windows don't have.
the intention was to have heading with the same stroke width as the rest of the text, or slightly more still (which works on noto at least for level 1, apparently not on other styles)

so i'm ok to remove the light font here, but clearly as a failure to make it work properly due to the state of the lower stack

to me, it *is* still a clear visual regression, but is ok to go as "the least broken" option for now to not touch weigth.
with a clear intent to monitor the situation.

I wonder if it shouldn't be something in the future eventually part of the theme, I see things like menu font and toolbar font in fonts kcm as something completely obsolete, while those settings should be more about conventional typography (like normal font, heading font etc)

mart added a comment.Jan 10 2019, 11:12 AM

so, if this is pushed, the same thing should happen at the same time to the corresponding plasma components

Yep, will do. We have other diffs for those.

This revision was automatically updated to reflect the committed changes.
In D17906#389914, @mart wrote:

I wonder if it shouldn't be something in the future eventually part of the theme, I see things like menu font and toolbar font in fonts kcm as something completely obsolete, while those settings should be more about conventional typography (like normal font, heading font etc)

+1 FWIW