Como encontramos erros não óbvios nas interfaces de atribuição online para crianças

Cada nova lição na plataforma é o resultado do trabalho conjunto de metodologistas, designers, ilustradores, programadores e testadores. As novas tarefas geralmente são testadas nas escolas, onde os metodologistas podem observar o quanto entendem os alunos, coletar feedback e feedback. Mas alguns problemas em pequenas amostras podem passar despercebidos. E aqui o estudo das ações detalhadas dos estudantes vem em socorro - onde clicaram, em que números digitaram, em que resposta escolheram. As ações das crianças dentro das tarefas fornecem informações valiosas que nos permitem melhorar nossa plataforma para tornar o aprendizado mais conveniente e compreensível. As melhorias podem estar relacionadas à interface da tarefa e à redação de explicações e perguntas.




O que sabemos e o que não


Para todas as tarefas, temos disponíveis os eventos “o aluno começou a resolver a tarefa”, “a tarefa está concluída, a decisão está correta”, “a tarefa está concluída, houve erros”. Cada sessão da solução deixa um registro desses eventos, com base nos quais podemos descobrir quantas crianças cometem erros na tarefa e quanto tempo gastam na solução.


Este é um exemplo de estatística para uma tarefa específica. Os gráficos à esquerda mostram o número de decisões corretas e incorretas e a porcentagem de erros. O lado direito mostra a distribuição do tempo necessário para os alunos resolverem tarefas.

Alguns termos
. . , , . — ( . chunk — , ), — .

Às vezes, surgem perguntas para algumas tarefas - por exemplo, por que as crianças as deixam mais frequentemente do que outras sem concluí-las? Por que eles gastam tanto tempo em alguma tarefa aparentemente simples? Por que em uma série de tarefas do mesmo tipo a proporção de erros difere várias vezes?

Para responder a essas perguntas, precisamos examinar a solução - para ver não apenas o resultado “verdadeiro / falso”, mas também as ações que o levaram. Que erro específico o aluno comete? Como ele forma sua resposta? É aqui que a análise da ação é necessária.

Primeiras tentativas


Em suas primeiras tentativas de conduzir essa análise, os programadores de JS modificaram o código dos primeiros cartões do curso de matemática de primeira classe. Em cada cartão, eventos adicionais foram adicionados, próprios para cada tipo de tarefa.

Por exemplo, temos tarefas para resolver exemplos com o esquema "cubos". Em seguida, a criança deve clicar no cubo, que será rebentado a partir disso. Então você precisa calcular quantos dados restam e anote a resposta.


Assim, a tarefa de subtração parece primeiro.


Depois que o aluno "explode" o cubo, ele precisa inserir a resposta na janela.

Em tarefas desse tipo, eventos como "ativaram a voz da tarefa", "clicaram no número do cubo i", "inseriram o número na entrada" foram adicionados .

Aconteceu que mais da metade das decisões erradas são respostas absolutamente corretas: o número 6. O “erro” consistiu em clicar no cubo errado: nenhum cubo exceto o último poderia ser estourado, e clicar neles foi considerado um erro pelo cartão. Corrigimos essa lógica e agora clicar em outros cubos não é considerado um erro. Como resultado, a porcentagem de tarefas sem erros aumentou de 65% para 75%, e os alunos da primeira série não precisam mais adivinhar o que fizeram de errado.


O gráfico mostra quanto o número de passes sem êxito do cartão, que inclui a tarefa revisada, diminuiu.

Essa maneira de trabalhar tornou possível entender bem os detalhes da solução de tarefas para crianças, mas acabou consumindo muito tempo:

  • O programador JS deve modificar o cartão adicionando o envio dos eventos necessários.
  • O testador deve verificar se as alterações não estragaram a funcionalidade do cartão.
  • O analista deve obter os registros de decisão, entender os eventos e tirar conclusões sobre o que está acontecendo.

Essa solução não pôde ser dimensionada e distribuída para todos os cartões. Portanto, desenvolvemos uma variante com eventos comuns a todos os cartões.

Segunda tentativa


Todos os cartões contêm eventos comuns, como cliques, dragas ou valores de entrada nas entradas. Um componente especial foi criado que rastreia esses eventos elementares e os envia ao servidor.

Exemplos desses eventos e os dados adicionais que eles contêm:

  • click - (x, y) - coordenadas do clique, classe css e texto do elemento clicado
  • entrada para entrada - valor inserido, verdadeiro ou não
  • início do arrasto - coordenadas, texto do item arrastado
  • fim da draga - da mesma forma

O componente de rastreamento de ações está incluído no cartão em uma linha e não requer esforços adicionais dos programadores e testadores de JS. O componente foi adicionado aos cartões de matemática das séries 5 a 9.

Vou dar alguns exemplos do que foi descoberto usando os dados coletados dessa maneira.

Tambor


Como exemplo de refinamento da interface da tarefa, você pode trazer o elemento "drum", que é usado em alguns cartões. As crianças clicam nas setas e alteram as opções de resposta até encontrar a correta. A alteração das opções é animada - o tambor rola para cima ou para baixo.


Uma tarefa com um elemento de bateria

O mapa de cliques dessa tarefa deve conter muitos cliques na região das setas triangulares. No entanto, nem todos esses cliques foram iguais - havia dois tipos diferentes de classes de css. A experiência no cartão mostrou que valores diferentes correspondem ao estado clicável e não clicável das setas. Um estado não clicável aparece durante a animação de rolagem de rolagem.

Encontramos cliques nas setas bloqueadas em 85% a 90% dos alunos. Ou seja, as crianças geralmente procuravam clicar na seta novamente antes que a animação de rolagem terminasse. O cartão ignorou esses cliques. A animação da época durou 800 ms, mas algumas crianças conseguiram dar um novo clique depois de 100-200 ms.


Senti como o botão inativo incomodava as crianças.Para

tornar a interface mais responsiva, aceleramos significativamente a rolagem. Essa aceleração foi estendida a todos os cartões com "bobinas".

Descargas


Além de ações atômicas muito pequenas, como panelinhas, podemos estudar quais respostas as crianças dão e quais erros cometem.

Por exemplo, em uma das tarefas, os alunos da sexta série repetem os nomes dos dígitos de um número e aprendem a reconhecer décimos e centésimos. Aqui está um exemplo de uma tarefa em que as crianças precisam marcar um dígito em uma determinada categoria.


A tarefa de determinar os dígitos hoje se parece com a seguinte:

aqui no mapa de cliques, vimos cliques em retângulos com números. Pelas coordenadas do clique, você pode entender em qual número o aluno clicou. Também deve ser levado em consideração que o primeiro clique em um número o seleciona e o segundo clique remove a opção. Depois, no registro de eventos, você pode deduzir quais categorias o aluno escolheu antes de clicar no botão "Concluir".

Na primeira reunião com essa tarefa, cerca de um terço das crianças cometeu um erro. Alguns deles, como esperado, confundiram os décimos e as dezenas, mas outros erros foram mais surpreendentes. Por exemplo, 7% das crianças notaram dezenas e dezenas de milhares. Outros 5% - completamente adicionados a esta lista também décimos. 1,5% das crianças anotaram todos os números em geral.

A interface da tarefa foi modificada para permitir que apenas um dígito seja selecionado - ao clicar em um novo dígito, a seleção do anterior é removida. Na nova versão da tarefa, a porcentagem de erros diminuiu para 20% e os alunos podem entender melhor que o nome da categoria se correlaciona claramente com a posição do dígito no número do registro.

Fração


Outro exemplo é uma tarefa que apresenta aos filhos a propriedade principal das frações comuns. No início da tarefa, é mostrado aos alunos uma ilustração em que a fração é representada por uma figura parcialmente preenchida.


Assim, o início da tarefa parecia mais cedo: as

crianças devem indicar qual parte da figura está pintada. 88% das crianças lidam com esta etapa sem erros, escrevendo no numerador "3". 9% dos alunos escrevem "1": provavelmente gostam mais de cinza do que de verde. Outros 3% das crianças escrevem "4" - bem, de fato, porque todas essas partes não são brancas!

Na versão revisada do cartão, a pergunta foi alterada e sua nova redação é "Qual parte é verde?" Como resultado, o número de erros diminuiu três vezes, agora 96% das crianças agora vão para o conteúdo principal do cartão, sem tropeçar aqui do nada.

Resultados da segunda tentativa


Recebemos informações interessantes e fizemos melhorias úteis. Mas essa maneira de investigar eventos requer um trabalho minucioso do analista. Para converter uma sequência de cliques em um curso compreensível de uma solução, primeiro é necessário estudar o layout do cartão e entender qual elemento possui um clique específico. Em segundo lugar, entender a lógica do trabalho - onde o aluno seleciona algum elemento, onde remove a escolha, onde reorganiza os elementos em alguns lugares. Na verdade, você precisa duplicar literalmente a funcionalidade do cartão.

Obviamente, no curso de tais investigações, as funções são gradualmente desenvolvidas para o processamento da mecânica padrão (por exemplo, “escolhendo uma opção de uma linha localizada horizontalmente”). Mas, ainda assim, as tarefas são tão diversas que é impossível automatizar completamente esse processo. Além disso, na maioria das vezes o estudo de um cartão específico termina com a conclusão "tudo está indo conforme o planejado" - os erros nas crianças são praticamente os mesmos que o esperado, as dificuldades com a interface também não são visíveis. Isso, por um lado, indica o bom trabalho da equipe de produto, mas, por outro lado, pode desmotivar, pois parece que seus próprios esforços foram desperdiçados.

Usando eventos elementares, estudamos as respostas que as crianças dão e como elas chegam a elas. O conhecimento das respostas dos alunos é relevante em todas as tarefas, mas, devido à enorme variedade de mecânicas, é muito difícil restaurar as respostas de uma sequência de pequenos eventos. Isso levou à idéia de criar um evento separado "o aluno deu uma resposta".

Que logs estamos coletando agora e o que eles fornecem


Sempre que o cartão verifica a resposta do aluno, enviamos um evento com informações sobre a resposta. O evento contém as seguintes informações:

  • resposta correta ou incorreta
  • a resposta em si, ou seja, o estado atual dos elementos ativos do cartão (o que é inserido na entrada, qual dos botões de opção está selecionado, quais pontos são marcados no plano e assim por diante, dependendo da tarefa atual)
  • opcional - em que estágio da tarefa o aluno está agora

É importante que, no código do cartão, haja obviamente uma verificação da resposta do aluno, e todo o status no momento seja conhecido. Tudo o que resta é adicionar uma linha enviando essa resposta ao servidor. Ou seja, nesta opção, não há necessidade de duplicar a lógica do cartão, o que criou tantas dificuldades no estágio anterior.

Informações sobre o estágio da tarefa são necessárias em cartões com passagem não linear. Por exemplo, um aluno pode ter uma escolha - anote imediatamente a resposta para o problema ou resolva-o em etapas.

As estatísticas acumuladas de tais eventos nos dão:

  1. Mapa do movimento dos alunos nas etapas do trabalho. Entendemos que estágios são fáceis para as crianças e em que elas têm dificuldade.
  2. Estatísticas de respostas de cada etapa. Ajuda a ver que tipo de erros os alunos cometem.

Como os eventos têm um único formato, seu processamento automático é possível. Agora, depois de lançar um novo cartão, já podemos ver no dia seguinte em um aplicativo especial como as crianças lidam com as tarefas.



Erros de ortografia típicos são evidentes

Incluímos eventos com respostas em todos os novos cartões e também os adicionamos aos antigos quando eles são finalizados. Agora, todos os funcionários envolvidos no processo de atribuição podem ver o que é dado facilmente aos alunos e o que causa dificuldades.

All Articles