posts recentes

arquivos

tags


Quarta-feira, 13 de Junho de 2012
#118_15 - research day 2012

 

 

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




Sexta-feira, 8 de Junho de 2012
#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:

  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:
     

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

TABELA

 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

grafico1

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:

galeria

voltar

 jogo

 

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

grafico1 

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. 

grafico2

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. 

grafico3 

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.

grafico4

 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 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:

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. 

Satisfação: este aspecto é, talvez, o mais difícil de medir e quantificar, pois, encontra-se relacionado com factores subjectivos. De uma maneira geral, a satisfação refere-se ao nível de conforto que o utilizador sente ao utilizar a aplicação. Assim, analisando em globalidade as respostas obtidas nos inquéritos, os participantes mostraram sentir-se satisfeitos e aliciados pelo produto UAW!. É ainda de referir que mesmo para aqueles em que o nivel de difculdade era maior, não foi sentida grande frustração devido à rápida percepção de como funciona.

Em suma, a realização desta bateria de testes revelou-se bastante útil na identificação dos principais problemas relativos à experimentação da parede interativa UAW!. Desta forma, poderemos agora proceder às alterações nevessárias com o intuito de contornar os principais obstaculos encontrados e referidos ao longo desta publicação.

 

 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/

 



publicado por carlota-silva às 23:03
editado por filiperoque às 23:20
link do post | comentar | adicionar aos favoritos |

Quinta-feira, 7 de Junho de 2012
#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!

 


tags: | |


Segunda-feira, 28 de Maio de 2012
#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.


tags: | | |


#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!


tags: | | |


Quinta-feira, 24 de Maio de 2012
#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.

 


tags: | | |


Sexta-feira, 18 de Maio de 2012
#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.

 

mapanavegaçao_vbeta

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:
 

BugsDescriçãoClassificaçãoCalendarização
Menu SuperiorSe 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 piscaElevadoAté ao dia 8 de Junho
Menu SuperiorDepois de selecionar uma das áreas do menu superior, não é possível regressar à anterior somente à seguinteElevadoAté ao dia 8 de Junho
KinectAjustar 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 fidelidadeElevadoAté ao dia 8 de Junho
KinectDefinir se o utilizador é destro ou esquerdino, pois apenas é possível utilizar a mão direitaBaixoAté ao dia 8 de Junho


BugsDescriçãoClassificaçãoCalendarização
Diferenciação dos POI'sQuando 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.ElevadoAté ao dia 8 de Junho
Feedback do sistemaQuando 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);

2. Ecrã inicial

2.1. Visitar o campus

Apresentação dos POIs

Seleção do POI

Seleção do ponto lúdico

 

2.2. Visitar Aveiro 

Apresentação dos POIs

Seleção do POI

Seleção do ponto lúdico

 

2.3. Ua antigamente 

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

Seleção de um ano

Seleção de um ano intermédio

 

3. Consola de opções 

  3.1. POIs

 

3.2. Pontos lúdicos

 

4. Inserir comentários das fotografias

 




#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.


tags: | | |


Quarta-feira, 16 de Maio de 2012
#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;


tags: | | | | |

publicado por filiperoque às 14:20
editado por joao-amorim em 18/05/2012 às 13:48
link do post | comentar | adicionar aos favoritos |

Segunda-feira, 14 de Maio de 2012
#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.


tags: | | | |


mais sobre nós

 

Junho 2012
Dom
Seg
Ter
Qua
Qui
Sex
Sab

1
2

3
4
5
6
7
8
9

10
11
12
14
15
16

17
18
19
20
21
22
23

24
25
26
27
28
29
30