Should MediaWiki CSS prefer non-free fonts?

classic Classic list List threaded Threaded
125 messages Options
1234567
Reply | Threaded
Open this post in threaded view
|

Re: Communication of decisions (was Re: Should MediaWiki CSS prefer non-free fonts?)

Tyler Romeo
On Sun, Feb 16, 2014 at 6:36 PM, Greg Grossmeier <[hidden email]> wrote:

> See also: The general rule among many engineering departments at WMF is
> "If it didn't happen on the list (or somewhere similarly public and
> indexable) it didn't happen."
>
> The team I most recently heard champion that rule was the Mobile Team.
>

Agreed on this. Even on Gerrit, it is hard to keep track of possible
changes and decisions being made. The mailing list is an important medium
for any significant discussion and announcements concerning MediaWiki.

*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Communication of decisions (was Re: Should MediaWiki CSS prefer non-free fonts?)

Steven Walling
In reply to this post by Greg Grossmeier-2
On Sun, Feb 16, 2014 at 3:36 PM, Greg Grossmeier <[hidden email]> wrote:

> See also: The general rule among many engineering departments at WMF is
> "If it didn't happen on the list (or somewhere similarly public and
> indexable) it didn't happen."
>

Wikitech is great for discussing things with a wider audience especially
where we need to seek opinions of developers outside the staff. But most
decisions people make are documented on a wiki, Bugzilla, and/or their
preferred project management tool. A mailing list is quite bad at reaching
a consensus decision on something, as evidenced by the fact that we hold
RFCs on a wiki, and not here.

No one is suggesting that we should make all decisions via
teleconferencing. If you read Jon's comment with good faith, he obviously
wants to reach common ground with Brad on a contentious issue, and
suggested using a medium that is different than what we've tried already.
Brad has brought this up repeatedly on the list and Talk:Typography
Refresh, discussing this with both end users who disagreed and fellow staff
members. Little apparent progress has been made in reaching consensus.
Jon's trying to be respectful and reach common ground with a coworker. I
don't think anyone should be taken to task for such behavior, not when (as
you say) Jon's clearly been part of a team that has pushed for better
documentation of decisions than just in-office face to face meetings.

In short: mountain out of a mole hill. Don't assume people don't care about
public discussion because they want to have a 1-1 with someone whose
opinion they think is important.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Communication of decisions (was Re: Should MediaWiki CSS prefer non-free fonts?)

Jon Robson
Firstly apologies if my mail was read as public discussions = bad. That was
not my intention. The fact I am on a vacation and writing emails on a phone
with a heavily bandaged hand (which hurts when i type) surely shows I care
a lot about this matter (and the fact that I am doing so on a phone might
account for it being worded badly). Thanks Steven for reading it as it was
intended.

The problem that I am seeing is that we have these discussions on talk
pages, countless mailing lists, Bugzilla, MediaWiki pages, gerrit commit
summaries ... where should decisions be recorded in such a way that they
can be found? We are obviously failing...

From my perspective the decision for this change was communicated - at the
code level. See https://gerrit.wikimedia.org/r/#/c/108155/ and the code is
the first place someone should go to understand why something is happening.

As can be seen in the commit summary there was a meeting and this was the
outcome... (I was not in said meeting and your can see from the review that
I demanded to understand why said change was happening in an attempt to
help document this.)

Meetings imo are sometimes more effective than mailing list conversations
especially for any design related work and I don't think this needs to go
against the idea of an open community as long as output is recorded in some
form.

In this particular situation I ask all of you how could a better job in
communicating the dropping of free fonts have been done? What can we learn
from this to improve our communication?

On 16 Feb 2014 19:36, "Greg Grossmeier" <[hidden email]> wrote:
>
> <quote name="Brian Wolff" date="2014-02-16" time="18:00:29 -0400">
> > On Feb 16, 2014 2:04 PM, "Jon Robson" <[hidden email]> wrote:
> > >
> > > Brad since you work for the for the foundation and seem to have a lot
of
> > > expertise in this area and seem to have been one of the more vocal
> > > supporters of free fonts have you reached out to your work colleagues
over
> > > video conferencing or similar to understand the problems being hit and
> > > helped them work through them? Email doesn't seem to have been an
> > effective
> > > method of communication in this situation as you have pointed out.
Maybe
> > > you can help with documenting these issues and helping people like
> > yourself
> > > understand the problems and why this change was reverted?
> > >
> >
> > I've seen setiment like this (discuss in person, in hangout, or
otherwise
> > privately) pop up recently (e.g on [1]). I think attitudes like that
are a
> > real problem. Supposedly we are an open community. People should be
> > entirely prepared to explain their reasoning for doing anything on a
public
> > mailing list no matter if the request comes from a wmf staffer like
Brad,
> > or if it comes from somebody you have never heard of before. In fact i
> > would argue that the criteria and results of evaluations should be
public

> > on the wiki from the get go, without anyone even asking for it.
>
> See also: The general rule among many engineering departments at WMF is
> "If it didn't happen on the list (or somewhere similarly public and
> indexable) it didn't happen."
>
> The team I most recently heard champion that rule was the Mobile Team.
>
> Greg
>
> --
> | Greg Grossmeier            GPG: B2FA 27B1 F7EB D327 6B8E |
> | identi.ca: @greg                A18D 1138 8E47 FAC8 1C7D |
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 16 Feb 2014 20:01, "Steven Walling" <[hidden email]> wrote:

> On Sun, Feb 16, 2014 at 3:36 PM, Greg Grossmeier <[hidden email]>
> wrote:
>
> > See also: The general rule among many engineering departments at WMF is
> > "If it didn't happen on the list (or somewhere similarly public and
> > indexable) it didn't happen."
> >
>
> Wikitech is great for discussing things with a wider audience especially
> where we need to seek opinions of developers outside the staff. But most
> decisions people make are documented on a wiki, Bugzilla, and/or their
> preferred project management tool. A mailing list is quite bad at reaching
> a consensus decision on something, as evidenced by the fact that we hold
> RFCs on a wiki, and not here.
>
> No one is suggesting that we should make all decisions via
> teleconferencing. If you read Jon's comment with good faith, he obviously
> wants to reach common ground with Brad on a contentious issue, and
> suggested using a medium that is different than what we've tried already.
> Brad has brought this up repeatedly on the list and Talk:Typography
> Refresh, discussing this with both end users who disagreed and fellow staff
> members. Little apparent progress has been made in reaching consensus.
> Jon's trying to be respectful and reach common ground with a coworker. I
> don't think anyone should be taken to task for such behavior, not when (as
> you say) Jon's clearly been part of a team that has pushed for better
> documentation of decisions than just in-office face to face meetings.
>
> In short: mountain out of a mole hill. Don't assume people don't care about
> public discussion because they want to have a 1-1 with someone whose
> opinion they think is important.
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Communication of decisions (was Re: Should MediaWiki CSS prefer non-free fonts?)

Greg Grossmeier-2
In reply to this post by Steven Walling
On Feb 16, 2014 4:01 PM, "Steven Walling" <[hidden email]> wrote:
>
> On Sun, Feb 16, 2014 at 3:36 PM, Greg Grossmeier <[hidden email]>
wrote:

>
> > See also: The general rule among many engineering departments at WMF is
> > "If it didn't happen on the list (or somewhere similarly public and
> > indexable) it didn't happen."
> >
>
> Wikitech is great for discussing things with a wider audience especially
> where we need to seek opinions of developers outside the staff. But most
> decisions people make are documented on a wiki, Bugzilla, and/or their
> preferred project management tool. A mailing list is quite bad at reaching
> a consensus decision on something, as evidenced by the fact that we hold
> RFCs on a wiki, and not here.
>
> No one is suggesting that we should make all decisions via
> teleconferencing.

And I'm not saying the opposite. I'm just referring to the communication of
those decisions (see subject ;)). The end reasoning and decision part (at
least).

Tangentially, I very much disagree with the sentiment that email = bad for
group discussion. There are so many counter examples where it is good for
discussion, and notably in technical discussions where details/quoting is
important.

End rant :)

Greg (from phone)
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Communication of decisions (was Re: Should MediaWiki CSS prefer non-free fonts?)

Chad
In reply to this post by Steven Walling
On Sun, Feb 16, 2014 at 4:00 PM, Steven Walling <[hidden email]>wrote:

> Wikitech is great for discussing things with a wider audience especially
> where we need to seek opinions of developers outside the staff.
>

Which is basically almost always :)


>
> No one is suggesting that we should make all decisions via
> teleconferencing.


I'd suggest none be made via teleconferencing, but I know that
won't happen :)

-Chad
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Design] Should MediaWiki CSS prefer non-free fonts?

Derk-Jan Hartman
In reply to this post by Steven Walling-3

On 16 feb. 2014, at 09:13, Steven Walling <[hidden email]> wrote:
> On webfonts: it's not just that it would take "more research". We have
> already tried webfonts and failed miserably so far.
> UniversalLanguageSelector is an example of how even the most
> well-intentioned efforts in this area can face serious setbacks. Keep in
> mind also that this typography work is largely being done with volunteer or
> side project time from myself, the developers, and most of the designers.
> We are simply not prepared to implement and test a webfonts system to work
> at Wikipedia scale.

I would say that ULS was a success. It just had quite few general implementation mistakes that created a lot of backlash that was not being dealt with fast enough.

There is one area where ULS made true mistakes and that is thinking that it can always do better than the operating system/user. And that is the same risk that this exercise is running into. Thinking that we can define fonts in a way that is 'better' than the OS can do it. And though that is a lofty goal and in some specific cases/browsers is probably achievable, it also introduces a lot of potential risks.

On English Wikipedia we have done a lot of exercises in the past with trying to find fonts that improve peoples experiences for specific scripts, ipa, math and unicode in general and we have always run into similar community problems because there were edge cases there were problematic.

In my opinion IF you want to do this, you really need to look at, NOT what you are enhancing, but as with so many changes, what you might potentially break and how NOT to break that. Knowledge is key there, mostly because fonts on various systems have always been a bit of a mess to begin with. Knowing which names map to which fonts. Knowing the 'completeness' and 'correctness' of fonts, knowing how the various browser (versions) use the various web font loading techniques, knowing which Operating Systems use which glyph fallback routines thus becomes key to knowing how NOT to break the defaults.

And if we don't have time to look at such things, then we probably shouldn't mess too much with it.

DJ


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Design] Should MediaWiki CSS prefer non-free fonts?

Steven Walling
On Mon, Feb 17, 2014 at 12:15 PM, Derk-Jan Hartman <
[hidden email]> wrote:

> There is one area where ULS made true mistakes and that is thinking that
> it can always do better than the operating system/user. And that is the
> same risk that this exercise is running into. Thinking that we can define
> fonts in a way that is 'better' than the OS can do it. And though that is a
> lofty goal and in some specific cases/browsers is probably achievable, it
> also introduces a lot of potential risks.


In this regard we are something of an odd duck though, which should be a
red flag. The vast majority of well-designed and highly usable sites, large
and small, do 'declare fonts in a way that is "better" than the OS can do
it.' Even an *exceptionally* plain product like Gmail has a more specific
font family setting than Vector does at the moment.

Which is not to deny that there are no risks. It's to say that, with elbow
grease and attention to the cases you talk about below (IPA, different
scripts, etc.) we can actually have a setting that is better for most users
on most platforms. Sacrificing the readability and beauty of content for
most users because there is no universally perfect solution is the kind of
hard-line approach that limits the reach of FOSS, and ultimately undermines
our goal of making something the entire world can use and enjoy.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Design] Should MediaWiki CSS prefer non-free fonts?

Steven Walling-3
In reply to this post by Greg Grossmeier-2
On Sat, Feb 15, 2014 at 3:59 PM, Greg Grossmeier <[hidden email]> wrote:

> <quote name="Federico Leva (Nemo)" date="2014-02-15" time="22:52:31 +0100">
> > And surely, before WMF/"MediaWiki" tell the world that no free fonts
> > of good quality exist, there will be some document detailing exactly
> > why and based on what arguments/data/research the numerous free
> > alternatives were all rejected? Free fonts developers are an
> > invaluable resource for serving Wikimedia projects' content in all
> > languages, we shouldn't carelessly slap them in their face.
>
> I just skimmed the entire thread again, and yes, this has been requested
> a few times but no one from the WMF Design team has responded with that
> analysis (or if would respond with an analysis). The first time it was
> requested the person was told to ask the Design list, then the next
> message CC'd the design list, but no response on that point.
>
> I don't see much on https://www.mediawiki.org/wiki/Typography_refresh
> nor it's talk page. Nor
> https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Typography
>
> cc'ing the Design list :)
>

Update on this: after discussing with Greg, Jared, etc. I've edited
wikitech Deployments calendar to reflect a longer term goal of mid to late
March at the earliest.

The calls from Greg, Kaldari, Nemo and others for better documentation are
100% correct, and it's something we should do before we move to merge
anything from the typography refresh in to Vector proper. There's a better
FAQ and more in development by the design team, but getting that out and
properly translated in just a week is not realistic. Overall the continued
discussion on Wikitech-l suggestions to me that doing this by the 27th
would be a rush job.

Note that there was a small update to the feature on Friday, which removed
the max-width restriction and tweaked some padding. I'd encourage anyone
who hasn't tried the beta feature in a few weeks to give it another shot.
We'll update Typography Refresh and the accompanying Talk page on
mediawiki.org accordingly.

Thanks,

--
Steven Walling,
Product Manager
https://wikimediafoundation.org/
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Design] Should MediaWiki CSS prefer non-free fonts?

Derk-Jan Hartman

On 17 feb. 2014, at 21:49, Steven Walling <[hidden email]> wrote:
>
> Note that there was a small update to the feature on Friday, which removed
> the max-width restriction and tweaked some padding. I'd encourage anyone
> who hasn't tried the beta feature in a few weeks to give it another shot.
> We'll update Typography Refresh and the accompanying Talk page on
> mediawiki.org accordingly.

There was also a small addition to that feature, which concerns the ToC styling, which has had NO time to garner feedback yet, so I think postponing is a good idea. Also a good pass of the feedback page seems a requirement for any deploy if you ask me :D

DJ


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Design] Should MediaWiki CSS prefer non-free fonts?

Steven Walling
On Mon, Feb 17, 2014 at 12:59 PM, Derk-Jan Hartman <
[hidden email]> wrote:

> There was also a small addition to that feature, which concerns the ToC
> styling, which has had NO time to garner feedback yet, so I think
> postponing is a good idea. Also a good pass of the feedback page seems a
> requirement for any deploy if you ask me :D
>

The TOC style is actually not new as of Friday (see:
https://gerrit.wikimedia.org/r/#/c/108155/), and rolled out to most
Wikimedia sites on Feb 6th. I think it's just that enough MediaWiki
insiders disliked the max-width that they stopped using the beta feature,
and haven't seen the updates since then. ;)
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Design] Should MediaWiki CSS prefer non-free fonts?

Rob Lanphier-4
In reply to this post by Steven Walling
On Mon, Feb 17, 2014 at 12:38 PM, Steven Walling
<[hidden email]>wrote:

> Sacrificing the readability and beauty of content for
>  most users because there is no universally perfect solution is the kind of
> hard-line approach that limits the reach of FOSS, and ultimately undermines
> our goal of making something the entire world can use and enjoy.


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.html

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-switches-to-compatibility-mode-ie9-and-ie10/15011654#15011654
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Design] Should MediaWiki CSS prefer non-free fonts?

Ryan Kaldari-2
In reply to this post by Ryan Kaldari-2
I took a closer look at Linux Libertine for possible use as a webfont for
headers. Linux Libertine is a "classic" serif font that would match the
character of the site (i.e. it looks "encylopedic"). It has a wide
character coverage (over 2000 characters) and support for most ligatures.
It even has its own bug tracker (
http://sourceforge.net/p/linuxlibertine/bugs/). It's only shortcoming is
that it has an install base of pretty much no one.

Unfortunately, the WOFF file for the base font (not including bold, italic,
etc.) is 516K which is way too large to use as a webfont. I imagine this is
due to the font's character coverage. One option would be for us to fork
Linux Libertine, reduce the character coverage (for example, it's very rare
to need math and symbol glyphs in headers), and see if we can get it small
enough to try delivering as a webfont. This is probably not something we
could do immediately, but I think it's an idea worth looking at. Another
option would be seeing if we could convince some major Linux distros to
include it as a default font.

As far as it's aesthetic qualities (cover your ears, devs), it has been
positively reviewed by several design sites.[1] Apparently the font
designers put so much work into tweaking the kerning that it would cause
some older word processors to run out of kerning memory! You can see
samples of it here: http://www.linuxlibertine.org/index.php?id=86&L=1.
The

[1] See sidebar at http://www.linuxlibertine.org/index.php?id=2&L=1

Ryan Kaldari



On Mon, Feb 17, 2014 at 11:49 AM, May Tee-Galloway
<[hidden email]>wrote:

> We've been testing out Open Sans on the apps team, it's an open source
> font. The goals with any font choice is high quality (legible, scannable,
> well-kerned, etc), has wide character set, and since every font has its own
> personality, we want the font choice to reflect us and our content, and
> among that is credible, neutral, and high quality.
>
> Not all fonts are created equal. Helvetica is very widely used not only
> because it's such a polished font but it was designed specifically to be
> the font that is neutral and to have no implied meanings like many fonts
> do. Sounds perfect, except for the not free part.
>
> We're actively looking and trying out helvetica neue alternative that's
> open source but it's been challenging. They either don't come with enough
> characters, not well-kerned, or has too much personality that is not us.
>
> I understand the preference for an open source font but we are giving up
> certain areas that are probably just as important as being open source like
> reading experience.
>
> As for Georgia or Helvetica, serif (Georgia) fonts are recommended with
> larger texts because they don't reduce well on screen. Sans serif
> (Helvetica) fonts are recommended with smaller texts because they retain
> their general character shapes better than serif fonts. [1] One might argue
> that our web body text is not that small, hence we can use serif. There are
> three reasons why I wouldn't recommend that. 1. Content looks large and
> fine on the web but when it's displayed on phones and tablets, it's not as
> big anymore to use serif. 2. Why don't we use serif on web and sans serif
> on other platforms? Because that causes inconsistency. Readers should
> experience the same experience regardless of platform. WP content should be
> the one that takes center stage, not "why is my content appearing different
> on my tablet or phone?" We have fallback font options only when we must
> choose an alternative. 3. Helvetica has a neutral font personality. Serif,
> on the other hand, has many implications like traditional, Roman, formal,
> etc. [2,3]
>
> We know the importance for using an open source font and we have been
> looking for an alternative. We also know that we care deeply for our
> reader's experience. Helvetica was chosen to use because it helped reflect
> our content type, it's high quality, has good amount of character set (and
> if it doesn't, it's fairly easy to find a similar-ish font to match). But I
> can't lie it's a beautiful font, I can assure you we didn't judge Helvetica
> by its cover though. ;P Hope this helps!
>
> [1]
> http://www.webdesignerdepot.com/2013/03/serif-vs-sans-the-final-battle/
> [2]
> http://psychology.wichita.edu/surl/usabilitynews/81/PersonalityofFonts.asp
> [3] http://opusdesign.us/to-be-or-not-to-be-the-serif-question/
>
> May
>
> On Feb 15, 2014, at 9:07 PM, Ryan Kaldari <[hidden email]> wrote:
>
> Frankly, I think there has been a large degree of intransigence on both
> sides. The free font advocates have refused to identify the fonts that they
> want to be considered and why they should be considered other than the fact
> that they are free, and the designers have refused to take any initiative
> on considering free fonts. The free fonts that I know have been considered
> are:
> * DejaVu Serif. Conclusion: Widely installed, but horribly ugly and looks
> nothing like the style desired by the designers.
> * Nimbus Roman No9 L. Conclusion: Basically a clone of Times. Most Linux
> systems map Times to Nimbus Roman No9 L, so there is no advantage to
> specifying "Nimbus Roman No9 L" rather than "Times" (which also maps to
> fonts on Windows and Mac).
> * Linux Libertine. Conclusion: A well-designed free font that matches the
> look of the Wikipedia wordmark. Unfortunately, it is not installed by
> default on any systems (as far as anyone knows) but is bundled with
> LibreOffice as an application font. If MediaWiki were using webfonts, this
> would likely be the serif font of choice rather than Georgia, but since we
> are relying on pre-installed fonts, it would be rather pointless to list it.
> * Liberation Sans. Conclusion: Essentially a free substitute for Arial.
> Like Nimbus Roman, there is no advantage to specifying "Liberation Sans"
> instead of "Arial" (which is at the bottom of the sans-serif stack) since
> Linux systems will map to Liberation Sans anyway, while other systems will
> apply Arial.
>
> As to proving the quality of Georgia and Helvetica Neue, I don't think the
> designers have done that, but I also haven't seen any evidence from the
> free font advocates concerning the quality of any free fonts. So in my
> view, both sides of the debate have been delinquent.
>
> Ryan Kaldari
>
>
> On Sat, Feb 15, 2014 at 4:16 PM, Greg Grossmeier <[hidden email]>wrote:
>
>> <quote name="Steven Walling" date="2014-02-15" time="16:08:41 -0800">
>> > On Sat, Feb 15, 2014 at 3:59 PM, Greg Grossmeier <[hidden email]>
>> wrote:
>> >
>> > > <quote name="Federico Leva (Nemo)" date="2014-02-15" time="22:52:31
>> +0100">
>> > > > And surely, before WMF/"MediaWiki" tell the world that no free fonts
>> > > > of good quality exist, there will be some document detailing exactly
>> > > > why and based on what arguments/data/research the numerous free
>> > > > alternatives were all rejected? Free fonts developers are an
>> > > > invaluable resource for serving Wikimedia projects' content in all
>> > > > languages, we shouldn't carelessly slap them in their face.
>> > >
>> > > I just skimmed the entire thread again, and yes, this has been
>> requested
>> > > a few times but no one from the WMF Design team has responded with
>> that
>> > > analysis (or if would respond with an analysis). The first time it was
>> > > requested the person was told to ask the Design list, then the next
>> > > message CC'd the design list, but no response on that point.
>> > >
>> > > I don't see much on https://www.mediawiki.org/wiki/Typography_refresh
>> > > nor it's talk page. Nor
>> > > https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Typography
>> > >
>> >
>> > There wasn't an answer because the question is a fundamental
>> > misunderstanding of the way CSS works and options that are within our
>> > reach. The question isn't "are there good free fonts?" the question is
>> "can
>> > we deliver good free fonts to all users?". I'll try to help the UX team
>> > document the answer better.
>>
>> Thanks.
>>
>> I may be part of the misunderstanding-of-how-things-work-in-font-land
>> contingent. Advice/clarity appreciated.
>>
>> Greg
>>
>>
>> --
>> | Greg Grossmeier            GPG: B2FA 27B1 F7EB D327 6B8E |
>> | identi.ca: @greg                A18D 1138 8E47 FAC8 1C7D |
>>
>> _______________________________________________
>> Design mailing list
>> [hidden email]
>> https://lists.wikimedia.org/mailman/listinfo/design
>>
>
> _______________________________________________
> Design mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/design
>
>
> _______________________________________________
> Design mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/design
>
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Design] Should MediaWiki CSS prefer non-free fonts?

Erik Moeller-4
In reply to this post by Rob Lanphier-4
On Mon, Feb 17, 2014 at 4:42 PM, Rob Lanphier <[hidden email]> wrote:
> 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.

So, what would be the downside of listing a font like Arimo for
sans-serif and Libertine for serif first in the stack? While not
affecting the reader experience for a significant number of users, it
would still be a symbolic expression of a preference for freely
licensed fonts, and a conscious choice of a beautiful font for readers
that have installed it.

There may be practical and aesthetic arguments against these or other
specific free fonts; if so, it would be good to hear those arguments
spelled out. I do agree that if "Helvetica Neue" is only installed on
Macs and costs $30 for everyone, it's a pretty idiosyncratic choice as
a primary font to specify. :-) Surely if the font requires downloading
on the majority of platforms anyway, we may as well specify a free one
before the non-free one.

As for webfonts, given the ULS experience I'd be very leery of the
performance impact, both in terms of delivering the font and any
unintended re-rendering flashes.

Erik

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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Design] Should MediaWiki CSS prefer non-free fonts?

Steven Walling-3
In reply to this post by Rob Lanphier-4
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 <[hidden email]> wrote:

> This doesn't seem like a satisfying leap forward, given the level of
> disruption.


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/
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Design] Should MediaWiki CSS prefer non-free fonts?

Steven Walling-3
In reply to this post by Erik Moeller-4
On Mon, Feb 17, 2014 at 4:58 PM, Erik Moeller <[hidden email]> wrote:

> So, what would be the downside of listing a font like Arimo for
> sans-serif and Libertine for serif first in the stack? While not
> affecting the reader experience for a significant number of users, it
> would still be a symbolic expression of a preference for freely
> licensed fonts, and a conscious choice of a beautiful font for readers
> that have installed it.
>

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/
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Design] Should MediaWiki CSS prefer non-free fonts?

Erik Moeller-4
On Mon, Feb 17, 2014 at 7:19 PM, Steven Walling <[hidden email]> 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.

Thanks Steven et al. It's clear from
https://gerrit.wikimedia.org/r/#/c/108155/ that everyone involved is
trying to do the right thing. :)

I agree with Rob's follow-up question here --

https://www.mediawiki.org/w/index.php?title=Talk:Typography_refresh&diff=908614&oldid=908502

i.e. we should document our assessment of freely licensed fonts and
any associated design or rendering issues. Even if specifying
alternative fonts in the stack _is_ largely symbolic, to the extent
that we can express our values through our choices here without
negative side effects, we should.

Erik

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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Design] Should MediaWiki CSS prefer non-free fonts?

rupert THURNER-2
In reply to this post by Steven Walling-3
On Tue, Feb 18, 2014 at 4:19 AM, Steven Walling <[hidden email]>wrote:

> On Mon, Feb 17, 2014 at 4:58 PM, Erik Moeller <[hidden email]> wrote:
>
> > So, what would be the downside of listing a font like Arimo for
> > sans-serif and Libertine for serif first in the stack? While not
> > affecting the reader experience for a significant number of users, it
> > would still be a symbolic expression of a preference for freely
> > licensed fonts, and a conscious choice of a beautiful font for readers
> > that have installed it.
> >
>
> 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.
>

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.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Design] Should MediaWiki CSS prefer non-free fonts?

Brad Jorsch (Anomie)
In reply to this post by Steven Walling
On Mon, Feb 17, 2014 at 3:38 PM, Steven Walling <[hidden email]>wrote:

> Even an *exceptionally* plain product like Gmail has a more specific
> font family setting than Vector does at the moment.
>

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
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Design] Should MediaWiki CSS prefer non-free fonts?

Brad Jorsch (Anomie)
In reply to this post by Steven Walling-3
On Mon, Feb 17, 2014 at 10:19 PM, Steven Walling <[hidden email]>wrote:

> and we got very specific negative feedback about [placing free fonts
> first] on the Talk page.
>

You also got very specific positive feedback about placing free fonts
first, and very specific negative feedback about specifying anything other
than "sans-serif". But you seem to have ignored that feedback.

I think the problem is that you've defined Helvetica Neue as what you want,
so nothing else is good enough.


--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Design] Should MediaWiki CSS prefer non-free fonts?

C. Scott Ananian
In reply to this post by Rob Lanphier-4
An apropos link from daringfireball today:

http://www.jordanm.co.uk/tinytype
lists the available 'system fonts' on iOS/Android/Windows Phone/Blackberry.

For communication purposes, it would be great to fork it (
https://github.com/jordanmoore/tinytype) and add the available default
system fonts on Mac OS, Window 7/8, Ubuntu, Red Hat, etc.

(Then the only missing piece would be the font-mapping information, so you
could tell what font the string "serif" or "Helvetica" (say) is mapped to
on the various platforms.)
  --scott
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
1234567