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

Читаемость
Наша основная причина ограничения ширины контента — это улучшить читаемость всего удивительного содержимого наших вики. Эффективное чтение текста имеет решающее значение для подавляющего большинства всех случаев чтения и редактирования в наших проектах. Хотя есть несколько факторов, влияющих на читаемость, например: размер шрифта, контрастность, сам шрифт и длина строки — изначально мы решили сосредоточиться на длине строки. Исследование о формировании длины строки при чтении печатных текстов рекомендует длину строки от 45 до 90 символов в строке (cpl). Недавние исследования по чтению текста веб-сайта сосредоточены в основном на диапазоне от 35 до 100 cpl, при этом большинство рекомендаций относятся к меньшему концу этого диапазона. Однако в настоящее время без каких-либо ограничений по ширине содержания статьи читатели могут обнаружить, что длина строки намного превышает рекомендуемый диапазон. Исследование 2005 года хорошо обобщает последние исследования: «короткие строки легче читать», и, кроме того, что касается обучения и удержания информации, «испытуемые, читающие узкие абзацы, запоминают лучше, чем те, кто читает широкие абзацы».

Наконец, хотя для нас всегда важно проводить собственное исследование и делать собственные выводы, мы считаем, что стоит отметить огромное количество крупных веб-сайтов, которые имеют аналогичные ограничения по ширине контента. Например: академические журналы, такие как Nature, новостные веб-сайты, такие как The New York Times, правительственные и межправительственные веб-сайты, такие как UN, академические документы, такие как LaTeX, и текстовые процессоры, такие как [ https://www.google.com/docs/about/ Google Docs] и Etherpad. Эти примеры в сочетании с обширными исследованиями вселяют в нас уверенность в правильности этого решения.

Короче говоря, ограничение ширины содержимого обеспечивает лучшую читаемость, меньшее напряжение глаз и лучшее запоминание самой информации.

Но что насчет всего пустого пространства!?
Мы слышали от примерно 30 редакторов (особенно людей с большими экранами), которые были разочарованы пустым пространством, появившемся по бокам страницы, хотя некоторые из них согласны с тем, что ограничение ширины лучше для чтения. По-видимому, есть две основные причины этого разочарования: Наша цель — создать наилучшие условия для чтения, а не заполнять контентом каждый пиксель экрана. И в этом случае меньше означает на самом деле больше — люди могут легче читать с более короткими строками и легче фокусироваться, не отвлекаясь на боковые панели или другие элементы. Если лучший макет — это тот, который включает пустое пространство, это нормально — в пустом пространстве нет ничего плохого по своей сути.
 * 1) Пустое пространство кажется потраченным впустую
 * 2) Пустое пространство яркое и отвлекает

Кроме того, по мере продвижения проекта мы надеемся начать использовать часть этого пространства для других функций. Мы начали экспериментировать с приклеиванием боковой панели к левой стороне страницы (ссылка на прототип). Далее, согласно проекту, мы планируем поэкспериментировать с размещением оглавления и/или инструментов страницы рядом с контентом. Кроме того, как, ограничение ширины контента дает нам новые возможности для макета контента, такие как правый столбец, предназначенный для информационных блоков и изображений.

Почему читатели не могут просто уменьшить окна своего браузера?
Несколько человек возразили, заявив: если люди хотят, чтобы контент был более узким, они могут уменьшить окно своего браузера или щелкнуть ссылку «Мобильный просмотр» внизу страницы. Как упоминалось выше: поскольку мы знаем, что большинство людей приходят читать статьи, мы должны оптимизировать макет для этого варианта использования. У нас есть только один шанс произвести первое впечатление, и мы должны стремиться дать людям отличный опыт, как только они придут, без необходимости вносить коррективы.

Таблицы и другие шаблоны не помещаются в ограниченную ширину, разве это не плохо?
Мы получили несколько отчетов о таблицах с длинными горизонтальными полосами прокрутки или о шаблонах, которые расширяются за пределы ограниченной ширины. Мы хотели бы отметить, что у большого процента наших пользователей, у которых нет больших экранов и которые заходят в Википедию со своих ноутбуков, уже были проблемы с таблицами и шаблонами еще до изменения. Мы должны работать над тем, чтобы весь наш контент был максимально адаптивным для всех посетителей.

Почему бы нам просто не сделать это настройкой?
Одной из лучших частей интерфейса MediaWiki является то, насколько он настраиваемый. И хотя мы могли бы настроить ширину контента, мы задаемся вопросом, может ли быть полезно поощрять общий опыт, которым пользуются редакторы и читатели. Это потенциально может быть полезно редакторам при принятии решений о макетах страниц (примечание: 1024 пикселя упоминается как минимальный размер, который следует учитывать в Руководстве по стилю английской Википедии, хотя это не совсем одно и то же). В настоящее время редактор может редактировать страницу шириной 1500 пикселей, а читатель читает ее шириной 1200 пикселей. Реализуя max-width, мы не устраняем это несоответствие полностью (потому что для людей с более узкими экранами по-прежнему будут вариации ниже max-width), однако мы сильно ограничим диапазон вариаций.

Тем не менее, мы по своей сути не против конфигурируемости. Если вы хотите продолжить использовать новую версию Векторной темы оформления без ограничения ширины, вы можете использовать для этого локальный пользовательский скрипт или гаджет. Мы можем порекомендовать этот.

Как мы выбрали ширину 960 пикселей?
Пожалуйста, просмотрите эту страницу, чтобы узнать больше о том, как мы приняли это решение:

Когда эти изменения будут доступны на крупнейших вики?
Мы надеемся увидеть включение наших изменений по умолчанию на всех вики позже в этом году. Каждое сообщество может присоединиться к ранним последователям.

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.

On which wikis are these changes turned on by default?
Currently, these are: We are open to add more wikis to this list!

Additionally:
 * Office Wiki
 * 
 * MediaWiki wiki
 * Wikimedia Foundation Governance wiki
 * Collab wiki
 * Strategy wiki

How can this be deployed on my home Wikimedia wiki?
If you are interested to see the Desktop Improvements as default on your wiki,
 * 1) ask your community and reach the consensus,
 * 2) contact SGrabarczuk (WMF), email: sgrabarczuk@wikimedia.org if you need support.

How can I enable it on my own (third-party) wiki?
First, make sure you have downloaded. Be mindful that the stable version will be released in mid 2021. If you accept the risk and would like to see our changes anyway, add following lines in your :

We are glad to learn that you appreciate our improvements!

Will Monobook or Timeless be affected?
No. These changes will be applied to Vector only. [ Vector] has been the default interface on Wikimedia wikis since 2010. No other skins will be affected, including [ Monobook], [ Timeless], [ Minerva] or [ 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@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.

How can I disable it?
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): 

Will you remove the link that allows to opt-out?
We will not remove the opt-out link. Legacy Vector will continue to be available through that link, similar to other skins that have been default in the past, such as Monobook.

How can I report a bug?
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@wikimedia.org.

Why not make a new skin? What will happen to Legacy Vector?
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.

Technically, Desktop Improvements are similar to previous features or projects such as or. The only difference is that this time, there will be more of them. Vector documentation should remain relevant.

We will keep and maintain the Legacy Vector. There is no intention of its removal.

Why not use beta features only?
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.

What are the feature's success metrics?
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.