Reading/Web/Desktop Improvements/Frequently asked questions/ko

가독성
Our main reason for limiting the width of the content is to improve the readability of all of the amazing content on our wikis. Reading text in an efficient manner is crucial to the large majority of all reading and editing use cases across our projects. While there are several factors that affect readability – i.e. font size, contrast, font, and line length – we have decided to focus on line length initially. Formative line length research on reading of printed texts recommends line lengths between 45 and 90 characters per line (cpl). Recent research on reading of website text focuses primarily within the range of 35 – 100 cpl, with most recommendations falling towards the smaller end of that range. However currently without any width limitation on article content readers might find themselves with line lengths far above the recommended range. A 2005 study summarizes the latest research well: "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".

Lastly, while it’s always important for us to do our own research and form our own conclusions, we think it’s worth noting the overwhelming amount of major websites that have similar limitations on content width. For example: academic journals like Nature, news websites like The New York Times, government and intergovernmental websites like the UN, academic documents like LaTeX, and word processors like Google Docs and Etherpad. Those examples, combined with the extensive research, gives us confidence in this decision.

간단히 말해 내용 폭 제한은 가독성을 제고하고, 눈 긴장을 낮추어주며, 정보 그 자체에 대해 더 나은 집중을 가능케 합니다.

그런데 흰 공간은 무엇입니까?
We have heard from around 30 editors (particularly people with large screens) who are frustrated by all of the white space created on the sides of the page, though some of them agree that the width limitation is better for reading. There seem to be two main causes of this frustration: Our goal is to create the best reading experience we can, not to fill every pixel of the screen with content. And in this case less is actually more — people are able to read more easily with shorter line lengths, and focus more easily without the distraction of sidebars or other elements. If the best layout is one that includes white space that is okay — there is nothing inherently wrong with white space.
 * 1) The white space feels like wasted space
 * 2) The white space is bright and distracting

Additionally, as the project proceeds, we are hoping to begin utilizing some of this space for other functionality. We have started experimenting with making the sidebar sticky to the left side of the page (link to prototype). Further along in the project we plan to experiment with putting a table of contents and/or page tools next to the content. Also, as, limiting the content width gives us new options for content layout, such as a right-hand column dedicated to infoboxes and images.

Why can’t readers just make their browser windows smaller?
Several people have pushed back saying: if people want the content to be more narrow they can make their browser window smaller, or click the “Mobile view” link at the bottom of the page. As mentioned above: since we know that the majority of people come to read articles we should optimise the layout around that use case. We only have one chance to make a first impression and we should aim to give people a great experience as soon as they arrive, without them having to make adjustments.

표와 기타 틀이 제한된 폭 안에 들어맞지 않는데, 나쁜 것이 아닙니까?
기나긴 수평 스크롤바가 있는 테이블이나 제한된 폭을 넘어서는 틀에 관한 여러 보고를 받았습니다. 대형 화면이 없고 노트북에서 위키백과에 접근하는 우리 사용자들 중 상당수가 이미 변경 이전에도 표와 틀에 문제를 경험하였음을 말씀드리고 싶습니다. 모든 방문자들을 수용하려면 우리의 콘텐츠 전반이 가능한 반응적이도록 만들어야 합니다.

설정으로 만들면 되지 않나요?
미디어위키 인터페이스의 가장 좋은 부분 가운데 하나는 어떻게 구성할 수 있는가입니다. And while we could make a setting for content width we wonder if it might be beneficial to encourage a common experience that is shared between editors and readers. This could potentially be helpful to editors when making decisions about page layouts (note: 1024px is mentioned as a minimum size to consider in the English Wikipedia Manual of Style, though that’s not quite the same thing). 현재 편집자는 1500px 너비의 페이지를 편집하며 독자는 1200px 너비로 읽습니다. By implementing a max-width we don’t remove this discrepancy completely (because there would still be variation below the max-width, for people with narrower screens), however we would be greatly limiting the range of variation.

That said, we are not inherently against configurability. If you would like to continue using the new version of the Vector skin without the limited width, you can use a local user script or gadget to do so. 이것을 추천할 수 있습니다.

폭에 대해 960px로 결정한 경위는 무엇입니까?
우리가 이 결정을 하게 된 것에 대해 더 알아보려면 이 문서를 검토해 주십시오:

이 변화가 규모가 가장 큰 위키들에 적용되는 시점은 언제입니까?
Not in the first half of 2021, unless a community volunteers to join our testing. Currently, we are focusing on the development of our features based on data we have already collected, and on the tests on the early adopter wikis. We do hope to see the changes set as default on all wikis later in the year.

Are the improvements to be implemented on sister projects and on non-Latin script wikis?
Yes. We have already made a list of early adopter wikis which represents various sizes and scripts. We also wanted to ensure that at least one non-Wikipedia project is selected.

어느 위키가 이 변경사항을 기본으로 활성화합니까?
현재는 다음과 같습니다:


 * 자매 프로젝트:
 * 
 * 


 * 라틴어를 사용하지 않는 위키:
 * he:
 * fa:


 * 라틴어를 사용하는 위키백과:
 * eu:
 * fr:


 * 추가적으로:
 * 오피스 위키

이 목록에 더 많은 위키를 넣을 여지가 있습니다!

제 위키에 이것을 어떻게 적용할 수 있습니까?
데스크톱 개선을 여러분의 위키에 기본적으로 보는데 관심이 있으시다면,
 * 1) 여러분의 공동체에 물어보고 총의를 달성하시고
 * 2) 지원이 필요한 경우 SGrabarczuk (WMF), 이메일: sgrabarczuk-ctr@wikimedia.org에 문의하십시오.

모노북이나 타임리스는 영향을 받습니까?
아니요. 이 변경은 벡터에만 적용됩니다. [ 벡터]는 2010년 이후로 위키미디어 위키의 기본 인터페이스입니다. [ Monobook], [  Timeless], [  Minerva], [  Modern]을 포함한 다른 스킨은 영향을 받지 않습니다.

Will you improve charts, maps, a-/f-/o-/tmboxes, infoboxes, navboxes, other templates?
No. We will not change anything that's within the light gray article content area (except for the table of contents):



How can I suggest improvements?
Add a section on the [ talk page of the main page of the project] or contact SGrabarczuk (WMF), email: sgrabarczuk-ctr@wikimedia.org.

어떻게 비활성화할 수 있습니까?
It's possible to turn the improvements on and off within user preferences. We have also provided an opt-out button in the left sidebar (accessible on each page):.

제 위키에 어떻게 적용할 수 있습니까?
먼저, 을(를) 다운로드하셨는지 확인하십시오. 안정판은 2021년 중순에 출시된다는 점을 명심하십시오. 아무튼 위험을 받아들이고 변경사항을 보고 싶으시다면 에 다음 줄을 추가하십시오:

개선사항을 평가해주셔서 기쁩니다!

기능 비활성화가 가능한 링크를 제거하실 예정입니까?
우리는 기능 비활성화 링크를 제거하지 않을 것입니다. Legacy Vector will continue to be available through that link, similar to other skins that have been default in the past, such as Monobook.

어떻게 버그를 보고할 수 있습니까?
Check the following page to see if your bug is a know issue.

You can add a task on Phabricator and add Desktop Improvements project tag or contact SGrabarczuk (WMF), email: sgrabarczuk-ctr@wikimedia.org.

새 스킨을 만드는 것은 어떻습니까? 레거시 벡터에는 무슨 일이 벌어집니까?
It would be an excellent idea to make a new skin, but in the case of Wikimedia skins, it's easier to change an existing one than to create a new one from scratch. There are various reasons:


 * it would be too complex to make the existing extensions, gadgets, and user scripts compatible with yet another skin, and too costly to maintain their compatibility,
 * it would be too challenging to build and maintain yet another skin (as a total replacement is not an option),
 * it would be less likely for the communities to collaborate effectively in the process of building a new skin.

기술적으로 데스크톱 개선은 이나 와 같은 이전 기능이나 프로젝트와 유사합니다. The only difference is that this time, there will be more of them. Vector documentation should remain relevant.

우리는 레거시 벡터를 유지하고 관리할 것입니다. 제거할 의도는 없습니다.

베타 기능 전용으로 하면 안 됩니까?
Beta features are available for registered users only, and the improvements are intended to serve our readers and unregistered users as well. Therefore, using beta features only would give us feedback from a very specific type of user that is not representative of our entire base of users. And moreover, we wish to receive the readers' and anonymous users' feedback from the earliest deployments.

기능의 성공 지표는 무엇입니까?
Increase utility among our existing audiences, proxied by:


 * Interactions
 * Increase searches per session by 5% over the course of the project
 * Increase language switching per project by 5% over the course of the project


 * Affinity
 * Increase in positive and welcoming sentiments towards the site (via surveys and user testing)
 * Increase in sentiments of trust and credibility (measured via surveys and user testing)

As we define the changes we want to make with more specificity, we will expand and iterate on this list.