A Linguagem de programação que serve como suporte e cria a estrutura lógica de navegação e interação na aplicação e que está a ser desenvolvida é o Javascript. É uma das três linguagens usadas pela ferramenta UNITY3D - já amplamente discutida neste blog -, a par do C# e BOO.
Na realidade, apesar do Javascript do Unity ser bastante parecido com o standard ECMAScript, utilizado nas páginas web, tem algumas diferenças substanciais. Devido a essas diferenças, há quem nomeie de outra forma esta linguagem: UnityScript. De facto, ela é bastante parecida com o JScript da Microsoft, especialmente porque são ambas linguagens .NET.
Ao invés do irmão mais velho e mais conhecido (JS), o UnityScript é compilado e não interpretado. Além disso não tem a trabalhar consigo o DOM (ufa!). Contudo, perde um pouco no dinamismo que a versão para browser tem.
Os objetos existentes na scene de uma aplicação criada nesta ferramenta, podem ser muito diversos, desde câmaras, luzes, objetos modelados em 3D, entre outros - denominados GameObjects. A esses GameObjects podem ser acrescentados Components que podem introduzir imensas possibilidades de comportamento aos mesmos. Um Component pode ser um detetor de colisões, uma textura, e, entre outros, pode ser um script.
Fig.1 e 2 - Acesso ao GameObject e às componentes no Unity
Desta forma, cada GameObject pode ter vários scripts (ficheiros JS), pelo que é importante implementar os scripts de forma modular, tendo a ganhar com isso a flexibilidade de uso.
No caso da aplicação virtUA, damos o exemplo do script criado chamado Raycast_Collider, que trata, entre muitas coisas, da alteração do estado da mira que aparece no centro da interface.
Na imagem que se segue, consegue-se ter uma ideia da quantidade de ficheiros JS que se criaram para se obter os resultados da conseguidos na implementação. Nem todos estes ficheiros foram criados na integra pelo grupo, dado que algumas das interações base já vem criadas de raiz em ficheiros JS disponibilizados (como o caso da ligação dos movimentos do rato e teclado ao GameObject que serve como câmara) mas mesmo esses precisam de ajustamentos, conforme o tipo de aplicação criada. Neste tópico é também necessário dar um realce à imensa comunidade de utilizadores desta plataforma, que é extremamente colaborativa, apresentando respostas a quase todo o tipo de problemas que se apresentaram ao grupo.
Uma das últimas implementações no projeto foi a criação de uma galeria de fotos no próprio Campus. Esta galeria de fotos encontra-se "invisível", ou não renderizada, por defeito. Para fazer aparecer a galeria faz-se uso de outro objeto escondido (que é uma simples caixa), presente ao redor do "i" gigante que se vê a rodar (rotação constante originada por programação) no campus. Podemos verificar que essa caixa (GameObject) tem o "is_trigger" ativo, tem acoplada um script "i_abre_galerias (script)", e tem o "Mesh_renderer" desativo.
O "is_trigger" vai despoletar um efeito (neste caso passa uma variável boleana de falso para verdadeiro) em caso de colisão. O script apresentado é o que vai conter essa variável e todo o código para fazer aparecer (render) o outro objeto (as imagens em si) representado na variável "Obj_galerias".
Fig. 7 - Script e activação da opção isTigger
Esta linguagem de programação conta já com uma função para ajudar nestes casos de colisão. OnTriggerEnter é usado para quando se dá a colisão em si, e OnTriggerExit quando a mesma colisão deixou de acontecer. Neste caso concreto, quando o player entra em colisão com o objeto que tem anexado este script, faz aparecer o objeto que está ligado à variável "Obj_galerias": "i_placard_galerias_pav1". Este último contém as fotos do respectivo edifício. Para já as fotos estão integradas diretamente na aplicaçao (fazem parte da compilação). Para a implementação final vai-se proceder ao uso de scripts que permitam obter as fotos diretamente do website. Fotos essas que serão colocadas pelos administradores assim como por qualquer utilizador registado e que queira partilhar com a comunidade.
Para se poder navegar por entre as diversas fotos de cada edifício, faz-se novamente uso do script "raycast_collider". Está criada uma função própria para alterar a mira da interface e responder aos inputs do teclado (teclas Q e E), alterando a posição do Array criado para a listagem das fotografias.
Fig. 9 - Script relativo à activação das teclas para mudar de fotografias
Bibliografia:
http://www.unifycommunity.com/wiki/index.p
http://forum.unity3d.com/threads/34015-N
http://answers.unity3d.com/questions/832
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 a preocupação em termos de testes de usabilidade, acessibilidade, funcionalidade, conteúdos e design sejam fundamentais.
Face a esta realidade, segue-se o documento de suporte à fase de testes do projecto:
Dado que o teste de usabilidade subdividiu-se em três fases: pré-teste, teste e pós-teste. Seguem-se os diferentes instrumentos de recolha de dados:
Reflexão - os próximos passos:
Com base na análise do documento, o grupo virtUA chegou, rapidamente, à conclusão que ainda falta reunir esforços de modo a tornar o projecto, em todas as suas componentes, user-friendly.
Todo o grupo tinha a expectativa de estar, nesta altura, um passo mais à frente, e poder, até à dia da entrega, estar mais concentrado no desenvolvimento de conteúdos da aplicação: reconstrução de ambientes tri-dimensionais, podendo dessa forma atingir o maior número de períodos possível. Infelizmente, esse objectivo não será possível, dada a quantidade de alterações / atualizações necessárias a fazer para melhorar o programa, de forma a ser uma experiência intuitiva e satisfatória para o utilizador final.
Frisamos então, o compromisso tido desde a primeira hora do projecto - e que está estampado nos valores da organização - manter a qualidade acima tudo. Reiteramos esse compromisso junto de todos os stakeholders que mantêm este projecto. O nosso focus para a entrega final será, acima de tudo, em criar sistemas de ajuda ao utilizador tanto para o módulo website como para o módulo da aplicação virtual. Dentro de poucos dias divulgaremos todos esses sistemas a criar e como irão interagir no projecto. Fica desde já revelado que, dado o que já foi referido anteriormente, serão poucas as implementações novas a realizar (infelizmente), mas muitas implementações de background, talvez mais morosas e complicadas, que garantem uma máquina rápida e eficaz, sempre centrada no utilizador.
Aproveitamos para deixar uma palavra de agradecimentos a todos aqueles que nos ajudaram a realizar os testes, em especial aos beta-testers: pela sua paciência, críticas e sugestões apresentadas que, certamente, irão enriquecer o nosso produto não só ao nível da métrica de usabilidade mas também no rigor dos conteúdos.
A versão beta corresponde ao momento em que a equipa efectua uma revisão completa do design da aplicação multimédia. É neste momento que também se procede à versão final do design da aplicação e ao seu "congelamento " (Strauss, 1997). Deste modo, a versão beta pode ser consultada em: virtua.campusitv.com, servindo o presente documento de seu suporte.
Na sequência do post “Testes ao projecto virtUA”, criou-se um esquema de recolha e análise de dados, tendo em conta a divisão por equipa e a intervenção de um responsável.
Fig.1 - Esquema de testes - Equipa virtUA
Assim, para cada teste, há um elemento responsável pela coordenação do teste e a intervenção e divisão dos elementos do grupo. É de referir que os testes de usabilidade foram adiados para esta 2ª feira (4 utilizadores) e 4ª feira (2 utilizadores), de acordo com a disponibilidade dos recursos humanos do Arquivo, CEMED e DeCA.
Os teste de conteúdo irão concretizar-se em paralelo com o teste de usabilidade de forma a verificar dados históricos e proceder à validação da informação.
No que concerne, os testes de acessibilidade, já se constatou segundo o Web Accessibility Inspector, os erros do website, faltando efectuar uma reflexão e prodecimentos a tomar visando a melhoria do mesmo , junto dos professores-orientadores e da reunião – última OT com a Prof. Margarida Almeida.
É de referir que a monitorização das tarefas, passou a ser feita no CODE.UA, a equipa encontra-se a resolver os bugs detectados no protótipo de alta-fidelidade e a progredir em termos de desenvolvimento do mapa de navegação. O GANTT encontra-se em constante actualização, faltando, ainda, marcar uma reunião milestone, perto da entrega, a fim de analisar e tomar decisões face aos testes efectuados.
O Pavilhão I foi o primeiro edificio a localizar-se no Campus de Santiago. Concebido por uma Comissão Instaladora em 1974, em 29 de Novembro de 1976 é construido o pré-fabricado que albergaria os cursos de Biologia, Geociências. Cerâmica e Vidro, Ciências da Educação, Matemática e Biblioteca Geral.
Este período marca o inicio da era em que a Universidade começa a ter instalações próprias. O que se pensava ser uma solução provisoria, passou nos dias de hoje, uma construção definitiva, onde funciona actualmente o grupo UNAVE, CEMED e a Incubadora de Empresas da UA.
A criação do Pavilhão I atravessou diferentes fases:
Visita ao edifício, recolha e registo fotográfico
Fig.1 - Recolha de imagens do Pav.I
Recolha da planta e organização das layers
A modelação do edificio partiu da digitalização da planta cedida pelo gabinete dos técnicos e de arquitectura da Universidade de Aveiro
Modelação de objectos e Composição
Fig.2 - Vista aérea do Pav.I - modelação
Fig.3 - Vista lateral do Pav.I - modelação
Fig.4 - Vista lateral do Pav.I - modelação
Texturização
A texturização do Pavilhão I foi feito com recurso a fotografias e ao controlo do mapeamento através de Photoshop e 3ds Max. A textura da parede do pavilhão, ainda sofreu o efeito bump para dar saliência e cada janela foi alvo da extracção booleana (Boolean).
Importação para o Unity e criação da envolvente
A importação para o Unity passou pela localização do ficheiro de 3ds max e respectivos materiais para a pasta assets. Por uma questão de formalidade e maior facilidade na importação de materiais, as próximas importações serão feitas através do formato .fbx.
A criação da envolvente foi feita no Unity através da utilização de librarias (árvores, arbustos, etc) e a aplicação do relvado sobre o terreno.
Fig.5 - Envolvente
Fig.6 - Envolvente
Fig.7- Envolvente
Fig.8 - Envolvente
Aquando o desenvolvimento do projecto multimédia, o grupo virtUA irá concretizar testes de avaliação da aplicação em termos de usabilidade, funcionalidade, compatibilidade e acessibilidade.
Teste de usabilidade
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, desempenham as funções que seriam de esperar.
2. Funcionalidades testadas
Fig.1 - Módulos a testar no teste de usabilidade
Segundo a norma ISSO 9241-11, a usabilidade é a extensão na qual os utilizadores pertencentes a um determinado público-alvo atingem 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:
Fig.2 - Medição da métrica de usabilidade
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 desde a década de 80. O género não é fundamental para este estudo, porém, tentar-se-á que seja equilibrado (3 pessoas do género feminino e 3 do género masculino, por exemplo).
4. Contexto de teste
O teste será realizado num ambiente controlado em laboratório, no Deca. Trata-se 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.
5. 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.
6. 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
3. Escala Likert: (1=pouco, 5= plenamente satisfeito)
7. 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;
8. 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.
Teste de funcionalidade
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.
3. 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.
Teste de compatibilidade
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.
Teste de conteúdos
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).
Teste de acessibilidade
- 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.
Porque é que não há teste de design e de segurança?
A equipa procedeu, também, a uma revisão de erros/bugs presentes na prototipagem de alta-fidelidade. É nesta fase que se inicia o processo de comparação do desenvolvimento com o escalonamento original de actividades.
Assim, eis que se segue a grelha com a lista de alguns bugs encontrados na aplicação:
Estes encontram-se categorizados entre Programação, Conteúdo e Design e são classificados consoante a sua prioridade. É de referir que o grupo acabou por actualizar a listagem de actividades para o CODE.UA e seguem-se as tabelas de suporte, funcionalidade e de resolução de bugs.
A versão beta corresponde ao momento em que a equipa efectua uma revisão completa do design da aplicação multimédia. É neste momento que também se procede à versão final do design da aplicação multimédia e ao "congelamento do design" (Strauss, 1997).
Deste modo, segue-se a actualização do mapa de navegação em que é assinalado as áreas e módulos a desenvolver nesta fase:
Fig.1 - Mapa de navegação, enquadrado na versão BETA
A implementar
Galeria (página do website)
A página Galeria será implementada com completude ao nível dos conteúdos e interacção.
Implementação parcial
Ajuda
O ecrã ajuda não irá ser implementado totalmente. No entanto sofrerá algumas atualizações resultantes dos testes a executar durante esta fase. Acresce-se o facto que é nesta fase do desenvolvimento da versão Beta que se inicia todo o processo de documentação e suporte ao utilizador.
Navegação
Nesta fase o objectivo primordial é terminar o período 1, a saber:
- Edifícios totalmente modelados e texturizados;
- Ambiente e áreas limites dos 3 edifícios com mais detalhe.
Também se pretende melhorar a perfomance da navegação do utilizador no campus, tendo como base os testes a realizar junto dos utilizadores.
A implementar totalmente (Alvo de implementação parcial na Prototipagem de alta-fidelidade)
Ecrã Ajuda
Ecrã Opções
Ecrã Info (edificios)
O ecrã de informação (edificios) sofrerá ajustes gráficos e técnicos finais para melhoria estética desta área.
Ecrã Galeria
A criação e implementação do sistema visa despoletar das fotografias no próprio campus virtual. Todos os edifícios terão uma pequena zona, que ao ser acedida pelo utilizador, o mesmo poderá consultar as fotografias sobre o edifício em questão.
Ecrã Mapa
Esta área permitirá ao utilizador saber onde está espacialmente no campus. A mesma será totalmente implementada.
Outros ecrãs
Na fase anterior, algumas áreas não tiveram o cuidado gráfico desejado, algo que será tido em conta nesta versão. Dessa forma, muitos dos menus da aplicação serão modificados graficamente, tendo cuidados estéticos e de usabilidade.
Sem implementação
Visita Guiada
A visita guiada não irá ser implementada nesta fase dado que a aplicação de navegação virtual ainda se encontra em fase de desenvolvimento e não seria possível fazer uma demonstração de toda a potencialidade do projecto.
Apresentamos o documento e respectivos materiais que constituem a entrega do módulo TP5. É de referir que esta fase de implementação aumenta a sensação de realização por parte da equipa, assumindo uma importância crucial no desenvolvimento de vários módulos em paralelo, restrição da ocorrência de erros de programação/ autoria a cada módulo e a realização de testes à aplicação no inicio do desenvolvimento e rentabilização do código.
Assim, para além do link que serve de suporte à aplicação e que faz parte da prototipagem final (aconselha-se o visionamento através do browser firefox), serve o seguinte documento como apoio e ponto da situação do projecto.
Para experimentar o protótipo da melhor maneira, aconselha-se as seguintes acções:
- Inserção do url: http://virtua.campusitv.com/ (Com preferência no Firefox);
- Na página principal, clicar no botão login e efectuar login com ligação directa a um dos diferentes serviços apresentados;
- Clicar no menu Sobre – Sobre Projecto, Visão e Missão e Sobre Equipa;
- Em Campus – Visita Virtual, Clicar num dos períodos da navegação e na imagem, clicar sobre Iniciar Visita Virtual;
- No ecrã inicial, clicar no Ponto sobre o mapa Entrada Norte;
- Clicar no atalho V para alternar entre som On e Off;
- Clicar no atalho O para aceder ao menu Opções;
- Alterar os valores da slider do volume da aplicação e qualidade de gráficos e verificar as alterações na aplicação;
- Clicar no atalho F para efectuar fullscreen da aplicação;
- Clicar no atalho H para aceder ao menu de ajuda;
- Voltar à aplicação e navegar através das teclas de direcção aswd ou cima, baixo, esquerda e direita;
- Mover o cursor e acertar a mira no Edifício Pavilhão I;
- Alterar o período de visualização através do clique no link Navegar neste período;
- Verificar que os submenus do menu Campus – visita guiada e galerias estão em desenvolvimento;
- Em Campus Memórias, ler os diferentes posts inseridos, fazer like aos posts e ao grupo virtUA;
- Se efectuou login, pode inserir um novo post ou comentários;
- Se não efectuou login, pode verificar que não dá para realizar o passo 16;
- Em Campus – Evolução Histórica, pode verificar a integração do Dipity;
- No menu Ajuda, encontra-se presente diferentes perguntas e respostas do projecto, com links auxiliares para diferentes páginas (É de referir que esta página ainda se encontra em desenvolvimento);
- Em Contactos, poderá enviar um e-mail à equipa com sugestões;
