Semanas #14-15

Durante estas duas últimas semanas foi possível concluir a montagem dos circuitos eléctricos dos terminais individuais, para além de se ter construído uma caixa protótipo para um terminal, por impressão 3D.

Para além disso, o sistema CLASSQUIZ foi submetido à participação no forum Teaching & Learning, a realizar-se no dia 18 de Junho da Universidade de Aveiro.

No dia 29 de Maio foi possível testar o sistema desenvolvido num ambiente realista, durante uma apresentação realizada no LAR (apresentação em anexo). Nesta apresentação foi possível detectar alguns erros do sistema, relacionados com o cálculo do número de respostas certas e erradas de cada aluno aquando da visualização dos resultados de uma dada lição, bem como erros na visualização dos resultados de questões anónimas, onde apenas é apresentado um resultado. Para além disso, foi pedido aos participantes que respondessem a um pequeno questionário (disponível em anexo) no final da apresentação, de forma a recolher algum feedback dos inquiridos acerca da sua utilização do sistema. Um dado interessante que resulta da avaliação dos questionários realizados é o facto de os alunos que participaram na apresentação se sentirem mais receptivos para que o sistema seja utilizado na realização de inquéritos autenticados, em vez de inquéritos anónimos, o que contraria o resultado esperado.

Por fim, foi possível ainda dar continuidade à escrita da dissertação, em particular ao capítulo que descreve a implementação da aplicação web desenvolvida.

Semanas #12-13

Finalmente foi possível finalizar a montagem dos circuitos dos terminais individuais (à exepção dos LED’s, cuja montagem depende da solução final para a caixa envolvente). Para além disso, foi criado com sucesso um protótipo para o sistema de acomodação do cartão de estudante. Assim, fica a faltar apenas a criação de uma caixa envolvente final.

Ao nível da aplicação, foram realizadas algumas alterações à lógica da criação dos questionários. Antes da criação de um questionário, é agora necessária a criação de uma lição (lesson), na qual é definida a Unidade Curricular, bem como qual a resposta válida (se a última ou a primeira). Desta forma, a definição da resposta válida deixa de ser efectuada na página de perfil. Após a criação de uma lição, apenas será possível realizar questões associadas a essa Unidade Curricular. Se o utilizador não criar nenhuma lição, será utilizada a última lição criada. Caso não exista ainda nenhuma lição criada, não será possível realizar qualquer questionário.

Página de criação de uma nova lição.

As sessões já existentes passam também a estar associadas a estas lições. Esta abordagem permite juntar vários questionários, com o fim de apresentar os resultados dos mesmos em conjunto. No caso de serem realizados questionários anónimos, não será possível ver as respostas de forma agrupada, uma vez que todas as respostas têm o mesmo aluno associado (aluno nº 00000). A opção para ver as respostas de forma individual continua disponível, tal como existia previamente.

Lista de lições existentes, caracterizadas pela Unidade Curricular e pela data/hora.
Visualização dos resultados agrupados de todos os questionários realizados numa sessão.

Semana #11

Durante esta semana dei início à escrita da segunda parte da dissertação, correspondente à implementação do sistema.

Para além da escrita da dissertação, iniciei a planificação dos inquéritos de utilização do sistema CLASSQUIZ. Neste momento a ideia passa por fazer três inquéritos diferentes: um para os alunos, outro para os professores e por fim um para os administradores da aplicação. Os administradores serão os utilizadores com acesso à pagina de administração, e terão como funções a criação de Unidades Curriculares e respectiva associação aos professores. Contudo, os administradores poderão existir em vários níveis, sendo que estas funções mencionadas correspondem ao nível mais baixo, que poderá corresponder ao regente de uma disciplina. Administradores de níveis mais elevados serão responsáveis pela actualização das listas de alunos de terminais, bem como a manutenção da base de dados, restauro de senhas de utilizador e inicialização da aplicação. Assim, os inquéritos aos administradores prendem-se às dificuldades encontradas nas tarefas descritas acima.

Os inquéritos do alunos têm um foco maior na utilização dos terminais, bem como no grau de aceitação dos mesmo ao sistema CLASSQUIZ. Assim, nestes questionários são abordadas questões como a abertura para diferentes métodos de autenticação (cartão de estudante e impressão digital), bem como a disponibilidade dos alunos para realizar os diferentes tipos de questionários (anónimos/autenticados e para fins estatísticos ou de avaliação). É ainda abordada a possibilidade de os alunos terem acesso à aplicação para visualizarem os seus resultados obtidos.

Por fim, os inquéritos aos professores focam-se mais nas dificuldades sentidas na utilização da aplicação, seja na criação de questionário, alteração da resposta válida ou exportação dos resultados, abordando ainda a probabilidade de virem a utilizar o sistema, e em que condições.

Ao nível da aplicação, foram feitas umas pequenas optimizações ao nível do código, mas que pouco ao nada interferem com o utilizador.

Semana #10

Foi concluída a implementação de questionários anónimos no lado do servidor. Durante a criação de um questionário, ou na sua página de edição, existe agora uma opção que permite seleccionar se o inquérito é anónimo, ou não. Isto reflecte-se também na página de visualização de resultados, uma vez que neste tipo de inquéritos não existe um aluno associado à resposta, nem existe uma resposta certa (apesar de esta opção continuar presente na criação do inquérito).

A tabela de resultados passa a ter um campo que indica se a resposta se refere a um questionário anónimo ou não. Assim, mesmo que um questionário que era anónimo deixe de o ser, as respostas continuam a ser anónimas. Dito de outra forma, o anonimato deixa de ser um parâmetro apenas do questionário, passando a ser também um parâmetro da resposta.

Visualização de resultados de um questionário não-anónimo.
Visualização de resultados de um questionário anónimo.

A forma como este inquéritos funcionam, do lado do estudante, é que este pode responder ao inquérito, independentemente de o cartão de estudante estar ou não presente. Caso o cartão não esteja presente, o terminal enviará o cartão número “00 00 00 00 00 00 00” na mensagem para o servidor, que corresponde ao aluno número “00000”, garantindo o anonimato do inquirido. Caso o cartão esteja presente num questionário anónimo, o terminal enviará a UID do cartão. De forma a garantir o anonimato do inquirido, o servidor irá de qualquer forma associar a resposta ao aluno “00000”.

Como todas as respostas têm o mesmo aluno associado, o processamento das respostas não contempla, neste caso, a verificação de se um aluno responde mais que uma vez, fazendo essa verificação apenas para o terminal. Assim, a opção seleccionada pelo professor no seu perfil sobre qual a resposta válida (a última ou a primeira) continua a ter efeito, sendo que neste caso a verificação é feita ao nível do endereço MAC.

Foram ainda feitas alterações à página fullscreen do questionário. Agora, ao entrar neste modo, apenas é visível um botão gigante no centro do ecrã que, ao ser premido, desaparece e mostra o questionário, iniciando-o de imediato. Esta abordagem previne que várias sessões sejam iniciadas ao mesmo tempo (por se clicar mais que uma vez no botão), e previne ainda que os alunos possam ver a pergunta e respostas antes do inquérito começar, o que na prática lhes dava mais tempo de respostas.

Ao nível dos terminais, foi corrigido um problema que fazia com que os novos microcontroladores NodeMCU v2 perdessem a sua ligação à rede Wi-Fi. Esta perda de conexão era causada por uma leitura quase constante do pino ADC (esta leitura sistemática é necessária por causa da implementação dos questionários anónimos). A resolução do problema passou por acrescentar um pequeno delay (100ms) antes da leitura das entradas. É importante referir que esta abordagem não previne que a ligação caia, mas reduz significativamente a sua ocorrência. Para além disso, não se pode por um delay muito elevado pois isso faz com que o terminal não seja tão responsivo. Como tal, tiveram de ser tomadas medidas de salvaguarda. Caso o terminal perca a sua ligação ao servidor, irá tentar retomá-la assim que um botão seja premido (pois só quando o botão é premido é que se sabe se a ligação caiu). Após a re-conexão, o aluno terá de premir novamente o botão, uma vez que a resposta anterior não foi enviada.

Ainda ao nível dos terminais, foi possível testar o novo terminal com o módulo de leitor de cartões, tendo-se verificado que tudo funciona como suposto (já foi possível responder a questionários com o novo terminal).

Semanas #8-9

Por fim consegui implementar uma solução para importar questionários a partir de um ficheiro. Em vez de importar os questionários directamente para o backend, como havia tentado previamente, optei por o tentar fazer através do frontend da aplicação. Na página de criação de um novo questionário, existe agora um botão que permite seleccionar um ficheiro .xlsx. Uma vez seleccionado o ficheiro, é criada uma tabela (invisível para o utilizador) que contém informação presente nesse ficheiro. De seguida, esta informação é utilizada para preencher os campos existentes. Com esta abordagem, deixa de existir o risco de um utilizador fazer override a um questionário já existente. Uma limitação que existe neste momento é que as imagens têm de ser adicionadas manualmente, ou seja, não podem ser importadas juntamente com o ficheiro Excel. Para além disso, a forma como é feita a selecção da unidade curricular do questionário não é intuitiva para o utilizador, uma vez que no ficheiro .xlsx deve estar indicada a sua ID e não o seu nome. Uma forma de contornar este problema é não permitindo que a unidade curricular seja importada juntamente com o resto dos parâmetros, tendo depois de ser seleccionada manualmente, como acontece com a selecção de imagens.

O ficheiro .xlsx tem também algumas restrições que devem ser cumpridas. A primeira é que o nome da “folha de cálculo” deve ser “Sheet1”, e a segunda é que as células onde estão os parâmetros do questionário devem ser os mesmo do ficheiro exemplo.

Ficheiro exemplo .xlsx.

Foi ainda criada uma nova tabela, designada ‘Terminal‘, que contém o mac address de todos os terminais válidos. Durante o processamento das respostas, é agora feita também uma validação do terminal. Assim, só os terminais registados serão válidos para responder a questões.

No que diz respeito aos terminais individuais, o firmware foi actualizado de forma a permitir a realização de inquéritos anónimos, para além dos autenticados, faltando, contudo, actualizar a aplicação de forma a que tal seja possível.

Por fim, foi testado o equipamento que chegou durante estas duas semanas, nomeadamente as battery shields, baterias, PCB, botões, encoders e microcontroladores. Com a ajuda do engenheiro Luís, foi possível montar um novo terminal, à execpção do leitor de cartões RFID, que foi testado, tendo-se verificado que, até ao momento, o sistema funciona como devido.

Para além do referido acima, foi dado início à escrita da dissertação, em particular à descrição do Estado da Arte.

Semana #7

Foram feitas alterações à forma como é validado o cartão de estudante do aluno. Segundo a nova metodologia, a validação deixa de ser feita no terminal individual para passar a ser feita no servidor, aquando do processamento das respostas. Assim, quando o terminal envia a resposta, envia a UID do cartão lido no lugar do número mecanográfico do aluno. Por sua vez, o servidor, quando está a processar as respostas, faz a validação do cartão, fazendo uma query a uma nova tabela designada ‘Students‘, que contém as UID dos vários cartões dos alunos e os respectivos números mecanográficos. Como consequência disto, o terminal fica bastante mais responsivo.

Para além disso, o terminal passa a enviar a resposta através de um http request ao servidor, em vez de a escrever directamente na base de dados. Desta forma, apenas o servidor (Django) tem acesso à mesma. Como consequência, é possível ter uma resolução até aos milissegundos nos tempos das respostas. Um pormenor a ter em conta é que o timer visível em modo fullscreen corre no browser e não no servidor, sendo que 1 segundo pode não ser exactamente um segundo (poderá ser ligeiramente mais longo, nunca mais curto). De forma a não induzir em erro o aluno quando este está a responder a um inquérito (se responder no segundo final, poderá pensar que ainda está a tempo quando na verdade o tempo já terminou), o tempo de resposta não é tido em conta para a validação da mesma, servindo apenas para dar a indicação ao professor de quais os alunos mais rápidos a responder. É importante referir que, apesar de o tempo de resposta não ser utilizado para validar a mesma, respostas submetidas depois do timer do modo fullscreen chegar a zero não serão contabilizadas. Desta forma, o aluno nunca será induzido em erro, pois todas as respostas submetidas enquanto o timer estiver a decrescer serão validadas.

Foi ainda adicionada a possibilidade de o utilizador (professor) escolher de qual sessão pretende ver os resultados, permitindo assim exibir resultados de inquéritos passados.

Selecção da sessão.
Tabela das respostas, com resolução até ao milissegundo.
De notar que este questionário tinha uma duração de 3 segundos. Devido às limitações descritas acima, a resposta é considerada válida uma vez que foi submetida enquanto o timer não tinha chegado a zero.

Foram ainda realizados os últimos testes com o microcontrolador NodeMCU v2 (Amica). Ligando este microcontrolador ao sistema já implementado, foi possível responder a um questionário, como se pode ver no vídeo seguinte.

Semana #6

Esta semana foram realizados os primeiros testes com a battery shield da WEMOS, tendo-se conseguido alimentar, com sucesso, tanto o microcontrolador NodeMCU v2 (AMICA), como todo o terminal individual já existente. A alimentação é feita com recurso a uma bateria 18650 (2500mAh) da Samsung, ligando a saída de 5V da battery shield à entrada Vin do microcontrolador. Usando este sistema de alimentação foi possível executar todas as tarefas já implementadas no sistema (conexão à base de dados por wireless, leitura e validação do cartão de estudante por comparação com a base de dados referida, e leitura do estado dos botões). Desta forma, fica comprovada a funcionalidade do sistema de alimentação inicialmente idealizado.

No que respeita à aplicação, foi implementada a funcionalidade que permite a leitura de respostas, e o seu processamento, vindas do terminal individual. Para tal existem três tabelas: a primeira, designada ‘Answer‘, é a tabela onde o terminal insere a resposta; a segunda, ‘AnswerProcessing‘, é a tabela onde é feito o processamento das respostas (no final do processamento deve existir apenas uma resposta por aluno e apenas um aluno pode estar associado a um endereço MAC); a terceira tabela, ‘Results‘, é onde ficam registadas as respostas para a eternidade.

Um problema que se verificou é que quando o terminal regista a sua resposta na tabela ‘Answer‘, a precisão da hora de registo é apenas até ao segundo. Isto significa que existe um erro potencial de até um segundo na resposta dada, e resposta submetidas no último segundo podiam ser consideradas como erradas. Para solucionar este problema, são dados mais 3 segundos (este número pode vir a ser alterado no futuro) até que se dê início ao processamento das respostas. O senão desta abordagem é que respostas submetidas no segundo imediatamente após o fim do inquérito podem ainda ser consideradas válidas. Ainda assim, considera-se que mais um segundo de tempo de inquérito não é determinante (o professor pode sempre jogar com este segundo extra quando define a duração do inquérito). NOTA: o erro de 1 segundo referido acima não será sempre de 1 segundo, pois depende da hora de início do inquérito e da hora de submissão da resposta. Por exemplo, se um inquérito, com duração de 60 segundos, for iniciado às 15:00:00.000001 horas, e uma resposta for submetida às 15:01:00.000001 e outra às 15:01:00.999999, ambas serão consideradas como tendo sido submetidas às 15:01:00, e serão válidas. Mas se o inquérito for iniciado às 14:59:59.999999, ambas as respostas serão inválidas.

Para o processamento das resposta, é dada a possibilidade ao professor de definir se quer que a resposta válida seja a primeira ou a última que foi submetida pelo aluno, através da sua página de perfil.

Imediatamente antes de se iniciar o processamento das respostas, é criada uma sessão associada ao questionário realizado. Esta sessão fica também associada a cada resposta dada. Isto é necessário porque um questionário pode ser executado várias vezes, para turmas distintas, e é necessário existir alguma parâmetro que os permita diferenciar.

Uma vez processadas as respostas, estas são guardadas na tabela ‘Results‘. O utilizador tem depois a possibilidade de ver os resultados do questionário na página quiz/results/, exibidos em forma de tabela, e a partir da qual pode exportar os resultados para um ficheiro .xslx. É importante referir que neste momento apenas são exibidos os resultados do último inquérito realizado. No futuro, tentarei dar a opção de escolha ao utilizador de exibir os resultados de uma dada sessão, de forma a que possa ver/extrair os resultados de inquéritos passados.

Uma vez que o sistema funciona offline, isto é, sem acesso à internet, foi necessário instalar as bibliotecas que até aqui eram obtidas por CDN (Bootstrap, JQuery, Popper.js, MathJax, e agora também FileSaver.js e SheetJS). Como consequência, a aplicação fica ligeiramente mais pesada, mas dada a capacidade computacional dos computadores/smartphones dos dias de hoje, a diferença não é significativa. Ainda assim, existe sempre a possibilidade de no futuro se tentar optimizar a utilização destas bibliotecas, quer fazendo uma filtragem para garantir que não estão a ser carregas funções que não são utilizadas, quer fazendo uma optimização para que estas apenas sejam carregadas quando forem necessárias.

Esta semana foi ainda dado início ao projecto da PCB. Uma das coisas a ter em conta durante o desenho da placa é a sua dimensão, bem como o posicionamento dos vários elementos. Assim, a par com o desenho da PCB, é feito o projecto CAD da solução final do terminal, de forma a garantir a correcta assemblagem dos elementos. As figuras seguintes mostram um protótipo da PCB (as ligações foram geradas automaticamente com o software Eagle) e do terminal individual.

PCB (vista de cima)
PCB (vista de baixo)
Terminal individual (com tampa)
Terminal individual (sem tampa)