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: Estamos abertos para adicionar mais wikis a esta lista!


 * Além disso:
 * Office Wiki
 * 
 * MediaWiki wiki
 * Wikimedia Foundation Governance wiki
 * Collab wiki
 * Strategy wiki

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. 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) Nós realizamos A/B tests com usuários registrados. Metade deles podem experienciar a nova interface, e metade não vê a diferença. Em seguida, comparamos as estatísticas. No caso de resultados negativos, aprimoramos as alterações ou removemos elas.
 * 8) Para usuários não registrados, comparamos o antes e depois. Infelizmente, não somos capazes de realizar testes A/B com usuários não registrados.
 * 9) Nós observamos a página de discussão do projeto. Também participamos de conversas separadas em wikis regularmente.
 * 10) Nossos  facilitam trabalhar mais de aberto com algumas comunidades, e reagir mais rapidamente e eficientemente.

Como posso desativá-lo?
This is only available to authorized users. É 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): 

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.

Você pode adicionar uma tarefa no Phabricator e adicionar etiqueta do projeto de Melhorias da Área de Trabalho ou entrar em contato com SGrabarczuk (WMF) através do 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:


 * seria complexo demais fazer com que as extensões, gadgets e scripts de usuários fossem compatíveis com mais um tema, e caro demais manter a compatibilidade,
 * seria desafiador demais construir e manter mais um tema (já que uma substituição por completo não é uma opção),
 * seria mais difícil para as comunidades colaborarem eficientemente na construção de um novo tema.

Tecnicamente, as melhorias da área de trabalho são semelhantes a recursos ou projetos anteriores, como ou. A única diferença é que desta vez, veremos mais deles. Documentação do Vector deve permanecer relevante.

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

Por que não usar apenas recursos beta?
Recursos beta estão disponíveis somente para usuários registrados, e os aprimoramentos estão sendo criados para atender também nossos leitores e usuários não registrados. Portanto, utilizar somente recursos beta resultaria em feedback de um grupo de usuários bem específico e não representativo de nossa base de usuários. Além disto, queremos receber retorno de leitores e usuários anônimos sobre as versão mais recentes.

Quais são as métricas de sucesso do recurso?
Aumentar utilidade para nossa audiência atual, através de:


 * Interações
 * Aumentar buscas por sessão em 5% durante o curso do projeto
 * Aumentar a alteração de idiomas por projeto em 5% durante o curso do projeto


 * Afinidade
 * Aumentar os sentimentos positivos e de acolhimento no site (através de pesquisas e testes)
 * Aumentar os sentimentos de segurança e credibilidade (medidos através de pesquisas e testes com usuários)

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