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

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

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

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

그런데 흰 공간은 무엇입니까?
약 30명의 편집자(특히 대형 화면을 갖춘 사람들)가 페이지의 측면에 추가된 흰 공백으로 인해 좌절했다는 이야기를 들었으나 이들 중 일부는 폭 제한이 가독성을 높여준다는 점에 동의하고 있습니다. 이 좌절에는 2가지 주된 이유가 있는 것으로 생각됩니다: 우리의 목표는 화면의 모든 픽셀에 내용을 채우는 것이 아니라 우리가 할 수 있는 한 최상의 읽기 경험을 창출하는 것입니다. 그리고 이 경우 채울 내용이 적을수록 더 좋습니다. 사람들은 줄 길이가 더 짧아야 더 쉽게 읽을 수 있으며 사이드바나 다른 요소의 방해를 받지 않고 더 쉽게 집중할 수 있습니다. 최상의 레이아웃이 흰 공간을 포함하고 있다면 문제가 없음을 의미합니다. 즉 본질적으로 흰 공간에 아무런 문제가 없습니다.
 * 1) The white space feels like wasted space
 * 2) The white space is bright and distracting

게다가 프로젝트가 진행될수록 우리는 다른 기능을 위해 이 공간의 일부를 활용하는 것을 시작하길 희망하고 있습니다. 우리는 사이드바를 페이지의 좌측에 고정시키는 실험을 시작했습니다. (프로토타입 링크) 프로젝트가 더 진척되면 우리는 목차와 문서 도구를 콘텐츠 옆에 배치하는 실험을 할 계획입니다. 또, 내용 폭을 제한하면 정보 상자와 이미지 전용의 우측 공간 등 콘텐츠 레이아웃에 대한 새로운 옵션이 생깁니다.

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

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

설정으로 만들면 되지 않나요?
미디어위키 인터페이스의 가장 좋은 부분 가운데 하나는 어떻게 구성할 수 있는가입니다. 그리고 우리가 내용 폭 설정을 만들 수 있겠지만 편집자와 독자 사이에 공유되는 통일감있는 경험을 제공하는데 이익이 될지는 의문입니다. 이것은 잠재적으로 페이지 레이아웃에 관한 토론을 할 때 편집자에게 도움이 될 수 있습니다.(참고: 1024px은 영어 위키백과 편집 지침에서 고려하는 최소 크기로 언급되고 있으나 여기서 이야기하는 것과는 다른 건입니다) 현재 편집자는 1500px 너비의 페이지를 편집하며 독자는 1200px 너비로 읽습니다. 최대폭을 설정한다고 하여 이 차이를 완전히 없애지는 못하지만(너비가 더 좁은 화면을 사용하는 사람들의 경우 최대폭 아래의 편차가 여전히 있을 것이기 때문에) 우리는 이 편차 범위를 상당 부분 제한하고 있습니다.

즉, 우리가 구성 가능성에 대해 반대한다는 것을 의미하는 것이 아닙니다. 폭 제한 없는 새 버전의 벡터 스킨을 계속 사용하고 싶으시다면 로컬 사용자 스크립트나 소도구를 사용하여 그렇게 할 수 있습니다. 이것을 추천할 수 있습니다.

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

이 변화가 규모가 가장 큰 위키들에 적용되는 시점은 언제입니까?
우리는 올해 말에 모든 위키에서 이러한 변화를 기본적으로 볼 수 있기를 희망합니다. Each community is welcome to join the early adopters.

이 개선사항이 자매 프로젝트와 라틴어를 쓰지 않는 위키에 구현됩니까?
예. 우리는 이미 다양한 규모와 언어를 대표하는 얼리 어답터 위키 목록을 만들었습니다. 또, 우리는 반드시 위키백과가 아닌 프로젝트를 적어도 하나 선택하기를 원했습니다.

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


 * 자매 프로젝트:
 * 
 * 
 * 


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


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


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

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

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

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

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

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

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



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

How do you work with the communities?

 * 1) Prior to the deployments:
 * 2) We performed user research, and reviewed gadgets and user scripts. See the  for more details.
 * 3) We have been reaching out to various wikis asking to join the early adopters.
 * 4) We had a roundtable discussion at Wikimania in 2019 (see the outcomes).
 * 5) We have run two prototype testing rounds. Editors could gain an understanding of our ideas, and share what they appreciate or find confusing.
 * 6) Shortly after the deployment of each feature improvement, we collect usage data via  for each early adopter wiki.
 * 7) We run A/B tests for logged-in users. A half of them can experience the changed interface, and a half does not see any difference. Next, we compare the statistics. In the case of negative results, we improve the change or roll it back.
 * 8) For logged-out, we compare before and after. Unfortunately, we are not able to perform A/B tests on logged-out users.
 * 9) We watch the project talk page. We also engage in discussions on individual wikis regularly.
 * 10) Our  make it easier for us to work with a few communities more closely, react more quickly and effectively.

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

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

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

파브리케이터에 태스크를 추가하고 데스크톱 개선 프로젝트 태그를 추가하거나 SGrabarczuk (WMF), 이메일: sgrabarczuk-ctr@wikimedia.org에 문의할 수 있습니다.

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


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

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

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

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

기능의 성공 지표는 무엇입니까?
기존 사용자 간 공익의 제고:


 * 소통
 * 프로젝트 중 세션 당 5%까지 검색율 제고
 * 프로젝트 중 프로젝트 당 언어 전환을 5%까지 제고


 * 친밀감
 * 사이트에 대한 긍정적이고 따뜻하게 맞이할 정서를 제고 (설문조사와 사용자 테스트를 통해)
 * 신뢰와 신용의 정서를 제고 (설문조사와 사용자 테스트를 통해 측정)

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