Introdução Após o desenvolvimento da versão beta, é necessário perceber se a mecânica do produto final é perceptível para o público-alvo. A ubiquidade das tecnologias da informação e comunicação (TIC) e o papel do utilizador enquanto agente prosumer (criador e consumidor de conteúdos Web) na era do conhecimento (TOFFLER, Alvin), fazem com que aumente a preocupação em termos de testes de usabilidade, acessibilidade, funcionalidade, conteúdos e design.
Projectos com elevado nível de usabilidade melhoram a eficácia, eficiência, e a satisfação dos utilizadores.
O Design gráfico equilibrado e estável reflecte os valores do projecto. Esse requisito cria mais consistência e um ambiente confortável e seguro de interacção
A acessibilidade é uma exigência que deve ser tomada em conta, que deve fazer parte de uma estratégia para alcance universal do projecto.
A compatibilidade é um ponto essencial, uma arquitectura de informação consistente, flexível e evoluída que potencializa todo o projecto.
Todos os elementos da interface reforçam a credibilidade do projecto
Fig.1 – Características necessárias para a avaliação do sistema em termos de usabilidade
Sumário A equipa do projecto virtUA, concretizou ao longo do desenvolvimento da versão Beta: testes de funcionalidade, compatibilidade, acessibilidade e conteúdos. O presente documento serve de suporte aos testes de avaliação da aplicação e respectiva análise de resultados. Deste modo, este encontra-se subdividido em: 1. Planeamento dos testes ao projecto e objectivos 1.1.
Teste de funcionalidade
1.2.
Teste de usabilidade
1.2.1. Objectivos do teste de usabilidade 1.2.2. Funcionalidades testadas 1.2.3. Participantes 1.2.3.1. Recrutamento de participantes 1.2.4. Metodologia 1.2.4. 1.Organização do teste de usabilidade 1.2.4. 2.Planeamento e duração do teste de usabilidade 1.2.5. Calendarização dos testes de usabilidade 1.2.6. Timeline do projecto 1.2.7. Contexto do teste 1.2.8. Técnicas de teste 1.2.9. Técnicas de recolha de dados 1.2.10. Heurísticas de Usabilidade 1.3.
Teste de compatibilidade
1.4.
Teste de acessibilidade
1.5.
Teste de conteúdos
2. Conclusão e reflexão critica
Planeamento dos testes ao projecto e objectivos 1.1. Teste de Funcionalidade 1. 1.1.Objectivos do teste de funcionalidade O teste de funcionalidade visa tipificar, isolar e descrever erros ao nível da programação, design e conteúdos. É de realçar a importância do controlo de debugging para que se detectem falhas ao nível do funcionamento da aplicação. 1.1.2. Técnicas de teste Este teste baseia-se nas técnicas de teste por módulos do projecto, teste integrado e teste de regresso de forma a retestar problemas já corrigidos. 1.1.3. Técnicas de recolha de dados A técnica de recolha de dados tem por suporte a construção de grelhas de apoio ao registo de erros e controle do processo de debugging. 1.1.4. Agendamento temporal O teste de funcionalidade seguirá um processo contínuo antes e pós a versão Beta do website. É realizado pelos Recursos Humanos Internos e segue-se após o protótipo de alta-fidelidade. 1.1.5. Conclusão A equipa do projecto procedeu ao controle de debugging através de grelhas de apoio que reforçassem o estado das diferentes funcionalidades. Em termos de falhas, foi detectado no espaço Memórias, a promoção de inserção de conteúdos por parte do utilizador e a alteração do idioma de inglês para português nos comentários. Há, apenas, ajustes necessários em termos de design como ajuste de imagem, ecrãs de aplicação e botões e informação áudio.
1.2.Teste de Usabilidade “Usabilidade é a extensão na qual os usuários pertencentes a um determinado público-alvo atinjam objectivos específicos com eficácia, eficiência e satisfação num contexto de uso particular” - ISSO 9241-11
1. 2.1. Objectivos do teste de usabilidade O teste de usabilidade suporta e fundamenta a validação de todo o interface de uma aplicação multimédia. Quer o website quer a aplicação centram-se no utilizador (UCD- User Centered Design) pelo que faz sentido identificar as suas necessidades, perceber o contexto específico de uso, especificar o utilizador antes de encontrar soluções e avaliar os requisitos de design. A análise do projecto multimédia em termos de usabilidade pretende ser persuasiva de modo a que a maior parte dos utilizadores consiga acompanhar as tarefas e não conduza à frustração. Estes testes destinam-se a identificar se a interface do utilizador é, de facto, simples e acessível e se os elementos interactivos, também designados por controlos, desempenhem as funções que seriam de esperar.
Fig.2 – Procedimentos inerentes ao processo iterativo da avaliação do design da aplicação
1.2.2. Funcionalidades testadas A seguinte tabela resume os diferentes módulos a avaliar no teste de usabilidade, objectivos e sua importância. Módulos Login no website (Entrar)
Objectivos Verificar se o utilizador consegue efectuar login no website (entrar) Logout no Website Verificar se o utilizador consegue efectuar logout da aplicação Galeria de Verificar se o Fotografias utilizador consegue (Website) visualizar as fotografias Memórias (Website) Verificar se o utilizador consegue inserir posts, comentários e fazer partilha para o facebook Informação do Verificar se o projecto e contactos utilizador consegue (Website) aceder a informação do projecto e contactar a equipa Navegação Virtual Verificar se o utilizador consegue aceder directamente à navegação virtual. Navegação Virtual Verificar se o utilizador consegue navegar na aplicação de navegação virtual e o acesso aos diferentes menus da aplicação (mapa de navegação, opções e ajuda)
Importância Elevada. O utilizador só consegue inserir posts no menu Memórias, comentários e fotografias se estiver logado. Mínima. O utilizador pode estar sempre logado. Média. Serve como módulo complementar ao ecrã Memórias. Média. Não é objectivo primordial do projecto mas é complementar à aplicação e que contribui para a partilha da memória colectiva. Mínima. Trata-se de informação adicional/ complementar do projecto.
Muita elevada. Verificar se o utilizador consegue aceder à navegação virtual (objectivo primordial do projecto) Muita elevada. Trata-se do meio de interacção base e de importância fulcral na aplicação de navegação virtual.
Navegação Virtual
Aceder à informação sobre os diferentes departamentos, aumentar volume de som da aplicação, alterar a qualidade dos gráficos da aplicação e fullscreen
Elevada. Trata-se de funcionalidades complementares que não comprometem a interacção do utilizador mas que contribuem para uma experiência enriquecedora em todo o ambiente imersivo.
Fig.3 – Módulos a testar no teste de usabilidade
Segundo a norma ISSO 9241-11, usabilidade é a extensão na qual os utilizadores pertencentes a um determinado público-alvo atinjam objectivos específicos como a eficácia, eficiência e satisfação num contexto de uso particular. Assim, eis que surgem diferentes técnicas de medição da métrica de usabilidade:
Métrica Eficácia
Eficiência Satisfação
Noção Medição Cumprimento dos Nº erros objectivos/acções Cognitive Walkthrough propostas Thinking Aloud Protocol Modo como o utilizador Nº de cliques concretizou a acção Thinking Aloud Protocol Apreciação geral do Difícil medição participante Questionários pós-testes Aceitação e look and feel Thinking Aloud Protocol da aplicação Fig.4 - Medição da métrica de usabilidade
1.2.3. Participantes Segundo Virzi e Nielsen, bastam cinco participantes para detectar a maioria dos problemas de usabilidade. O estado resumir-se-á a seis participantes que tenham assistido à evolução do Campus de Santiago da Universidade de Aveiro.
1.2.3.1. Recrutamento dos Participantes Em termos de selecção dos participantes dos testes de usabilidade, estes respeitam 6 participantes com as características descritas na seguinte tabela. Número de participantes
Caracteristicas Tipo de participantes piloto regular em substituição
1 5 0 Totalidade de participantes
6
Ano de entrada na Universidade de Aveiro 1976-1984 1985-1993 1994-2000
1 2 2
2001-2011
1
Contacto com aplicações de navegação virtual 5 1
Sim Não Frequência de navegação virtual Muito raramente: 1–5 vezes por ano Poucas vezes: 1–3 vezes por mês Às vezes: 1 vez por semana
1 2 2
Muitras vezes: Mais do que 1 vez por semana
0
Motivação da utilização de aplicações de navegação virtual Interacção com espaço e momento temporal Motivos profissionais
3 3
Acesso a informação Descoberta e identidade do espaço virtual Partilha de informação e conteúdos
4
Fig.5- Características dos participantes dos testes de usabilidade
3 3
Os testes de usabilidade abrangem participantes cuja data de entrada na Universidade corresponde a diferentes intervalos temporais de evolução do Campus de Santiago. É de referir que se restringiu a seleccção dos participantes a antigos e actuais estudantes da Universidade de Aveiro. 1.2.4. Metodologia Os testes de usabilidade seguem uma avaliação sumativa (com intuito de melhorar a interface e persuadir as pessoas sobre o design de interacção). Este teste de usabilidade segue as áreas mais importantes do produto. As técnicas de teste utilizada são: o Guião Walkthrough e Thinking Aloud, por prioridades por frequência. 1.2.4.1. Organização do teste de usabilidade No teste de usabilidade, cada participante irá debruçar-se em cada tarefa específcia. A equipa irá conduzir 6 testes de 20 minutos em termos de sessões de estudo de usabilidade. Cada participante realizará diferentes tarefas enunciadas no guião relativas ao website virtua.campusitv.com e respectiva aplicação. Cinco minutos de cada sessão são utilizados para explicar a cada participante o âmbito do projecto. 1.2.4. 2. Planeamento e duração do teste de usabilidade Cada teste de sessão de usabilidade tem a duração de, aproximadamente, 20 minutos, em que 3 minutos correspondem à sessão introdutória de pré-teste e pós-teste. Pré-teste (3 minutos):
Configuração da sala ;
Explicação do âmbito do projecto;
Questionário pré-teste;
Thinking aloud;
Teste : Os participantes recebem um guião e desenvolvem as tarefas consoante o mesmo (Cognitive Walkthrough).
Pós-teste (3 minutos):
Questionário pós-teste ;
Recolha de informação quantitativa e qualitativa;
Recolha e reflexão sobre problemas particulares do projecto, expostos pelos participantes;
1.2.5. Calendarização dos testes de Usabilidade Tempo
Segunda, 6 Junho
9:00 – 10:00
Quinta, 9 Junho Configuração da sala Debriefing Sessão 4
10:00 – 10:45
Configuração da sala
11:00 – 1:00
Sessão Piloto
Sessão 5
2:00 – 6:00
Revisão da versão
Sessão 6
Beta e correcção de algum código/bugs 6:00 -6:20
Debriefing Sessão 1
6:30 – 7:00
Sessão 2
7:00 – 7:30
Debriefing Sessão 3
Fig. 6- Plano de sessão dos testes de usabilidade
1.2.6. Timeline do projecto
O quê?
Quando?
Reunião entre a equipa sobre os testes de usabilidade
31 de Maio
Rever os objectivos, âmbitos e entregas Identificar o critério de selecção de participantes Acordo na calendarização final
Entrega do plano de teste
31 de Maio
Recrutamento de participantes
6-8 Junho
Entrega do script da versão final
7 de Junho
6 sessões de testes de usabilidade de 20 minutos
6-9 de Junho
Entrega do relatório
9 de Junho
Apresentar soluções finais
9 de Junho
Fig. 7- Timeline do Projecto 1.2.7. Contexto de teste O teste será realizado num ambiente controlado em laboratório, no Deca. Tratase de um ambiente de natureza artificial em que o equipamento necessário e a concentração é maior. Uma vez que a equipa apresenta alguma inexperiência em realizar testes de usabilidade, entendemos que o ambiente controlado será a melhor opção para obter resultados e posteriormente a análise e correcção do projecto.
1.2.8. Técnicas de teste Cognitive Walkthrough Nesta técnica pretende-se que o utilizador realize determinadas tarefas prédefinidas que vão ajudar a perceber a usabilidade da aplicação nos seus pontos fulcrais. É de referir que será fornecido ao tester (utilizador) um guião escrito à priori. Deste modo, evita-se a dispersão deste último na realização do teste. Thinking Aloud Protocol Tendo por base o guião para a técnica Cognitive Walkthrough, a técnica Thinking Aloud Protocol é baseada no pedido ao utilizador para que se exteriorize todos os pensamentos e o raciocínio que tem ao longo do percurso definido pelo guião e que nos ajudará a perceber melhor o nível de satisfação ou frustração com a interacção da aplicação multimédia. A observação será feita em laboratório, não participativa e indirecta pelo que não a consideramos, neste projecto, técnica de teste.
1.2.9. Técnicas de recolha de dados A equipa utilizará como técnicas de recolha de dados, os questionários. Assim, estes serão constituídos por: 1. Questionário pré-teste: obtenção de uma caracterização do utilizador, diagnóstico objectivo do seu perfil 2. Questionário pós-teste: obtenção da satisfação do utilizador na utilização da aplicação
1.2.10. Instrumentos, materiais e recursos humanos necessários Para a implementação dos testes de usabilidade, é necessário: 1. Laboratório de testes; 2. Guião de tarefas para entregar ao utilizador; 3. Inquéritos pré e pós-experiência; 4. Contador; 5. Elementos do grupo: anotação, observação e explicação do processo;
1.2.11. Planificação temporal dos testes O teste de usabilidade tem duração de um dia e está agendado para o dia 3 de Junho. No fim-de-semana, o grupo irá proceder à análise de resultados e a melhorias na aplicação.
1.2.12. Análise de resultados Os testes de usabilidade foram realizados a seis participantes e aos quais foram extraídas algumas conclusões. No que confere a representação dos dados, relacionada com a monitorização do tempo em minutos e a execução das tarefas, optou-se pela construção de um gráfico, onde se pode constar as diferentes variações de cores representativas de cada participante do teste de usabilidade. Deste modo, é possível estabelecer uma análise comparativa entre estes. As tarefas estão ajuntadas em módulos, sendo estas: Site – Home (diz respeito à página inicial); Site – Memórias (espaço memórias, onde se publicam posts e comentários); Aplicação -Visita Virtual (Aplicação de Navegação Virtual) ; Site Projecto e Equipa (Áreas do menu Sobre – Informação sobre o Projecto) e Site – Galeria (Visualização de Fotografias).
Os participantes dividem-se de acordo com a sua literacia tecnológica e ao nível dos conteúdos. Segundo os testes feitos, dois dos beta testes, apesar de terem pouca experiência no domínio técnico , (Participante 1 e Participante 6), foram seleccionados dado o seu domínio ao nível do conteúdo, concentrando-se mais em questões sobre a pertinência e incorrecções ao nível da informação e conteúdo. Dois participantes destacam-se, ainda, pela rapidez no cumprimento dos módulos, (Participante 3 e o Participante 5) pelo que já detêm alguma experiencia em plataformas
Web,
sendo
ligeiramente
mais
rápidos
e
um
grau
de
conhecimento/familiaridade com os diferentes mecanismos apresentados. Por fim, os Participantes 4 e 5, demoraram ligeiramente um pouco mais, comparativamente aos dois utilizadores citados anteriormente, dado que existia uma preocupação por parte destes últimos em navegar e perceber o que era pedido. Estes revelaram alguma experiencia no contexto dos jogos pela facilidade de navegação virtual do Campus de Santiago.
Fig.8-Representação gráfica do tempo de execução dos módulos de cada participante Antes de se realizarem os testes de Usabilidade tivemos um participante piloto que testou toda a aplicação estimando um tempo de execução das tarefas, o que tinha sido estabelecido era que o ideal seria cumprir todas as fases sensivelmente entre 12 a 14 minutos.
Em baixo é apresentado o gráfico com de média de tempo contendo as linhas de representação da prestação de todos os participantes deste teste, apresentam-se em tons de cinza. Pela análise deste gráfico, temos quatro dos participantes que se conseguem incluir na estimativa. Dois deles abaixo da estimativa, e outros dois encontram-se ligeiramente a cima mas no entanto diferencia-se de cerca de 2 minutos dos outros participantes 3 e 5.
Fig.6 - Representação gráfica do tempo médio de execução dos modulos
1.2.13. Conclusão e reflexão No que diz respeito aos testes de usabilidade a diferentes participantes, pode-se tirar as seguintes conclusões:
Alguns participantes não tinham nenhuma das seis contas identificadas no plugin de login (“entrar”). É de referir que dado que o projecto integrará, posteriormente, o login com o utilizador universal, esta questão não se coloca uma vez que a solução apenas pretende simular o utilizador universal. Detectou-se, ainda, pouco contraste no botão "entrar" existente no website. Este botão tem sido muito problemático, pois foram testadas diversas soluções para resolver os problemas que apresenta - desde a colocação de um fundo branco à alteração da cor das letras. As modificações não surtiram efeito, pelo facto deste login apresentar-se, normalmente, por cima de um slider de imagens que variam constantemente, alternando o fundo com cores diversas. A próxima solução será alterar a localização do botão entrar, combinando isso com a alteração da cor e eliminação do stroke.
De um modo geral, há dificuldade em inserir post no blog Memórias por não conseguirem encontrar o botão que dá acesso a escrever um novo post. As hipóteses de resolução prendem-se com a melhoria do seu design a nível ergonómico/funcional, a alteração da localização do botão ou informar, antecipadamente, o utilizador sobre a sua localização. O mesmo se segue para sair da área/formulário de envio de post – esta apresenta apenas uma indicação de que o mesmo foi enviado, deixando o utilizador na mesma área. O utilizador deveria ser remetido para a página do blog (memórias). Para solucionar este problema, foi sugerido a instalação de um novo plugin que permita a interacção com o API do wordpress para envio de posts de forma mais simples e eficaz.
Há alguma dificuldade em interagir com a galeria de fotografias no Unity 3D. Esta dificuldade resume-se à compreensão da mudança de fotografias, pelo que é necessário alterar a forma como aparece a informação ao utilizador na zona da mira. Como resolução, há que implementar, em
Photoshop, uma nova mira especifica para a interacção com a galeria de imagens e a interacção lógica dessa área.
No que concerne o ecrã de opções durante a navegação virtual, há dificuldade em encontrar o botão que despoleta este. A solução passa por aparecer, quer seja a primeira vez que o utilizador inicia a aplicação, um ecrã de ajuda com informação que auxilie a interacção, após o loading da página.
Na entrada na navegação virtual, há dificuldade em perceber que a mudança de intervalos temporais processa-se pelo botão/link “Iniciar navegação virtual”. Uma possível solução passa por alargar a área clicável;
No que diz respeito à escolha de ponto de entrada, também seguiram-se alguns problemas do ponto de vista da sua visualização. A solução passa pelo aumento do tamanho dos botões e inclusão, na área de ajuda, um ecrã com a explicação da interacção, incluindo figuras ilustrativas da acção;
Há dificuldade em compreender como funciona a interacção com os objectos i posicionados ao longo do Campus. Verificou-se que não é intuitivo para os utilizadores compreenderem que necessitam de se aproximar (atravessar) os pontos “i” para despoletar fotografias. Estes presumiram que a forma de interacção seria igual à textual dos edifícios, ou seja, através do posicionamento da mira no objecto “i” e posterior clique na tecla i. A solução passa pelo aparecimento de informação contextual na parte superior da mira a sugerir uma aproximação ao objecto em causa ou alteração do ícone “i” para uma analogia relativa a fotografias (possível utilização do ícone da máquina fotográfica, existente no manual da marca para ícones);
Outra dificuldade prende-se com a percepção o funcionamento dos ícones existentes na interface da aplicação. Vários utilizadores não conseguiram, de forma rápida e intuitiva, perceber o que alguns ícones significavam nem que tinham de carregas nas teclas indicadas para aceder às áreas respectivas. A solução passa pela alteração dos ícones para algo mais próximo do ponto de vista semiótica, criação de uma tooltip localizada por baixo dos ícones por forma a identificar o seu significado ou inserção de uma explicação aprofundada na área de ajuda da aplicação;
Os textos com informação relativa a cada edifício eram demasiado monótonos. Para facilitar esta leitura, decidiu-se alterar a estrutura com que este se apresenta para que se possa realçar a informação;
Durante a navegação, a informação textual relativa a qualquer departamento/ edifício é despoletada através do atalho i. Esta causou algumas dificuldades por não ser através do clique no rato. No entanto, esta percepção de que seria possível aceder à informação foi descartada, por levantar problemas ao nível de visualização da informação;
Foi indicado por um dos beta-testers que os hovers dos botões do menu principal estão um pouco diferentes, a nível visual, do resto do website. Por esse motivo as cores e entalhe existente nesses botões serão um pouco diferentes.
Uma outra situação que se verificou pelos beta-testers foi a existência de muitos botões e opções, potencialmente distractivos da atenção do utilizador, na área de escrita e envio de post.
Alguns beta testers queixaram-se que a utilização de teclas para aceder às diversas funcionalidades da aplicação não seria a melhor opção. Durante as diversas etapas na produção desta aplicação, outras alternativas foram testadas para melhorar a interação, no entanto, nenhuma delas se mostrou mais eficaz.
A existência de dois cursores na aplicação (mira e rato) em simultâneo para interagir com a aplicação, cria confusão na utilização do cursor. Poderá ser conveniente fazer desaparecer o cursor convencional do rato, de forma a não gerar confusão junto do utilizador. Com essa escolha, emergem dois problemas: impossibilidade de escolha do período temporal da timeline existente no website e impossibilidade de utilização dos botões na aplicação;
Além de todas as funcionalidades/correcções pensadas para solucionar situações descritas na análise dos erros, surgiram, igualmente, outros desenvolvimentos complementares, nomeadamente: AJUDAS no Unity
A criação de mecanismos de ajuda no Unity passa pela criação de um novo ecrã inicial (após o loading e antes do menu) com as seguintes funcionalidades: Processo de Verificação se é a primeira vez do utilizador na aplicação (poderá ser implementado pelo reconhecimento - ou não reconhecimento de "variáveis temporárias do unity" no sistema).
Caso seja a primeira vez no sistema, o utilizador é remetido, automaticamente, para um ecrã de ajuda tutorial que o irá ajudar a compreender todos niveis de interação na navegação;
Caso não seja a primeira vez no sistema, o utilizador tem a possibilidade de escolher se quer continuar a navegar no mesmo local (nas mesmas coordenadas) onde estava na altura do último fecho da aplicação, ou se quer começar num dos pontos de entrada pré-definidos.
Timeline Criação de uma nova área que permita, facilmente, mudar de período temporal na própria aplicação. Website Atualização da área da ajuda com mais perguntas & respostas;
4.3. Testes de Compatibilidade 1. Objectivos do teste de compatibilidade O teste de compatibilidade visa a verificação do conteúdo ao nível da consistência da aplicação multimédia para os diferentes browsers e resoluções, de modo a garantir uma visualização correcta na plataforma. O projecto destina-se a um público demasiado abrangente, logo é imprescindível a preocupação com os diferentes browsers e resoluções. 2. Técnicas de teste As técnicas de teste de compatibilidade são o teste por módulos do projecto, o teste integrado e o teste de regresso de forma a retestar os problemas já corrigidos. 3. Técnicas de recolha de dados O teste de compatibilidade tem como suporte a construção de grelhas e apoio ao registo de erros. Neste proceder-se-á ao teste de 2 resoluções e 5 browsers (2 resoluções * 5 browsers = 10 testes). Fazem parte dos browsers-alvo destes testes o IE, Firefox, Chrome e Safari.
Porquê estes browsers?
Os browsers a utilizar são o Internet Explorer, Firefox, Chrome e Safari dado serem os mais utilizados: IE (24.3%), Firefox (42.9%), Chrome (25.6%) e Safari (4.1%), segundo o website w3C - dados para 2011. Apesar da percentagem de utilização do Safari não ser muito representativa porque está incorporado os utilizadores do Windows , no universo Apple este nível de utilização poderá ser significativo.
Porquê estas resoluções? As resoluções a considerar são 1280*800 para portáteis wide, 1280*1024, 1024*768 e 1440*900 para ecrãs mais antigos.
3. Agendamento temporal O teste de compatibilidade seguirá um processo contínuo antes e pós a versão Beta do website. É realizado pelos Recursos Humanos Internos e segue-se após o protótipo de alta-fidelidade.
4. Conclusão Em termos de compatibilidade em diferentes browsers, na plataforma Windows, o projecto apresenta bons resultados no IE nas diferentes resoluções, Firefox e Google Chrome. É apenas de realçar que no browser Internet Explorer, verifica-se um ligeiro problema na visualização das imagens iniciais. Aparece, também, uma div no lado direito do ecrã que provoca o aparecimento desnecessário do scroll horizontal. Na plataforma MAC OS , apresenta, tambem, bons resultados, apesar de afectar, no Safari numa resolução 1024*768 a legibilidade dos menus e submenus.
4.4. Testes de Acessibilidade
1. Objectivos do teste de acessibilidade A realização de testes de acessibilidade tem por objectico tornar uma aplicação acessível a utilizadores com necessidades especiais e facilitar o seu acesso a utilizadores que devido a determinadas circunstâncias têm o seu acesso limitado incapacidades temporárias. O contexto de uso assume uma importância fulcral nestes testes. Através dos testes de acessibilidade, pretende-se desenhar uma aplicação apelativa para todos (principio da equitividade), utilização em diferentes contextos (flexibilidade) e simples. 2. Funcionalidades testadas Considerando o facto que a aplicação multimédia desenvolvida pela equipa baseia-se em cores para dar algum feedback ao utilizador da sua acção, torna-se relevante avaliar problemas com imagem e navegação pelo website. Deste modo, os diferentes aspectos de avaliação passarão por: •
Permissão da leitura monocromática;
•
Imagens com legendas ou descritas em texto;
•
Comprimento do texto na página e seu ajuste no tamanho da janela;
•
Facilidade no contacto com os responsáveis do projecto (e-mail,
facebook, formulário);
3. Normas W3C Authoring Tool Acessibility Guidelines (ATAG) Esta norma é pertinente para websites que impliquem a interacção com o utilizador (inserir, editar/actualizar e apagar conteúdos), como CMS, blogs, wikis, partilha de fotos e redes sociais. Será importante corrigir e verificar o conteúdo inacessível ao utilizador e o acesso a diferentes tipos de media do website. No que diz respeito a princípios mais relevantes do W3C para a aplicação, seleccionou-se: • Não recorrer apenas à cor: Há que assegurar as informações disponíveis sem cor e ter em atenção o contraste entre fundo e combinação de cores; • Fornecer mecanismos de navegação claros: Barras de navegação, links ilustrativos, etc. As ferramentas de avaliação a utilizar pela equipa são as automáticas dado que estas devolvem um relatório das directivas a tomar e a respectiva validação. São as mais indicadas para testes iniciais, rápidas e sistemáticas, não necessitando de recursos humanos extra. Porém, integrar-se-á, também, ferramentas de revisão directa juntamente com os testes de usabilidade (cognitive-walkthrough-Guião), de forma a ter em conta aspectos semânticos (avaliação humana), questões subjectivas, aplicável a diferentes cenários e de complemento a testes iniciais.
A ferramenta a utilizar em termos de avaliação automática de acessibilidade será o Web Accessibility Inspector, critério baseado no W3C WCAG 1.0 em que se avalia o website em termos de HTML, CSS, gerando um diagnóstico preciso: tamanho do texto, cores e fundos. Dado que a aplicação web apresenta uma componente visual forte determinativa de acções, é necessário efectuar a sua avaliação encontrando soluções alternativas.
4. Agendamento temporal O teste de acessibilidade realizar-se-á no dia 3 de Junho. É de referir ainda que as questões de acessibilidade são relativas a aspectos muito estruturantes e devem ser tidas em conta aquando o desenvolvimento de CSS. 5. Conclusões Para o teste de acessibilidade, utilizou-se o programa Web Accessibility Inspector que inspecciona e examina a acessibilidade de um website e aponta os problemas que afectam em termos da sua percepção. Depois de ter efectuado o teste, a equipa procedeu à análise dos resultados:
Fig. A – Resultado do teste de Acessibilidade Considerando que os testes de acessibilidade de prioridade 3 são elevados, a equipa virtUA tem consciência da sua importância e fragilidade do projecto, pelo que irá tentar minimizar o seu impacto, quanto possível eliminar alguns dos erros. Dado a pretensão de garantir a interoperabilidade das especificações para a Web e a usabilidade por parte dos utilizadores com necessidades especiais, o grupo irá, pelo menos tentar minimizar a ocorrência de erros e disponibilizar avisos em caso de erros. Será complicado do ponto de vista da interacção no Unity permitir que o utilizador mantenha uma posição corporal correcta dado a simultaneidade da interacção rato e teclado. As legendas das imagens e a informação sonora quando se clica nos edificios constituem o primeiro passo para a minimização destes problemas.
4.5. Teste de conteúdos 1. Objectivos do teste de conteúdos A equipa apresenta uma preocupação primordial com os conteúdos pelo que irá convidar um especialista com formação em Tecnologias e Design para fazer uma apreciação crítica ao nível dos conteúdos (ortografia e formatação textual, qualidade das imagens, vídeo, etc.) 2. Técnicas de teste A técnica utilizada para este tipo de teste é o peer review, considerando que os testes e revisão serão feitos por peritos externos. 3. Técnicas de recolha de dados O teste de conteúdos tem como suporte a construção de grelhas de apoio à correcção. 4. Agendamento temporal O teste de conteúdos subdivide-se em dois momentos: dia 30 de Junho (antes do teste de usabilidade) e no dia 5 de Junho (pós-teste de usabilidade e antes da versão Beta). 5. Conclusões Paralelamente aos testes de usabilidade, estabeleceram-se testes de conteúdos através da técnica peer review. Procedeu-se à correcção de algumas falhas apontadas como a questão da legibilidade de alguns textos devido ao negrito, informação histórica e correcção dos níveis de luminosidade na aplicação Unity para que as fotografias não ficassem muito escuras e não comprometesse a sua visibilidade. É de acrescentar que a equipa terá que proceder a futures correcções ao nível a informação sobre a Evolução do Campus, qualidade da captação de som e detalhes do ponto de vista dos gráficos 3D.
2. Conclusão e reflexão critica Após uma breve análise dos diferentes testes, a equipa terá que dar prioridade ao teste de usabilidade e funcionalidade. Todos eles apresentam-se um elevado grau de importância no projecto. No entanto, o projecto virtUA não seguirá nem testes de design nem testes de segurança. Não iremos proceder a testes de design, dado que estes só se processam caso o design seja encomendado e a equipa não confie no próprio design. O mesmo segue para os testes de segurança, dado que as questões de segurança são asseguradas pelos serviços externos como no caso de login que é feito com a ligação facebook, através de um plugin. Acresce-se o facto que no projecto não existe fornecimento de dados pessoais que reúna características que justifiquem a concretização deste tipo de testes. Procederemos, assim, por grau de importância, à resolução dos testes de funcionalidade e usabilidade. Posteriormente conteúdos e compatibilidade e acessibilidade.