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

가독성
내용 폭을 제한하는 주된 이유는 우리 위키의 놀라운 콘텐츠의 가독성을 개선시키기 위함입니다. 효율적인 방식으로 문구를 읽는 것은 우리 프로젝트 간 모든 읽기 및 편집 용례 대부분에 필수적입니다. 이를테면 글꼴 크기, 대비, 글꼴, 줄 길이와 같은 가독성에 영향을 주는 요인이 여럿 있지만 우리는 처음에는 줄 길이에 초점을 두기로 결정하였습니다. 인쇄된 문구 읽기에 관한 줄 길이 연구에 따르면 한 줄에 45자에서 90자 사이의 줄 길이(cpl)를 권고합니다. 웹사이트 문구의 최근 연구에 따르면 주로 35 – 100 cpl 범위 내에 맞추며 대부분은 해당 범위의 하한에 가까운 값을 권장합니다. 그러나 현재 문서 내용의 폭 제한이 없다면 독자들은 권고된 범위를 초과한 줄 길이를 보게 될 수 있습니다. 어느 한 2005년 연구는 최근 연구를 잘 요약해주고 있습니다: "짧은 줄 길이가 읽기 더 쉬우며" 게다가 학습과 정보 집중에 관하여서는 "좁은 문단을 읽는 피실험자들은 넓은 문단을 읽을 때보다 집중도가 더 높았습니다".

끝으로, 우리가 직접 연구를 수행하고 스스로 결론을 내리는 것이 어느 경우에도 중요하지만 상당수의 주요 웹사이트가 내용 폭에 비슷한 제한을 두고 싶음을 말씀드리고 싶습니다. 예: 네이처 등의 학술 논문, 뉴욕 타임스 등의 뉴스 웹사이트, 유엔 등의 정부 및 정부 간 웹사이트, LaTeX 등의 학술 문서, 구글 문서도구, 이더패드 등의 워드 프로세서. 이 광범위한 연구와 결합된 해당 예시들은 우리의 이 결정에 신뢰감을 줍니다.

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

그런데 흰 공간은 무엇입니까?
약 30명의 편집자(특히 대형 화면을 갖춘 사람들)가 페이지의 측면에 추가된 흰 공백으로 인해 좌절했다는 이야기를 들었으나 이들 중 일부는 폭 제한이 가독성을 높여준다는 점에 동의하고 있습니다. 이 좌절에는 2가지 주된 이유가 있는 것으로 생각됩니다: 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.

독자들이 그냥 자신들의 브라우저 창을 더 작게 만들면 되지 않을까요?
일부 사람들은 다음과 같은 의견을 제기합니다: 사람들이 내용을 더 좁게 만들고 싶으면 브라우저 창을 더 작게 만들거나 페이지 하단의 "모바일 보기" 링크를 클릭하면 된다. 위에서 언급된 것처럼: 대다수 사람들이 문서를 읽으러 온다는 것을 우리가 알고 있기에 우리는 해당 용례에 따라 레이아웃을 최적화하는 것이 좋습니다. 우리는 첫 인상을 줄 기회가 한 번뿐이며 사람들이 방문하자마자 별도 수정 작업 없이 그들에게 대단한 경험을 제공하는 것을 목표로 두어야 합니다.

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

설정으로 만들면 되지 않나요?
미디어위키 인터페이스의 가장 좋은 부분 가운데 하나는 어떻게 구성할 수 있는가입니다. 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. 폭 제한 없는 새 버전의 벡터 스킨을 계속 사용하고 싶으시다면 로컬 사용자 스크립트나 소도구를 사용하여 그렇게 할 수 있습니다. 이것을 추천할 수 있습니다.

폭에 대해 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]을 포함한 다른 스킨은 영향을 받지 않습니다.

차트, 맵, a-/f-/o-/tmbox, 정보 상자, 둘러보기 상자, 기타 틀을 개선할 예정입니까?
아니요. 우리는 밝은 회색의 "문서 내용" 영역 안의 어떠한 것도 변경하지 않을 것입니다(목차는 제외):



개선사항을 어떻게 제안할 수 있습니까?
[ 프로젝트 대문의 토론 문서]에 문단을 추가하거나 SGrabarczuk (WMF), 이메일: sgrabarczuk-ctr@wikimedia.org에 문의하십시오.

어떻게 비활성화할 수 있습니까?
사용자 환경 설정 안에서 개선사항을 켜고 끄는 것이 가능합니다. 좌측 사이드바(각 문서에서 접근 가능)에서 기능 끄기 버튼을 제공하고 있기도 합니다:.

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

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

기능 비활성화가 가능한 링크를 제거하실 예정입니까?
우리는 기능 비활성화 링크를 제거하지 않을 것입니다. 레거시 벡터는 모노북처럼 과거에 기본으로 존재했던 다른 스킨과 비슷하게 해당 링크를 통해 계속 이용할 수 있습니다.

어떻게 버그를 보고할 수 있습니까?
버그가 알려진 이슈 인지 확인하려면 다음 문서를 확인하십시오.

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

새 스킨을 만드는 것은 어떻습니까? 레거시 벡터에는 무슨 일이 벌어집니까?
새 스킨을 만드는 것은 탁월한 생각입니다만 위키미디어 스킨의 경우 처음부터 새로 스킨을 만드는 것보다 기존의 것을 변경하는 것이 더 쉽습니다. 여러 이유가 있습니다:


 * 기존의 확장 기능, 소도구, 사용자 스크립트를 다른 스킨과 호환시키는 일은 매우 복잡하며 이 호환성을 유지하는 것은 비용이 너무 많이 듭니다.
 * 다른 스킨을 빌드하고 유지하는 일은 상당한 도전을 받는 일입니다.(완전히 대체하는 것은 선택사항이 아닙니다)
 * 공동체가 새로운 스킨을 빌드하는 과정에 효율적으로 협업할 가능성이 적습니다.

기술적으로 데스크톱 개선은 이나 와 같은 이전 기능이나 프로젝트와 유사합니다. 유일한 차이는 이 시점에서 더 많은 개선사항이 있다는 점입니다. 벡터의 설명문서는 적절히 유지하는 것이 좋습니다.

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

베타 기능 전용으로 하면 안 됩니까?
베타 기능은 등록된 사용자만 이용이 가능하며 개선사항은 독자와 미등록 사용자에게 서비스하도록 고안되어 있습니다. 그러므로 베타 기능만을 사용하면 모든 사용자를 대표하지 않는 매우 특정한 유형의 사용자의 의견만 제공하게 됩니다. 그리고 더 나아가 우리는 최초 적용 시점부터 독자와 익명 사용자의 의견을 수용하기를 원합니다.

기능의 성공 지표는 무엇입니까?
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)

우리가 더 구체화하기 원하는 변경사항을 정의할 때 우리는 이 목록을 확장하고 여러 번 검토할 것입니다.