Talk:Typography refresh

Small fonts even smaller?
I know it's not fair to start a discussion without having seen what you did. Sorry. But your note about reducing the font size for navigational elements confuses me. I know that many users think the font used in articles (0.8em, resulting in 12.8px) is to small. There are constantly discussions about using  or   in templates and articles. Most users (at least in the German Wikipedia) agree stuff like this makes the text very hard to read and should be avoided. In addition the current font size for all navigational elements is already smaller than the main font (0.75em, resulting in 12px). Therefor my suggestion is: Don't make any fonts smaller. Make the main font a little bit bigger instead. --TMg 13:13, 6 November 2013 (UTC)


 * Readers don’t read the navigation links very much – they mainly scan or skim over them, when they look at them at all. They become familiar and don’t contain any new words. So they have very different readability requirements than running text an encyclopedia article that may present new concepts, technical language, unusual technical characters, or foreign-language text. I would say that nav links can safely be smaller than the body text. Determining a specific acceptable size would depend on designer’s judgment, and testing in different browsers and platforms, with different readers. —Michael Z. 2013-11-07 18:09 z 
 * Reducing the font size also reduces the clickable region. Links like "Watchlist", "Talk" or short usernames like mine are already very small, hard to hit with the mouse and almost impossible to hit on a touch screen. Some of the more important links were made a lot smaller recently when [ "My talk" was truncated to "Talk"] along with other truncations. Please don't make these navigational links – thousands of users click them like a million times each day – even less clickable. --TMg 10:44, 8 November 2013 (UTC)
 * Good point. This could be compensated by padding the a elements instead of using line-height, padding, and margins on the list items, essentially making the nav items fat buttons. —Michael Z. 2013-11-08 23:29 z 
 * Yes, padding would help a lot. Currently there is zero padding in most places except for the tab bar ("Page", "Discussion" and so on) a the top. --TMg 10:46, 12 November 2013 (UTC)

Georgia, OK. But Helvetica !?
''"While Georgia and Helvetica are fonts optimized for the web, we can see that body gracefully degrades to Arial because it is freely available on nearly every computer and operating system while being a screen-friendly typeface." '' Helvetica, and most of its clones like Arial or Nimbus Sans L, are not optimized for screen reading nor for the Web. Its original intent was signage which is the complete opposite of tiny sizes on screen. Its closed counters make it harder to recognize or distinguish some letters. There are much better options out there, Liberation Sans or Arimo (Croscore fonts) are already a bit better, but I’d recommend Source Sans Pro or Noto fonts (a variation of Droid Sans) both with more open and legible designs, fully optimized for screen reading and larger coverage. All these are available as web fonts, can be hosted on Wikimedia servers or are available on Google Fonts. Helvetica and its clones should only be fallbacks not first choice. Full disclosure: I work in the digital type design industry, and am a co-lead on the DejaVu Fonts project, DejaVu Sans LGC would be a possible option however it is not yet fully optimized for screen as some characters are still unhinted, DejaVu Sans is available on most Linux systems.

Georgia is optimized for screen reading (specifically with Windows 95 rendering) and is downloadable in MS Core fonts for the Web. If another option or a better fallback than 'serif' are needed, there are a few web fonts that could do and actually have a better coverage than Georgia. --Moyogo (talk) 09:35, 8 November 2013 (UTC)
 * Arial is heavily optimized for the screen. It contains a lot of hinting information most other fonts are missing. Hinting is crucial on Windows (not so much on Apple products). Same applies to Georgia – that's why I think it's a good choice. More important: People are used to Arial and Helvetica. This alone makes the fonts very readable. It doesn't really matter if the shapes are perfect. People recognize them instantly because they have seen them a million times before. --TMg 10:44, 8 November 2013 (UTC)


 * That recognition or familiarity of a screen font improve its readability sounds dubious. Any evidence? Even were it so, WikiMedia could start with a very readable typeface, rather relying on familiarity to bring a mediocre one up to middling. —Michael Z. 2013-11-09 00:26 z 


 * Yes Arial is hinted but it wasn’t originally designed to be used at small size, it is therefore not optimized for Web use as a body text font. The fonts I mentioned as better choices by their designs are hinted and work well on Windows. Yes, Georgia is a good choice, Helvetica is not, they are diametrically opposed. Georgia has wide x-height, open counters while Helvetica has short x-height and closed counters. In fact Helvetica would be better at larger sizes and Georgia is great at small sizes, see . For info on better legibility of open designs compared to closed designs see . I guess you don’t care about legibility, but neither about language support or character coverage and care more about not changing the font you’re used to, ignoring what people are telling you. --Moyogo (talk) 21:53, 8 November 2013 (UTC)


 * @MediaWiki design team: So many free-as-in-freedom typefaces designed for reading on-screen (Open Sans, Merriweather, Ubuntu, DejaVu, Liberation, etc.), and you go and choose Helvetica. If you only increased the ridiculously tiny bodytext size… Fitoschido (talk) 08:56, 10 November 2013 (UTC)
 * I can not support using any other body font than the default "sans-serif" simply because of the familiarity argument explained above. It outweighs every other argument. If you are in web typography, you know what I'm talking about. There is enough evidence out there. As said above I highly support increasing the body text size. I really wonder why this was not considered instead of making everything but the body text smaller. WMF, please explain (in the section above) why you prefer this solution over each other. --TMg 11:11, 12 November 2013 (UTC)

Black text on white, why not black text on light grey?
Pure black text on pure white is hard on the eyes in some contexts. A very light grey would be preferable, but it must not be too light either otherwise low contrast will prevent legibility. --Moyogo (talk) 10:58, 9 November 2013 (UTC)
 * Indeed… Not only the text should not be pure black, also the page’s background should not be pure white. Designers, search for this, any Smashing Magazine article will tell you. —Fitoschido (talk) 09:07, 10 November 2013 (UTC)


 * You can't use "light gray" backgrounds for a simple reason: Cheap and badly calibrated monitors. It will look ugly on many devices, like the battery is going to die or worse. Sometimes it will even look greenish. But you can use dark gray text on white. #111111 on white (example) is a good idea if the font has a reasonably size (which is currently not the case, see above). Just don't make it as worse as in the current Microsoft Office 2013. They are using #5E5E5E on white (example) in some places. This makes the interface look "smooth" – when looking at it from a designers perspective – but actually reading it hurts my eyes. --TMg 11:28, 12 November 2013 (UTC)
 * PS: [//en.wikipedia.beta.wmflabs.org/wiki/Special:Preferences#mw-prefsection-betafeatures The Beta wiki] currently uses #252525 on white (example) for the text and #555555 on white (example) for some navigational elements. On top of that the level 2 headlines look like they are smaller because Georgia is a lighter font. There is also a major problem with the navigation on the left (see the screenshot on the right). I can't help but I find the sum of these changes disturbing. Please increase all font sizes (starting with the main text) and please, please do not remove all color from all navigational elements. --TMg 12:48, 12 November 2013 (UTC)

Bugs & compatibility issues
I consider the line break issue (see the screenshot in the section above) a bug/regression as well as the missing colors on all navigational links. Readers are already complaining about the Wikipedia pages looking gray and dead. This makes it worse. --TMg 12:59, 12 November 2013 (UTC)
 * I agree that the main-navigation-sidebar linebreaks are a serious problem. All wikis will have carefully tailored the wording in their interfaces to minimize linewrap problems. (I don't understand why the smaller text is resulting in more linebreaks?) –Quiddity (talk) 21:26, 12 November 2013 (UTC)


 * I also agree that removing the color from the links in the main-navigation-sidebar and the personal toolbar, is problematic and probably needs more discussion (or at the very least a mention and some references in the Typography Update page). Links should always be easily discernible, and blue for links, and purple for visited links, (or red in the case of non-existent content, per mediawiki standard), are the universal browser standard, as endorsed by the Nielsen. We already collapse some of the subsections (on most/all wikis?), which imho is sufficient. –Quiddity (talk) 21:26, 12 November 2013 (UTC)

Chinese web
In Chinese web, sans-serif more readable. No serif--Shizhao (talk) 03:45, 8 November 2013 (UTC)

Where I can test it?
In which Wikimedia project is it possible to test this feature? --Daniele Pugliesi (talk) 07:47, 9 November 2013 (UTC)
 * Right now you can definitely test it [//en.wikipedia.beta.wmflabs.org/wiki/Special:Preferences#mw-prefsection-betafeatures on the Beta Labs replica of English Wikipedia, at en.wikipedia.beta.wmflabs.org]. Steven Walling (WMF) &bull; talk   23:13, 9 November 2013 (UTC)