pesquisar neste blog
posts recentes

O motor da aplicação

Mód. TP6 – Testes

Mód. TP6 – Versão Beta

"Não descansaremos enquanto não pusermos o virtUA a crescer"

#1 BASTIDORES: Criação do Pavilhão I

Testes ao projecto Virtua

Jardinagem virtual: Luta contra os bugs!

Informações sobre versão Beta de Virtua

Mód. TP5 – Prototipagem de alta fidelidade (2/2)

Mód. TP5 – Prototipagem de alta fidelidade (1/2)

arquivos

Junho 2011

Maio 2011

Abril 2011

Março 2011

Fevereiro 2011

Quarta-feira, 15 de Junho de 2011
O motor da aplicação

 

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.

 
 
 
-
 
 Fig. 3, 4 e 5 - Script e Propriedades do RayCast Collider
 

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.

 
  Fig. 6 - Área do Projecto
 

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.

  Fig. 8 - Objectos da cena
 

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.php?title=Head_First_into_Unity_with_JavaScript 

http://forum.unity3d.com/threads/34015-Newbie-guide-to-Unity-Javascript-(long) 

http://answers.unity3d.com/questions/8329/how-to-get-started-learning-javascript-or-unityscr.html



tags: , ,

publicado por palexandre às 12:49

editado por lilianavale às 12:57

Quinta-feira, 9 de Junho de 2011
Mód. TP6 – Testes

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:

 

Open publication - Free publishing - More 3d

 

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:

 

Open publication - Free publishing - More uarhere

 

 

Open publication - Free publishing - More uarhrere

 

 

Open publication - Free publishing - More uarhere

 


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.


tags: , , ,

publicado por pedro-charneca às 23:16

Terça-feira, 7 de Junho de 2011
Mód. TP6 – Versão Beta

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.

 

 

Open publication - Free publishing - More 3d

tags: , ,

publicado por lilianavale às 18:41

Segunda-feira, 6 de Junho de 2011
"Não descansaremos enquanto não pusermos o virtUA a crescer"

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.


"Vai ser difícil, mas vai valer a pena. Eu sei que vai valer a pena"

tags: , , , ,

publicado por lilianavale às 00:55

Sábado, 4 de Junho de 2011
#1 BASTIDORES: Criação do Pavilhão I

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 


tags: , , , ,

publicado por lilianavale às 22:40

Terça-feira, 31 de Maio de 2011
Testes ao projecto Virtua

 

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


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

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


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.

  

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

 

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

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:

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?

 

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.

 


tags: , , , ,

publicado por lilianavale às 12:44

Sexta-feira, 27 de Maio de 2011
Jardinagem virtual: Luta contra os bugs!

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: 

 

tabela_bugs-v2.pdf

 

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.

 

suporte_codeUA.pdf

funcionalidade_codeUA.pdf

bugs_code_ua.pdf


 


tags: , , ,

publicado por lilianavale às 23:58

Informações sobre versão Beta de Virtua

 

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: 

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

A equipa procederá à continuação do desenvolvimento da área de ajuda, já começado anteriormente. Os resultados dos testes também serão muito importantes para a concepção e desenvolvimento desta área.

 

Ecrã Opções

Proceder-se-á, também à continuação e finalização do trabalho implementado na fase anterior, sendo de destacar a resolução de bugs e melhoria da eficácia, bem como a criação de um nível de "qualidade gráfica" mais adequado para computadores com maiores limitações a nível gráfico ou de processamento. 

 

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.


tags: ,

publicado por lilianavale às 21:45

Sexta-feira, 20 de Maio de 2011
Mód. TP5 – Prototipagem de alta fidelidade (2/2)
Open publication - Free publishing - More 3d

tags: ,

publicado por lilianavale às 22:51

editado por pedro-charneca em 23/05/2011 às 14:25

Mód. TP5 – Prototipagem de alta fidelidade (1/2)

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:

 


tags: ,

publicado por lilianavale às 22:37


pesquisar neste blog
mais sobre mim

goncalvessilva

lilianavale

palexandre

pedro-charneca

Junho 2011
Dom
Seg
Ter
Qua
Qui
Sex
Sab

1
2
3
4

5
6
7
8
9
10
11

12
13
14
16
17
18

19
20
21
22
23
24
25

26
27
28
29
30


arquivos

Junho 2011

Maio 2011

Abril 2011

Março 2011

Fevereiro 2011

tags

todas as tags

subscrever feeds

RSSPosts

RSSComentários

posts recentes

O motor da aplicação

Mód. TP6 – Testes

Mód. TP6 – Versão Beta

"Não descansaremos enquanto não pusermos o virtUA a crescer"

#1 BASTIDORES: Criação do Pavilhão I

Testes ao projecto Virtua

Jardinagem virtual: Luta contra os bugs!

Informações sobre versão Beta de Virtua

Mód. TP5 – Prototipagem de alta fidelidade (2/2)

Mód. TP5 – Prototipagem de alta fidelidade (1/2)