Nesta última semana, o grupo NavLocator teve a oportunidade de confrontar os módulos da aplicação até agora desenvolvidos com navegadores experientes, de diferentes perfis.

O maior Intuito da experiência foi fundamentalmente perceber se as funcionalidades existentes na aplicação correspondiam às necessidades sentidas por uma equipa de navegadores, numa viagem de longa duração.

Foi possível ainda avaliar o grau de usabilidade da interface construída, pelo registo de todas as dificuldades encontradas e erros dos utilizadores.

A equipa dá assim por encerrada a fase de testes de usabilidade, continuando ainda os testes de funcionalidade, segurança, compatibilidade e desing. Tal facto deve-se ao constante desenvolvimento que a apalicação sofre, nesta fase de grande produção técnica.

A avaliação heurística agendada para a passada quarta-feira não pode realizar-se, pelo que acontecerá nos próximos dias.

Relativamente aos testes efectuados, todas as grelhas de registo e dados obtidos serão publicados, após o tratamento da informação recolhida através de registo directo e gravação áudio.

Aqui fica a agenda de testes, cumprida na última semana:

Ana Silva – 3ª feira, às 18h00m no DECA
Rui Vasco – 6ª feira, às 10h no DECA
Óscar Mealha – 6ª feira, às 11h30m no DECA
Pedro Pinto Correia e Paula Vizinho – 6ª feira, às 14.30m no DECA

E o mapa já mexe, com direito a waypoints. Há algumas semanas atrás já tinhamos mostrado, nas aulas de projecto, um protótipo do protótipo (há que ser técnico) de como iria funcionar o simulador de GPS, já com um marcador de posição a mexer-se em direcção ao seu destino.

Tal como previsto, o utilizador poderá adicionar waypoints, isto é, passagens intermediárias, antes de chegar ao seu destino. Esta introdução passou de uma algo confusa introdução à mão no XML, para uma introdução gráfica.

O módulo que faz com que os utilizadores se movam, em tempo real, (o programa em JAVA), não pode ser chamado directamente através do Flex, necessitando ainda de ser executado à mão. Para o protótipo este facto não é preocupante, na medida em que pode ser criado um atalho que corra simultaneamente a aplicação NavLocator e o simulador em JAVA.

No vídeo exemplificativo abaixo, podem ver a simulação em acção. O marcador de posição pára em cima do Waypoint 1, e posteriormente avançará para os seguintes.

Estamos a caminho…

Como prometido ontem, vamos mostrar aquilo que já temos em cada módulo. De notar que ainda nenhum deles está 100% completo, quer a nível de design quer a nível de funcionalidades, mas já representam uma versão aproximada daquilo que virão a ser.

Menu de Login

A título de exemplo, o menu de login contempla dois utilizadores. Á medida que estes são adicionados na base de dados e o utilizador efectua login, é criado um ficheiro XML no disco que guarda a sua informação para acesso rápido. Um vídeo da animação está exemplificado abaixo.

Menu principal

Interacção principal que dá acesso a todas as outras áreas. Existem eventos simples de rollover e rollout. O design mostrado aqui não é o final; actualmente este já conta com reflexos dinâmicos que também sofrem os efeitos como os ícones. O vídeo abaixo serve de exemplo ao tipo de interacção que o menu possui:

Diário de Bordo

Exemplo da visualização do diário de bordo de um utilizador. Os posts, listados por nome e data, podem ser clicados e a mensagem associada é imediatamente exibida em baixo para leitura. Como as entradas no diário têm sempre associadas as coordenadas actuais do utilizador, o mapa é actualizado automaticamente para a localização onde o utilizador escreveu a mesma entrada.

A qualquer altura, este pode escrever uma nova entrada, abrindo uma nova janela com as informações necessárias. Neste momento, todos estes dados estão a ser carregados/inseridos na base de dados.

Um exemplo do diário em acção:

Janelas de Interface

Uma das premissas iniciais do projecto era providenciar ao utilizador liberdade com a sua própria interface, podendo redimensionar, mover, fechar, e até minimizar as suas janelas. Após uma duríssima luta com o Flex, o grupo já conseguiu implementar esta funcionalidade.

Uma aplicação de exemplo, que pode ser testada directamente, está disponível aqui! (a distorção da imagem de fundo é normal aqui no browser)

Perfil

A zona de perfil ainda está muito crua a nível de design, mas as informações básicas quer sobre o utilizador quer sobre a embarcação já estão disponíveis para visualização. Apostamos que poucos sabiam que o Chuck Norris era madeirense.

Mapa

A principal componente de toda a aplicação. Com o GPS a debitar informação simulada, é já possível ter um marcador no mapa a mexer-se em direcção ao seu destino, passando pelos destinos intermédios definidos. Um exemplo deste componente será publicado mais tarde, assim que for optimizado ao longo do dia de hoje.

No decorrer destas últimas duas semanas, e apesar de muito trabalho ter sido desenvolvido, a equipa não procedeu à actualização do blog devido ao facto de o tempo ter sido empregue no conhecimento das (novas) ferramentas de trabalho.

Após um longo período de desenvolvimento de documentos teóricos e respectiva investigação (módulo 1), a equipa sentiu a necessidade de se concentrar totalmente na exploração e domínio das funcionalidades do Flex, permitindo a integração de todos os conteúdos já produzidos nessa ferramenta.

Outra das razões pelas quais não foram feitas actualizações no blog deve-se ao facto das aulas de projecto e reuniões com orientadores serem de carácter meramente demonstrativo de todo o trabalho desenvolvido para protótipo, não havendo novas tomadas de decisão ou qualquer alteração às directrizes delineadas anteriormente.

Em suma, a equipa esteve estas duas semanas em total “modus operandis”.

Nestas duas semanas, a integração da interface em diferentes módulos de Flex revelou-se problemática, na medida em que o formato das imagens escolhido (.svg) apresentou problemas em suportar transparências definidas em Adobe Illustrator.

A solução encontrada passa por importar todos os gráficos para o Flex em formato .swf, o que no entanto, não é totalmente satisfatório, pois as imagens nao apresentam a qualidade esperada.

Relativamente à arquitectura do projecto, a estruturação deste baseia-se numa organização por módulos, isto é, na aplicação principal existirá um módulo principal (navlocator.mxml) que carregará os outros cinco módulos correspondentes a cada área de interacção (perfil, mapa, diário de bordo, definições, e viagens).
Por uma questão de organização, a equipa decidiu separar o código funcional do código gráfico, sendo que para cada mxml existe um ficheiro externo de Action Script que contém toda a programação necessária a esse módulo.

Desta forma, o grupo poderá trabalhar em gráficos e programação separadamente, sem que exista qualquer conflito entre estas duas componentes na altura de reunião de ficheiros.

Relativamente à apresentação de 22 de Abril, o grupo terá desenvolvido os seguintes módulos:

- módulo de Menu Inicial

- navegação básica (animada) da aplicação

- modulo de simulação de Gps

- simulação de dados de geo-posicionamento (em tempo real)
- definição de rotas
- simulação de dados de telemetria

- módulo de Diário de Bordo

- visualização de posts dos blogs/diários de bordo
- possibilidade de escrita de novos posts

- módulo de Mapa

– módulo de Perfil

- visualização de perfis completos (dados pessoais e avatares)

O grupo tem consciência que os objectivos de prototipagem definidos anteriormente não serão totalmente atingidos (passando estes pela construção de todas as funcionalidades do módulo do mapa à excepção da pesquisa), no entanto essa impossibilidade é justificada pelo surgimento do módulo de simulação de GPS, que necessitou de ser desenhado e programado de raíz e que consumiu uma considerável quantidade de tempo .

Os contratempos naturais que existem no confronto com uma nova ferramenta de trabalho estão igualmente a consumir tempo útil.

Amanhã, e em jeito de desculpa pela falta de actualizações neste blog, serão colocadas imagens, excertos de código e exemplos funcionais da aplicação NavLocator. Sim, porque estivemos realmente a trabalhar!

Durante a madrugada de terça feira, será disponibilizada a versão de protótipo em extensão AIR, antes da apresentação.

Até amanhã,

O grupo NavLocator

Deixamos aqui também os novos ícones a utilizar na interface final. A restante simbologia ainda está a ser desenvolvida (vectorialmente, claro está) pelo que serão aqui adicionados assim que estiverem finalizados.

Apesar do modelo da base de dados ter sido anteriormente apresentado em Access, já foi especificado que esta será implementada em MySQL, que comunicará com a aplicação via PHP.  A base de dados está actualmente a ser testada, de modo a verificar-se “à prova de erros” num ambiente de utilização real.

A mesma já foi convertida, para efeitos de teste e simulação, para MySQL. Está actualmente implementada localmente, à espera que cheguem os novos servidores para ser posteriormente copiada e alojada no seu destino final.

A prova, está no phpMyadmin!:

A comunicação do Flex com a BD também está assegurada; este executa os scripts de PHP (que contêm as queries), que geram resultados em XML e são interpretados pela aplicação. Exemplo de uma aplicação que retorna dados (ainda fictícios) a partir da base de dados:

E fica também o script PHP que torna esta comunicação possível;

Agora é apenas uma questão de adaptar estes novos ricos e fantásticos conhecimentos à mui nobre e cuidada interface, e tudo seguirá para bom porto!

No último post, explicitou-se a necessidade de utilização de um simulador de dados GPS para alimentar um ambiente de utilização fictícia. Como tal, iniciou-se o desenvolvimento de uma aplicação em Java (seguindo a lógica e conceito multi-plataforma) que fosse responsável por ler a rota definida e recalcular a posição do utilizador à medida que percorre essa mesma rota.

Sendo assim, a estrutura criada baseia-se no seguinte:

- Ficheiro XML, de nome “telemetria.xml”, que contém informação das coordenadas actuais, bem como da rota definida, velocidade e hora universal. A estrutura deste xml consiste em:

- Classe em JAVA, responsável por fazer variar as coordenadas actuais do dispositivo GPS simulado, de acordo com a rota definida. Esse mesmo ficheiro é responsável por registar as novas informações de dados no ficheiro “telemetria.xml”, substituindo as existentes. Deste modo o programa poderá sincronizar essa mesma informação com o ficheiro de mesmo nome em server-side, em intervalos que podem ser definidos pelo próprio utilizador.

Aqui fica o desenho da base de dados, já com as relações desenhadas, actualmente estruturada em Access. Após novas verificações quanto à consistência das tabelas e respectivas relações, esta será implementada em MySQL.O grupo já fez avanços no estudo sobre implementação de bases de dados em MySQL e sua integração com PHP. Eis alguns sites de investigação que servem de apoio:

MySQL — http://www.tizag.com/mysqlTutorial/

MySQL & PHP — http://www.w3schools.com/php/php_mysql_intro.asp

Modelo físico da BD

Dada a necessidade de criar um ambiente que possibilite a explicação perfeita de todo o conceito do NavLocator, foram pensados módulos de simulação integrados na aplicação, que permitem atingir o objectivo anteriormente descrito.

Segue-se a contextualização destes módulos de simulação;

- Simulador de dados GPS

Criação de uma aplicação independente da aplicação NavLocator, simuladora da comunicação entre dispositivo de GPS
e computador, calculando as coordenadas e registando-as num ficheiro XML, que será lido em Flex, que será posteriormente sincronizado num ficheiro de telemetria em XML no servidor.

O grupo encontra-se ainda a estrutura o modo de funcionamento (e respectivo fluxograma) deste simulador, pelo que a sua estruturação será aqui postada assim que concluída.

- Simulador de utilizadores e embarcações

Os administradores têm a possibilidade de adicionar utilizadores fictícios ao sistema NavLocator, com todos os dados inerentes a um perfil de embarcação, de utilizador e de viagem, aproximando-se do ambiente real no qual a aplicação NavLocator seria utilizada.

Estes utilizadores, ainda que não-reais, comportar-se-ão como verdadeiros utilizadores, isto é, serão dotados de uma “inteligência artificial” capaz de providenciar comportamentos semelhantes aos que um outro utilizador real providenciaria.

O intuito deste ambiente simulado é fornecer aos utilizadores uma experiência interactiva com outros utilizadores , que de outra forma não seria possível visto que não iriam existir registos no sistema.

Em anexo fica o documento da localização dos módulos de simulação no modelo de arquitectura de sistema.
Apresentamos ainda o mapa de navegação com a identificação das zonas que serão alimentadas pelos dados fictícios dos simuladores.

Os fluxogramas da simulação de utilizadores/embarcações estão disponíveis nos respectivos módulos de login, inserção de utilizadores fictícios, e eliminação dos mesmos.

– PROTOTIPO 22 ABRIL –
– CARACTERÍSTICAS SEGUNDO STRAUSS –

1) Tipologia do Protótipo (forma de evolução)

> Reutilizável e modular: os módulos do protótipo a apresentar no dia 22 de abril são as primeiras versões desses componentes na aplicação final. Para esta apresentação, não estão contemplados todos os módulos, pelo que componentes adicionais serão acrescentados posteriormente à medida que forem testados (secção de “viagens” e secção de “definições”).

2) Nível de detalhe/profundidade do protótipo

> Prototipagem em T: serão prototipados alguns módulos principais (camada horizontal), e algumas secções dentro de cada um destes módulos (camada vertical). No caso específico do NavLocator, a prototipagem vertical incidirá especificamente nos módulos do Mapa e do Perfil de Utilizador. Os restantes módulos, Diário de Bordo, Viagens e Definições, serão prototipados horizontalmente.

Secção Mapa: Prototipagem Vertical

– Secção de FAVORITOS
– Visualização de POI’s
– Inserção de POI’s

– Visualização de utilizadores no mapa (em tempo real)

Secção Perfil: Prototipagem Vertical

– Inserção de dados pessoais
3) Nível de aproximação final

> Prototipagem High-Fidelity: as tecnologias utilizadas no protótipo serão o mais semelhantes possível às utilizadas na versão final, isto é, o código dos módulos prototipados será reutilizado e melhorado posteriormente.

mapa de prototipagem