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. Além disto, como, limitar a largura do conteúdo oferece novas oportunidades para layouts do conteúdo, como uma coluna à direita dedicada a caixas de informação e imagens.

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. Como mencionado acima: como sabemos que a maioria das pessoas visitam o projeto para leitura de artigos, devemos otimizar a aparência para esse caso. Nós temos somente uma chance de causar uma boa primeira impressão, e nós devemos visar em oferecer a melhor experiência possível assim que as pessoas chegam, sem que tenham que realizar alterações.

Tabelas e outras predefinições não cabem dentro da largura limitada, isto não é ruim?
Recebemos vários relatos de tabelas com uma barra de rolagem horizontal extensa, ou predefinições que ultrapassam a largura limitada. Gostaríamos de notar que uma grande porcentagem de nossos usuários, que não tem uma tela grande e estão acessando a Wikipédia através de notebooks, já tinham problemas com tabelas e predefinições antes mesmo destas mudanças. Nós deveríamos trabalhar para certificar que todo o nosso conteúdo seja sensível à situação de nossos visitantes.

Por que não criar uma opção para a largura?
Uma das melhores partes da interface do MediaWiki é como ela é configurável. E apesar de ser possível a criação de uma opção para a largura do conteúdo, nos perguntamos se não seria mais benéfico encorajar uma experiência comum a todos os editores e leitores. Isto poderia ser útil a editores quando estiverem realizando decisões sobre o layout da página (nota: 1024px é mencionado como o tamanho mínimo a ser considerado no Manual de Estilo da Wikipédia anglófona, apesar de não ser exatamente a mesma coisa). Atualmente, um editor pode estar editando uma página com uma largura de 1500px, enquanto um leitor a lê com uma largura de 1200px. Ao implementar uma largura máxima, não removemos a divergência por inteiro (pois ainda existiriam variações abaixo da largura máxima, para pessoas com telas menores), porém estaríamos limitando essa variação.

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. Podemos recomendar este daqui.

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?
Esperamos que as alterações se tornem padrão em todas as wikis mais tarde neste ano. Qualquer comunidade é bem-vinda a participar através da implementação antecipada.

As melhorias devem ser implementadas em projetos irmãos e em wikis que não utilizam alfabeto latino?
Sim. Já temos uma lista de wikis com implementação antecipada com representação de vários tamanhos e alfabetos. Também nos certificamos de que pelo menos um projeto que não fosse uma Wikipédia fosse selecionado.

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


 * projetos irmãos:
 * 
 * 
 * 


 * Wikipédias com alfabeto não latino:
 * bn:
 * he:
 * fa:
 * ko:
 * sr:


 * Wikipédias com alfabeto latim:
 * 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 da Wikimedia?
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@wikimedia.org se você precisar de suporte.

Como posso habilitá-lo em minha própria wiki (de terceiros)?
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?
Não. Estas alterações serão aplicadas somente no Vector. O [ Vector] tem sido a interface padrão das wikis da Wikimedia desde 2010. Nenhum outro tema será afetado, incluindo [ Monobook], [ Timeless], [ Minevar] ou [ 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?
Adicione uma sessão na [ discussão da página principal do projeto] ou entre em contato com SGrabarczuk (WMF), email: sgrabarczuk@wikimedia.org.

Como vocês trabalham com as comunidades?

 * 1) Antes da implantação:
 * 2) Realizamos uma pesquisa com usuários, e analisamos gadgets e scripts de usuários. Veja  para mais detalhes.
 * 3) Estivemos entrando em contato com várias wikis perguntando se gostariam de participar com implementações antecipadas.
 * 4) Tivemos uma discussão de mesa-redonda durante a Wikimania em 2019 (veja os resultados).
 * 5) Nós realizamos duas rodadas de teste com protótipos. Os editores puderam ver nossas ideias em ação e compartilhar o que gostaram e o que acharam confuso.
 * 6) Logo após a implantação de cada recurso, coletamos dados de uso via  de cada wiki com implementação antecipada.
 * 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.