Testes de Usabilidade

Para o teste de usabilidade, o grupo usou 3 ferramentas: um Cognitive Walktrough, com um guião de tarefas para o utilizador realizar, uma tabela de registo de dados / comentários do utilizador (através da técnica de Thinking Aloud) e um inquérito final de satisfação do utilizador.

Ao efectuar o teste, foi possível ao grupo identificar 3 problemas de usabilidade na nossa plataforma:
- A posição do formulário de contacto
- A posição do formulário de registo
- A colocação de vídeo nos comentários

Essas foram os aspectos que os utilizadores mais comentaram, mesmo que não se tenham reflectido em cliques ou erros, pois nos dois casos o problema era os utilizadores andarem a procura do modo de efectuar as tarefas, necessitando, no caso do upload de video, do auxílio do grupo.
Em relação ao formulário de contaco, o principal aspecto negativo era o facto de se localizar no fundo da página, no footer. A maior parte dos utilizadores demorava um pouco a encontrá-lo por ter de fazer o scroll ao longo da página.

Já o formulário de registo, o facto de não se localizar no header provoca um pouco de hesitação nos utilizadores, pois é o lugar comum onde estes elementos se encontram.
Estes dois pequenos problemas não são, no entanto, alarmantes, pois não causaram confusão nos utilizadores, como os mesmos apontaram nos inquéritos de satisfação. Apenas são os aspectos que demoram mais a ser encontrados.

Quanto à colocação do vídeo nos comentários, a opção de colocar o url do vídeo, sem precisar do embbed e apenas tendo de “deslinkar” o mesmo revelou-se complicada para os utilizadores. A tentativa de alertar os utilizadores para esse facto com uma tooltip informativa também se revelou pouco eficaz, pois os utilizadores não viam o botão. Esta é uma questão fundamental para o grupo resolver.
Outra das tarefas do questionário que causou alguma dificuldade aos utilizadores testados foi o sistema de legendagem do youtube que é pouco intuitivo e prático. Este, no entanto, não é algo que seja da responsabilidade do grupo, logo não o podemos resolver.

Outro aspecto constatado nos testes está relacionado com as próprias funcionalidades do wordpress. A partir do momento que o utilizador está logado, surge uma barra no topo que permite igualmente pesquisar na plataforma, terminar sessão e editar o perfil.

Assim, três dos cinco utilizadores testados utilizaram essa ferramenta, e não a barra implementada pelo grupo ou os botões de editar perfil e fazer logout. No entanto, pensamos que isto não é um problema, e dá liberdade ao utilizador de utilizar o que for mais intuitivo.

Para completar os elementos utilizados para o teste, e a título de curiosidade, o grupo usou uma ferramente online chamada “ClickTale” (http://www.clicktale.com/), que rastreia diversos elementos num site como o número de cliques, as “heat zones”, ou seja, que são mais clicadas ou onde o mouse passa mais frequentemente, etc. 

O grupo fez o registo dos cinco testers e monitorizou as zonas mais clicadas e os locais de passagem do rato, originando os seguintes documentos:

(Obs.: no mapa de cliques há uma zona que está oculta por não apresentar nenhum clique)
 

Testes de Compatibilidade

Efectuando os testes de compatibilidade entre browsers e concluímos que grande parte dos problemas prendem-se com o não reconhecimento de CSS3 por parte do Internet Explorer. No entanto, não é grave uma vez que tudo está funcional, são pequenos pormenores como fade-ins nos botões ou os cantos dos formulários.
Dois outros problema surgiram recentemente e são esses que prendem agora a atenção do grupo: os comentários recentes, no footer, não estão a respeitar a grelha e ultrapassam o espaço que lhes é destinado, e o botão de pesquisa, a lupa, não está alinhada com o campo de inserção de texto.
 

Teste de acessibilidade:

W3C xhtml validation:

Foram detectados 12 erros:

•10 são referentes ao código de embed dos vários vídeos do youtube presentes na página, código este que é gerado automaticamente.

•1 um refere-se a uma tag cujo atributo alt não está atribuído definido. Este erro só aparece uma vez, porque só exite uma imagem que foi colocada através do plugin de inserção de ficheiros nos comentários, e sendo a imagem colocada automaticamente este atributo não lhe é atribuído pelo script base do plugin.

•1 refere-se a um uma incorrecta invocação de um tag HTML numa variável de javascript.

W3C CSS validation:

São reportados 56 erros de CSS 2.1. Todos estes erros se referem a tags de CSS3.

São ainda reportados 211 avisos referentes a contrastes de cor na plataforma

Em sequência dos posts já efectuados sobre os testes ao documentário eis o último teste efectuado ao documentário.

posts anteriores:

• http://euragora.blogs.ua.sapo.pt/11773.html
• http://euragora.blogs.ua.sapo.pt/10613.html

A realização deste teste deveu-se à possível má interpretação do inquérito previamente realizado e para tal decidiu-se realizar um novo teste, mais detalhado, que nos permitiu aprofundar algumas questões.

Em baixo encontra-se o documento produzido.

Teste

Com a mudança da data da entrega, o grupo achou que seria benéfico alterar a calendarização dos testes da plataforma. 

Assim, os únicos testes que se efectuarão antes da versão BETA serão o de Segurança, uma vez que já todos os módulos a ser testados estão totalmente implementados e o de Acessibilidade, a realizar no dia anterior à entrega, em que se espera que a plataforma já esteja numa versão pronta a entregar. 

Assim, este é o novo calendário de testes à Plataforma Eurágora: 

Os erros listados derivam da análise dos inquéritos realizados a 32 alunos e da análise crítica do documentário por parte do grupo de trabalho.

1. Correcção de erros ortográficos, nomeadamente na sequência inicial: onde se lia “tracar objectivos” e “eramus”, lê-se agora “traçar objectivos” e “erasmus”;
2. Alinhamento da logomarca em relação à área útil do ecrã e reposicionamento da estrela em relação à marca “Eurágora”:
   
   Figura 1 – Comparação entre alinhamentos (antes e depois da correcção)
3. Separador “Media e Cultura” – correcção da animação do texto – verificava-se inconsistência ao nível da animação da opacidade (efeito de escrita à máquina) em relação aos restantes momentos do vídeo onde se aplicou o mesmo efeito;
4. Separador “Web” – correcção da velocidade da animação do globo – verificou-se que a velocidade não era constante ao longo do separador (erro de redundância na utilização de keyframes);
   
   Figura 2 – Redundância de frames
5. Gráfico “quantas horas de TV vês por dia?” – Correcção do momento (no tempo) em que surgem as percentagens respectivas a cada resposta: antes surgiam apenas quando todas as barras horizontais estavam completas e em simultâneo; agora surgem no final do movimento da respectiva barra (individualmente) por forma a facilitar a leitura da informação; verifica-se uma melhor leitura porque cada percentagem está mais tempo (segundos) presente no ecrã e é mais fácil associa-la à respectiva barra.
   
   Figura 3 – Comparação entre alinhamentos no ecrã (antes e depois) – Na imagem da esquerda verifica-se um posicionamento deficiente dos conteúdos em relação à área total. A imagem da direita representa a correcção desse posicionamento assim como um aperfeiçoamento gráfico ao nível das animações e da posição dos conteúdos entre si com o objectivo de melhorar a eficiência na transmissão da mensagem.
6. Texto de suporte - Aperfeiçoamento da composição ao nível do tamanho da fonte e da opacidade por se ter verificado que as definidas não tornavam o texto totalmente perceptível aquando da visualização do vídeo sem ser em full-screen.
   
   Figura 4 – A imagem da esquerda representa as características da fonte na versão do protótipo de alta-fidelidade; a imagem da direita representa a versão corrigida.
7. Texto de suporte - Aperfeiçoamento da composição ao nível do tamanho da fonte.
   Figura 5 – A imagem da esquerda representa o tamanho da fonte na versão original enquanto a da direita representa a versão corrigida.
8. Correcção do período de permanência do texto no ecrã por se ter verificado que o tempo inicial não permitia uma leitura perfeita do texto.
   
   Figura 6 – Representa o texto cuja permanência no ecrã foi prolongado de cerca de 1 segundo para 2 segundos.
9. Velocidade do gráfico circular e das animações dos respectivos dados: na versão original (protótipo de alta-fidelidade) identificaram-se algumas falhas ao nível das animações no gráfico circular, nomeadamente no que diz respeito à sincronia entre a “fatia” do gráfico que se está a formar e o respectivo valor em percentagem.
   
   Figura 7 – Diferença entre as posições dos valores (%) em relação à animação das “fatias” nas diferentes versões.

Esta lista não se encontra fechada, pelo que podem ser acrecentados erros no decorrer do trabalho.

Na realização do teste ao documentário obtiveram-se 32 inquéritos preenchidos.

Os dados foram posteriormente inseridos no Microsoft Excel e foi gerado o seguinte conjunto de gráficos que correspondem a cada uma das perguntas do inquérito.

Figura 1 - Representação gráfica representativa dos dados recolhidos

Conclusões sobre os dados recolhidos

Depois de tratados os dados, e observando os gráficos, tendo em conta as respectivas escalas utilizadas em cada pergunta, as conclusões são:

“Que temas aborda este excerto do documentário?”

Todos os participantes assinalaram como resposta “Media e Cultura” e “Internet”. Sendo estes os temas que foram abordados neste trecho, pode-se concluir que os separados utilizados na identificação dos temas estão bem visíveis, sem necessidade de alteração.

“De um modo geral, quanto à velocidade da informação textual, consideras que seja:”

As respostas dividiram-se em 2 grupos: 19 dos inquiridos disse que a velocidade da informação textual é Algo lenta; 13 disseram que é Adequada.

Apesar dos resultados dizerem que a velocidade do texto é algo lenta, o grupo, depois de nova visualização e análise do doumentário, optou por prolongar o tempo de permanência de alguns trechos com informação textual, por considerar que a pergunta pode ter sido mal interpretada. Sendo assim, definiram-se os seguintes objectivos (com vista o melhoramento do produto):

-       Observar as velocidades das informações textuais e identificar os casos onde surgem mais rapidamente;

-       Reduzir as velocidades para dar mais tempo ao visualizador de perceber todos os conteúdos textuais.

De um modo geral, no que diz respeito à velocidade dos gráficos, consideras que seja:

Apesar das respostas se dividirem por 4 grupos, a maior concentração focou-se em dois: 18 dos participantes assinalaram que a velocidade dos gráficos é adequada; 11 disseram que era algo rápida. Só 2 afirmaram ser algo lenta e 1 demasiado rápida.

Pode-se concluir então que é necessário alterar a velocidade dos gráficos, tendo em conta a dispersão das respostas, forçando uma análise gráfico a gráfico.

Os objectivos serão:

• Observar a diferença nas velocidades das animações dos diferentes gráficos;
• Uniformizar a velocidade dos gráficos e reduzir um pouco a velocidade das animações.

Clareza da informação, sendo que 0 corresponde a nada clara e 10 a muito clara?

As respostas concentram-se nas possibilidades de resposta do 6 ao 10, existindo 2 pessoas que classificaram a clareza da informação com um 4.

Conclui-se que a informação está bem explicita, tendo sido a avaliação positiva.

Qualidade técnica, sendo que 0 corresponde a muito fraca e 10 a muito boa?

Tal como a resposta anterior, a avaliação é maioritariamente positiva. As respostas concentram-se nas possibilidades 5 a 10, havendo maior concentração na possibilidade 8 (11x) e 9 (9x).

Qualidade de som, sendo que 0 corresponde a muito fraca e 10 a muito boa?

Os resultados para esta questão foram mais dispersos. Apenas a classificação 1 e 2 não foram assinaladas por nenhum dos participantes. Apesar de termos um número significativo de possibilidades assinaladas compreendidas entre os valores 6 a 10 (27 das respostas), ainda existem participantes que assinalaram respostas consideradas negativas.

Como o objectivo é termos, não só um som razoável, mas uma qualidade de som elevada, concluiu-se que este deverá ser melhorado.

Os objectivos serão assim os seguintes:

• Identificar quais os momentos em que o som é de menor qualidade, isto é, com mais ruído associado, ou o volume inadequado;
• Suprimir o máximo de ruído possível dos momentos identificados.

Como classificas o volume (música de fundo):

Dos 32 participantes, só 4 é que classificaram o volume como Elevado, sendo que os restantes 28 referiram que o volume é Adequado.

Conclui-se que não surge a necessidade de alterar o volume da música de fundo.

Como classificas o volume (intervenções do focus group):

As respostas concentraram-se em 2 grupos: 25 dos participantes classificaram o volume das intervenções do focus group como Adequado; 7 assinalaram o volume como Baixo. Neste caso já existe uma percentagem mais considerável de participantes a identificar o volume como baixo.

Devido a estes resultados, e também pela existência de ruído em alguns dos trechos, concluiu-se que o som deverá ser editado.

Os objectivos serão:

• Identificar quais os momentos em que o som tem mais ruído e/ou se encontra mais baixo;
• Editar o som de forma a retirar o ruído e uniformizar os trechos de focus group existentes nesta parte do documentário.

Usabilidade e Conteúdos

Para o documentário, os tipos de teste mais importantes são os que representam a eficácia, eficiência e satisfação desde os métodos de transmissão da informação até à apreensão dos conteúdos.

Os testes a realizar ao documentário não podem seguir a tipologia de testes que são utilizados em contexto web., visto que não existe uma interacção directa com os utilizadores, que neste caso são visualizadores que apreendem os conteúdos.

Assim sendo, os 3 atributos principais de especificação e avaliação de usabilidade (eficácia, eficiência e satisfação) assumem os seguintes objectivos:

Eficácia –transmissão da mensagem (conteúdos);

Eficiência – se os conteúdos são apreendidos pelos visualizadores da melhor forma possível;

Satisfação – se o utilizador fica satisfeito com o que visualizou.

Participantes

No contexto audiovisual, quanto maior o número de participantes, mais adequada vai ser a análise dos resultados, possibilitando uma melhor correção dos conteúdos e técnicas de transmissão dos mesmos. Quanto às idades, convém abranger o máximo o nosso público-alvo (dos 18-25 anos).

Contexto

O contexto de utilização poderá ser variado (desktop, dispositivos móveis, portáteis, projeção), ou seja, o ambiente de realização do teste será não controlado.

No caso, será num anfiteatro do departamento23, no anfiteatro 2.

Técnicas de teste

No caso dos testes ao documentário não poderão ser utilizadas técnicas de teste que recorram a interação com o utilizador, como o Cognitive Walktrought ou o Thinking Aloud, utilizados na plataforma. 

Assim, os participantes irão ver/ouvir o trecho do documentário.

Técnicas de recolha de dados

Questionário, no qual estão presentes algumas escalas que variam quanto ao tipo de questão. (http://www.scribd.com/fullscreen/56797567?access_key=key-swl9foy5w72ztf26fo8)

Materiais necessários para a realização do teste: anfiteatro, computador, projector, sistema de som e questionário.

Para o sucesso de qualquer projecto / produto é importante submeter o mesmo a um conjunto de testes que averiguem se o mesmo cumpre os objectivos para que foi concebida, qualquer que seja o browser / sistema operativo utilizado ou o utilizador que a ela queira ter acesso.
Na plataforma do Projecto Eurágora vamos realizar os seguintes testes: compatibilidade, segurança, usabilidade e acessibilidade.

Funcionalidade 
Os testes de funcionalidade são fundamentais para garantir que a plataforma cumpra todos os objectivos para que foi criada sem erros.
Estes testes foram também sendo executados pelo grupo ao longo do desenvolvimento do projecto, de forma a ir validando os módulos que iam sendo concluídos. 

A técnica de teste é, assim, a técnica de regressão: as funcionalidades vão sendo testadas e corrigidas sucessivamente, pondendo voltar a corrigir erros que já haviam sido detectados. 
A técnica de recolha de dados a utilizar é a observação e registo directo: as funcionalidades são detectadas e imediatamente registadas para serem depois acrescentadas à calendarização para futura correcção. Serão registadas numa tabela semelhante à usada para o teste de compatibilidade, com a mesma grelha de avaliação de prioridade a usar no teste de compatibilidade (ver m

Conteúdos 
Uma vez que os conteúdos primordiais são inseridos pelos utilizadores e os conteúdos inseridos pelo grupo são mínimos, não haverá um teste específico para este parâmetro.

Design 
O teste relativo ao design da plataforma deve ser realizado antes da execução da mesma, e assim este ocorreu na entrega da especificação gráfica através de peer review: um especialista da área, no caso, o professor Pedro Amado, que validou o design concebido para a entrega da TP4.

Compatibilidade
Os testes de compatibilidade já têm sido feitos ao longo de todo o desenvolvimento da plataforma web, principalmente nos browsers Firefox e Google Chrome / Rockmelt. Nesta fase é importante verificar com mais atenção algumas pequenas variações que possam ocorrer, nomeadamente a nível do layout da página, assim como testar no brower Safari e nas diferentes versões o Internet Explorer
Para além dos Browsers,o grupo testou também em diferentes sistemas operativos, nomeadamente Windows XP, Vista e 7 e MacOS X Snow Leopard. 

O objectivo é verificar a consistência da plataforma nas tecnologias em que será maioritariamente visualizada, garantindo o seu pleno funcionamento.

Notamos que a nível de sistemas operativos, e tendo em conta que as funcionalidades da plataforma são comuns a qualquer outra, não há qualquer diferença no seu uso. Assim, debruçamo-nos apenas na questão dos browsers.

Para a concretização desses testes, utilizaremos a técnica de unit testing com recolha de dados com recurso a uma grelha de registo, em que listamos os parâmetros a ser avaliados em cada browser / SO, aos quais atribuímos um valor de 1 a 3 (em que 1 determina que o aspecto avaliado não está operacional ou com vários problemas; o 2 significa que tem alguns erros importantes a corrigir e 3 que está com um funcionamento totalmente satisfatório, ou com pequenas imperfeições a melhorar). É deixado também um espaço para colocar exactamente que erros / falhas foram encontradas.
Uma vez que a maioria dos problemas encontrados são relativos à formatação das páginas, registamos com mais detalhe os parâmetros de CSS a avaliar.

Este teste será levado a cabo pelo próprio grupo de trabalho.

Segurança
Uma vez que a nossa plataforma terá uma grande componente de participação, é importante que a segurança dos dados dos utilizadores seja assegurada, e que a plataforma demonstre robustez face a ataques à integridade da mesma.
Para isso, vamos também recorrer a unit testing, com dois métodos de recolha de dados.

Em primeiro lugar, vamos seguir também uma tabela de registo a publicar posteriormente em que determinamos scripts a implementar no formulário de contacto, de forma a perceber o comportamento da plataforma face a intrusões de PHP e SQL.

Uma segunda fase consiste não exactamente num teste à nossa plataforma em particular, mas sim numa pesquisa sobre a robustez do próprio CMS, de forma a perceber quais as fragilidades mais comuns do Wordpress e como conferir maior protecção.

Usabilidade
Se os testes de funcionalidade são importantes para que a plataforma funcione para satisfazer os seus objectivos, só os testes de usabilidade garantem que esta os cumpra efectivamente, garantindo a sua eficácia e eficiência e levando à satisfação dos utilizadores.
A plataforma constitui uma espécie de rede social em que a contribuição dos utilizadores é fundamental para o seu dinamismo e crescimento, ou seja, tudo se centra no utilizador: User Centered Design.
Este aspecto reforça ainda mais a importãncia de testar a usabilidade desta vertente do projecto.
Para a realização do teste vamos ter em conta a norma ISO 9241-11 (extend to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use) que determina 3 atributos principais de especificação e avaliação de usabilidade: a eficácia, a eficiência e a satisfação, mediante um determinado público-alvo e num dado contexto específico.

Participantes
Segundo Virzi (1992) e Nielsen (2000) são apenas necessários 5 utilizadores para detectar 80% dos problemas de usabilidade, assim sendo, será este o número de participantes deste teste, preferencialmente 2 de um sexo, 3 do outro e com idades diferentes, tentando abranger ao máximo o nosso público-alvo (dos 18 aos 25)

Contexto
Tendo em conta que o contexto de utilização do computador e de acesso à plataforma não é particularmente específico, ou seja, pode ser em casa, numa sala de aula, num café, etc., será em ambiente não controlado.
No caso, será numa sala do departamento a definir.

Técnicas de teste

As técnicas de teste serão: Cognitive Walkthrough e Thinking Aloud.
No Cognitive Walktrough pretende-se que o utilizador siga um determinado conjunto de procedimentos definidos pelo grupo posteriormente, de forma a testar os principais módulos / funcionalidades da plataforma.
O guião de tarefas a pedir ao utilizador será posteriormente publicado no blog.
A técnica de Thinking Aloud funcionará como um complemento à técnica anterior. Durante a realização das tarefas, é pedido ao utilizador que exteriorize o que pensa e as dificuldades que encontra, de forma a percebermos quais as tarefas que causam mais perturbação ao utilizador.
Esta técnica pressupõe que o utilizador esteja a falar para algum elemento do grupo de forma a sentir-se mais a vontade a exteriorizar o que pensa, logo a observação processar-se-á de forma directa e participativa.
As técnicas de recolha de dados serão questionários, entregues após a realização dos testes, usando várias escalas que dependem do tipo de questão.
Os materiais necessários para o teste serão apenas: uma sala, um computador, o guião e o questionário.

Acessibilidade

Assim como a usabilidade, é importante aferir a acessibilidade da plataforma de forma a garantir que qualquer utilizador tenha a ela acesso e que consiga que ela desempenhe as funções para as quais foi desenhada.
É importante realçar que, para além das pessoas com necessidades especiais intrínsecas e permanetes (invisuais, daltónicos, etc), qualquer utilizador “comum” pode, em algum momento, apresentar igualmente necessidades especiais derivadas de cansaço, problema visual ou físico momentâneo.
Parâmetros a avaliar

Logo no momento da construção da plataforma, o grupo teve em atenção alguns aspectos fulcrais neste contexto da acessibilidade, nomeadamente:
- a capacidade de leitura a monocromático (preto e branco) para pessoas com dificuldades de leitura das cores;
- a substituição das imagens por texto caso algo ocorra na visualização das mesmas, e assim possível leitura por programas de varrimento;
- o não uso de botões como imagem, que não permitem a funcionalidade anteriormente descrita;
- a possibilidade de aumentar / diminuir o tamanho do texto;
- o fornecimento de um sistema de ajuda com FAQ (Frequently Asked Questions) e com contactos da equipa de desenvolvimento para outras questões;

Para complementar estes cuidados, o grupo vai recorrer a algumas normas específicas e ferramentas automáticas de avaliação da plataforma, conseguindo assim poupar precioso tempo na realização dos testes:

W3C CSS VALIDATION SERVICE (http://jigsaw.w3.org/css-validator/)
Esta ferramenta visa testar a norma CSS Techniques for Web Content Accessibility Guidelines 1.0, fundamental para avaliar mais a fundo algumas das questões visadas acima, como a dos contrastes.

W3C MARKUP VALIDATION SERVICE (http://validator.w3.org/)
Esta ferramenta diz respeito ao HTML da plataforma e às questões da construção, baseando-se na norma HTML Techniques for Web Content Accessibility Guidelines 1.0.
 

Agendamento dos testes 

No seguimento da entrega do protótipo de alta fidelidade segue-se a seguinte etapa: versão beta e testes.

Objectivos do post:

• Identificar e resolver os problemas críticos referentes à última entrega;
• Calendarizar as tarefas a efectuar;
• Testes a efectuar à plataforma e documentário.

Módulos e secções a desenvolver

Plataforma

Documentário

Identificação de problemas e funcionalidades/melhoramentos a implementar

Seguindo o conselho dos docentes, e de forma a faciliar a partilha de bugs e funcionalidades entre os elementos do grupo e a docência (docentes da disciplina e orientadores), utilizou-se a ferramenta Code (code.ua.pt).

Esta ferramenta foi muito útil na identificação dos problemas e sua descrição, mas mais do que isso, na organização das tarefas ao nível temporal - escolha de ínicio e fim das tarefas; percentagem já realizada; número de horas previstas para a realização; gantt, etc.

Foi criado um projecto "Eurágora" que contém 2 subprojectos "Documentário" e "Plataforma" onde são reportados os erros referentes a estas duas vertentes do nosso projecto.

Nota: a calendarização está disponivél para a docência da disciplina.

Imagens do projecto criado no code e issues reportados

Para partilhar esta informação com a restante comunidade académica, elaboraram-se tabelas com toda a calendarização referida no code, de forma a clarificar todos os processos realizados. :)

Subprojecto Documentário

Existem tarefas que se repetem durante vários dias. Serão tarefas a realizar em continuidade, por isso é que estão representadas desta forma.

Subprojecto Plataforma

Testes a realizar ao documentário

Nas duas últimas aulas de projecto estudaram-se as hipóteses de teste a realizar.

Quanto ao documentário já especificamos temporalmente a realização dos testes.

Ir-se-á realizar um teste, no decorrer de uma aula teórica do segundo ano de Novas Tecnologias da Comunicação, com vista a analisar a usabilidade do protótipo de alta fidelidade, para futuros melhoramentos no mesmo e implementação das mudanças na entrega da versão beta.

A documentação (inquérito) está a ser produzida.

Calendarização dos testes

Brevemente irá ser publicado um post com os objectivos, técnicas, técnicas de recolha de dados, participantes, e instrumentos a utilizar na realização dos testes.