Wikipédia Abstrata/Atualizações/10-06-2022
| ◀ |  Atualizações da Wikipédia abstrata 
|
▶ |
|
O pesquisador de design Jeff Howard fez outra rodada de pesquisa para verificar os problemas no período próximo ao lançamento. O relatório completo da pesquisa foi publicado no Meta. Aishwarya, o designer da equipe da Wikipédia abstrata, leu e analisou os resultados da pesquisa e os resumiu em um slide deck. Esta semana, Aishwarya apresentou o deck para a equipe, e estamos oferecendo aqui um pequeno resumo da apresentação.
O objetivo de projetar a página de função é duplo: ser compreensível e utilizável por técnicos de todas as origens e acolhedor para pessoas com baixos níveis de experiência em programação. Os contribuidores técnicos devem entender o fluxo de trabalho de criação de funções e o modelo mental do Wikifunctions. Sete participantes técnicos foram entrevistados usando designs de Aishwarya na Figma (clique em qualquer lugar na tela para avançar pelos slides e lembre-se de expandir sua janela).
Os entrevistados levantaram muitas ótimas questões, validaram muito do nosso trabalho de design e identificaram várias áreas de melhoria. No geral, o relatório validou que atendemos aos objetivos de design declarados da interface do usuário, sendo compreensível e utilizável para o pessoal técnico, mas o relatório também destacou que os contribuidores realmente não entenderam o fluxo de trabalho de criação de funções e o modelo mental geral do Wikifunctions. Em suma, eles podiam fazer tudo, mas muitas vezes ficavam confusos sobre o que estavam fazendo e por que isso era apresentado dessa maneira.
Não vou entrar em muitas coisas que funcionaram bem. Você pode ler sobre eles no relatório completo e também nos slides. Eu quero elogiar o diagrama de resumo do trabalho, que é consistente com muitas outras reações que também tivemos no bate-papo e em outras interações com membros da comunidade Wikimedia. Também quero aproveitar a oportunidade para parabenizar Aishwarya por seu trabalho de design e vê-lo validado de forma tão positiva. Estamos todos ansiosos para lançar o design implementado para você brincar e aprender mais sobre como podemos melhorá-lo.
Dois pontos foram apontados pelos entrevistados em particular como causa de surpresa ou confusão: a divisão entre as definições de funções e suas implementações, e a natureza multilíngue do Wikifunctions.
No Wikifunctions, permitimos que cada função tenha várias implementações. Conseguimos isso fazendo com que as implementações sejam suas próprias páginas no Wikifunctions. Tal separação não é um conceito novo: linguagens de programação como C++ ou Ada tiveram arquivos de cabeçalho e implementação por décadas, e linguagens orientadas a objetos têm interfaces que podem ser implementadas por diferentes classes. Mas os entrevistados repetidamente quiseram ir direto para a implementação. Eles estavam confusos que poderiam publicar a definição de uma função antes mesmo de fornecer uma implementação. Essa também foi uma solicitação que vimos em testes de usuários anteriores.
As a side remark, the little word “publish” really did a lot of heavy lifting here. A long time ago, Wikipedia used to use the word “save” for the button that let the contributor store an edit, and this was changed to “publish” in 2017, based on user research that found wiki users surprised and alarmed that merely 'saving' an edit would put it online, in public, for everyone to see, forever. This user study reiterated the point that the word “publish” makes it clear that the contribution will indeed go live to the whole world. But at the same time, several interviewees felt that just a function definition, without any implementations yet, didn’t seem to be useful to be published. The word “publish” really brought out that contrast, and helped us identify this discrepancy in the user’s mental model.
The second point that raised quite strong reactions was the multi-lingual nature of Wikifunctions. That is one of the points that is often questioned in the design of Wikifunctions, often unprompted: why does it have to be multi-lingual? Why labels in different languages? Doesn’t everyone who wants to code just learn English? To quote one of the interviewees, “usually people who speak other languages are just expected to learn English to code”.
Because the world of coding is indeed so English-centered, it is very difficult to find people with coding experience who don’t speak basic English, and indeed all interviewed contributors spoke English.
There have been a number of research studies showing that the English-centricity of programming is a major barrier for many people. People who can use their own language to code achieve results faster. For parents that don’t speak English, it is more difficult to help their children to learn programming. Based on these and other research results, we choose to intentionally deviate from the recommendations of our own user research, as we believe that this aligns better with the Wikimedia 2030 movement strategy recommendations, particularly towards knowledge equity.
There were many smaller, but very good points raised. The contributors asked for a space to describe the functions in more detail (that’s planned for Phase ι, which is up next in our development plan). The term “aliases” confused users. The list of types was too simple. The example table was identified as a place that probably won’t scale for complex entries. The difference between the words “available” and “proposed” and “verified” in the tables showing implementations and testers was confusing. And there were quite a few more.
We also identified a number of larger areas that could be improved: making the use of language more consistent throughout, displaying more meta-data immediately, and improving the text to make the distinction between definitions and implementations clearer. We are going to work on these design challenges.
We are relieved and pleased to see that the designs allowed all the contributors to fulfill their tasks. We are more than excited to implement these designs, and get them to you. We would love to hear from you, if you have ideas or suggestions around the issues discussed here, or in the full report.
Thanks to all the contributors who were interviewed, thanks to Jeff for performing the research, and thanks to Aishwarya for summarizing the results.
Updates as of June 3: Fix-it week
- May 30 – June 3 was a ‘Fix-it’ week for the Abstract Wikipedia team. During this week, the team paused the development of new features and focused on tasks related to technical debt.
- Design update: This week, the team kicked off the design work for the ‘lists’ component.