Читання/Веб/Стаціонарні покращення/Новини/2022-07 для найбільших вікі

From mediawiki.org
This page is a translated version of the page Reading/Web/Desktop Improvements/Updates/2022-07 for the largest wikis and the translation is 30% complete.

Визначмо процес обговорення того, щоб Вектор 2022 став за замовчуванням

About the project

Читати це іншою мовою

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

Привіт усім!

Ми б хотіли, щоб оформлення Вектор 2022 (гляньте, як це виглядає) стало новим виглядом усіх вікі за замовчуванням, у тому числі в українській Вікіпедії. Це оформлення будуть бачити усі анонімні користувачі, а також усі залогінені користувачі, які зараз використовують Вектор (поточний вигляд за замовчуванням). Користувачі, які увійшли в свою обліковку, можуть і будуть могти перемкнутися на будь-яку з наших доступних тем, у тому числі на поточний Вектор. Ми готові будемо починати зміни наприкінці серпня (а не в липні, як оголошували раніше), коли будуть готові візуальні удосконалення та вирішені інші завади до розгортання.

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

Every one of our changes goes through a rigorous process. First, research, then development, qualitative and quantitative testing with readers and editors, prototype testing with editors (across 30+ language communities), more changes based on the communities feedback, and monitoring. When a change does not meet the success criteria or does not perform better than the previous version, we either stop developing the change or work on it until performance is improved.

The changes we have made will be crucial to making the site more welcoming and easier to use to new readers and editors. When compared to the old Vector skin, Vector 2022 is proven to:

  • Save time while reading and editing (measured by decreases in scrolling to the top of the page after the introduction of sticky header and table of contents)
  • Increase exploration within a given page (measured by increased clicks to the table of contents)
  • Improve readability (measured via collapsible sidebar usage)
  • Improve the discovery of new content (measured by an increase in searching)

More details on how we have been building Vector 2022

Unhide to read 
  1. Problem identification research with readers and editors - during this phase, we studied the way people use the site. We identified the largest usability issues as well as issues to exploring the site further, becoming more engaged with reading or editing. We did this by interviewing readers and editors across multiple countries and locations
  2. Prototype development and testing - this is when we build out the ideas of a feature and begin showing new things to our audiences. Each feature was tested with readers and editors through interviews and rounds of prototype testing. Generally, for testing with editors we used central notice banners across multiple language wikis so that we can get the most diverse audience possible. Each prototype was tested by approximately 200 editors on average
  3. Refining and building - we then take the feedback from the prototype testing and refine or change the prototype based on what needs were identified in the prototype testing. In some cases, we ask for additional feedback so that we’re sure we’re making the right decisions
  4. A/B testing on pilot (early adopter) wikis and other quantitative testing - this is the "beta" phase. We test whether the feature works as expected based on the criteria of success we have previously defined. For example, the sticky header was designed to decrease scrolling to the top of the page. We gave the sticky header to 50% of users and compared them to the other 50% for two weeks. After two weeks we compared the results and identified that that people that had the sticky header were indeed scrolling less to the top of the page in order to select any of the tools available there. If we get negative results from our test, we change the feature and test again. During this phase, we also monitor usage across all wikis, where many account holders are already using the new skin.
  5. Finally, we deploy the feature on more wikis and continue monitoring the way people are using it so that we can flag any issues.

We are working on an easy way to explore all of the above data and research (and are welcome to suggestions on the best format). For now, the best way to see the testing is:

  • From Reading/Web/Desktop Improvements/Features, select the feature you are most interested in
  • Within that feature page, refer to the Qualitative or Quantitative testing section to see the results and our conclusions

For more details on this data, please visit our repository.

A quick overview of our learnings

Collapsible sidebar 

The collapsible sidebar allows people to collapse the main menu in order to focus on reading - helping to find the information needed without distraction

  • Qualitative testing with readers and editors on the usefulness of the sidebar and our navigation. Our conclusion here was that the number of different tools provided on the page by default was found to be overwhelming by readers and actively discouraged them from reading, but also from exploring the functionality within the page, an effect opposite of what the exposure of multiple tools aims to do. More details can be found on our feature page for the collapsible sidebar, as well as within the original report
  • Quantitative testing on the usage behavior of the sidebar itself, in both its open and collapsed states (see the results). When using the sidebar, logged-out users are much more likely to collapse it and, once collapsed, to keep it collapsed. In addition, the rate of un-collapsing also indicated that users are aware that, were they to need to navigate to an item in the sidebar, that option was available to them.
Maximum line width 

We have introduced a maximum line width to articles. Research has shown that limiting the width of long-form text leads to a more comfortable reading experience, and better retention of the content itself.

  • Our studies with readers showed that readability was an issue with the current interface, in particular being able to focus on the content
  • Pages that are not in a long-text format (such as diffs, special pages, page history) will be presented at full-width as before
  • Logged-in users who wish to read articles at full width are welcomed to set up a script or gadget that will allow for this, such as this one
  • For more details on research and motivation, see our research section
Search 

The new search widget includes important context that makes it easier for users to find the query they are looking for by adding images and descriptions for each search results

  • People had difficulties finding the correct result using our previous search
  • Our A/B testing showed that adding the new search can lead to a 30% increase in search sessions initiated on the wikis we tested
Language switching 

The new language switching tools are more prominently-placed than before. They allow multilingual readers and editors to find their preferred language more easily.

  • Readers did not previously know they could switch languages from the page, even if they read multiple language wikis habitually. They would use external search engines to find the correct article instead.
  • In our user testing, new readers were able to find the new location much quicker than the previous location
  • Our qualitative testing showed that this was more difficult to find for existing users who were used to the previous location, leading us to iterate on the feature. We have since added a note in the previous location of the language switcher and made the button itself a more prominent color
  • In the future, we will continue exploration on languages, considering potentially a direct link to a person’s most frequent languages
User menu 

The new user menu provides links to all links related to the user in one place. This reduces confusion between general navigation links and specific user links

  • New editors were confused between the links at the top of the page and other navigation. They didn’t know these links pertained to their personal tools
  • Our user testing with readers and editors showed that people found it intuitive that all user links are in a single menu and that the menu is easy to find
  • In our prototype testing, 27 out of 38 (71%) editors and other logged-in users showed strong positive experiences with the user menu
  • Based on community requests and current data, we iterated on the feature and moved the watchlist link out of the user menu for easier access
Sticky header 

The sticky header gives access to functionality that is used most frequently that was previously only accessible at the top of the page. The goal is for people to scroll less and thus, save time

  • Our A/B test showed an average 15% decrease in scrolls to the top per session for logged-in users within the 15 pilot wikis we tested on

Currently, we are finishing the predicted part of the development work. We think this is the best time to plan for any additional work that might need to be done based on needs of the various communities. We hope to begin this process during this conversation.

What should the process look like?

Нам треба ваша допомога і відгуки щодо того, як рухатись далі. У нас є два прохання:

  1. Нам треба обговорити все у такий спосіб, який спрацює для спільноти української Вікіпедії. Який формат і терміни будуть найкращими для обговорення змін? Ми включили нижче пропозицію формату, і нам цікаво почути, що ви про це думаєте. Якщо ви згодні, ми можемо почати розмову про розгортання через тиждень. Ось наша пропозиція:
    1. Провести обговорення розгортання, яке триватиме 2 тижні. Ціль цього обговорення — визначити камені спотикання чи можливості для покращення нового оформлення. Нам важливо зменшити ризик багів чи недоліків, які були б особливо проблематичними для української Вікіпедії.
    2. Після обговорення ми повернемось до вас зі списком робіт / побажань, необхідних до впровадження
    3. Перед впровадженням:
      • Банери, що оголошують зміну, будуть показуватись для залогінених і незалогінених користувачів
      • Оголошення буде опубліковане у Кнайпі і в Техновинах.
    4. Ми перейдемо до розгортання тоді, коли погодимося на виправленнях.
  2. Нам треба розуміти точки зору різних частин спільноти української Вікіпедії. Які форми комунікації допоможуть зібрати відгуки і підвищити поінформованість спільноти української Вікіпедії? Ми б хотіли провести відкрите обговорення, але відкриті й до інших форм, таких як офісні години конкретно для спільноти української Вікіпедії або гостьові презентації на вікізустрічах. Якщо треба, ми також можемо підлаштувати графік обговорень під ваші потреби.

Будемо раді вашим відповідям тут чи на електронну пошту (olga@wikimedia.org, sgrabarczuk@wikimedia.org), а також під час нашої наступної офісної години.

Дякуємо за ваш час і допомогу.