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

Читабельність
Наша основна причина для обмеження ширини контенту — покращити зручночитність усього чудового вмісту наших вікі. Читання тексту в ефективний спосіб є критично важливим для переважної більшості усього читання і редагування, яке відбувається у наших проєктах. Зручність читання залежить від кількох факторів — скажімо, розміру шрифту, контрасту, шрифту і довжини рядків, — але ми вирішили зосередитися перш за все на довжині рядків. Формативне дослідження довжини рядків під час читання друкованих документів рекомендує рядки довжиною від 45 до 90 символів/рядок (cpl). Нещодавні дослідження читання текстів на вебсайтах дають число в межах 35—100 символів/рядок, при цьому здебільшого рекомендації тяжіють до меншого числа у цьому проміжку. Однак зараз, без жодного обмеження ширини вмісту статті, читачам може доводитися читати рядки з довжиною набагато більшою рекомендованого діапазону. Праця 2005 року добре підсумовує останні дослідження: «короткі рядки легше читати» і, більше того, щодо навчання й утримання інформації, «особи, які читають вузькі абзаци, краще утримують інформацію, ніж ті. хто читає широкі абзаци».

І наостанок, хоча для нас дуже важливо проводити власні дослідження і робити власні висновки, ми вважаємо незайвим зауважити неймовірну кількість великих вебсайтів, які мають подібні обмеження на ширину контенту. Наприклад: наукові журнали на зразок Nature, новинні вебсайти як The New York Times, урядові й міжурядові вебсайти як ООН, академічні документи як LaTeX і текстові процесори як Google Docs та Etherpad. Ці приклади, у поєднанні з широким дослідженням, дають нам впевненість у своєму рішенні.

Якщо підсумувати, обмеження ширини контенту забезпечує зручність читання, менше навантаження на очі і краще засвоєння самої інформації.

Але що з цим всім білим місцем!?
Ми отримали відгуки від близько 30 редакторів (зокрема людей з широкими екранами), геть розбитих усім білим простором, який утворився з обох боків сторінки, хоча дехто з них погоджуються, що обмеження ширини краще для читання. У цього засмучення бачимо дві основні причини: Наша ціль — створити якомога кращий читацький досвід, а не заповнити контентом кожен піксель екрану. І в цьому випадку менше — це насправді більше: завдяки коротшим рядкам люди мають змогу легше читати і краще зосереджуватися, не відволікаючись на бічні панелі й інші елементи. Якщо найкраще розташування елементів на сторінці містить порожній простір, то це нормально — порожнє місце не має нічого в корені поганого.
 * 1) The white space feels like wasted space
 * 2) The white space is bright and distracting

Окрім цього, по ходу розвитку проєкту, ми сподіваємося почати пристосовувати цей простір для іншого функціоналу. Ми почали експериментувати з прикріпленням бічної панелі до лівої сторони сторінки (посилання на прототип). Далі по плану експерименти з розташуванням змісту і/або інструментів сторінки поруч з вмістом. Також, як, обмеження ширини вмісту дає нам нові можливості розташування контенту, наприклад, колонку праворуч для картки і зображень.

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

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

Чому це не зробити просто пунктом в налаштуваннях?
Одна з найкращих рис інтерфейсу MediaWiki — це те, наскільки він налаштовний. І хоча ми могли б зробити пункт налаштувань для ширини вмісту, ми подумали, що може варто було б просувати однаковий досвід, спільний для редакторів і читачів. Це може бути корисно для редакторів, які вирішують, як саме розташувати елементи на сторінці (примітка: 1024 пкс згадані як мінімальний розмір, про який треба пам'ятати, у Посібнику зі стилю в англійській Вікіпедії, хоча це й не зовсім те саме). Зараз так виходить, що редактор може редагувати сторінку шириною 1500 пкс, а читач читає її з шириною 1200 пкс. Впроваджуючи обмеження максимальної ширини ми не усуваємо цієї розбіжності повністю (бо все одно буде варіація нижче максимальної ширини, у людей для з вужчими екранами), але ми значно зменшуємо діапазон варіацій.

Тим часом ми не є стовідсотково проти налаштовуваності. Якщо ви хотіли б продовжувати використовувати нову версію векторного оформлення без обмеженої ширини, то можете використати для цього локальний користувацький скрипт чи додаток. Ми рекомендуємо оцей.

Як ми зупинилися на 960 пкс ширини?
Будь ласка, перегляньте цю сторінку, щоб дізнатися більше про те, як ми прийняли це рішення:

When will these changes be available on the largest wikis?
We hope to see the changes set as default on all wikis later in the year. Each community is welcome to join the early adopters.

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.

Which wikis these changes are default turned on?
Currently, these are:


 * sister projects:
 * 
 * 
 * 


 * non-Latin script wikis:
 * bn:
 * he:
 * fa:
 * ko:
 * sr:


 * Latin script Wikipedias:
 * eu:
 * fr:
 * pt:
 * sr:
 * tr:
 * vec:


 * additionally:
 * Office Wiki
 * 

We are open to add more wikis to this list!

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.