Talk:Typography refresh/Archive

What do you like about Typography Update

• Hello, I like the way section titles show a clearer hierarchy. Regards, --Daehan (talk) 10:14, 22 November 2013 (UTC)

• Nothing, thus far. I dislike reading serif fonts on the computer, and much prefer Arial. It's not graceful or fancy looking, but it's brutally effective. I also find that when you have fonts that aren't very tall, they don't stand out as much, which kind of defeats the purpose of section headers. Finally, I dislike the change to the size of the "Username Talk Preferences Beta Watchlist Contributions Log out" bar up top. It's too small now, and even with glasses corrected normal vision, it's just at the level where if it gets any smaller it will be difficult to read. Sven Manguard (talk) 03:59, 23 November 2013 (UTC)
• Nothing, the text is too small and I dislike the smaller links at the top. I disabled the setting after a few minutes. Frmorrison (talk) 19:14, 26 November 2013 (UTC)
• Nothing. Not seeing any improvements, but the different font/sizes throw me off. Disabled very quickly. What was the point of this again? Seems pointless. --Piotrus (talk) 05:16, 29 November 2013 (UTC)
• Beautiful! The headings change for the desktop improves readability (and consistency). DanielVallstrom (talk) 09:07, 3 December 2013 (UTC)
• I find it a bit unorthodox to mix families of fonts and I tend to react negatively to the lack of consistency. Codex26 December 3, 2013
• I tried for 10 seconds, than I deactivated it. I don't like it at all. I use Firefox 25.0 on Windows XP. --Daniele Pugliesi (talk) 22:12, 8 December 2013 (UTC)
• Nada, estaba mucho mejor antes del cambio. Lo peor es que la letra sea de un tamaño tan pequeño. --Tatvs (talk) 07:01, 15 December 2013 (UTC)
• Nothing. I quickly disabled it after looking at two or three pages. Too distracting. Keφr 10:06, 15 December 2013 (UTC)
• A lot. I like the rhythm of the serif headings even on Linux lacking Georgia, I like the quieter top and left nav links. There's some inconsistency to polish, but it feels good. -- S Page (WMF) (talk) 04:24, 17 December 2013 (UTC)
• I think it's rather nice and I don't see what all the fuss is about. ZX95 (talk) 06:12, 21 December 2013 (UTC)
• I tried it for 60 seconds, had a look at some different articles, then turned it off. I found the mix of serif and sans typefaces to be visually jarring. The default typeface looks much cleaner. Sandbh (talk) 22:53, 24 December 2013 (UTC)

What would you change about Typography Update

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 <small> or font-size:90% 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)

@Mzajac: This is basically a revert back to the mono book styling for the links. It might be wise to look into the original argumentation for this change in Vector. (if that has ever been captured anywhere). TheDJ (talk) 17:32, 26 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 [1]. For info on better legibility of open designs compared to closed designs see [2]. 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 [[3]], 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 ..... :-)

I don't understand why people think it is necessary to change the fonts. I think they are fine the way they are. I definitely support using sans-serif for both text and headings. I think serif fonts look old-fashioned and are just a bit harder to read than sans-serif fonts. As it is, I have to increase the size of the text to be able to read articles. Just a thought -- to allow more space for the article itself and perhaps allow all the fonts to be a bit larger, couldn't the WP information at the left be hidden, with a button one could click in order to view it? CorinneSD (talk) 23:32, 22 November 2013 (UTC)

I agree with the above comment. I am in favor of continuing to use a sans-serif for both text and headings, and think that sans-serif fonts are more straining to read on a computer. Sven Manguard (talk) 20:37, 24 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)

Navigation

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: 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

I am quite aware of these controls. Setting them to B/W removes colour in everything not just text. You may call it readability not accessibility, but it's the same thing to most people if we're talking bout vision within the normal range of variation that needs careful design, not special individualized modifications. You've decreased readability. Why should an encyclopedia want to do that? DGG (talk) 01:37, 26 November 2013 (UTC)

Regarding the sidebar links: the space is too small, and even a single word has been split on sv-wiktionary: Deltagarportal+en. Skalman (talk) 06:49, 22 November 2013 (UTC)

Links should be somehow differentiated from the rest, also in the navigations zones (maybe another mean than colours could do it, but I don't have a better idea for now). Navigation links spread over 2 lines doesn't help either. And really I don't see the purpose of smaller fonts. Klipe (talk) 18:21, 25 November 2013 (UTC)

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) • 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

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

  "According to whom must all links be uniform?" I believe the answer is one of the goals of this update: Consistency. ChrisJBenson 22:40, 30 November 2013 (UTC)

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)

Visual emphasis. Blue links are coloured blue to differentiate and draw attention to themselves by their hue, chroma, and lightness, in contrast to surrounding text. But the sidebar navigation does not benefit from this. Its nature is already evident from its elements’ size, position, and arrangement. In a visual design, any unnecessary emphasis is a distraction, and detracts from the design’s objectives.

It’s like ushers in the aisle continually whispering “hey, I’m an usher,” for the benefit of moviegoers. —Michael Z. 2013-11-23 20:50 z

• I personally don't care what color you make them, they are obviously links. My opposition to this is when I took a look, the links in the pt- toolbar were a light gray and the contrast ratio to the background was very low. On top of that, bold seems to be stripped from the ones inserted by JavaScript and the font size seems to be smaller than normal. This renders them very difficult for me to see on my laptop and I would expect near impossible to see in desktop mode on my mobile. Due to this lack of accessibility (the very thing this claims it is suppose to improve), I've disabled this beta feature for me for now. Technical 13 (talk) 12:32, 22 November 2013 (UTC)

I agree. Besides, black links on grey background just look bad. Dr. Fatman (talk) 14:18, 22 November 2013 (UTC)

The uniform black links are bad. Before I could tell if a discussion page existed (blue link) or not (red link). Now both are just black. There needs to be a distinction between "target page exists" and "target page does not exist". Now I have to click on the link to see if a discussion page exists. If a discussion link was red I did not click it becaue I already knew I won't find answers there. Now I have to try and see a create new page formular. I don't care what color you give the links (they can be black), but please make a distinction at least between "existant" and "non-existant". --2003:63:2F00:D800:98DD:D5CA:240B:868A 13:53, 22 November 2013 (UTC)

I agree with the IP, as well as with Patrick87. I also don't see a purpose to this change, from a design point of view. We shouldn't be breaking from a strongly held internet tradition without a good reason, as it does cause confusion. Sven Manguard (talk) 04:04, 23 November 2013 (UTC)

I came here myself with the same complaint 2003: just raised. I can't tell whether an article's talk page exists at a glance anymore. The blue/red needs to be restored for these, if nowhere else. Jackmcbarn (talk) 20:08, 24 November 2013 (UTC)

+1 for this. I see that non-existent talk pages still come up as red links, but having links to existing talk pages coloured black was confusing for me. I instinctively thought of black as "existence status unknown" rather than "exists". — Mr. Stradivarius ^{♪ talk ♪} 02:56, 30 November 2013 (UTC)

Really, they are still red? I have a colour/contrast weakness, I can't distinguish the Red from Black. But I could distinguish clearly Red from Blue. --2003:63:2F22:7700:B046:4CF7:167A:9593

The black links confused me to start with, and were the principal reason I turned this off, after giving it several days' trial. I think blue = link, red = deadlink, black = not a link is a usefully clear distinction and one we should stay with. JohnCD (talk) 20:30, 12 December 2013 (UTC)

Let me second this. Link colour currently conveys information, and beyond that I strongly appreciate the consistency that it provides: Links are always blue (or purple if visited). Consistency is valuable; I'd say more so than the minor chrome/content distinction that the alternative provides. Nihiltres (talk) 16:09, 13 December 2013 (UTC)

To my eye, the black links on the grey background look great. There's a clear contrast between the article content and the sidebar. For general readers and casual users, this seems preferable. But for frequent editors, the link status conveyed by color is indeed useful. I expect someone will add a setting for this for registered accounts. On the English Wikipedia I already use a similar enhancement that colors the article title according to its WikiProject classification. Ringbang (talk) 19:19, 19 December 2013 (UTC)

It's easy enough for me to tweak this for myself, yes… but I do think the blue (or red) should be used in general. I've added a comment below now that I've realized precisely what intuitively bothers me about it; a reason that I'd imagine would affect more casual users. Nihiltres (talk) 16:00, 4 January 2014 (UTC)

From a usability and accessibility standpoint, there should be an easy to spot distinction between a link and text and also between an unvisited link and a visited one. Here on the wiki, we already break that by having normal blue links and unwritten red ones. Fortunately, there is enough distinction between them in appearance and purpose, that there is a logical reason to break the rules and it actually helps make things easier to understand and navigate. Gray links for navigation is not logical. Links are for navigation. Making some even less obvious does not help anyone. Furthermore, we are looking for consistency. When the nav links are read in a screen reader (for non-sighted visitors), what are we going to do? Speak them more quietly so that they are less noticeable than the other links? They still will be read, but making them quieter just makes it more difficult for someone to hear what is being said. Likewise, making the nav links nearly impossible to see if you don't have perfect vision on a large screen doesn't make the links less noticeable--it just makes them more difficult to read for those who want to see them. Being off in a sidebar as they are, most people probably skip right past them unless they need them. Why make it even harder to access them when we do need them? Keep them standard colors--blue/violet and red. Making people have to work or struggle to use the site is a good way to make them leave and never come back. —Willscrlt ( Talk | w:en | com | b:en | meta ) 00:21, 1 January 2014 (UTC)

Having turned on the typography refresh again (briefly) I've realized exactly what about the black sidebar links bother me: the black links feel like a solid wall of text. With the blue links, the sidebar section titles are "highlighted" by being in grey, breaking up the sidebar into manageable visual chunks. With the black links, I feel like I see a wall of text with no intuitive breaks, because there's insufficient contrast between the section titles and the links. The black also de-emphasizes the lines that visually separate the sections, since in pale grey they are not as visually distinctive on the paler grey background as the black text on either side of them. I'm not a design expert, but I'm pretty sure that a feeling of a wall of links is not one that we want a design to foster. Nihiltres (talk) 16:00, 4 January 2014 (UTC)

I won't talk long, because I am no expert in web designing or anything, and moreover most of what I wanted to say have been said. I prefer blue links in the nav menu, but it might be out of habit. There is one thing that really bothers me though, it's the links to the article in other languages : they're smaller than the rest, which make them a bit hard to distinguish if there are more than, like, five or ten, and they're ugly (IMO).--Thouny (talk) 00:31, 7 January 2014 (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)

Puny light fonts do not improve readability

I don't care so much about whether the fonts are serif, sans-serif, small x-height, large x-height, whatever. But if you are going to use Helvetica and Arial, the size needs to be bigger than it is, and the text should also be black to make it clearer. Typographic improvements are good, but they are not improvements if the changes make the text less readable. I was happy to see "Typography Update," but when I tried it out, I found that the fonts were smaller and gray — not even black. This looks okay from a distance, but reading it seriously hurts my eyes when reading. And really, screen resolutions have increased over the years, yet we're still using puny font sizes? The trend over the last decade has been toward larger fonts for more readable typography, and more generous leading. Why is Wikimedia stuck in the bad old days, and (perhaps) making them even worse? Not only that, but the navigation links are even tinier. Casual readers may not use them very much, but the people who edit the wiki (and spend the most time there) use them all the time. There are steps that could be taken to improve the readability. One is to first make the navigation links a similar size to the body text. Another is to make all standard text black. The next is to make the standard small text size a bit larger (e.g. fonts at 14px for body text, 12px for navigation). Tengu800 (talk) 03:50, 24 November 2013 (UTC)

Totally agree. I found the typography update style to be grayish and very difficult to read. Actually the discussion above prompted me to switch my default "sans-serif" font in Firefox to Liberation Sans, which I find to be even a slight improvement over the previous default (Dejavu Sans). --Nanite (talk) 11:08, 29 November 2013 (UTC)

I forgot that I had enabled this feature, and couldn't understand why I was getting a headache and was having to squint to read an article. Then I noticed how tiny and fuzzy all the text was, so I thought I must have changed the zoom factor in my browser. Zooming in did help a bit, but it was still difficult to read. Then I remembered this "feature" (a "feature" is just a bug that has been promoted as a "good thing" after all). I turned it off, and I could read things again. Somewhere in the discussion above, people suggested enlarging the main text and keeping the less important stuff at the existing size. A very good idea in my opinion. Not all of us have perfect eyesight, and smaller screens can make small text completely unreadable. Better contrast by using solid black text and white or nearly white background colors helps make things much easier to read, too. Also, Helvetica Neue is a much thinner (thus lighter appearing) version of Helvetica, which makes the horizontal parts of letters disappear. It was originally designed for use in large sizes (signs, posters, etc.), but then somewhere along the line it became common to use it for body text. It's not. It wasn't designed for that purpose, and it's hard on the eyes at small sizes. At large sizes (18pt and up), it's a great font, but not for lots of text. Something like Verdana, which was specifically designed for use on screens, is what you need. Verdana is not very thrilling to look at (i.e., kind of boring), but this project is an encyclopedia, not a graphic design showcase. Give us fonts that invite visitors to spend a lot of time reading, not ones that will give them headaches and drive them away. —Willscrlt ( Talk | w:en | com | b:en | meta ) 00:29, 1 January 2014 (UTC)

Serif titles are bad design

No, seriously. Titles are even often sans serif in print. You should not be mixing serif titles with sans serif main fonts. It just looks wrong, as wrong as Cologne Blue or Modern.

And, yes, we are supposed to be all about being free. Using non-free fonts is a bad idea. The whole point of custom fonts is that you include them in the webpage itself. You can only do that with free fonts. Trlkly (talk) 04:26, 30 November 2013 (UTC)

One of the good principles of good design is consistency, and serif titles break consistency. There is no need for this as the normal text is close to the header.--Desbest (talk) 07:04, 1 December 2013 (UTC)

I partially agree with you here, but could you explain how serif fonts break consistency? They are meant to offset titles from paragraph content for better scannability. Vibhabamba (talk) 08:15, 17 December 2013 (UTC)

I was thinking the same thing. Aside from the obvious incompatibility with the rest of the site's design, serifed fonts don't provide enough of a readability benefit to justify the lack of aesthetic consistency. If we absolutely *must* use a serifed font for headers, it should be slab type as that style fits alongside sans-serifed fonts much better than the more traditional serifs. --NBMATT (talk) 08:55, 2 December 2013 (UTC)

What open source serif options do you think could work with the default sans serif body copy options that we carry? Vibhabamba (talk) 08:17, 17 December 2013 (UTC)

Sorry these serifed titles are like a visual slap in the face. Please, don't do that! -- Gymel (talk) 16:05, 2 December 2013 (UTC)

I agree. I found that serif titles with sans-serif body text grated, visually, and that was the second reason (after black links) why I have turned this off after trying it for several days. JohnCD (talk) 20:37, 12 December 2013 (UTC)

Have to agree here. It was one of the more visually disturbing aspects of the Typography Update to have blocky, squat, serif headings dividing the usual clean, simple Wikipedia design. I can see that the idea might have been to try and bring something of the typography of the Wikipedia logo into the page design, but it is crude and inelegant. If a little more visual flourish is desired then why not think about something like Trebuchet? The tapered lines and double story lowercase 'g' give it a bit of a lift compared to most sans-serif, while keeping the clean lines of the format. The inclined stems of the capital 'W' also give it a little of the Wikipedia feel. Just a thought. Pyrope (talk) 18:03, 19 December 2013 (UTC)

There have been many studies (which I haven't looked up in quite a while) that show serifs increase readability, especially in small text. The little "flags" and "feet" on the letters help to make them more recognizable to the reader's eyes, thus increasing reading speed and ease. Headlines, usually being in a larger size and often a bolder weight, or perhaps in italics, do not need to be as easily readable, since they are not so tiny. To make the headings serif and the body text sans-serif (and a very thin one at that) is just backwards of the way things should be done to make this a highly readable encyclopedia. There's a reason why traditional encyclopedias, newspapers, textbooks, novels, and nearly all other large works full of text follow that basic rule: it provides the best experience for the reader and helps them to read better. There are many reasons that Web and graphic designers break those rules, but usually it comes down to wanting to look "fresh" or "modern" or "innovative". That's fine for posters or a :30 commercial. However, it's not something you want to slog through while reading a challenging article full of facts and figures. Another issue specifically with the Georgia typeface is that it uses Old Style Figures. That means that numbers like 3 and 5 drop below the baseline, and the numeral 6 pops up higher than most of the other letters. If you're writing a story about 1910 London, it looks pretty cool, but if you are trying to read an article title or a heading that contains numerals in it, it's very distracting and difficult to read. For this reason, I'd recommend against Georgia as a body font, too (can you imagine trying to read a mathematics article where all the numerals "jump around" all over the page?). I agree that stylistically distinguishing between a header and body text is generally a "good thing", but pick two typefaces that are stylistically similar to one another and look well paired together. Helvetica Neue and Georgia do not pair well by any stretch of the aesthetic imagination. —Willscrlt ( Talk | w:en | com | b:en | meta ) 00:40, 1 January 2014 (UTC)

Chinese web

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

Quotes Font Size

The most urgent element that needs to be fixed in my opinion is the completely unproportional size of quotes in the general text. Not only is the font itself unnecessarily large, it also includes a gigantic margin that interferes with the text's natural flow. --InbalabnI (talk) 15:12, 22 November 2013 (UTC)

That is very valuable input, thank you for this. We certainly need to look into balancing the whitespace more. Vibhabamba (talk) 08:18, 17 December 2013 (UTC)

You mean quotes, i.e. quoted text, or quotation marks? Can you link to an example? —Michael Z. 2013-11-22 19:34 z

@InbalabnI: Ditto what Michael asks. I've tried looking through all the Enwiki quote-templates but I can't see any unproportional changes. Perhaps your home wiki's (Hebrew) templates are using custom-style-code that conflicts with the Typography Update? Examples almost always help! :) –Quiddity (talk) 19:46, 23 November 2013 (UTC)

On serif vs. sans and their possible combinations

Printing the headers in serif and the actual paragraphs in sans seems wrong to me. I would prefer it the other way round, as it is done in most books, journals, newspapers — and for good reason: While the heading is clearly readable in its own self due to its larger size, sans is appropriate. However, it should be at least possible to switch from sans to serif for the article's paragraphs, since multiple lines of text are just better legible when printed with serifs. Since resolutions are ever-increasing, nowadays I find serif to be a valid way to display text on web pages.

Maybe you would consider this as an option? --91.63.211.73 18:00, 9 December 2013 (UTC)

I am from the old school that Helvetica headings and Times body text is natural and true. Although the consensus in younger generations brought up with screen reading as their primary test interface seems to be sand is best. The way screen fonts have evolved from the compromise between poor screen resolution and dot matrix printers to more effective wysywig, suggests a logic that what we currently take as normal and good, is not necessarily so. This trial could be an opportunity to test the idea, perhaps even robotically if time taken to read and/or edit pages in the different styles can be measured in some way.Garyvines (talk) 21:14, 11 December 2013 (UTC)

I totally agree with you – for printed material. A printed text is read best with serif fonts. On computer displays with limited resolution sans-serif fonts are the way to go, though. They're just much more readable. --Patrick87 (talk) 22:30, 11 December 2013 (UTC)

As mentioned before, I'm not sure mixing serif and sans-serif in the main body is a good idea. While sans-serif is fine, IMO, for all the navigational links and interface, I think serif would be better for the body of the article, but probably also titles and captions. --OlivierMehani (talk) 08:50, 15 December 2013 (UTC)

I absolutely loathe the mixing of serif and sans-serif as it's done in the typography refresh. My objection isn't merely aesthetic — I feel the conflicting styles break the "cohesiveness" of the content. In the Wikipedia style, headings are frequently repeated in the body content below. This occurs at the top of every article, as well as in many sections, especially those that were created from an article merge. When the body content is set in a font similar to the heading, that repetition automatically connects for the reader; it's subconsciously "noticed" without interrupting the flow of reading. With the new, clashing typefaces, the association between the repeated term and the heading is less fluid, and the reader can be jarred into consciously observing and resolving the dissimilarity. It's subtle, and it certainly doesn't occur all the time or for everyone, but it's one of the factors behind the Conventional Wisdom™ that serif and sans-serif typefaces shouldn't be mixed.

My personal preference for online content is sans-serif using a high-quality, well-hinted font designed and intended specifically for screen display. But I'd be more in favor of all-serif, if it came down to it. The worst of both worlds is to mix the two. (I'm most in favor of letting the user decide and respecting their local browser settings on the matter, but I realize in the Web 2.0 world that opinion sounds like I just stepped out of a time machine from 1993.) --FeRD_NYC (talk) 09:04, 16 December 2013 (UTC)

As I mentioned above, it breaks good readability by doing the way the refresh has currently chosen to implement the typefaces. I agree with FeRD, that the mixing of the two styles breaks the cohesiveness that Wikipedia has enjoyed for many years. While it's not a "sexy" layout, the existing style is easy to read and very cohesive. It's almost iconic for an online encyclopedia. Does that mean it can't be changed? Of course not. We can always create a new look that becomes a standard, but it should be done with care and not just by picking almost randomly from some list of popular computer fonts. Go back to the basics of good typography. If you haven't taken studied courses in typography, then seek out those who have, and get them to help out. Don't just try to "wing it", or you will end up with something that looks like, well, like you winged it. The current proposal looks like a poorly cobbled together collection of good intentions trying to solve some perceived problems, but really just messes up the good bits and introduces more problems. All serif could work nicely. All sans-serif (as we currently use) also works quite nicely. A sans-serif heading and a serif body using two well-coordinating typefaces also could work quite nicely. A serif heading and a sans-serif body text really doesn't work well. It is common to see that simply because Microsoft Office made it an easy default, but just because Microsoft got it wrong and made it common doesn't mean we have to emulate their bad decisions. —Willscrlt ( Talk | w:en | com | b:en | meta ) 00:50, 1 January 2014 (UTC)

Consistency polish

Firefox on Ubuntu:

• The fonts are too small. Without the Typography Update they're right on the edge of being OK size, but with it enabled I have to Ctrl-+ zoom once.
• The pure black on white links in the left-hand nav are too stark and grate with the #555 gray h3 expand/contract navigation headings. And they don't match the tabs across the top: current tab is #333, other tabs and the row of user links above that are #555. I would make the left-hand nav links #333 or even #444
• I like the serif headings, but
  • The sans-serif [edit | edit source ] next to them grates. There have been various experiments to make these a rollover (e.g. http://unicorn.wmflabs.org/navmod/ ) or a pencil icon.
  • The h2 in the TOC box shouldn't be serif; there are probably other semantic headings that should not be serif.
• Left-hand nav issues
  • As someone else remarked, on mw.org the mediawiki logo is clipped in the left-hand nav. The box model sets width to 10em (becomes 118px), but the logo is 135px
  • The .mw-panel for the left-hand nav is much narrower than the gray column it's in, it wastes a lot of space on the right. If you really want it this narrow, make the div#content's margin-left 10em to give the content more room.
  • The divider lines above the left-hand nav's h3 headings have hard right edges instead of fading out as they did before.

-- S Page (WMF) (talk) 05:36, 17 December 2013 (UTC)

Regarding "I would make the left-hand nav links #333": Don't! If you care about consistency, the top navigational links should be colored black, not the other way round. Dark gray text on light gray background is a very bad idea. Actually the missing contrast on top navigational links in combination with the small font size already givers me an headache. For the vector tabs it's worst, because of the light blue background and therefore further reduced contrast (those should be colored in blue/red depending on existence of the linked page anyway, as pointed out in several places already). --Patrick87 (talk) 18:52, 17 December 2013 (UTC)

Feedback on style

Hi, I really don't like serif fonts, that just will not match with any flat style layout. The left sidebar look too narrow and messy and black color for links just don't go, I was waiting a cool and bold design, not a look that seems back from nineties. I definitely do not support this change.Dianakc (talk) 01:46, 8 December 2013 (UTC)

"...to improve readability, accessibility and consistency."

The typography refresh feature is describes as, "Updates typography of the Vector skin to improve readability, accessibility and consistency."

No doubt the creators of the feature believe it "to improve readability, accessibility and consistency". But is there any evidence or heuristic to support the claim? I turned it on expecting to (somehow) do what is says on the tin. I'm now turning it off precisely to restore "readability, accessibility and consistency". From a glance at the plugin page, I don't think I'm alone in questioning it's logic or the objectivity of the claim.

Some may like it and it's there for them. But for all, can we have a more neutrally-worded description of the feature? Thanks, --Tóraí (talk) 09:36, 13 December 2013 (UTC)

Count my vote against the new look, particularly the serif fonts for headings. The headings looked smaller to me and the overall look seemed to provide less division between sections. —Ost316 (talk) 20:55, 7 January 2014 (UTC)

Bugs & compatibility issues

What browser (etc.) are you using?

Might I suggest that comments include mention of the browser the posting editor is using? (If others agree perhaps this should mentioned in an editnotice.) EEng (talk) 13:26, 29 November 2013 (UTC)

left column after typography update

Left column shows quite narrow in firefox, chrome, opera. At least in greek wiki--Kalogeropoulos (talk) 10:36, 22 November 2013 (UTC)

The same is true for the German Wikipedia and Internet Explorer. The typography update causes many links to spill over to two lines in an unacceptable way, like "Benutzerbeiträg — e" (user contributions) and "Seiteninformatio — nen" (page information), or be cut off, like "Drucken/exporti" (print/expo...) because the font is bigger. I am using Windows 8.1 and IE 11. --Momotaro (talk) 15:25, 24 November 2013 (UTC)

New typography showing even though not enabled

Like I wrote in the title, I'm seeing a different font in some places, not sure what it's called but it's something new for me. I checked now to see if I enabled it, and it looks like I haven't. Annoying part of it is that when I move my mouse over it, it changes to the normal font. Looks to me like some events change the CSS back and forth between fonts. Girondaniel (talk) 20:13, 4 December 2013 (UTC)

@Girondaniel: Are you using Chrome? There's a known bug in Chrome that's been getting worse of late which sounds like you describe. Nothing to do with Wikimedia, sadly. ;-( Jdforrester (WMF) (talk) 22:09, 4 December 2013 (UTC)

WP logo (on top left) is being scaled with part of the edges cropped

Telugu WP logo (on top left) is being scaled with part of the edges cropped on opting for Beta. Please fix this. URL for check: http://te.wikipedia.org Browser:Firefox 23.0 , Ubuntu 12.04--Arjunaraoc (talk) 12:13, 24 November 2013 (UTC)

@Arjunaraoc: This is filed as bug 57286. Matma Rex (talk) 17:58, 24 November 2013 (UTC)

@Matma Rex: Thanks. --Arjunaraoc (talk) 06:06, 29 November 2013 (UTC)

Line breaks and missing colors on navigational links

Screenshot of the sidebar at Portuguese Wikipedia after the typography refresh.

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)

You didn’t notice we were talking about “all links,” did you? —Michael Z. 2013-11-22 20:15 z

Same problem on Portuguese Wikipedia. It is important no notice that the words in other languages may be longer than their English translations. Helder 14:08, 22 November 2013 (UTC)

• On Dutch Wiki ALL menu links are just plain black text, so we can't see it's linking to something, only by navigating over those items. Further: the left menu widt is too small, so certain links are broken up over several lines... which gives a linguistic false abbreviation on those items. Pls fix: 1. link color (BLUE!!!!) 2. left column width. Regards, Tjako (talk) 00:44, 23 November 2013 (UTC)

• FWIW I'm not convinced the links in the left nav and the personal bar are the right colour, but I certainly disagree that they need to be blue - especially when it comes to navigation menus. Go to Amazon, facebook, bbc news, google, twitter, youtube.. all of thee sites have menus which do not have blue links. The most important thing with links is that they stand out from the rest of the content and you can distinguish them from other things. I agree that the line breaks need to be fixed but I'm not convinced that the link colours are as problematic as being made out. This is a interesting guide on styling links Jdlrobson (talk) 01:28, 23 November 2013 (UTC)

• Same here on the Wiktionnaire (fr.wiktionary). Vive la Rosière (talk) 18:29, 24 November 2013 (UTC)

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

The H1 has a relative font-size: 1.8333em (=26px), but an absolute line-height: 22pt (=29px). On my machine, the underline bites into the text descenders already.

If I increase my font-size by almost any method, the text will be truncated. Mixing relative and absolute sizes is bad for accessibility. Also, there doesn’t seem any point in setting overflow: hidden;. —Michael Z. 2013-11-22 20:10 z

I am experiencing the same issue in Firefox. In Chrome, the descenders are not cut off, but they touch the horizontal line. Simply eliminating line-height and letting the browser figure it out solves the problem. MrX (talk) 00:27, 24 November 2013 (UTC)

Descenders (g, q, etc.) in article titles are shaved at the bottom, cut in half, or cut off almost completely by the horizontal rule just below. How much this happens depends on the browser, zoom level, and (in IE11) text size setting. EEng (talk) 13:26, 29 November 2013 (UTC)

Line breaking

Typography refresh unnecessarily break sidebar texts at Wikimedia Commons (problem screenshot, without TR). This problem also visible at ml.wikipedia, and also wikipedia icon is slightly not visible there (problem screenshot). Interface Language: Malayalam, OS:Linux Mint 13 (Ubuntu 12.04), Browser: Firefox 24--Praveenp (talk) 04:52, 23 November 2013 (UTC)

Same here: https://dl.dropboxusercontent.com/u/22742936/wikibeta.PNG (dewiki; Firefox 24.0, Win 7). Note that "Drucken/exporti" is cut off alltogether. Pajz (talk) 13:39, 23 November 2013 (UTC)

Logo gets clipped

#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)

Same here on the Wiktionnaire (fr.wiktionary). Vive la Rosière (talk) 18:29, 24 November 2013 (UTC)

Same on my iPad: http://www.flickr.com/photos/101369746@N07/11114658825/lightbox/ Numbermaniac (talk) 10:36, 29 November 2013 (UTC)

Conflicts between CSS properties

Illustration of the problem.

Hi,

If you navigate on wikt:fr: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)

Annoying and disturbing problem. Vive la Rosière (talk) 18:23, 24 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):

h2 + h3 { margin-top: 0; }

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

Padding of h1-headings too small

The padding of h1-headings (article titles) is too small. Therefore letters are colliding with the underlining. You can alreday see what I mean on the top this page. The letters "y,p,g" are all touching the line. --Patrick87 (talk) 18:43, 24 November 2013 (UTC)

Русская версия

Принципиально пишу на русском, т. к. проблем в английской версии 100 % нет. Ширина сайдбара стала уже, а значит те бедняки, которые не имеют у себя никаких Helvetica, то они получают Arial шрифт, который решительно шире, следовательно, мы получаем замечетльные переносы типа «Спецстраниц\nы», «Загрузить\nфайл», которых ранее не было. Сам логотип слева и справа ограничен и обрезаются буквы «В» и «Я», а также слоган. Заголовки 3 уровня теперь имеют непозволительно большой отступ от основного текста или заголовка, что указан до него. --Higimo (talk) 07:47, 22 November 2013 (UTC)

• Эти ошибки я тоже вижу и они неприятны. На 1920X1080 можно найти место для нескольких букв.--Attendant (talk) 21:57, 27 November 2013 (UTC)

Order: beta feature bug?

It looks like the Typography css stylesheet is loaded after the sites own stylesheets when we use the beta. So any custom changes that were made for the sites would be overwritten by the Typography update if they change the same properties. If that is the case, then this is a bug of the beta feature and not of the Typography update style. Darkdadaah (talk) 10:01, 25 November 2013 (UTC)

Purge links on a page are inactive

I have a purge link in userboxes on my user pages in English Wikipedia and Simple English Wikipedia, and those links do not work under the Typography Update. StevenJ81 (talk) 03:46, 27 November 2013 (UTC)

Complex diacritics poorly printed

Hello, as you can see on the picture on the right, the complexe diacritics are poorly printed when Typography Update is enabled. Pamputt (talk) 06:21, 27 November 2013 (UTC)

There are fonts with similar high quality for screen that have much better character coverage, as I have mentioned before. An advantage of using open source fonts is that the community can change them to what it needs. --Moyogo (talk) 09:28, 27 November 2013 (UTC)

I also noticed the following diacritics render incorrectly with the new font stack (specifically due to Helvetica Neue):

• t͡s t͡ʃ (in sans-serif)
• t͡s t͡ʃ (in new font stack)

Kaldari (talk) 04:26, 1 December 2013 (UTC)

Typography refresh dramatically increase Wikibase items label font

Tracked in Phabricator
Task T59436

There looks like to be an issue between Wikibase and Typographic refresh beta option: Wikibase item label, in view and edit mode, looks very big when the option is activated.

Section titles on Main Page

At [4], some section heading have "jumped" out of their place (Firefox 25.0.1, Mac OSX 10.6.8). 130.225.98.240 11:21, 22 November 2013 (UTC)

Same problem with w:fr:Portail:Accueil Safari 7.0, Chrome 31.0 on OS X 10.9 Drongou (talk) 22:02, 25 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)

@Daniele Pugliesi: Right now you can definitely test it on the Beta Labs replica of English Wikipedia, at en.wikipedia.beta.wmflabs.org. Steven Walling (WMF) • 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#mw-prefsection-betafeatures 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.

/* reset font-size to browser default */

html { font-size: 1em; }
 
#bodyContent { font-size: inherit; }

/* edit fields */
 
textarea { font-size: inherit; }

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

Is there a setting that works with and without the refresh, so I do not have to go back and forth from different parts of the project? DGG (talk) 01:38, 26 November 2013 (UTC)

Include screenshots

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

Done Jdlrobson (talk) 01:28, 23 November 2013 (UTC)

Indeed (File:Typography refresh beta feature 2013-11-22 13-35.png). Thanks! :-) --MZMcBride (talk) 17:28, 2 December 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)

+1. And screenshots (before/after) would help a lot. Perhaps something interns for Google Code-In could help with? --Elitre (WMF) (talk) 16:48, 22 November 2013 (UTC)

Elitre, Quiddity The CSS is right here: https://git.wikimedia.org/tree/mediawiki%2Fcore.git/HEAD/skins%2Fvector%2Fbeta TheDJ (talk) 17:40, 26 November 2013 (UTC)

Much thanks, TheDJ. I've added a link to that (and a link to Requests for comment/LESS for anyone confused by the file extensions), on the project page. –Quiddity (talk) 18:35, 26 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)

Agreed. The personal toolbar has "font-size: 11px;" on Google Chrome 27. Helder 11:25, 22 November 2013 (UTC)

Agreed. While the reasoning above about the font sizes for navigation buttons seems OK, reducing the observable font size for the article body is a pretty bad idea. I had to increment the font size in Web browser preferences from 16 to 17 to get a similar-looking page. And I still wish it was a tad bit bigger! Melikamp (talk) 22:33, 13 December 2013 (UTC)

Comments

I enabled the typography refresh on enwiki, but have disabled it again, as I find it makes the UI less usable. While I can see the intent of the refresh, there are two major problems with it from my point of view:

• small fonts just got smaller, and are now too small to comforably read, given that the new choice of default font is not hinted/anti-aliased well on my default platform, Debian Linux 6.0: the new default font should either be chosen from the set of fonts with better anti-aliasing support across all platforms, or the current new font should have better hinting
• menu navigation links are no longer blue -- this is an important hint that something is clickable, and such a common idiom of web design that removing it is perplexing even for experienced users, and likely to make the learning curve steeper for new users

-- The Anome (talk) 12:06, 25 November 2013 (UTC)

Of the top 10 Alexa sites that I could access,[5] 5 have menu navigation links in black or grey (Google, Facebook, YouTube, Yahoo, Gmail), 2 have blue links (Baidu, Wikipedia for now), 4 have mixed links with blue prominent (QQ, LinkedIn, Amazon, Taobao), and one has blue links, but customized by users on many pages (Twitter). It looks like blue links is a fairly common idiom, but not considered mandatory by website creators or universally expected by website visitors.

Is there any evidence that making nav-bar links black or grey perplexes anyone at all? —Michael Z. 2013-11-25 17:24 z

It's not a matter of being perplexed; it's a matter of readability. The current Vector skin has mostly blue text in the left sidebar and mostly black text for the article. This contrast makes it easier for your eye to read paragraphs, because it's less likely that your eye will jump back too far at the end of a line. The proposed new skin does away with that, making the article less readable.

Unlike Google, Facebook, YouTube, etc., Wikipedia is primarily a platform for users to read vast quantities of text. The user's focus should always be drawn towards the article; everything else should look like background. Because of this, I think Wikipedia's design should not derive from those websites' designs. We ought to use black links or not solely depending on whether or not they improve Wikipedia's core focus of delivering articles to users. My judgment is that they do not. Ozob (talk) 03:14, 26 November 2013 (UTC)

I'd also put it the other way round: rather than justifying the default web-1.0 convention of blue links, those proposing changing it should be able to justify exactly how non-blue menu links would be an improvement on the status quo. If you want graphic-design-led change, you should do a root-and-branch redesign and propose radical change. If you want to do incremental change, you need to be far more cautious, lest you end up with something that is a mish-mash: neither bold and fresh, nor traditional and comfortable. If something's a material improvement with a rationale for changing it, and ideally also evidence from A/B or multivariate testing that it's more effective and better liked by users, it's definitely fine to do so: change for change's sake, particularly if the only justification for doing it is that other, commercial, sites do it, generally isn't such a good idea in my opinion. -- The Anome (talk) 10:54, 27 November 2013 (UTC)

ÄÖÜÉÈÊÂ... accents and dots over capital letters in first and second level headings are not displayed

As you can see on https://de.wikipedia.org/w/index.php?title=Wikipedia:Spielwiese&oldid=124826866 with Typography Update enabled there are the dots and accents over the capital letters in the headings missing. --Pyfisch (talk) 16:15, 25 November 2013 (UTC)

They all appear correctly, in both the headings and the page index, on Safari 6.1/Mac, Firefox 25.0.1/Mac, and Chrome 31.0.1650.57/Mac, and on Safari/iOS 5.

What browser/version/OS are you using? Do you have Georgia or DejaVu Serif fonts installed? If not, what is your browser’s default serif font? —Michael Z. 2013-11-25 17:33 z

@Pyfisch: Ditto what Michael said/asked. (Here's a screenshot from Firefox in Ubuntu http://i.imgur.com/WGggvHP.png (and a Tools->web-developer->inspector screenshot http://i.imgur.com/Z4AIKyp.png)). –Quiddity (talk) 17:58, 25 November 2013 (UTC)

• OS: Ubuntu 13.10
• Browser: 25.0.1
• Default font: serif; size 22
• DejaVu Serif is installed
• Screenshot: http://i.imgur.com/W8hlv5j.png

It looks like a font size problem to me. If I set the default size to 14 I can see the dots, but everything is too small. Regards --Pyfisch (talk) 15:34, 26 November 2013 (UTC)

Improvements for audio usage of the page ?

Slightly off topic, but still about accessibility. It seems that it would be really useful to have a mean to go quickly to the start of the main article when listening to a page (with screen readers) instead of having to go through so many navigational elements first. Something like having a very first navigational element allowing to jump directly to the title of the main content. Klipe (talk) 18:23, 25 November 2013 (UTC)

Pages are already laid out like this. The =H1= of the page title is the first content in the html body. The navigation (left-sidebar, and personal-toolbar) are at the very end, after all the page content (which means notifications are harder to access, but that's bugzilla:47993). Hope that helps. –Quiddity (talk) 00:03, 26 November 2013 (UTC)

@Quiddity What you write here sounds good to me. Is this rather recent? In a small informal report on the topic on the WP:fr "bistro" page of 25 July 2013 [6], I read (rough translation) "When one arrives on the page, the synthetic voice first reads the address of the page, then everything that appears on the page in the order in which it is written: link create an account link log on link article link talk link read link edit link history link search...". Because of the example given, I understand "the order in which it is written" as the order in which it appears on the page, at least for what concerns the navigation elements at the top of the page. Could it be that this behaviour actually depends on the reader and some would read in the HTML code order while others would read in the display order (after having taken positioning via CSS and JS into account)? Strange. Klipe (talk) 17:13, 26 November 2013 (UTC)

Klipe, I'm not sure what software was used there, but it's definitely not what the most used screen readers (JAWS, VoiceOver and NVDA) would do. They follow what is called the document order, where title and content come before navigational UI components of the website. Actually, it's one of the few areas in terms of accessibility, where we really do stuff correctly.

Now it might be that some screen readers have a mode, where you can switch between 'visual order' and 'document order' of reading the document, but that would be a different story. We ALSO have 'jumplinks' in the top of the page, just under the H1, that are only 'visible' to users with screen readers, that can quickly take them to search and the navigation sections of pages. This has been in place for a long time already (Vector and monobook, the skins that have been the default for the past 9 years or so feature this). But this is getting off scope of this page a bit. If these things interest you, I suggest discussing them on the wikitech-l mailinglist, check out the links here and/or contacting people in w:Wikipedia:WikiProject Accessibility. There aren't many people working on things like this, but there is slow progress on various accessibility issues. TheDJ (talk) 17:56, 26 November 2013 (UTC)

TheDJ, thanks for your answer. It may have been specific to that user's config. I'll discuss this elsewhere if/when I ever get to know more. Klipe (talk) 09:19, 28 November 2013 (UTC)

I can't see any apreciable difference

I can't see any apreciable difference, only better aligments in the text. What are exactly the changes? I use in my browser the Ubuntu font, so probably is that? --Jakeukalane (talk) 17:59, 27 November 2013 (UTC)

thumbs down

I tried this for a minute and reverted after just a few clicks. Smaller top navigation links, black color of links, mixed serif and sans serif, it was a mess. --Joy (talk) 20:09, 2 December 2013 (UTC)

I've got to agree with the black links issue. I'm relatively fine with the links on the side, but the talk page and history links appear almost red to me.Ryan Vesey (talk) 21:14, 2 December 2013 (UTC)

Sizing looks really bad in Wikidata

That header? That's a problem.

So I'm not a fan of Typography Update to begin with, because I think that both the use of serif fonts and the decision to change a bunch of the links to black make reading and editing harder, but it's especially bad in Wikidata. It makes the item label unreasonably large. That's a short label, and it takes up two lines. It would take up four or five lines if the label was for "Army of the Guardians of the Islamic Revolution" or "List of divisions of the People's Liberation Army". In short, please at least tone the size down significantly. (My first choice, having this not to deploy it to Wikidata, is unlikely to happen, but I figured I'd throw that out there as an option too.) Sven Manguard (talk) 22:42, 3 December 2013 (UTC)

Numbers and underscore looks bad in ja.wikipedia.org

Numbers and underscore looks bad.

ja.wikipedia.org is bad. en.wikipedia.org is OK.

Linebreaks in almost every element

After a few weeks of testing I'm still not convinced about the sidebar and personal tools color changes (the headings font change is fine with me). The most annoying thing though in my opinion and it has been named a couple of times above already is this: Due to some changes in sizing almost every single entry in the list is now broken up over two lines. That's just a show blocker period. Can we get that part fixed User:Steven (WMF) ?TheDJ (talk) 12:58, 14 December 2013 (UTC)

I can't make an executive call, but I agree this is nasty. I'll make sure it gets brought up. Steven Walling (WMF) • talk 00:20, 17 December 2013 (UTC)

Doesn't look good on my system

Typography refresh ON

Typography refresh OFF

Here are screenshots of how it looks on my system in Firefox. Some of the issues:

• Bold text is less readable because letters are too close together. (Compare the appearance of the article title link in Today's Featured Artcle.)
• Personal tools links, tabs, and sidebar links are all grey.
• Many sidebar links now include a line break.
• The layout gets adjusted considerably, beyond just the typography. The sidebar is slimmer, the top of the main content box moves up, the margins change for a lot of the layout elements within the page.
• Font on interface elements is too small.

What I like:

• Text that is not styled is somewhat easier to read quickly, with the extra line spacing, larger spaces between words, and smaller spaces between letters.

--Sage Ross (WMF) (talk) 17:04, 4 December 2013 (UTC)

Whine whine whine

If you're going to be fussing around with the skins and such to restore readability, can I have Classic back. Seriously. DragonflySixtyseven (talk) 20:25, 19 December 2013 (UTC)

The new constant width pages

They are too narrow! Please return to full browser width. --Wikitiki89 (talk) 19:27, 7 January 2014 (UTC)

Hey, this is part is in flux, and will change some shortly. I'll update this page when the latest version is released. Steven Walling (WMF) • talk 20:44, 7 January 2014 (UTC)

I can see the same problem (W7 Chrome) here and on the Polish chapter wiki (wmpl:). When Typography refresh is on, the sidebar's and header's links are blue and their space isn't smaller, as it should be. Tar Lócesilion|queta! 22:47, 7 January 2014 (UTC)