Nesta entrega, as reflexões finais serão feitas de uma forma diferente do que tem sido habitual, pelo cariz especifico do documento entregue.
O grupo optou por um sistema de Q&A (pergunta e resposta) para explicar clara e detalhamente todas as opções tidas em conta
Este sistema também se apresenta ideal para este tipo de entrega em formato blog, pelo facto de permitir uma maior interacção com os seus leitores. Desta forma, caso o leitor não esteja totalmente satisfeito, ou tenha alguma dúvida/questão acerca do projecto, poderá aproveitar este espaço para colocar essas mesmas questões.
Sendo este um projecto em desenvolvimento tem, sem qualquer dúvida, as suas lacunas e imperfeições, pelo que sugestões ou críticas serão extremamente bem-vindas.
Q&A (perguntas e respostas)
· Após a criação da aplicação, esta é exportada (encapsulada) e colocada na página para ser lida, assim como um ficheiro flash (SWF). Após a instalação do player unity3D, ele irá reconhecer todo o conteúdo.
· Embora a aplicação esteja preparada para receber conteúdo externo, sempre que forem necessárias alterações de fundo na aplicação (alteração de objecto, menus, etc) é necessário novo encapsulamento e troca do ficheiro gerado, no servidor. Esta troca apenas é disponível a administradores.
o Qual a relevância de fazer uma ligação à Base de dados para recolher nova informação e fotos se a aplicação já tem por defeito?
· Porque um dos objectivos da aplicação passa por partilhar memórias e histórias que aconteceram no campus. A integração do blog servirá mesmo nesse propósito e, se tudo correr como planeado, originará muitas imagens (fotos e documentos) sobre o campus. Para evitar estar constantemente a actualizar o ficheiro encapsulado criado no unity, resolveu-se fazer essa actualização de forma dinâmica. Dessa forma aplicação irá ligar-se à base de dados e recolher todas essas imagens. Esse dinamismo também permite a correcção de erros, bugs e imprecisões.
o Porque motivo a aplicação redimensiona as fotos enviadas pelos utilizadores?
· Porque as fotos enviadas podem ter até 4Mb de tamanho máximo, e além disso, podem ter uma resolução muito alta, não necessário para a visualização dentro da aplicação. Caso houvessem muitas fotos com um tamanho muito elevado, poderia gerar graves problemas de navegação e streaming de dados. Dessa forma, o plugin NextGen Gallery vai redimensionar para 800x600 e reduzir a qualidade em 70% (caso seja necessário).
o Porque razão a aplicação não faz essa recolha enquanto está a fazer o loading da aplicaçao?
· Por motivos de rapidez e eficiência. No caso de haver muitas imagens para download, corria-se o risco da aplicação demorar muito tempo a fazer o loading no arranque da mesma. Além disso, não seria eficiente porque a aplicação poderia eventualmente estar a recolher imagens que o utilizador não iria ver. Assim sendo o download das fotos apenas acontecerá quando o utilizador escolher ver a galeria de fotos de dado edifício, fazendo a recolha apenas relativa ao mesmo.
o A aplicação apresenta-se num formato widescreen (estilo 16:9). O que motivou isso?
- Verificou-se que o uso de um formato menos largo (como apresentado nas demos técnica/gráfica, poderia prejudicar a visualização do campus, quando a interface apresenta informação contextual (do lado esquerdo), juntamente com o mapa no canto inferior direito.Ao “alargar” área do ecrã, aumenta-se bastante a área útil de observação do campus 3D. Outro motivo para a alteração do formato foi a melhor adaptação à largura do template, ajustando-se também às regras (guidelines) que foram sendo criadas para o mesmo. Também se verificou que é cada vez maior o número de monitores que usam formatos wide, como se pode verificar pela tabela em anexo 4. (ver documento final)
o Como será concretizada a timeline?
· Ao invés do que tinha sido pensado inicialmente, a timeline não será implementada através de um plugin do wordpress, dado serem bastante redutores relativamente ao que o grupo pretende. Dada essa limitação, a timeline será criada através de jQuery (JavaScript) que posteriormente será integrada na página respectiva.
o De que forma a existe essa interacção entre a timeline e a aplicação?
· A aplicação aceita variáveis de entrada (em JavaScript) que serão diferentes conforme a opção escolhida. Cada uma dessas opções remete a aplicação para um nível diferente, que terá conteúdo diferente (mais ou menos edifícios, terrenos modificados, entre outros) conforme a época.
o Porque motivo não se incluiu uma timeline na própria aplicação?
· Considerou-se que seria redundante incluir na aplicação outra timeline, dado que já existe uma na página web e o Unity permitir esse tipo de dinamismo com entidades externas.
Implementado através de um plugin que permite interligação com API's externos. Esses têm base de dados de milhões de utilizadores, sendo credíveis e fidedignos.
o Qual a razão de usar um plugin externo e não o sistema de utilizadores do wordpress?
· Pela extrema facilidade de registo na aplicação virtUA que este tipo de implementação permite. O utilizador não necessita de responder a mais um questionário de registo numa nova aplicação, ajudando desta forma a usar eficientemente o seu tempo, poupando recursos.
o E é seguro?
· Sim, as API's escolhidas são conhecidas por apresentar sistemas fidedignos.
o Mas não era para se usar o sistema de Utilizador Universal (UU) utilizado na U.A.?
· A utilização do UU representava despender algum tempo na sua implementação, além de obrigar a conversações com diversas entidades, o que poderia, muito facilmente, demorar mais tempo do que o previsto para produção do projecto. O sistema adoptado, conceptualmente, apresenta-se idêntico ao uso do UU (utilizadores já existem, partilha-se alguma info para criação dos utilizadores) pelo que no futuro, com menor esforço, é possível a integração do UU, com um sistema idêntico ao usado no paco ou sapo campus.
o Os utilizadores ficam automaticamente registados no site virtUA, após confirmação de ligação ao provider ID? (ex. ligação ao facebook)
· Sim, ao fazer a ligação com a aplicação externa e concordar com a partilha de informação entre os mesmos (ex. virtUa <-> facebook), o wordpress cria automaticamente um utilizador novo na sua base de dados (com alguns dados partilhados pela API externa), com permissões de "autor", que permite apenas criar posts novos (com ou sem imagens) e alterar os seus dados.
o Mas não é inseguro criar automaticamente utilizadores novos, que podem inserir conteúdos impróprios?
· O facto do utilizador usar um login próprio, já com histórico próprio (ou rasto) e reconhecido por colegas e amigos, já instiga o utilizador a fazer uma interacção com o mínimo de cuidado.
o Porque é que é necessária a ligação à BD (Base de Dados) para obter informação/fotografias sobre o edifício escolhido?
o Porque não recolher informação/fotografias no momento de loading da aplicação?
· O loading poderia ficar extremamente lento e comprometer a eficiência da aplicação e daí diminuir a satisfação do utilizador final. Alem disso, o utilizador poderia estar à espera de informação que não pretendia visualizar.
o Qual a cor principal em termos de identidade do projecto? Porquê?
· A cor principal em termos de identidade do projecto é o laranja, dado ser a segunda cor que a comunidade académica associa à Universidade de Aveiro ser representativa dos tijolos dos departamentos. Facilmente se associa o projecto à UA, transmitindo vivacidade e dinamismo.