On 07/04/14 20:19, Jon Robson wrote:

After the deploy last Thursday various users on Village Pumps bug reports and external sites (e.g. Twitter and Reddit) were informing us that the new typography was unreadable. Sadly it was difficult to distinguish whether this was simply a dislike of the new fonts or something deeper related to a bug.

After lots of experimentation and reaching out to users on Friday, we discovered that the free fonts in the stack were rendering very poorly on some Windows machines. I experimented with some live hacks to beta labs to try and identify the problems [1] with a user who was experiencing the problem. I tested various things like text-size-adjust and font size. The problem that caused the text to be unreadable for the user was the Liberation Sans font [2]

I tried to restore Arimo [3] and although it was fine for this particular user, it wasn't fine for another user, meaning both our fonts were causing issues. As a result, I have pulled together a small patch to remove these fonts [4]. This is meant as only a short term solution.

As for a long term solution, what can we do? Ideas in my head involve

1. Picking a new open font that is either

** widely available on Linux but not so much on Windows ** renders well in Windows 2) We create our own open font, maybe forking an existing font. 3) We restore these two fonts to the font stack but using JavaScript either enable or disable them on Windows machines 4) We identify the issues here with the existing fonts, filing upstream bugs and find a timeframe in which we can restore them by 5) Insert your idea here

I welcome your ideas on how we can find an open font that keeps all users happy.

Is it worth opening an RFC on MediaWiki.org to discuss our options some more?

[1] http://en.wikipedia.beta.wmflabs.org/w/index.php?title=MediaWiki:Common.css&... [2] http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:MobileDiff/86501 [3] http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:MobileDiff/86501...86502 [4] https://gerrit.wikimedia.org/r/124387

5) Restore the status quo - specifying 'sans-serif' as the font, which translates to the default font for the platform, had none of these problems, and resulted in fonts for all platforms which were good for those platforms (though perhaps not necessarily the best).

* Windows users got fonts optimised for Windows, and which Windows knows well how to render. They may not be free, but /we/ weren't the ones prioritising the non-free. * Linux users got whatever (probably free) font their distribution provides, for which in all likelihood their fontconfig (rendering settings) is also optimised. * Those with cleartype etc off previously had fonts that rendered properly or they would not have been using their system with cleartype etc off for all this time. * Anyone previously using free fonts, on whatever platform, did not have their choices overridden. This also applies to those using dyslexic-friendly and other accessibility-oriented fonts. * And so on.

Given that no objective and verifiable issues with this were ever provided to explain the need for a shift to specific fonts across all platforms and languages in the first place, this means there should also be no issues with going back.

-I

* Isarra Yos wrote:

5. Restore the status quo - specifying 'sans-serif' as the font, which

translates to the default font for the platform, had none of these problems, and resulted in fonts for all platforms which were good for those platforms (though perhaps not necessarily the best).

• Windows users got fonts optimised for Windows, and which Windows knows well how to render. They may not be free, but /we/ weren't the ones prioritising the non-free.
• Linux users got whatever (probably free) font their distribution provides, for which in all likelihood their fontconfig (rendering settings) is also optimised.
• Those with cleartype etc off previously had fonts that rendered properly or they would not have been using their system with cleartype etc off for all this time.
• Anyone previously using free fonts, on whatever platform, did not have their choices overridden. This also applies to those using dyslexic-friendly and other accessibility-oriented fonts.
• And so on.

Given that no objective and verifiable issues with this were ever provided to explain the need for a shift to specific fonts across all platforms and languages in the first place, this means there should also be no issues with going back.

Sounds very good to me.

This. Let's go back to what we *know* worked.

-Chad On Apr 7, 2014 1:52 PM, "Isarra Yos" zhorishna@gmail.com wrote:

On 07/04/14 20:19, Jon Robson wrote:

...

After the deploy last Thursday various users on Village Pumps bug reports and external sites (e.g. Twitter and Reddit) were informing us that the new typography was unreadable. Sadly it was difficult to distinguish whether this was simply a dislike of the new fonts or something deeper related to a bug.

After lots of experimentation and reaching out to users on Friday, we discovered that the free fonts in the stack were rendering very poorly on some Windows machines. I experimented with some live hacks to beta labs to try and identify the problems [1] with a user who was experiencing the problem. I tested various things like text-size-adjust and font size. The problem that caused the text to be unreadable for the user was the Liberation Sans font [2]

I tried to restore Arimo [3] and although it was fine for this particular user, it wasn't fine for another user, meaning both our fonts were causing issues. As a result, I have pulled together a small patch to remove these fonts [4]. This is meant as only a short term solution.

As for a long term solution, what can we do? Ideas in my head involve

1. Picking a new open font that is either

** widely available on Linux but not so much on Windows ** renders well in Windows 2) We create our own open font, maybe forking an existing font. 3) We restore these two fonts to the font stack but using JavaScript either enable or disable them on Windows machines 4) We identify the issues here with the existing fonts, filing upstream bugs and find a timeframe in which we can restore them by 5) Insert your idea here

I welcome your ideas on how we can find an open font that keeps all users happy.

Is it worth opening an RFC on MediaWiki.org to discuss our options some more?

[1] http://en.wikipedia.beta.wmflabs.org/w/index.php?title= MediaWiki:Common.css&action=history [2] http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:MobileDiff/86501 [3] http://en.m.wikipedia.beta.wmflabs.org/wiki/Special: MobileDiff/86501...86502 [4] https://gerrit.wikimedia.org/r/124387

5. Restore the status quo - specifying 'sans-serif' as the font, which

translates to the default font for the platform, had none of these problems, and resulted in fonts for all platforms which were good for those platforms (though perhaps not necessarily the best).

• Windows users got fonts optimised for Windows, and which Windows knows well how to render. They may not be free, but /we/ weren't the ones prioritising the non-free.
• Linux users got whatever (probably free) font their distribution provides, for which in all likelihood their fontconfig (rendering settings) is also optimised.
• Those with cleartype etc off previously had fonts that rendered properly or they would not have been using their system with cleartype etc off for all this time.
• Anyone previously using free fonts, on whatever platform, did not have their choices overridden. This also applies to those using dyslexic-friendly and other accessibility-oriented fonts.
• And so on.

Given that no objective and verifiable issues with this were ever provided to explain the need for a shift to specific fonts across all platforms and languages in the first place, this means there should also be no issues with going back.

-I _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Chad writes:

This. Let's go back to what we *know* worked.

https://gerrit.wikimedia.org/r/#/c/124387/ has already been merged, so you're /just/ late – unless you want to submit yet another patch reverting to sans- serif.

Tomasz

I noticed from Kaldari's notes [1] that "Open sans" was rejected based on language support and install base. I notice however that it is pretty popular on the web [2,3]. Can someone elaborate on these results as it is surprised me?

To me we can learn from this experience that install base (especially where Windows is concerned) is probably not such an important factor. The language support is more of an issue, but I wonder if this can be resolved by specific font stacks with more suitable open fonts is provided.

To improve install base we can easily iterate on this and start using web fonts in some form in the future.

[1] https://www.mediawiki.org/wiki/Typography_refresh/Font_choice#Body_font_eval... [2] http://www.typeandgrids.com/blog/the-ten-most-popular-web-fonts-of-2013 [3] http://www.smashingmagazine.com/2014/03/12/taking-a-second-look-at-free-font...

On Mon, Apr 7, 2014 at 2:49 PM, Tomasz W. Kozlowski tomasz@twkozlowski.net wrote:

Chad writes:

...

This. Let's go back to what we *know* worked.

https://gerrit.wikimedia.org/r/#/c/124387/ has already been merged, so you're /just/ late - unless you want to submit yet another patch reverting to sans- serif.

            Tomasz

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Private/offlist

Steven,

I think you're missing what Issara and others like myself have suggested: just reverting the fontstack part, not the font-size/color/etc that are a part of the changeset.

Greg

<quote name="Steven Walling" date="2014-04-07" time="15:41:02 -0700">

On Mon, Apr 7, 2014 at 1:52 PM, Isarra Yos zhorishna@gmail.com wrote:

...

5. Restore the status quo - specifying 'sans-serif' as the font, which

translates to the default font for the platform, had none of these problems, and resulted in fonts for all platforms which were good for those platforms (though perhaps not necessarily the best).

We're not going to do this.

The idea that one bug requires a complete revert and even more disruption for users is pretty absurd. Do we revert deployment of an extension every time a bug occurs? No. We do it when the disruption caused by keeping the new version is greater than taking it away again. This is not one of those times.

We made the last change, which includes vital improvements besides slightly altered body copy font family, after months of testing and prep. But all new software has bugs, even "simple" LESS-only changes when they have a scope this wide. The latest patch by Jon was a bug fix, but that doesn't mean we're going to cause further disruption for users by completely reverting back to the old defaults.

What we're going to do is discuss the options Jon laid out for trying to promote free fonts in our stack, while also being practical and retaining the enhancements that most users have been delivered so far. This is why we iterate on changes in any realm of design and development.

I'll also nudge us here to remember that we cannot make design decisions like this in a vacuum, without feedback from non-technical users. It wasn't perfect, but we've been working hard to do that as part of Typography Refresh. Jon's latest bug fix itself is based on reports from many users. So far they've been thankful we did this. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Sadly it was difficult to distinguish whether this was simply a dislike of the new fonts or something deeper related to a bug.

Since, you're changing something primarily for aesthetic purposes (I think anyways, all the accounts of why we even would want to change the font are very hand wavey and I'm honestly unsure what the principle motivations actually are), why isn't dislike of the new font a valid criticism? After all, the reason you are changing it in the first place is that you presumably did not like the old font.

5. Insert your idea here

Browsing through the feedback on this thing, there seems to an enormus amount of hate in our userbase for it. Lots of that is of the form of "its ugly" which some might argue is not constructive, but I personally think is something that should be taken into consideration when there are so many people making the complaint, and the change is mostly about aesthetics. Others have more concrete criticisms about eye strain and non latin text not working as good, etc.

Anyways to sum it up, this change is: *Fixing something that most users think is not a problem [citation needed, but that is my impression] *Causing behavior that significant numbers of users do not like (e.g. IDONTLIKEIT, its ugly, etc). A subset of users are experiancing behaviour that is objectively bad *In order to make it work acceptably, has to do something that a portion of our community finds ideaologically questionable, if not outright unacceptable. (Remember folks, we are a project built on ideaology. Ideaology is important)

Given the above, it seems like a temporary revert until solutions to the problems can be found, or a permenant revert if solutions can't be found, may be advisible.

--bawolff

On 08-04-2014 00:45, Steven Walling wrote:

On Mon, Apr 7, 2014 at 3:42 PM, Jon Robson jdlrobson@gmail.com wrote:

...

I noticed from Kaldari's notes [1] that "Open sans" was rejected based on language support and install base.

A similar example is Google's Noto font ( https://en.wikipedia.org/wiki/Noto_fonts). It has basically no default install base that I'm aware of, but it's focused on readability in as many scripts as possible and is Apache-licensed.

Noto is useless without a suitable localization mechanism.

I feel that I am not being taken seriously. Three times now I have indicated what is wrong with this solution, namely that a single font stack cannot possibly serve a global website.

I want to ask Steven and Jon how they plan on serving *all* the scripts and languages in the world in a *single* font stack. There is not a single font in existence that can possibly support all languages.

Again, this excercise is completely Latin-centered. Projects using different script have no choice but to override to their native fonts, and only Europe/Americas is left to 'enjoy' the new font stack.

Regards,

I feel that I am not being taken seriously. Three times now I have indicated what is wrong with this solution, namely that a single font stack cannot possibly serve a global website.

I'm sorry you feel this way, if I wasn't clear, I agree with you, but I think where we disagree is that we could support multiple font stacks based on language.

I want to ask Steven and Jon how they plan on serving *all* the scripts and languages in the world in a *single* font stack. There is not a single font in existence that can possibly support all languages.

Yes I thought I had recognised this. See my message above: "The language support is more of an issue, but I wonder if this can be resolved by specific font stacks with more suitable open fonts is provided." I think we have a great chance to iterate from here and get better font stacks for all our languages. LESS supports configurable variables after all.

On Mon, Apr 7, 2014 at 4:08 PM, Erwin Dokter erwin@darcoury.nl wrote:

I feel that I am not being taken seriously. Three times now I have indicated what is wrong with this solution, namely that a single font stack cannot possibly serve a global website.

I want to ask Steven and Jon how they plan on serving *all* the scripts and languages in the world in a *single* font stack. There is not a single font in existence that can possibly support all languages.

I think we actually answered this up front at https://www.mediawiki.org/wiki/Typography_refresh#Is_there_a_perfect_font_th...

Ultimately we're shooting for and getting a lot more consistency and control over the user experience here, for most users. That doesn't meant that it's perfect. There is definitely not a single font that is available everywhere that supports all languages. That's why it's a font stack with fallbacks. We definitely don't gain more consistency across the experience by moving back to a situation where the styles basically just define no style.

Again, this excercise is completely Latin-centered. Projects using different script have no choice but to override to their native fonts, and only Europe/Americas is left to 'enjoy' the new font stack.

To add on to what Jon said: we're going to figure this out in discussion with the communities. I don't think it's the case at all that users "have no choice" if they want readable text in a non-Latin script. To use CJK as an example: I actually was able to remove some local hacks that were necessary before the new version. We'll keep working on it.

On 08/04/14 00:02, Steven Walling wrote:

On Mon, Apr 7, 2014 at 4:08 PM, Erwin Dokter erwin@darcoury.nl wrote:

...

I feel that I am not being taken seriously. Three times now I have indicated what is wrong with this solution, namely that a single font stack cannot possibly serve a global website.

I want to ask Steven and Jon how they plan on serving *all* the scripts and languages in the world in a *single* font stack. There is not a single font in existence that can possibly support all languages.

I think we actually answered this up front at https://www.mediawiki.org/wiki/Typography_refresh#Is_there_a_perfect_font_th...

Ultimately we're shooting for and getting a lot more consistency and control over the user experience here, for most users. That doesn't meant that it's perfect. There is definitely not a single font that is available everywhere that supports all languages. That's why it's a font stack with fallbacks. We definitely don't gain more consistency across the experience by moving back to a situation where the styles basically just define no style.

...

Again, this excercise is completely Latin-centered. Projects using different script have no choice but to override to their native fonts, and only Europe/Americas is left to 'enjoy' the new font stack.

To add on to what Jon said: we're going to figure this out in discussion with the communities. I don't think it's the case at all that users "have no choice" if they want readable text in a non-Latin script. To use CJK as an example: I actually was able to remove some local hacks that were necessary before the new version. We'll keep working on it. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Why? All this effort, and for what? You want consistency in what's given to the users, but users are not consistent. Their hardware is not consistent, nor are their operating systems, languages, eyes, brains, habits, or preferences. As was, the default sans-serif already addressed these inconsistencies, giving them something that worked for them. Why go to all this trouble when the problem was already solved? What's the point?

-I

On Mon, Apr 7, 2014 at 5:46 PM, Brian Wolff bawolff@gmail.com wrote:

No you don't get more consistency by moving back to an experience where you let the browser determine fonts. However you do get a situation where things are more likely to work for non-latin scripts (and other issues that have been brought up, if I understand correctly). Consistency and actually working for all scripts are separate goals. If you can't satisfy both, you're going to have to make one take higher priority than the other. I personally consider the "Actually working for all languages" to be much more important consideration than consistency.

I totally agree. I don't see how there is any indication this is functionally broken or a major regression across languages, keeping in mind the necessity of ULS et al still. What major language-related bugs have been raised that would not be present regardless for most default sans-serifs?

I see some cases, such as CJK, where users may not prefer the serif headings, since serifs look closer to a brush script in those languages than they do in Latin languages. That doesn't seem to be what we're discussing though? When it comes to the body font settings and language support, we've been able to remove some local overrides. Some others, like Persian, had Common.css overrides long before the new version was released. The general state of affairs before *and* after is that there aren't great-looking, freely-licensed fonts with support across all languages and which are widely installed on our most popular OS/device combos. We're making incremental improvements here.

On Mon, Apr 7, 2014 at 5:40 PM, MZMcBride z@mzmcbride.com wrote:

I've read through this thread and I've formulated two questions:

• Is there consensus to specify "font-family: 'Helvetica Neue', Helvetica,

Arial, sans-serif;" in MediaWiki core?

I am going to be annoying and answer your question with a question: consensus among who? How do make a decision like this?

On the one hand, you have Wikimedia users, who don't really care about the appearance of promoting FOSS or not. They just want to things to work and look good. They also believe that the only consensus that matters is the one on their local wiki. They could honestly care less what the conglomeration of volunteer and staff developers think their internal consensus is. And mostly, even when something is a consensus decision based on an RFC/discussion, the Wikimedia Foundation gets the blame (as we should).

On the other hand, we have MediaWiki developers, some of whom would rather throw up their hands and not specify a real font stack, rather than touch the non-free fonts *most users already have* with a ten foot pole. They seem to think that an RFC or discussion on Wikitech-l is what represents a consensus that must be respected. And they don't feel responsible for what gets released on Wikimedia sites necessarily.

We can gain more consistent, accessible typography across languages with an iterative approach that continues to build on what we've done over the last five months. Or we can go back to the drawing board to try and please everyone, which is an impossibility if you ever want to make progress.

• Is there an issue with specifying "font-family: sans-serif;" in

MediaWiki core?

Do you mean just for body type as Odder proposed in https://gerrit.wikimedia.org/r/#/c/124475/, or for everything?

Steven

On 4/7/14, Steven Walling steven.walling@gmail.com wrote:

On Mon, Apr 7, 2014 at 5:46 PM, Brian Wolff bawolff@gmail.com wrote:

...

No you don't get more consistency by moving back to an experience where you let the browser determine fonts. However you do get a situation where things are more likely to work for non-latin scripts (and other issues that have been brought up, if I understand correctly). Consistency and actually working for all scripts are separate goals. If you can't satisfy both, you're going to have to make one take higher priority than the other. I personally consider the "Actually working for all languages" to be much more important consideration than consistency.

I totally agree. I don't see how there is any indication this is functionally broken or a major regression across languages, keeping in mind the necessity of ULS et al still. What major language-related bugs have been raised that would not be present regardless for most default sans-serifs?

I see some cases, such as CJK, where users may not prefer the serif headings, since serifs look closer to a brush script in those languages than they do in Latin languages. That doesn't seem to be what we're discussing though? When it comes to the body font settings and language support, we've been able to remove some local overrides. Some others, like Persian, had Common.css overrides long before the new version was released. The general state of affairs before *and* after is that there aren't great-looking, freely-licensed fonts with support across all languages and which are widely installed on our most popular OS/device combos. We're making incremental improvements here. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

I don't speak any non-latin languages, so I'm not competent to judge. I based my comment on a large number of complaints I'm seeing. Including Erwin Dokter's email earlier in this thread, and comments on wiki like: "I really really hate it. New fonts are really awful for non-latin languages." [1]

[1] https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump&old...

--bawolff

On Mon, Apr 7, 2014 at 6:44 PM, Tim Landscheidt tim@tim-landscheidt.dewrote:

(anonymous) wrote:

...

...

...

This. Let's go back to what we *know* worked.

...

...

https://gerrit.wikimedia.org/r/#/c/124387/ has already been merged, so you're /just/ late – unless you want to submit yet another patch reverting to sans- serif.

...

I would write said patch but I have no desire to get into WWIII on Gerrit over it. I've already fixed the whole nasty mess anyway and put MW back to how it should be[0]

...

[0] https://en.wikipedia.org/wiki/User:%5edemon/common.css

So we just need to get https://bugzilla.wikimedia.org/57891 ("Review and deploy GlobalCssJs extension to Wikimedia wikis") fixed :-).

If I was active on more than 2 wikis, maybe. Copy+paste WFM ;-)

-Chad

Steven Walling wrote:

On Mon, Apr 7, 2014 at 5:40 PM, MZMcBride z@mzmcbride.com wrote:

...

• Is there an issue with specifying "font-family: sans-serif;" in

MediaWiki core?

Do you mean just for body type as Odder proposed in https://gerrit.wikimedia.org/r/#/c/124475/, or for everything?

That's what I was looking for, thanks. Please remove your -2 from that change. I think you're better than that.

MZMcBride

On Apr 8, 2014 3:46 AM, "Steven Walling" steven.walling@gmail.com wrote:

On Mon, Apr 7, 2014 at 5:40 PM, MZMcBride z@mzmcbride.com wrote:

...

I've read through this thread and I've formulated two questions:

• Is there consensus to specify "font-family: 'Helvetica Neue',

Helvetica,

...

Arial, sans-serif;" in MediaWiki core?

I am going to be annoying and answer your question with a question: consensus among who? How do make a decision like this?

On the one hand, you have Wikimedia users, who don't really care about the appearance of promoting FOSS or not. They just want to things to work and look good. They also believe that the only consensus that matters is the one on their local wiki. They could honestly care less what the conglomeration of volunteer and staff developers think their internal consensus is. And mostly, even when something is a consensus decision

based

on an RFC/discussion, the Wikimedia Foundation gets the blame (as we should).

Is the above the group amongst who you think there is consensus to go with font stack "font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif;" ? It seems a rather nebulous group. Are you sure there is consensus amongst them, or could it reflect wishful thinking of what you're pretty sure they must agree with.

Also, I doubt that this entire group doesn't care about specifying non free fonts. If you hand-wave the group that does away, that leads to circular reasoning that the group that doesn't care about specifying non free fonts really doesn't care if non free fonts are specified. That doesnt tell us much.

I'm starting to doubt there is any group of people that you're not willing to dismiss the opinion of because the have the wrong opinion and we shouldn't listen to them on the issue of non free fonts.

On the other hand, we have MediaWiki developers, some of whom would rather throw up their hands and not specify a real font stack, rather than touch the non-free fonts *most users already have* with a ten foot pole. They seem to think that an RFC or discussion on Wikitech-l is what represents a consensus that must be respected. And they don't feel responsible for what gets released on Wikimedia sites necessarily.

We can gain more consistent, accessible typography across languages with

an

iterative approach that continues to build on what we've done over the

last

five months. Or we can go back to the drawing board to try and please everyone, which is an impossibility if you ever want to make progress.

...

• Is there an issue with specifying "font-family: sans-serif;" in

MediaWiki core?

Do you mean just for body type as Odder proposed in https://gerrit.wikimedia.org/r/#/c/124475/, or for everything?

Steven _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On 4/8/14, S Page spage@wikimedia.org wrote:

In https://gerrit.wikimedia.org/r/#/c/124475/ (go back to sans-serif) Legoktm claims "There was a consensus that listing only non-free fonts was not acceptable", that's not my recollection. Was a bug ever filed?

Kaldari valiantly tried to put non-free fonts first, that caused bug 63512. Now as I understand it, we're back to:

• Mac users get Helvetica Neue
• Windows users get Arial unless they have Helvetica Neue (unlikely) or

Helvetica (I can't reproduce bug 63662)

• Linux users get whatever F/OSS font fontconfig supplies for the

well-known string "Helvetica", I get Nimbus Sans L

• Android users ?? (Nobody responded.)

quoting Isarra Yos

...

Given that no objective and verifiable issues with this were ever provided ... Why? All this effort, and for what?

BECAUSE DESIGN. (I begged and pleaded with the talented designers who work next to me to put something emphatic in the Typography refresh FAQ.) It's a better design. It makes MediaWiki web sites look better for millions of our users by mentioning proprietary fonts that 90+% of them have. That's not "objective and verifiable", it just is. Is it worth mentioning non-free fonts? People disagree. But I'm saddened by the implicit and overt hostility towards the art of design here ("its debatable whether this actually represents "progress"",

How is that hostile to the "art of design". I have no problem with what the typo refresh project set out to do. I have a problem with what it actually did. I'm totally fine with the "art of design" as an abstract idea and I agree with 3 of the 4 stated requirements of Typo refresh (neutral on the consistency requirement).

"it seems like things have shifted more to managers at WMF make the decisions", etc.).

To clarify I never said that was necessarily a bad thing. Maybe it is, maybe it isn't. All I'm saying is that seems to be the direction we're heading. Heck in the context I was arguing for the side of typography refresh...

--bawolff

On 08-04-2014 03:25, Steven Walling wrote:

I totally agree. I don't see how there is any indication this is functionally broken or a major regression across languages, keeping in mind the necessity of ULS et al still. What major language-related bugs have been raised that would not be present regardless for most default sans-serifs?

I see some cases, such as CJK, where users may not prefer the serif headings...

I know that Japanese Wikipedia has reset [1] their font stack entirely one day after the refresh.

[1] https://ja.wikipedia.org/w/index.php?title=MediaWiki:Vector.css&diff=512...

Regards,

I don't really have the energy to keep having this conversation, I appreciate that everyone has taken the time to weigh in on this whatever you opinion is on the matter.

From Issara...

* Windows users got fonts optimised for Windows, and which Windows knows well how to render. They may not be free, but /we/ weren't the ones prioritising the non-free. * Linux users got whatever (probably free) font their distribution provides, for which in all likelihood their fontconfig (rendering settings) is also optimised. * Those with cleartype etc off previously had fonts that rendered properly or they would not have been using their system with cleartype etc off for all this time. * Anyone previously using free fonts, on whatever platform, did not have their choices overridden. This also applies to those using dyslexic-friendly and other accessibility-oriented fonts.

From S Page

* Mac users get Helvetica Neue * Windows users get Arial unless they have Helvetica Neue (unlikely) or Helvetica (I can't reproduce bug 63662) * Linux users get whatever F/OSS font fontconfig supplies for the well-known string "Helvetica", I get Nimbus Sans L

With the changes from Jon's patch removing Arimo and Liberation Sans, the current font stack renders very closely to what it was originally for Windows, and is improved for Mac and Linux users. For anyone on any platform who has made the decision to have helvetica on their machine they get an experience which is more consistent across devices, and platforms.

We said from day one that their might be some issues for a few non-latin scripts, and we've reached out to the admins of those sites to help them make small tweaks, as of jon's patch no one has provided us with any screenshots which highlight the issues that have been mentioned from this thread, I would welcome those screenshots as well as comments from users fluent in the languages to comment on the matter.

I understand if you "don't like it" there are a lot of things I don't like too. Sadly that is a fact of life. Sometimes we don't like thing, sometimes we have to learn to get used to things when they change. The thing that confuses me, is that someone would go so far as to try to prohibit others from doing their job based on their subjective opinion. Do product and design people go and -2 developers patches when they don't agree on the choices they've made? They do not. Do you know why? Its because we trust them to make good decision based on the acceptance of their knowledge of their domain. Why is Design different? Why does everyone think they have equal say when it comes to aesthetic choices, its a good question, one I don't think I'll try to answer here, but I think the gist of it is that everyone has opinions, everyone says "I could have done that" whether they could or not, whether they did or not.

We try as much as we can, with our limited time, and limited resources to validate our decisions in a measurable way. Sometimes this isn't possible, sometimes things are immeasurable. Does this mean that we shouldn't do them? No, it does not.

The question was asked, why do we spend so much time on this when there are other pressing matters to attend to. The answer is simple, because of this process, this discourse where every decision is questioned, because a process that should take a month takes six. I honestly want to move on to tackle other problems, but if everything that my team or the product teams work on comes up for a vote, it questioned to this degree, nothing will happen, nothing will improve.

I'm tired of fighting over this, I'd like to move on, and moving on does not mean going on to the status quo.

*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation

M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman

On Tue, Apr 8, 2014 at 8:10 AM, Isarra Yos zhorishna@gmail.com wrote:

On 08/04/14 06:57, S Page wrote:

...

In https://gerrit.wikimedia.org/r/#/c/124475/ (go back to sans-serif) Legoktm claims "There was a consensus that listing only non-free fonts was not acceptable", that's not my recollection. Was a bug ever filed?

Kaldari valiantly tried to put non-free fonts first, that caused bug 63512. Now as I understand it, we're back to:

• Mac users get Helvetica Neue
• Windows users get Arial unless they have Helvetica Neue (unlikely) or

Helvetica (I can't reproduce bug 63662)

• Linux users get whatever F/OSS font fontconfig supplies for the

well-known string "Helvetica", I get Nimbus Sans L

• Android users ?? (Nobody responded.)

Linux often gets arial. Anyone with wine will probably have it installed, too, and most will have wine even if they don't use it. It's not necessarily a particularly good copy, either.

quoting Isarra Yos

...

Given that no objective and verifiable issues with this were ever

...

provided ... Why? All this effort, and for what?

BECAUSE DESIGN. (I begged and pleaded with the talented designers who

work next to me to put something emphatic in the Typography refresh FAQ.) It's a better design. It makes MediaWiki web sites look better for millions of our users by mentioning proprietary fonts that 90+% of them have. That's not "objective and verifiable", it just is. Is it worth mentioning non-free fonts? People disagree. But I'm saddened by the implicit and overt hostility towards the art of design here ("its debatable whether this actually represents "progress"", "it seems like things have shifted more to managers at WMF make the decisions", etc.).

Saying something is 'better' doesn't make it so. There are real reasons behind why anything is better than something else, or it would not be better. Even art in general is not purely subjective; if it were, we wouldn't hire artists and designers at all because it would be just as subjective to them and everyone would have different views and it'd just be hopeless.

Good design is good because it plays to the way our brains work. Even without a background in neuroscience, artists and designers learn over time what works and why, and they often take classes to enumerate the concepts as well. These are concepts they should be referring to here, things about the composition, the contrast, the use of space, the interplay between the colours. You can't just say this painting did this 'because design' and expect anyone to take you seriously. You can, however, say that the added negative space helps to emphasise the subject, drawing attention away from that place in the background where someone punched a hole through the canvas. They may still not take you seriously because then they know you punched a hole in the canvas, but it's a real, understandable reason.

But there's more that needs to go into something like this beyond just the general principles of design - this isn't a painting, but a thing that people use. So what of the users themselves? What of the languages that it will be in, the disabilities that need to be accommodated, the hardware on which it will be displayed, the software that will be rendering it to the end user, and the principles we uphold? How is it better in these respects, and for these?

'Just is' doesn't fly. There is so much more to design than that, and to suggest otherwise discredits those who make it their passion.

-I

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Tue, Apr 8, 2014 at 7:29 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:

I don't really have the energy to keep having this conversation, I appreciate that everyone has taken the time to weigh in on this whatever you opinion is on the matter.

From Issara...

• Windows users got fonts optimised for Windows, and which Windows knows well how to render. They may not be free, but /we/ weren't the ones prioritising the non-free.
• Linux users got whatever (probably free) font their distribution provides, for which in all likelihood their fontconfig (rendering settings) is also optimised.
• Those with cleartype etc off previously had fonts that rendered properly or they would not have been using their system with cleartype etc off for all this time.
• Anyone previously using free fonts, on whatever platform, did not have their choices overridden. This also applies to those using dyslexic-friendly and other accessibility-oriented fonts.

From S Page

• Mac users get Helvetica Neue
• Windows users get Arial unless they have Helvetica Neue (unlikely) or

Helvetica (I can't reproduce bug 63662)

• Linux users get whatever F/OSS font fontconfig supplies for the

well-known string "Helvetica", I get Nimbus Sans L

With the changes from Jon's patch removing Arimo and Liberation Sans, the current font stack renders very closely to what it was originally for Windows, and is improved for Mac and Linux users. For anyone on any platform who has made the decision to have helvetica on their machine they get an experience which is more consistent across devices, and platforms.

So, the font stack changes with regards to the status quo now change nothing for Windows users, changes Helvetica -> Helvetica neue for Mac users and changes Arial, DejaVu Sans or Arimo for possibly something else, amongst which Nimbus Sans L, maybe, maybe not. It's not clear if the linux change is an improvement, as we have only one test case.

Is that amount of change - effectively changing from Helvetica to Helvetica neue on Mac and nothing else - really worth defining a non-free font stack for? Is it even worth the fight over it? Or have we gotten ourselves in a situation where not backing downhas become more important than the merits of the discussion. Do you really want to defend the position "We must use a non-free font stack, because otherwise our Mac users will get Helvetica rather than Helvetica Neue"?

--Martijn

We said from day one that their might be some issues for a few non-latin scripts, and we've reached out to the admins of those sites to help them make small tweaks, as of jon's patch no one has provided us with any screenshots which highlight the issues that have been mentioned from this thread, I would welcome those screenshots as well as comments from users fluent in the languages to comment on the matter.

I understand if you "don't like it" there are a lot of things I don't like too. Sadly that is a fact of life. Sometimes we don't like thing, sometimes we have to learn to get used to things when they change. The thing that confuses me, is that someone would go so far as to try to prohibit others from doing their job based on their subjective opinion. Do product and design people go and -2 developers patches when they don't agree on the choices they've made? They do not. Do you know why? Its because we trust them to make good decision based on the acceptance of their knowledge of their domain. Why is Design different? Why does everyone think they have equal say when it comes to aesthetic choices, its a good question, one I don't think I'll try to answer here, but I think the gist of it is that everyone has opinions, everyone says "I could have done that" whether they could or not, whether they did or not.

We try as much as we can, with our limited time, and limited resources to validate our decisions in a measurable way. Sometimes this isn't possible, sometimes things are immeasurable. Does this mean that we shouldn't do them? No, it does not.

The question was asked, why do we spend so much time on this when there are other pressing matters to attend to. The answer is simple, because of this process, this discourse where every decision is questioned, because a process that should take a month takes six. I honestly want to move on to tackle other problems, but if everything that my team or the product teams work on comes up for a vote, it questioned to this degree, nothing will happen, nothing will improve.

I'm tired of fighting over this, I'd like to move on, and moving on does not mean going on to the status quo.

*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation

M : +1 415 609 4043 | : @JaredZimmerman< https://twitter.com/JaredZimmerman%3E

On Tue, Apr 8, 2014 at 8:10 AM, Isarra Yos zhorishna@gmail.com wrote:

...

On 08/04/14 06:57, S Page wrote:

...

In https://gerrit.wikimedia.org/r/#/c/124475/ (go back to sans-serif) Legoktm claims "There was a consensus that listing only non-free fonts

was

...

...

not acceptable", that's not my recollection. Was a bug ever filed?

Kaldari valiantly tried to put non-free fonts first, that caused bug 63512. Now as I understand it, we're back to:

• Mac users get Helvetica Neue
• Windows users get Arial unless they have Helvetica Neue (unlikely) or

Helvetica (I can't reproduce bug 63662)

• Linux users get whatever F/OSS font fontconfig supplies for the

well-known string "Helvetica", I get Nimbus Sans L

• Android users ?? (Nobody responded.)

Linux often gets arial. Anyone with wine will probably have it installed, too, and most will have wine even if they don't use it. It's not necessarily a particularly good copy, either.

quoting Isarra Yos

...

Given that no objective and verifiable issues with this were ever

...

provided ... Why? All this effort, and for what?

BECAUSE DESIGN. (I begged and pleaded with the talented designers who

work next to me to put something emphatic in the Typography refresh FAQ.)

It's

...

...

a better design. It makes MediaWiki web sites look better for millions of our users by mentioning proprietary fonts that 90+% of them have. That's not "objective and verifiable", it just is. Is it worth mentioning non-free fonts? People disagree. But I'm saddened by the implicit and overt hostility towards the art of design here ("its debatable whether this actually represents "progress"", "it seems like things have shifted more to managers at WMF make the decisions", etc.).

Saying something is 'better' doesn't make it so. There are real reasons behind why anything is better than something else, or it would not be better. Even art in general is not purely subjective; if it were, we wouldn't hire artists and designers at all because it would be just as subjective to them and everyone would have different views and it'd just

be

...

hopeless.

Good design is good because it plays to the way our brains work. Even without a background in neuroscience, artists and designers learn over

time

...

what works and why, and they often take classes to enumerate the concepts as well. These are concepts they should be referring to here, things

about

...

the composition, the contrast, the use of space, the interplay between

the

...

colours. You can't just say this painting did this 'because design' and expect anyone to take you seriously. You can, however, say that the added negative space helps to emphasise the subject, drawing attention away

from

...

that place in the background where someone punched a hole through the canvas. They may still not take you seriously because then they know you punched a hole in the canvas, but it's a real, understandable reason.

But there's more that needs to go into something like this beyond just

the

...

general principles of design - this isn't a painting, but a thing that people use. So what of the users themselves? What of the languages that

it

...

will be in, the disabilities that need to be accommodated, the hardware

on

...

which it will be displayed, the software that will be rendering it to the end user, and the principles we uphold? How is it better in these

respects,

...

and for these?

'Just is' doesn't fly. There is so much more to design than that, and to suggest otherwise discredits those who make it their passion.

-I

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On 08-04-2014 19:29, Jared Zimmerman wrote:

I don't really have the energy to keep having this conversation, I appreciate that everyone has taken the time to weigh in on this whatever you opinion is on the matter.

I am sorry you feel that way. But I have to make one thing clear:

This is not an aestethic issue. This is a *technical* one.

I do appriciate all the work the designers have done and I do believe the new typography is in essense very well thought out.

However, its *technical* implementation is severy flawed.

It has caused many non-latin projects to force them to override the global font stack in their local CSS to reset it to sans-serif, because parts of their site have become unreadable or illegible. That makes this a *breaking change*, and as such, *must* be reverted.

I do not accept that there will be a "few" readers left with issues; our primary goal is legibility. And if legibility is damaged on a world-wide encyclopedia, how can you even *think* about defending a breaking change?

Regards,

On Apr 8, 2014 12:10 PM, "Isarra Yos" zhorishna@gmail.com wrote:

On 08/04/14 06:57, S Page wrote:

...

In https://gerrit.wikimedia.org/r/#/c/124475/ (go back to sans-serif) Legoktm claims "There was a consensus that listing only non-free fonts

was

...

not acceptable", that's not my recollection. Was a bug ever filed?

Kaldari valiantly tried to put non-free fonts first, that caused bug 63512. Now as I understand it, we're back to:

• Mac users get Helvetica Neue
• Windows users get Arial unless they have Helvetica Neue (unlikely) or

Helvetica (I can't reproduce bug 63662)

• Linux users get whatever F/OSS font fontconfig supplies for the

well-known string "Helvetica", I get Nimbus Sans L

• Android users ?? (Nobody responded.)

Linux often gets arial. Anyone with wine will probably have it installed,

too, and most will have wine even if they don't use it. It's not necessarily a particularly good copy, either.

I have wine. However firefox on my linux seems to think Nimbus sans is a good match for helvetica and displays that. Arial would look much better.

(This is just an aside, if it was only me having font issues, i would suck it up and get over it. Im concerned with the larger context)

--bawolff

Just a note that Brandon just commented on the patchset:

"We discussed this patch today during our weekly design team meeting and how to move forward. At this point in time we are leaning towards +2'ing this but we want to have a bit of discussion internally before doing so.

We'll have something at the end of the day, so we're asking that no one merge it until then."

I think that's a completely reasonable request.

Thanks to everyone who's been speaking up in support of positive changes to our typography while also being constructive and critical as appropriate. I think one of the cool things about Wikimedia is that we're willing to try and experiment even at the risk of causing breakage and disruption, but the flip side of that is listening to each other and optimizing things together towards the right outcome. We've got tons of smart people around the world helping with this, which is awesome. As always, I have confidence in our collective ability to figure things out :)

Erik

On Tue, Apr 8, 2014 at 12:33 PM, Martijn Hoekstra <martijnhoekstra@gmail.com

wrote:

On Tue, Apr 8, 2014 at 8:13 PM, Erik Moeller erik@wikimedia.org wrote:

...

On Tue, Apr 8, 2014 at 10:59 AM, Martijn Hoekstra martijnhoekstra@gmail.com wrote:

...

So, the font stack changes with regards to the status quo now change nothing for Windows users, changes Helvetica -> Helvetica neue for Mac users and changes Arial, DejaVu Sans or Arimo for possibly something

else,

...

amongst which Nimbus Sans L, maybe, maybe not.

Actually, it's a bit more complicated. All users get serif fonts for headings, which they didn't before and which is probably the biggest visual before/after difference. The serif fonts still prioritize free/libre fonts over non-free ones.

The body fonts prioritized free/libre fonts on deployments, but for Windows users without ClearType/anti-aliasing, those render very poorly, so they were disabled shortly after deployment. This is now causing people to be upset because the initial agreement to never prioritize non-free fonts is no longer maintained for the body.

Odder's patch would revert to sans-serif as a generic classification for the body, but doesn't touch the font specification for the headers (yet). The commit summary is a bit misleading in that regard.

Yes, I should have made that clear: I do very much support the Odder patch[1] ( https://gerrit.wikimedia.org/r/#/c/124475/ ) that reverts body to sans serif and keeps @content-heading-font-family: "Linux Libertine", Georgia, Times, serif;

That is not the status quo, but the diff between the Odder patch and the typography refresh basically is the "Set a non-free font stack to give Mac now Helvetica Neue rather than Helvetica", with a -2 is planted in the ground before as a demarcation line. That's the point that I don't think is worth having a non-free font-stack for, and that I certainly think standing your ground for the brave new world of typography refresh is constructive for.

This is a persistent myth floating around about this. Neue for Mac users is most definitely not the only effect of explicitly declaring the stack. As Jared, S Page, and others have already pointed out, and as is stated in the FAQ on mediawiki.org, the impact of the current stack is:

-- Linux users get Nimbus Sans L, instead of DejaVu Sans, Liberation Sans, or whatever else the default sans is on your distro. Nimbus has an improved x-height and is much more consistent with the other sans-serifs we're specifying. -- Windows users always get Arial, unless they have Helvetica installed. This means many of the Windows users who might otherwise have set an alternative sans in their browser default (like Verdana or Tahoma) will now always get Arial. -- And yes, Mac users or those with it installed get Neue Helvetica instead of older version. This is a minor but worthwhile improvement for Mac users. For example, Neue Helvetica actually has properly designed font weights for bold, italic, etc. so that the cap height and x-height are consistent between weights. Regular Helvetica was really not consistently designed across weights.

Declaring some of the system defaults explicitly is not only an improvement for Mac users. It means that regardless of whether you switch between devices/browsers, you always get a grotesque/neo-grotesque sans-serif ( https://en.wikipedia.org/wiki/Vox-ATypI_classification) which is ideal for reading long, large blocks of text and is more neutral.

[1]My only nitpick about it is that I'm wondering what Times is doing in that stack. I can't think of any situation where a user wouldn't have Linux Libertine or Georgia, but does have Times, yet doesn't have it as its default serif font. When one has specifically set a default serif different from Times, you probably have a good reason for it - or at least a better reason than the websites desire for Times, and we should respect that. Yet this beef is very small compared to all other issues in this thread.

Times, like setting Helvetica, is there because it's what Linux systems recognize and match to. Linux fc-match has no idea what Georgia and Linux Libertine are unless you've installed them. By setting Times, we ensure that Linux uses Nimbus Roman No9 L for headings, which complements the body typeface selected on Linux well and which is consistent in style with the other serifs specified.

A lot of this stuff is already documented in the FAQ on [[Typography refresh]] on mediawiki.org. We produced it to answer the basic questions just like this.

...

There's some additional discussion about Georgia as a font choice due to its use of text figures (AKA old-style numerals), which some people find look odd in headings with numbers, especially in non-Latin scripts where old-style numerals may not be commonly encountered. Due to this, some are arguing for also changing the style for headings to serif (_not_ sans-serif) as a generic classification, or removing Georgia from the stack. That particular issue hasn't been discussed in detail yet, as far as I can see.

I think the differences of opinion here are not worth a holy war. Prioritizing a non-free font before free ones for the _body_ with a clear FIXME indicating that this is not a desirable state is IMO only marginally different from reverting to sans-serif until we have a free/libre font that _can_ be prioritized for the body. So I think either outcome should be OK for the short term, and we should focus on the longer term question of a good font stack for the body that prioritizes free/libre fonts.

Let's not polarize each other too much. All the arguments I've heard have been fundamentally reasonable and rational, not just "Change is evil". Some people hate the serifs per se, but that's a smaller discussion compared to these conversations, which are about substantial things that can be reasoned about.

Erik

Erik Möller VP of Engineering and Product Development, Wikimedia Foundation

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Tue, Apr 8, 2014 at 10:20 PM, Steven Walling steven.walling@gmail.comwrote:

On Tue, Apr 8, 2014 at 12:33 PM, Martijn Hoekstra < martijnhoekstra@gmail.com

...

wrote:

...

On Tue, Apr 8, 2014 at 8:13 PM, Erik Moeller erik@wikimedia.org wrote:

...

On Tue, Apr 8, 2014 at 10:59 AM, Martijn Hoekstra martijnhoekstra@gmail.com wrote:

...

So, the font stack changes with regards to the status quo now change nothing for Windows users, changes Helvetica -> Helvetica neue for

Mac

...

...

...

users and changes Arial, DejaVu Sans or Arimo for possibly something

else,

...

amongst which Nimbus Sans L, maybe, maybe not.

Actually, it's a bit more complicated. All users get serif fonts for headings, which they didn't before and which is probably the biggest visual before/after difference. The serif fonts still prioritize free/libre fonts over non-free ones.

The body fonts prioritized free/libre fonts on deployments, but for Windows users without ClearType/anti-aliasing, those render very poorly, so they were disabled shortly after deployment. This is now causing people to be upset because the initial agreement to never prioritize non-free fonts is no longer maintained for the body.

Odder's patch would revert to sans-serif as a generic classification for the body, but doesn't touch the font specification for the headers (yet). The commit summary is a bit misleading in that regard.

Yes, I should have made that clear: I do very much support the Odder patch[1] ( https://gerrit.wikimedia.org/r/#/c/124475/ ) that reverts

body

...

to sans serif and keeps @content-heading-font-family: "Linux Libertine", Georgia, Times, serif;

That is not the status quo, but the diff between the Odder patch and the typography refresh basically is the "Set a non-free font stack to give

Mac

...

now Helvetica Neue rather than Helvetica", with a -2 is planted in the ground before as a demarcation line. That's the point that I don't think

is

...

worth having a non-free font-stack for, and that I certainly think

standing

...

your ground for the brave new world of typography refresh is constructive for.

This is a persistent myth floating around about this. Neue for Mac users is most definitely not the only effect of explicitly declaring the stack. As Jared, S Page, and others have already pointed out, and as is stated in the FAQ on mediawiki.org, the impact of the current stack is:

-- Linux users get Nimbus Sans L, instead of DejaVu Sans, Liberation Sans, or whatever else the default sans is on your distro. Nimbus has an improved x-height and is much more consistent with the other sans-serifs we're specifying.

Unfortunately, we didn't properly test this. With the large diversity in results of the tests we did do on https://www.mediawiki.org/wiki/Typography_refresh/Font_choice/Test I doubt it's a hard rule that Linux users will now universally get Nimbus Sans L. I'm also not sure that Nimbus Sans L is the superior alternative over Liberation Sans. I'm by no means an expert, but in the tests on https://www.mediawiki.org/wiki/Typography_refresh/Font_choice it scored exactly the same as Helvetica Neue (both in the good an the bad). Nimbis Sans L unfortunately hasn't been part of that test.

-- Windows users always get Arial, unless they have Helvetica installed.

This means many of the Windows users who might otherwise have set an alternative sans in their browser default (like Verdana or Tahoma) will now always get Arial.

Windows Helvetica seems to be generally a lie, and is not Helvetica but "Helvetica" (actually Arial). I don't see overriding a users preference with our preference as an advantage. Most people don't change their default font in their browser. In those cases it's probably good if we work with our preferences instead. If someone put in the effort to set a different preferred font probably did that for a reason that we shouldn't override. I assumed that we only wanted to override "unset" user preferences, and not actually override the settings that users have explicitly chosen. I was apparently mistaken in that.

-- And yes, Mac users or those with it installed get Neue Helvetica instead

of older version. This is a minor but worthwhile improvement for Mac users. For example, Neue Helvetica actually has properly designed font weights for bold, italic, etc. so that the cap height and x-height are consistent between weights. Regular Helvetica was really not consistently designed across weights.

Declaring some of the system defaults explicitly is not only an improvement for Mac users. It means that regardless of whether you switch between devices/browsers, you always get a grotesque/neo-grotesque sans-serif ( https://en.wikipedia.org/wiki/Vox-ATypI_classification) which is ideal for reading long, large blocks of text and is more neutral.

...

[1]My only nitpick about it is that I'm wondering what Times is doing in that stack. I can't think of any situation where a user wouldn't have

Linux

...

Libertine or Georgia, but does have Times, yet doesn't have it as its default serif font. When one has specifically set a default serif

different

...

from Times, you probably have a good reason for it - or at least a better reason than the websites desire for Times, and we should respect that.

Yet

...

this beef is very small compared to all other issues in this thread.

Times, like setting Helvetica, is there because it's what Linux systems recognize and match to. Linux fc-match has no idea what Georgia and Linux Libertine are unless you've installed them. By setting Times, we ensure that Linux uses Nimbus Roman No9 L for headings, which complements the body typeface selected on Linux well and which is consistent in style with the other serifs specified.

This comes down to the same thing I said under Windows. I was under the impression that not overriding the explicit choice of font a user has made is a good thing. That impression is apparently up for debate. But this isn't really a big deal to me.

A lot of this stuff is already documented in the FAQ on [[Typography refresh]] on mediawiki.org. We produced it to answer the basic questions just like this.

With the free fonts removed from the stack, unfortunately the FAQ doesn't

provide all the answers anymore. That's no criticism on the FAQ, after the quick turnover of events it's not surprising that it's not up to date anymore.

...

...

There's some additional discussion about Georgia as a font choice due to its use of text figures (AKA old-style numerals), which some people find look odd in headings with numbers, especially in non-Latin scripts where old-style numerals may not be commonly encountered. Due to this, some are arguing for also changing the style for headings to serif (_not_ sans-serif) as a generic classification, or removing Georgia from the stack. That particular issue hasn't been discussed in detail yet, as far as I can see.

I think the differences of opinion here are not worth a holy war. Prioritizing a non-free font before free ones for the _body_ with a clear FIXME indicating that this is not a desirable state is IMO only marginally different from reverting to sans-serif until we have a free/libre font that _can_ be prioritized for the body. So I think either outcome should be OK for the short term, and we should focus on the longer term question of a good font stack for the body that prioritizes free/libre fonts.

Let's not polarize each other too much. All the arguments I've heard have been fundamentally reasonable and rational, not just "Change is evil". Some people hate the serifs per se, but that's a smaller discussion compared to these conversations, which are about substantial things that can be reasoned about.

Erik

Erik Möller VP of Engineering and Product Development, Wikimedia Foundation

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On 2014-04-08, 12:33 PM, Martijn Hoekstra wrote:

That is not the status quo, but the diff between the Odder patch and the typography refresh basically is the "Set a non-free font stack to give Mac now Helvetica Neue rather than Helvetica", with a -2 is planted in the ground before as a demarcation line. That's the point that I don't think is worth having a non-free font-stack for, and that I certainly think standing your ground for the brave new world of typography refresh is constructive for.

Just to randomly chime in here, as someone using a Mac bought for my personal use by my employer awhile ago in my daily activities, I'd prefer that the difference between Helvetica and Helvetica Neue is not belittled.

Helvetica is an ancient font, created for print in 1957. Helvetica Neue was still only created in 1983 but its goal of being an improvement over Helvetica still carries over to the current computer fonts nonetheless. I can't fathom why Helvetica is still in use when a variant created specifically to be more legible than base Helvetica is now available – some would say any variant of Helvetica doesn't belong on the web[1], but Neue is still an improvement.

Flipping between Helvetica and Helvetica Neue by turning on and off a font-face: sans-serif; overriding the current `"Helvetica Neue", Helvetica, Arial, sans-serif` on en.wp's main page I can see a notable difference between the two.

Primarily in the kerning, Helvetica Neue's kerning is much better than Helvetica's, which simultaneously leaves extra space between letters when not needed and uses too little space between letters when it's necessary for legibility.

In general Neue has better kerning between letters, putting things closer together: - In "Main Page" it drops the unnecessary space inside Pa that Helvetica has. - In "Main page" in the sidebar it puts all letters closer together, dropping unnecessary space between ai and ag - In the content "All" drops unnecessary space between ll and "The" drops unnecessary space between Th - and so on

While in other cases Neue separates things that Helvetica puts together to it's detriment: cl, co, ct, te, all have extra space between them, while Helvetica puts them close together in ways that could be mistaken for other letters (d, oo, d, b).

[1] http://www.64notes.com/design/stop-helvetica-arial/

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]

On Tue, Apr 8, 2014 at 6:46 PM, Steven Walling steven.walling@gmail.comwrote:

On Tue, Apr 8, 2014 at 2:18 PM, Matthew Walker <mwalker@wikimedia.org

...

wrote:

...

Perhaps this is a question that has an answer elsewhere but, irrespective of if this change should be made to WMF wikis, why are we:

a) Making this a change in core?

and b) Not making the change in core be a SASS variable that can then be set as a preference somewhere? (I say this because we've consistently identified that some languages need different default fonts. If it was a preference in that we could set via our multiversion scripts it would obviate the need for overrides in common.css just to make things work.)

The patches (such as the first one at https://gerrit.wikimedia.org/r/#/c/120978/) are to the LESS variables that define Vector styles.

Fair enough.

So they're in core because Vector is in core. Based on conversations with Jon we should be able to work out how to do per-wiki or preferably per-language styles, right?

Ideally yes; not sure if we have support for that yet or not. I'll defer to Jon. :)

I've been sitting back watching this thread as it has unfolded, as well as the discussions in a few other places, to better understand how this particular subset of the Wikimedia/Mediawiki community problem-solved. I'd like to share with you all a few observations.

Steven and Jon, consider having coffee with your colleague Siko Bouterse. Siko can tell you all about how to fail successfully. Yes, I know it's an oxymoron, but there are huge opportunities in trying something, having it fail, and deriving goodwill, experience and knowledge from that failure. You've got an amazing opportunity here to learn from a well-intentioned process that has had significant unanticipated negative effects. As best I can tell, nobody doubts that this project was undertaken in good faith, and nobody doubts that you and your team are disappointed that its outcome is not what was anticipated.

There is a bit of amnesia about the fact that almost all editors are also readers and regular users of the projects we create, and those editors have been encouraged since Day One to inform developers of any technical problems with the site; they're the canaries in the coal mine. And for anyone who's been editing more than 3-4 years (an ever-increasing percentage of the editing community), "software" issues were things they had to pretty much solve themselves within the volunteer community. For years, most developers were volunteers too, and had close links to the editing community. At least a good portion of you remember those days - because you used to be those volunteer developers that community members would hit up to fix things, and you used to watch the village pumps to figure out what else needed to be fixed. Until very recently, it was almost unheard-of for community members to be told that problematic things were going to stay that way because of a decision made by a small number of people in an office somewhere. When most developers were clearly participating as community members, they behaved as though they were, at least to a significant extent, accountable to both the editing and Mediawiki communities; I'm not sure that sense of accountability exists anymore. Now, I don't think anyone begrudges the many talented developers who started off within the community having taken the opportunity to move on to paid positions at the WMF, and I think on the whole the big-picture community is overall very happy with the majority of changes that have come with the increased professionalization of the site engineering and operations. But this is a major change in culture, and the gulf between volunteers (either developer or editor) and WMF staff is widening noticeably as time progresses. I could tell who was a volunteer and who was staff from the way their posts were responded to in this thread; I doubt that would have been the case even two years ago.

It's pretty clear that the objectives of this project are not successfully met at this point, and in fact have caused major problems on non-Latin script WMF sites, and significant but less critical problems on Latin script sites. Several factors for this have been identified in the thread - including limited attention to the effects on non-Latin script projects, the insertion of philosophical principles (FOSS) without a clear understanding of the effects this would have on the outcome, and the unwillingness to step back when a major change results in loss of functionality.

Think a bit more. If this change is a cornerstone of future design changes, it needs to work on all WMF projects, and as currently structured you already know it can't. It may well be best to pull back to status quo ante in order to consider how to design not just for Latin-script sites, but for Chinese, Arabic and Vietnamese ones. Members of those communities may not be writing to this mailing list, but most of the non-Latin projects are growing much faster than the older, Latin-script sites. They're our future. They have to be in the mix.

Best,

Risker

On Apr 9, 2014 2:02 PM, "Steven Walling" steven.walling@gmail.com wrote:

On Tue, Apr 8, 2014 at 10:05 PM, Risker risker.wp@gmail.com wrote:

...

It's pretty clear that the objectives of this project are not

successfully

...

met at this point, and in fact have caused major problems on non-Latin script WMF sites, and significant but less critical problems on Latin script sites. Several factors for this have been identified in the

thread -

...

including limited attention to the effects on non-Latin script projects, the insertion of philosophical principles (FOSS) without a clear understanding of the effects this would have on the outcome, and the unwillingness to step back when a major change results in loss of functionality.

[citation needed]

Loss of functionality? The functionality we're talking about here is reading of Wikimedia content. It's the most core, most basic functionality we have. In the case of VisualEditor, which picks up read-mode typography styles, it's also editing.

Did reading suddenly become seriously impaired? No.

Yes, it was seriously impaired. On the scale of impairments possible with a font stack change, compared to how it was, this change was in the high end of the scale, next to broken.

I currently visit a lot of language pedias doing category linking on wikidata, and after the change I noticed many had obviously bad font issues that I didnt see the day before. Clicking random on a few wikis would have been enough testing to work that out.

Btw that was using Chrome on Fedora Core 19 without any local mods to font handling.

The functionality was previously fine. Maybe it could be improved, but that isnt what happened.

I agree with everything Risker said. I go further and suggest the team involved stops defending their goals and implementation. The former are not the issue, and the latter was indefensible. I havent looked at how much testing was done, or if there was some staging of the rollout, but it is clear that it wasnt careful enough.

-- John

On Wed, Apr 9, 2014 at 5:06 PM, David Gerard dgerard@gmail.com wrote:

On 9 April 2014 09:26, John Mark Vandenberg jayvdb@gmail.com wrote:

...

I havent looked at how much testing was done, or if there was some staging of the rollout, but it is clear that it wasnt careful enough.

To be fair, it's easy to say that in hindsight. But e.g. who knew so many people were running Windows with ClearType off, and that these fonts rendered so badly under it? I mean *now* we know to look at that specific thing :-)

Did you even read my email?

On 09/04/14 08:26, John Mark Vandenberg wrote:

I agree with everything Risker said. I go further and suggest the team involved stops defending their goals and implementation. The former are not the issue, and the latter was indefensible. I havent looked at how much testing was done, or if there was some staging of the rollout, but it is clear that it wasnt careful enough.

While I agree in general, I'm not even sure about that, that the goals weren't the issue - do we even know what the goals /were/, or the issues that they were trying to address? I've asked, and seen others ask, several times in multiple venues, and I've yet to see a real answer. The most anyone has been able to produce (usually Steven, I think, so I'll thank him for at least trying) have been things like that it looks better or it's more consistent, but that would be like a security person only saying their change makes things more secure, and explaining 'because security' in the commit message. Sure, it might be true, but it's completely useless if you're trying to work with it, or test it exhaustively. We need to know what the issue really was, too, or we can't possibly have any real discussion or collaboration. With security, it's communicated - we just saw that with announcements of the heartbleed exploit. Why isn't it with design?

So, yeah, the goals are probably noble enough, but we don't even know that for sure. There's a gulf here, and it's just getting worse.

-I

On Wed, Apr 9, 2014 at 1:05 AM, Risker risker.wp@gmail.com wrote: <snip>

There is a bit of amnesia about the fact that almost all editors are also readers and regular users of the projects we create, and those editors have been encouraged since Day One to inform developers of any technical problems with the site; they're the canaries in the coal mine. And for anyone who's been editing more than 3-4 years (an ever-increasing percentage of the editing community), "software" issues were things they had to pretty much solve themselves within the volunteer community. For years, most developers were volunteers too, and had close links to the editing community. At least a good portion of you remember those days - because you used to be those volunteer developers that community members would hit up to fix things, and you used to watch the village pumps to figure out what else needed to be fixed. Until very recently, it was almost unheard-of for community members to be told that problematic things were going to stay that way because of a decision made by a small number of people in an office somewhere. When most developers were clearly participating as community members, they behaved as though they were, at least to a significant extent, accountable to both the editing and Mediawiki communities; I'm not sure that sense of accountability exists anymore. Now, I don't think anyone begrudges the many talented developers who started off within the community having taken the opportunity to move on to paid positions at the WMF, and I think on the whole the big-picture community is overall very happy with the majority of changes that have come with the increased professionalization of the site engineering and operations. But this is a major change in culture, and the gulf between volunteers (either developer or editor) and WMF staff is widening noticeably as time progresses. I could tell who was a volunteer and who was staff from the way their posts were responded to in this thread; I doubt that would have been the case even two years ago.

<snip>

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Which gulf is growing more quickly - between the WMF staff and volunteers, or between the veteran editing population and the typical reader? I won't argue that there is some distance, and a degree of conflict, between the goals and priorities of the staff and many veteran volunteers. But this distance hasn't occurred organically. It's been introduced consciously, and mentioned on a number of occasions, by WMF leaders like Sue and Erik. They have often made the point that the WMF has to consider first the hundreds of millions of readers who compose our intended audience.

No one has said, that I've seen, that complaints and problems from the editing community should be ignored. But I think Steve and Jon are struggling with how to react to complaints without knowing how representative they are of the reader experience. If complaints are presented by a tiny percentage of the editing community, how many should they assume are encountering the problem but not reporting it? If readership numbers don't change, and people who login to complain are definitionally lumped into "editors", how do we assess the impact on readers and whether or not many readers are having difficulty?

These aren't easy questions to answer. Many people complaining about this change, and others, seem to make different automatic assumptions about relevance and impact than the WMF staff, or they don't consider it at all. To be fair to the engineering staff, we should keep in mind that they have to relate complaints from developers and editors to the experience of hundreds of millions of readers and make decisions principally (but not wholly) based on the latter, not the former.

Which gulf is growing more quickly - between the WMF staff and volunteers, or between the veteran editing population and the typical reader? I won't argue that there is some distance, and a degree of conflict, between the goals and priorities of the staff and many veteran volunteers. But this distance hasn't occurred organically. It's been introduced consciously, and mentioned on a number of occasions, by WMF leaders like Sue and Erik. They have often made the point that the WMF has to consider first the hundreds of millions of readers who compose our intended audience.

No one has said, that I've seen, that complaints and problems from the editing community should be ignored. But I think Steve and Jon are struggling with how to react to complaints without knowing how representative they are of the reader experience. If complaints are presented by a tiny percentage of the editing community, how many should they assume are encountering the problem but not reporting it? If readership numbers don't change, and people who login to complain are definitionally lumped into "editors", how do we assess the impact on readers and whether or not many readers are having difficulty?

These aren't easy questions to answer. Many people complaining about this change, and others, seem to make different automatic assumptions about relevance and impact than the WMF staff, or they don't consider it at all. To be fair to the engineering staff, we should keep in mind that they have to relate complaints from developers and editors to the experience of hundreds of millions of readers and make decisions principally (but not wholly) based on the latter, not the former. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

To be honest, I'm kind of tired of hearing, "won't anyone think of the readers" as an excuse to do pretty much anything. Most of the time (not all the time) I've seen that excuse be used, there isn't any evidence about how the change actually affects the readers except for the authors' own conjecture (Or if they do have evidence, they largely aren't communicating it very well). Readers generally don't complain when something changes for the worse, unless it really changes for the worse (e.g. Site going down). Even if the readers did complain in the same way our users do, taking a lack of complaints to mean something is a positive improvement, seems like a recipe for confirmation bias.

That said, we shouldn't be afraid of making changes where we reasonably think they might be a good idea, even without evidence they actually are. You can't have data on everything. I just don't like "Well we are undoubtedly making things better for the reader" used as a counter argument to criticism when we simply don't know what it will do for the average reader.

--bawolff

On Wed, Apr 9, 2014 at 9:33 AM, David Gerard dgerard@gmail.com wrote:

On 9 April 2014 17:30, Brian Wolff bawolff@gmail.com wrote:

...

That said, we shouldn't be afraid of making changes where we reasonably think they might be a good idea, even without evidence they actually are. You can't have data on everything. I just don't like "Well we are undoubtedly making things better for the reader" used as a counter argument to criticism when we simply don't know what it will do for the average reader.

Yes, it is the sort of statement that probably should not be used without being followed by a link to actual UI testing results.

I should follow up on this and say that no one working on the Beta Feature thinks it's a good idea to try and design typography that only works for people who aren't logged in/don't edit. The design goals listed at http://blog.wikimedia.org/2014/03/27/typography-refresh/ and https://www.mediawiki.org/wiki/Typography_refresh#Summary_of_changes are pretty universal to all users, as they should be.

I don't really think that when it comes to typography, either type of visitor to Wikimedia sites is more or less important when it comes to listening to feedback. Even if Nathan was right, sometimes it's hard for us to balance the two. What I said in reply to Risker is that I don't think there saying the change is a failure is fair or true, based on the level and kind of feedback we've been getting from both readers *and* editors.

On 9 April 2014 19:36, Risker risker.wp@gmail.com wrote:

And has any testing been done with screen readers and dyslexia readers to test #4? I've not seen any reports of that. We do have some regular users of screen readers who would probably have been right there letting you know if there was a conflict. I have some anecdotal info that it does not interact well with at least one dyslexia reader, but no further details, and the user wouldn't provide me with a screenshot that I could share. Nonetheless, the evidence is lacking that this was tested for; if it's a principle goal, this needs to be done.

Just wondering - are the user testing results up anywhere?

(And btw, is there any way user testing can be distributed, so interested parties can participate? That might save a lot of later angst and catch edge cases. I realise I may just have said "simple matter of programming.")

- d.

Hoi, Given that you do have statistics, how did all the huha around the ULS "performance issue" and now all this hit the use of the functionality for dyslexic people?

We know that it helps but how do we help people with dyslexia? They are "only" 7 to 10% of a population.. I have not done the arithmetic but would that be more than 7 to 10% of all our readers? (what is the breakdown in fonts for our total public) Thanks, GerardM

On 10 April 2014 02:45, Brian Wolff bawolff@gmail.com wrote:

...

And has any testing been done with screen readers and dyslexia readers to

I would be extremely surprised if this interacted negatively with screen readers. Screen readers normally dont even look at the font choice.

--bawolff _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

My sentiment here is that all of this has supported every latent opinion that I had about the project when it was started. Years of maintaining templates, CSS and Javascript on English Wikipedia had taught me not to mess with fonts unless it was very targeted (preferring a specific font for a language fragment or class). It also taught me that anything like this is factors worse on non-English wiki's. I think Erwin was sharing those concerns (probably more vocal than me) for the exact same reason. We might not have been able to show the evidence beforehand in a nicely written document, but we knew this was a very risqué operation. The beta testing had sort of subdued my concerns a bit, but that turned out to be a false sense of security.

With all the good that has happened on the web over the past 10 years, there are simply a few areas that are hopelessly stuck in that past, and those are mostly the areas that are very much bound to (or used to be bound to) OS functionality. These include for instance: Audio/Video, accessibility support and fonts !!!

There are very good reasons for why all these areas are in such a bad shape, history, long support cycles, patents etc. Every time we have tried to make changes in these areas, we seem to underestimate: 1. just how far in the past many of the browser+OS configurations are 2. how much worse 3rd party software can make the situation 3. how inadequate the existing Free/Open alternatives are (especially with regard to global scope/big audiences/high performance) 4. how 'religious' our community is with regard to it's Free/Open foundations.

So for me, the question is not how can we apply pretty serif fonts to headers, the question is what can we do short term and long term to make that happen. Short term: * Accept that the current solution is not working * Rely on Operating System to make the best choice it can, because we cannot do better (return to status quo) * Accept that maybe it might just not be possible right now * Gather statistics on cleartype font rendering (just like we look at tofu). * See if there are ways to make the target group to which the font change is applied narrower/stricter/better defined.

Longer term: * Work with font communities to build true usable, enjoyable Free fonts with global reach. * Work with web/browser development communities to make web fonts more efficient * Work with OS vendors to make sure they are committed to fixing problems in/with fonts, delivering open fonts

It seems to me that those are the areas where we should focus our attention, simply because that will allow us to get to nicely designed pages, without running into those problems mentioned above.

DJ

On Tue, Apr 8, 2014 at 8:14 PM, Erwin Dokter erwin@darcoury.nl wrote:

On 08-04-2014 19:29, Jared Zimmerman wrote:

...

I don't really have the energy to keep having this conversation, I appreciate that everyone has taken the time to weigh in on this whatever you opinion is on the matter.

I am sorry you feel that way. But I have to make one thing clear:

This is not an aestethic issue. This is a *technical* one.

I do appriciate all the work the designers have done and I do believe the new typography is in essense very well thought out.

However, its *technical* implementation is severy flawed.

It has caused many non-latin projects to force them to override the global font stack in their local CSS to reset it to sans-serif, because parts of their site have become unreadable or illegible. That makes this a *breaking change*, and as such, *must* be reverted.

I do not accept that there will be a "few" readers left with issues; our primary goal is legibility. And if legibility is damaged on a world-wide encyclopedia, how can you even *think* about defending a breaking change?

Regards,

Erwin Dokter

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Thu, Apr 10, 2014 at 9:54 AM, Erik Moeller erik@wikimedia.org wrote:

(snip)

My understanding is that there are three separate major issues:

• serif may not be a good choice for certain languages

• The explicitly specified sans-serif stack needs to be further

optimized

• some people feel that either reverting to the previous state would be preferable. The

Are those the main issues? Am I misrepresenting anything or forgetting something / additional major issues?

The analysis of these points looks accurate. We could add:

* A MediaWiki Core change vs a Wikimedia specific configuration.

On Wed, Apr 9, 2014 at 9:44 PM, Gerard Meijssen gerard.meijssen@gmail.comwrote:

Given that you do have statistics, how did all the huha around the ULS "performance issue" and now all this hit the use of the functionality for dyslexic people?

I'm not sure what statistics you're referring to.

We know that it helps but how do we help people with dyslexia? They are "only" 7 to 10% of a population.. I have not done the arithmetic but would that be more than 7 to 10% of all our readers? (what is the breakdown in fonts for our total public)

In the FAQ (https://www.mediawiki.org/wiki/Typography_refresh#FAQ) we specifically mentioned enhancing the view for dyslexic users as one of the reasons why the body font color was changed. To go in to more detail about other aspects... dyslexic users is one of the reasons why we did not suggest we switch to a serif for body text along with the headers. As far as I understand, it's also a reason to not specify a more humanist-style sans-serif like Open Sans, Verdana, or DejaVu where the letterforms have more calligraphic characteristics compared to a Grotesk-style sans like Arial, Helvetica, and Nimbus.

Of course there is also the question about whether to deliver Open Dyslexic as a webfont option via ULS. I don't know why it was removed and how that decision was made, so I can't comment on it.

Steven

On 10 April 2014 22:16, Quim Gil qgil@wikimedia.org wrote:

Our 3rd party MediaWiki users (the sysadmins and their users) should not be affected by the unstable situation around font styles. If we are going to change their defaults, we should better do it when we are certain about the reliability of the changes. If this certainty comes soon enough to make it to 1.23.0, good. Otherwise, can we plan for an alternative?

*hand up* Speaking as one user, I'd be fine with the previous situation, or with just sans-serif for the body, if we don't have an excellent answer by then.

- d.

Erik Moeller wrote:

On Thu, Apr 10, 2014 at 7:39 AM, Derk-Jan Hartman d.j.hartman+wmf_ml@gmail.com wrote:

...

So for me, the question is not how can we apply pretty serif fonts to headers, the question is what can we do short term and long term to make that happen.

It would be good if we could focus the conversation as much on concrete bugs and issues as possible.

You mean something like this?

Derk-Jan Hartman wrote:

Short term:

• Accept that the current solution is not working
• Rely on Operating System to make the best choice it can, because we

cannot do better (return to status quo)

• Accept that maybe it might just not be possible right now
• Gather statistics on cleartype font rendering (just like we look at

tofu).

• See if there are ways to make the target group to which the font

change is applied narrower/stricter/better defined.

Longer term:

• Work with font communities to build true usable, enjoyable Free

fonts with global reach.

• Work with web/browser development communities to make web fonts

more efficient

• Work with OS vendors to make sure they are committed to fixing

problems in/with fonts, delivering open fonts

I agree with all of this. Both Erik's and Derk-Jan's posts are very good, but I get the feeling that people are talking past each other in this thread sometimes.

As Quim notes, there's an upcoming MediaWiki release. We should merge https://gerrit.wikimedia.org/r/124475 into master and figure out what to do with the other font-family adjustments for the short-term.

There seems to be demonstrable consensus for merging Gerrit change 124475 into master, though Steven refuses to remove his -2, which he should never have been able to set. If you (Erik) are truly interested in focusing the conversation on concrete bugs and issues, that's where I would start.

MZMcBride

On Thursday, April 10, 2014, MZMcBride z@mzmcbride.com wrote:

Erik Moeller wrote:

...

On Thu, Apr 10, 2014 at 7:39 AM, Derk-Jan Hartman d.j.hartman+wmf_ml@gmail.com wrote:

...

So for me, the question is not how can we apply pretty serif fonts to headers, the question is what can we do short term and long term to make that happen.

It would be good if we could focus the conversation as much on concrete bugs and issues as possible.

You mean something like this?

Derk-Jan Hartman wrote:

...

Short term:

• Accept that the current solution is not working
• Rely on Operating System to make the best choice it can, because we

cannot do better (return to status quo)

• Accept that maybe it might just not be possible right now
• Gather statistics on cleartype font rendering (just like we look at

tofu).

• See if there are ways to make the target group to which the font

change is applied narrower/stricter/better defined.

How are these specific, replicable bugs? DJ is saying things the current solution is "not working" and we "cannot do better" but there is no evidence about why this is the case for such a large number of users that it requires a revert back to plain sans-serif.

People are talking in generalities and about problems related to areas like non-Latin script support, but not referring to bugs filed and which would be fixed by the suggested patch. Brian's recent comment here is an example of what we are asking to hear, though I don't think that requires a full revert.

Meanwhile, in this thread and in the documentation on mediawiki.org, we have been extremely specific about how each aspect of the new typography (including the body fonts specified) is a pragmatic improvement for users, and what we lose by reverting. I also posted links to that effect on the patch.

The patch as it stands does not refer to an unresolved bug or enhancement. It also explicitly refers to the issue as an ideological one about potentially promoting non-free fonts in our code, even though Jon already out a FIXME acknowledging this.

Unless you can raise issues that cause actual functional problems that outweigh the benefits of the new body font stack, I don't think merging that patch is required to improve things and is worth the churn in user experience for millions of readers.

Steven

I agree with all of this. Both Erik's and Derk-Jan's posts are very good, but I get the feeling that people are talking past each other in this thread sometimes.

As Quim notes, there's an upcoming MediaWiki release. We should merge https://gerrit.wikimedia.org/r/124475 into master and figure out what to do with the other font-family adjustments for the short-term.

There seems to be demonstrable consensus for merging Gerrit change 124475 into master, though Steven refuses to remove his -2, which he should never have been able to set. If you (Erik) are truly interested in focusing the conversation on concrete bugs and issues, that's where I would start.

MZMcBride

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Fri, Apr 11, 2014 at 6:26 AM, Brian Wolff bawolff@gmail.com wrote:

.. By "lower quality" I mean both subjectively, but also objectively. For example, today I was reading https://en.wikinews.org/wiki/Hamilton_wins_%27incredible%27_Bahrain_race,_F1... (enwikinews is one of the few wikis I haven't overridden the font changes with css). At first I thought there was a typo in the image caption toward the end of the page, an extra space between "prote" and "stor". But no, the kerning on the font chosen is just literally that bad, that you can't tell if it is an extra space, or just a kerning error. I call that objectively bad (There's other things I don't like about the font choice, but they are more touchy-feely subjective)

I can reproduce this. It looks _very_ bad on Firefox/Fedora Core 19, and but it also appears to a lesser degree on Chrome/Fedora Core 19.

Compare it against monobook

https://en.wikinews.org/wiki/Hamilton_wins_%27incredible%27_Bahrain_race,_F1...

See also the "ама" in the bold title in the first sentence of

https://ru.wikipedia.org/wiki/?oldid=58319520

vs

https://ru.wikipedia.org/wiki/?oldid=58319520&useskin=monobook

On 11-04-2014 04:35, Steven Walling wrote:

How are these specific, replicable bugs? DJ is saying things the current solution is "not working" and we "cannot do better" but there is no evidence about why this is the case for such a large number of users that it requires a revert back to plain sans-serif.

People are talking in generalities and about problems related to areas like non-Latin script support, but not referring to bugs filed and which would be fixed by the suggested patch. Brian's recent comment here is an example of what we are asking to hear, though I don't think that requires a full revert.

[1] shows half the world complaining about the typography refresh.

I'm sorry, but this is beginning to be like VE all over again; all I see now coming out of the foundation is a big, unpenetrable progaganda machine with a broken record: "There is no problem! This is a good change! There are no bugs!"

Steven, it has been sufficiently demonstrated that the single, global font stack is technically flawed and must be reverted. With all due respect to the design team, they are *not* engineers and may not be aware of the problems as they have emerged.

I will explain one more time: free/non-free fonts are not the issue, MediaWiki is now forcing a Latin font stack that does not work in non-Latin installations. This does not only affect current Mediawiki wikis but will also affect new non-Latin MW 1.23 installations; they all had/have to fix this one way or another, usually by resetting the font stack.

We must focus on a system that delivers a font stack on a per-language basis. But that cannot happen as long as the global font stack is in place.

Unless you can raise issues that cause actual functional problems that outweigh the benefits of the new body font stack, I don't think merging that patch is required to improve things and is worth the churn in user experience for millions of readers.

*ANY* functional problem outweighs the purported benefits. That is because actual functional problems should never be weighed; they should be fixed on sight.

Please Steven, and the foundation in general, PLEASE step of the propaganda wagon and do the responsible thing; remove the font stacks so that we can focus on a *real* solution that actually *does* benefit the entire world.

I am really, really affraid that refusing to +2 this patch is going to affect future attempts to fix this on a per-language basis.

Regards,

On 11-04-2014 13:11, Erwin Dokter wrote:

[1] shows half the world complaining about the typography refresh.

I forgot to include the URL:

[1] https://www.mediawiki.org/wiki/Talk:Typography_refresh#Languages_problems

Regards,

On 11-04-2014 18:42, Jon Robson wrote:

I keep hearing about ALLL THE BUGS but I've not seen anything on Bugzilla.

That's because you don't *want* to see... Most of the reports on [1] are from readers who don't know anything about Bugzilla. That doesn't make that anything less valid.

Since that page was linked as the primary feedback page when the refresh was announced, it should be the first place to check for error reports. Claiming non-existence of Bugzilla reports is just plain selective ignorance.

There is also a tracking bug [2] with plenty bugs attached, among the [3], [4] and [5]; *all* language related. Buth the bug reports and Typography talk page have plenty of screenshots.

[1] https://www.mediawiki.org/wiki/Talk:Typography_refresh#Languages_problems [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=63549 [3] https://bugzilla.wikimedia.org/show_bug.cgi?id=63720 [4] https://bugzilla.wikimedia.org/show_bug.cgi?id=63718 [5] https://bugzilla.wikimedia.org/show_bug.cgi?id=63817

Regards,

That's because you don't *want* to see... Most of the reports on [1] are from readers who don't know anything about Bugzilla. That doesn't make that anything less valid.

Please don't accuse me of things that are not true. I do want to see these things, but I have to manage 1) mailing lists 2) bugzilla 3) wiki pages (which i have to know exist). I am only human. Thanks for the links to bugs I've cc'ed myself on all of these.

The problem with https://www.mediawiki.org/wiki/Talk:Typography_refresh#Languages_problems is that they are easy to get lost. If you want the full attention of a developer they need to go into Bugzilla. Recording bugs, sometimes on behalf of these users can help give them more attention, especially on a huge wiki discussion page like this where this sort of thing gets buried. I opened a bug for this one: https://bugzilla.wikimedia.org/show_bug.cgi?id=63827

Since that page was linked as the primary feedback page when the refresh was announced, it should be the first place to check for error reports. Claiming non-existence of Bugzilla reports is just plain selective ignorance.

I disagree. Bugzilla is where we report bugs. If no one raises bugs as they will go lost.

On Fri, Apr 11, 2014 at 11:17 AM, Brian Cox nativeforeignerwiki@gmail.comwrote:

Perhaps all the user reported bugs should be added to Bugzilla for tracking purposes. But it's not reasonable to expect the average user to report them there.

Brian/NF

Yes I think we definitely need to track things in Bugzilla, but you're right Brian. The average reader especially is not going to be able to figure out bug filing.

Nemo, Jared, and others have been trying to migrate bugs there or ask people to do so where they can. Nemo in particular deserves thanks for trying to spend some time helping us wrangle Bugzilla for typography refresh. :) Once things are tracked there and we can replicate them, we'll do our best to fix issues that are widely applicable.

On Fri, 2014-04-11 at 09:42 -0700, Jon Robson wrote:

I keep hearing about ALLL THE BUGS but I've not seen anything on Bugzilla.

https://bugzilla.wikimedia.org/show_bug.cgi?id=63549 dependency list plus likely stuff on https://www.mediawiki.org/wiki/Talk:Typography_refresh that I'd expect the developers to read and convert into bug reports, when necessary.

andre

On 11-04-2014 20:00, Jon Robson wrote:

Please don't accuse me of things that are not true. I do want to see these things, but I have to manage 1) mailing lists 2) bugzilla 3) wiki pages (which i have to know exist). I am only human. Thanks for the links to bugs I've cc'ed myself on all of these.

That was not my intention, I'm sorry. But I am getting so frustrated because the foundation keeps giving the impression that it does not even acknowledge that there is a problem, or at least refuses to remedy it by clinging on the currently broken implementaion.

...

Since that page was linked as the primary feedback page when the refresh was announced, it should be the first place to check for error reports. Claiming non-existence of Bugzilla reports is just plain selective ignorance.

I disagree. Bugzilla is where we report bugs. If no one raises bugs as they will go lost.

Then that should have been in the FAQ. The announcement only sends the readers to the talk page to give feedback.

Regards,

On 11/04/14 18:42, Bartosz Dziewoński wrote:

I have merged the Gerrit change (https://gerrit.wikimedia.org/r/#/c/124475/), restoring the body font to "sans-serif". The heading font is unchanged for now.

I've read the entire wikitech-l thread (89 emails as of writing) and pondered this carefully. My summary of the situation is:

• This font stack, according to WMF Design, only provides real improvements for Macs (~6% of Wikimedia sites visitors per

http://stats.wikimedia.org/wikimedia/squids/SquidReportOperatingSystems.htm) and should be (nearly) identical to defaults for other systems. However, it causes major rendering issues for an unspecified number of Windows and Linux users (especially with, respectively, Helvetica and Nimbus Sans L; see both open and closed dependencies of bug 63549).

• This font stack also apparently causes issues with non-Latin-script languages (not very well-specified ones, though; more bug reports like bug 63817 would be welcome); it's serious enough for at least one affected Wikimedia wiki (the Japanese Wikipedia) to have already reset the stack to "sans-serif". This might affect the serif heading fonts more than the sans-serif body fonts (again, more precise reports needed).
• The wikitech-l discussion, as well as various on-wiki discussions (e.g. on WP:VPT on the English Wikipedia) have been overwhelmingly in favor of restoring the plain "sans-serif" font definition.
• Orthogonally to these issues, all other aspects of the typography refresh have been generally considered successful and minor problems with them have been quickly fixed.

Other issues with it have largely been drowned out, or were never brought up here due to the scope of the discussion (things like contrast issues causing eyestrain, for instance, are distinct from foss ideology, fonts or windows). Depending on what they are, they may or may not be relatively minor; without going into them it's hard to say. I'd suggest starting a new thread for that, though.

In conclusion we should all make waffles.

-L