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 пкс ширини?
Будь ласка, перегляньте цю сторінку, щоб дізнатися більше про те, як ми прийняли це рішення:

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

Чи покращення будуть впроваджені у сестринських проєктах і у вікі з не-латинкою?
Так. Ми уже зробили список «перших вікі», серед яких вікі різних розмірів і писемностей. Ми також хотіли впевнитися, що там є принаймні один проєкт, що не є Вікіпедією.

У яких вікі ці зміни за замовчуванням увімкнені?
Зарає це такі:


 * сестринські проєкти:
 * 
 * 
 * 


 * вікі з не-латинкою:
 * bn:
 * he:
 * fa:
 * ko:
 * sr:


 * Вікіпедії латинкою:
 * eu:
 * fr:
 * pt:
 * sr:
 * tr:
 * vec:


 * а також:
 * офісна вікі
 * 

Ми відкриті до додання більшої кількості вікі до цього списку!

Як це можна впровадити у моїй домашній вікі Вікімедіа?
Якщо ви хочете побачити Стаціонарні покращення увімкненими за замовчуванням у своїй вікі,
 * 1) запитайте у своєї спільноти і досягніть консенсусу,
 * 2) зв'яжіться з SGrabarczuk (WMF), електронна пошта sgrabarczuk@wikimedia.org, якщо вам треба допомога.

Як я можу увімкнути їх у власній вікі (треті сторони)?
Для початку, переконайтеся, що завантажили. Майте на увазі, що стабільна версія з'явиться у середині 2021. Якщо ви приймаєте ризик і все одно хотіли б побачити наші зміни, додайте такі рядки до вашого :

Ми раді дізнатися, що вам подобаються наші покращення!

Чи теми Monobook або Timeless будуть зачеплені?
Ні. Ці зміни будуть застосовані лише до векторного оформлення. [ Вектор] увімкнено за замовчуванням у вікі Вікімедіа з 2010 року. Жодне інше оформлення не буде зачеплене, у тому числі [ Monobook], [ Timeless], [ Minerva] чи [ Modern].

Чи будете ви покращувати графіки, карти, шаблони повідомлень, картки, навігаційні чи інші шаблони?
Ні. Ми не змінюватимемо нічого, що належить до сірої зони «вміст статті» (окрім змісту):



Як я можу запропонувати покращення?
Додайте розділ на [ сторінці обговорення головної сторінки проєкту] або напишіть SGrabarczuk (WMF), ел. пошта: sgrabarczuk@wikimedia.org.

Як ви співпрацюєте зі спільнотами?

 * 1) Перед впровадженням:
 * 2) Ми виконали дослідження користувачів і переглянути додатки й користувацькі скрипти. Див. детальніше на.
 * 3) Ми запрошували різні вікі приєднатися до переліку перших, які отримають покращення.
 * 4) Ми провели обговорення за круглим столом на Вікіманії 2019 (див. результати).
 * 5) Ми провели два раунди тестування прототипу. У цей період редактори могли отримати розуміння наших ідей і поділитися з нами, що вони схвалюють, а що ні.
 * 6) Невдовзі після впровадження кожної риси покращення, ми збираємо дані про використання через  для кожної вікі окремо.
 * 7) Ми робимо A/B tests для зареєстрованих користувачів. Половина з них бачить змінений інтерфейс, а половина не спостерігає жодних змін. Далі, ми порівнюємо статистику. Якщо результати негативні, ми покращуємо зміну або відкочуємо її.
 * 8) Для незареєстрованих користувачів ми порівнюємо до і після. на жаль, ми не можемо проводити A/B-тестування користувачів, які не ввійшли в систему.
 * 9) Ми слідкуємо за сторінкою обговорення проєкту. Ми також регулярно долучаємося до обговорення в окремих вікі.
 * 10) Наші  забезпечують нам більш тісну роботу з кількома спільнотами, швидше й ефективніше реагування.

Як мені це вимкнути?
Покрашення можна увімкнути й вимкнути у налаштуваннях користувача. Ми також розмістили кнопку вимкнення на бічній панелі ліворуч, яка є на кожній сторінці: 

Чи приберете ви посилання, яке дозволяє вимкнути це?
Ми не будемо прибирати посилання на вимкнення. Старий вектор залишиться доступним за посиланням, подібно до інших оформлень, які були за замовчуванням у минулому, як-то Monobook.

Як повідомити про помилку?
Перегляньте цю сторінку, чи ваш баг не є уже відомим:.

Ви можете створити завдання на Фабрикаторі і додати тег проєкту Стаціонарних покращень або зв'язатися з SGrabarczuk (WMF), ел. пошта: sgrabarczuk@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)

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