Reading/Web/Desktop Improvements/Repository/First Prototype Feedback Report/pt-br

Visão geral

Recursos

Repositório

Perguntas frequentes

Em dezembro, publicamos um protótipo dos primeiros recursos do projeto para feedback da comunidade. O protótipo apresentou uma versão recolhível da barra lateral, uma restrição de largura máxima no conteúdo e uma localização mais proeminente para o alternador de idioma.

Recebemos feedback detalhado e atencioso de mais de 200 usuários conectados, em cinco idiomas. O feedback é principalmente positivo, com a maioria dos usuários vendo as mudanças como uma melhoria em relação ao design atual.

No entanto, havia também algumas áreas de preocupação. Muitos dos problemas levantados foram devido a bugs no protótipo (particularmente com o menu de troca de idioma). Com relação a outros problemas expostos, iremos iterar sobre eles e/ou ficar de olho durante o desenvolvimento. Este relatório destaca os principais pontos levantados, tanto positivos quanto negativos, e nossos planos para o futuro em resposta a esse feedback.

Método de feedback

O protótipo foi mostrado para usuários logados usando um aviso central nas seguintes wikis:

• Wikipédia em basco
• Wikipédia em francês
• Wikcionário em francês
• Wikipédia em hebraico
• Wikipédia em persa
• Wikipédia em polonês
• Wikipédia em inglês
• Wikiversidade em português

As respostas foram coletadas por meio de um formulário pré-preenchido com perguntas especializadas sobre as alterações apresentadas. Também pedimos ideias e opiniões gerais sobre as mudanças no protótipo. Os respondentes também tiveram a opção de enviar suas ideias por e-mail. Os resultados apresentados contêm os comentários que recebemos na página e também por e-mail.

Recebemos muitos comentários relacionados a bugs no protótipo. Em particular, eles estavam relacionados à funcionalidade de troca de idioma e ao Seletor de Idioma Universal (ULS, em inglês). Pedimos desculpas por não fornecer informações suficientes sobre o protótipo em si e por não detectar esses problemas antes.

Resumo dos resultados

Um total de 230 usuários logados nos deram feedback sobre o protótipo. A maioria das respostas foi em inglês (180), seguida de francês (38) e hebraico (7).

Positiva

• A maioria dos usuários conectados preferiu o novo menu de idioma em vez da implementação atual na barra lateral.
• A maioria dos editores gostou da capacidade de reduzir a barra lateral. Especificamente, a visualização de leitura mais focada que resulta da barra lateral sendo recolhida e uma restrição de largura máxima no conteúdo.

Espaço para melhorias

• Houve uma série de preocupações levantadas com o alternador de idioma. A maioria deles estava relacionada à troca de idioma, exigindo dois cliques em vez de um, pois o novo alternador de idioma era muito proeminente, e questões sobre a internacionalização dos nomes dos idiomas na lista.
• Houve algumas preocupações em torno da quantidade de espaço em branco introduzido com uma barra lateral recolhível e restrição de largura máxima no conteúdo.

Solicitações de recursos

• Modo escuro/noturno
• Torne o índice sempre disponível na página

Resultados

Troca de idioma

Positiva

No geral, a maioria dos usuários preferiu o novo local do seletor de idioma. Eles relataram que era mais fácil de encontrar do que o local anterior. As pessoas que usaram o seletor de idioma frequentemente relataram que seria mais rápido para elas trocar de idioma. Vários usuários também relataram que o novo local é mais intuitivo, pois segue um padrão usado por outros sites multilíngues.

Espaço para ideias de melhoria e iteração

• Mudança de idioma com um clique: atualmente você pode mudar para outra wiki ou idioma com um único clique. Dependendo da altura da tela, alguma rolagem também pode ser necessária. No protótipo, são necessários dois cliques para alternar os idiomas (além da possibilidade de rolar também). Muitas pessoas notaram que a nova posição do alternador de idioma era mais fácil de encontrar. Eles também expressaram preocupação em ter um clique extra para trocar de idioma. Foi especialmente importante para os casos em que as pessoas esperam mudar com frequência. Existem duas maneiras de pensar sobre isso:
  • Estaremos coletando dados de uso e realizando testes A/B em nossas wikis de teste. Dessa forma, determinaremos se a troca de idioma aumenta, diminui ou permanece relativamente igual. Esperamos que, apesar do clique extra, o aumento da proeminência do alternador de idioma leve a uma maior capacidade de descoberta e, por fim, a mais alternância de idioma.
  • Elaboramos uma opção que inclui links para alternar os idiomas diretamente na página, adjacente ao seletor geral de idioma:

    

    Mostrando dois links diretos de idioma ao lado do alternador de idioma no cabeçalho do artigo

A mudança de idioma não é relevante para todas as pessoas. Teríamos que descobrir quando mostrar esses links diretos. Caso contrário, eles podem ser uma distração. Talvez eles possam aparecer quando alguém mudou de idioma uma vez, ou se acharmos que é provável que mude de idioma. Isso pode ser causado por uma incompatibilidade entre o idioma do sistema operacional e o idioma da wiki. Ainda não escolhemos nossa abordagem. Pretendemos revisitar essa ideia assim que a implementação inicial da troca de idioma estiver em vigor. Qualquer feedback sobre este ou os modelos acima seria muito apreciado.

• Problemas para encontrar um determinado idioma no Seletor de Idioma Universal (ULS): Muitos usuários gostaram da posição do novo seletor de idioma, mas expressaram preocupação com o próprio seletor.
  • Algumas dessas preocupações giram em torno da dificuldade de encontrar um determinado idioma no seletor. Em parte, isso se deveu aos seguintes bugs no próprio protótipo: a lista de idiomas sugeridos e usados ​​com frequência estava faltando, a pesquisa de idioma estava quebrada e o menu estava sendo renderizado muito pequeno.
  • Também havia preocupações com a ordem dos idiomas por região e com o espaçamento entre os itens no seletor, levando a muita rolagem.

Iremos priorizar as sugestões e problemas e esperamos trabalhar com a equipe Language para fazer algumas melhorias no Seletor de Idioma Universal. Atualizaremos mais sobre isso em breve.

• Localização & proeminência: As seguintes preocupações foram expressas sobre a localização do alternador de idioma no protótipo:
  • Algumas pessoas preferiram o local atual ao novo, por vários motivos. O tema principal parecia ser a dificuldade de usar o Seletor de Idioma Universal e a perda de acesso com um clique. Ambos são abordados abaixo.
  • O novo local é muito proeminente, pois muitas pessoas nunca trocam de idioma. Um objetivo principal deste projeto é aumentar a proeminência das funcionalidades usadas com frequência.  Atualmente, os links de mudança de idioma são os links mais usados ​​na barra lateral. Além disso, acreditamos que permitir que usuários multilíngues mudem de idioma é uma forma crucial de promover idiomas menos difundidos. Devido à localização atual, muitos não sabem que alternar entre os idiomas é possível.
  • A nova localização é boa, mas o botão é muito grande. Nós esboçamos várias outras opções para o tratamento de botão, mostradas abaixo:

    

    Quatro tratamentos para o menu de links interlinguísticos. Mais proeminente à esquerda, menos proeminente à direita.

• Looks like a translation: De acordo com alguns usuários, os leitores casuais podem pensar que, ao trocar de idioma, estão apenas visualizando uma tradução do artigo, em vez de trocar para uma wiki diferente. Esses usuários acreditam que isso pode ser causado pela colocação do seletor de idioma na visualização do artigo. É importante esclarecer a relação entre as wikis de diferentes idiomas. Estamos conduzindo testes com usuários para investigar isso e entender se essa confusão está ocorrendo e até que ponto isso seria um problema para os leitores.

Outras notas

• Houve alguns pedidos de exibição de nomes de idiomas em inglês, além do nome nativo (ou seja, exibindo bengali e বাংলা, em vez de apenas বাংলা).
• Tradução da palavra “language”. Vários usuários mencionaram que a palavra “language” deve ser traduzida para o idioma da wiki. Isso foi um erro do protótipo. A interface será traduzida para o idioma da wiki na versão final.
• Algumas pessoas mencionaram a adição de algum tipo de indicador na barra lateral que aponta as pessoas para a nova localização do alternador de idioma. Esperamos explorar isso.
• Algumas pessoas estão se perguntando como será a aparência do alternador de idioma em artigos sem outros idiomas disponíveis. O esboço virá em breve.

Barra lateral recolhível

Positiva

A maioria dos usuários que forneceram feedback gostou da barra lateral recolhida para uso pessoal e, especialmente, para fins de leitura. As pessoas mencionaram que ela remove as distrações e torna a leitura mais agradável. Um usuário com deficiência de leitura mencionou que remover a barra lateral torna mais fácil para eles se concentrarem no conteúdo.

Espaço para ideias de melhoria e iteração

• Não recolher por padrão para usuários desconectados: Alguns usuários não gostaram da ideia de a barra lateral ser recolhida por padrão para usuários desconectados. Eles expressaram preferência pelo estado atual. O raciocínio deles era que os itens da barra lateral poderiam aumentar o interesse na edição e no funcionamento interno dos projetos da Wikimedia. Reconhecemos que, com a barra lateral recolhida, há menos pontos de entrada para editar/contribuir com páginas relacionadas. Isso inclui as mudanças recentes. No entanto, esperamos que, ao reduzir o número de links na página, os que permanecem (Editar, Discussão, Histórico, etc.) sejam mais perceptíveis. Esperançosamente, veremos mais engajamento. Não planejamos repetir o design atual com base neste feedback. No entanto, estaremos testando cliques A/B em links para comparar como uma barra lateral recolhível se compara a uma não recolhível. Também monitoraremos se as alterações da barra lateral têm algum efeito na criação da conta (como um proxy para a conversão de leitores em editores).
• Recolher por padrão para todos: Por outro lado, vários usuários mencionaram que prefeririam que a barra lateral recolhida fosse o padrão para leitores e editores. Muitos sugeriram remover a barra lateral por completo. Atualmente, não temos planos de seguir nenhuma dessas ideias. Aceitamos comunidades individuais para discutir mais os links da barra lateral e sua utilidade.
• Mude e/ou reposicione o ícone de abrir e fechar o menu: Muitas pessoas comentaram que o ícone escolhido não era uma forma intuitiva de abrir/fechar o menu. Apenas um dos mais de 220 usuários que escreveram não conseguiu abrir a barra lateral quando solicitado (link para o feedback). As duas sugestões mais comuns foram: 1) quando a barra lateral está aberta, o ícone deve mudar para algo como um “X” ou “<<”, e 2) tente mover o ícone para mais perto do próprio menu, em vez de colocá-lo no cabeçalho do site. Os esboços dessas duas ideias estão abaixo.

Ícone de fechamento alternativo para barra lateral recolhível

Local alternativo para o botão recolhível da barra lateral

• Não esconda o aleatório: Alguns usuários mencionaram que o link da página aleatória é importante para os leitores e uma parte central da experiência wiki. Concordamos que esta é uma ideia interessante. Estamos explorando a movimentação do link para fora da barra lateral e para a barra de pesquisa.

  

  Showing a Random article button next to search

• Recolha as seções na barra lateral também ou reduza o número de links na barra lateral: Atualmente, a barra lateral contém muitos links que não são usados ​​com frequência. Algumas pessoas temem que, ao reduzir a barra lateral, estejamos ignorando o maior desafio: remover os links não usados ​​da barra lateral. Alguns sugeriram tornar as seções da barra lateral recolhíveis. Others have suggested cleaning up the links. Os links na barra lateral são determinados em cada wiki individualmente. Concordamos que as comunidades devem remover links desnecessários da barra lateral.

Perguntas abertas, novas ideias e outras notas

• Para onde foram o botão de edição e as categorias? Alguns usuários mencionaram que não conseguiram acessar o botão de edição e a lista de categorias dentro do protótipo. Esse era um bug do protótipo. Pedimos desculpas por não mencioná-lo nas instruções.

Apresentando uma largura máxima

Contexto

Um dos bugs do protótipo era que o conteúdo tinha uma restrição de largura máxima apenas quando a barra lateral era fechada. Muitas pessoas comentaram sobre como isso era estranho e quanto o conteúdo saltou pela página quando você fechou a barra lateral. Isso foi um erro, não como pretendíamos que fosse. Por favor, veja este protótipo atualizado para entender como a restrição de largura máxima funcionará: https://di-collapsible-sidebar-5.firebaseapp.com/Tea

Positiva

A maioria das pessoas respondeu positivamente ao layout de largura máxima. Foi observado que resultou em uma experiência de leitura mais confortável. Várias pessoas mencionaram que ter margens em torno do conteúdo facilita o foco. Para eles, comprimentos de linha mais curtos eram melhores para a leitura. Isso é consistente com a pesquisa profissional que foi conduzida.

Feedback geral e outras ideias de recursos

• Crie um modo noturno: Uma parte significativa dos usuários solicitou a inclusão do modo escuro/noturno no escopo do projeto. Não estávamos considerando isso no escopo inicial. Percebemos que essa é uma solicitação que vimos várias vezes no passado também. No momento, estamos discutindo se podemos adicionar o modo escuro ao escopo do projeto e como isso pode afetar nosso cronograma. Atualizaremos assim que soubermos mais.
• O índice deve permanecer sempre em vista: Muitas pessoas comentaram que ter acesso ao índice, independentemente de quão pequena seria a página (“extremamente útil”). Estamos planejando explorar essa funcionalidade como parte deste projeto.
• Build a sticky header: Muitos usuários expressaram interesse em ter acesso a ações comumente usadas no topo da página. Os usuários solicitaram acesso a páginas e ações comumente usadas (discussão, histórico, edição), bem como outras funcionalidades, como a barra de pesquisa. Uma solicitação semelhante foi a necessidade de retornar ao topo da página e/ou alternar as seções de maneira rápida. Planejamos explorar esta opção como parte deste projeto. Gostaríamos de apresentar um cabeçalho fixo com ações comumente usadas, bem como um índice persistente. Abaixo estão alguns exemplos de nossas idéias até agora. Agradecemos qualquer feedback sobre isso que você possa ter.

Esboço de cabeçalho fixo para usuário desconectado

Esboço do cabeçalho fixo para o usuário conectado

• Limpe a barra superior: Houve algumas ideias e pensamentos sobre como limpar os links no topo da página, recolhendo-os ou movendo-os em menus suspensos. Isso também é algo que estamos considerando para o projeto.

  

  Protótipo de ferramentas de usuário consolidado

• O logotipo é muito pequeno.

Nossa justificativa para a largura limitada

Legibilidade

Pesquisa

O objetivo principal é melhorar a legibilidade das páginas da Wikimedia. Decidimos trabalhar na largura da área de conteúdo. Existem recomendações baseadas em pesquisas sobre este assunto.

• O artigo da Wikipédia em inglês sobre Comprimento da linha fornece uma boa visão geral.
• O mesmo acontece com o ensaio da Professora Laura Franz.
• Optimal Line Length in Reading - A Literature Review (2005), from the peer reviewed journal Visible Language – "studies concluded that moderate line length in between 50 to 70 cpl [characters per line] are the easiest to read and users do not prefer extreme line lengths (very short or very long) while reading from screen. There was no significant effect of line length found on comprehension, though fast readers benefit from narrow columns with short lines due to specific reading patterns (with one contradictory finding)".
• Effects of Surrounding Information and Line Length on Text Comprehension from the Web (2002), from Canadian Journal of Learning and Technology – "Comprehension was affected by whitespace; participants had better comprehension for information surrounded by whitespace than for information surrounded by meaningless information", which is more likely to happen if the text stretches to the edge of the browser.
• The influence of reading speed and line length on the effectiveness of reading from screen (2001), from International Journal of Human-Computer Studies – "A line length of 55 cpl appears to support e!ective reading in terms of both rate and comprehension. However, as the line lengths used in this study were spread across a wide range, there may be a more optimal setting than this. By varying the range and extremes of line lengths in future research, it may be possible to more precisely identify an optimal format and to explore the relative contributions of mechanical and cognitive factors."
• Shorter Lines Facilitate Reading in Those Who Struggle (2013), from PLOS One – "short lines reduce the number of regressions, and generally improve reading speed and comprehension, simply by reducing the probability that crowded text in locations previously fixated can be perceived."
• The Effects of Line Length on Children and Adults' Online Reading Performance (2002), from Software Usability Research Laboratory (SURL) at Wichita State University – "This study examined the effects of line length on reading performance. Reading rates were found to be fastest at 95 cpl. Readers reported either liking or disliking the extreme line lengths (35 cpl, 95 cpl)".
• The Effects of Line Length on Children and Adults' Perceived and Actual Online Reading Performance (2003), from Proceedings of the Human Factors and Ergonomics Society Annual Meeting – "No differences were found for either reading time or efficiency for either adults or children. However, adults preferred shorter line lengths to full-screen line lengths." and "The narrowest line length condition was perceived as promoting the highest amount of reader concentration, while the medium line-length condition was considered to be the most optimally presented length for reading."
• Reading Online Text: A Comparison of Four White Space Layouts (2004), unclear if this was peer reviewed – "Results from this study showed that the manipulation of the Margin white space affected both reading speed and comprehension; participants read the Margin text slower, but comprehended more than the No Margin text. In general, the results favored the use of Margins."

A recomendação popular é que deve haver entre 40 e 75 caracteres por linha. Os resultados de vários estudos concluem que "comprimentos de linha curtos são mais fáceis de ler". Com relação ao aprendizado e retenção de informações: "Os sujeitos que leram os parágrafos estreitos tiveram melhor retenção do que aqueles que leram os parágrafos amplos".

Web Content Accessibility Guidelines (WCAG)

• The Web Accessibility Initiative (WCAG) guideline 1.4.8 states that, in order to be accessible to all users, lines of text should be 80 or fewer characters (or 40 or fewer characters if the text is Chinese, Japanese, or Korean)."

Sites populares com largura limitada

É possível encontrar muitos sites populares que estão em conformidade com essas diretrizes.

• Os artigos da revista científica online Nature têm largura máxima de aproximadamente 76 caracteres por linha.
• Os artigos do New York Times têm aproximadamente 64 caracteres por linha.
• Os artigos do Times of India têm cerca de 100 caracteres (hindi).
• Os periódicos da Oxford Academic possuem ~75.
• Os artigos da Organização Mundial da Saúde são ~96 no alfabeto latino, ~46 no chinês e ~85 em alfabeto cirílico.
• Ao usar o modo de leitura no Safari ou Firefox, o texto é renderizado em ~73 e ~77 caracteres por linha, respectivamente (alfabeto latino).

Comparação com wikis da Wikimedia

Atualmente, uma página wiki da Wikimedia em uma janela do navegador com 1280px tem aproximadamente 170 caracteres por linha. Isso está na pequena extremidade do espectro do tamanho da tela.

Na wiki da Wikimedia, a contagem de caracteres por linha aumenta conforme a largura da tela aumenta. Portanto, no segundo tamanho de tela mais popular, 1920px (21% dos usuários), a contagem de caracteres por linha é de aproximadamente 262, mais de três vezes o valor recomendado.

Por que não escolher a solução "mais simples"

Com base exclusivamente no comprimento de linha recomendado, parece que algo em torno de 700px é razoável. Por que não limitar a largura de forma que alcancemos o comprimento de linha recomendado, como outros sites de conteúdo online parecem fazer?

Porque nossas páginas são diferentes e, portanto, as pessoas as lêem de maneira diferente.

• As páginas wiki da Wikimedia são muito longas, contêm uma grande quantidade de informações e não são igualmente uniformes. As a result, people have a need to skim and search within pages. Isso é diferente da leitura linear de um artigo ou livro online típico. Isso é apoiado por nossa pesquisa sobre o tempo de leitura na Wikipédia.
• Quanto mais estreito formos o conteúdo, mais longa será a página. Talvez a digitalização também se torne mais difícil, porque envolve mais rolagem, etc. Para obter mais informações sobre os diferentes tipos de leitura online, consulte este estudo de 2006 conduzido pelo Nielsen Norman Group.
• Além disso, não é fácil obter um número específico de caracteres de texto por linha. Isso ocorre porque as páginas wiki da Wikimedia contêm muitos elementos que são inseridos junto com o texto.

Artigo da Lua com 550px de largura, parágrafo ininterrupto com uma contagem de caracteres por linha de ~83

Artigo da Lua com 750px de largura, parágrafo próximo à infobox com uma contagem de caracteres por linha de ~72

Nosso design deve levar em consideração essas distinções.

• Devemos limitar a largura em alguma quantidade para acomodar a leitura focada/engajada. Isso significa comprimentos de linha mais curtos e menos densidade.
• Ao mesmo tempo, devemos permitir que os leitores percorram e pesquisem, obtendo um mapa visual da página sem ter que rolar muito Este é um argumento para comprimentos de linha mais longos e mais densidade.

Como fazemos isso?

Nossa solução

Existem duas experiências comuns que devemos considerar.

1. A parte superior de um artigo, um parágrafo de texto situado próximo a uma infobox
2. No meio de um artigo, um parágrafo sem elementos que o interrompam

Podemos considerar essas duas experiências em várias larguras, contando o comprimento de caracteres por linha para cada uma:

Largura do conteúdo	Parágrafo próximo a uma infobox	Parágrafo ininterrupto
600px	~30 caracteres por linha	~94 caracteres por linha
700px	~59	~109
800px	~76	~125
900px	~89	~142
1000px	~105	~154

Com 1000px de largura, um parágrafo de texto ininterrupto tem ~154 caracteres, quase o dobro do limite recomendado. Às vezes, há elementos flutuantes que são mais largos do que infoboxes, resultando em colunas de texto mais estreitas. Além disso, não houve uma largura máxima. Embora alguns editores possam editar em telas mais estreitas (ou verificar como as páginas ficam em telas mais estreitas), é provável que haja conteúdo em páginas que não ficarão bem em uma largura mais estreita (ainda), porque pode não ter sido uma consideração (por exemplo, grandes tabelas).

Another approach is thinking about a grid-based layout. Esta é uma abordagem que visa tanto a harmonia visual na página quanto a tomada de decisões sobre espaçamentos, larguras, etc. com mais facilidade. The Vector skin does not currently use a grid. Something we could do is think about the width of the infobox as a grid column (since they are such common elements), and then use a multiple of that to determine the content width.

India article with content at 3x infobox width

India article with content at 4x infobox width

Estabelecendo uma experiência de leitura comum

A introdução de uma largura máxima funcionaria no sentido de estabelecer uma experiência comum. Esperançosamente, seria útil para os editores na tomada de decisões sobre layouts de página.

Observação: 1024px é mencionado na Wikipédia em inglês como um tamanho mínimo a ser considerado. Isso não é exatamente a mesma coisa, no entanto.

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 essa diferença completamente. Ainda haveria variação abaixo da largura fixa, para pessoas com telas mais estreitas. No entanto, estaríamos limitando muito a faixa de variação.

Conclusão

Depois de pensar tudo isso, chegamos a duas conclusões:

1. Parece que uma largura máxima na faixa de 800-1000px é um ponto de partida sensato. Vamos centralizar o conteúdo na página para garantir que fique bem com a barra lateral aberta e fechada.
2. Parece valer a pena conduzir um estudo com foco na legibilidade de artigos da Wikipédia, especificamente. Esperamos encontrar os recursos para fazer isso.

Mostrando conteúdo com largura máxima de 960px (barra lateral recolhida)

Mostrando conteúdo com largura máxima de 960px (barra lateral aberta)

Notas adicionais

A note on breaking templates / content / special pages / etc.

Part of what makes Wikipedia, and other Wikimedia wikis, a powerful tool for sharing knowledge is that there are very few constraints on how information is presented. The result of this is a wide variety of different elements on the pages: tables, image galleries, diagrams, panoramic images, graphs, forms, maps, category boxes, and more. We have dealt with the challenges of designing the mobile site, and got the content to look good. This is why we do recognize that there are going to be some situations where page content doesn’t look great given the max-with. Our plan currently is:

• Work with our test wiki communities to identify issues and discuss solutions using template styles or other existing tools.
• Not to implement the max-width on Special pages. Special pages are not intended for “reading”. They often function more as lists or dashboards. Until we have time to work through the details about more responsive layouts for these pages, we will be leaving them alone. Here is an initial prototype of how this would work. You can switch between "View history" and "Read" to get a sense for it: https://di-collapsible-sidebar-5.firebaseapp.com/Tea

Previous conversations

This topic has been discussed in the past.

• 2014 – discussion from the Typography Refresh project

Please feel free to add additional links to past conversations here.