[Fonts KCM] Improve user-friendliness of some anti-aliasing strings
AbandonedPublic

Authored by ngraham on Jun 18 2018, 7:09 PM.

Details

Reviewers
None
Group Reviewers
Plasma
VDG
Summary

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

Test Plan

Before:

After:

Diff Detail

Repository
R119 Plasma Desktop
Branch
more-user-friendly-strings-in-fonts-KCM (branched from master)
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 734
Build 746: arc lint + arc unit
ngraham created this revision.Jun 18 2018, 7:09 PM
Restricted Application added a project: Plasma. · View Herald TranscriptJun 18 2018, 7:09 PM
Restricted Application added a subscriber: plasma-devel. · View Herald Transcript
ngraham requested review of this revision.Jun 18 2018, 7:09 PM
ngraham edited the test plan for this revision. (Show Details)Jun 18 2018, 7:10 PM

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?

abetts added a subscriber: abetts.Jun 18 2018, 7:28 PM

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.

ngraham added a comment.EditedJun 18 2018, 7:36 PM

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.

ngraham edited the summary of this revision. (Show Details)Jun 18 2018, 7:36 PM
Fuchs added a subscriber: Fuchs.Jun 19 2018, 1:54 PM

Maybe add the technical term in brackets though, for those people who search for the technical term and don't find it otherwise?

How about in a tooltip?

Fuchs added a comment.Jun 19 2018, 1:58 PM

How about in a tooltip?

whatever is search- and findable, I guess.

davidedmundson added inline comments.
kcms/fonts/package/contents/ui/main.qml
143

What's the rationale of these two changes?

ngraham added inline comments.Jun 19 2018, 2:07 PM
kcms/fonts/package/contents/ui/main.qml
143
  1. Reducing unnecessary string length: I didn't think "type" and "style" added anything.
  2. Making the text work with all options. e.g. Hinting style: none seems kind of awkward ("none" isn't really a style)
mart added a subscriber: mart.Jun 22 2018, 8:51 AM

I'm ok with shortening the strings, i don't think anti alias is much more complicated than smoothing?

In D13593#281594, @mart wrote:

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.

mart added a comment.EditedJun 25 2018, 11:26 AM

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 :)

ngraham updated this revision to Diff 37525.Jul 10 2018, 7:41 PM

Add technical tooltips

In D13593#282711, @mart wrote:

if as native speaker you think antialias isn't nearly common enough, go for it :)

Yes, that's my position. :)

ngraham updated this revision to Diff 37533.Jul 10 2018, 10:06 PM

Revert unintentional changes

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,

  • shows them the screenshots with both terms (individually, in randomized order)
  • asks them what they think this setting means
  • records the answers
  • records whether the participant should be considered a "regular" or "advanced" users

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:

  • Plasma user for several years (because I recommended it to her)
  • Frequent but generally mostly "non-technical" computer user
  • Uses Plasma in English but isn't a native English speaker
  • Has quite some experience with GIMP (also in English) and Snapseed, but not with a professional background or education

Procedure:

  1. Showed her the "After" screenshot, told her it's from the Fonts area in System Settings, and asked her "What do you think this setting does? ", pointing at the Font smoothing setting
  2. Showed her the "Before" screenshot with the same question
  3. Asked her which one she would understand better

Results:

  • "Font smoothing" reminded her of blurring filters in photo editors, but she could not imagine why she'd want to do that with fonts.
  • "Anti-aliasing" didn't ring a bell for her at all. After I showed her the Wikipedia article about it, she understood the concept, but she has never noticed aliasing in screen fonts nor has she ever noticed problems caused by anti-aliasing in fonts, so she can't see a reason why she would ever want to change that setting
  • After reading the article on anti-aliasing, she still compared it to the blurring filters in photo editors, and therefore thought that she would have understood the same from reading "Font smoothing"

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.

harmathy added inline comments.
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:

  • FT_LOAD_TARGET_NORMAL
  • FT_LOAD_TARGET_LIGHT
  • FT_LOAD_TARGET_MONO
  • FT_LOAD_TARGET_LCD
  • FT_LOAD_TARGET_LCD_V

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

ngraham abandoned this revision.Nov 27 2018, 11:01 PM

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.