Talk:Typography refresh

Note: Thank you for all your feedback so far. Note, this page is being reviewed on a regular basis, despite the lack of responses. A second round of design is planned during which we plan to go through all these issues and concerns raised and address them all. Jdlrobson (talk) 23:01, 3 December 2013 (UTC)

Update to Typography refresh
Hi everyone,

This an update regarding the "Typography refresh" Beta feature, which is live on all wikis that have Beta Features available. The following changes will be live soon, if you don't see them already.

The first version of the typography update certainly wasn't perfect, but the UX design team wanted to get it out there and see what people thought about some of the ideas included. Well, we've recevied a ton of feedback on the Talk page.

Changes made based on your feedback
Almost all of the feedback was constructive, and some showed a really keen understanding of the issues with typography on Wikipedia. Thank you to everyone who stopped by and left a message. Based on the feedback we got, we made the following changes:


 * 1) Reverted the size of the personal toolbar menu and lefthand sidebar back its previous size (.8em)
 * 2) Reverted the black/grey links in the sidebar and personal toolbar back to blue
 * 3) Reverted the width of the left-hand back to its previous width, to avoid line breaks in those links
 * 4) Increased the body content size to 1.1em. While we did not originally increase the body content size, we saw that many people brought up this idea, and we think it's a good strategy for improving readability. This also allows us to emphasize the main content more without decreasing the size of toolbar or sidebar links, etc.
 * 5) Increased the size of page titles and their line height
 * 6) Tweaked the whitespace between section/subsection headings and around blockquotes. We hope this version provides better balance.
 * 7) Reprioritized the font family CSS for headings, placing the free and open source variant "DejaVu Serif" first

Additional ideas we're trying out in this release

 * 1) Placing a maximum width on page contents of 715px. It is widely accepted that text columns with a line length which spans the entire width of a (desktop or laptop) screen are not ideal for reading/scanning.,, , The max width will not apply to Special pages (like Prefences) or to actions on an article, like viewing history.
 * 2) Removing the border around thumbs, increasing the whitespace around them, and changing the text styling on thumbcaptions. Vector and Monobook styles are both overly reliant on border styles to demarcate page elements. Numerous borders, especially with right angles, increases cognitive load when scanning a page.
 * 3) Changing disambiguation and row links to have the same type as thumb captions.

Other things we have retained in the beta. For example, serif headings were a source of complaints, but were retained since one of the goals is consistency with the mobile skin for Wikimedia projects.

On behalf of the design team, Steven Walling (WMF) &bull; talk   23:17, 7 January 2014 (UTC)


 * Regarding maximum width: for reading text, I don't mind having a narrower column, but Wiktionary has very little body text, and on svwiktionary we put quite some content (images, links, inflections) floating on the right. Are we expected to disable the maximum width for pages in the main namespace? Skalman (talk) 12:01, 8 January 2014 (UTC)


 * FWIW, I've already disabled maximum width for the main namespace at svwiktionary. Skalman (talk) 12:44, 8 January 2014 (UTC)
 * I'm a little confused. You are penalising ALL svwiktionary users with a slightly larger CSS page load for an opt in feature that is currently only enabled by 4 users (according to the preferences page) which by the way doesn't even work... why? This is senseless.... I understand there may be problems with the feature but it would be more useful to surface those issues and discuss them than hide them. Please consider using User:Skalman.css/Vector.css instead. Jdlrobson (talk) 06:47, 9 January 2014 (UTC)


 * One of the four was complaining about it, so I thought I might as well fix it by adding 46 bytes of extra uncompressed, minified CSS. Further, I am assuming that Typography refresh will actually be enabled by default in the "near" future, and thus making the transition smoother by starting now. If we're caring this much about 46 bytes there are plenty of other improvements that should go first. Skalman (talk) 10:13, 9 January 2014 (UTC)
 * Can you please make it clear in something like a site notice (displayed to those that have the feature enabled) that you are making this change (the page width restriction)? I was just very confused by the page width suddenly shrinking so much. I've disabled this feature in my settings - I hope it is removed as it is absolutely terrible on widescreen monitors! Thanks. Mike Peel (talk) 20:04, 9 January 2014 (UTC)

What do you like about typography update?
I like the ToC change and the new image frame. Although I'd also suggest experimenting with a very light faded frame when hovering the thumbnail. TheDJ (talk) 20:55, 9 January 2014 (UTC)

Limitation of page content width needs some more thought
While I like the idea of a limited content width (actually I never maximize my browser window horizontally for this very reason) I think a potential implementation on Wikipedia would need much more work than is done in this iteration of typography refresh. Some issues that directly come to my mind: --Patrick87 (talk) 00:59, 8 January 2014 (UTC)
 * While the page content's width is limited all other UI elements use all available horizontal space (e.g. navigational links at the top). This doesn't look right and makes the actual content look needlessly squeezed to the left.
 * Pages with navigational templates or floating images as well as informational templates often look squished.
 * File description pages also look wrong with the image not being influenced by the width restriction and often being much wider than the rest of the page content.
 * Jaredzimmerman (WMF) (talk) 07:58, 9 January 2014 (UTC)
 * Patrick87, can you update with some specific links so we can make sure we're all on the same…page, as to which pages we're talking about. I've also added a section below for cataloging special pages with issues due to the fixed measure.


 * I agree with Patrick and would add that category pages should not have the maximum width either, since they are displayed in columns.
 * Why is the max width specified in pixels, not ems? Ems would seem to make more sense to me for this kind of thing. This, that and the other (talk) 10:40, 8 January 2014 (UTC)


 * Jaredzimmerman (WMF) (talk) 07:51, 9 January 2014 (UTC)
 * I played around with using ems for the width, the problem with that is that different languages use different base em sizes to properly scale their type. So, if we base the width on ems (about 53em) the page width could change a lot per language, and since one of the main points of this beta feature is consistency both with mobile and across projects, that wouldn't work out so well.


 * Thanks guys this is really useful feedback. Jdlrobson (talk) 06:48, 9 January 2014 (UTC)

Default system fonts should be given preference over free fonts (especially on Windows)
I'm running Windows 7 and use Firefox. By chance (mainly to create SVGs for Commons) I have the fonts "Liberation Sans" and "DejaVu Serif" installed on my system. After the update to typography refresh those free fonts are used throughout the page instead of the default system fonts normally expected on Windows ("Arial" and "Georgia"). This results not only in an inconsistent look compared to other pages but more importantly to badly readable text due to bad font rendering which is caused because of insufficient hinting of those free fonts (basically the same problem that came up with the Autonym font). The code should be changed to always prefer default system fonts! --Patrick87 (talk) 00:35, 8 January 2014 (UTC)


 * I have to agree in principle, but I also understand this is next to impossible; each OS has its own system fonts and CSS cannot determin what OS is being used. I do not share Patrick's concern about Liberation Sans (or DejaVu Serif); they render quite well on my Windows PC (perhaps you should update the fonts?) One question though... If Liberation Sans is used for the body, why not use Liberation Serif for the headers? As they are basically part of the same font family, it would make more sense to combine them. On second thought, Liberation Serif is too narrow. — Edokter  ( talk ) — 14:03, 8 January 2014 (UTC)
 * I note that the font stack for the headers appears to be DejaVu Serif, then a non-free font, then the system default. While for the body it appears to be Nimbus Sans L, Liberation Sans, then some non-free fonts, then the system default. I applaud the use of free fonts over non-free fonts in this iteration. But agree with Edokter: DejaVu Sans, Nimbus Roman No9 L, and Liberation Serif exist, so why not include them too? I have no opinion on the ordering of the free fonts as long as they remain before the non-free fonts. Anomie (talk) 14:51, 8 January 2014 (UTC)
 * What the heck are you talking about? DejaVu Serif is a free font to use, reuse, and modify. Just see http://dejavu-fonts.org, including the licensing information there. Steven Walling (WMF) &bull; talk   19:15, 8 January 2014 (UTC)
 * I mis-read it too. He ment "DejaVu Serif, [then] a non-free font [Georgia], then the system default." — Edokter  ( talk ) — 21:29, 8 January 2014 (UTC)
 * Sorry, clarified. Anomie (talk) 14:32, 9 January 2014 (UTC)
 * @Edokter: Those fonts render OK, but they are considerably less readable than Arial. Therefore this change would actually be detrimental to the most important goal of typography refresh which it is actually supposed to improve: Readability.
 * @All: I assumed it would be hard to prefer system fonts while still using a customized font stack. But if no proper solution can be found we should accept that we have to stick with the specification of generic font families - normally the way to go if you don't want to force specific fonts to achieve a particular design (which will by definition never look well on all systems) but aim for maximum compatibility. In this case if default system fonts are used optimum rendering is guaranteed and a high level of readability can be assumed. At the same time people with different likings are free to change the fonts used in their browser's preferences, therefore being served with their favorites instead of a predefined list of favorites of the MediaWiki devs. --Patrick87 (talk) 21:39, 8 January 2014 (UTC)
 * The new body stack starts with Nimbus Sans L, which has issues in bold text. I would much prefer Liberation Sans as the initial font. Also, not too sure about the font-size increase to 0.875em; it is really big, no matter what font. — Edokter  ( talk ) — 14:43, 8 January 2014 (UTC)

Pages with issues due to narrower measure
Jaredzimmerman (WMF) (talk) 07:35, 9 January 2014 (UTC) There might be some page types that the narrower measure doesn't make sense as a hard limit, such as watchlist, or contributions, while we've tried to find and exclude as many of these from the typography changes as we could find, I'm sure we've missed some, if you come across pages where the measure is breaking things, list and link them here so we can take a look.

Pages where narrow measure possibly shouldn't be applied:
 * Main Page — https://en.wikipedia.org/wiki/Main_Page
 * Rationale: The design of this page is not set up for the narrow measure and become hard to read depending on where images fall


 * Administrators' noticeboard - https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard
 * The table of contents overlaps the Centralized discussion box

Pages where narrow measure isn't applied but possibly should:
 * Edit and edit preview state of pages which have narrow measure (like this talk page you're reading)
 * Rationale: even in non-visual editor workflows, its easier to understand my edits if the layout of the page resembles what it will look like in read mode.

Visual issues that may be caused by narrower measure
on https://en.wikipedia.org/wiki/United_States_Senate the template halfway down the page has weird overflow issues now https://www.dropbox.com/s/l97fccee3czxg9k/Screenshot%202014-01-09%2011.44.50.png (Mac/Chrome 32.0.1700.68 beta) Jaredzimmerman (WMF) (talk) 19:48, 9 January 2014 (UTC)
 * Caused by nowraplinks selflink class combination on the "United States Senate" header + increased font size.


 * For some reason this selector does not seem to take effect if I load with debug=true (which does give me a shitton of MF related error btw). TheDJ (talk) 20:46, 9 January 2014 (UTC)

Update to typography refresh, or refresh to typography update
What is the correct name of this project? —Michael Z. 2014-01-08 04:23 z 
 * Jaredzimmerman (WMF) (talk) 07:37, 9 January 2014 (UTC)
 * "Typography refresh" is the name of the Beta Feature

Not sure which header to put this under
Can someone please make an updated version of File:Typography refresh beta feature 2013-11-22 13-35.png? --MZMcBride (talk) 05:00, 8 January 2014 (UTC)



max-width: 715px
Today I filed 59815 because I thought the new "max-width: 715px" is a bug but I learned it is feature... It makes Wikimedia Commons nearly unusable for me, half of my (wider) screen is white now, see screenshots included in the bug.

I will wait until thursday, when this release will be deployed to the German Wikipedia for further critics. But I am sure that I do not like narrow Wikipedia pages... Raymond (talk) 16:39, 8 January 2014 (UTC)


 * ACK. Elleff Groom (talk) 21:27, 8 January 2014 (UTC)


 * I've had to uninstall. While I agree that for continuous prose (like a wikipedia article body text) a limit on width may be desirable, there are too many pages on Wikipedia and Commons where this is unhelpful. I can choose to not maximize my browser window for when I want the prose to be narrower. Too much wrapping for complex pages like watchlists and diffs. Pages with the gallery packed feature (like Flickr) were reduced to just one or two images per row. -- Colin (talk) 22:03, 8 January 2014 (UTC)

Thanks for the feedback. Out of interest could we categorise this width limit as a problem on certain types of pages e.g. file pages / pages with gallerys etc? Also would it be less of a problem if the whitespace opened up by such a change was occupied by things like infoboxes / gallery images? It would be really interesting if you could point us to examples of pages you do not think the limit works on. Maybe it's a bad idea, maybe it's a good idea that needs some polish. I'm keen for us to distinguish between the two. Jdlrobson (talk) 06:41, 9 January 2014 (UTC)
 * I think it would be a good idea to restrict the max-widths to pages in the content namespace(s) (NS0 on most wikis). But maybe not on the Main Pages? Please note: Some wikis have their Main Page in another namespace (like dewiki in the WP namespace). Your idea to occupy the whitespace by infoboxes sound interesting. Raymond (talk) 09:23, 9 January 2014 (UTC)

A couple of suggestions: Only regular paragraphs should be corralled into the maximum width. Many page features can benefit greatly from the full width of the viewport: div boxes, like the one at the top of WP:ANI; galleries; panoramic images; all tables; possibly columnar reference lists (a la enwiki and frwiki); etc. And yes, I really like the idea of pushing infoboxes and floated images into the whitespace (if it is wide enough). These things may not be possible with CSS alone, but they are still ideas. This, that and the other (talk) 12:36, 9 January 2014 (UTC)
 * This is a good idea, and we've heard it brought up before. Moving elements like images, infoboxes, etc. in to that right-hand space is not out of the question, though it's fairly complex to do well when so many of these are dependent on templates. Steven Walling (WMF) &bull;  talk   18:47, 9 January 2014 (UTC)
 * And the ToC of course. plus JS toggle might help. But to begin with, I'd go just slightly wider than this. With the font-size increase and info boxes taking up a third of the remaining space, this is just a bit too narrow for my taste atm (and I'm on a 13" laptop). TheDJ (talk) 20:27, 9 January 2014 (UTC)
 * You might already know about it, but Magnus Manske has a demo proposal of what this might look like, which I think looks good. I don't know how usable it is as currently written, though. Imo the current beta max-width look has two problems by comparison: 1) asymmetrical, with whitespace on the right but not left (and the header extends above the whitespace, making it look extra-gaping), and 2) everything pushed into a narrow column including all the flow-around boxes gives a cluttered feeling (at least to me). --Delirium (talk) 20:30, 9 January 2014 (UTC)

The 715px max width may be good for small monitors, but on most modern monitors that's just too narrow (expecially in the era of 1920x1080 and larger) interfaces. Hasteur (talk) 20:02, 9 January 2014 (UTC)

On my wide monitor, the narrow max width looks awful, and pretty much renders the typography refresh unusable for me. Please roll back that part of the update, or at least provide some css so that I can disable it myself. Thanks. —DoRD (talk) 20:45, 9 January 2014 (UTC)
 * Indeed. I find this to be ludicrously narrow, disrupting the display of tables and crushing text around infoboxes and images. I've been enjoying the typography refresh so far but this has driven me to deactivate the beta for myself. I see I am not alone in this. - Dravecky (talk) 20:59, 9 January 2014 (UTC)

Not actually sure what this is supposed to 'fix'. If people find their screens too wide to read, they will make their browser window narrower. This isn't exactly typography-related either; it is a layout change. In web design, some thing are best left to the browser. — Edokter  ( talk ) — 21:26, 9 January 2014 (UTC)

Numbers looks weird in article title
The "9" and "1" in the title at the top of the AT91SAM article looks weird. They are both shorter than then "AT" and "SAM". I'm using 64-bit Windows 7 IE11. 98.164.11.206 23:05, 8 January 2014 (UTC)
 * That's the nature of the Georgia font: it uses "old-style" digits. This is the way it is supposed to look. ABCabc 1234567890 versus Georgia: ABCabc 1234567890 This, that and the other (talk) 01:47, 9 January 2014 (UTC)
 * Yes, that's correct. We have tried to account for this by increasing the line height of titles (i.e. h1 elements) so that there is enough space to provide some balance. If anyone would like to suggest a common serif to emphasize other than Georgia, suggestions are welcome. Overall, we're aiming for a serif that conveys a serious, encyclopedic feel. Steven Walling (WMF) &bull; talk   18:45, 9 January 2014 (UTC)
 * Does Georgia (or a similar font) have the ability to specify a "lining numerals" variant? The traditional typographic practice with old-stye numerals wasn't to use them throughout, but to use both types depending on context. Old-style numerals would be used in body text, and then lining/title numerals would be used in headings and titles. --Delirium (talk) 22:09, 9 January 2014 (UTC)

Underlining Links
I’d suggest that links should be underlined with  instead of   The text-decoration cuts through the letters with descenders (g, j, y), while the border leaves enough space for them. —MRosetree (talk) 11:41, 9 January 2014 (UTC)
 * Disagree,  is the de facto method of underlining links, and is present in every major browser's default stylesheet as well as in wide use across major websites. As such, I believe users come to expect that when a link is underlined, the underline is close to the bottom of the text and will cut through those letters you mention. Pushing the underline further down would look "weird" because it is simply not seen across the major websites. -- Skiz  zerz  16:35, 9 January 2014 (UTC)

blockquote
On enwiki, blockquotes are showing in italics, and much larger than the font-size: 85% se in Common.css. Here it is not italic. "Lorem ipsum dolor" --Gadget850 (talk) 20:42, 9 January 2014 (UTC)
 * Italicised blockquotes were killed already, the change will be visible on en.wp too soonish (with wmf10 at the latest, see MediaWiki 1.23/Roadmap). Matma Rex (talk) 21:07, 9 January 2014 (UTC)

Max width / Narrow pages opt out option
As with all experiments, there is always something that might be seen as a little controversial / whacky to some users. It seems this time round the max-width is upsetting users.

If any one wants to disable the max width part of this experiment on this opt in feature, feel free to add in your Vector.css e.g. User:Jdlrobson/vector.css the following css to disable it. Please do not apply this rule somewhere stupid like MediaWiki:Common.css where you will effect all users and not allow constructive discussions around this part of the experiment to take place. Jdlrobson (talk) 21:05, 9 January 2014 (UTC)

Pages gone narrow when logged in.
Is checking this option supposed to be making all Wikipedia articels narrow (except when previewed from edit source)? I've unchecked it for now, and the pages are fine again, but how will I know when the bug is fixed? This is true for both IE9 and Firefox. It was also okay when not logged in, but...

Graham.Fountain.
 * Disabled it for now too. It looks similar to the Flow discussion style, which does not work for article space at all. - Hahnchen (talk) 21:22, 9 January 2014 (UTC)

Narrow pages: centering content
I've seen the new display of pages as narrow, which is a great thing I waited for a long time: on wide screens, it was difficult to follow lines in an article. But I would have a suggestion: display the page content at center of the screen. Indeed, on my screen, the page content only covers one half on the screen, on the left, which makes it very uncomfortable and very bad looking, with the whole right half of the screen made white.

Another way would be to display the content using two columns.

Epok (talk) 21:27, 9 January 2014 (UTC)