읽기/웹/데스크톱 개선/기능/내용 폭 제한

개요

기능

저장소

FAQ

« 이전

다음 »

파브리케이터에서 추적됨
일감 T246420

이 프로젝트의 주된 목표 가운데 하나는 위키백과와 다른 위키미디어 위키들이 새로 온 사람들을 더 따뜻하게 맞이할 수 있도록 만드는 것입니다. 이를 수행하기 위한 목표로 한 방법은 문서 읽기 경험을 더 편안하게 만드는 것입니다.

편안한(또는 불편한) 읽기 경험은 무엇을 의미할까요? 연구에 따르면 여러 요인이 있으나 그 중 주된 것은 줄 길이입니다. IBM Center for Advanced Learning의 피터 오튼 박사의 연구 컴퓨터 텍스트 줄이 읽기와 학습에 영향을 준다에 따르면 줄 길이가 길어질수록 읽기 더 어려워지며 궁극적으로 텍스트 정보를 학습하고 집중하기 어려워진다고 결론을 내립니다. 그 밖의 일부 관련 연구는 위키백과 문서 Line length에서 볼 수 있으며 권장되는 줄당 문자 수는 40~75자 사이입니다.

특히 위키미디어 위키에서 권고되는 줄 길이를 달성하기는 쉽지 않지만 우리는 위키 텍스트 대부분을 권고안에 가깝게 맞추기 위해 최대폭을 사용하여 내용 폭을 제한할 예정입니다.

이 기능의 연구와 고려사항에 대한 더 자세한 정보를 알아볼 수 있습니다.

기능 설명 및 요건

이 기능의 주된 목적은 문서 내용의 폭을 제한하는 것입니다. 그러나 문서의 다른 요소들(이른바 사이드바와 헤더)이 내용으로부터 너무 멀리 이동하지 않도록 하기 위해 우리는 2개의 추가적인 컨테이너를 추가했습니다. 두 번째 컨테이너는 사이드바가 콘텐츠에 가깝게 유지되도록 보장합니다. 그 다음 헤더가 내용과 사이드바로부터 너무 멀리 이동하지 않도록 하기 위해 헤더의 최대 폭을 제한하는 세 번째 컨테이너를 두고 있습니다.

기술적 관점에서: 대부분 문서의 내용은 최대폭 960px의 내용 컨테이너 안에 배치됩니다. 헤더, 사이드바와 같은 인터페이스의 다른 부분의 폭 관리에 도움을 주는 추가적인 2개의 컨테이너가 있습니다: 워크스페이스 컨테이너(최대폭 1440px), 페이지 컨테이너(1650px) 다음은 이 컨테이너들이 어떻게 동작하는지를 나타낸 도표입니다. 역사, 최근 바뀜, 기타 비슷한 기록 유형 문서를 포함하여 내용이 내용 컨테이너에 의해 제약되지 않을 특정한 페이지가 존재합니다.

• 
  사이드바가 닫힌 레이아웃 컨테이너 3개를 보여주는 도표
• 
  사이드바가 펼쳐진 레이아웃 컨테이너 3개를 보여주는 도표
• 
  특수문서가 있는 레이아웃 컨테이너 3개를 보여주는 도표

디자인 요건 및 지침

다음은 현재 레이아웃과 위에 기술된 다양한 폭 제한으로 업데이트된 레이아웃 간 차이를 묘사하는 GIF입니다:

현재 레이아웃과 내용 폭 제한을 둔 업데이트된 레이아웃을 비교하는 GIF

제약

역사와 최근 바뀜 등 특정 기록 문서 등 여기서 주된 문제는 줄 바꿈으로 인해 화면이 더 좁아질수록 읽기가 더 어려워진다는 점입니다. 그러므로 우리는 내용 컨테이너(960px) 대신 워크스페이스 컨테이너(1440px)에만 이 페이지들의 제약을 두도록 특수한 방식으로 이 페이지들을 처리하기로 결정했습니다. 다음은 일반 문서와 관련 역사 문서 간 전환을 보여주는 프로토타입의 GIF입니다:

새 벡터 레이아웃에서 일반 문서 vs 역사 문서의 폭을 보여주는 GIF

편집자의 사용자 테스트

우리는 내용 폭 제한 프로토타입과 관련하여 여러 위키의 편집자들의 피드백을 수행했습니다. 편집자들은 센트럴 노티스 배너를 사용하여 프로토타입을 탐구하고 피드백을 제공하기 위해 초대되었습니다. 기능에 관한 혼재된 평가가 있었습니다: 수많은 편집자들은 줄 길이가 더 짧아짐에 감사를 표했고 이 기능이 더 편안한 읽기 경험을 제공함에 동의하였습니다. 일부 편집자들은 내용 주위의 흰 공백을 싫어했으며 이를 낭비되는 공간처럼 느꼈습니다. 우리는 줄 길이와 읽기의 편안함에 관한 기존의 광범위한 연구와 더불어 해당 피드백 전반의 균형을 맞추고 있습니다.

목표 및 동기

Readability

Research

The primary objective is to improve readability of Wikimedia wiki pages. We decided to work on the width of the content area. There are research-based recommendations on this issue.

• English Wikipedia article on Line length provides a good overview.
• So does the essay by Professor Laura Franz.
• Optimal Line Length in Reading - A Literature Review (2005), from the peer reviewed journal Visible Language – "studies concluded that moderate line length in between 50 to 70 cpl [characters per line] are the easiest to read and users do not prefer extreme line lengths (very short or very long) while reading from screen. There was no significant effect of line length found on comprehension, though fast readers benefit from narrow columns with short lines due to specific reading patterns (with one contradictory finding)".
• Effects of Surrounding Information and Line Length on Text Comprehension from the Web (2002), from Canadian Journal of Learning and Technology – "Comprehension was affected by whitespace; participants had better comprehension for information surrounded by whitespace than for information surrounded by meaningless information", which is more likely to happen if the text stretches to the edge of the browser.
• The influence of reading speed and line length on the effectiveness of reading from screen (2001), from International Journal of Human-Computer Studies – "A line length of 55 cpl appears to support e!ective reading in terms of both rate and comprehension. However, as the line lengths used in this study were spread across a wide range, there may be a more optimal setting than this. By varying the range and extremes of line lengths in future research, it may be possible to more precisely identify an optimal format and to explore the relative contributions of mechanical and cognitive factors."
• Shorter Lines Facilitate Reading in Those Who Struggle (2013), from PLOS One – "short lines reduce the number of regressions, and generally improve reading speed and comprehension, simply by reducing the probability that crowded text in locations previously fixated can be perceived."
• The Effects of Line Length on Children and Adults' Online Reading Performance (2002), from Software Usability Research Laboratory (SURL) at Wichita State University – "This study examined the effects of line length on reading performance. Reading rates were found to be fastest at 95 cpl. Readers reported either liking or disliking the extreme line lengths (35 cpl, 95 cpl)".
• The Effects of Line Length on Children and Adults' Perceived and Actual Online Reading Performance (2003), from Proceedings of the Human Factors and Ergonomics Society Annual Meeting – "No differences were found for either reading time or efficiency for either adults or children. However, adults preferred shorter line lengths to full-screen line lengths." and "The narrowest line length condition was perceived as promoting the highest amount of reader concentration, while the medium line-length condition was considered to be the most optimally presented length for reading."
• Reading Online Text: A Comparison of Four White Space Layouts (2004), unclear if this was peer reviewed – "Results from this study showed that the manipulation of the Margin white space affected both reading speed and comprehension; participants read the Margin text slower, but comprehended more than the No Margin text. In general, the results favored the use of Margins."

The popular recommendation is that there should be between 40 and 75 characters per line. The findings of multiple studies conclude that "short line lengths are easier to read". Regarding learning and information retention: "Subjects reading the narrow paragraphs had better retention than those reading the wide paragraphs".

Web Content Accessibility Guidelines (WCAG)

• The Web Accessibility Initiative (WCAG) guideline 1.4.8 states that, in order to be accessible to all users, lines of text should be 80 or fewer characters (or 40 or fewer characters if the text is Chinese, Japanese, or Korean)."

Popular sites with limited width

One can find many popular sites that conform to these guidelines.

• Articles on the online science journal Nature have a max-width resulting in ~76 characters per line.
• New York Times articles are ~64 characters per line.
• Times of India articles are ~100 characters (Hindi).
• Oxford Academic journal articles are ~75.
• Articles on the World Health Organization’s website are ~96 (Latin alphabet), ~46 (Chinese alphabet), and ~85 (Cyrillic alphabet).
• When using reading mode in Safari or Firefox text is rendered at ~73 and ~77 characters per line respectively (Latin alphabet).

Comparison with Wikimedia wikis

Currently, an English Wikimedia wiki page on a browser window at 1280px has a character count of ~170 characters per line. That’s at the small end of the screen size spectrum.

On Wikimedia wiki the character count per line grows as the screen width grows. So on the second most popular screen-size, 1920px (21% of users), the character count per line is ~262, more than three times the recommended value.

Why not choose "the simplest" solution

Based exclusively on the recommended line length, it seems like somewhere around 700px is reasonable. Why not limit the width such that we achieve the recommended line length, as other online content sites seem to?

Because our pages are different, and therefore people read them differently.

• Wikimedia wiki pages are very long, contain a large amount of information, and they are not uniform from one page to the next. As a result, people have a need to skim and search within pages. This is different than linear reading a typical online article or book. This is supported by our research around reading time on Wikipedia.
• The more narrow we make the content, the longer the page gets. Perhaps the more difficult scanning becomes as well, because it involves more scrolling, etc. For more information regarding different types of online reading, please see this 2006 study conducted by the Nielsen Norman Group.
• Additionally, it is not straightforward to achieve a specific number of text characters per line. That is because Wikimedia wiki pages contain many elements that are floated inline alongside text.

Moon article at 550px wide, uninterrupted paragraph with a character count per line of ~83

Moon article at 750px wide, paragraph next to infobox with a character count per line of ~72

Our design must take into account these distinctions.

• We should limit the width by some amount to accommodate focused/engaged reading. This means shorter line lengths, and less density.
• At the same time, we should still enable readers to skim and search around, obtaining a visual map of the page without having to scroll too much This is an argument for longer line lengths, and more density.

How do we do that?

Our solution

There are two common experiences we might want to consider.

1. The top of an article, a paragraph of text situated next to an infobox
2. The middle of an article, a paragraph with no elements interrupting it

We can consider these two experiences at various widths, counting the character length per line for each:

Content width	Paragraph next to an infobox	Uninterrupted paragraph
600px	~30 characters per line	~94 characters per line
700px	~59	~109
800px	~76	~125
900px	~89	~142
1000px	~105	~154

At 1000px wide an uninterrupted paragraph of text is ~154 characters long, just about double the upper limit of the recommended range. Sometimes there are floated elements that are wider than infoboxes, resulting in more narrow columns of text next to them. Also there has not been a max-width. While some editors might edit on narrower screens (or check how pages look on narrower screens) there’s likely content on pages that won’t look great at a narrower width (yet), because it might not have been a consideration (e.g. large tables).

Another approach is thinking about a grid-based layout. This is an approach that aims for both visual harmony on the page, and making decisions about spacing, widths, etc. easier. The Vector skin does not currently use a grid. Something we could do is think about the width of the infobox as a grid column (since they are such common elements), and then use a multiple of that to determine the content width.

India article with content at 3x infobox width

India article with content at 4x infobox width

Establishing a common reading experience

Introducing a max-width would work towards establishing a common experience. Hopefully, it would be helpful to editors when making decisions about page layouts.

Note: 1024px is mentioned as a minimum size to consider in the WP:Manual of Style/Layout page. That’s not quite the same thing, though.

Currently, an editor might be editing a page at a width of 1500px, while a reader reads it at a width of 1200px. By implementing a max-width, we don’t remove this difference completely. There would still be variation below the fixed-width, for people with narrower screens. However, we would be greatly limiting the range of variation.

Conclusion

After thinking all of that through we’ve come to two conclusions:

1. It seems that a max-width in the range of 800–1000px is a sensible starting point. We will center the content on the page to ensure that it looks good with the sidebar both open and closed.
2. It seems worthwhile to conduct a study focusing on the readability of Wikipedia articles specifically. We hope to be able to find the resources to do this.

Showing content with a max-width of 960px (sidebar collapsed)

Showing content with a max-width of 960px (sidebar open)

Additional notes

A note on breaking templates / content / special pages / etc.

Part of what makes Wikipedia, and other Wikimedia wikis, a powerful tool for sharing knowledge is that there are very few constraints on how information is presented. The result of this is a wide variety of different elements on the pages: tables, image galleries, diagrams, panoramic images, graphs, forms, maps, category boxes, and more. We have dealt with the challenges of designing the mobile site, and got the content to look good. This is why we do recognize that there are going to be some situations where page content doesn’t look great given the max-with. Our plan currently is:

• Work with our test wiki communities to identify issues and discuss solutions using template styles or other existing tools.
• Not to implement the max-width on Special pages. Special pages are not intended for “reading”. They often function more as lists or dashboards. Until we have time to work through the details about more responsive layouts for these pages, we will be leaving them alone. Here is an initial prototype of how this would work. You can switch between "View history" and "Read" to get a sense for it: https://di-collapsible-sidebar-5.firebaseapp.com/Tea

Previous conversations

This topic has been discussed in the past.

• 2014 – discussion from the Typography Refresh project

Please feel free to add additional links to past conversations here.

Full-width toggle

The fullscreen toggle

Until October 2022, logged-in users were only able to switch between the limited and full content width using gadgets. According to the English Wikipedians, this was insufficient. We decided to build a toggle. (On the right, you can see a screenshot of this toggle.) It needed to be visible and available to both logged-out and logged-in users. As a result, we have:

1. Built a preference for logged-in users. It allows for the width to be set across pageviews and wikis. The preference is available in the appearance section of the preferences page (폭 제한 모드 사용). It may also be set as a global preference.
2. Built a toggle for logged-in and logged-out users. The toggle is available on every page if the width of the screen is larger than 1400px. Selecting the toggle increases the width of the content area.
   • For logged-in users, the toggle also controls the preference mentioned in 1 above. For example, if you click the toggle on the page and visit your preferences page, you will notice that the enable limited width mode checkbox is unchecked.
   • For logged-out users, initially, the toggle set the width on a per-page basis. This means that after refreshing the page or opening a different page the width would return to the default (limited) state.
   • After making our skin the default on English Wikipedia, we heard concerns about the setting for logged-out users. After coordinating with many teams, we made a change. Since February 2023, all users see the width setting of their choice despite refreshing pages or opening new ones.

Why did the toggle work on a per-page basis initially? This was because in principle, preferences are not available for logged-out users. The lack of preferences for logged-out users doesn't only apply to this skin. (You may learn more about the technical limitations.) We have managed to find a short-term bypass. We have more work to do to make sure this solution may be maintained. We might use a better solution in the future. This could be applied to settings such as font size or dark mode.

References