Reading/Web/Desktop Improvements/Frequently asked questions/pt-br

Legibilidade
Nossa principal razão para limitar a largura do conteúdo é melhorar a legibilidade de todo o incrível conteúdo em nossas wikis. A leitura de textos de maneira eficiente é crucial para a maioria absoluta de todos os casos de uso de leitura e edição em nossos projetos. Embora existam vários fatores que afetam a legibilidade – ou seja, tamanho da fonte, contraste, fonte e comprimento da linha – decidimos focar inicialmente no comprimento da linha. Formative line length research on reading of printed texts recommends line lengths between 45 and 90 characters per line (cpl). Recent research on reading of website text focuses primarily within the range of 35 – 100 cpl, with most recommendations falling towards the smaller end of that range. No entanto, atualmente, sem qualquer limitação de largura, os leitores do conteúdo do artigo podem se encontrar com comprimentos de linha muito acima do intervalo recomendado. A 2005 study summarizes the latest research well: "short line lengths are easier to read", and furthermore, regarding learning and information retention, "subjects reading the narrow paragraphs had better retention than those reading the wide paragraphs".

Lastly, while it’s always important for us to do our own research and form our own conclusions, we think it’s worth noting the overwhelming amount of major websites that have similar limitations on content width. Por exemplo: jornais acadêmicos como Nature, sites de notícias como The New York Times, sites governamentais e intergovernamentais como o UN, documentos como LaTeX e editores de texto como Google Docs ou Etherpad. Esses exemplos, combinados com a extensa pesquisa, nos dão confiança nesta decisão.

Resumindo, limitar a largura do conteúdo permite melhor legibilidade, menos cansaço visual e melhor retenção da própria informação.

Mas e todo o espaço em branco!?
We have heard from around 30 editors (particularly people with large screens) who are frustrated by all of the white space created on the sides of the page, though some of them agree that the width limitation is better for reading. There seem to be two main causes of this frustration: Our goal is to create the best reading experience we can, not to fill every pixel of the screen with content. And in this case less is actually more — people are able to read more easily with shorter line lengths, and focus more easily without the distraction of sidebars or other elements. If the best layout is one that includes white space that is okay — there is nothing inherently wrong with white space.
 * 1) The white space feels like wasted space
 * 2) The white space is bright and distracting

Additionally, as the project proceeds, we are hoping to begin utilizing some of this space for other functionality. We have started experimenting with making the sidebar sticky to the left side of the page (link to prototype). Further along in the project we plan to experiment with putting a table of contents and/or page tools next to the content. Also, as, limiting the content width gives us new options for content layout, such as a right-hand column dedicated to infoboxes and images.

Why can’t readers just make their browser windows smaller?
Several people have pushed back saying: if people want the content to be more narrow they can make their browser window smaller, or click the “Mobile view” link at the bottom of the page. As mentioned above: since we know that the majority of people come to read articles we should optimise the layout around that use case. We only have one chance to make a first impression and we should aim to give people a great experience as soon as they arrive, without them having to make adjustments.

Tables and other templates don’t fit within the limited width, isn’t that bad?
We have received several reports of tables with long horizontal scroll bars, or templates that expand past the limited width. We’d like to point out that a large percentage of our users, who don’t have large screens and are accessing Wikipedia from their laptops, already had issues with tables and templates even before the change. We should work to make sure that all of our content is as responsive as possible to accommodate all visitors.

Why don’t we just make it a setting?
One of the best parts of the MediaWiki interface is how configurable it is. And while we could make a setting for content width we wonder if it might be beneficial to encourage a common experience that is shared between editors and readers. This could potentially be helpful to editors when making decisions about page layouts (note: 1024px is mentioned as a minimum size to consider in the English Wikipedia Manual of Style, though that’s not quite the same thing). Currently an editor might be editing a page at a width of 1500px, while a reader reads it at a width of 1200px. By implementing a max-width we don’t remove this discrepancy completely (because there would still be variation below the max-width, for people with narrower screens), however we would be greatly limiting the range of variation.

That said, we are not inherently against configurability. If you would like to continue using the new version of the Vector skin without the limited width, you can use a local user script or gadget to do so. We can recommend this one.

How did we decide on 960px for the width?
Please review this page to learn more about how we made this decision:

When will these changes be available on the largest wikis?
Not in the first half of 2021, unless a community volunteers to join our testing. Currently, we are focusing on the development of our features based on data we have already collected, and on the tests on the early adopter wikis. We do hope to see the changes set as default on all wikis later in the year.

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:
 * he:
 * fa:


 * Latin script Wikipedias:
 * eu:
 * fr:


 * additionally:
 * Office Wiki

We are open to add more wikis to this list!

How can this be deployed on my 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-ctr@wikimedia.org if you need support.

O Monobook ou o Timeless serão afetados?
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].

Você vai melhorar gráficos, mapas, a-/f-/o-/mboxes, infoboxes, navboxes e outras predefinições?
Não. Não mudaremos nada que esteja dentro da área cinza claro conteúdo do artigo (exceto o índice):



Como posso sugerir melhorias?
Informe na [ discussão da página principal do projeto] ou entre em contato com SGrabarczuk (WMF), email: sgrabarczuk-ctr@wikimedia.org.

Como posso desativá-lo?
É possível ativar e desativar as melhorias nas preferências de usuário. Também fornecemos um botão de desativação na barra lateral esquerda (acessível em cada página):.

Como posso habilitá-lo em minha própria wiki?
Primeiro, certifique-se de ter baixado. Lembre-se de que a versão estável será lançada em meados de 2021. Se você aceita o risco e gostaria de ver nossas alterações de qualquer maneira, adicione as seguintes linhas em seu :

Ficamos felizes em saber que você aprecia nossas melhorias!

Você removerá o link que permite a desativação?
Não removeremos o link de desativação. O Vector Legado continuará disponível por meio desse link, semelhante a outros que eram padrão no passado, como Monobook.

Como posso relatar um erro?
Verifique a página a seguir para ver se seu erro é um problema conhecido.

You can add a task on Phabricator and add Desktop Improvements project tag or contact SGrabarczuk (WMF), email: sgrabarczuk-ctr@wikimedia.org.

Por que não fazer uma nova aparência? O que acontecerá com o Vector Legado?
Seria uma excelente ideia fazer uma nova, mas no caso de aparências da Wikimedia, é mais fácil mudar uma existente do que criar uma nova do zero. Existem vários motivos:


 * 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.

Tecnicamente, as melhorias da área de trabalho são semelhantes a recursos ou projetos anteriores, como ou. The only difference is that this time, there will be more of them. Vector documentation should remain relevant.

Manteremos o Vector Legado. Não há intenção de sua remoção.

Por que não usar apenas recursos beta?
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.

Quais são as métricas de sucesso do recurso?
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)

À medida que definimos as mudanças que queremos fazer com mais especificidade, iremos expandir e iterar nesta lista.