Reading/Web/Desktop Improvements/Features/Limiting content width/ko

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

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

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

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

출시 계획
2020년 5월 오피스 위키와 테스트 위키의 첫 번째 검토 단계를 배치하였으며 수개월 내에 우리의 얼리 어답터 위키에 계속 반영할 예정입니다. 더 자세한 정보는 주요 기능 문서를 참고하십시오. See our main Features page for more details.

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

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

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

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



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

가독성
주된 이유는 위키미디어 위키 문서들의 가독성을 제고시키는 것입니다. So perhaps the first question is: how can we know what the optimal width of the content area is? There are research-based recommendations regarding optimal line lengths for readability of text, so we should probably start there. But then again Wikimedia wiki articles are different from common articles or web pages in certain ways. They are unique both in how long they are and in the variability of layout from one article to the next. Both of these factors may lead to a larger than usual need for scanning and searching for content (rather than linear reading). Our design must take into account these distinctions. We need to therefore ask, are Wikimedia wiki pages unique enough to warrant a line-length different from what is generally recommended? Below we explain how we’ve arrived at our design recommendation for what the max-width should be.

Without studying readability of Wikimedia wiki pages directly we can’t know what is optimal, but in an attempt to make an educated guess we start with the research on optimal line length for readable text. The research and recommendations in this area seem to be well established. The Wikipedia page on Line Length provides a good overview, as does the essay Size Matters: Balancing Line Length And Font Size In Responsive Web Design by Professor Laura Franz. The research study Computer text line lengths affect reading and learning by By Peter Orton, Ph.D. IBM Center for Advanced Learning is a more rigorous, academic study. 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", and furthermore regarding learning and information retention "Subjects reading the narrow paragraphs had better retention than those reading the wide paragraphs". 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, and articles on the World Health Organization’s website are ~96 (Latin alphabet), ~46 (Chinese alphabet), and ~85 (Cyrillic alphabet). It is also worth noting that when using reading mode in Safari or Firefox text is rendered at ~73 and ~77 characters per line respectively (Latin alphabet).

In comparison, a Wikimedia wiki page on a browser window at 1280px* has a character count of ~170 characters per line, and that’s at the small end of the screen size spectrum. (*The most common computer screen size, accounting for 22% of users, is 1366px wide according to StatCounter; imagining a browser window at nearly full width you end up with ~1280px). Then factor in that on Wikimedia wiki the character count per line grows as the screen width grows (whereas on the other sites mentioned the character count per line remains the same, the result of max-width constraints). So on the second most popular screen-size, 1920px (21% of users), the character count per line is ~262 (again assuming a browser window at nearly full-width), more than three times the recommended value. So as a starting point we know that for paragraphs of uninterrupted text we are well over the recommended limit.

The question then becomes: why not limit the width of Wikimedia content such that we achieve the recommended line length, as other online content sites seem to? The short answer is: 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 greater need to skim and search within pages than they would when reading a typical online article or book (this is supported by our research around reading time on Wikipedia). So while the line length recommendations provide a good starting point, we also must consider that the more narrow we make the content, the longer the page gets, and perhaps the more difficult scanning becomes (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, because Wikimedia wiki pages contain many elements that are floated inline alongside text it is not straightforward to achieve a specific number of text characters per line.

공통 읽기 경험 확립
The second reason we think introducing a max-width could be beneficial to the reading experience is because it would work towards establishing a common experience, which hopefully 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, though that’s not quite the same thing). 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 discrepancy completely (because there would still be variation below the fixed-width, for people with narrower screens), however we would be greatly limiting the range of variation.

결론
이 모든 것에 대해 심사숙고를 한 이후 우리는 2가지 결론을 냈습니다:

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

틀 / 내용 / 특수문서 / 등의 깨짐
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. Having dealt with the challenges of designing the mobile site, and getting the content to look good, we recognize that there are going to be some situations where page content doesn’t look great given the max-with. 현재 우리의 계획은:

Special pages are not necessarily intended for “reading”, they often function more as lists or dashboards, and until we have time to work through the intricacies of 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.
 * 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.

이전 대화
이 주제는 과거에 논의되었습니다. 이 이전 대화에 추가 링크를 자유롭게 추가해 주십시오. Please feel free to add additional links to past conversations here.
 * 2014 – 타이포그래피 리프레시 프로젝트의 토론


 * 2014 – discussion from the Typography Refresh project