– 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

No momento de Orientação Tutorial desta semana (terça-feira,25 Março), foram discutidas os diferentes perfis que o protótipo final do projecto pode/deverá assumir no momento de teste e apresentação, face à definição de três objectivos fundamentais a atingir nesse momento:

- Comunicação do Impacto Social da Aplicação NavLocator;

- Comunicação do Conceito base do projecto;

- Comunicação de todas as funcionalidades disponibilizadas na aplicação;

Partindo destes objectivos base, foi discutida a melhor forma de os transmitir, chegando-se à conclusão da necessidade de simulação de ambientes, para que se realize o teste à aplicação.

A estruturação da simulação será feita através da criação de um módulo especifico para o controlo de todas as variáveis do ambiente a simular. Este módulo pode ser operado numa máquina diferente da máquina-cliente.

Na máquina cliente estará instalada, apenas, a aplicação NavLocator . Qualquer utilizador que deseje testar o sistema necessita da criação de um registo pessoal e só posteriormente terá acesso ao sistema.

Assim que o login esteja efectuado, este utilizador terá acesso a todas as áreas principais da aplicação, que se pretende que sejam funcionais, na medida que exibirão os dados provenientes do ambiente de simulação, acumulados em server-side.

No que diz respeito à secção do mapa, esta permitirá a visualização dos vários utilizadores simulados.

A interacção com os utilizadores simulados deverá aproximar-se ao máximo de um ambiente real de viagem (existência de rotas, dados de telemetria e diário de bordo).

Em vésperas da apresentação, decidimos fazer um apanhado de tudo aquilo que foi realizado ao longo desta última semana, para a preparação de sexta feira.

As planificações técnicas em falta já foram realizadas, e as que já tinham sido exibidas na última aula de projecto, corrigidas. Haviam alguns aspectos técnicos que estavam em falta e esta semana foi a semana decisiva para os apontar e solucionar.

A interface foi também inteiramente revista, quer a nível gráfico quer a nível das formas de interacção.  Foram enviadas as interfaces para os senhores do design, que reviram vários aspectos e pormenores no grafismo que entretanto já foram revistos pelo grupo.

Após uma reunião com o orientador Ferraz de Abreu, apercebemo-nos de uma importante componente que ainda não tinha sido pensada devidamente: a questão das telecomunicações (entre a aplicação e o servidor). Dado que a aplicação será também utilizada por embarcações, onde a banda larga não abunda tanto como as estrelas do mar, é necessário ter esta situação em conta.

Desta forma, será necessário fazer um estudo da taxa de transmissão mínima necessária para assegurar um bom funcionamento da aplicação. Claro que, tal estudo poderá apenas ser simulado com credibilidade quando de facto existirem módulos funcionais – caso contrário, serão apenas suposições incorrectas.

O ideal seria a existência de um dispositivo que detectasse as ligações disponíveis no momento (satélite, 3G, GPRS, por aí fora) e se ligasse nesse preciso instante à ligação mais adequada, quer a nível de transmissão, quer a nível de custos. Esta detecção seria à partida feita através da filtragem de IP’s, e o utilizador nem se teria de preocupar com estas questões enquanto acedia à aplicação.

Estima-se que, para o envio de dados telemétricos para o servidor (posição, altitude, velocidades, etc), uma solução tipo InmarSat Mini C/ Mini D seja o suficiente. Para a restante utilização da aplicação, que não será propriamente leve, tudo dependerá da possibilidade de integração dos mapas localmente, ou da falta desta.

As soluções de mapas online actuais (GoogleMaps, YahooMaps, VirtualMap, etc) são óptimas e completíssimas, mas muito pesadas a nível de transmissão. Seria ideal conseguir alojar grande parte da informação destes mapas localmente (em disco), mas este é um processo controverso, complicado, e sem garantias. Mesmo assim, a mais valia que esta funcionalidade traria em termos de utilização, é merecedora de um estudo intensivo sobre a sua validação, pelo que ainda estamos a averiguar as possibilidades.

Todas estas questões surgiram recentemente, e, dada a sua natureza extensa, não houve hipótese de detalhar problemas/soluções na planificação actual. O grupo está no entanto plenamente ciente delas, e debate-se dia e noite 27 horas por dia na ultrapassagem destas limitações.

As duas primeiras semanas de desenvolvimento do projecto foram dominadas pela preocupação de definir quais os contextos de viagem a abranger no protótipo de alta fidelidade a obter como produto final.

Tendo em conta este objectivo, contactámos pessoas que desenvolvem viagens por lugares desconhecidos, utilizando diferentes meios de transporte.

Genuíno e Beatriz Madruga (navegação aquática) e Pedro Príncipe (traçamento de trilhos a pé e em bicicleta) foram as pessoas que prontamente se disponibilizaram para fornecer dados relativos às actividades em que participam .

O contacto com Paula Vizinho foi efectuado, tendo-se agendado um encontro com a navegadora para a próxima semana. Desde já, um terno agradecimento a todos.

Ontem, na reunião com o Prof. Ferraz de Abreu, e depois de feito o estudo de contextos de viagem passíveis de incluir na aplicação, foi decidido que o protótipo a implementar apenas contará com o contexto de viagem náutica, devido à enorme quantidade de trabalho que acarreta implementar a implementação tecnica de diferentes interfaces e funcionalidades, adequadas ao tipo de meio de transporte utilizado pelos viajantes.

Desta forma, a equipa NavLocator compromete-se a desenvolver horizontalmente diferentes contextos propostos (viagem de carro e viagem de mota) mas tecnicamente aprofundar um só ramo – as viagens de barco.

Ainda no encontro de ontem, o Prof. Ferraz chamou a atenção para a importância da conceptualização de todo o projecto e para a grande potencialidade de, paralelamente às fases de design, teste e implementação, se desenvolver pertinente material teórico, enquadrado por estudos recentes de temáticas relacionadas com” a relevância que a informação de presença tem na promoção de comunicação interpessoal e na partilha de conhecimento“. Relativamente a este tópico, encontram-se, na área de artigos de referência alguns dos documentos que estamos a analisar, fornecidos pelo professor-orientador.

O estado de arte relativo ao projecto NavLocator foi igualmente alvo de atenção: foram analisas empresas como Imahima e estudados casos com o homelocator ou o txtracks .O trabalho de investigação neste tópico continuará, agora com a ajuda da equipa Connetor, que amavelmente cedeu o estado de arte por si realizado.

Quanto à investigação técnica, nos últimos dias a investigação tem abrangido softwares tais como delphi borland, adobe flash cs3, adobe flex e adobe air. As possíveis linguagens a utilizar são actionscript , javasrcipt, mxml, sql e asp.

Mais detalhes nos próximos posts. Prometemos uma arquitectura de sistema inicial, logo após a publicação do ficheiro .xls com as específicações funcionais!

Sejam bem-vindos a este modesto blog, cujo objectivo pauta por ser o relato detalhado e actualizado do processo evolutivo do projecto NavLocator!

A equipa de trabalho integra quatro elementos, sendo eles Carla Ceia, Cristina Teixeira, Ricardo Pinto e Ricardo Magalhães.

Margarida Almeida e Jorge Ferraz de Abreu coordenam a equipa e o desenvolvimento de todo o trabalho.

Os objectivos do projecto deliniam a construção de um software social, aliado ao sistema de geoposicionamento global (GPS) que permitirá a viajantes, solitários ou em grupo, estabelecer contacto com outros indivíduos, trocando experiências e informações relativas às viagens.

A partilha de informações tem uma utilidade lúdica - uma vez que os utilizadores poderão partilhar dados relativos a pontos de interesse turístico – mas também utilidade funcional, pois poderá contribuir para optimizar a navegação de viagem, sendo que os utilizadores do NavLocator poderão trocar informações relativas a condições atmosféricas, zonas de perigo, característica geológicas de determinados locais.

Em suma, qualquer informação que um determinado utilizador necessite numa situação específica é passivel de ser obtida através do Navlocator, utilizando a informação armazenada no sistema ou contacto com outros utilizadores (directo, através de instant messaging ou indirecto, através de participação no diário de bordo de cada navegador).

Num sentido lato, o objectivo primário do projecto será construir uma plataforma de comunicação entre utilizadores em contexto de viagem, tendo por base as permissas da web 2.0, uma vez que todo o sistema está delineado de forma a crescer com a partilha de experiências de cada utilizador.