Reading/Web/Desktop Improvements/Updates/2022-07 for the largest wikis/pt-br

Defining a process for the discussion of making Vector 2022 the new default

About the project

Read this in another language

In short: in one to two weeks, we would like to begin the conversation to update the default design of Wikipedia to Vector 2022.

We are interested in deciding on the process we want for the conversation before discussing the change itself.

This is because we want to have a good decision-making process that allows for a way to identify the needs of the community from the new skin.

Hi everyone,

We would love to see the Vector 2022 skin (see what it looks like) become the new default across all wikis, including [insert your language] Wikipedia.

The skin would be turned on for all anonymous users, and also all logged-in users who now use Vector (the current default). Logged-in users are and will be able to switch to any of our other available skins, including the current Vector.

We will be ready to begin making the change at the end of August (and not in July, as previously announced), when the visual refinements and other deployment blockers are ready.

The goal of the project is to make the interface more welcoming and comfortable for readers and useful for advanced users.

The project consists of a series of feature improvements which make it easier to read and learn, navigate within the page, search, switch between languages, use page and user tools, and more.

The team has been working on this change for the past 3 years, ensuring that every change is thoroughly tested and proven to work.

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)

Mais detalhes sobre como temos construído o Vector 2022

Revele para ler

Problem identification research with readers and editors - durante esta fase, estudamos a forma como as pessoas utilizam o site. Identificamos os maiores problemas de usabilidade, bem como problemas para explorar o site mais a fundo, ficando mais envolvidos com a leitura ou a edição. Fizemos isso entrevistando leitores e editores em vários países e locais Desenvolvimento e testes de protótipos - é quando construímos as idéias de uma característica e começamos a mostrar coisas novas para nosso público. Cada recurso foi testado com leitores e editores através de entrevistas e rodadas de testes de protótipo. Geralmente, para testes com os editores, usamos banners centrais de avisos em wikis de vários idiomas para que possamos ter o público mais diversificado possível. Cada protótipo foi testado por aproximadamente 200 editores, em média Refino e construção - então tomamos o feedback do teste do protótipo e refinamos ou alteramos o protótipo com base nas necessidades que foram identificadas no teste do protótipo. Em alguns casos, pedimos feedback adicional para que tenhamos certeza de que estamos tomando as decisões certas 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. Finalmente, nós implantamos o recurso em mais wikis e continuamos monitorando o modo como as pessoas o estão utilizando para que possamos sinalizar qualquer problema. Estamos trabalhando em uma maneira fácil de explorar todos os dados e pesquisas acima (e estamos abertos a sugestões sobre o melhor formato). Por enquanto, a melhor forma de ver os testes é: A partir de Leitura/Rede/Melhorias da Área de Trabalho/Características, selecione o recurso no qual você está mais interessado Dentro dessa página de características, consulte a seção de testes Qualitativos ou Quantitativos para ver os resultados e nossas conclusões Para maiores detalhes sobre estes dados, visite nosso repositório.

Uma rápida visão geral de nossos aprendizados

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. O objetivo é que as pessoas rolem menos e assim, economizem tempo Nosso teste A/B mostrou uma redução média de 15% nas rolagens ao topo, por sessão, para usuários logados dentro dos 15 wikis pilotos que testamos.

Atualmente, estamos terminando a parte prevista do trabalho de desenvolvimento. Pensamos que este é o melhor momento para planejar qualquer trabalho adicional que precise ser feito com base nas necessidades das diversas comunidades. Esperamos iniciar este processo durante esta conversa.

Qual deve ser o aspecto do processo?

We need your help and feedback on how to proceed. We have two requests:

1. We need to talk in a way that works well for the [insert your language] Wikipedia community. What would be the best format and timeline to discuss the change? We have included a proposed format below, and are interested in what you think about it. If you agree, we can begin the deployment conversation in one week. Here is our suggestion:
   1. Have the deployment conversation that would take 2 weeks. The goal for that discussion will be to identify breaking issues or opportunities for improvement for the new skin. It will be important for us to reduce the risk of bugs or imperfections that would be particularly troublesome on [insert your language] Wikipedia
   2. After the deployment conversation, we get back to you with a prioritized list of remaining work/fixes necessary prior to deployment
   3. Before the deployment,
      • Banners announcing the change will be displayed for logged-out and logged-in users
      • The announcement will be made both on the Village Pump as well as in the Tech News.
   4. We proceed with deployment once the agreed upon fixes are ready.
2. We need to understand the perspectives of different parts of the [insert your language] Wikipedia community. What forms of communication would help to gather feedback and further raise awareness for the [insert your language] Wikipedia community? We would like to have an open discussion, but are open to other forms such as office hours dedicated specifically for the [insert your language] Wikipedia community, or guest presentations at community meetings. Se necessário, também podemos tentar ajustar a linha do tempo das conversas com base em suas necessidades.

Agradecemos suas respostas aqui, ou via e-mail (olga@wikimedia.org, sgrabarczuk@wikimedia.org), bem como durante o [[Special:MyLanguage/Reading/Web/Desktop Improvements/Updates/Talk to Web|nosso próximo expediente].

Thank you for your time and help.