Universidade de Aveiro

#118_15 - research day 2012

 

 

Os primeiros momentos do research day hoje de manhã, ainda vamos cá ficar até às cinco. Apareçam!

#entrega06testes

 

1. Contextualização teórica

De acordo com o tipo de projecto que nos encontramos a desenvolver, optamos por realizar apenas testes de conteúdo, design e usabilidade.

Não será necessário fazer testes de compatibilidade uma vez que a aplicação estará alojada num computador, disponibilizado pela Universidade de Aveiro e que a forma como a UAW! esta está a ser implementada não pressupõe incompatibilidades entre sistemas operativos ou outro tipo de softwares. No entanto, será sempre necessário garantir que o OpenNi, o Flash Player e o Osceleton se encontrem instalados na máquina. Relativamente aos testes de segurança, apenas terão de ser realizados ao nível da interface que permitirá a inserção de comentários on-line - a realizar no período de desenvolvimento desta componente - pois todo o resto da aplicação é do tipo stand-alone, não sendo da nossa competência a prevenção de intrusões ilícitas. Devido ao tipo de equipamento utilizado – sensor kinect – e à forma como a aplicação reage – movimento gestual do utilizador – este projecto não é adequado para usuários com necessidades especiais motoras, sendo que, o sensor necessita de reconhecer todas as partes do corpo para poder analisar e calibrar o utilizador, não havendo assim, a necessidade de realizar testes de acessibilidade.

Para a realização dos teste da aplicação, procuramos seleccionar dez participantes com o seguinte perfil:

• Principiantes – percebendo, assim, se a aplicação apresenta um bom funcionamento, fácil navegação e bom sistema de ajuda;
• Jovens e adultos – sendo esta aplicação dirigida a este tipo de público-alvo, pretendemos saber se despoleta interesse e motivação;
• Utilizadores destros/esquerdinos – de forma a verificar se existe alguma interferência no uso da aplicação, quanto à orientação.

1. Relativamente aos testes de conteúdo, estes serão elaborados pela equipa de produção que terá que verificar e corrigir os erros de conteúdo relativamente aos textos (legibilidade, formatação, ortografia e sintaxe), às imagens (qualidade) e às animações (qualidade e visibilidade). A técnica utilizada para a concretização deste tipo de teste será unit testing – testes individualizados dos diferentes módulos funcionais - recorrendo à observação e ao registo directo.
    
2. Relativamente aos testes de design, estes serão avaliados por um conjunto de utilizadores voluntários que irão analisar a consistência, a identidade visual, o equilíbrio cromático, a legibilidade e a ergonomia visual. O aspecto gráfico é o primeiro impacto que um novo utilizador terá relativamente à aplicação e caso seja agradável, poderá reduzir o número de erros, quanto à usabilidade.
   A técnica utilizada será o teste integrado – teste simultâneo dos diferentes módulos – onde os utilizadores utilizam, seguindo um guião, a aplicação e no final, respondem a um questionário de resposta aberta, com o intuito de avaliar os parâmetros acima enumerados.
    
3. Relativamente aos testes de usabilidade, estes serão avaliados por um conjunto de utilizadores voluntários. Este tipo de teste procuram adaptar-se aos diferentes utilizadores, de forma a que estes atinjam os seus objectivos com eficácia, eficiência e satisfação num contexto específico de uso. Neste sentido, procura-se que a aplicação seja de uso fácil, contribuindo para a motivação e interesse de quem a explora. É importante que o utilizador que não possui conhecimento relativamente a este projeto, aquando do seu primeiro contacto, se sinta familiarizado e realize, com rapidez e facilidade, aquilo que pretende. Para tal, é importante, avaliar essencialmente, a precisão do movimento, o acesso aos diversos pontos, e a facilidade/dificuldade demonstrada pelo utilizador durante a exploração da aplicação (selecção de uma opção; voltar atrás; deslocação direccional).
   Para tal, a aplicação será testada num ambiente de uso controlado – simulação do seu ambiente natural de utilização – e irá recorrer-se a dois tipos de técnicas de teste:
    

• Cognitive Walkthroughs – será possível verificar todos os passos e quais as dificuldades apresentadas pelos participantes, aquando o pedido de determinadas tarefas (ex: selecção de um botão do menu) para posterior análise e respectiva solução.
• Thinking-Aloud Protocol – Quando o utilizador sente dificuldade em realizar determinada tarefa, deverá expressar aquilo que ‘sente/pensa’, para que seja registado;

Quanto às técnicas de recolha de dados, consoante os tipos de teste enumerados acima, optamos por recorrer a sessões individuais,  realizadas informalmente, onde e pedido a cada participante que respondesse a um inquérito antes e depois de interagir com a aplicação. Em simultâneo, a equipa do projeto registava numa tabela dados para análise. Para complementar, recorreu-se ao registo de vídeo para análise detalhada de alguns pormenores. No ínicio de cada sessão, foi mostrado ao utilizador um vídeo promocional que simulava o screen-saver da aplicação - este funciona como instruções para o uso da aplicação. 

2. Material de apoio à realização dos testes

2.1. Tabela utilizada pela equipa do projeto para o registo de dados

 2.2. Questionário para os participantes

 

 

 2.3. Registo de vídeo

O vídeo que apresentamos mostra o ambiente das sessões de teste, assim como, algumas das funcionalidades da versão beta.

 

 

3. Análise de dados

3.1. Dados relativos ao teste da aplicação

Com o auxílio dos dados recolhidos na primeira fase do questionário foi possível identificar quais os utilizadores que já tinham utilizado previamente o sensor Kinect - assinalados no gráfico com a cor azul - percebendo assim, que este factor não revela grande interferência na prestação do participante à semelhança do que acontece com a orientação do utilizador.  

O presente gráfico permite concluir que as tarefas pedidas foram, no geral, concluidas com sucesso, apresentando em segundos, um valor médio satisfatório - corresponde à linha verde do gráfico.
É possivel analisar, quando comparadas a tarefa a) com a tarefa c) - que correspondem as duas à seleção de um item do menu - a curva de aprendizagem, reflectindo em média, a diminuição do tempo gasto para metade.

Após a análise da informação recolhida através do método Thinking-Aloud Protocol, registou-se:

• Os botões de navegação presentes na galeria de fotografias, que permitem o avanço e retrocesso, não estão de acordo com as expectativas do utilizador, na medida em que deveriam fazer deslocar as fotografias de forma contínua, sempre que a mão se encontra sobre um deles.

• O botão voltar revelou alguns problemas de visibilidade e posição, devendo ser destacado e uniformizado - manter a mesma posição em toda a aplicação, inclusivé quando nos encontramos na consola de um ponto de interesse.

• A inicialização do jogo é feita de forma muito rápida e o utilizador não tem percepção do que acontece, perdendo de imediato uma vida. Relativamente às vidas, também estas terão que ser assinaladas de uma forma mais visivel. 

 

 

3.2. Análise dos dados recolhidos depois da interação com a aplicação

 

Pela análise deste gráfico, podemos perceber que os gestos pelos quais optamos são adequados e o utilizador, facilmente, se  conseguiu adaptar aos mesmos. 

Cada teste individual demorou, em média, cerca de 6 minutos. Ao analisar o gráfico podemos perceber que nenhum dos utilizadores se sentiu demasiado cansado após a experiência de interacção com a aplicação. Este foi um aspeto que tentamos ter sempre em conta, desde o início do desenvolvimento do projeto, não so pela disposição no espaço das areas de seleção, mas tambem pela calibração do Kinect, de forma a reduzir a area de controlo do cursor. 

 

Um dos aspetos que nos levantava mais dúvidas era o tempo de espera para a seleção de um item - seria este demasiado lento? 
Após a análise deste gráfico, percebemos que nenhum dos particantes considerou que o tempo é demasiado, mas sim o suficiente.

 A análise deste gráfico permite perceber que os gestos que optamos são bastante simples, o que irá facilitar a interação por parte do utilizador.

3.3. Observações com maior ocorrência nas perguntas de resposta aberta do questionário 

"Consegues facilmente navegar com o cursor e apontar para onde desejas? Se não, diz em quê que sentiste mais dificuldades."

De uma forma geral, a resposta a esta pergunta foi afirmativa, revelando que facilmente se consegue controlar o cursor de forma intuitiva. Pela análise de cada questionário, podemos ainda destacar referências singulares a aspetos como:

• O lado esquerdo exigir um pouco mais de esforço, pela necessidade de movimentação do corpo;
  
• Dificuldade em fazer deslocar a mão de um extremo ao outro da interface.

"O que achas do sistema de selecção (aponta e espera)?"

A resposta a esta pergunta revelou-se positiva, tendo a maioria referido como uma boa solução simples para a substituição do tradicional clique. No entanto, foi refererido também que só depois da visualização das "instruções" é que ficou claro o funcionamento do sistema de selecção - factor com o qual já contavamos e por isso, estarão presentes no screen-saver da aplicação.

"Faz uma apreciação dlobal da aplicação. Tenta responder às segintes questões:

a) o que mudarias na aplicação?
b) onde sentiste mais/menos dificuldade?
c) o que gostaste mais/menos na aplicação?
d) sentiste-te, de alguma forma, constrangido/envergonhado?"

a) Os aspectos mais referidos foram:

• O funcionamento dos botões de navegação na galeria de fotografias.
• O posicionamento e coerência do botão "Voltar"
• Aumentar o feedback durante o jogo: - quando inicia; número de vidas; quado se perde;

b)  O jogo é o ponto da aplicação onde se verifica maior dificuldade de interacção, sendo que todo o resto não revela existência de grandes dificuldades;

c) Aplicação muito inovadora e interessante; o recurso à fotografia; o aspecto minimalista da interface e a falta de complexidade das controlos confere à aplicação um carácter bastante apelativo.

d) Na globalidade, ninguém se revelou sentir constrangido ou envergonhado pela necessidade de movimentação do corpo para a interacção com a aplicação.

 4. Conclusão

Depois de concluida esta primeira fase de testes poderemos passar à analise dos três fatores inerentes ao conceito de Usabilidade para o poduto que nos encontramos a desenvolver: 

Eficácia: A detecção da presença de um utilizador encontra-se funcional e este consegue tomar, facilmente, o controlo do cursor para aceder aos diversos conteúdos da aplicação.

 Eficiência: Será ainda necessário proceder a alguns melhoramentos, o sensor deverá captar apenas o corpo da pessoa que estiver a utilizar a aplicação, ignorando os demais movimentos. Isto permitirá proporcionar uma melhor experiência reduzindo as interferências do espaço. Como já foi referido, é necessário proceder, também, à alteração dos pontos que se revelaram mais criticos. Aumentando assim, o nivel de eficiência da parede interactiva. 

 

 5. Referências

http://www.useit.com/papers/heuristic/heuristic_list.html

http://pplware.sapo.pt/jogos/pplware-ja-experimentou-o-kinect-e/

http://testesdesoftware.blogspot.pt/

 

#aula_13

 

Na passada aula de projeto, lecionada pelo Professor Ivo e pelo Professor Caixinha, foi apresentado o ponto de situação relativamente à aplicação. Em seguida, mostramos o plano de testes a realizar para a próxima entrega e foram-nos sugeridas alterações que, no decorrer da aula, foram modificadas.

P.s: Os testes já foram realizados com bastante sucesso. Obrigado a todos os que colaboraram!

 

#aula_12

 

Iniciamos a aula com a demonstração do trabalho desenvolvido até hoje ao Professor Benjamim e discutimos a forma de como esta implementação foi concebida. No seguimento da aula, foi feita alguma pesquisa para a implementação do jogo e foi ainda, aproveitado o tempo para trabalhar para a disciplina de Publicidade e Marketing que se encontra directamente relacionada com o projecto.

#orientação_13

 

Na semana passada,à semelhança da estratégia que temos vindo adoptar, fomos estando em contacto com o orientador, demonstrando os principais avanços na implementação do projecto.

No dia 23 de Maio, tivemos oportunidade de reunir com o Bruno, membro da equipa Mesh-t, que nos ajudou relativamente à programação do algoritmo de calibração para o kinect. 

 

p.s: obrigado Bruno por nos teres ajudado com este bug!

#aula_11

 

No decorrer da passada aula de projeto, consolidámos a bateria de testes, revendo e selecionando as diferentes técnicas, para a aplicarmos no teste da versão beta: foi realizada uma lista com as escolhas feita pelo grupo e a justificação de cada uma. Avançamos ainda com o planeamento de algumas destas componentes.

Continuámos com o desenvolvimento da aplicação e apresentámos o ponto de situação aos docentes. Analisámos com o professor Ivo os bugs encontrados relativamente ao design e discutimos possíveis alterações. Com o professor Helder falamos sobre os bugs técnicos, nomeadamente sobre a calibração do Kinect que, neste momento, já se encontra realizada.

 

#entrega_06pre

 

Numa primeira fase - protótipo de alta fidelidade, optámos por desenvolver a aplicação a um nível superficial - as três áreas presentes no menu já se encontram acessíveis, apresentado os diferentes POI’s e a timeline.

Para a versão beta, propomo-nos a desenvolver a consola de opções de um POI presente no ecrã “visitar campus”, considerando-o como um exemplar, pois é igual para os restantes. Esta consola apresenta três opções: informações sobre o ponto de interesse, uma galeria de fotos e um espaço com curiosidades. Relativamente aos pontos lúdicos estes encontrar-se-ão assinalados - no ecrã “visitar aveiro” correspondem à Praça do Peixe e ao Parque do Drinks e no ecrã “visitar o campus” correspondem ao Depósito de água e à Ponte do Crasto. Para a versão beta optámos por desenvolver o jogo correspondente ao POI Ponte do Crasto.

O jogo assemelhar-se-à a um puzzle, onde será apresentado um thumbnail de uma fotografia do campus universitário e o utilizador terá que compor os fragmentos da mesma fotografia, posicionados aleatóriamente, que devem combinar para formar a imagem apresentada em tamanho menor.

 

Após o desenvolvimento e entrega do protótipo de alta fidelidade, foram detetados alguns bugs na aplicação, durante a sua exploração. Tivemos também, a oportunidade de apresentar o projeto a uma turma de Design, onde vários alunos o exploraram e deram o seu feedback, o que nos ajudou na recolha de opiniões e problemas de usabilidade.

Posto isto, realizamos uma tabela identificando o tipo, descrição, classificação e calendarização do bug, para que o grupo rapidamente consiga saber quais as funcionalidades já implementadas que necessitam de ajuste:
 

• Programação 

Bugs	Descrição	Classificação	Calendarização
Menu Superior	Se a mão não alcançar bem o retângulo que permite fazer a colisão entre os dois objetos, o botão no seu estado hover pisca	Elevado	Até ao dia 8 de Junho
Menu Superior	Depois de selecionar uma das áreas do menu superior, não é possível regressar à anterior somente à seguinte	Elevado	Até ao dia 8 de Junho
Kinect	Ajustar a calibração – definir um ponto máximo (cabeça do utilizador) que corresponda ao topo da aplicação, um ponto mínimo (cintura) que corresponde à base da aplicação e o máximo do braço esticado que corresponda às laterias para que o utilizador não precise de se mover como acontecia no protótipo de alta fidelidade	Elevado	Até ao dia 8 de Junho
Kinect	Definir se o utilizador é destro ou esquerdino, pois apenas é possível utilizar a mão direita	Baixo	Até ao dia 8 de Junho

• Design
  

Bugs	Descrição	Classificação	Calendarização
Diferenciação dos POI's	Quando a mão alcança o POI, não existe nenhuma diferença visual que indique se aquele ponto de interesse é um local ou um jogo. Impossibilitando o utilizador de aceder diretamente ao jogo, teria que utilizar um método de tentativa erro.	Elevado	Até ao dia 8 de Junho
Feedback do sistema	Quando o menu “visitar aveiro” se encontra selecionado, as riscas que indicam a seleção, antepõem-se ao sistema de feedback - fazendo com que este perca um pouco de legibilidade.	Baixo	Até ao dia 8 de Junho

 

Durante o desenvolvimento do projeto, procedemos a alterações relativamente aos requisitos funcionais: o conceito base manteve-se mas a forma como a informação é apresentada, modificou-se. Para além disso, acrescentamos uma nova funcionalidade, onde o utilizador tem a possibilidade de visualizar e inserir comentários nas fotografias através do seu dispositivo móvel com leitor QR-Code.

Apresentamos, então, a lista de requisitos funcionais alterada e aquela que servirá de guia para a conclusão do projeto.

 

1. Sistema de ajuda

1.1. Screensaver (animação);

• Ativar a aplicação através do gesto; 
   

2. Ecrã inicial

2.1. Visitar o campus

Apresentação dos POIs

• Deslocar para a esquerda;
• Deslocar para a direita;

Seleção do POI

• Consola de opções:
  • Seleção da opção;
  • Voltar ao ponto anterior.

Seleção do ponto lúdico

• Consola de opções:
  • Seleção da opção;
  • Voltar ao ponto anterior.

 

2.2. Visitar Aveiro 

Apresentação dos POIs

• Deslocar para a esquerda;
• Deslocar para a direita.

Seleção do POI

• Consola de opções:
  • Seleção da opção;
  • Voltar ao ponto anterior.

Seleção do ponto lúdico

• Consola de opções:
  • Seleção da opção;
  • Voltar ao ponto anterior.

 

2.3. Ua antigamente 

Apresentação da linha temporal de 5 em 5 anos

• Deslocar para a esquerda;
• Deslocar para a direita.

Seleção de um ano

• Apresentação dos anos intermédios;
• Voltar ao ponto anterior.

Seleção de um ano intermédio

• Acesso à informação por leitura;
• Voltar ao ponto anterior.

 

3. Consola de opções 

  3.1. POIs

• Galeria:
  • Visualização da fotografia;
  • Visualização dos comentários;
  • Próxima fotografia;
  • Fotografia anterior;
  • Voltar à consola de opções.
• Informações:
  
  • Acesso à informação por leitura;
  • Voltar à consola de opções.
• Curiosidades:
  • Acesso à informação por leitura;
  • Voltar à consola;
• Voltar:
  • Voltar ao ponto anterior.

 

3.2. Pontos lúdicos

• Como jogar:
  • Acesso à informação por leitura;
  • Voltar à consola de opções.
• Jogar (puzzle; brick breaker; jogo da mira; pair game):
  • Controlar o jogo através do gesto;
  • Sair do jogo.
    
• Voltar:
  • Voltar ao ponto anterior.

 

4. Inserir comentários das fotografias

• Aceder ao url disponibilizado através do QR-Code:
  
  • Escrever comentário;
  • Enviar comentário.

 

#orientação_12

 

Durante toda esta semana, fomos encontrando o nosso orientador e fomos acentando já alguns pontos e por isso, a hora da orientação serviu de apoio à resolução de alguns bugs encontrados durante o protótipo de alta fidelidade e foi também, apresentada a entrega de hoje.

#118_14 - logotipo

Depois da aula de ontem de Publicidade e Marketing, e de acordo com a reunião do grupo com o professor, chegámos a conclusão que o nosso logotipo precisava de ligeiras modificações. A imagem que se segue apresenta o logo antigo do lado esquerdo e o mais recente do lado direito.



As alterações concretizadas consistem em:

-alargar o tipo de letra de forma a dar mais peso/consistência ao logotipo;

-adicionar um ponto de exclamação "!"  com o intuito de reforçar a ideia da onomatopeia que sugere admiração;

#aula_10

A aula de hoje, 14 de Maio, teve inicio com uma breve explicação da entrega n.º 6 - que deverá estar dividida em duas partes. A primeira, de entrega obrigatória até ao dia 18 de Maio, consiste de forma resumida em: -identificar de problemas a resolver a nível de programação, design e conteúdo;

-identificar, no mapa de navegação, componentes, módulos ou secções a desenvolver;
-identificar, definitivamente, os requisitos e funcionalidades;

A segunda entrega, deve ser entregue até dia 8 de Junho e consiste na:

-correcção de erros detectados;
-implementação das alterações definidas;
-integridade da aplicação (robustez e qualidade);
-desenvolvimento de testes de compatibilidade, usabilidade e segurança;

Posteriormente, o grupo fez a apresentação da aplicação em funcionamento ao professor Hélder Caixinha, que aproveitou para testar a interferência de possíveis utilizadores enquanto o funcionamento normal da aplicação. No restante tempo da aula o grupo aproveitou para desenvolver uma lista de tarefas e, posteriormente, começámos a realizar alguns dos pontos listados.