First, I like to aplologize to anyone who I may have come over too passionate at some times. Frustration is known to get the better of me, even though I should control that. (I also quit smoking.)
Not sure where a new font stack should be discussed, so I'm just throwing it in here. Also, note I propose this for Latin wikis only.
Asuming we want the 'Helvetca' look for the body font:
font-family: "Nimbus Sans L", "Helvetica Neue", Arial, Helvetica, sans-serif;
Breakdown:
Nimbus Sans L - for Linux. This is the defacto helv font on Linux systems which result in an look similair to Mac/Windows. Windows will not match this font, as the Windows versions of the Nimbus font packages have different font family names (ie. 'NimbusSanL' instead of 'Nimbus Sans L').
Helvetica Neue - for Mac. Like Nimbus, this should not match fonts on Windows (or Linux for that matter), as those copies for Windows have differen font family names (like 'Helvetica Neue LT Com 55 Roman').
Arial - For Windows. Positioned after Nimbus Sans and Helvetica Neue, so Mac and Linux do not match Arial, but positioned before Helvetica to prevent matching an inferiour Helvetica font that may be installed on some Windows machines.
Helvetica - Generic Helvetica fallback for any system not matching any of the previous fonts.
I'd like to test this locally on the English Wikipedia, and I am quit confident this makes everyone happy because 1) every OS should end up using a native font, and 2) it "promotes" a free font at the beginning of the stack (not a high priority in my book though).
Next up I may think about the headers font stack; While Georgia is a good serif; I detest its use of text figures.
Regards,
<3
Thank you Erwin for always moving things forward. Much appreciated. :)
Erik
On Friday, April 11, 2014, Erwin Dokter erwin@darcoury.nl wrote:
First, I like to aplologize to anyone who I may have come over too passionate at some times. Frustration is known to get the better of me, even though I should control that. (I also quit smoking.)
Much harder to quit than to find a perfect font stack that pleases everyone. :) Thanks for all your work on this Erwin.
Not sure where a new font stack should be discussed, so I'm just throwing it in here. Also, note I propose this for Latin wikis only.
Asuming we want the 'Helvetca' look for the body font:
font-family: "Nimbus Sans L", "Helvetica Neue", Arial, Helvetica, sans-serif;
Breakdown:
Nimbus Sans L - for Linux. This is the defacto helv font on Linux systems which result in an look similair to Mac/Windows. Windows will not match this font, as the Windows versions of the Nimbus font packages have different font family names (ie. 'NimbusSanL' instead of 'Nimbus Sans L').
This is the part I want to confirm and test. I want to be 100% sure that we are not gonna run in to the same ClearType rendering issues. (I have a Windows 7 laptop at my disposal that I can test with, as well as XP virtual machines.)
Helvetica Neue - for Mac. Like Nimbus, this should not match fonts on Windows (or Linux for that matter), as those copies for Windows have differen font family names (like 'Helvetica Neue LT Com 55 Roman').
Arial - For Windows. Positioned after Nimbus Sans and Helvetica Neue, so Mac and Linux do not match Arial, but positioned before Helvetica to prevent matching an inferiour Helvetica font that may be installed on some Windows machines.
Helvetica - Generic Helvetica fallback for any system not matching any of the previous fonts.
Putting this after Arial will avoid any Windows users getting a bad version of Helvetica rendered on their machines.
I'd like to test this locally on the English Wikipedia, and I am quit confident this makes everyone happy because 1) every OS should end up using a native font, and 2) it "promotes" a free font at the beginning of the stack (not a high priority in my book though).
Why don't we test this on Beta Labs and Mediawiki.org first instead of using enwiki as a guinea pig? We can make you a sysop there.
Next up I may think about the headers font stack; While Georgia is a good serif; I detest its use of text figures.
Times and Times New Roman are worse overall. ;)
Regards,
Erwin Dokter
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 11-04-2014 21:49, Steven Walling wrote:
This is the part I want to confirm and test. I want to be 100% sure that we are not gonna run in to the same ClearType rendering issues. (I have a Windows 7 laptop at my disposal that I can test with, as well as XP virtual machines.)
I aksed on the Typography page where you got the fonts, as there may be other versions then what I have.
Putting this after Arial will avoid any Windows users getting a bad version of Helvetica rendered on their machines.
That is the general idea.
Why don't we test this on Beta Labs and Mediawiki.org first instead of using enwiki as a guinea pig? We can make you a sysop there.
I would appriciate that. I can also use test.wikipedia.org of course. The beta labs is very slow for me somehow.
Regards,
On 12 April 2014 05:49, Steven Walling steven.walling@gmail.com wrote:
I'd like to test this locally on the English Wikipedia, and I am quit confident this makes everyone happy because 1) every OS should end up
using
a native font, and 2) it "promotes" a free font at the beginning of the stack (not a high priority in my book though).
Why don't we test this on Beta Labs and Mediawiki.org first instead of using enwiki as a guinea pig? We can make you a sysop there.
MW wiki is a content wiki first and foremost, not a test bed wiki, First level testing should take place elsewhere.
On 2014-04-11, 12:30 PM, Erwin Dokter wrote:
Nimbus Sans L - for Linux. This is the defacto helv font on Linux systems which result in an look similair to Mac/Windows. Windows will not match this font, as the Windows versions of the Nimbus font packages have different font family names (ie. 'NimbusSanL' instead of 'Nimbus Sans L').
Helvetica Neue - for Mac. Like Nimbus, this should not match fonts on Windows (or Linux for that matter), as those copies for Windows have differen font family names (like 'Helvetica Neue LT Com 55 Roman').
Arial - For Windows. Positioned after Nimbus Sans and Helvetica Neue, so Mac and Linux do not match Arial, but positioned before Helvetica to prevent matching an inferiour Helvetica font that may be installed on some Windows machines.
Helvetica - Generic Helvetica fallback for any system not matching any of the previous fonts.
Hmmm, thinking about it this might work.
* I was a little worried that older versions of Apple products may not have Helvetica Neue and didn't want them to get Arial, however it looks like it's been long enough. iOS has had Neue since the same time it has has Helvetica, and OSX has had Neue since 10.5 at least (that's as far back as the per version font lists go). * However I wonder if 'Helvetica' will ever actually be matched. Even Arial is crappier than Helvetica in most places (aside from those Windows installed Helvetica fonts) I can't really think of any situation where a device would have Helvetica but not any of the others. Are there any linux installs which don't have Nimbus Sans L and don't have a font which would be matched by Arial?
A random unrelated point I found while looking up Android, the Kindle Fire supposedly bundles Arial in addition to the default Droid Sans that comes with Android. Not sure that it's preferable to match Arial, would need actual testing
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
On 11-04-2014 22:43, Daniel Friesen wrote:
- However I wonder if 'Helvetica' will ever actually be matched. Even Arial is crappier than Helvetica in most places (aside from those Windows installed Helvetica fonts) I can't really think of any situation where a device would have Helvetica but not any of the others. Are there any linux installs which don't have Nimbus Sans L and don't have a font which would be matched by Arial?
I don't know, and that's basically why it's there. I don't know of any other desktop OSes, but I'm sure they're there. As for mobile, there's Blackberry, which I also know nothing about. But again, that's why Helvetica is there... as a general fallback (before sans-serif).
Regards,
On 11 April 2014 20:30, Erwin Dokter erwin@darcoury.nl wrote:
...
Thank you for your work on this!
Next up I may think about the headers font stack; While Georgia is a good serif; I detest its use of text figures.
I previously suggested a solution to this that should work for most users ( https://www.mediawiki.org/wiki/Talk:Typography_refresh/Archive_2#Numbers_loo... ) Steven: was this tried?
Regards,
Erwin Dokter
Peter
On 12-04-2014 00:47, Peter Coombe wrote:
I previously suggested a solution to this that should work for most users ( https://www.mediawiki.org/wiki/Talk:Typography_refresh/Archive_2#Numbers_loo... ) Steven: was this tried?
Using the font-feature-settings CSS. I've had some trouble using this with Georgia, but that was regarding tabular numbers. Works just fine for lining though.
You can test it now at https://test.wikipedia.org/, along with the new font stack.
Regards,
On 12-04-2014 01:29, Erwin Dokter wrote:
Using the font-feature-settings CSS. I've had some trouble using this with Georgia, but that was regarding tabular numbers. Works just fine for lining though.
Thinking further... Browser support is pretty recent, doesn't work in old Opera (Presto) and IE < 10.
Also the font has to support it. What worries me most though in that regard is the old webcore font version of Georgia on Linux; that is an old TTF version without OpenType support, so that trick does not work there.
So, Times is the Helvetica of serifs...
Regards,
On 11/04/14 19:30, Erwin Dokter wrote:
First, I like to aplologize to anyone who I may have come over too passionate at some times. Frustration is known to get the better of me, even though I should control that. (I also quit smoking.)
Not sure where a new font stack should be discussed, so I'm just throwing it in here. Also, note I propose this for Latin wikis only.
Asuming we want the 'Helvetca' look for the body font:
font-family: "Nimbus Sans L", "Helvetica Neue", Arial, Helvetica, sans-serif;
Breakdown:
Nimbus Sans L - for Linux. This is the defacto helv font on Linux systems which result in an look similair to Mac/Windows. Windows will not match this font, as the Windows versions of the Nimbus font packages have different font family names (ie. 'NimbusSanL' instead of 'Nimbus Sans L').
Helvetica Neue - for Mac. Like Nimbus, this should not match fonts on Windows (or Linux for that matter), as those copies for Windows have differen font family names (like 'Helvetica Neue LT Com 55 Roman').
Arial - For Windows. Positioned after Nimbus Sans and Helvetica Neue, so Mac and Linux do not match Arial, but positioned before Helvetica to prevent matching an inferiour Helvetica font that may be installed on some Windows machines.
Helvetica - Generic Helvetica fallback for any system not matching any of the previous fonts.
But same as the original font stack, the question remains - for everything but mac, what is this supposed to solve? What is the purpose of even having helvetica and arial there when they're already the defaults on their respective systems, and when on other systems they would likely be far worse than the defaults? And for linux, either they'll already be using nimbus sans (if they even have it), or it's not going to be what their renderers are optimised for. Every distro is different, with its own defaults and optimisations, and they are optimised based on their defaults. We should not be overriding those without very good reason.
Only one default has been explained to have legitimate problems (I believe it was Daniel Friesen who went into this, so thank you) - helvetica on mac. Given that the fix appears to be a font that will only be present on macs in the first place, would it not be a better approach to simply address this and leave the others be?
Thus:
/* Override Helvetica default on macs to improve font legibility */ font-family: "Helvetica Neue", sans-serif;
This way it is clear what's going on in the source, ideologies are left alone, and everyone gets the best possible experience for their platform.
I'd like to test this locally on the English Wikipedia, and I am quit confident this makes everyone happy because 1) every OS should end up using a native font, and 2) it "promotes" a free font at the beginning of the stack (not a high priority in my book though).
Next up I may think about the headers font stack; While Georgia is a good serif; I detest its use of text figures.
Problem with any serifs is that when using them with sans-serifs, the different fonts need to match each other with similar ratios and weights; sans-serif, serif, or otherwise, you can't just shove any two fonts together and call it a day. Linux libertine, for instance, is very pretty, but its thickness and dimensions simply do not match the body in helvetica et al; it's much more similar to a bold verdana-style font. Georgia may have similar problems (I don't have it so I couldn't say at present), so that might be something to look into there as well.
-I
On Apr 12, 2014 8:58 AM, "Isarra Yos" zhorishna@gmail.com wrote:
On 11/04/14 19:30, Erwin Dokter wrote:
First, I like to aplologize to anyone who I may have come over too
passionate at some times. Frustration is known to get the better of me, even though I should control that. (I also quit smoking.)
Not sure where a new font stack should be discussed, so I'm just
throwing it in here. Also, note I propose this for Latin wikis only.
Asuming we want the 'Helvetca' look for the body font:
font-family: "Nimbus Sans L", "Helvetica Neue", Arial, Helvetica,
sans-serif;
Breakdown:
Nimbus Sans L - for Linux. This is the defacto helv font on Linux
systems which result in an look similair to Mac/Windows. Windows will not match this font, as the Windows versions of the Nimbus font packages have different font family names (ie. 'NimbusSanL' instead of 'Nimbus Sans L').
Helvetica Neue - for Mac. Like Nimbus, this should not match fonts on
Windows (or Linux for that matter), as those copies for Windows have differen font family names (like 'Helvetica Neue LT Com 55 Roman').
Arial - For Windows. Positioned after Nimbus Sans and Helvetica Neue, so
Mac and Linux do not match Arial, but positioned before Helvetica to prevent matching an inferiour Helvetica font that may be installed on some Windows machines.
Helvetica - Generic Helvetica fallback for any system not matching any
of the previous fonts.
But same as the original font stack, the question remains - for
everything but mac, what is this supposed to solve? What is the purpose of even having helvetica and arial there when they're already the defaults on their respective systems, and when on other systems they would likely be far worse than the defaults? And for linux, either they'll already be using nimbus sans (if they even have it), or it's not going to be what their renderers are optimised for.
https://www.mediawiki.org/wiki/Typography_refresh/Font_choice/Test tells me Linux now often gets DejaVu as default sans, and I understand we would rather force Nimbus if it is available as it is deemed better. Also, free font up front.
--Martijn
Every distro is different, with its own defaults and optimisations, and they are optimised based on their defaults. We should not be overriding those without very good reason.
Only one default has been explained to have legitimate problems (I
believe it was Daniel Friesen who went into this, so thank you) - helvetica on mac. Given that the fix appears to be a font that will only be present on macs in the first place, would it not be a better approach to simply address this and leave the others be?
Thus:
/* Override Helvetica default on macs to improve font legibility */ font-family: "Helvetica Neue", sans-serif;
This way it is clear what's going on in the source, ideologies are left
alone, and everyone gets the best possible experience for their platform.
I'd like to test this locally on the English Wikipedia, and I am quit
confident this makes everyone happy because 1) every OS should end up using a native font, and 2) it "promotes" a free font at the beginning of the stack (not a high priority in my book though).
Next up I may think about the headers font stack; While Georgia is a
good serif; I detest its use of text figures.
Problem with any serifs is that when using them with sans-serifs, the
different fonts need to match each other with similar ratios and weights; sans-serif, serif, or otherwise, you can't just shove any two fonts together and call it a day. Linux libertine, for instance, is very pretty, but its thickness and dimensions simply do not match the body in helvetica et al; it's much more similar to a bold verdana-style font. Georgia may have similar problems (I don't have it so I couldn't say at present), so that might be something to look into there as well.
-I
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Erwin, I echo Erik's statement. Thanks for moving this along. In response to your suggestion that we need a font stack specific to the language I have compiled this patch [1]
I envision this change should enable various other possibilities in styling our content better for other languages, starting initially with font families. As stated, I think this is a really good opportunity to talk with local communities and do an audit of the best fonts per language.
The stack you suggested makes total sense to me and I've included it in that patch. We can debate it some more however and if necessary I can remove the change from the patchset - I just wanted to explain how it might work via code!
Jon [1] https://gerrit.wikimedia.org/r/125760
On Sun, Apr 13, 2014 at 7:12 AM, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Apr 12, 2014 8:58 AM, "Isarra Yos" zhorishna@gmail.com wrote:
On 11/04/14 19:30, Erwin Dokter wrote:
First, I like to aplologize to anyone who I may have come over too
passionate at some times. Frustration is known to get the better of me, even though I should control that. (I also quit smoking.)
Not sure where a new font stack should be discussed, so I'm just
throwing it in here. Also, note I propose this for Latin wikis only.
Asuming we want the 'Helvetca' look for the body font:
font-family: "Nimbus Sans L", "Helvetica Neue", Arial, Helvetica,
sans-serif;
Breakdown:
Nimbus Sans L - for Linux. This is the defacto helv font on Linux
systems which result in an look similair to Mac/Windows. Windows will not match this font, as the Windows versions of the Nimbus font packages have different font family names (ie. 'NimbusSanL' instead of 'Nimbus Sans L').
Helvetica Neue - for Mac. Like Nimbus, this should not match fonts on
Windows (or Linux for that matter), as those copies for Windows have differen font family names (like 'Helvetica Neue LT Com 55 Roman').
Arial - For Windows. Positioned after Nimbus Sans and Helvetica Neue, so
Mac and Linux do not match Arial, but positioned before Helvetica to prevent matching an inferiour Helvetica font that may be installed on some Windows machines.
Helvetica - Generic Helvetica fallback for any system not matching any
of the previous fonts.
But same as the original font stack, the question remains - for
everything but mac, what is this supposed to solve? What is the purpose of even having helvetica and arial there when they're already the defaults on their respective systems, and when on other systems they would likely be far worse than the defaults? And for linux, either they'll already be using nimbus sans (if they even have it), or it's not going to be what their renderers are optimised for.
https://www.mediawiki.org/wiki/Typography_refresh/Font_choice/Test tells me Linux now often gets DejaVu as default sans, and I understand we would rather force Nimbus if it is available as it is deemed better. Also, free font up front.
--Martijn
Every distro is different, with its own defaults and optimisations, and they are optimised based on their defaults. We should not be overriding those without very good reason.
Only one default has been explained to have legitimate problems (I
believe it was Daniel Friesen who went into this, so thank you) - helvetica on mac. Given that the fix appears to be a font that will only be present on macs in the first place, would it not be a better approach to simply address this and leave the others be?
Thus:
/* Override Helvetica default on macs to improve font legibility */ font-family: "Helvetica Neue", sans-serif;
This way it is clear what's going on in the source, ideologies are left
alone, and everyone gets the best possible experience for their platform.
I'd like to test this locally on the English Wikipedia, and I am quit
confident this makes everyone happy because 1) every OS should end up using a native font, and 2) it "promotes" a free font at the beginning of the stack (not a high priority in my book though).
Next up I may think about the headers font stack; While Georgia is a
good serif; I detest its use of text figures.
Problem with any serifs is that when using them with sans-serifs, the
different fonts need to match each other with similar ratios and weights; sans-serif, serif, or otherwise, you can't just shove any two fonts together and call it a day. Linux libertine, for instance, is very pretty, but its thickness and dimensions simply do not match the body in helvetica et al; it's much more similar to a bold verdana-style font. Georgia may have similar problems (I don't have it so I couldn't say at present), so that might be something to look into there as well.
-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 13/04/14 14:12, Martijn Hoekstra wrote:
But same as the original font stack, the question remains - for everything but mac, what is this supposed to solve? What is the purpose of even having helvetica and arial there when they're already the defaults on their respective systems, and when on other systems they would likely be far worse than the defaults? And for linux, either they'll already be using nimbus sans (if they even have it), or it's not going to be what their renderers are optimised for.
https://www.mediawiki.org/wiki/Typography_refresh/Font_choice/Test tells me Linux now often gets DejaVu as default sans, and I understand we would rather force Nimbus if it is available as it is deemed better. Also, free font up front.
--Martijn
Deemed better? Better how? But that's what I'm saying - if the configuration is optimised for dejavu sans, nimbus won't be better at all even if it is a better-engineered font (doubtful, though, it being an arial clone from what I understand). Letters will be too close together, sizes and hinting will be off, and that's not even going into the whole rabbit hole of messing with what people are used to, which seems to be the single biggest determining factor as to what they find easy to read once the basics are covered...
-I
On 15-04-2014 00:55, Isarra Yos wrote:
Deemed better? Better how? But that's what I'm saying - if the configuration is optimised for dejavu sans, nimbus won't be better at all even if it is a better-engineered font (doubtful, though, it being an arial clone from what I understand). Letters will be too close together, sizes and hinting will be off, and that's not even going into the whole rabbit hole of messing with what people are used to, which seems to be the single biggest determining factor as to what they find easy to read once the basics are covered...
The purpose of a font stack is to let the browser use the website's font preference. So "but Arial is already the default on Windows" is not a valid retort; we _want_ the browser to use Arial, even is it is _not_ the default.
Nimbus fonts come from URW++, a respected foundry, and their font are quite well engineered. They released some of their fonts under a free licence for the GhostScript project, but I do not know if the fonts are still maintained (but I suspect so, as GhostScript has active development).
It all boils down to preference. Of cource people are used to how things look, but change is not always necessarily a bad thing.
Regards,
On 14/04/14 23:49, Erwin Dokter wrote:
On 15-04-2014 00:55, Isarra Yos wrote:
Deemed better? Better how? But that's what I'm saying - if the configuration is optimised for dejavu sans, nimbus won't be better at all even if it is a better-engineered font (doubtful, though, it being an arial clone from what I understand). Letters will be too close together, sizes and hinting will be off, and that's not even going into the whole rabbit hole of messing with what people are used to, which seems to be the single biggest determining factor as to what they find easy to read once the basics are covered...
The purpose of a font stack is to let the browser use the website's font preference. So "but Arial is already the default on Windows" is not a valid retort; we _want_ the browser to use Arial, even is it is _not_ the default.
A website can prefer what it wants; that doesn't make it a good practice. I keep asking WHY 'we' prefer this particular font because there generally should be a good reason when going out of our way to avoid responsive design; doing what works best for the platform is good practice. Hence why we have an entirely separate layout for mobile, for instance, and specific apps from some of them. Different desktop platforms, too, are different.
Similarly, when people override their platform's defaults, generally they have a good reason to do so. Considering this, we should have an even better reason if we're going to go overriding those overrides - especially if this is simply back to the defaults.
Nimbus fonts come from URW++, a respected foundry, and their font are quite well engineered. They released some of their fonts under a free licence for the GhostScript project, but I do not know if the fonts are still maintained (but I suspect so, as GhostScript has active development).
It all boils down to preference. Of cource people are used to how things look, but change is not always necessarily a bad thing.
Don't dismiss preference so blithely. The psychological processes that go into determining preferences are huge; when our brains are rearranging themselves based on what we're used to, dismissing that as 'just' preferring what we're used to makes no sense. The details of particular character forms are relatively minor, of course, but like how a language a person grew up on will shape all of their future interactions with all languages, even in the short term we do come to expect letters to be a certain way.
So yes, different people prefer different things. This is good. It means we're still human.
-I
On Mon, Apr 14, 2014 at 3:55 PM, Isarra Yos zhorishna@gmail.com wrote:
Deemed better? Better how? But that's what I'm saying - if the configuration is optimised for dejavu sans, nimbus won't be better at all even if it is a better-engineered font (doubtful, though, it being an arial clone from what I understand). Letters will be too close together, sizes and hinting will be off, and that's not even going into the whole rabbit hole of messing with what people are used to, which seems to be the single biggest determining factor as to what they find easy to read once the basics are covered...
Design involves making choices on the behalf of users. What color should these buttons be? Where should this text go? We can't design for every person's individual taste. We have to design for what we think will do the most functional good for the most people. This is why the vast majority of sites a user will visit on a regular basis do not simply leave typography up to the browser defaults. Even MediaWiki, by choosing "sans-serif" for many years, forced users who might want everything to be serif to not get that.
To be honest Isarra, the number of emails and on-wiki comments you have written with this exact same question is kind of mindblowing. You ask it every time the subject comes up, regardless of which particular font stack is under discussion or who is talking about it. No amount of detailed explanation ever seems enough for you.
On Wikitech-l, Design-l, and in the extensive documentation on mediawiki.org, people have laid out highly objective rationales for why each font and the associated type sizing, spacing, leading, and more were selected to be harmonious with each other. If your objection is not to the particular choices made, but to the fact that we're making specific design choices at all, I don't really think there's much point in talking about it more.
Steven
On 15/04/14 01:54, Steven Walling wrote:
On Mon, Apr 14, 2014 at 3:55 PM, Isarra Yos zhorishna@gmail.com wrote:
Deemed better? Better how? But that's what I'm saying - if the configuration is optimised for dejavu sans, nimbus won't be better at all even if it is a better-engineered font (doubtful, though, it being an arial clone from what I understand). Letters will be too close together, sizes and hinting will be off, and that's not even going into the whole rabbit hole of messing with what people are used to, which seems to be the single biggest determining factor as to what they find easy to read once the basics are covered...
Design involves making choices on the behalf of users. What color should these buttons be? Where should this text go? We can't design for every person's individual taste. We have to design for what we think will do the most functional good for the most people. This is why the vast majority of sites a user will visit on a regular basis do not simply leave typography up to the browser defaults. Even MediaWiki, by choosing "sans-serif" for many years, forced users who might want everything to be serif to not get that.
Just because something is common doesn't mean it's a good idea. It may well be. But it may also just be something someone did that everyone else decided to copy, rather like big hair and leg warmers.
Don't get me wrong, big hair can be awesome, but the maintenance, man, that's just killer. Looks ain't everything, and at some point you wind up just wanting your hair back.
To be honest Isarra, the number of emails and on-wiki comments you have written with this exact same question is kind of mindblowing. You ask it every time the subject comes up, regardless of which particular font stack is under discussion or who is talking about it. No amount of detailed explanation ever seems enough for you.
On Wikitech-l, Design-l, and in the extensive documentation on mediawiki.org, people have laid out highly objective rationales for why each font and the associated type sizing, spacing, leading, and more were selected to be harmonious with each other. If your objection is not to the particular choices made, but to the fact that we're making specific design choices at all, I don't really think there's much point in talking about it more.
Steven
So what is the explanation, then? What was so wrong with the defaults? Do you have any links?
-I
On 15 April 2014 05:48, Isarra Yos zhorishna@gmail.com wrote:
So what is the explanation, then? What was so wrong with the defaults? Do you have any links?
I must ask again:
Where are the user test results?
Are there any?
I've asked several times and had no response.
- d.
On Mon, Apr 14, 2014 at 6:54 PM, Steven Walling steven.walling@gmail.comwrote:
On Wikitech-l, Design-l, and in the extensive documentation on mediawiki.org, people have laid out highly objective rationales for why each font and the associated type sizing, spacing, leading, and more were selected to be harmonious with each other.
While I do not want to belittle that effort at all, I think at this stage the discussion might benefit more from data than from rationales. There was a lot of guessing about the availability and readability of certain fonts; to a large extent, this could be measured:
- you can create a font with zero-width characters, download it as a web font, set up a staging area somewhere outside the viewport, fill it with some text, set "font-family: testedFont, zeroWidthFont" on it and query the width. This is a fairly reliable way of testing for the presence of a font name (although not the font itself, since the OS might match a different font to the name - but at least it tells you which font name on the stack is matched). Do this for all the fonts in the stack, report the results (together with browser, OS and location) back with EventLogging, and you will have a good idea of how widely each font is supported, and how that correlates with OS, wiki language etc. (There are more direct methods with Flash, but the browser support for it is worse.) - the same width-measurement trick can also be used to tell apart fonts: for example if the same string has the exact same width in Helvetica and Arial, the OS is faking Helvetica. (It might be even possible to build some sort of font fingerprint by specifying all CSS properties relevant for text layout in absolute sizes, and measuring the width of a few different strings on a reference machine. This could be used to identify fonts on the user's machine, although with all the subtle differences in font display that depend on browser and OS, this might not be useful in practice.) - instead of guessing about user preferences, you could just create a simple survey which shows them the same text with two different font stacks side by side, and ask them which is more readable. This is good for making aesthetic decisions more objective, and also for catching weird issues with old machines, CJK fonts etc: you can add a comment field to the survey, and if the browser is sufficiently modern to support canvas elements, you can even save a snapshot if the rendered text; you can skim through the survey replies which are different from what you have expected, and look for display problems.
On Tue, Apr 15, 2014 at 9:59 AM, Gergo Tisza gtisza@wikimedia.org wrote:
- instead of guessing about user preferences, you could just create a
simple survey which shows them the same text with two different font stacks side by side, and ask them which is more readable. This is good for making aesthetic decisions more objective, and also for catching weird issues with old machines, CJK fonts etc: you can add a comment field to the survey, and if the browser is sufficiently modern to support canvas elements, you can even save a snapshot if the rendered text; you can skim through the survey replies which are different from what you have expected, and look for display problems.
Are you volunteering to build such a survey tool? ;-)
We don't have a powerful/easy to use/not annoying/privacy-respecting survey tool that can do side-by-side comparisons. This is why the feature was launched using Beta Features for five months first. Putting out in opt-in mode and gathering feedback via the channels we have now is the most efficient way to make a change that doesn't have a big WMF team assigned to like Multimedia or VisualEditor.
When it comes to using a survey to catch problems early and gauging preferences, a survey still very much suffers from the self-selection bias that all opt-in options have. It's just the name of the game. When you move something from opt-in to opt-out you reach a wider audience and encounter new complaints/questions/bugs.
On 15 April 2014 18:12, Steven Walling steven.walling@gmail.com wrote:
We don't have a powerful/easy to use/not annoying/privacy-respecting survey tool that can do side-by-side comparisons. This is why the feature was launched using Beta Features for five months first. Putting out in opt-in mode and gathering feedback via the channels we have now is the most efficient way to make a change that doesn't have a big WMF team assigned to like Multimedia or VisualEditor. When it comes to using a survey to catch problems early and gauging preferences, a survey still very much suffers from the self-selection bias that all opt-in options have. It's just the name of the game. When you move something from opt-in to opt-out you reach a wider audience and encounter new complaints/questions/bugs.
... so the answer to "what user testing did you do, where are the user test results" is "we didn't"?
- d.
On Tue, Apr 15, 2014 at 11:23 AM, David Gerard dgerard@gmail.com wrote:
We don't have a powerful/easy to use/not annoying/privacy-respecting
survey
tool that can do side-by-side comparisons. This is why the feature was launched using Beta Features for five months first. Putting out in opt-in mode and gathering feedback via the channels we have now is the most efficient way to make a change that doesn't have a big WMF team assigned
to
like Multimedia or VisualEditor. When it comes to using a survey to catch problems early and gauging preferences, a survey still very much suffers from the self-selection
bias
that all opt-in options have. It's just the name of the game. When you
move
something from opt-in to opt-out you reach a wider audience and encounter new complaints/questions/bugs.
... so the answer to "what user testing did you do, where are the user test results" is "we didn't"?
A survey and a user test are not the same thing. "User test" is also slightly too generic for me to understand what you're asking. Are you asking if we did scripted usability tests? Or are you asking if we ran an A/B test with users?
On Tue, 15 Apr 2014 19:12:29 +0200, Steven Walling steven.walling@gmail.com wrote:
Are you volunteering to build such a survey tool? ;-)
Is the Foundation unable/unwilling to allocate resources towards that? I mean, so far it looked like everyone is treating the typography refresh seriously :)
When it comes to using a survey to catch problems early and gauging preferences, a survey still very much suffers from the self-selection bias that all opt-in options have. It's just the name of the game. When you move something from opt-in to opt-out you reach a wider audience and encounter new complaints/questions/bugs.
How is self-selection bias relevant here? People who are not interested in taking surveys won't take the survey, of course, but I don't see how that diminishes the value of the results one might get. I quite like this idea.
On 15 April 2014 19:40, Bartosz Dziewoński matma.rex@gmail.com wrote:
On Tue, 15 Apr 2014 19:12:29 +0200, Steven Walling steven.walling@gmail.com wrote:
When it comes to using a survey to catch problems early and gauging preferences, a survey still very much suffers from the self-selection bias that all opt-in options have. It's just the name of the game. When you move something from opt-in to opt-out you reach a wider audience and encounter new complaints/questions/bugs.
How is self-selection bias relevant here? People who are not interested in taking surveys won't take the survey, of course, but I don't see how that diminishes the value of the results one might get. I quite like this idea.
Indeed. Even a user survey with a known bias is better than pure praxeology.
- d.
On Tue, Apr 15, 2014 at 7:12 PM, Steven Walling steven.walling@gmail.comwrote:
On Tue, Apr 15, 2014 at 9:59 AM, Gergo Tisza gtisza@wikimedia.org wrote:
- instead of guessing about user preferences, you could just create a
simple survey which shows them the same text with two different font stacks side by side, and ask them which is more readable. This is good for making aesthetic decisions more objective, and also for catching weird issues with old machines, CJK fonts etc: you can add a comment field to the
survey,
and if the browser is sufficiently modern to support canvas elements, you can even save a snapshot if the rendered text; you can skim through the survey replies which are different from what you have expected, and look for display problems.
Are you volunteering to build such a survey tool? ;-)
We don't have a powerful/easy to use/not annoying/privacy-respecting survey tool that can do side-by-side comparisons. This is why the feature was launched using Beta Features for five months first. Putting out in opt-in mode and gathering feedback via the channels we have now is the most efficient way to make a change that doesn't have a big WMF team assigned to like Multimedia or VisualEditor.
When it comes to using a survey to catch problems early and gauging preferences, a survey still very much suffers from the self-selection bias that all opt-in options have. It's just the name of the game. When you move something from opt-in to opt-out you reach a wider audience and encounter new complaints/questions/bugs.
What would be a good design for such a survey? Would it be a good idea to ask surveyees which scripts they regularly read, and for each of those scripts prepare a bit of text, including hard parts (combining characters and the such), style it with fontx, sans-serif, and ask questions about the qualities we are looking for?
If so, what would be the questions to ask? When I read the former tests, base questions seem to be
* How would you rate the readability of this font? very/completely unreadable - somewhat unreadable - not specifically readable or unreadable - well readable - very well readable * How would you rate the neutrality of this font? (I don't really know what this means exactly, so a different phrasing is probably better, maybe something like "do you think this font has a specific style", where less is better?) Very neutral/not a specific style at all - somewhat neutral/no of a specific style - not neutral or non neutral/not much of a specific style - somewhat non-neutral/a somewhat specific style - very non-neutral/a very specific style/you just showed me papyrus * Does this font look authoritative? Very authoritative - somewhat authoritative - neither authoritative nor non-authoritative - not very authoritative - not authoritative at all/I just told you you're showing me papyrus * Does this font seem to render correctly? yes - no
Is testing like this a road we want to go down at all? If so, is this specific format a good idea? Can we improve this idea to make it good?
I don't mind making this in the weekend if it is a good idea.
--Martijn
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Apr 15, 2014 at 10:12 AM, Steven Walling steven.walling@gmail.comwrote:
Are you volunteering to build such a survey tool? ;-)
Will see if I find the time. "Survey" probably gives the wrong idea here, it is really just an overlay with two buttons, more of an interactive A/B test. Could be probably cobbled together from GuidedTours and EventLogging.
When it comes to using a survey to catch problems early and gauging preferences, a survey still very much suffers from the self-selection bias that all opt-in options have. It's just the name of the game. When you move something from opt-in to opt-out you reach a wider audience and encounter new complaints/questions/bugs.
You can survey the opt-out audience before actually enabling any changes; that is a good way of catching those bugs without actually causing them. Of course, that point is moot now, and the refresh seemed like a simple change without the benefit of hindsight.
Still, it might be useful to run such a survey (or surveys) even now:
- Which fonts users would prefer is mostly based on educating guesses now. Complaints and bugs are much more heavily self-selected than a survey (especially a super-short one-click survey), so even though the results would still be slanted towards more active users, you would get a better picture of severity. - There is a lot of uncertainty about how widespread certain bugs are (e.g. ClearText issues); showing an affected text and asking "Does this look good to you?" is an easy way to get data about that.
On Tue, Apr 15, 2014 at 12:08 PM, Gergo Tisza gtisza@wikimedia.org wrote:
Are you volunteering to build such a survey tool? ;-)
Will see if I find the time. "Survey" probably gives the wrong idea here, it is really just an overlay with two buttons, more of an interactive A/B test. Could be probably cobbled together from GuidedTours and EventLogging.
A similar toolkit that is extremely well-designed is Polar (polarb.com), if you're looking for inspiration.
On Tue, Apr 15, 2014 at 12:55 AM, Isarra Yos zhorishna@gmail.com wrote:
On 13/04/14 14:12, Martijn Hoekstra wrote:
But same as the original font stack, the question remains - for everything
but mac, what is this supposed to solve? What is the purpose of even having helvetica and arial there when they're already the defaults on their respective systems, and when on other systems they would likely be far worse than the defaults? And for linux, either they'll already be using nimbus sans (if they even have it), or it's not going to be what their renderers are optimised for.
https://www.mediawiki.org/wiki/Typography_refresh/Font_choice/Test tells me Linux now often gets DejaVu as default sans, and I understand we would rather force Nimbus if it is available as it is deemed better. Also, free font up front.
--Martijn
Deemed better? Better how?
According to https://www.mediawiki.org/wiki/Typography_refresh/Font_choice#Body_font_eval... sans scores 0 out of 10 points for "readability, neutrality, and "authority" (does the font look like it conveys reliable information)." Apparently the font is not readable, neutral or authoritive at all, and completely unsuitable for the website. If it is in fact almost completely unreadable it seems reasonable to override it, even if it is the system default, but I have the feeling that there may be some hyperbole in that table. That said, with https://bugzilla.wikimedia.org/show_bug.cgi?id=61470 it seems a terrible idea to have Helvetica Neue in the font stack.
But that's what I'm saying - if the configuration is optimised for dejavu sans, nimbus won't be better at all even if it is a better-engineered font (doubtful, though, it being an arial clone from what I understand). Letters will be too close together, sizes and hinting will be off, and that's not even going into the whole rabbit hole of messing with what people are used to, which seems to be the single biggest determining factor as to what they find easy to read once the basics are covered...
-I
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
According to
https://www.mediawiki.org/wiki/Typography_refresh/Font_choice#Body_font_eval...
sans scores 0 out of 10 points for "readability, neutrality, and "authority" (does the font look like it conveys reliable information)." Apparently the font is not readable, neutral or authoritive at all, and completely unsuitable for the website. If it is in fact almost completely unreadable it seems reasonable to override it, even if it is
the
system default, but I have the feeling that there may be some hyperbole in that table. That said, with https://bugzilla.wikimedia.org/show_bug.cgi?id=61470 it seems a terrible idea to have Helvetica Neue in the font stack.
Really a 0? What would comic sans get?
--bawolff
On 15 April 2014 17:24, Brian Wolff bawolff@gmail.com wrote:
Really a 0? What would comic sans get?
High scores for readability! It's also well-known to be very business-friendly.
- d.
On Tue, Apr 15, 2014 at 3:47 AM, Martijn Hoekstra <martijnhoekstra@gmail.com
wrote:
According to
https://www.mediawiki.org/wiki/Typography_refresh/Font_choice#Body_font_eval... sans scores 0 out of 10 points for "readability, neutrality, and "authority" (does the font look like it conveys reliable information)." Apparently the font is not readable, neutral or authoritive at all, and completely unsuitable for the website. If it is in fact almost completely unreadable it seems reasonable to override it, even if it is the system default, but I have the feeling that there may be some hyperbole in that table.
I marked that font test page as outdated. It's not updated for the new font stack, and to be honest I don't think that just asking a random assortment of people to vote on readability is really how we should evaluate our options.
If you're designing in a vacuum, DejaVu Sans might be perfectly fine. But it was not proposed or included in our font family settings because it's a different style of sans than Helvetica (incl. Neue), Arial, Roboto (on Android), and the other fonts specified. DejaVu, as well as its predecessor Bitstream Vera, are humanist sans-serifs.[1] This style of sans has much more personality to it, which isn't necessarily desirable if we want very neutral typography. From a purely functional perspective, a more humanist sans is less readable for very large text blocks because it is less uniform in appearance between letterforms. (This is why, for instance, if you're reading these long email threads in Gmail, Google sets Arial.)
That said, with https://bugzilla.wikimedia.org/show_bug.cgi?id=61470 it seems a terrible idea to have Helvetica Neue in the font stack.
Helvetica regular also has problems in this regard. Other Mac fonts, like Lucida Grande, are worse in other ways. None of them are perfect. Hence the comments in the FAQ at mediawiki.org/wiki/Typography_refresh in answer to "Is there a perfect font that meets our readability needs in all scripts? Do we think this is it?".
Steven
1. More about this at https://en.wikipedia.org/wiki/Sans-serif#Classification
wikitech-l@lists.wikimedia.org