Improve the user-friendliness of some strings in the Fonts KCM. "Anti-aliasing" is a technical term not well understood by people who aren't like us, and we can also shorten some strings with no loss of meaning.
BUG: 386566
FIXED-IN 5.14
Lint Skipped |
Unit Tests Skipped |
Sometimes it's better to be precise about well-known technical terms instead of hiding them. Would a person who does not know what anti-aliasing is want/need to change that setting?
I agree, this is a very fundamental question we should always make as we design. We have our motto, simple by default, powerful when needed. I feel this setting is more "powerful when needed." I would think that it needs to be in an 'advanced' section or in second place to fundamental controls. You can decide how to present it.
Most of this stuff used to be hidden behind a Configure button, but it was changed to put everything on the main page in 5.13 as part of the QML port in D8916 - which was based on your mockup, @abetts: M112/411
IMHO as long as we're going to present everything on the main page, we need to make sure it's as user-friendly and comprehensible as possible. I think the sort of person who knows what "anti-aliasing" means is likely to understand that "font smoothing" is the same thing. I'm less sure that the reverse is true, which is why I submitted this patch (and presumably why @abetts filed the bug).
Another point: until we're able to use better default settings for anti-aliasing (see https://bugs.kde.org/show_bug.cgi?id=389598 and https://bugs.kde.org/show_bug.cgi?id=290909), I think it's reasonable to expect regular users to fiddle with these settings in pursuit of better-looking fonts, which requires that these settings be at least somewhat comprehensible.
Maybe add the technical term in brackets though, for those people who search for the technical term and don't find it otherwise?
kcms/fonts/package/contents/ui/main.qml | ||
---|---|---|
135 | What's the rationale of these two changes? |
kcms/fonts/package/contents/ui/main.qml | ||
---|---|---|
135 |
|
I'm ok with shortening the strings, i don't think anti alias is much more complicated than smoothing?
"Anti-aliasing" is esoteric technical jargon; "Smoothing" is plain language. The point is to replace the former with the latter.
some jargon words become so common they are the most obvious one..
I don't have the pulse on where anti alias stands, so if as native speaker you think antialias isn't nearly common enough, go for it :)
I ran into an issue with the QtQuick tooltips, unfortunately: they don't wrap, and instead overflow the bounds of the window:
I couldn't figure out a way to limit the width to avoid overflowing. Even if so, it would probably be best to fix that globally, rather than just here, so I filed https://bugs.kde.org/show_bug.cgi?id=396385.
I can revert that part of the diff if this is a deal-breaker.
I know that doing user research is not something favored here, but given how easy it is to use some user testing to settle discussions like this in a fact-based manner, I would really suggest the following:
Each of us here who knows people that use English as their UI languague (regardless of whether they are native speakers or not, doesn't matter if they use Plasma) takes a couple of them,
Yes, the sample would be relatively small, but even a small sample of people != us tells us more about our users than our introspection.
Plus, we might be surprised by them either understanding both terms, or maybe neither of them (which would mean we'd have to come up with a better term).
If we don't know enough people, we can easily reach out to other KDE people to do the same, since it's very easy to do.
This may sound like overkill for you, but I honestly believe we should start getting in the habit of doing more empirical research, rather than each of us thinking we magically know best.
Good idea, @colomar. I did that in D10245#201638, resulting in a change supported by at least a little bit of user testing: D11768: Add Desktop and Downloads to the default list of Places.
I'll do a little survey for this too.
So, first (and perhaps for me only one this time) guerilla test:
Participant:
Procedure:
Results:
Interpretation:
For this non-technical user, "Font smoothing" is more understandable than anti-aliasing, but does not at all help her understand the purpose of the setting or why she would change it
This - combined with the fact that I was unable to explain the concept of anti-aliasing to her without consulting WIkipedia - reinforces the perception that this is a f**king advanced setting (and it's still the least advanced of that group of settings down there!) which no "regular" user will understand without reading up on the topic, and for 99% of users just leaving the default untouched will be best anyway. Therefore, I really believe we have to introduce some separation for "advanced settings" (which @abetts had in several iterations of his System Settings mockups anyway) which users will only even open when they need to change them and know what they are.
For those, we might as well leave it as "anti-aliasing", because users who don't understand what it is see no reason to change it no matter what it's called.
Since we shouldn't make decisions based on a sample of one, however, I'd encourage others to do the same to gather at least maybe a handful of participants.
+1 on removing style/type from the strings
I'm unsure about the anti-aliasing/font smoothing discussion and I understand both sides. However, if we were to change it to smoothing then we should also consider renaming sub-pixel rendering to be consistent.
kcms/fonts/package/contents/ui/main.qml | ||
---|---|---|
221 | This is wrong. The hinting style option is independent from sub-pixel rendering. There are five hinting algorithms in freetype:
But some of them only make sense in combination with other settings, e.g. FT_LOAD_TARGET_MONO would only be used when anti-aliasing is turned off and FT_LOAD_TARGET_LCD_V would imply that sub-pixel rendering is activated and you display is turned vertically (vrgb or vbgr). The hintingstyle (as in fontconfig/Xft) would then be mapped to one of these hinting algorithms or turn off hinting at all. |
FYI I've submitted a new patch with only the non-controversial elements of this one: D15738: [Fonts KCM] remove filler words from anti-aliasing settings' labels
Looks like the conclusion is that this isn't the right change. I would advocate for returning to an "advanced settings" dialog or sub-page to hold these settings, and then we wouldn't have to be so shy about presenting technical terms.