On Sun, Feb 16, 2014 at 1:16 AM, David Gerard <dgerard(a)gmail.com> wrote: Language Selector has been disabled on 21-01-2014 to work out some performance issues that had affected the Wikimedia sites." To my understanding part of the major performance issues here related to issues like loading the Autonym font via webfonts. I probably should not have brought up ULS because feelings are still raw about it and I'm not interested in rehashing its problems, but my point is that it's an example of how delivering webfonts is not a trivial thing for us. No one has offered to spend time on a highly performant webfonts system that can deliver better typography reliably to all Wikimedia sites, and we're certainly not going to officially task a team to do so when there's a reasonable alternative that thousands of users are trying out right now in beta mode. The beta feature has involved lots of testing in non-Latin scripts. It's not perfect yet but we certainly haven't ignored scripts that represent so many users. (Remember we're not talking about something actually that new. A very similar font stack has been in use for 100% of mobile users for more than a year.) Steven P.S. Sorry for answering from a different account. My work address is not subscribed to Wikitech.

On 16 February 2014 18:54, Gerard Meijssen <gerard.meijssen(a)gmail.com>wrote;wrote: TBH we probably lost most of that when everything was rolled into one gigantic extensions, instead of separate tools that specialised in what they were designed for.

On Mon, Feb 17, 2014 at 12:38 PM, Steven Walling <steven.walling(a)gmail.com>wrote;wrote: I need to challenge the assertion that this is about most users. Here's my understanding of the status quo: for prose, we currently specify the neutral and non-descript "sans-serif". This results in the following fonts on the default install on these platforms if I've done my homework correctly: * MS Windows: Arial(?) * Mac: Helvetica * Ubuntu/Firefox: DejaVu Sans (presumably other Linux variants are similar) * Ubuntu/Chrome: Liberation Sans * Android: Roboto * iOS: Helvetica(?) Note that the differences between Firefox and Chrome on Linux seem to stem from Firefox using the OS standard font resolution mechanism, and Chrome having a built-in heuristic that seems to be very heavily biased toward Liberation Sans. Under the new "Helvetica Neue", Helvetica, Arial, sans-serif font stack, we get: * MS Windows: Arial(?) * Mac: Helvetica Neue * Ubuntu/Firefox: Nimbus Sans L (Helvetica substitute) * Ubuntu/Chrome: Liberation Sans (Helvetica and Arial substitute) * Android: Roboto * iOS: Helvetica Neue This doesn't seem like a satisfying leap forward, given the level of disruption. * By our numbers[1], a plurality of our users are using MS Windows still (and probably a majority of those using the desktop site). They got Arial before, and they get Arial now.[2] The only way they improve their experience is to buy Helvetica Neue or buy a product that includes Helvetica Neue. Moreover, it's quite possible that MS Windows users will get a crappy experience with Helvetica if they have an old Type 1 version of it installed on their system.[3] * It looks like this causes shift from Helvetica and Helvetica Neue on Mac and iOS, which would seem to be to be pretty subtle. How big is the difference on the site? I don't have access to a Mac at home, so I can't see the difference myself, but the available screenshots don't present a noticeable difference to me. * If cross-platform consistency is the goal, I think this misses the mark. In particular, Android would still be using Roboto, which has quite different metrics than the Helvetica/Arial set of fonts. Additionally, we still end up with a difference between our two most popular Linux browsers, which while not as large as before, still seems unnecessary. Here is what seems to be a reasonably well-researched article where the author has clearly put a lot of thought into the cross-platform experience, with the added bonus that it proposes use of free (libre) fonts: http://www.grputland.com/2013/11/multiplatform-helvetica-like-font-stack.ht… tl;dr: His stack still lists HelveticaNeue as the first font, but proposes Arimo as a web font which may well look better on MS Windows. Arimo ships with ChromeOS. I believe it is worth more research on replacements for free and better alternatives to Arial, because it would seem to me that it's not hard to do better. While it's unlikely that most MS Windows users will install Arimo, it sends a way better message if we can say "to make your Wikipedia reading experience better, download and install the free font Arimo" than it does to say "to make your Wikipedia experience better, please purchase Helvetica Neue for the low low price of $29.95". Furthermore, it may be worth it to try out the web font mechanism, and we might even be able to talk Mozilla and/or Google into shipping a free font or two with the browser so as to get some real install penetration with these fonts. In general, it feels as though this iteration is centered around only making the experience for Apple products better, while trying not to break the experience on other platforms, which feels like a low bar. It's not entirely clear how much hands-on effort the User Experience team has put into Windows, Android tablets, ChromeOS, or other Linux desktops, or what the team's goals are for those platforms. The fact that much of the rationale for the new design centers around greater use of Helvetica Neue specifically (which is not free, and is only available to a minority of our users) is annoying to me, and that seems to be where a lot of the frustration from others comes from as well. Rob [1] http://stats.wikimedia.org/wikimedia/squids/SquidReportOperatingSystems.htm [2] I don't have a modern system with Windows 7 or 8 on it, so I don't know if they've switched to Segoe as the default. If so, we may be making an unintentional downgrade to Arial with our new choice. [3] http://stackoverflow.com/questions/15011653/internet-explorer-automatically…

On Mon, Feb 17, 2014 at 4:58 PM, Erik Moeller <erik(a)wikimedia.org> wrote: We basically tried the equivalent of this (placing relatively free fonts unknown on most platforms first) which Kaldari talked about previously. Ultimately that kind of declaration is useless for the vast majority of users and we got very specific negative feedback about it on the Talk page. These fonts are ignored by most systems when placed first or when placed later in the stack. Systems match the first font they recognize, so using something they don't recognize or putting it later is a largely just feel-good measure. The whole Arimo/Arial conundrum is largely a matter of the fact that Windows users simply do not have a Helvetica-like font available on most versions which is better than Arial, warts and all. Again, the best solution is to deliver a webfont, which most people with good design sense are doing these days, and we can't yet. -- Steven Walling, Product Manager https://wikimediafoundation.org/

On Tue, Feb 18, 2014 at 4:19 AM, Steven Walling <swalling(a)wikimedia.org>wrote;wrote: would you be so kind to invest a little of your precious time and make this story easy to read/digest for the many people on this list? you might add verifiable links of what you say and explain in a manner somebody normally technically gifted can follow why "we" cannot (webfonts), and why we need the change at all (i.e. who is the target), and why free fonts like ubuntu are not good enough, what you tried, the feedback on talk pages? i am already ashamed that i ask this now the second or third time ... and i still try to do it in a nice and welcoming way, not shouting or swearing ... rupert.

Rob, I think you should cross-post all or most of that on Talk:Typography Refresh, since not all the designers are actually on Wikitech. A few thoughts of my own... On Mon, Feb 17, 2014 at 4:42 PM, Rob Lanphier <robla(a)wikimedia.org> wrote: 1). I don't really see how there is or will be actually any serious "level of disruption" for users beyond a temporary shock of an incremental change. Right now what I see internal MediaWiki community drama over changing a longstanding precedent, which is not the same thing. I don't know about you, but I care ultimately what happens for users of MediaWiki/Wikimedia not whether people want to fight about something on a mailing list. If that's the measure of disruptive, then almost everything we do is extremely disruptive. As you say, it's not a hugely radical chance, and so far overall use of the beta has stayed steady or grown over time. Millions more mobile readers have been happily using almost the exact same font family settings for all our projects for more than a year. (That's the basic consistency we're talking about.) Feedback from most end users on the Talk page has been positive or neutral the base content font family, or has been more concerned with other details (like serif headings). People here mostly seem to have debated two points: "are violating our free software requirement?" (unequivocal answer: no) and "is this better?" The answer to that is partially a matter of personal taste, which is why everyone who wants is still free to customize the skin however they like. Typography is one of those elements of design that everyone has a strong opinion about, even if they don't really grasp fundamentals of the domain. The second part of the answer seems to me that the UX team, as the experts in this, needs to do a better job of documenting their research and the feedback so far from end users. That is why I recommended we hold back on pushing the beta feature to Vector for now. 2). I think Jared and others hinted that the most satisfying leap forward would be delivering free/open webfonts to all users. Ideally, it would even be something custom designed for Wikimedia. However, that's just not a realistic bet right now, and we have reason to tread cautiously as Erik said. 3). Last and most important, you listed main body font family, but ignored the other changes that are a part of the Typography Refresh as housed in Extension:VectorBeta. A large part of what makes typography good or bad is not simply the font family you choose. It's how you set it -- the visual context -- that matters just as much. Ultimately arguing about that one line of CSS is not really a discussion about the actual experience on our sites. -- Steven Walling, Product Manager https://wikimediafoundation.org/

On Mon, Feb 17, 2014 at 3:38 PM, Steven Walling <steven.walling(a)gmail.com>wrote;wrote: And in Gmail, "I" and "l" look identical in the font that they chose. Often that doesn't matter, but sometimes it does and since they override it it's not as simple as configuring a better font in the browser (or not having to at all). And then there are the several ways they screw around with the normal browser behavior in these reply boxes that are usability issues for me: I can't Ctrl-PgUp or Ctrl-PgDn to switch tabs, I can't Shift-PgUp or Shift-PgDn to select large blocks of text, I have to always choose the "Pop out reply" because the scrolling is screwed up in the inline reply and I can't actually see the entirety of the input field, etc. So saying "We're not as fancy as Gmail" doesn't sound like a very compelling argument to me. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation