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)
 * TMg so for you familiarity is more important than legibility, intended use of typeface, or character support? Does this means that Helvetica/Arial will be the Wikipedia fonts forever? How could we convince you that improvements outweighs familiarity? What’s the point of this Typography update then? Wouldn't any kind of change break familiarity? Isn’t breaking familiarity for improvements the whole point? --Moyogo (talk) 21:54, 14 November 2013 (UTC)
 * We are obviously not talking about the same thing. It's all about legibility. There is nothing more legible than a familiar font at a decent size. You may not like Arial. This doesn't make it illegible. Do you have a problem to read this right now? No? Then please explain what the problem is. The proposed font stack mainly uses fonts that are default anyway. What's the point? When became "sans-serif" a problem? At the current small font size where the letters are made of not more than 10 to 20 pixels it is way, way more important to have perfect hinting than anything else. It may become less important when all screens are 200 ppi. But today they aren't. --TMg 10:18, 15 November 2013 (UTC)
 * We are recommending sans-serif fonts. Where did you get that we have a problem with sans-serif? I already explained why Helvetica/Arial are less legible, and that other fonts are very well hinted and more legible. But for you familiarity trumps everything else, legibility [], intended use, character and language support. When I ask what the point of this "Typography update" I mean, why is this called an update if we're just keeping the same font? Don't ask people what they think if you've already made up you mind and won't change it when given arguments. --Moyogo (talk) 16:56, 15 November 2013 (UTC)
 * I find the choices problematic. print typography has almost universally used serif for text and sans-serif for headings. Serifs are I think used for text used, because the additional visual features of a letter  increase readability.  My understanding of the difference for the web is because of the limitations of digital pixels, the finer features don't come over well, especially on the formerly conventional low resolution monitors, and the   readability advantage therefore disappears or even becomes confusingly blurred. But increasingly monitors especially for handheld devices are of much higher resolution; I know I increasingly prefer serif fonts with better monitors.  I think this is a field where individuals & their needs  will differ--I use not only different default point sizes but different default fonts on my different computers, and even at different times of the day. Of course the CSS can be changed on an individual basis, but perhaps there should be a facility so this can be a easy prebuilt feature to enable quick and easy choices (I'm thinking of the analogy  of a car radio's easy choice of a variety of preset display colors--I use blue at night and amber in daylight)DGG (talk) 03:28, 19 November 2013 (UTC)

--Cappuccetta Rosa (talk) 01:28, 22 November 2013 (UTC) I think it would be better Tahoma or Calibri, are very readable. Ariel is used everywhere and it seems too boring ..... :-)

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)
 * As someone getting rapidly older, I suggest that doing anything but pure black on pure white is a mistake--to the extent either text or background is colored or even tinted it decrease accessibility especially for older people. Anyone who likes it otherwise can get the same effect by decreasing monitor contrast and brightness. I am not colour-blind, but colour always decrease readability for me except in very large font sizes--when you use colour, there are intrinsically fewer receptors in the human eye. DGG (talk) 03:28, 19 November 2013 (UTC)


 * Running text should be have a high contrast, and the common colour-blind combinations should be avoided in conveying information. That is essential readability.


 * But accessibility doesn’t mean tailoring the site for a specific reader’s needs. Particular readers may require black-on-white, white-on-black, 36px text, or something else, and all websites aren’t about to accommodate this. If your needs are unusual, find the accessibility controls on your computer or device. They let you increase text size, change contrast, eliminate colour, invert the display, or read text aloud.


 * Accessibility means making the site work well with these accessibility controls. —Michael Z. 2013-11-19 17:43 z 

Alternate proposal regarding text sizing and color
Hey all. For those not familiar with it, we have a public design mailing list, which you're welcome to join. On there, I made a proposal which so far has had support from several people.

Basically, I am in agreement with the goal to focus on page content as the first priority, but I also agree with the objections to the smaller text size and the color changes for the sidebar and personal toolbar. My proposal is that we give more focus to content by making the main content text have a larger size of 1.1em, and leave the rest of the UI (toolbars, sidebar, footer, etc.) at .8em. I think others here have said they would prefer to see us increasing base font sizes rather than making anything smaller.

In my mailing list post I attached links to screenshots of how this looks on OSX in Chrome and Firefox, and an approximation is visible via my personal CSS. Different browsers react slightly differently to this: FF looks only barely larger, while on Chrome the difference is notable. In general, I think this will improve both accessibility and still support the main goals of the typography refresh, which are to improve the visual hierarchy in a page and align with the very nice typography on mobile (m.wikipedia.org). Steven Walling (WMF) &bull; talk   00:57, 15 November 2013 (UTC)


 * I would be happy if the body text size were the browser default of 16px instead of the current 13px.


 * The browser difference might be because FF uses fractional pixels but Webkit rounds to whole pixels in sizing text. It shouldn’t be hard to make it identical in both, or at least rounded to the nearest pixel. —Michael Z. 2013-11-15 02:10 z 

Page heading descenders are truncated
In Safari/iOS 5, the descenders on the H1 page heading are clipped by the underline. This hinders readability. —Michael Z. 2013-11-20 03:42 z 

Black links are a bad idea
In the updated style many links (those in the navigation bars to the left and on the top as well as the vector tabs) are colored in black or dark gray. This is a very bad decision in my opinion, since links should always have a uniform color across a site, which is different from the text color. Blue (as it was before) is probably the best option, since people are used to it. I advise to undo the changes to coloring of navigational links. --Patrick87 (talk) 12:28, 20 November 2013 (UTC)


 * Why? These are obviously horizontal and vertical lists of navigation links. Who thinks otherwise? According to whom must all links be uniform? —Michael Z. 2013-11-21 00:45 z 
 * These are obviously horizontal and vertical lists of navigation links as soon as you're used to Wikipedia and have first analyzed the page content. For a user visiting Wikipedia rarely or even for the first time, those are lists of black text, which are not identifiable as links prior to hovering. Unnecessary steps and unnecessary obscurity for no gain at all (or what are black link actually meant to improve?)...
 * See also the section directly below, where the black links are also thematized (overlooked that when posting because the section was missing a heading). --Patrick87 (talk) 09:50, 21 November 2013 (UTC)


 * They are clearly sidebar nav menus, if you’ve used the web for an hour. Anyone who is actually seeing a web browser for the first time in their life can determine that this is a nav menu by the way it looks, by its text, and by its behaviour on mouseover in about three seconds.


 * But ten seconds later, you no longer need to be signalled that they are a nav menu. Since a significant proportion of humanity has now seen these menus five thousand times, an advantage of the black link text is that it visually de-emphasizes distracting, non-content parts of the many pages that they will be reading. —Michael Z. 2013-11-21 17:21 z 
 * Sorry, but how are blue navigational links distracting? Distracting is the fact, that content text as well as navigational elements share the same font, similar size, comparable style and identical color - making them indistinguishable when having only a short glimpse at the page. The gain is still zero in my opinion while clarity suffers from the changes. --Patrick87 (talk) 22:20, 21 November 2013 (UTC)

Split the page-content changes out from the navigation-UI changes
I like, and want to keep testing, the changes to the article/project/talk/content pages. I dislike the color and size changes to the navbar (details elsewhere on this page). Perhaps we could split this Beta Feature into two parts? –Quiddity (talk) 00:17, 22 November 2013 (UTC)

Line breaks and missing colors on navigational links
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)


 * Jakob Nielsen’s own website uses black, non-underlined links for the main navigation menu across the top, and the Popular Topics menu at the bottom, so we can see that his 9-year-old recommendations are not holy scripture. —Michael Z. 2013-11-21 17:42 z 
 * You noticed, that all the links in the left sidebar on the mentioned page are blue, with black headings, did you? --Patrick87 (talk) 22:17, 21 November 2013 (UTC)

Logo gets clipped
&#35;p-logo a has a width of 10em but the background image is 135px x 135px. This results in the logo getting clipped. Specifying a background size would possibly help with this. —The preceding unsigned comment was added by Jdlrobson (talk • contribs) 21:38, 19 November 2013‎
 * Also, different problems at various sizes:
 * If the window is more than ~985px then it looks like this (http://i.imgur.com/UaXmuF5.png), otherwise it looks like this (http://i.imgur.com/QQwnCbF.png). –Quiddity (talk) 00:01, 22 November 2013 (UTC)
 * Both issues mentioned above affect the English Wikibooks logo as well. Coupled to the linebreak issues discussed above, it does suggest the sidebar should be made a little wider. --Duplode (talk) 01:44, 22 November 2013 (UTC)

Conflicts between CSS properties
Hi,

If you navigate on arnaquâtes, you can see that the display is different with and without this beta feature. With the beta feature, the padding CSS property for the h3 elements overwrites the padding-left property inherited of the "site" module (wikt:fr:Mediawiki:Common.css, by the .titredef class), as a result the text is on the image. Is "Typography update" should be corrected or attribution styles on fr.wikt? Automatik (talk) 23:47, 21 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)


 * That site looks pretty broken. The CSS is not working at all, the site says I must log in to use Preferences, but does not accept my login. —Michael Z. 2013-11-19 01:06 z 

About Beta Features still says “This feature is now scheduled for release by November 14.” But it hasn’t been released as of Nov 14.

What is the current schedule? —Michael Z. 2013-11-14 16:23 z 

I'd also love to test it. Today is not the day? The Beta Labs link above sends me to a page with unstyled text. Also, I'm looking at the thumbnails on the beta-features opt-in page and the graphic (though faint) suggests a searchbox at the top of the screen instead of the current at the side. Is this coming?

Personally I think of all the editor engagement projects, redesign/update should be high on the list. Giving users the ability to author rich/beautiful content is a motivating force. At the moment, Wikipedia, as usefull as it it, is a just a little antiquated visually and it is a put off as a potential editor. I prefer reading it from the snippets that appear at the side of my Google searches. MarkJurgens

What is this called?
Which is the correct name, Typography Refresh or Typography Update? —Michael Z. 2013-11-14 16:25 z 
 * Agreed. To clarify: In Special:Preferences it says "Typography refresh", but everywhere else (?) it is called "Typography Update". –Quiddity (talk) 00:14, 22 November 2013 (UTC)

Browser default font-size
To make the body text the browser default font-size, put the following in your vector.css. This is changed slightly from before the refresh.

—Michael Z. 2013-11-21 03:05 z 

Include screenshots
Please include screenshots at Typography Update. --MZMcBride (talk) 00:21, 22 November 2013 (UTC)

Where are the changes documented?
I'd like to know what exactly has been changed. Is there a CSS file, or a gerrit link, or anything? I'd love to understand the changes more, and to help diagnose and fix bugs, and make my own experimental iterations (eg. removing the sidebar/UI changes, but keeping the page-content changes), but I need something to start off with. –Quiddity (talk) 00:44, 22 November 2013 (UTC)

Increase font size
After activating the article font actually got smaller than the default font. Is it a bug or something? Specs: Linux Mint 15, Firefox 25.0.1, default zoom, cache cleaned. TheVulcan (talk) 01:51, 22 November 2013 (UTC)

Subheadings
On sv-wikt we make frequent use of an H2-heading immediately followed by an H3-heading, so we've made the space between the two smaller than default.

The typography update causes that space to re-appear, since it adds a large margin-top (on e.g. H3), rather than keeping the margin-bottom (on e.g. H2).

If possible, maybe something like this should be done (if it's okay with performance):

Skalman (talk) 06:32, 22 November 2013 (UTC)