타이포그래피 개정

This page is a translated version of the page Typography refresh and the translation is 18% complete.
Outdated translations are marked like this.

이 문서는 위키미디어 프로젝트와 미디어위키 소프트웨어의 기본 스킨인 '벡터'에 발생한 최근 타이포그래피 업데이트를 서술하고 있습니다. 주의: 이 내용은 아직 미디어위키 코어에 적용되지 않았으며, 이 문서에서의 현재 상태는 아직 $date 시점에서 미래에 일어날 일입니다.

(위) OSX의 기존 타이포그래피
(아래) OSX의 바뀐 타이포그래피
우분투/파이어폭스의 (위) 기존 타이포그래피 (아래) 바뀐 타이포그래피
(위) OSX의 기존 타이포그래피
(아래) OSX의 바뀐 타이포그래피
(위) 윈도우의 기존 타이포그래피
(아래) 윈도우의 자유 폰트(Linux Livertine과 Arimo)가 설치된 상태의 바뀐 타이포그래피

변경 내용 요약

우리는 다음 요구사항을 고려해 위키미디어의 기본 타이포그래피를 다음과 같이 업데이트하게 되었습니다.

  1. 가독성 : 타입페이스는 읽을 수 있어야 하고 모든 사이즈에서 아름다워야 합니다. 기본요소로서의 타입은 문서 내용에서 (사이트 네비게이션 같은) 인터페이스를 차별화할 수 있도록 도와야 합니다.
  2. 지속성 : 데스크톱과 모바일 기기에서 시각적 경험이 지속되어야 합니다.
  3. 가능성 : 우리가 사용하는 모든 타입페이스들이 위키미디어 프로젝트들이 사용되는 모든 플랫폼에서 이미 사용가능하(거나 제공되어)야 합니다. 모든 선택들은 기기와 플랫폼들 전부(Mac OS X, 윈도우, 리눅스, 모바일 OS) 에서 사용될 수 있도록 적절히 낮은 수준이 되어야 합니다.
  4. 접근성 : 위키미디어 콘텐츠는 장애를 가진 사람들을 포함해서 모든 사람들이 쉽게 접근할 수 있어야 합니다.

이러한 맥락 속에서, 다음과 같은 변경을 가했습니다.

새로운 폰트 지정
우리는 다음과 같이 글자가족 (영어)을 설정했습니다.

제목 스타일 : "Linux Libertine, Georgia, Times, serif"
본문 스타일 : "Arimo, Liberation Sans, Helvetica Neue, Helvetica, Arial, sans-serif".

이 리스트가 당신이 이러한 폰트들을 수령할 것이라는 사실을 의미하지 않습니다. 그 대신, 당신의 브라우저와 OS는 리스트에서 여러분이 설치한 리스트에서 가장 첫번째 폰트부터 찾은 이후, 그것을 보여줄 것입니다.[1][2]
New spacing and sizing for headings, body copy, and leading
With the current text width, headings need to clearly stand out and the leading (whitespace between lines) needs to be sufficient to enable readability without creating eye fatigue. Headings will now be set to the following: H1 (page titles) will be 1.3/1.8em, H2 (main section headings) will be 1.3/1.4em. H3 will be 1.6/1.17em, H4 1.6/1em, H5 1.6/1em. The body copy has been increased to 0.875em (from 0.8em). Depending on your browser and operating system, this will translate to slightly different pixel values, but overall results in a slightly larger body font size. The superscript (sup) and subscript (sub) line-heights are now set to 1, to fix a long-standing problem with reference numbers affecting the leading.

[3]

New body font color
In hex triplets, the body copy color is now set to #252525 on #FFFFFF, from #000000 on #FFFFFF. In less technical terms, this means the color has changed from pure black text on a pure white background, to very dark grey text on pure white background. (Colors for links, headings, and other elements have not changed.)

FAQ

아래 내용은 이 변화에 대한 몇가지 주요 질문에 대한 답변입니다.

누가 이 변화를 보게 됩니까?

기본 벡터 스킨을 사용하는 사용자와 편집자를 포함한 모든 위키미디어 사이트 이용자들이 보게 됩니다. 환경설정이나 다른 방법을 통해 모노북이나 콜로뉴 블루같은 다른 스킨을 사용하는 사용자들에게는 변화가 없습니다.

Please note that users who have customized their personal CSS, or who are on a site where local administrators have altered site-wide CSS, may notice discrepancies with the new defaults. Please check this summary and FAQ to see if a particular design element should be attributed to this change.

What was the problem with our typography to begin with?

Text is our core visual element of Wikimedia projects, whether it's an encyclopedia (like Wikipedia) or a smaller project like Wikisource and Wikibooks. We want our users to sense accuracy, reliability, and clarity from our design, just like the actual content they are reading. Prior to this typography update, we had more than 20 arbitrarily defined type sizes on desktop alone, which appeared inconsistent for our users. The type size was too small for many readers, and the line height could make reading long form content difficult. For headings, these should act as entry points in a long pages of text and were styled accordingly to aid readability. We sought to achieve better balance and cohesiveness for users to efficiently scan the page or engage in long form reading.

The functional problems with our older styles were first addressed via improvements to our mobile typography. That gave us a chance to test a larger type size, increased leading, and serif headings. Now, it is time to address readability and accessibility in all languages/projects, as well as create consistency in the design language across desktop, mobile web, and apps.

Is there a perfect font that meets our readability needs in all scripts? Do we think this is it?

No, there is no one perfect font which embodies…

  1. Ubiquity: i.e availability on all popular desktop and mobile operating systems.
  1. Proper rendering of glyphs and diacritics: for hundreds of non-Latin scripts, as well as good kerning for character pairs, so users do not have to squint to read characters.
  1. Respectable x-height: so type is legible at small sizes for things like left navigation, captions, terms of service or secondary information.
  1. Hinting: avoiding blurriness of characters at small sizes, particularly on Windows.

We have to make a practical decision based on what comes close to meeting all these requirements, within our constraints. Millions of users read Wikipedia on different devices every day. The current font selections will bring improved readability and consistency across platforms, even if they're not perfect.

Why is the type size and leading increased?

This is a small, conservative change. The previous type size was unreadable to many users. We found through user feedback that text zooming was used extensively to make the text more readable for those with even basic vision issues or impairments. Since we endeavor to make the information accessible to all users, this change felt like a basic requirement for any improvement in this area. Along with the type size the leading has also been increased to 21px leading, following typographic standards for leading i.e 120% of the type size. This helps readers who go past the introduction and read long paragraphs.

The body copy is the focus of pages on Wikimedia projects. For most language projects the text size is small and dense with our current measure. The lack of airiness lends some efficiency but creates eye fatigue with extended reading. Also, under 14px is not recommended for non-Latin scripts. Words carry superscripts and glyphs which tend to get squashed and cannot be deciphered without squinting.

Why are we using serif fonts for the headings?

Combining serif and sans-serif is not an unusual or original idea.[4][5] We do so in this case to provide better contrast and distinction between body and headings. Headings act as entry points when users are scanning a page, looking for information. Both headings and images play an important role in breaking up the visual monotony of the page, which is of critical importance considering that much of Wikimedia content (content pages, discussion pages, help text, policies, etc.) are quite lengthy and have many sections.

Why did we specify Linux Libertine, Georgia, and Times as the serif fonts?

Section titles are entry points into the article. A serif font provides visual differentiation and character compared to the body copy, which helps a user scan the page. Serif are also well-known for conveying a traditional demeanor that is in keeping with our design goals.

Linux Libertine is not widely available, but is a well-designed and free/open serif font that is also used in the Wikipedia logo. This makes it a ubiquitous part of the Wikimedia design language, as well as being appropriate for use in headings. Georgia is a font optimized for browsers and screens. It is also widely available on our most popular platforms, including for users of Windows, Mac OSX, and iOS. Linux Libertine and Georgia act as good complementary fonts, and pair well with Helvetica and Arial. Times is set specifically to ensure that users on Linux systems have a good serif by default – Linux systems do not by default include Linux Libertine, nor Georgia. By setting Times, most Linux users will see Nimbus Roman No9 L.

Languages and scripts for which problems have been reported with Georgia or Times include Russian/Cyrillic, Hebrew, Arab, Polish, Chinese, Japanese and Korean.

Why did we specify new sans-serif fonts?

The previous state of our body content is that only "sans-serif" was specified, leaving it up to the browser to use its default sans-serif. With the exception of Helvetica, Arial and Nimbus Sans L, the fonts that most browsers use in this condition do not account for proper rendering of glyphs, pairs, and diacritical marks at small sizes. There is no free/open font that addresses this need and is ubiquitously available (see table).

We specify Neue Helvetica for Mac users, as it is a slightly more developed version of Helvetica where punctuation has been improved, the x-height is slightly more consistent, and in some cases it has more rounded bowls and counters. Overall it is an optimization of Helvetica, though it may not be as ideal in all scripts.[6]

We specify fonts both to achieve consistency across devices and platforms and to guarantee appropriate readability and rendering at small sizes for Latin and non-Latin scripts alike. With the specifications in place, users who are interested can download the free/open fonts that have been tested or report issues to us for the fallback cases, which will allow us to address issues in a more systematic manner.

In the past, we experimented with several alternative fonts that were freely-licensed, including: Arimo, Liberation Sans, and others. Ultimately these fonts are either not commonly installed by users (creating no effect) or they render poorly on older systems or those without font smoothing/hinting.

Why did we include non-free fonts in the font stack?

The stack specified a range of fonts from Helvetica Neue to Arial that are available across all major platforms. Even though Arial is widely used as a default, we need to specify it so that the CSS degradation is predictable. To ensure a reliable experience to users across platforms as best as we can, we decided to include non-free fonts in the stack since many operating systems (such as Windows, MacOS, and iOS) do not have any FOSS fonts installed by default. Meanwhile many operating systems will use a FOSS font (such as Nimbus Sans L) in place of "Helvetica".

It is particularly important to note that, because of the way CSS font-family settings work, specifying a particular font does not create a hard dependency on that font, nor does it cause the user to download that font. This means that fonts we specify only appear if the user has them already, and Wikimedia text will continue to appear regardless of whether you have a particular font or not.

What about using webfonts?

Webfonts is a system to deliver a font to users who do not have it installed. This involves having a user's browser download a font we provide, which causes additional resources to load and would have a negative impact on site performance (i.e. how fast pages load). This is particularly true for older browsers. In the future we may explore using webfonts, but for now this update provides greater readability and consistency while not degrading page load times.

Why did we change the body text color?

The new values (#252525 on #FFFFFF) have a contrast ratio of 15.3:1, which is an AAA rating according to WCAG 2.0 1.4.6.[7] Pure black for both body copy and captions is not recommended against white for several reasons. Dyslexic users are sensitive to the juxtaposition of pure black text on a pure white background due to its high contrast. This can cause the words to swirl or blur together. To avoid this, use a slightly off-white color for your background, like a light gray, or decrease the contrast between foreground (text) and background. For users without accessibility issues, the harsh contrast of pure black on pure white can increase eye strain as well.

How did this change happen?

This typography update was first tested for four months, and then released on mobile web for all Wikimedia projects in October 2012. These included font stack declarations for serif headings and sans serif body copy, as well as increased type size and leading for body copy and captions.

These changes were later brought into desktop as a beta feature, starting in November 2013.[8] This beta feature then went through three major iterations based on community feedback.

How did we get feedback?

Many of the typography changes were first tested on mobile in October 2012, much of the learning was integrated into the typography beta feature for desktop which was launched October 2013 and went through three major releases. During that time the beta feature was used by over 14,000 users across the top 10 Wikipedias, and more than 100 discussion threads were created on the feature's Talk page.

Can I opt out of changes to the default fonts?

Yes. It is possible for logged-in users of Wikimedia sites to customize their personal CSS (i.e. Special:MyPage/vector.css on each wiki) to override some or all of the changes. You can copy User:Ekips39/typographyrefreshoverride.css into your personal CSS if you don't want to learn CSS in order to opt out of the changes. You may also of course choose to switch to another skin entirely, in your Preferences under the Appearance tab. Last but not least, you can define the default font your browser uses to display "serif" and "sans-serif" fonts, if your system does not have any of these specified fonts this browser preference will be used instead.

Did we test this on a variety of browsers and operating systems?

Yes. The new font stack was tested on the following operating systems: Windows XP, Windows 7, Windows 8, Ubuntu Linux, Mac OS X 10.8-9, iOS 6 and 7, Android, and Chrome OS. Size, leading, glyphs, hinting and font renders were tested on Windows, Ubuntu Linux, Mac OS X 10.8, Android, and Chrome OS.

How will non-English language projects adapt to these changes?

By default, the typography update will be applied to all projects (as part of the Vector skin). There may be languages that need to override some of these styles to accommodate particular scripts. For example, some scripts may need a taller line height or larger font size. Each wiki can override these particular styles by editing their MediaWiki:Vector.css page. We encourage other projects to audit the changes introduced by the update, and override the CSS only where necessary based on their script.

What about non-Latin scripts?

The old type size in non-Latin scripts was 0.8em (12.8px). This squashes glyphs and superscripts significantly along with the type being too small to read. Scripts examined were Urdu, Marathi, Bahasa Melayu, Chinese, Korean, and Navajo. The body copy type size increase will improve readability for most scripts. Specifically for Navajo, an override will be provided because character pairs render strangely in Helvetica.

Inline CSS guidance can be provided to ensure that languages make overrides on a case-by-case basis as needed. Please comment on the Talk page if you primarily use a non-Latin script and encounter significant problems.

Did you run any controlled experiments e.g. A/B or split tests to measure impact of the new typography?

No.

We often first launch new features in controlled experiments, to objectively measure their performance and test hypotheses about positive impact they might have. In the most common version (an A/B or split test) we randomly select a sample of readers or editors, give half the new version, and give half no new experience. In this case, Foundation research scientists advised against running any A/B tests or other controlled experiments. It is unlikely that minor typography changes alone would make a large impact on reading-related metrics like time on site, number of page views per visitor etc., which could be measured with confidence.

Related goals, like enhanced trust in Wikimedia sites or comprehension in reading, are not the kind of data we can best learn about on a quantitative basis, or which are also largely impacted by unrelated factors like the page content and subject, what type of page is being read (Talk versus articles, for example), and more.

Can using these new fonts cause Wikipedia to be slower for me?

No. We typically measure the site performance impact of a new feature, meaning whether it makes pages take longer to load. In this case, we are not adding to the list of resources that a user must download to view a page, so any change in performance will be negligible.

References

  1. 폰트, W3C
  2. [$font-family 폰트가족], 모질라 개발자 네트워크 (영어)
  3. bugzilla:49965
  4. Best Practices of Combining Typefaces
  5. "Sans serif and serif typefaces can be effectively combined if changes are limited to prevent visual chaos. The key is to ensure that the result respects the content and reinforces the information hierarchy and overall design goals." Human-Computer Interaction Handbook: Fundamentals, Evolving Technologies, and Emerging Applications, Third Edition
  6. Helvetica: Old and Neue
  7. Web Content Accessibility Guidelines (WCAG) 2.0
  8. https://blog.wikimedia.org/2013/11/07/introducing-beta-features/

See also