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. A pesquisa de comprimento de linha na leitura de textos impressos recomenda comprimentos de linha entre 45 e 90 caracteres por linha (cpl). Pesquisas recentes sobre a leitura de textos de sites se concentram principalmente na faixa de 35 a 100 cpl, com a maioria das recomendações caindo para a extremidade menor dessa faixa. 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. Um estudo de 2005 resume as pesquisas mais recentes muito bem: "linhas de largura menor são mais fáceis de serem lidas", e além disto, sobre aprendizado e retenção de conhecimento, "os sujeitos lendo os parágrafos mais estreitos tiveram uma maior retenção do que aqueles lendo parágrafos mais largos".

Finalmente, enquanto é importante que façamos nossa própria pesquisa e cheguemos às nossas próprias conclusões, acreditamos que é importante notar a grande quantidade de sites que possuem uma limitação semelhante na largura do conteúdo. 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!?
Ouvimos cerca de 30 editores (principalmente pessoas com telas grandes) que estão frustrados com todo o espaço em branco criado nas laterais da página, embora alguns deles concordem que a limitação de largura é melhor para leitura. Parece haver duas causas principais para essa frustração: Nosso objetivo é criar a melhor experiência de leitura possível, não preencher todos os pixels da tela com conteúdo. E, neste caso, menos é realmente mais — as pessoas são capazes de ler mais facilmente com comprimentos de linha mais curtos e se concentrar mais facilmente sem a distração de barras laterais ou outros elementos. Se o melhor layout incluir um espaço em branco, tudo bem — não há nada inerentemente errado com o espaço em branco.
 * 1) The white space feels like wasted space
 * 2) The white space is bright and distracting

Além disso, à medida que o projeto avança, esperamos começar a utilizar algum deste espaço para outras funcionalidades. Nós começamos a experimentar manter a barra lateral fixa ao lado esquerdo da página (ligação para o protótipo). Mais adiante no projeto, planejamos experimentar colocar um índice e/ou ferramentas ao lado do conteúdo. Also, as, limiting the content width gives us new options for content layout, such as a right-hand column dedicated to infoboxes and images.

Por que os leitores não podem simplesmente diminuir as janelas do navegador?
Várias pessoas contestaram, dizendo: se as pessoas querem que o conteúdo seja mais restrito, elas podem diminuir a janela do navegador ou clicar no link “Versão móvel” na parte inferior da página. 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?
Uma das melhores partes da interface do MediaWiki é como ela é configurável. 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). Atualmente, um editor pode estar editando uma página com uma largura de 1500px, enquanto um leitor a lê com uma largura de 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.

Dito isso, não somos intrinsecamente contra a configurabilidade. Se desejar continuar usando a nova versão do Vector sem a largura limitada, você pode usar localmente um código ou gadget para fazer isso. We can recommend this one.

Como decidimos 960px para a largura?
Veja esta página para saber mais sobre como tomamos esta decisão:

Quando essas mudanças estarão disponíveis nas wikis maiores?
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.

As melhorias devem ser implementadas em projetos irmãos e em wikis não latinas?
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.

Em quais wikis essas mudanças são ativadas por padrão?
Atualmente, são:


 * projetos irmãos:
 * 
 * 
 * 


 * wikis não latinas:
 * bn:
 * he:
 * fa:
 * ko:
 * sr:


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


 * Além disso:
 * Office Wiki
 * 

Estamos abertos para adicionar mais wikis a esta lista!

Como isso pode ser implantado em minha wiki?
Se você estiver interessado em ver as melhorias da área de trabalho como padrão em seu wiki,
 * 1) pergunte à sua comunidade e chegue ao consenso,
 * 2) entre em contato com SGrabarczuk (WMF), email: sgrabarczuk-ctr@wikimedia.org se você precisar de suporte.

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!

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.

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.

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): [$optout ]. 

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