Talk:Typography refresh/Archive 2

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.[1], [2], [3],[4] 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) • 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)

Mike Peel, There won't be a site notice as this is a beta feature, however it is on our roadmap to have echo notifications when there are major changes to Beta Features for users who have the featured enabled. We just haven't gotten to creating that notification type yet.

Jaredzimmerman (WMF) (talk) 23:23, 9 January 2014 (UTC)

Thanks for the reply. Echo notifications would work well - I'd encourage you to consider prioritising getting those working before you make more big changes like this one. Thanks. Mike Peel (talk) 06:20, 10 January 2014 (UTC)

Mike Peel, when a column is too wide (say, more than 60 or 70 characters per line), it is harder to read. The only time I have a window open to full screen is to view a video or slide show. Still, I think the user should have a handy way to override the maximum width setting.

--71.178.95.236 23:02, 12 January 2014 (UTC)

Even if this is true, I found it extremely annoying and disorienting to have my pages shrunk to 715px. I usually just set my window width to a place where it's comfortable to read, rather than relying on someone to make the choice for me. I think that the narrow column shouldn't be implemented at all, but if it is, it should definitely be opt-out and/or should allow users to specify the width of the column. 0x0077BE [^talk/_contrib] 18:00, 12 February 2014 (UTC)

What do you like about typography update?

ToC change and the new image frame

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)

Thanks TheDJ, what do you feel would be the benefit of having a frame on images on hover? We don't want to step on the multimedia team's toes too much, as they might be planning some interactive elements for images on pages as well.

Jaredzimmerman (WMF) (talk) 23:27, 9 January 2014 (UTC)

The Egyptian pyramids of the Giza Necropolis, as seen from the air

The Egyptian pyramids of the Giza Necropolis, as seen from the air

A frame creates gives affirmative feedback that the caption and the image belong together. Actually, you are creating a frame even in this design. It's just made using a lot of whitespace towards it surroundings. The reason this needs to be 'a lot' of whitespace is because whitespace is a lot harder to notice, so in order to create a 'grouping' of image and caption within the surrounding text, you will need at least more that 2 times the amount of whitespace that is between the two elements that you want to group. The frame I am proposing wouldn't have to be much. I'm thinking something like this example, with shadow and a significant fading. An alternative is to simply use a background color perhaps TheDJ (talk) 00:40, 10 January 2014 (UTC)

You're right TheDJ, there are lots of ways to create cohesion between the image text and the image, or separate the image caption from the article body text. and this is certainly one of the ways, in this version of the Text Refresh we went with a rather large margin for the images, this was partly due to the fact that even modern browsers still can't create a nice text rag automatically. and the rough rags look bad when the margin is too small. I don't know if a large hover effect is the right way to go, since there was such an outcry from people on the rather subtle hover effects for the edit links on visual editor from last year. I think the Multimedia team will want to investigate things like mouseovers and hovers where appropriate, but your point is taken that we can push further to more clearly associate the caption text with images and further distinguish it from article body text. Jaredzimmerman (WMF) (talk) 00:50, 10 January 2014 (UTC)

Yeah, my point was, please experiment with this, I think we can do more in this area. Personally I don't like the whitespace style, but perhaps with some experimentation, you can find something that is even better. TheDJ (talk) 07:59, 10 January 2014 (UTC)

This reads like the text requirements are always leading, even in image presentation. Still, in the content area for the visual effects that are the topic here (when scanning a page not reading lines), these effects should just as well be designed & experimented starting from image-requirements. Current approach is always putting images into a text, and in the end that will show (as in: looking bad without exactly being able to point the cause). -DePiep (talk) 11:05, 13 February 2014 (UTC)

Refreshing indeed

I find this update globally refreshing for a non typo/non tech expert. I like the experiment with the thumb images. It help reducing visual clutter (boxes, boxes, boxes,...) Keep on trying.

Working on high res screens makes the 715px width limit a little bit awkward. Is there any possibility to somehow link page width or font size to screen resolution? Is the number of characters per line important for improved readability or is the absolute width?

I agree! The limited text column width just looks downright ridiculous on my family's mid-2007, 24-inch, widescreen, aluminum iMac! — RandomDSdevel (talk) 01:01, 23 February 2014 (UTC)

As others suggested, I would experiment with using the empty space for infoboxes, media or even ToC. I would also pay extra attention to formatting reference lists as they may become endless with a 715px page width (see Obama's page for ex) Afernand74 (talk) 11:03, 11 January 2014 (UTC)

Afernand74, thanks for your comments, to answer your question, yes, studies we've looked at identify 45 to 115 CPL (characters per line) to be ideal for reading long form content. The current measure of 715px gets you ~113 CPL depending on many factors, such as makeup of the line, language, etc. but gets quite close the the upper limits of what we researched was an ideal measure length. While we could link it to screen size we'd lose the benefits of staying within that 45-115 ideal CPL band.

As far as other reasons beyond readability that we went with the narrower measure, you basically read or mind, this is a Beta Feature and therefore not finished, final, or polished, we plan to experiment with moving the infobox out of the main body of text as well as plan on experimenting with other types of content that could exist to the right of the main article body, some examples we've thought of (as have you apparently) are TOC, related Commons content, Wikivoyage, Wiktionary, Wikinews, and other sister project content. Nearby (geographically) related articles, and other types of related articles or content.

This step was to lay the groundwork for people to start thinking about how we could simultaneously make the article content easy to read, as well as free up space for other types of content to help people explore, learn more, and discover content that already exists within the project but might not be as visible as we'd like it to be.

Its also easy to begin to imagine what other things could exist to the right of an article, things like Flow talk page, Content translation workflows, Draft guides for new editors, as well as others we haven't even thought of yet.

Jaredzimmerman (WMF) (talk) 00:27, 12 January 2014 (UTC)

I agree that for running text, the 715px limit is probably a good idea, and agree with putting infoboxes+images outside the main text. However, please be very careful if you consider putting other types of content there, as it may be distracting. The things you mention (talk, translation, draft) sound good, but perhaps should be collapsed by default. Otherwise I'm afraid we'll get information overload. Skalman (talk) 09:47, 12 January 2014 (UTC)

@Skalman things like translation, drafts, talk are explicit actions the user takes, however infoboxes, related commons content, and related information from sister projects like wiktionary are some of the things that we imagine being part of the default reading experience, as you rightly pointed out we will have to come up with a design that enriches the reading experience rather than distracting from it. The first piece of content in the right sidebar will be infoboxes, and if all goes well you'll see that in the next version of the Beta Feature.

Jaredzimmerman (WMF) (talk) 06:16, 20 January 2014 (UTC)

Okay, I wasn't sure that they'd require an extra click. Then it's fine. Skalman (talk) 09:19, 20 January 2014 (UTC)

Text width and font size

I like those changes. They take wikipedia up to par to modern sites. Resizeable text is a relict from the 90s, when the screens where 640 or 800 pixels wide. As some others mentioned before, we have a centuries long culture of reading and writing and should also adhere its rules when the physical medium changes. And wikipedia is all about reading and writing! I often read longer articles and used a user css before to brake the lines. Also the increased font size makes reading a lot easier, thumbs up! My criticism is found in the appropriate section below Schulu (talk) 09:57, 13 February 2014 (UTC)

Unless my browser is just freaking out, the max-width feature has been removed. I just wanted to say that that was by far my favorite feature, and that I'm probably now going to have to go back to reading with Evernote Clearly because it was removed. Please at least make it optional, as there's really no reason to ever make text wider than 120 characters. Exercisephys (talk) 02:31, 15 February 2014 (UTC)

But what about users who, like me, prefer extra-wide text? Sidebar content shouldn't take up more than about a fifth of my fully-expanded Safari window's content space, in my opinion, thank you very much! — RandomDSdevel (talk) 01:05, 23 February 2014 (UTC)

What would you change about typography update?

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:

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

--Patrick87 (talk) 00:59, 8 January 2014 (UTC)

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)

"the problem with that is that different languages use different base em sizes to properly scale their type." Could you say a bit more about what you mean by this? Do different language Wikipedias specify different font sizes in their style sheets? 86.149.168.38 00:40, 10 January 2014 (UTC)

Yes, thats exactly it, languages that use non latin scripts such as Japanese frequently change the font size to look appropriate for their character sets

Jaredzimmerman (WMF) (talk) 19:48, 10 January 2014 (UTC)

I would change two things about content width limiting. 1. I would make it slightly wider. 800px is perfect for me. 2. I would maybe center the content of the page. That would make it look better on wide screen displays. Other than that, I enjoy the update. Especially the fonts. Dr. Fatman (talk) 22:23, 11 January 2014 (UTC)

The width limiting, as it's currently implemented, seems like a step backwards. The article body is tight against the left hand side, and the right hand side is just a vast expanse of blank space. This is very unbalanced. For an example of how to do width limiting well, take a look at the recent New York Time redesign. While the text is still biased towards the left hand side, there's enough white space there to give a sense of openness. They also allow images to extend into the whitespace on the right hand side. See, for example [5] or [6]. 96.250.56.207 00:55, 16 January 2014 (UTC) (en:User:pburka)

I agree on the centering. Another difference with the NYT page is that they don't have the bar on the left that the Vector skin does. Right now, when I look at a page on my 1600x900 screen, it's pretty much a busy left half and a blank right half. It's not that the NYT has the text go further to the right; they don't, and just have a narrower column. But the whitespace is mostly symmetric and uncluttered, with no blue-ish bar, no lots of links, and a continuous top bar to give context, and something (even if not very much) on the right (the arrow thing). Among those, the main thing seems to be that the left side is blank; it makes it look more like a text column that happens to be narrow, rather than half a page.

For what it's worth, my first reaction on seeing the narrow column wasn't "Oh, that's an interesting change". It was "Huh, something on Wikipedia's bugged. Where's the bug, and how can I fix it?" The half-screen feels like something went wrong, that it was intended to be a full-width text and failed. When I tweaked it in my browser to have an additional 200px of left spacing for the body and 150 px for the title, it looked much more natural (again, I have a 1600x900 screen, so that's what those pixel changes worked for). --Generalcp702 (talk) 09:12, 25 January 2014 (UTC)

There were already so many comments against fixed width in the being-designed Flow interface. Now you intend to also limit the width of the main space!? What is this? Width should not be imposed.

Fixed width may be rather comfortable for reading long texts, but I don't think that this matches the most frequent activity of our readers. Seriously, do most people usually read encyclopaedia articles or dictionary entries from start to end? Text reading is often done in a non-linear way, like in small chunks split from each others by various other actions such as reading refs/notes (possibly looking at a linked external web page), navigating thanks to the table of contents, navigating via the browser Search/Find functionality to quickly identify parts of text relevant to the current interest focus, having a quick look (e.g. just the intro) at a linked page, fixing a typo or any other kind of edit (it's a wiki, after all), etc.

Fixed width means seeing much less info on the screen at once and therefore having to scroll much more. In non-linear "reading", fixed with is no help, only an annoyance. At the very least, this should be an option. Not just a preference for registered users but really an option available to anyone (like switching to the mobile version is available to anyone as well). Klipe (talk) 13:25, 16 January 2014 (UTC)

I agree with both you and Generalcp702 on this; it seems like a major oversight to me, and I just hate it! — RandomDSdevel (talk) 01:16, 23 February 2014 (UTC)

@Klipe as you pointed out, people tend to either read straight through, skim, or search. For each of use cases the narrow measure seems to be either more ideal or have no effect. For long form reading, the narrow measure is ideal (most studies show 45-115 CPL (characters per line, including spaces) being best, depending on character size, since we were moving from what many people were used to ~200 CPL or more on a modern laptop down to 60-80 CPL on lower resolution screens or for users with zoomed text, we targeted the higher end of the ideal measure, 115 CPL for latin scripts. For skimming, while there isn't much research on ideal line measures for skimming, we can assume that much of the same is applicable, a narrow measure aids is peoples ability to move from line to line, the need for additional scrolling is likely to be offset by the ability to better move from line to line. For the last case, search on page, I can't imagine the measure having any appreciable effect since the users search query is highlighted on-page. I'd love to have researcher do more current research on how narrow measure affects reading and comprehension with scrolled text on modern higher resolution screens. It doesn't exist yet, but I think Wikipedia could be a great test platform for doing this kind of research.

Your point about things like TOC and infobox being an issue with the narrow measure are spot on, we agree completely, and we're working on it. I'd love to flip a switch and have it all to show everyone at once, but its not how design or development works, we don't have the time or resources to do it all at once, and truthfully if the narrow measure by itself is this much of a point of contention for some users I think gradual change is more ideal anyway.

Jaredzimmerman (WMF) (talk) 06:53, 20 January 2014 (UTC)

@Jaredzimmerman (WMF): Re: For skimming, [...], we can assume that much of the same is applicable, [...] - This is the main point that many of us are concerned about.

(Note: "skimming" c/should also include the use-case of "editing", although happily the edit-window currently doesn't shrink to 715px)

Many readers and many editors of our projects (encyclopedia and otherwise) are not average. Many have studied speed-reading, and can take in 2-lines-at-a-time. We need to cater to (assist) multiprocessing polymaths, as much as everyone else. If we slow down the top-percentile, they will get frustrated.

We also have many systems of glanceable content, such as WP:SHORTCUTS, and blue links, that stand out from the bulk of the text. I'll often skim down a Village Pump page looking for (A) topics titles (B) shortcuts (C) bluelinks, (D) usernames, and only read deeply if one of those catches my eye.

I've said it elsewhere, but I'll repeat it here: I think we need options. (An "in-page toggle" is probably best: to avoid multiple diverging skins, and to allow/remind editors who choose one setting of the existence of the other.) One Size does not fit all (windows, screens, users, use-cases), and trying to force it to, will hurt the long long tail of non-average instances. HTH. –Quiddity (talk) 20:30, 20 January 2014 (UTC)

Quiddity, certainly we want an experience that is equally good for the "multiprocessing polymaths" as it is for everyone else. but that is a hard line to walk, and if the ideal case for those specific users is not the ideal case for the 90% of the users of the site then it has to be prioritized accordingly.

Jaredzimmerman (WMF) (talk) 03:41, 22 January 2014 (UTC)

Hi. You know, some books and electronic documents (PDF and Word) have a white margin reserved for photos, occasional small tables and pull quotes. Large tables and figures in the body use both body space and this margin. Body prose, however, never crosses intro this area.

It would have been nice if we had such a thing. But I don't know whether it is even possible. I mean, HTML pages like Wikipedia need to be springy. Still, I am sure I want to see diffs, image description pages, categories, my watchlist, my edit window, templates and talk pages to take full advantage of the width of the screen.

Best regards,
Codename Lisa (talk) 13:35, 28 January 2014 (UTC)

I personally agree with many of the statements here, and there are many. If you are going to force a maximum page width, the entire page should be fixed, not just the article area, and it should be centered. However, the current default width is probably too small for the majority of monitors. Even my small laptop screen is 1380px wide so a max of 1024px looks fantastic for a website (which is why it is often used). CSS media queries can be used, as I assume they already are to set the best reduction (or no reduction) for each screen size. The current settings, however, just don't look good and force users to look to the left more than is comfortable. Please see my screenshot to understand my gripe. Hazmat2 (talk) 19:20, 28 January 2014 (UTC)

Line spacing

I think that line spacing is too large. We could keep it the same as before. With this, every superfluous empty lines appear extremely large (Maybe beneficial for hilighting wrong typography?). --Gumok (talk) 19:17, 9 January 2014 (UTC)

@Gumok Thanks for the feedback, ideally your line spacing is 120-160% of your text size our computed text size is roughly 16pts (depending on the font your system used) and we settled on a leading of 1.6 ems, slightly bigger than the 145% but consistant with the mobile styles.

Jaredzimmerman (WMF) (talk) 07:03, 20 January 2014 (UTC)

Still nothing

I enabled it again, and disabled again after 30 seconds. Nimbus Sans looks awfully on my computer: the letters are blurry and crammed next to each other. Non-bold DejaVu Serif in headers looks awkwardly slim, I am tempted to say that the headers are even less readable than previously. There is a large blank space to the right of page content, and I am in no mood for fighting with style sheets to get rid of it. If I wanted webpages to take only half of my screen width, I would shrink the browser window to half of my screen width. I do not. Respect it.

This is just change for the sake of change. Keφr 16:54, 10 January 2014 (UTC)

@Keφr We changed the font stack to include free and open fonts suggested by the community but the feedback is overwhelmingly that they are not of a quality that users expect from the site. For the next revision of the typography Beta Feature we've switched back to specifying only fonts that we know are of high quality, and when those fonts are not present, relying on the users browser and OS to substitute fonts where possible. Our adjustments to the the text measure we based on best practices and research. We are firm believers in not making changes for the sake of change. We're all on the same page there.

Jaredzimmerman (WMF) (talk) 07:16, 20 January 2014 (UTC)

Choice of fonts

As much as I like the structural changes made to the layout, I have to disagree on the fonts. In a time where all major news sites are changing, and rightly so, from sans-serif (often Helvetica, Arial or Verdana) to serif (Georgia, Palatino or custom webfonts) the change to Helvetica and Arial in the paragraphs seems anachronistic. Helvetica (and its clones Nimbus Sans and Arial) was made for display ads and logos, not for running text. As a geometric grotesque the characters are to similar to each other. A better choice would be to flip the order and use Georgia as body font and Helvetica for the headlines. I made a screenshot to show the differences: http://imgur.com/cnaLtub

And for the current headlines: I feel DejaVu Serif is a bad choice because it bears little resemblance to Georgia. A better choice would be Bitstream Charter/Charis SIL, as they are libre fonts, found on almost all GNU/Linux systems and are similar to Georgia, because they were made by the same designer, Mathew Carter.

If you think you need sans-serif fonts for the sake of compatibility to the mobile layout, then use a humanist sans-serif. They are found on virtually all computers out there, on Windows there are Segoe, Calibri or Verdana, on GNU/Linux there are Bitstream Vera/DejaVu Sans, Open Sans or Ubuntu. I don't know the fonts on OS X, but i bet there are also a ton available. Schulu (talk) 11:02, 13 February 2014 (UTC)

Helvetica Neue is typically praised as being the clearest for screens, although this might not be considered 'web-friendly' yet. Agreeing with User:Schulu, I think that the article titles should be a sans-serif and body text should be serif typeface. I'm not an expert, and I don't doubt that educated opinion has influenced the current selection of fonts in the typography refresh, however it for some reason features the reverse of what I understand is generally said to be ideal for clarity and legibility. JamesDouch (talk) 22:56, 13 February 2014 (UTC)

You both neglect the fact that most users are reading on "low-res" displays where every character consist only of few pixels. While your points about readability of serif fonts are totally valid for printed texts, this is not true for text displayed on computer displays. The resolution is not high enough to nicely render the serifs, turning the advantage of serif fonts into a disadvantage. As a result serif fonts actually end up less readable than sans-serif fonts on mosts computer displays. --Patrick87 (talk) 23:05, 13 February 2014 (UTC)

About a third of the users read wikipedia from mobile devices. On these devices the screens usually have 150 ppi+. Also since Windows XP is going to be extinct in foreseeable future, there are no operating systems left that force unreadable black and white rendering on the users. With the advent of font smoothing technologies like cleartype, coretext and freetype serif fonts get perfectly readable also on low resolution screens. The screenshot above was taken on a 88 ppi display. The point is, that Helvetica has too many similar characters. Can you tell the difference between big I and small l? IlIlIlIl. Or, more common, small r, small n and small m: mrnmrnmrn. Sure, if you look closer, you can tell the difference. But that is slowing down the reading, because we don't read letter by letter, but instead word by word or even bigger parts of a sentence. If we have to look closer at certain letters reading takes more time.

As a compromise I suggested above to change the body text at least to a humanist typeface. Recently Firefox introduced Clear Sans as its default sans serif typeface on mobile devices, because of the better legibility: https://bugzilla.mozilla.org/show_bug.cgi?id=877203 Schulu (talk) 01:15, 14 February 2014 (UTC)

Even on XP ClearType is available. But even with hinting / subpixel rendering / anti aliasing enabled a normal display is not able to resolve serifs properly. As an example I struggle to read the serif text in your screenshot while I'm fine with the sans-serif text. In my opinion you need at least 150 ppi for serif fonts to work on computer displays as long as you do not want to scale up text to a level where it becomes inconvenient to read again. Most modern computer displays do not exceed 96 ppi.

As for a compromise in form of an updated sans-serif font: While this is not a bad idea, you're in principle free to chose any font you like right now. Just change the default font used for "sans-serif" text in your browser settings. This is the easiest possibility I can think of to allow everybody to achieve the best reading experience on his/her system! I don't know if you're aware, but this won't be possible anymore as soon as we specify a specific font, as pointed out above, which is bad! --Patrick87 (talk) 09:52, 14 February 2014 (UTC)

Only very few users change the default typefaces in their browser. They never bother changing them. And there still are websites, that assume the user has Arial/Helvetica and Times as default, so it is even bad for the user experience if they are changed. So for the majority wikipedia always showed up set in Helvetica or Arial. But I think we shouldn't use those fonts anymore and use typefaces that have a better readability, as I laid out above. As long as low resolution displays have a large userbase I don't mind if we use sans-serif typefaces. I can always change that in my user css. Schulu (talk) 15:58, 14 February 2014 (UTC)

Borders around blockquotes

Why did you remove the borders from the image frames and introduced them at the same time around blockquotes? That doesn't make sense at all. I think it would be better if we could just leave the quotation marks around the blockquote and otherwise just indent that paragraph and maybe use italics. Here's a comparison: http://imgur.com/qYf17IZ What do you think? Schulu (talk) 15:58, 14 February 2014 (UTC)

Bugs & compatibility issues

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 agree stronly with this, the user should be in control, we already know which font works best for our eyes, e.g. I want to read Wikipedia and all my webpages in serif fonts without even a single sans-serif anywhere and I had to uninstall typography refresh after I found out it doesn't adhere to my browser's default fonts (which are all serif). In fact I'm considering uninstalling all sans-serif fonts from my computer to force websites suffering from stylesheet fascism to load serif fonts. For centuries readers were forced to read books without control over how the text was shown and we had to bow to the typographer's preferences; why shouldn't we let webpage readers control how text is displayed on their own screens? Webpages aren't books to specify what fonts should be used to read them, the user should have control! Cogiati (talk) 14:38, 14 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)

As a user I already know which font I prefer for text (serifs) and I've set it in my browser as the default font, why should the webpage designer force me to use another font? What's wrong with allowing me to read with the font *I* have specified in my browser? Forcing a particular font upon the users is stylesheet nazism, the stylesheet designer isn't supposed to act against my preferences and my own needs. Cogiati (talk) 14:42, 14 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) • 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.

But *I*, the user, already have the fonts (serifs) I prefer to read webpages in, I already know what's good for me and what is readable to my eyes. The stylesheet designer shouldn't force a particular font upon me, she or he doesn't know what's good for me, I'm the only one who should have control over how webpages are rendered on my own screen, and I do so by adjusting my browser font settings. If typography refresh is fascist and doesn't allow me to have self-determination on my own screen, then it acts against my best interests by forcing me to read with a font I dislike. Cogiati (talk) 14:46, 14 January 2014 (UTC)

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

What's wrong with not specifying any font at all and allowing me, the user, to choose my browser default font? I already know the best font for me (serif). The stylesheet designer should respect my browser settings! Cogiati (talk) 14:49, 14 January 2014 (UTC)

I strongly agree. Forcing fonts is a bad idea, especially for Windows users. Specifying Arial explicitly defeats the purpose, since it already is the default sans-serif font in IE, Chrome, Firefox and Opera. Personally, I not only think Arial sucks due to its design failures, but I also feel offended and disrespected. Just because Google decides it is the default font for their web, it seems everyone has to be forced to use it without thinking. Verdana (for Windows purposes) is much more readable. Remember btw: Arial is non-free. Therefore: Please remove Arial from the font stack. --Sumpfchiller (talk) 05:07, 28 January 2014 (UTC)

Has anyone at Wikimedia Foundation verified that all of the free options cause the problems described? This discussion is being cited as a reason not to favor free fonts in our font ordering, going with '"Helvetica Neue", Helvetica, Arial, sans-serif'. For what it's worth, my preference would be to just stick with plain "sans-serif" until we have a good cross-platform strategy. -- RobLa-WMF (talk) 04:14, 18 February 2014 (UTC)

I also still think that a generic "sans-serif" would be the most compatible (and therefore best) option. Regarding the specific font stack that is now used: Why do you still include Arial? If we're on Windows this is the default sans-serif font anyway and on other systems Arial most likely isn't installed, so this specification doesn't make sense in my opinion. It only prevents Windows users to override the default (which they do for a reason when they do it I assume). --Patrick87 (talk) 10:21, 18 February 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 of English wikipedia — 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.

Pages where narrow measure possibly should be changed:

• Main Page of German wikinews — https://de.wikinews.org/wiki/Hauptseite

It look's quite strange, but I've tested some possibilities with FireBug and I think, the content has to be centered and the max width set to 800px or so. -- SuPich (talk) 16:16, 9 February 2014 (UTC)

• I'd like to add this situation to the list: page parts where every pixel in width counts. Think images like a world map with colored countries (like this, or panorama pictures). And think tables (like this). Images nor tables require the readability "maximum x char per line" rule.

I find it strange that the exceptions mentioned here are getting this attention right now in the development process. They are lists, non-content, full-page: definitely not the mainstream issues at all (they sh/could be solved latest). Instead, developers should be thinking about how to integrate images into a content page, together with the CPL-texts. (images: pics, tables, boxes, ...: all non-flowing text. That is both full-width and shared-width elements). -DePiep (talk) 10:38, 13 February 2014 (UTC)

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.

.nowrap, .nowraplinks a, .nowraplinks .selflink, sup.reference a {
    white-space: nowrap
}

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)

Looking forward to a mature version of the Typography Refresh

I was specifically looking for a way to not have paragraphs span across the entire width of my widescreen (16:9) monitor. I was very happy to see that the typography refresh creates easy to read columns. This is a good idea. I'm sure it's why newspapers do it on their web editions. I would like to see the column itself centered. As of now it's too far to the left when the browser is maximized, and monitors are only getting wider. 66.65.172.106 16:13, 12 January 2014 (UTC)

While we probably won't have the text centered on screen, since this doesn't really create a harmonious balance on the page, due to the right rag, we are investigating ways through this and future Beta Features to make the column of type feel more optically balanced on the page. Thanks for the feedback.

Jaredzimmerman (WMF) (talk) 07:21, 20 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 Bugzilla: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) • 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)

I really like many aspects of Magnus' demo. 2 problems that jump out: it doesn't work at all on small screens or in small windows (try reducing the window size - below 1024px width it starts to look bad), and it completely removes the option of using thumbnails larger than 220px (eg larger lead images, or wide panorama shots). Those aspects would need to be thought about in any design that utilized forcibly split-columns. –Quiddity (talk) 22:40, 9 January 2014 (UTC)

The demo is interesting, but I don't actually think it is a very pleasant layout, Having the images small and completely pulled out of the text looks very dated to me. It can be quite nice to have images break up the text, the article in the demo is not just a huge wall of grey text, I don't think that is good from a UX or visual design point of view. But it does start to get at the point of what we were experimenting with. When you have a narrower measure for your text with the larger text size it is (arguably) easier for people to read. What it also gives you is room to highlight relevant non-text content, Images, galleries, content from sister projects like wiktionary and wikisource. You could also imagine a situation where you had a two column layout with the article on one side a second functional column such as Flow for discussing the article or Translate UI for translating the article side-by-side. Try not to imagine the narrow measure as an end of itself, but as a means to an end.

Jaredzimmerman (WMF) (talk) 23:45, 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)

Agreed. I've had to disable this feature now as, frankly, having very narrow page displays is just annoying. Internet pages used to be this width, but then we all got wider, higher res screens and moved on. As Edokter says, I too don't understand what this is supposed to fix and as a result it just looks like a backwards step. Danno uk (talk) 22:52, 9 January 2014 (UTC)

As someone who isn't a fan, I can explain the logic behind all the studies that prove a narrower column-width (and larger font-sizes) lead to increased content understanding & retainment - It's a matter of eye-movement, whereby if the eyes have dozens of centimetres to travel to find the beginning of the next-line (or have to squint to read tiny type), that is a tiny increased cognitive load. It's partially why ye olde gigantic printed dictionaries and encyclopedias use multi-column layouts, and ditto for many current magazines and newspapers. The width of an average book page (paper/trade/hard) is: cost-effective to print/transport, and easy to hold/carry/store, but also easy to read with minimal effort (particularly by demographics without perfect vision or peak language fluency).

That said, I think there's a difference between reading a page in-depth, and scanning/skimming a page looking for content. I'd suggest (with no scientific evidence) that a very-wide page is preferred by many editors because we spend so much time scanning back-and-forth and up-and-down (articles/documentation) looking for sentences to re-write, and paragraphs to shuffle amongst sections, and images to align with content chunks, as well as glancing rapidly through gigantic talkpages looking for keywords or keylinks or usernames that warrant closer attention (eg, "oh look, someone mentioned category:X which interests me, I guess I'll read this thread...").

Overall, I think this is a highly-subjective point, i.e. there are legitimate rationales in each direction (both towards clarity/sparseness, and towards density/compactness). I usually prefer great-density (I want as much detail on-screen as possible. I purposefully use small fonts, on a largish monitor. If there's wasted space, I'll tile the windows so that they overlap. I often tile windows if I'm going back and forth between 2 programs/pages a lot. Etc.); but occasionally I'll use a bookmarklet to minimize everything and zoom the font in, so that I can lean back and read a site slowly and carefully. Relatedly: There's a very interesting script linked in this design mailing list post (scroll down to the screenshots, or go straight to the script/css to be pasted into your vector.js/.css), which I've installed on Enwiki, and I like having as an option, but not as my own default. I can certainly understand how some people would prefer to have it (or something like it) as their default though.

HTH. –Quiddity (talk) 22:49, 9 January 2014 (UTC)

No, this is clearly a bug. The intent, to ensure the width of the text is reasonably short and thereby improve readability, is fine. But limiting the length of the bodyContent div to a fixed pixel width is the wrong way to achieve that aim, for at least two reasons. First, this div contains things other than paragraphs of text (it includes diffs, for instance, which appear in two columns, and it includes floated content like images and sidebars, thereby reducing the actual text to less than the desired width); second, specifying the width in pixels takes no account of users different font sizes, screen or window sizes, etc.86.149.168.38 23:28, 9 January 2014 (UTC)

It doesn't take users' page zoom levels into account, either! — RandomDSdevel (talk) 21:52, 23 February 2014 (UTC)

But it's the user who should be in control and decide how wide the text should be by adjusting the browser window, the stylesheet designer shouldn't force a specific pixel width upon us! Cogiati (talk) 14:19, 14 January 2014 (UTC)

I mostly like it. As Quiddity pointed, it makes reading long articles much more pleasant. On my wide screens (1680x1050 and 1920x1080), lines were too long to be read comfortably and even long paragraphs did not span more than a few lines. But to make this update complete and really operational, non-text items should be removed from the article body and flushed to the right column ; except for tables and maybe wide pictures if they stay clear of text on both sides. Kept inline, these items just get in the way of reading. This layout would miss a way to link article text to pictures, maybe some kind of new illustration reference (like source references but pointing to illustrations on the side) could be introduced. One last point : on wide screens again, it is disturbing that the main column sticks to the left panel ; it would probably look more natural (or less disturbing) if it was centered, with white space on both sides. --EdouardHue (talk) 23:37, 9 January 2014 (UTC)

I was disappointed with this addition and had to disable the feature as a result. I wish it was an optional setting as I liked other aspects of what this feature provided. --Varnent (talk)^(COI) 05:49, 10 January 2014 (UTC)

I'm afraid to say that I've disabled the feature as well. The large amount of white space created on large monitors does not go well with the user menu in the top right, which starts to look very lonely. As for the bunched-up content, enwiki's Main Page is one of the victims - Mark Schierbecker's screenshot illustrates this well. — Mr. Stradivarius ^{♪ talk ♪} 06:10, 10 January 2014 (UTC)

I've disabled this feature. It looks *absolutely godawful* on modern widescreen monitors, wasting a high percentage of screen space. If the goal is to reduce paragraph width, the solution needs to be introducing multi-column layouts, not artificially forcing everyone's viewing back to the SVGA era Too bad. 174.236.69.160 08:14, 10 January 2014 (UTC)

I'm truly shocked somebody considered even trying the fixed page size. What is this? Back to the 90's of the Internet? I always admired Wikipedia for using responsive design much earlier than other mainstream websites, and I think it is absolutely not an option to introduce fixed-width pages in 2014. —Volgar (talk) 09:39, 10 January 2014 (UTC)

Agreed. I also had to disable this feature as well (after I had found out that this was actually not a bug – I thought something with my vector.css was broken). While in Wikipedia articles I could imagine that some people would find it helpful to have not too long rows (but these people can just adjust their browser window as mentioned above), in longer discussions, on pages with large tables, on image description pages etc. this is just VERY bothering. And yes, why would you dictate people with wide screens that they have to use a fixed width and have half of their screen left blank? Please undo. Yellowcard (talk) 10:38, 10 January 2014 (UTC)

I actually like it, as you can browse in a full screen window and still have reasonable short lines, but the I have to agree with 86.149.168.38 that the current solution isn't optimal. I tried

.action-view #bodyContent p {
 max-width: 50em;
}

instead, which looks good (though I didn't test it on many pages). --Schnark (talk) 10:41, 10 January 2014 (UTC)

Why the heck would I want Wikipedia to not make use of my whole screen? I hate the idea and have gone ahead and inserted the code posted in a lower conversation into my vector.css page to remove the width limit. I really like the other features that were added at the same time (change in typography in article text, removal of borders around pictures) but it seems pointless not making full use of the whole screen - especially since Wikipedia automatically adjusts to the width of your browser/screen anyway. Jr8825 (talk) 11:17, 10 January 2014 (UTC)

And a few afterthoughts: If the purpose is to make it easier to read, why not develop a reading button (along the top pane along with 'view history' and 'edit' etc.) which turns the page into columns or moves pictures to the side? That way people can choose to use it, it is easily to enable and it doesn't force itself upon anyone. I don't like the idea of just reducing everything into one single column, if people are moving towards fixed-width columns couldn't a feature be developed that fits two or three columns into the page depending on the screen resolution/width? Therefore it's still smart and fills up the screen but it also make it easier to read. Jr8825 (talk) 11:25, 10 January 2014 (UTC)

You state accessibility as one of your goals and you stress that visual impairments must not get in the way of access. I'm afraid that a fixed maximal width that is measured in pixels works against this goal. Some visual impaired people (like me) work with big screens and huge fonts, i.e. they scale everything up. This works very nicely as long as I do not run into fixed pixel measurements. There is also another point. In the time of CRTs the pixel densities of the monitors didn't vary much but today we have to work with an extreme range of pixel densities of which many would not work well with a fixed pixel width optimized for some commonplace monitor configuration. In summary, if you want to set any width limit at all, do it in ems, not in pixels. If this is found necessary, reasonable values should be at least 60 or 70 ems. But I think that this should be better kept easily configurable because it depends on so many factors (reading distance, for example) which cannot be generalized. --AFBorchert (talk) 12:46, 10 January 2014 (UTC)

This is a great discussion of the problems that limiting the width of MediaWiki wikis' content columns brings into existence, and I agree with you whole-heartedly, especially since I always hit ⌘-+ twice when viewing wiki content. — RandomDSdevel (talk) 22:09, 23 February 2014 (UTC)

715px is too narrow. I think 900px would be OK.--Portal3046 (talk) 05:18, 11 January 2014 (UTC)

I disabled the feature because I like to use the full width of my screen. It's a pity since I liked the other improvements especially the increased difference between the section and sub-section headings. Would it be possible for each reader to decide in its preferences the width he likes ? With, of course, an option for "full screen width" ? Thank you.--AnTeaX (talk) 11:09, 11 January 2014 (UTC)

I disabled the feature because of the very narrow width, too. This is no improvement. --Cepheiden (talk) 20:58, 12 January 2014 (UTC)

I am chiming in to object to this as well. I don't think it looks good in articles, but it's especially bad outside of the mainspace. Crimping to that width makes the entire Portal namespace look just awful. Most portals use a two column format (like the main page does). When I review portals for Featured Portal status, I look to make sure that the portal looks good in what I consider "low-width" resolutions, like 1024×[whatever], 1280×[whatever], and 1366×[whatever], because I know that not everyone has a 1600px wide screen like I do, and it's important for it to look good on smaller screens. To go any smaller than 1024 though (especially when taking into account the vector bar) makes portals look cramped and lowers the utility of the namespace. Sven Manguard (talk) 22:58, 12 January 2014 (UTC)

• I have also disabled this. I have a wide screen display (1366X768), and having half of my screen blank, and everything else shoved to the left side of the display is both ugly and inconvenient. I understand the desire to make the extension usable on as many systems as possible, but setting a fixed resolution at circa 1995 levels is a bit ridiculous. My en.wp userpage is designed to look good on most modern displays (the userboxes are fixed width, while the collapsible frames for the various sections are set at a variable width). It looks nice (with no overlap) with any horozontal resolution of 1280 pixels or greater. It looks terrible with a max width of 715 px. I won't even go into the frustration of dealing with long article talk pages, which now become a scroll-fest of epic proportions when looking at a threaded discussion with multiple active sections actively being edited.
• What are the current stats for user screen resolution among our readers? Is there a substantial proportion of editors using resolutions so low that a 715px width is essentially a full-screen display? Horologium (talk) 03:48, 13 January 2014 (UTC)

• Arriving this late on this topic (but hey this was not mentioned in the Beta description page here). This is where it ends up wrong: en:Template:Periodic table. The template was developed as it is last year according to en:WP:ACCESS#Resolution, essentially saying that screen resolution 1024×768 is the one to serve. And so it does (did). Even worse, in the WikiProject we have a discussion going to add one more column (now in en:Template:Periodic table/sandbox, this version).

It appears that the aesthetics/readability argument is only made for & valid for "text columns", omitting any sense for combined image/text columns or image-only columns (that is, parts in columns at certain vertical ranges). Anyway, I do not feel invited or convinced to compromise the periodic table layout for this.

For the record: the template is broken by this. -DePiep (talk) 19:22, 1 February 2014 (UTC) (home)

narrow columns are good for reading... but what kind of reading?

Maybe one reason why so many of us find the narrow width completely unusable is that we don't read Wikipedia pages in the same way that we read the types of writing that benefit from narrow columns. I almost never treat a Wikipedia page as something to be read from beginning to end. For Wikipedia articles, I first look at the overall structure of it, and then (without thinking about it too much overtly) starting zooming in on the places I think have the information I'm looking for. Likewise, talk pages and other Wikipedia pages aren't the kind of texts that are meant to be read linearly. I really like narrow columns for blogs, newspaper articles, and other web prose where there's a linear text (usually unstructured or lightly structured, in terms of headings and subdivision) that I'm reading from the beginning onward. But I don't think that's a good fit for wikis; it may make it easier to read and comprehend from beginning to end, but at the expense of being able to navigate the page and grok its structure. The latter matters a lot more for wikis than other types of reading.--Ragesoss (talk) 18:39, 13 January 2014 (UTC)

It is the user who should decide how wide a webpage should be, not the stylesheet designer! I can control the text by adjusting my browser window... Also note that I often use Wikipedia in extremely high zoom levels (300-500%) because I often use it as a foreign language learning tool and it's useful to let people far away from the screen to be able to read it so I zoom highly, but this doesn't work well with the left sidebar and the max width forced upon the user by the stylesheet designer. Why not let the user be in control? Cogiati (talk) 14:16, 14 January 2014 (UTC)

Just adding another voice to the chorus who don't like the width limit. I can make my browser window as wide as I prefer—when pages insist they don't want to use that space, it is annoying. The Wikipedia main page, which is already divided into columns, looks particularly poor with this setting. I've turned the beta off for now while this is in effect. If it is put in for real, please make it something we can turn on or off. —Salton Finneger (talk) 16:31, 14 January 2014 (UTC)

+1 to Ragesoss' explanation. That's exactly what I was trying to get at, just above. –Quiddity (talk) 20:13, 14 January 2014 (UTC)

Analysis/screenshots

I just learned of the typography refresh beta when it was mentioned on a talk page at the English Wikipedia. Upon enabling it, I assumed that something was broken on my end. I was very surprised to learn that the fixed width is intentional.As others have noted, such an approach seems downright antiquated. It's been noted that "one of the main points of this beta feature is consistency", with an em-based approach rejected because "different languages use different base em sizes to properly scale their type". But what about consistency across different displays? A fixed width causes a particular wiki's white space to vary wildly (depending on resolution, window size and text size). Some have suggested increasing the width by 50x, 100px or 200px. This might help under some configurations, but it would barely make a dent under others. As an example, let's look at the English Wikipedia's Wikipedia article at various resolutions (with a full-screen window and the default text size). 1024x0768px: Typography refresh beta disabled | Typography refresh beta enabled
1280x1024px: Typography refresh beta disabled | Typography refresh beta enabled
1600x1200px: Typography refresh beta disabled | Typography refresh beta enabled
1920x1080px: Typography refresh beta disabled | Typography refresh beta enabled
2560x1440px: Typography refresh beta disabled | Typography refresh beta enabled
3840x2160px: Typography refresh beta disabled | Typography refresh beta enabled Surely, the results seen at higher resolutions don't reflect the intent behind the change. I don't understand why this method is even under consideration. —David Levy 07:25, 15 January 2014 (UTC)

+1 (see: http://imgur.com/CxrHFik 1920x1080px ) I suggest to add some kind of responsive font size magic instead like http://simplefocus.com/flowtype/ or something similar. --Sebaso (talk) 15:38, 19 January 2014 (UTC)

Sebaso,Salton Finneger, talk,Ragesoss,Horologium,Sven Manguard, Cepheiden, AnTeaX, Portal3046, AFBorchert,Jr8825, Schnark, Raymond, Elleff Groom, Colin, This, that and the other, Sebaso, Delirium, Danno uk, Dravecky, DoRD, Edokter, Hasteur, TheDJ

Thanks all for your feedback, positive and negative, I want to address the points you brought up.

Why 715px? — As I mentioned before we based this number on the ideal characters per line (CPL) found in the research we found on text measure's effect on readability and comprehension which ranged from 45-115 CPL, at ~16pt type in latin script 715px gives us ~113 CPL we went with px rather than ems because the base text size on most wikipedias is 1em, but this is changed on some non-latin script wikis to be larger or smaller, if we based the measure on ems the width could vary quite widely from wiki to wiki.

Why do this at all? — The early days of the web were a dark age for typography, things looked like they did because we didn't have control over layout to make things look balanced, harmonious and readable the way we did in print. Much of the early web was not about conscious choices but ill conceived defaults. Thats not to say we are making these choices now because we can, we are making them because they are good choices, and there is a long rich history that got us to where we are now when it comes to best practices in typography and layout. This history does not need to be abandoned when we move from print to screen. We now have the option to take all of the historical learning about good layout and apply it to this new medium, that is why we are doing this.

Read mode — suggesting adding a reading mode button to wikipedia feels like adding a game mode to tetris. People come to Wikipedia to read. The written word is the primary content type on the site and as such we optimize for it. It is a pretty safe assumption that a users goal when they come to the site is to read, so requiring them to enter a special mode that optimizes for that task seems rather backwards.

Make it an option — Have you seen the user preferences lately? its hard to navigate, hard to find what you're looking for and pretty overwhelming to new and advanced users alike. Whenever possible we avoid adding new options, both to the main UI and to the preferences. Additionaly preferences aren't available to IP users.

Manually resize your browser — They say you only get one chance to make a first impression, if an article doesn't look good when a browser is maximized because the measure is unreadable long, the an the images are small in comparison to the long text lines, and the images stack up in the right side, no longer associated with the text they illustrate we've lost that chance at a good first impression. We don't want to put the onus on the users to have to manually resize their browser to make the text readable, we want the text to be readable immediately when they come to the site. We don't even what the user to get into a situation where they aren't looking at readable, beautifully set type. Type layout is more of an art than a science, although you can augment it with plenty of math if you like. If we set a type size and leading for a narrower measure and a user views it at a measure that is twice is wide it will not be an ideal experience. While libraries like http://simplefocus.com/flowtype/ seek to remedy this, they are not ideal for some of the complex layouts we have on the site. We may be able to leverage them long term but they would not be a straightforward thing to implement.

More Data — We don't know a lot about our users systems, we purposefully limit the amount of data we try to gather about users as privacy is one of our core tenants, while we seek to expand this in ways that are aligned to our privacy policy we don't have information about screen (browser) widths of users who visit the site currently. It would be great to have, and would certainly aid in our design process but its not available to us at this time.

Thanks again for everyone's feedback, we're listening, we promise, and we're working on a new revision to the Typography Refresh Beta Feature right now, stay tuned, keep testing and giving feedback. Thank you.
Jaredzimmerman (WMF) (talk) 08:02, 20 January 2014 (UTC)

Jared:

As stunned as I was to learn that the 715px width was intentional, I'm more stunned by your apparent statement that it's to remain in place.

Did you view the screenshots to which I linked above? (I wasn't among those pinged, so I'm not sure.) I'm at a loss as to how such a setup (even with adjustments planned) has been deemed acceptable. Having previously read the justification for using a fixed width instead of an em-based solution (repeated above), I remain perplexed as to why vast layout inconsistencies depending on individual users' settings (with an enormous gap appearing under some configurations) are considered preferable to inconsistencies among languages (which could be addressed simply by enabling adjustment to accommodate a wiki's base text size). I'm confused as to why CPL has been conflated with raw width (the latter of which is only one of the components determining the former). I'm bewildered by the description of a fixed width as a move away from outdated methods.

I don't mean to be rude or ungrateful that you're taking the time to engage the community, but I'm taken aback by all of this. If I've misunderstood something, my apologies. —David Levy 09:38, 20 January 2014 (UTC)

Eh, also somewhat flabbergasted .... but most importantly, i don't think any of my points were answered. TheDJ (talk) 16:33, 20 January 2014 (UTC)

I'm deeply troubled by your responses. Wikipedia is already one of the most heavily read websites in the world, it clearly isn't losing readers because of its format. This (from the above comment) is what my screen looks like under the new format. It looks unprofessional. It looks broken. What you have is a good idea about ease of readability that is utterly detached from reality.

How exactly are you going to rectify that there's a massive chunk of whitespace that appears for some but not all users, is different-sized depending on the user, and has to not look like a giant chunk of whitespace regardless of the page. Are you going to utilize images? What if there aren't any? What if there's only one, and the article is really long. Are you going to put some other content there? What other content? Who decides? How will it be determined what the side content is going to be for every one of the millions of pages we have? Are you just going to leave it white? It looks, as I said, unprofessional and broken as a giant chunk of whitespace.

Jared: You came to us with a half-flushed out idea, and in the face of a large amount of very specific objections, you came back to us with a set of responses that are not only woefully inadequate at addressing those concerns, but also come across as holier-than-thou (especially the Read mode and Make it an option sections). I am generally willing to give the foundation the benefit of the doubt, but there are serious problems here, both with the idea itself and with your interaction with the community — the people that have to work in the environment that you are creating. I would much rather comment on a finished proposal, one that addresses what is going to be done with the extra space, but in the absence of that, I'm commenting on what we have here. If the 715px format were to go live, especially with nothing to put in its place, English Wikipedia would revolt. I've been told that you haven't been around to see firsthand any of the true revolts that have happened in the past. They're ugly, months-long affairs, and at the end of them, neither side gets what they want and people are bitter about it for years afterwards. I strongly recommend that, in the absence of just ditching this idea in its entirety (still my first choice), you come up with a much stronger proposal; one that addresses the concerns that people have in a substantive fashion and answers the questions about what's going to happen to the empty space. Sven Manguard (talk) 01:24, 21 January 2014 (UTC)

Jared: I agree with you in most of your points, and am looking forward to the next update. But I disagree with your rationale for using px instead of em. You want a consistent layout across all wikis, even if they changed their base font size. This just doesn't work, nor is it desirable: Let's compare ar: with en:: Perhaps you succeded to make the content block the same width in both wikis, but I just can't see this, as the width of the side bar in ar is much smaller than in en (and when you use Arabic as your interface language, you just won't get a consistent layout, no matter what you put into your CSS). When a community decided to change the font size, they might decide to change the content width, too, so again you won't get a consistent layout. On the other hand there are users who changed the basic font size in their browsers. For them, the fixed pixel width causes problems, while a width in em would look consistent across different browser settings. And this consistency is much more important than consistency across different wikis in different languages. --Schnark (talk) 09:26, 21 January 2014 (UTC)

David Levy, I did see your screenshots, sorry I missed you in comment, it was accidental, I think your screenshots represent a large chunk of possible, but mostly unlikely scenarios. I'd love to have more data to back that up, but as i mentioned, we don't yet.

David Levy & TheDJ, Sven Manguard, I'm sorry that you are stunned, flabbergasted, and deeply troubled but the truth is this is a beta feature and participating in it at this early state is completely up to you. No one is forcing you to keep it on, and there are no concrete plans to transition the narrow measure into the production site. I'm happy you are using it and happy to have your feedback, but language like that makes it sound like you are being forced against your will to use this experimental feature. I want to stress that last point experimental meaning not done, early, testing, etc. if you think the idea is half baked, its because it is, and thats fine, in fact it is the point of beta features.

If you want to wait to talk about a finished proposal, come back later, but that isn't what the project or the foundation is about, its about collaboration, but its hard to collaborate with someone who attacks the first thing you do, rather than working with you in a collaborative and constructive way. But beta features will continue, and their point is not to show finished work, its to show work in progress.

Schnark, Thanks for the feedback, I checked the sidebar in arabic wikipedia and english wikipedia and measured 177px in both cases perhaps you have some special css on your profile that is conflicting with the default site styles. While yes we can't control the css for each language site we can propose best practices, and hope that people stick to them.

TheDJ, I'm sorry I'm not seeing any other questions you had other than those about the image hover which isn't part of this Beta Feature, and the infobox issues which we're working on for the next release of this beta feature, if there is something I'm missing please point me to it so I can address it.

Jaredzimmerman (WMF) (talk) 03:43, 22 January 2014 (UTC)

Jared: They are both the same width when I use Arabic as interface language in ar, but when I use English or German the width is smaller in ar. And, as I said, when I use ar.wikipedia with Arabic and en.wikipedia with English the layouts just aren't comparable, as one is LTR the other RTL, so I just don't care whether the content has exactly the same width in both or not, I just won't notice. When you publish guidelines about what communities should or shouldn't do with the site's CSS, you can just tell them: "If you need to change the base font size please consider changing the content width, too, to make it look consistent across different wikis", and use em as unit for the default width. (BTW: Your ping didn't work.) --Schnark (talk) 08:37, 22 January 2014 (UTC)

Jared: Thanks very much for your response.

I'm curious as to why you "think [my] screenshots represent a large chunk of possible, but mostly unlikely scenarios" (particularly given the absence of "data to back that up"). I used only default display settings (in both the OS and the browser) and standard resolutions. The screenshots accurately depict the results of simply viewing the article in a maximized window, which is hardly out of the ordinary.

I also mentioned that under an em-based approach, wikis could adjust the setting in accordance with their base text sizes. Schnark has now noted this as well.

I'm sorry if my reply came across as an "attack". As I said, "I don't mean to be rude or ungrateful that you're taking the time to engage the community". Indeed, this is about collaboration. And I think that much of our frustration stemmed from a perceived incongruity between our belief that the feature in question is fatally flawed (to the extent that I'd label it "broken") and your response.

There may have been a misunderstanding. In your latest reply, you emphasize that the changes are experimental, so maybe you meant that the team wishes to continue experimenting with the feature before ruling out the possibility that it will make the final cut. On our end (or mine, at least), it came across more like "Thanks for your feedback, but the 715px width is here to stay. We hope that you can look past your misplaced concerns and realize that this is the best solution moving forward."

Perhaps past experience has colored our expectations. The above might not accurately reflect your attitude or the message that you intended to convey, but it does accurately reflect strategies employed previously.In 2010, the Vector skin was rolled out with a controversial interface change that wasn't even included in the pubic beta test. The interlanguage links were collapsed by default, thereby hiding them under a label that users lacking fluency in a wiki's language often are unable to comprehend. This greatly impeded users' ability to find content in other languages (for reading, editing and translation purposes). The change was made on the basis that "the language links were used relatively infrequently based on tracking data" (collected, rather inexplicably, at the English Wikipedia alone) and a hunch (with absolutely no testing to corroborate it) that readers perceived the links as a distraction. Sven noted that "you haven't been around to see firsthand any of the true revolts that have happened in the past". I would include the community's reaction to that change, which was overwhelmingly negative. And the development team's initial response amounted to an explanation of why we were mostly wrong and a promise to explore some potential tweaks. In the end, the change was simply rolled back (as a vast majority of respondents requested in the first place), but not before wasting a great deal of time and shaking the community's confidence in the abilities of the parties responsible for such decisions. Relevant discussions can be found here, here and here. (The second link is the most useful.) Of course, you weren't involved in that situation (and others), so it obviously wouldn't be fair to hold you accountable. But I hope that you can understand why we worry about the potential for something similar to occur again. —David Levy 11:39, 22 January 2014 (UTC)

Schnark, sounds like a bug to me, would you mind logging it, as you can better create the reproduction steps? if the sidebar is changing width based on the language, that shouldn't be happening. To your point, do I think the site should look the same across languages? I honestly do, I think this level of consistency is important to people's experience of the product.

David Levy, I appreciate your response, I've been with the foundation for about 9 months now, and one of my first points of business was to create and roll out Beta Features, in order to improve the change management on the project. I understand that there has been friction in the past, but I just want to be clear that this framework was created specifically to help that. Due to the current state of typography on the site i believe that user with monitors larger than 1600x1200px are no running the site maximized, additionally I believe the number of users with resolutions higher than this is extremely small. That is not to say that we should penalize users with large monitors in any way, just that we should design for the 90% and try to make sure we have an acceptable solution for people outside that. Your screenshot for the 3840x2160px screen is not only well out of what most users will be running, its also goes against any best practices in layout design and best practices for readability. I'll continue to investigate a way we can log more data about users screen sizes in a way that is compatible with our privacy policy.

I'm sorry if I came across as saying any part of the design was "here to stay" beyond the context of this experiment, but I am adamant that is part of this experiment, a day after its release members of the community logged a bug an started a very hostile conversation to remove that aspect of the design from the beta feature, I hope this seems as ridiculous to everyone else as it does to me, since this is an opt-in test, not a core piece of the site experience. It also makes our job quite difficult if instead of actually doing out job of working with the community to improve the site we have to argue for HOW we do our job at such a granular level.

Again I appreciate everyone's feedback, and I hope you all continue to test the beta features. Please try to come at them with new eyes, and not let your past experiences color how you try out this new way of giving us design and usability feedback.

Jaredzimmerman (WMF) (talk) 17:39, 22 January 2014 (UTC)

To your point, do I think the site should look the same across languages? I honestly do, I think this level of consistency is important to people's experience of the product.

I don't think that anyone disagrees with the idea that consistency is desirable. It just seems odd to prioritize consistency across wikis written in different languages over consistency within a particular wiki when viewed by different users. Regardless, an em-based approach would enable both, provided that it's adjustable to compensate for different base text sizes.

Due to the current state of typography on the site i believe that user with monitors larger than 1600x1200px are no running the site maximized,

Like you, I lack relevant research data. I can tell you that I routinely view Wikipedia at 1920x1080px (significantly wider than 1600x1200px) with the browser window maximized. As I noted previously, when I enabled the typography refresh beta and saw the enormous gap, I assumed that something was broken on my end.

additionally I believe the number of users with resolutions higher than this is extremely small.

Higher than 1600px wide? I have no figures in front of me, but 1080p (1920px-wide) displays have become common even for laptop computers (such as mine, which cost less than US$1,000 in 2012).

That is not to say that we should penalize users with large monitors in any way, just that we should design for the 90% and try to make sure we have an acceptable solution for people outside that.

Implementing something along the lines of FlowType.JS has been mentioned as a possible solution. Any thoughts on that?

David Levy, Yep, as i mentioned above we are aware of this library (even before it was mentioned in this discussion) and are interested in looking in to it. It is no small task though, since many things like templates are generated at runtime they may not play nicely with flowtype, so there is research to be done, and we plan on doing it, just not at this moment.

Jaredzimmerman (WMF) (talk) 19:36, 22 January 2014 (UTC)

Your screenshot for the 3840x2160px screen is not only well out of what most users will be running,

The technology press has recently described the emergence of 3840x2160px ("4K UHD") displays as one of the hottest trends in consumer electronics. They aren't particularly widespread yet, but there's every indication that they will be in the not-too-distant future. Already, a 39" 3840x2160px display can be purchased for as low as US$500 (less than half what I paid for a 32" 1920x1980 display in 2008).

its also goes against any best practices in layout design and best practices for readability.

No argument there. A solution is called for, but it hasn't been found yet (as the 715px width takes matters from bad to far worse).

David Levy, I'll reiterate that the 90% of our users don't have an extra $1,000-$500 to spend on high end monitors and while these monitors are becoming more mainstream I would bet that 1024x768-1280x1024 is still the high end of "common" for most users, or smaller. I can't say any of this for sure without more research though.

Jaredzimmerman (WMF) (talk) 19:36, 22 January 2014 (UTC)

I'll continue to investigate a way we can log more data about users screen sizes in a way that is compatible with our privacy policy.

Thanks very much for that.

a day after its release members of the community logged a bug an started a very hostile conversation to remove that aspect of the design from the beta feature, I hope this seems as ridiculous to everyone else as it does to me, since this is an opt-in test, not a core piece of the site experience.

Having read the Bugzilla discussion, I agree that the matter should have been dropped (in that forum) as soon as it became clear that the 715px width was intentional. I can understand mistaking it for a bug (as I did), but it clearly isn't one. It's an experimental feature that doesn't impact users who haven't opted into the experiment.

Thanks again, Jared, for taking the time to respond here. I sincerely appreciate it (and the underlying framework). —David Levy 19:01, 22 January 2014 (UTC)

David Levy, happy to help.

Jaredzimmerman (WMF) (talk) 19:36, 22 January 2014 (UTC)

Jared: No, that's not a bug: In ar:MediaWiki:Common.css there is a line [dir="ltr"]{ font-size: 13px }, which applies to the side bar when you select English or any other LTR language as interface language, while the default CSS (which is in use without modifications on en.wikipedia) uses the browser's default, which is 16px in most browsers. The width of the side bar is 10em, i.e. relative to the font size, so it is smaller than usual in ar.wikipedia, by the same factor the font size is smaller. That's the same reason why you get different widths when you use em as unit for the max-width: It's relative to the font size, and that size sometimes is changed in a wiki. But that's not a reason to use px, but just to accept the differences. --Schnark (talk) 08:35, 23 January 2014 (UTC)

Schnark, I'll ping the language team, bug or not I don't think it was a purposeful decisions, just an artifact of how it was developed.

Jaredzimmerman (WMF) (talk) 00:58, 24 January 2014 (UTC)

┌───────────────────────────────────────┘

Jared: You say you're "adamant that [715px] is part of this experiment" and describe opposition as "ridiculous", neither of which give me hope that you have any intent other than eventually forcing this failure on us all after the beta has run its course. As a content creator and one of the English language Wikipedia's top contributors, it also makes my job "quite difficult" knowing that this change mangles many of the articles I've created and that the concerns of so many are so easily dismissed. - Dravecky (talk) 08:24, 24 January 2014 (UTC)

Dravecky, I think you might have misread what I wrote, I was referring to the process of logging a bug against a beta feature rather than giving feedback here that we can discuss. All feedback it helpful positive or negative. But what is particularly helpful is actionable feedback, so you in your case, pointing out specific pages that you feel aren't displaying correctly is very helpful for us rather than speaking in generalities. One thing we've noticed so far is that pages that don't display correctly are usually because people have hard coded widths into elements. Which breaks on mobile and breaks for users with smaller displays, not implying this is your case but sharing some links to articles you've contributed to that aren't displaying correctly will help us figure out how it can be improved.

Jaredzimmerman (WMF) (talk) 20:06, 24 January 2014 (UTC)

Jaredzimmerman WMF's stance is that max width of 715px is what is going forward? Fine. My stance is as much as I did like the other compontents, that one rule is a deal breaker and I will advocate strongly against this "experiment" going forward and add another tick to the "Decisions that the foundation made that were accepted as a lead balloon on the flagship Wikipedia". I respond now because I rarely come over to meta. Hasteur (talk) 18:58, 3 February 2014 (UTC)

Hasteur, I would advise you to not assume that we are a homogenous bunch at the Wikimedia Foundation :-). I agree with you that the whitespace issue is pretty much a deal breaker for seeing this feature move towards being the standard on our wikis. I actually view this discussion as a success of the Beta Features programme; if the typography refresh was being quietly tested in some backchannel, the issue likely never would've surfaced until it was too late. I'm interested in iterating with the design team about this issue, so we'll see how things progress. --Dan Garry, Wikimedia Foundation (talk) 00:14, 14 February 2014 (UTC)

Disabled this too after wondering what was going on. this made wiki almost unusable for me. Any page with a few big images suddenly becomes a complete mess --Nate1481 (talk) 17:32, 10 February 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) • 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)

@Delirium: Something like this will force lining numerals in modern browsers where appropriate (although the user may need to have a recent version of Georgia installed too):

div#content h1, div#content #firstHeading, div#content h2 {
  -moz-font-feature-settings:"lnum" 1; 
  -moz-font-feature-settings:"lnum=1"; 
  -ms-font-feature-settings:"lnum" 1; 
  -o-font-feature-settings:"lnum" 1; 
  -webkit-font-feature-settings:"lnum" 1; 
  font-feature-settings:"lnum" 1;
}

@Steven (WMF): Is this something that could be incorporated into the refresh? the wub "?!" 00:09, 10 January 2014 (UTC)

Sounds pretty reasonable. I'll make sure we run it up to the designers in our next meeting about this. Steven Walling (WMF) • talk 00:17, 10 January 2014 (UTC)

For those not familiar with the rationale behind "old-style figures" they are created to bend in better with written text. the wub, this would be one totally valid way to fix the bottoms of letters being clipped off, adjusting the line height would be another way, when we meet next time to iterate on the Typography refresh, I think this is a good idea and we'll definitely evaluate it against some other options

Jaredzimmerman (WMF) (talk) 00:58, 10 January 2014 (UTC)

This is my only problem with using Georgia (or any typeface that uses old-style numerals [OSN]) in headers (or in articles either). OSN's are a nice typographic feature for signs, posters, or simulating something that might have been written in the 1700s or 1800s. It's just distracting and difficult to read in most modern uses, especially in an encyclopedia. We want to make things easier to read, so why make the numerals more difficult to read? If you pick a typeface that avoids OSN (and any CSS "hacks" necessary to "fix" the line spacing as shown in the examples above), then you will have something that will work in ALL browsers, not just the "modern" ones. I also think that doing so is more in line with the goals of this refresh. And if the font on the mobile edition doesn't match, then just change the font there. That will improve the mobile version, too. —Willscrlt ( Talk | w:en | com | b:en | meta ) 17:50, 12 January 2014 (UTC)

Underlining Links

I’d suggest that links should be underlined with

border-bottom: #0645AD solid 0.1em;

instead of

text-decoration: underline;

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, text-decoration: underline 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. --Skizzerz 16:35, 9 January 2014 (UTC)

There's a user preference for link underlining... we should probably simply respect that? --MZMcBride (talk) 23:05, 9 January 2014 (UTC)

Just because something is not widely used doesn’t mean it is cleaner. For example the letters ‘g’ and ‘q’ look exactly the same in an underlined link (Bugzilla etiquette). So it increases readability to use the border-Version. But I agree with MZMcBride, the user preference should be respected. —MRosetree (talk) 07:45, 10 January 2014 (UTC)

Strongly disagree. I could not support any change that blatantly screws up proper typography standards in the way that was suggested. The bottom border is a block-level style. Underlining is an inline style. If you had something two lines long that was underlined using border, it would underline the bottom of the two lines, but the top would not be. Even if you "hack" the CSS so that it is set to in-line, the semantics would be all screwed up. You use underlining to underline, not a border. Borders sit outside of the text (which is why you like it, since the underlines drop below the descenders), but that's not the way that underlining works. Underlines are supposed to appear under the baseline of the text, which means that they likely will cross the descenders. That's what is supposed to happen. If a typeface doesn't allow enough room between the baseline and the descender such that it becomes unreadable, then just pick a different, better designed typeface. —Willscrlt ( Talk | w:en | com | b:en | meta ) 17:56, 12 January 2014 (UTC)

Ok, I didn’t knew that. This is a point I can agree with. —MRosetree (talk) 07:27, 13 January 2014 (UTC)

blockquote

On enwiki, blockquotes are showing in italics, and much larger than the font-size: 85% set in Common.css. Here it is not italic.

Lorem ipsum dolor

--Gadget850 (talk) 20:42, 9 January 2014 (UTC)

@Gadget850: Italicised blockquotes were killed already [7], 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)

I support this change. Excessive italics should be avoided. But I have an other problem: In my Windows 7/Opera 12/GDI setup the contents of the blockquote look like they are bold. The blockquote isn't only bigger and uses an other font, it looks like it's double the weight as the rest of the text. The debugger shows that the calculated font weight is the same in both cases (400) but the font family and size is different (16.9px instead of the normal 14.08px). Dimming the currently used font-size: 1.2em; slightly down to font-size: 1.17em; fixes the problem (reduces the calculated size to 16.47px). I did not tested it with other browsers and configurations but I'm pretty sure that 0.03 will not make a difference in most other cases. --TMg 19:27, 10 January 2014 (UTC)

In enwiki (vector skin) using Safari on Mac (most recent versions, default everything), blockquotes just started appearing at 17pt in italics, compared to 14pt body text. It is way too big, folks. Zero0000 (talk) 06:56, 11 January 2014 (UTC)

The italics issue has been fixed but not yet deployed. The size has not yet been fixed. We can always override it on enwiki through Common.css. --Gadget850 (talk) 11:59, 11 January 2014 (UTC)

The italics is now resolved on enwiki. But, we still have the larger heavier font. This means that long blockquotes overwhelm the content. Enwiki styling for blockquotes is styled to font-size: 85%; through MediaWiki:Common.css, with a gadget to set it to 100% as desired. --Gadget850 (talk) 14:46, 22 January 2014 (UTC)

@Gadget850: I think Jaredzimmerman (WMF) and the design group need to explain in detail about blockquotes, but here's what I can propose from talking to them about it... from both the current enwiki Common.css style and the one set in the Beta Feature, sounds like folks mostly agree that blockquotes should be styled differently beyond just the indent. Fair? If the issue with the larger text size is that block quotes can already be quite long, then I can see how setting to .85 em or similar would make sense. Are blockquotes set to 85% on English Wikipedia because they tend to be longer than say, mere pull quotes? In the example articles with lots of blockquotes we could find, like the Rumi article, the blocks are mostly quite short. In any case, if there is agreement that block quotes should be styled differently than just indenting, let's try to reach agreement on the right style, so that we can apply it across wikis instead of just keeping in local English Wikipedia CSS. Steven Walling (WMF) • talk 00:44, 9 February 2014 (UTC)

The huge blockquotes also look stupid on wikisource :-( —SamB (talk) 01:32, 3 February 2014 (UTC)

I have disabled Typography Refresh due to this, so I won't be able to give further feedback. If this gets implemented as a standard, I will push to override it in common.css. --Gadget850 (talk) 14:02, 8 February 2014 (UTC)

Yes, there are large quotations, such as Jimmie W. Monteith. I see the larger font is now gone here, but now we have large quote marks. This violates the English Wikipedia guideline at MOS:Blockquote. --Gadget850 (talk) 20:05, 10 February 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)

.action-view #bodyContent {
  max-width: none !important;
}

You mean "affect" and using the word "stupid" in this context is probably a poor idea. --MZMcBride (talk) 23:03, 9 January 2014 (UTC)

I can't agree more with MZMcBride.--William915 (talk) 09:36, 10 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)

The general refresh seemed promising, but I disabled it now as it seems this was "by design". Too bad, it sounded like a good initiative. Disabled, let me know when you're back to normal width and I'll happily try again. Effeietsanders (talk) 21:01, 10 January 2014 (UTC)

Made pages narrow for me too, using the latest Firefox version, so I disabled it. I should note that pages looked better/cleaner despite that pesky narrowness. --CubicStar (talk) 16:11, 19 January 2014 (UTC) (el.wiki)

Also this problem appears on the latest version of Chrome browser. The page looks good, yet the narrow-width problem has to be solved. --KAMEERU322813 (talk) 12:17, 3 February 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)

• I agree in principle with a fixed column width. However, I use a 2560x1600 monitor and while I know that is rather uncommon, it looks horribly off-centred and unbalanced. Even on my laptop which is 1366px wide, the column width looks much too narrow to me. Centring the column would certainly minimise the issue. I'd like to see it a bit wider still though, to better fit the vast majority of displays (according to this, 90% of displays are at least 1280px wide, and 99% of displays are at least 1024px wide, and those stats are a year out of date). I'm not suggesting we set the column width to 1280px or 1024px necessarily, but something not far off would be a better compromise between compatibility and viewability. Diliff (talk) 23:24, 9 January 2014 (UTC)

You could try adding

@media screen
.action-view #bodyContent {
margin-left: auto !important;
margin-right: auto !important;
}

to your personal css. That should center the main body content.--Salix alba (talk) 00:18, 10 January 2014 (UTC)

Das geht garnicht. und tschüss.--Mauerquadrant (talk) 05:46, 10 January 2014 (UTC)

Tested here, don't work. Maybe I'm putting it in the wrong place? Note: I'm using style vector. Epok (talk) 08:41, 10 January 2014 (UTC)

Try

#bodyContent {
margin-left: auto !important;
margin-right: auto !important;
}

In your vector.css. This has a simpler selector. Its working for me in en.wikipedia using chrome. You may need to refresh you browser to get it to work.--Salix alba (talk) 09:09, 10 January 2014 (UTC)

Yep, this version worked! Thx, much better. Epok (talk) 09:21, 10 January 2014 (UTC)

I'm not that keen on editing my own CSS - I've already disabled the typography refresh on my account as I didn't like what it did to the pages. If we're all editing our own CSS to get it looking the way we like it, how is that helping move the typography refresh forward? I assume that overrides the settings that the beta? Surely it's better for us to test what is implemented for everyone participating in the beta and provide feedback on that? Diliff (talk) 09:47, 10 January 2014 (UTC)

Infoboxes and tables not considered

Sorry, but the current limitation is way to narrow. And why pixels? Why 715px? It simply feels wrong if half of the screen space is wasted. Currently it's like the Vector design is broken somehow. The rest of the design does not reflect the change. Most important problem: Currently this results in lines of only 50 to 60 characters if there is an infobox template, an image, climatic diagram or something like that on the right. People are using this space a lot when designing articles. There should be enough room for at least 80 to 100 characters even with an infobox template on the right. A typical infobox is 250px to 300px.

1. Please expand the max-width to something like 1000px.
2. Please provide a solution to turn the limitation off for big tables.

PS: I forgot all non-article pages like the main pages and portals. They are all using columns. Mostly two columns, sometimes three columns. With the proposed change all these pages are excessive scrolling stripes of sometimes only 20 characters per line. Even the most narrow newspaper style does have longer lines. An other example are gallery pages. Now it's impossible to use images larger than the proposed 715px without breaking the design.

PPS: Regarding the infobox templates. When looking at an article like de:Flugplatz Buochs with a single infobox template in the top right as the only non-text element, it feels like the infobox must be outside of the text. I created a mockup to show what I mean. Being able to put infoboxes and images there would solve many current problems. I'm sure many user would love and use this. It doesn't solve the problem with big tables, though. I think the best way to solve this is to turn the limitation of for specific elements like big tables. Something like {| class="wikitable wide" for big tables, [[File:…|thumb|detachable|…]] for images and {| class="infobox detachable" for infobox templates as shown in the image. --TMg 16:39, 10 January 2014 (UTC)

Lines endings visualized in red

We are considering this. One of the main motivations for making the space on the right was to explore putting infoboxes and other media here. It feels like this may warrant a separate beta experiment though in my opinion :) Jdlrobson (talk) 23:56, 10 January 2014 (UTC)

I don't think this can be separated. "Waste space first, make use of it later" is not going to work. See all the complaints here. If you want to separate this you need to remove the width restriction from the current feature set.

I'm using the limited width layout for some days now to see what happens and if it becomes familiar after a while. Here are my findings:

• Even if I'm starting to get familiar with the layout I still have mixed feelings. I still find it to narrow. The benefit of the short lines is outweigh by the increased need to scroll. With the current width I find the disadvantage of the additional scrolling much more distracting than the disadvantage of long lines. Every time you have to scroll you have the same problem as with long lines: it's hard to find the right line again. Please find a better balance. 100 to 120 characters per line are no problem nowadays. People are used to this.
• .js and .css subpages (in the MediaWiki: and User: namespaces) must always use the full width.
• Diffs should never be limited in width but currently are.
• Take care of the mixed "diff at the top, preview at the bottom" settings with both action=view and action=submit.
• Currently the preview isn't limited in width but must be similar to the final article.
• Take care of the live preview settings.

--TMg 14:21, 13 January 2014 (UTC)

Margins when mixing paragraphs and lists

I know I'm nitpicking. That's the point of my posts. ;-) Please don't get me wrong. I like almost all the changes (bigger font size, more line height, more margins). However, here is one of my nitpicking issues:

First paragraph introduces list:

• First list

Second paragraph introduces list:

• Second list

With the typography refresh enabled it's like the margins are switched. The margin at the bottom of a list (between a list and a paragraph) is smaller than the margin at the top of a list (between a paragraph and a list). It should be the other way around.

For comparison: With the typography refresh disabled these margins are equal. I never liked that for the same reason as above. In my opinion the bottom margin of a list should be slightly bigger than the top. I'm not sure if this is a good idea in all possible cases where lists are used. I know it will be good in most cases since almost every list does have an introduction and only very few do have footnotes. If you are not sure please make the margins equal again. --TMg 18:41, 10 January 2014 (UTC)

Enlarge image icon

Example

Why was the "enlarge image" icon () removed? I'm afraid this will cause existing pages to contain copyright infringements. Yea, I know this sounds strange. Let me explain. Sometimes images are used like they are simple imagemaps, using the relatively new link= parameter as shown in the example on the top left. With the magnify clip this wasn't a problem. The file description page could still be reached. When removing the icon all pages with such images will have an ugly licensing problem: you can't reach the file description page any more.

Oh, and while you are at it, please make the design of the ever misplaced "i" icon of the imagemap extension fit (example at the bottom right). --TMg 19:04, 10 January 2014 (UTC)

The ImageMap extension allows you to control the placement of the blue icon. — Edokter (talk) — 20:24, 10 January 2014 (UTC)

I'm not talking about the position but about the design of the "i". It always looked weird compared to the icon. --TMg 13:19, 13 January 2014 (UTC)

Best place to discuss that would be at Extension talk:ImageMap. — Edokter (talk) — 22:37, 13 January 2014 (UTC)

If one of the icons is discussed here why not discuss the other? Users tend to use imagemaps next to thumbnails in articles. They don't draw a line between the two. Same here. --TMg 20:58, 17 January 2014 (UTC)

Why can't you center the page?

Instead of pulling the whole page left.

Because we've got plans for the right side… <see above> but we might want to adjust the margins a bit next iteration.

Jaredzimmerman (WMF) (talk) 04:36, 13 January 2014 (UTC)

I don't know what is meant by "see above" but it might be the comment at #Refreshing indeed. Such stuff should be on the project page, this talk is a pain. --Nemo 23:38, 3 February 2014 (UTC)

Left Aligning

Left aligning the whole page doesnt really look well, especially for users who have really adjusted themselves to center aligned page. When all of a sudden, I viewed the new Typography refresh beta update, it gave me really a complex look, and I didnt wait any longer to revert the update. I hope Wikipedia will reconsider this update. Anandtr2006 (talk) 14:24, 11 January 2014 (UTC)

Thumbs border removing?

«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.» — That is a really bad idea. All the pages that have extensive picture usage have now transformed into hardly readable mixture of main text and captions. Check, as an example ru:Письма_махатм_А._П._Синнетту. You can see also that the font in the captions is the same in size now as in the main text, that brings even more confusion. --Melirius (talk) 13:41, 12 January 2014 (UTC)

Aha, the last point (about caption font) is connected to the magnification of the font in FF by Ctrl+, and it is not existing in the default size, where the difference is clearly visible. But this is still an issue to be solved: after the first magnification the difference is substantially decreased and after the second perceived difference disappears. --Melirius (talk) 13:48, 12 January 2014 (UTC)

I suggest also to make an option that allows one to show borders or switch them off for a thumb. --Melirius (talk) 13:50, 12 January 2014 (UTC)

A bit wider?

It's really good to see this project responding to feedback from users; it's really improved over the last few months. I still get the feeling that the current chosen page width is a bit too narrow, particularly on pages such as the enwiki Main Page: have you experimented with making it perhaps 50 or 100px wider? I also wonder whether you have experimented with A/B or multivariate testing on this? -- Giadiniera (talk)

Solve the width problem by making it user-configurable

Perhaps we could allow configuration of the narrowing or widening of the default screen width become a user-configurable option. Something like we have now under Preferences > Appearance > Files > Thumbnail Size. The options could read: Tiny (320px), Narrow (620px), Default (715px), Wide (960px), Full-screen. The numbers are just examples; feel free to substitute other values that make sense.

• The "Tiny" option matches the width of many mobile devices. In fact, this could basically just trigger the standard mobile interface so that we don't have to reinvent the wheel.
• The "Narrow" option would be the minimum width we can see being the narrowest usable screen size. 620px fits in a standard 640x480 monitor resolution (allowing 20px for browser borders and scroll bars). Nobody uses 640x480 anymore you say? Not true! Many people with limited vision use very low resolutions to "scale up" the size of everything on their screen automatically (higher resolutions make text and other things appear bigger, thus easier for people with vision problems to read more easily). Yes, there may be some issues with divs, TOCs, tables, etc., but we are trying to do our best here, and it establishes a goal to design for.
• The "Default" value is the 715px that is currently being bandied around in this proposal. Whatever "default" size is picked would go here, and it would be selected by default for all new users and for users with no accounts.
• The "Wide" would be a comfy size for people with wider screens. It probably also should center the main body text on the screen and do any other changes that people are suggesting (like moving thumbnails outside the body text flow). It would be for those people with plenty of screen real estate. Don't like it? Just change back to default.
• The "Full-screen" option would basically leave everything the way it is now. The text sprawls all the way across the screen. For folks with unusual screen dimensions, this might be a better option than any fixed size. Also, for people who like to have the text flow all the way across the screen, this would satisfy them.

To test this, the functionality could be implemented as a Gadget initially. Eventually, if successful, it would be rolled out into the interface. It should become part of Preferences > Appearance, under the Skin section. If a skin supports these default widths, then the preferences options would appear. If not, they would be dimmed out (disabled). This could be determined easily by adding a setting inside the skin's file. If the option is supported (i.e., the skin is updated to support these features), a directive (like "narrow-width:620px" or "full-screen:yes") could be added to the template, and preferences would only have to check that file to see if a width is supported and how many pixels it is (715px might be the default for Vector, 720px for Modern, and 721px for some other skin).

This level of configuration would be a big benefit for both end-users and for skin designers. It also would provide flexibility down the road as screen dimensions change, and also help designers trying to design new skins for people with disabilities or for new technologies that have a totally different output geometry. It also would satisfy people who like the text wide and sprawling, and those would think that narrow and compact is more readable. Personally, I think it depends on the device you are using to output (huge difference between how any site looks on my netbook screen vs. my HDTV). No designer can properly design a site to look good under all conditions, especially since it's a subjective decision anyway. Leaving the user in control is the best way to "fix" this problem. But, giving them a reasonable default is very important, too.

What do you think? —Willscrlt ( Talk | w:en | com | b:en | meta ) 18:23, 12 January 2014 (UTC)

I would suggest that an on/off switch also be included on the individual pages, so that the user wouldn't need to go back and change their default settings for each situation. The page would always open with the user's or wiki's default width, but the switch would release the width restriction to expand the contents to the full window width. This would be useful for making as much of the article, image gallery, or commons category as possible visible within the window. I see it working somewhat like the wrap/nowrap selection on some text-editors, with perhaps even a keyboard equivalent like ctrl-w to toggle back and forth.Nonenmac (talk) 20:29, 12 January 2014 (UTC)

DejaVu Serif Bold looks awkward in headings

Look at w:en:Main Page, the headings like "From today's featured article" look awkwardly ugly. The letters look like being smashed down and stretched horizontally. While I understand that this is a typeface peculiarity, I really don't think this should be used on Wikipedia and sister projects, especially as it is so noticeable on the Main Page. Timothy Gu (talk) 19:32, 12 January 2014 (UTC)

Max-width and large fonts

I have a wide monitor but I routinely tell my web browser to increase the font size for all web sites to avoid eye strain.

Needless to say, a "maximum width" that is based on displayed-pixels rather than "what would have been displayed, if it were displayed at 100%" pixels means I have a lot fewer words-per-line than is sensible, given the large amount of "unused" screen real estate.

My recommendation: Ditch the mandatory maximum-width-in-pixels, but enable it as a Preferences: item with a default of "no maximum."

70.251.134.187 21:29, 12 January 2014 (UTC)

All pages width shrunk

Some days ago the width of all Wikipedia pages went narrower than previously, I don't know why. I switched off "Typography refresh" because of this. --Misibacsi (talk) 21:42, 12 January 2014 (UTC)

• "It's not a bug, it's a feature" - and one that many are finding faults with. See #Max width / Narrow pages opt out option above for opt-out instructions. Davidwr (talk) 02:44, 13 January 2014 (UTC)

Mixing serif and sans serif

I think that using serif section headings and sans serif body text is silly looking. If the goal is to improve readability, I don't think that serif versus sans serif makes much of a difference at that size. If the goal is to look more classy or more professional, I think it backfired. Sorry, Sven Manguard (talk) 00:23, 13 January 2014 (UTC)

P.S. I'd much, much rather all sans serif than all serif. I don't see an issue with the font in use right now, to be honest. Sven Manguard (talk) 00:24, 13 January 2014 (UTC)

I'm very sorry but I have to disagree. The headings font is the most important change. One of several reasons: Level 3 to 5 headings were almost indistinguishable and level 6 headings looked exactly like bold paragraphs. --TMg 15:04, 13 January 2014 (UTC)

@Sven Manguard: "Silly" is fairly subjective. If we were using Comic Sans, I'd agree. ;) However, studies tend to show that users do react differently to serif type versus sans, when it comes to perceptions of seriousness, reliability, etc. This experiment by Errol Morris on the nytimes.com website is an amusing example of the phenomenon. As far as using all serif... I don't think this is objectionable per se, but as far as I know part of the goal of mixing is to more clearly differentiate headings from body text. Mixing different typefaces for headers and body is an extremely common technique for doing this, so we're hardly unusual in that regard. Last but not least: a primary goal of this experiment is to bring more consistency between our mobile typography and desktop typography. With that in mind, I don't think the design team will be removing the serif headings. As always, very advanced editors like the three of us are welcome to alter our experience using personal CSS. :) Steven Walling (WMF) • talk 22:00, 13 January 2014 (UTC)

I want to read Wikipedia and all sites in all-serif fonts as I don't like sans-serif and I find it difficult to read, so I've customized my browser to replace all sans-serif fonts with serif ones for all sites, and I read Wikipedia in serif since the site was founded. However, when I tried typography refresh I found out it doesn't change to serif text even though I've specified serif fonts in my browser, so I had to revert back to the old Wikipedia stylesheet. If typography refresh becomes the default and I can't change it, I'll have to find another way to substitute sans-serifs for serifs, but I believe it would be great if typography refresh could be made to adhere to the user's browser fonts settings. If that's not possible, then I think it would be good to make a fork of typography refresh with all-serif fonts. Cogiati (talk) 13:56, 14 January 2014 (UTC)

@Steven (WMF): While "the profession" seems to generally agree that “to more clearly differentiate headings from body text”, the type used for headings can be different from that of body text, it also generally agrees that there are limits on how much should be changed, and by what means. (“Don't overdo.” Really, any applicable book on typography—as opposed to graphics design—will explain, e.g. Tschichold's and others'.) Among the means are spacing and other visual cues (like a separating horizontal line above or below the heading), and there are about three dimensions of type along which to achieve differentiation:

• type (counting Italics etc. as separate ones)
• size
• boldness

Together with

• space           (around the heading)
• ♦ “graphical” cues

that makes five degrees of freedom, but there are only two differences to show: heading and level! I think it is safe to assume that changes along all dimensions will be overdoing things. The design uses type, size, boldness and, in addition, spacing and a horizontal separator. The phenomenon (too many changes in appearance) is known as one form of fontitis, and should be addressed. As a side note, another traditional way to reduce (apparent) clutter is to have baselines stay on a grid where possible, thus suggesting to place headings in a box whose height is a multiple of the baseline. (Yes, even on a computer screen without anything printed on the other side. Humans do recognize regular patterns.) GeorgBauhaus (talk) 17:31, 15 January 2014 (UTC)

The headings we are using in the MediaWiki projects don't use all these degrees of freedom. Especially level 4 and 5 headings look exactly like bold paragraphs (I really wish the refresh would fix that, see below). Other levels use slightly bigger sizes. That's all. That's like 1 and a half degree of freedom for the two dimensions. I don't think what the refresh does is overdoing. Especially since the discussed level 1 and 2 headings aren't bold. --TMg 20:53, 17 January 2014 (UTC)

Level 4 or 5 heading, bold or broken definition list?

Level 4 or 5 heading, bold or broken definition list?

Level 4 or 5 heading, bold or broken definition list?

Level 4 or 5 heading, bold or broken definition list?

Why not go on and fix this confusion too? I don't think the definition list should be changed. But all headings should. --TMg 20:53, 17 January 2014 (UTC)

Fuck no, please do not use Comic Sans.

I have to agree that I dislike having a serif font in headings. It's one of the main reasons I've turned off the typography refresh beta. The issues are covered (where else) in a Wikipedia article. The important thing (not covered in the article) is that distinct letter shapes give more information to the eye, allowing it to read faster. This is why ALL CAPS is slower and difficult to read—capital letters are all big boxes so the brain has to work harder to differentiate them without the shape cues. Sans-serif type is less shaped than serif, and therefore a little slower. But in the case of a heading, you want to slow the eye down. Obviously this rule is often broken (for example, the New York Times), but I certainly prefer the convention. It doesn't bother me that we use sans-serif type in the body, although I certainly think it's worth exploring serif options. Fnordware (talk) 02:44, 21 February 2014 (UTC)

Malfunction

I point out the malfunctioning of the Typography refresh in the beta version. All pages of Wp are blank on the right side. Removing Aggiornamenti tipografici (Typography refresh), the pages return to normal, as before. Thank you. --Antonella (talk) 01:15, 13 January 2014 (UTC)

• "It's not a bug, it's a feature" - and one that many are finding faults with. See #Max width / Narrow pages opt out option above for opt-out instructions. Davidwr (talk) 02:43, 13 January 2014 (UTC)

Missing icons for collapsible side bar and drop-down in tab bar

When I enable VectorBeta, the triangle icons in the side bar and the tab bar are missing, the CSS says something like url("VectorBeta/less/images/arrow-down-icon.png?2014-01-02T16:50:00Z") for the background-image of div.vectorMenu, which seems not to be resolved correctly. The URL should include the server and full path, url(//bits.wikimedia.org/static-1.23wmf9/extensions/VectorBeta/less/images/arrow-down-icon.png?2014-01-02T16:50:00Z) works for me. --Schnark (talk) 08:28, 13 January 2014 (UTC)

@Schnark: Hmm. I can't replicate this problem on Chrome. What browser/OS are you using? Also: can you check if you've enabled any other Beta features recently? Thanks for reporting this, Steven Walling (WMF) • talk 21:54, 13 January 2014 (UTC)

@Steven (WMF): I use FF10 (you don't have to tell me it is old, tell it to my university). You can't reproduce as you probably use a browser which uses the embeded SVG. FF10 falls back to PNG (the linear-gradient-hack doesn't work, as FF10 still needs the -moz- prefix), which uses the relative path I already copied above, and which seems to be resolved wrongly. Here is the uncompressed CSS for reference:

  div.vectorMenu {
    /* @noflip */
    direction: ltr;
    /* @noflip */
    float: left;
    /* SVG support using a transparent gradient to guarantee cross-browser
	 * compatibility (browsers able to understand gradient syntax support also SVG) */
    background-image: url(VectorBeta/less/images/arrow-down-icon.png?2014-01-02T16:50:00Z);
    /* SVG support using a transparent gradient to guarantee cross-browser
	 * compatibility (browsers able to understand gradient syntax support also SVG) */
    /* @embed */
    background-image: -webkit-linear-gradient(transparent,transparent), url(VectorBeta/less/images/arrow-down-icon.svg?2014-01-02T16:50:00Z);
    background-image: linear-gradient(transparent,transparent), url(data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9Im5vIj8+CjwhLS0gQ3JlYXRlZCB3aXRoIElua3NjYXBlIChodHRwOi8vd3d3Lmlua3NjYXBlLm9yZy8pIC0tPgoKPHN2ZwogICB4bWxuczpkYz0iaHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8iCiAgIHhtbG5zOmNjPSJodHRwOi8vY3JlYXRpdmVjb21tb25zLm9yZy9ucyMiCiAgIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyIKICAgeG1sbnM6c3ZnPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIKICAgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIgogICB2ZXJzaW9uPSIxLjEiCiAgIHdpZHRoPSIyMiIKICAgaGVpZ2h0PSIxNiIKICAgaWQ9InN2ZzIiPgogIDxkZWZzCiAgICAgaWQ9ImRlZnM0IiAvPgogIDxtZXRhZGF0YQogICAgIGlkPSJtZXRhZGF0YTciPgogICAgPHJkZjpSREY+CiAgICAgIDxjYzpXb3JrCiAgICAgICAgIHJkZjphYm91dD0iIj4KICAgICAgICA8ZGM6Zm9ybWF0PmltYWdlL3N2Zyt4bWw8L2RjOmZvcm1hdD4KICAgICAgICA8ZGM6dHlwZQogICAgICAgICAgIHJkZjpyZXNvdXJjZT0iaHR0cDovL3B1cmwub3JnL2RjL2RjbWl0eXBlL1N0aWxsSW1hZ2UiIC8+CiAgICAgICAgPGRjOnRpdGxlPjwvZGM6dGl0bGU+CiAgICAgIDwvY2M6V29yaz4KICAgIDwvcmRmOlJERj4KICA8L21ldGFkYXRhPgogIDxnCiAgICAgdHJhbnNmb3JtPSJ0cmFuc2xhdGUoMCwtMTAzNi4zNjIyKSIKICAgICBpZD0ibGF5ZXIxIj4KICAgIDxwYXRoCiAgICAgICBkPSJNIDEwLjAyODYyNCwzLjc3Mjk5MzIgOC4xOTc2NDQyLDYuOTQ0MzQyNCA2LjM2NjY2NDksMy43NzI5OTMyIHoiCiAgICAgICB0cmFuc2Zvcm09Im1hdHJpeCgyLjczMDc3OTEsMCwwLDEuNTc2NjE2LC0xMS44ODU5NTYsMTAzNi40MTM2KSIKICAgICAgIGlkPSJwYXRoMjk4NSIKICAgICAgIHN0eWxlPSJmaWxsOiM3OTc5Nzk7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlOm5vbmUiIC8+CiAgPC9nPgo8L3N2Zz4K);
    background-image: linear-gradient(transparent,transparent), url(VectorBeta/less/images/arrow-down-icon.svg?2014-01-02T16:50:00Z)!ie;
    /* @noflip */
    background-position: 100% 60%;
    background-repeat: no-repeat;
    cursor: pointer;
  }

I highlighted the line which is meant as fallback for old browsers, but doesn't work as expected. --Schnark (talk) 08:17, 14 January 2014 (UTC)

Vector and VectorBeta seem to use the same LESS file, but the compiled CSS in Vector is an protocol-relative URL starting with //bits.wikimedia.org/, so you should either use protocol-relative URLs for your paths (like in core), or claim it is a bug in RessourceLoader, and open a ticket to transform all paths to a working form there. --Schnark (talk) 10:54, 15 January 2014 (UTC)

[8] should fix this. --Schnark (talk) 10:16, 20 January 2014 (UTC)

Liberation Sans too narrow when compared with other fonts

Screenshot of de:Internationale Mathematik-Olympiade#Ablauf to compare fonts used in VectorBeta.

The current font-stack is "Nimbus Sans L", "Liberation Sans", "Helvetica Neue", "Helvetica", "Arial", sans-serif. I don't have Nimbus Sans L, so I can't say anything about it, but Liberation Sans is too narrow, especially when compared to Helvetica Neue. The screenshot uses the default fonts in the first window, for the second window I removed Liberation Sans. Note how different they look. IMHO the second one is much more readable, so I think Liberation Sans shouldn't be used. --Schnark (talk) 08:32, 14 January 2014 (UTC)

@Schnark: that looks a bit to me like it is using "Liberation Sans Narrow" instead of Liberation Sans". Would you happen to know if you have both or one them installed ? TheDJ (talk) 13:56, 14 January 2014 (UTC)

Another reason to stick with system fonts as requested above by simply specifying a generic font family, which is the best we can do after all (at least for normal text; headings might be given a more specific font as far as I'm concerned). --Patrick87 (talk) 17:53, 14 January 2014 (UTC)

@TheDJ: You are right, I have "Liberation Sans" in C:\Windows\Fonts, but it only contains "Liberation Sans Narrow" (to be exact: /Liberation Sans Halb Schmal( Fett)?( Kursiv)?/, where Schmal is German for Narrow). I don't think the system administrator of my university did anything special about this font, so this could affect many Windows 7 users. --Schnark (talk) 08:39, 15 January 2014 (UTC)

Can't replace sans-serif with serif

I wanted to use typography refresh but I found out it doesn't let me change to the serif fonts I prefer reading Wikipedia in, so I was forced to revert to the default stylesheet (which does change to serif fonts when I customize my browser to display serif fonts whenever a stylesheet specifies sans-serif). Many users (myself included) want to read Wikipedia and all sites with serif fonts rather than sans-serif, and those who do often change their browser font settings to make the browser display all text with serif fonts. If typography refresh were to become the default and I couldn't change it, I'd have to find another way to be able to read Wikipedia in serif fonts. It would be great if we could make a fork of typography refresh with all fonts being serif. Cogiati (talk) 13:42, 14 January 2014 (UTC)

• Also, as a general philosophy, I think it is the user who should decide what font to read webpages in, so CSS stylesheets should be made in a way that allows the user to replace one general family font (e.g. sans-serif) with another (e.g. serif) and still work satisfactory. Web designers shouldn't assume that users see the webpages in the fonts they specified, as many users strongly prefer serifs over sans-serifs since sans-serif fonts are difficult to read. Cogiati (talk) 13:50, 14 January 2014 (UTC)

Text should be in the center

Article text should be in the center of the screen. Sometimes users like myself use Wikipedia with very big zoom levels (300-500%), e.g. when using Wikipedia as a foreign language teaching tool or when sharing a screen with another person who is far away from the screen. When using extreme zoom levels, the distance of the text from the left side becomes far too extensive. In fact I think it would be better to place all the links currently on the left as horizontal links above or below the article text. After all, after reading somewhat into the article, we don't see the links anymore and all we see is an empty gray sidebar on the left. The perfect style for Wikipedia would be to use the whole screen width for the article text, and have the various links etc above and below the article. This would give users more control over where to position the text (e.g. I currently use a non-maximized browser window to place Wikipedia's text on the center of the screen because of the left sidebar, but if there were no sidebars I could use my standard maximized browser window just fine). Cogiati (talk) 14:07, 14 January 2014 (UTC)

Remove blue icon from images

Placing a blue icon over images is a bad idea. As a photographer myself I hate websites that place anything over my photos :) (in fact that's why I stopped sharing my photography on Facebook a long time ago). As a user, when I see an image in an article I expect to see the whole image rather than have some of it hidden by the blue icon. Cogiati (talk) 14:10, 14 January 2014 (UTC)

There are some beautiful redesigns of the thumb template above, and all of them (as well of the original thumb look) are vastly preferable to having an icon over the image. Frankly, I would find that putting anything over the image changes the image, and saps it of part of its educational value. That being said, the blue icon does not appear to be part of the current version of typography refresh (as it is deployed to EnWiki). Sven Manguard (talk) 20:35, 14 January 2014 (UTC)

The blue icon is only displayed when ‎<imagemap> is used, and is not related to the typograpfy refresh beta. — Edokter (talk) — 16:57, 15 January 2014 (UTC)

… but should be, see above. --TMg 18:32, 22 January 2014 (UTC)

In summary...

I have been testing the typography refresh locally (not on enwiki), and I must say it is not going the right direction. Knowing full well that each has their own opinion, here are my findings.

1. The constant switching of preferred fonts in the fontstack always reveals some issue on one platform or the other. Now that Nimbus Sans L is the primary font listed, I am met with a less-then-optimal rendering. Liberation Sans fares better, but is slightly narrow, but otherewise looks nothing like Helvetica. The initial goal was to have a Helvetica-like font on all platforms. In that regard, Helvetica should have remained the primary font (not Neue, as that is rarely mapped to a suitable substitute).
2. I like Georgia as a header font, but realize that Linux has outdated fonts lacking Unicode support. DejaVu serif is a good second but it is just not a very pretty font for headers. If serif is the goal, perhaps a more generic serif like Times should have been chosen.
3. There are some experiments with layout that have gone totally bad. First the UI links were all black, which was fontunately reverted. Now it is the restriced horizontal space that is an issue. Doing so in a hard-code value in px is a big no-no in any web layout where the rest of the page behaves fluidly, so that should be reverted as well. This is the "typography" beta; so stick to typography.
4. Likewise for image thumbs. This should not be touched, as it has nothing to do with typography. In fact, every change that interferes with core- or skin CSS other then fonts should be reverted.
5. All beta-related CSS is loaded after site and user CSS, which causes a lot of site/user CSS to fail, especially where non-typography related CSS is used. Make sure the CSS is loaded (if possible) before site/user CSS.

Perhaps the typography refresh should be restriced to the content, and not the rest of the UI. I feels like you are trying to redesign the Vector skin, which is just out of scope of this beta, instead of just improving readability. — Edokter (talk) — 17:21, 15 January 2014 (UTC)

Regarding the fonts, I for one think that if we're going to be specifying specific fonts at all then we should be preferring libre fonts over proprietary fonts like Georgia, Helvetica, or Times, just as we prefer free software solutions when available (see foundation:Guiding principles#Freedom and open source). Those could be fallbacks for people on systems without free fonts, but shouldn't be preferred in our design over free fonts. Anomie (talk) 14:16, 16 January 2014 (UTC)

To what end? This would neither aid in content distribution nor promote the adoption of libre fonts. It would merely ensure the existence of visual differences (however minor) on systems that happen to contain said fonts — arguably a penalty. —David Levy 17:36, 16 January 2014 (UTC)

We certainly shouldn't contribute to the encouragement of non-free fonts. Also, I'd consider it to be people without free fonts are the ones being "penalized" by visual differences. Anomie (talk) 14:24, 17 January 2014 (UTC)

Ugh... we have been over this already. The preference of free fonts serves no practical purpose whatsoever. Fonts are part of the client software; they are part of the OS. All the font stack does is say "use this font (when available)". We should not "prefer" fee fonts over proprietary fonts, just as we do not "prefer" the use of Firefox over Internet Explorer, or even Lunix over Windows. The average reader is completely oblivious to this font-ideology, but it will hurt them if they are forced to use fonts that risk being illegible on their native OS. — Edokter (talk) — 13:31, 18 January 2014 (UTC)

We aren't encouraging the adoption of non-free fonts. These particular fonts' ubiquity is one of the reasons behind their selection. Virtually no one will obtain them as a result of anything done within MediaWiki. Likewise, if MediaWiki were to favor libre fonts, very few users would even realize this (let alone act on it). However, a fair number would download the libre fonts at some point (for unrelated reasons) and suddenly find that their favorite wikis look different. How would this benefit anyone?

My reply already is overlapping that of Edokter (who covered the ideological issue well), so I'll stop there. —David Levy 00:20, 19 January 2014 (UTC)

Hey Edokter, in reply to your comments number-by-number...

1. You're absolutely right about this, and we'll make some changes accordingly. Like you elaborate on in this thread, it really is not accomplishing what we want with improved typography to put the less-than-optimal free/open fonts first. And if we put them later in the font stack, they are completely ignored once an OS gets a font like Helvetica Neue or regular that it can match.
2. Thank you for pointing this out. After testing both Chrome and Firefox (which behave slightly differently) on Ubuntu, we decided to set the headings stack back to 'Georgia, Times, serif'. This will mean most Linux users (except for those who downloaded extra fonts) will use the widely-available Nimbus Roman No9 L instead of DejaVu Serif. Nimbus matches our intended serif much better.
3. We'll probably be including more layout changes in the future, and probably change the beta feature to match its extension name ("Vector Beta" instead of just typography). This will make the scope less of an issue.
4. Comment three applies here too.
5. This is a nasty bug if it's happening, but I can't replicate it with my own mix of beta feature/personal Vector CSS. Can you file a bug and we'll get an engineer to investigate further?

Thanks for the helpful feedback. Steven Walling (WMF) • talk 00:32, 21 January 2014 (UTC)

Steven:

In response to #3, does this mean that whatever typography changes are eventually implemented won't reach the other skins?

Also, perhaps you could address my comments in the Analysis/screenshots subsection (including my reply to Jared Zimmerman). If so, I'd sincerely appreciate it. —David Levy 00:49, 21 January 2014 (UTC)

I won't say never, but this design is intended only for Vector right now. There's nothing stopping people from requesting changes be applied to Monobook as well, but it's not something we're going to push from the WMF end as far as I know. Steven Walling (WMF) • talk 01:16, 21 January 2014 (UTC)

In response to #5, I found that CSS is loaded in the following order: site (common - skin) - gadgets - beta - user. Does that sound about right? — Edokter (talk) — 13:37, 21 February 2014 (UTC)

Bug with the 715px layout

A couple thoughts about the new max-width layout:

• There seems to be a bug with some sidebars like this one caused by the line #content .navbox, #content .vertical-navbox { display: inherit; }.
  • Actually, this is a bug with the Nearby Pages beta and has already been fixed. Neil P. Quinn (talk) 02:13, 20 January 2014 (UTC)
• I really, really like the idea of limiting the article itself to a more readable width and moving infoboxes and images into the right margin. I've even tweaked my user styles to try it out for myself. Kudos for thinking big!
• However, like many people here, I thought the size change was a bug at first and only learned otherwise after coming to this page. Honestly, the change seems much more appropriate for a nightly than a beta release—personally, I'd want to present a complete experiment (i.e. at least take a stab at dealing with the most obvious downsides and at actually moving the infoboxes and images) rather than push out a partial, off-the-cuff experiment to thousands of users who will all assume it's a big mistake and get irrationally annoyed. And I'd definitely want to separate it out from the typography refresh so it can be considered (and disabled) separately. I think you're on the right track—but I'd say do it with a bit more deliberation.

Neil P. Quinn (talk) 07:53, 17 January 2014 (UTC)

Thanks for sharing your custom vector.It looks great indeed. On my 1920x1080 screen, I bumped the font size to 20px and width to 1000px and it is a great readability improvement imho.Far better than just zooming in as I usually do. I also like the idea that reflist remain multicolumns. I added the "@media screen (max-device-width : 1920px)" "(max-device-width : 1280px)" to adjust my font-size in function of the resolutions of the screen I usually use. --Afernand74 (talk) 11:02, 18 January 2014 (UTC)

White background on right side and simmetry

I will never use Vector unless the police seizes my computers and forces me, so I'm not personally affected by this experiment, but I wanted to check this screenshot.

I don't understand, how can anyone consider it acceptable to have a white background on the right, and a grey background on the left? A light blue line on the left as border for the content, and nothing on the right? They need to be consistent with each other: that white invasion looks like an unbalanced div or something equally horrible happened to the page. This is only partly covered by #Why can't you center the page?: whatever you place in that white area, they'll only look like abandoned debris in a sea of desperation (however big or small the sea is; I leave the 715px discussion to others). --Nemo 23:33, 3 February 2014 (UTC)

I completely agree with you here. the white column on the right looks unbalanced. In order to balance the whitespace even somewhat elegantly, we have to work out a significant amount of details for the left nav, the top right header, community elements of semi protection, featured articles. Centering it right now may alleviate the white-space but will have 10 side effect problems. Vibhabamba (talk) 23:07, 5 February 2014 (UTC)

Rethinking Narrow Pages from the Start

I see similar debates all over this page, but I think I can reframe the issue well.

There must, indeed, be a balance between line height and line width for easy reading. On the other hand, white space should not be wasted. White space may be very useful in design, but the current design is not useful whitespace, it is waste--it is half a blank screen. How can we reconcile our need to have a body of limited width with our other need to use screen real estate efficiently or at least pleasantly? The right half of the screen being white is simply not an option. In its place, what should we do? I'll offer a few ideas, and we can discuss under each, and add more. DanHakimi (talk) 03:11, 19 January 2014 (UTC)

• Media and Quotes. Move media to the right side of the page. Allow people to add quotes about the topic and pullquotes from the article. These will fill the space, look nice, and be useful -- the media for whatever reason it is already there, and t he quotes and pullquotes to offer more information at-a-glance. The problem, of course, is that when there is no media and nobody has put quotes on the page, this solution does nothing. DanHakimi (talk) 03:11, 19 January 2014 (UTC)

@DanHakimi Are you suggesting that we no longer allow users to left align their images? Maybe we do that because of the original manual of style, But I think it allows for two important things. 1. It allows users to associate image with text as they like (Left, Center or Right). I think this is important because sometimes text and image work in combination to illustrate a piece of information. 2. It really helps to break the monotony of the content. Curious to hear your thoughts. Thanks, Vibhabamba (talk) 23:03, 5 February 2014 (UTC)

• • Media idea is ok but don't put user quotes into the article body (or at the side); they'll be often obnoxiously useless, difficult to moderate, and confusing for the reader. Keeping the talk namespace separate sounds reasonable. --Gryllida 03:43, 22 January 2014 (UTC)

@Gryllida This article https://en.wikipedia.org/wiki/Rumi is a really good example of how the block quotes need ot be connected with the article text. Even if they persist in the right panel, they have to occur at the same vertical height which would mean adding serious structure to the right column. Vibhabamba (talk) 23:03, 5 February 2014 (UTC)

• Table of Contents. Have the right side of the page be a scrolling table of contents. This will fill the page, and allow people to jump around much more easily. It might not be as pretty as the above, but at least it will be more consistent. DanHakimi (talk) 03:11, 19 January 2014 (UTC). This is connected to an idea that we are exploring with a persistent header. Vibhabamba (talk) 23:03, 5 February 2014 (UTC)

  Building on this, what if the header of the current highest section appeared on the right, above or in the table of contents, and we used one of those javascript scrolling libraries to animate it to change when you reached the next section? That would look good, and be useful for sections that are more than one scroll-height long. DanHakimi (talk) 03:11, 19 January 2014 (UTC)

  I like your TOC idea, but in the context of the problem under discussion, these suggestions are based on the assumption that a relatively small amount of space (perhaps not substantially exceeding the portion occupied by text) has been left empty. To understand why such changes wouldn't necessarily "fill the page", please see the Analysis/screenshots subsection. —David Levy 08:08, 19 January 2014 (UTC)

  Well, I think it's still better to use some of that space than none of it. I also want to note that if the design is responsive, we can put together different solutions for screens with different widths/resolutions/aspect ratios. DanHakimi (talk) 14:21, 19 January 2014 (UTC)

  As I noted, I like the TOC idea. I just don't see it as a viable solution to the current problem (though I agree that it could serve as an element of one). —David Levy 17:22, 19 January 2014 (UTC)

  • Fear it could be too confusing.

  My screen is small and seeing TOC occupy the previous screen space in the margin would conflict with the images... It would be just too jumpy.

  Optionally implement a small 'go to top' button? :-)

  --Gryllida 03:07, 29 January 2014 (UTC)

  • By the way, in the left sidebar, after languages end, there could be a floating ToC, until someone comes up with better use for that empty space...

  Gryllida 03:24, 29 January 2014 (UTC)

• Two-pane system. This one would take time to make, and might be tricky... Is there some sort of system where we could have two Wikipedia pages next to one another, active at once, for comparison? I'm not particularly fond of this sort of setup, for a number of reasons, but figured I'd offer the idea. DanHakimi (talk) 03:11, 19 January 2014 (UTC)

  Users can simply open two browser windows and arrange them however they please. The native ability to display two pages in a single browser window isn't a bad idea, but even if most/all of the screen real estate were used under such a setup, this isn't something that readers would do most of the time. —David Levy 08:08, 19 January 2014 (UTC)

  • Too confusing for an average reader, sorry. :) --Gryllida 03:44, 22 January 2014 (UTC)
• Font Scale. Could we scale up the font on larger screens? This is what I do with my fixed 80 character width consoles, and it looks quite nice to me. I guess it's hard to vary font size responsively, but... Is it doable? Does it look good that way? DanHakimi (talk) 14:23, 19 January 2014 (UTC)

  While technically feasible (and certainly preferable to the current experimental implementation), I'm not sure that this is a desirable direction for MediaWiki to take.
  If a reader wants larger text, he/she can increase the browser's text size. Many people prefer filling their high-resolution screens with smaller text, thereby seeing more at once. Why eliminate the choice? —David Levy 17:22, 19 January 2014 (UTC)

  @DanHakimi: That suggestion is what http://simplefocus.com/flowtype/ would do, as suggested above and elsewhere. I agree with others, that this would be a problematic option, as it removes choice. Eg. I like seeing dense tables of information in full-width, without excessive wordwrap (en:List of churches preserved by the Churches Conservation Trust in Southwest England or en:List of counties in Arizona etc). Eg2. I sometimes like to have as many paragraphs onscreen as possible, to make content-rearrangement easier. (However, it's good that you added it to this list of possibilities. It could potentially be a button/toggle. :) –Quiddity (talk) 04:08, 20 January 2014 (UTC)

Once we have a persistent header we plan to add font controls so a user can start with a default optimum but adjust the font size based on their screen size. Vibhabamba (talk) 23:03, 5 February 2014 (UTC)

When not using the 100% width...

...put the pictures thumbnails into the margin. Otherwise text sideways of them, with them in the narrow column, is unreadable. --Gryllida 03:41, 22 January 2014 (UTC)

Also infoboxes and everything that gets in the way of text. (Full-width tables don't.) --Gryllida 05:58, 22 January 2014 (UTC)

That's my main concern, too, see above. --TMg 18:35, 22 January 2014 (UTC)

+1 DanHakimi (talk) 21:40, 25 January 2014 (UTC)

@Gryllida, @DanHakimi Users can currently add images which float left. So, this will continue to be problem for the left column. Thoughts? Vibhabamba (talk) 22:48, 5 February 2014 (UTC)

2¢

I just want to list what my personal preferences would be for these changes after having lived with them for a while:

In general I like the idea of limiting the page widths of articles. I've seen some otherwise very good Wikipedia articles that, because of the way they are layed out, with lists 3 or 4 columns wide and images on both sides, are difficult to read unless expanded to a couple thousand pixels wide, which I don't usually do, partly because I have other documents open on the screen that I don't want to cover, and partly because long lines are hard to read. Limiting the width will force writers lo lay out articles for more "normal" window widths.

But I do agree with some others above that 715px is a little too narrow for a max width. 800px fits perfectly on the widescreen monitor that I use in the portrait position for reading PDFs and Wikipedia articles. It also fits well with two browser windows open side-by-side with monitor in the normal position.

However, the combination of the narrow page width an larger font-size causes problems with many of the existing tables that were set up to be read at larger widths and a smaller font. So perhaps wikitables could be exempted from the change. It's like tables in a book that you need to turn sideways to read, only here you would only need to widen your window or scroll sideways to see it all. Some tables need to be wide to be meaningful. Categories, including image categories, should also be exempted. In fact I don't think a narrow screen restriction is appropriate for most of Wikimedia Commons.

The larger font-size is probably a good idea. It helps a little on some monitors, but doesn't matter on others, except for causing the table problems that I mentioned above.

I don't mind the mixing of fonts for headings mentioned by some. I think I would actually prefer a serif font for the text body too. I've never believed the studies showing that sans-serif fonts are easier to read on a computer monitor. — Nonenmac (talk) 19:12, 26 January 2014 (UTC)

Font choice and column width choice are too dependent on individual setups to be made into a rule: what is needed is a very simple way for people to specify what they want, without going into CSS. We will still need something for non-logged in users, but even they can be encouraged to change for an editing session. DGG (NYPL) (talk) 19:29, 27 January 2014 (UTC).

Heh. 600px screen width here. :o

And some of it is the skin sidebar with languages and the like.

--Gryllida 03:08, 29 January 2014 (UTC)

@Nonenmac, we are still examining the measure against column layouts & tables. Measure will not apply to special pages and history pages. The measure of 715px is being derived from the ideal no of characters (45-75) or words we want to accommodate in a line. We want to have some cushion for international scripts where the average character is wider. Vibhabamba (talk) 22:45, 5 February 2014 (UTC)

image thumbnail styling

I noticed the frameless images, and I must say it's a refreshing refreshment. That one's a keeper. Since you're experimenting, try out a credit line too!--Ragesoss (talk) 11:20, 28 January 2014 (UTC)

Although totally frameless makes them very hard to distinguish from the text. I'd like something along the lines of TheDJs proposal above much more. --Patrick87 (talk) 13:15, 28 January 2014 (UTC)

@Ragesoss, something like that (but far from finished) is part of the multimedia viewer beta right now. TheDJ (talk) 08:03, 30 January 2014 (UTC)

May I offer my ideas? There is an experimental gadget on enwiki that I intend to develop into a more comprihensive CSS framework. — Edokter (talk) — 22:34, 2 February 2014 (UTC)

Significant improvements to the Viewing experience will be done between the Multimedia and design team. I recommend moving this discussion to the Multimedia Page, since there are other 'mouse out and hover state' requirements around images. Please see - https://www.mediawiki.org/wiki/Multimedia. Thanks, Vibhabamba (talk) 22:31, 5 February 2014 (UTC)

Revert to first version of Typography refresh

I think that the version rolled out initially was best. I liked some changes made to sidebar. One problem was unwanted braked which I think can be avoided by decreasing padding.--Wikiuser13 (talk) 17:56, 28 January 2014 (UTC)

Thanks Wikiuser13. We think that the image and captions treatment is an important enhancement that came as part of the second set of changes. Currently, the text is practically running into images and captions. The improved whitespace will create good rest areas for the reader's eye. Could you clarify your comment on 'unwanted breaks' and some examples of where you are seeing these? Thanks, Vibhabamba (talk) 22:18, 5 February 2014 (UTC)

Documentation out of date

The subject page doesn't mention the 715px max-width restriction. Given this is the most striking change when enabling this beta feature (and the most controversial), it really should be mentioned in the documentation. – PartTimeGnome (talk | contribs) 16:56, 1 February 2014 (UTC)

@Steven (WMF) and Jaredzimmerman (WMF): ^. You could either copy the details from #Update to Typography refresh (currently at the top of this page), or write something else. I'm not sure what you'd prefer. –Quiddity (talk) 20:33, 2 February 2014 (UTC)

PartTimeGnome It is mentioned in the documentation under Additional Ideas we are trying Here is the rationale - The Max width is being set at 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.[9], [10], [11],[12] The max width will not apply to Special pages (like Prefences), We are still testing a whole lot of special pages. Vibhabamba (talk) 22:15, 5 February 2014 (UTC)

Vibhabamba: The request is concerning the subject page (Typography refresh), which is linked to from "Information" at every wiki participating (in their individual Special:Preferences#mw-prefsection-betafeatures). It's the primary documentation page, and hasn't been updated in a while. Thanks! –Quiddity (talk) 22:46, 7 February 2014 (UTC)

"gracefully degrades"

I cant translate "body gracefully degrades to Arial". WOuld you please paraphrase this　passage?--miya (talk) 14:02, 4 February 2014 (UTC)

@Miya: I think (but someone else should confirm) that this means something like "if the ideal font is not available (in other words, if we are forced to 'degrade' to a lesser font), then instead of picking a random or ugly font, it will use Arial (in other words, it will degrade 'gracefully' rather than in an ugly/unpredictable manner)". —LVilla (WMF) (talk) 00:19, 5 February 2014 (UTC)

@miya By graceful degradation we mean, that we specify fonts for all our grade A best browsers and ensure that as the various layers of CSS3 are peeled away on older browsers, those users still get a usable experience. For certain Browsers and operating systems Helvetica is not a base font, in those cases the type will default to Arial, which ensures that our objectives of readability at various sizes (Body Copy, Captions, References) are met. Vibhabamba (talk) 22:07, 5 February 2014 (UTC)

@LVilla (WMF) and @Vibhabamba, thank you! Now I can grasp the situation at last! --06:51, 6 February 2014 (UTC)

Lock icon on locked pages with long titles ends up in a funky place

This is a sort of edge-case, very cosmetic, issue, but FYI: on a locked page with a long title, the lock icon can end up overlaying the title text because of the narrow column width. For example, on my screen, the lock icon has ended up merged with the capital S in this page's title. —LVilla (WMF) (talk)

LVilla (WMF), We need to reserve a space for things like Semi protection, featured article icons etc in the top right area. Making a note to Brandon who is working on the Fixed Header experiment. Currently we haven't addressed where these elements will end up. But my initial thoughts are - 1. It feels like semi-protection should be more closely connected with the 'Edit' action 2. Featured Article Should be connected with article title Vibhabamba (talk) 21:53, 5 February 2014 (UTC)

Previewing discussion is broken

On en.wiktionary, discussion pages have fixed width, but the so-called editing preview has a fluid page width. So the new workflow for posting a comment is:

1. Select Edit (there is no Edit | Edit Source here) and type a comment
2. Select Preview
3. Adjust your text and select Save Page
4. View the discussion, discover that the layout doesn’t match the preview, and your screenshot narrows your indented paragraph to a width of 1½ words
5. Edit and adjust again – using guesswork instead of the preview. Save Page
6. Repeat as necessary

A preview should try to look like what it is previewing. Otherwise it is just like “nyah nyah!” —Michael Z. 2014-02-05 21:10 z

TOC broken

The table of contents is broken - literally: Long headlines break into two lines, and without the numbers it is impossible to tell, whether there are two different headlines or just one. For example w:Wikipedia:Village_pump_(miscellaneous) looks like this:

Photos taken of members of the European
Parliament
Please remove username and edit count from the
new pages feed

No, there isn't a headline "new pages feed", it belongs to the line above, but you just can't tell from looking at it. --132.230.1.28 10:11, 14 February 2014 (UTC)

I agree, ToC without numbering is painful in case of long section titles (cf above).

Moreover, I have the same feeling in case of any long ToC (e.g. [13]) and it gets even worse when plenty of sections are at the same level (browse a long ToC then go to a section and read it, then go back to the ToC... without numbering, it's not easy to continue looking for other interesting sections in the ToC... see f.i. [14]).

Klipe (talk) 16:48, 14 February 2014 (UTC)

Klipe Thank you for bring this to our attention. This is happening because of the measure (715 px width). If we revert the measure (which we are working on) individual list items in the TOC will not wrap.

Numbering : Agreed that numbers were long standing convention in the TOC. If you look closer, Numbers aren't reflected in the actual sections/ subsection headers. Its strange to carry the number in one place and not in the other. Now, introducing the number in the section/subsection titles would introduce a new noisy element that distracts from reading. There are no functional compromises here, the numbers that can be upto 5 numeric characters long are not actionable in any way. The focus of this update has been to eliminate noise and we believe the indentation is sufficient to reliably scan the TOC. Do you feel like this is a reasonable compromise to reduce the noise on the page? thanks Vibhabamba (talk) 22:17, 14 February 2014 (UTC)

@Vibhabamba: Note that Section titles can be any length, and are often quite long on discussion boards. See en:Wikipedia:Administrators' noticeboard (with Typography refresh on) and see how confusing the ToC is. They need a bullet point, at minimum. –Quiddity (talk) 23:08, 14 February 2014 (UTC)

I've used this code in my vector.css for years months:

* Tweak Table of Contents boxes, to have smaller numbers and dot-suffixes */
.tocnumber:after, .mw-headline-number:after { content: "." }
.tocnumber, .mw-headline-number { font-size: 80% !important; color:#333 !important;}

it looks like this: [update below] http://i.imgur.com/f0xcBC9.png (before and after). Making the numbers not-blue, would also help. I'd suggest that, instead of removing the numbers. –Quiddity (talk) 23:24, 14 February 2014 (UTC)

An improvement must pass a squint test. If I squint at this, it looks just as noisy as the previous version. Vibhabamba (talk) 02:27, 15 February 2014 (UTC)

@Vibhabamba: Updated screenshot with #333 (dark grey) numbers: http://i.imgur.com/k3ipFKz.png

Also, In an ironic turn of events, whilst trying to find the origin of the code above, I stumbled on this old 2007 thread where I ask for the numbers to be removed from the ToC. According to my monobook.css, I only used that tweak for 6 months though. –Quiddity (talk) 18:59, 15 February 2014 (UTC)

@Vibhabamba: Personally I've never felt the discrepancy between numbered ToC and non-numbered section titles as an issue when reading pages on the screen. Most of the time, I read just parts of an article instead of the whole of it: based on the ToC, I jump to a few selected sections. I use the numbers to quickly find back where I was in the ToC when coming back to it. Klipe (talk) 00:41, 15 February 2014 (UTC)

Klipe I do see your point, but we need to employ patterns that work for most people. Clicking on the section in the TOC does the same thing without without a number. The functionality seems ambiguous. Vibhabamba (talk) 02:30, 15 February 2014 (UTC)

Vibhabamba When I wrote "jump", I means by clicking on the ToC entry, of course. But when coming back to the ToC, I find numbers help me find back where I was before having clicked to read a specific section. Not sure why, since I don't explicitly remember numbers: it's just something I realise when comparing with vs without typography refresh active. Klipe (talk) 13:07, 18 February 2014 (UTC)

I like Quiddity's proposal a lot: keep the numbers and add a final dot to them while at the same time de-emphasising them a bit (no blue, and for once I would probably even be glad with some dark grey instead of black).

By the way, when I decide to read many sections of a long article (or talk page), I usually print it out and read it on the bus on my way to work. Numbered section titles would definitely help in that case, while removing numbers from the ToC wouldn't! Klipe (talk) 00:41, 15 February 2014 (UTC)

@Klipe: Re: Numbered section titles: in Special:Preferences#mw-prefsection-rendering there's an "Auto-number headings" option which does this. :) –Quiddity (talk) 01:31, 15 February 2014 (UTC)

@Quiddity: Yes and no. Indeed, this option numbers the sections and the ToC entries in print mode. But these numberings are not very much readable: there is no other separator between the number and the start of the section title than a space. At least these numbers should end with dots. Moreover, when reading on screen, this option only numbers the sections and not the ToC entries ! A bug, I hope ? Klipe (talk) 13:07, 18 February 2014 (UTC)

I left some notes at your talkpage.

Just FYI: I asked the research team if the "Auto-number headings" pref is used much, and apparently 31636 users have this preference enabled on Enwiki. More than I expected! –Quiddity (talk) 20:15, 19 February 2014 (UTC)

I don't understand, is this TOC thing (whatever it is) going to become default too? The page doesn't say anything about it, what does it have to do with typography? How can people give feedback about something if they don't even know about its existence?
If I look at a long page with the beta "refresh" on, e.g. [15], the TOC seems quite harder to navigate/skim: to see what a sub-section belongs to, I now have to carefully "climb" the indentation making sure not to carelessly jump one section above, while I could previously just look the first number. It also gets harder to get a precise sense of the structure and general development of the page, e.g. how many sections there are. Italo Calvino wrote (I think in Una notte d'inverno un viaggiatore but I'm quoting out of memory) that it's natural for every reader to check how many pages a book has, when beginning it, to assess what toll the reading will take. The numbers of sections is our online equivalent.
Now, these are just quick impressions/opinions, but on the other hand I similarly don't see any rationale for this undocumented unannounced unnamed unexplained change sneakly delivered on the bandwagon of a "typography refresh"; or rather, we only have two adjectives on a talk page, "strange" and "noise", which in practice are equivalent to "I don't like" (the numbers). If we have to be data-driven and rationality-driven, this change clearly has to go (and I don't know how many others in the bunch), at least until research is provided that is able to win an almost-Nobel quote. ;-) --Nemo 10:59, 15 February 2014 (UTC) P.s.: Note that I will never be affected by this thing because I only use monobook, so I'm not even defending my taste.

I have used this feature but I have now decided to turn it off because the TOC display is unsatisfactory. The TOC numbers do not appear even if section heading numbering is turned on. I have been very pleased with the typography changes (thank you, this has been appreciated) but not with the reformatting. Thincat (talk) 13:58, 15 February 2014 (UTC)

ToC without numbering!?! A useless horror!

The orientation while scrolling is a horror, especially on longer articles with a few more paragraphs. This is the first beta feature I will uncheck VINCENZO1492 12:35, 17 February 2014 (UTC)

I heartily concur. Danbarnesdavies (talk) 22:52, 17 February 2014 (UTC)

Becoming default in a week?

It may be a mistake because I've not seen any announcement about it, but wikitech:Deployments says "Week of Feb 24: Typograph Refresh merged in to Vector for all users (not in[c]luding width or blockquote changes)". The Typography refresh page is still horribly outdated and incomplete, when do you plan to update it? Consider that translators need some days at least, time is really running out. As of now, I'm unable to understand what this "typography refresh" in core is/will be about, I only understand that there will be no "width or blockquote changes". --Nemo 10:22, 15 February 2014 (UTC)

• I like my blue links, m'kay? I'd like to keep them. Thank you. odder (talk) 10:49, 15 February 2014 (UTC)

Nemo et al: that was premature scheduling based on the feedback here and the fact that there was one more update on Friday to tweak things. There needs to be much better documentation and much of it needs to be translated in order for their to be a smooth deployment, so we're holding off until March at least. Steven Walling (WMF) • talk 20:45, 17 February 2014 (UTC)

Thanks to Robla I'm finally understanding a bit of what the effects are as regards fonts and I'm very happy to read from Steven that documentation is coming, thanks to everyone working on it. We're starting a page at Typography refresh/Font choice to document stuff, please everyone contribute there. --Nemo 12:24, 18 February 2014 (UTC)

You are killing me eyes, kind sirs

Having just enabled this experiment on the English Wikipedia, I have to say I absolutely and completely despise the growing use of grey as the default font color in the interface (and I see a pattern, as the same things are being done with Flow). Maybe it looks great on your shiny MacBooks with Retina display, but this is certainly not true for us mere mortals using free software, and especially for those of us with vision impairment. TL;DR: No to using grey as the default font color. odder (talk) 11:05, 15 February 2014 (UTC)

• See also: bug 58683 ("RESOLVED WONTFIX"). odder (talk) 11:16, 15 February 2014 (UTC)

odder Is there a specific area where the color is bothering you - such as footers or left nav? For the body content high contrast color pairs, such as black on white, can create a sense of vibration on the screen and stress the eyes. The value used in our interface is #252525, so its quite a dark grey. Grey is some percentage of black and it needs to balance readability against eye fatigue. Its also better for desktop screens due to antialiasing. (https://en.wikipedia.org/wiki/Grey) You can see that this color value also meets W3C guidelines- http://snook.ca/technical/colour_contrast/colour.html Vibhabamba (talk) 09:16, 18 February 2014 (UTC)

@Vibhabamba: Yes, I'm bothered by the grey color used for article content — the current color scheme is much, much easier on the eyes (for me), and I would ideally use the value we're using right now (which is, I think, #000 — this is the perfect shade of grey). As for how hard it is to read black font on white background, I direct you to bug 58683, Zen Habits or to your printer — which, if I'm not much mistaken, prints black font on white paper most of the time. odder (talk) 09:32, 18 February 2014 (UTC)

max content width disabled?

Since today, there isn't the max content width anymore, i think. Was there an update for the Typography refresh? -- SuPich (talk) 17:40, 15 February 2014 (UTC)

Yes. Iteration 3 was released on Thursday/Friday. I've been asking on IRC, and I gather that there will be a documentation update on Monday (afternoon PST). –Quiddity (talk) 19:45, 15 February 2014 (UTC)

Shame, it made reading a lot easier. Littledogboy (talk) 15:14, 16 February 2014 (UTC)

For me it was the most useful aspect of all beta functions - this really does improve readability! Now I have the mess with scaling the browser window again... Limiting the width makes absolutely sense from a typographical point of view. KOMA documentation for example describes a line length greater than 80 characters as unsuitable (p. 26), in the German version even as "unacceptable" (p. 27). (Lord Biro) 21:01, 17 February 2014 (UTC)

I agree, it was closer to my heart than any other beta function. I'm back to using Evernote Clearly or a custom Firefox add-on now. I really hope the new beta feature comes out soon. Exercisephys (talk) 20:58, 17 February 2014 (UTC)

Don't fret we are still interested in exploring this but by actually making use if the whitespace that becomes available on the right (since many people in this community detest whitespace). Expect another beta feature coming soon!! :) Jdlrobson (talk) 18:07, 16 February 2014 (UTC)

I am very interested in this follow-up (-process), and also I think "many people in this community detest whitespace" is not a good description of their contributions here. -DePiep (talk) 13:50, 19 February 2014 (UTC)

Indeed. I would say that most people in this community are heavy users who would like to make optimal use of their computerscreen real-estate to read and edit wikipedia. Which this was not helping with. TheDJ (talk) 23:31, 20 February 2014 (UTC)

Update infobox

Infoboxes should also be updated in theme similar to toc. (.infobox {border: 3px solid hsl(0, 0%, 88%); background-color: hsla(0, 0%, 0%, 0);} can be used)--Wikiuser13 (talk) 17:18, 16 February 2014 (UTC)

Each project has their own local templates with their own CSS; this beta should not interfere with templates. — Edokter (talk) — 13:51, 21 February 2014 (UTC)

English vs. 'British English'?

That's a bit petty, don't you think? Yours, GeorgeLouis (talk) 15:46, 17 February 2014 (UTC)

This comment refers to the "Other languages" translations box at the top of the documentation page. (I was confused until I worked that out!)

I don't know why the editors who forked translated it did so. It does indeed seem fairly odd. However, nothing to do with project, 'tis just an individual editor's whim. Best to not discuss it on this page - instead discuss it with the editor. HTH. –Quiddity (talk) 20:23, 17 February 2014 (UTC)

It's not a "fork", it's a translation (or adaptation?). en-gb is a MediaWiki locale. --Nemo 11:35, 18 February 2014 (UTC)

Sorry, that was a bad and incorrect use of specific terminology; struck and corrected. –Quiddity (talk) 18:53, 18 February 2014 (UTC)

More Subtle Links

Links in text reduce readability, and Wikipedia articles (especially the more technical ones) are peppered with them. Would anyone support a beta feature that makes links more subtle, or toggles them present/absent or visible/invisible? Exercisephys (talk) 20:59, 17 February 2014 (UTC)

It's a tradeoff between readability and usability. The more subtle you make the links, the harder it is for people to find them -- I once read a news article on a site that used dark blue unornamented text for links and black for body text, and didn't realize the article had a half-dozen links until I accidentally moused over one of them. --Carnildo (talk) 02:18, 20 February 2014 (UTC)

When you call something "Typography refresh", you should better limit what it does to fonts

after the "content width" debacle, i found today that the "Typography refresh" beta feature changed the appearance of the TOC (and maybe other UI related things which i did not notice...).

without expressing any opinion on the change itself, i think it's really bad to call something "Typography refresh" and then make it do other UI changes. this violates the principle of least surprise, and antagonizes users.

If this project is about revamping the UI, please say so. when someone enables in their beta preferences "Typography refresh", they do not expect it to have any effect (modulo bugs, of course) on anything except font handling. This is why everyone assumed, as an obvious conclusion, that limiting the page width was a simple bug: when you enable "Typography refresh" and this choice makes the content narrower, it *is* a bug.

So, assuming this project is way beyond font handling by now, i think you guys should give it a name that reflect what it actually does. calling it "Typography refresh" is pure and clear deception. the deception may be unintentional, but it does not change the fact that it's a deception.

peace - קיפודנחש (talk) 01:46, 19 February 2014 (UTC)

also: the project page itself (i.e., the "Page" associated with this talk page) does not mention any of the non-typographical changes this project includes. it would be nice to update it and list all the changes, so we can give feedback on each. peace - קיפודנחש (talk) 21:06, 19 February 2014 (UTC)

קיפודנחש I agree, that this may feel like its not directly related to type. We can do a better job clarifying this. Would it help if we clarified that treatment of lists, adding whitespace, treating captions to balance the content and improve readability are all part of updating typography. Typography isn't just about fonts, but it was absolutely our job to explain this better. Do you think that would help? Vibhabamba (talk) 23:04, 19 February 2014 (UTC)

Vibhabamba: i believe so. both the project page and this discussion page are linked from the "Beta" options. this discussion page is long and tedious, so i expect many (most?) of the people press "discuss" mainly to report issues and complaints, and not so much to read all the existing discussions. people who press "information" get to the project page, should get some information telling them what this choice is about. i think the first order ob business should be to update the project page so it will explain what this is about, and the 2nd order of business should be to give this project a more appropriate name. for future reference, i also think that if this project does something as radical as limiting the content's width to 750px, it should also add a setting to control it. FWIW, i think the content-width limitation was a very bad decision, and it did not take into account all sort of things such as non-textual content, and the simple fact that the readers are already able to control content width simply by controlling the browser's width. if you could do something more sophisticated, such as dividing the text to columns like in a newspaper (and like the reflist on enwiki, where the number of columns is a function of screen width), i would be much more interested/supportive. peace - קיפודנחש (talk) 02:47, 20 February 2014 (UTC)

I don't like the minimalist styling

The TOC and image thumbs have had most, if not all visual styling removed, sans the grey bar to the left of the TOC. This gives the whole a very detached look; it make the page look unstructured. Throw in Winter, and the whole page will be nothing but grey floating elements on a white background. That is a rather depressing outlook. I understand that the current borders look outdated (I'm working on that), but removing them alltogether is one step too far. There is a test gadget on enwiki that refeshes the thumb, TOC and category borders, and I invite you to take a look. (disable the beta temporarely, as it overrides the gadget.) — Edokter (talk) — 14:01, 21 February 2014 (UTC)

I like this "gadgetized" proposal much more than the typography refresh. For 2 reasons actually :

• the first one is its look, indeed,
• the second one is the fact that it's a proposal at site-level (which could be replicated to all WP sites or all WMF sites easily) instead of a major change to an existing skin that is also used by more and more non-WMF wiki sites (partly because it's the only skin on which some of the new extensions will work fine... but that's another issue). Klipe (talk) 15:29, 21 February 2014 (UTC)

The test gadget has a different primary function. I intend to harmonize the overall look of Wikipedia and streamline all the CSS in Common.css so it can also be used as building blocks for templates. So there will be some overlap, but perhaps it is a step towards offering a unified, openly accessible CSS framework. — Edokter (talk) — 15:55, 21 February 2014 (UTC)

The 3 thumbnail designs

I threw together a spread of the thumbnail designs. –Quiddity (talk) 03:53, 3 March 2014 (UTC)

I totally concur. The new TOC doesn't look structured at all anymore (deadly for a TOC). The images without border aren't a good idea either since a) we do not have justified text and the ragged right edges hit the image and the image description rather arbitrarily and b) the image description looks too similar to body text. This results in everything looking mixed up. It's a wall of text with some images thrown in "randomly". The structure is lost (even with the large padding that was introduced in an unsuccessful attempt to fix this). --Patrick87 (talk) 18:06, 21 February 2014 (UTC)

The font makes me feel uncomfortable

I try this in Chinese(Mainland) version and the font became really weird.The spacing between word was also quite different and made reader feel uncomfortable.Zhu yihan (talk) 09:06, 23 February 2014 (UTC)

blockquote glitch

Seen at w:Euromaidan, with the beta enabled the closing quote of the quotation in the lead appears at the right of the (long) infobox, that is far to the right of the actual quote.--JohnBlackburne (talk) 13:44, 25 February 2014 (UTC)

I see it too. The quote is absolute-positioned. That will never play nice with floating elements. — Edokter (talk) — 14:14, 25 February 2014 (UTC)

The closing quotation mark is superfluous, and can be omitted. The opening mark serves to flag this as a quotation, and there is no confusion about where it ends.

(I am skeptical that any quotation marks are necessary at all. The novelty quotation marks and bigger font-size make a block quotation look like a w:pull-quote, which is not the same thing. The contrasting font is more than sufficient.) —Michael Z. 2014-02-27 18:30 z

Another glitch related to blockuotes is that they make some interactive elements at their right unaccessible. For example at w:Kraken I cannot click the last image when the blockquote is at the same level (this depends on your window size, so you need to adjust it to proper experience the issue). Pginer (talk) 12:27, 28 February 2014 (UTC)

Another glitch. At w:MOS:Blockquote#Block quotations the example shows how to use extension:poem within a blockquote, to preserve line breaks. But that seems to be adding quotes too, leading to large [single] quotes within [double] quotes, neither of which appear in the text; they are also different sized and badly aligned.--JohnBlackburne (talk) 11:59, 2 March 2014 (UTC)

That example is shown in w:template:xt2, so the additional quotes come from an additional nested blockquote element. This is not a display glitch, just a confusing, perhaps inappropriate way to present the example. —Michael Z. 2014-03-06 21:52 z

Yet another glitch. At w:WP:NAMB a blockquote box is used for an example, but the quote almost totally obscures the 'WP:NAMB' shortcut box. There are a few instances of this problem on this page.--JohnBlackburne (talk) 11:00, 6 March 2014 (UTC)

The shortcut box is obscured because an editor added an inline style background-color: white to the blockquote. Careless editing. Removing that rule makes every example readable, although the boxes do overlap, so there is potential for layout problems. —Michael Z. 2014-03-06 21:52 z

Setting default quotes property

In Safari/iOS 5, blockquote elements have big neutral typewriter quotation marks appearing on the left and right – I did a double-take before figuring out what they were supposed to be, and they continue to be very distracting when reading articles with block quotations.

Apparently, this browser doesn’t set the quotes property. The fix is to set it to match other browsers:

:lang(en) { quotes: '“' '”' '‘' '’'; }

For broader compatibility, it might be preferable to use the attribute selector:

*[lang|=en] { quotes: '“' '”' '‘' '’'; }

 —Michael Z. 2014-02-27 18:19 z

(In any case, the quotation marks are bolder than any text on the page, and a bit distracting. They might be just as effective but less distracting to give them color: #999;. —Michael Z. 2014-02-27 18:22 z)

Please just DONT do this at all. blockquote is used I MANY different ways, ways the CSS prettifier folk did not consider yet and are thus breaking... AGAIN. Please check w:MediaWiki_talk:Common.css#Set_default_quotes_property to that this change breaks at least three templates, and worse, they cannot be fixed, because you are using style rules that cannot be overridden from the style attribute. So please reconsider and revert this. TheDJ (talk) 18:55, 27 February 2014 (UTC)

I am not proposing any change to blockquote. It is setting the quotes CSS value so that some out-of-date minority browsers display the page the same way as modern browsers. There is nothing to revert because as far as I know this has not been implemented.

This is easily overridden in user style sheets, or in style attributes (although you should avoid the latter):

<blockquote style="quotes: '«' '»';">...</blockquote>
:

 —Michael Z. 2014-02-27 20:32 z

TOC right

I'm not sure if it's a problem at all - it actually looks quite good in some instances! - but we also need to be aware of {{TOC right }} uses.

• Eg. Manual:Configuration settings (and ~260 uses on mww)
• Eg. w:Economy of Alberta, w:Radical Party, w:WP:Requested pictures, and w:WP:WikiProject Breakfast (and ~23,000 other pages on Enwiki)

It's wikidata:Q5626794, and used on 90+ wikis. HTH. –Quiddity (talk) 21:29, 27 February 2014 (UTC)

Actually, there are quite a few templates like that, that will need to be adapted/fixed if this style gets applied I presume. TheDJ (talk) 21:07, 2 March 2014 (UTC)

Headers breaking right floating content

I first noticed it due to the TOC right pointed out above, but it is also effecting infoboxes. It seems to be caused by the rule:

@media screen {
    div#content h1, div#content #firstHeading, div#content h2 {
        margin-left: -0.04em;
    }
}

If you look at the page w:Radical_Party or for instance w:NIF3L1, with and without the Beta enabled using Google Chrome, you will notice a clear difference in how the content is being positioned. The content that should be left of the right floating element is getting cleared, from the point of where the content contains a header. This is despite the fact that there is only a clear:right; on these elements. Disabling the rule above fixes the problem. I suspect this is caused by the same aspects of the clear float specification that causes the bunched edit link problem for instance. Suggest we remove this. TheDJ (talk) 21:19, 2 March 2014 (UTC)

h4 same as h5? but only in firefox?

Weirdly, on Mac + Firefox ==== and ===== look the same to me - same size, style - with the typography refresh. On Chrome they are slightly (though very, very subtly) different in size. Would be nice to get a little more distinct, though I realize this is hard at h4/h5 levels. FYI. LuisV (WMF) (talk) 00:18, 4 March 2014 (UTC)

Infobox Float is Cleared by Section Header. Looks Poor, Bug?

Typo Refresh Infobox Float Comparison

It looks like the section heading is cleared from the infobox float. Is the desirable? It looks poor, from a readability perspective. See my uploaded picture of the comparison of the refresh as of today vs. the current default. I tested against the latest version of Google Chrome.

Interestingly, if you change the following overflow property

@media screen
h1, h2, h3, h4, h5, h6 {
  overflow: visible;
}

it almost solves the problem. --F3ndot (talk) 04:59, 4 March 2014 (UTC)

I agree this is a problem, it becomes more obviously a problem on pages with long infoboxes like https://en.wikipedia.org/wiki/Beyond_the_Boundary

Image caption area bug

There's a problem with the H2's underline extending into the caption area of the thumbnail. See screenshot. –Quiddity (talk) 18:43, 4 March 2014 (UTC)

Directly related to bug above. — Edokter (talk) — 18:49, 4 March 2014 (UTC)

Article title font is horrible

I dont know if this is Wikipedia specific or whatever, but on Wikipedia you have a beta "Typography refresh" which I'm assuming is the same as this. If it is, then please note that on a basic Windows 7 install the title font is horrible (Is it Times New Roman?) Its really awful and should be changed back to the older one! Anybody else thinks so? Please add your votes/comments below. Thanks -- JeremyJenko (talk) 09:04, 11 March 2014 (UTC)

It's Georgia. And yes, it is intended (but I'm not fond of it either). — Edokter (talk) — 14:43, 11 March 2014 (UTC)

Links

Hello, there is a bug in "Developers" link in bottom bar. It uses "external" class which results in arrow after link.

Also, please redesign those arrows. You can change their color to black like in google support. Thanks.--Wikiuser13 (talk) 15:38, 13 March 2014 (UTC)