Blog de acompanhamento ao projecto de 3º ano de NTC, no ano lectivo de 2010/2011.
11
Jul 11

 

Este post serve para reunir, num só sítio e em fácil acesso, todo o material relativo à entrega final do projecto weDraw.

O site encontra-se acessível em http://linlabmm.clients.ua.pt/wedraw. Os dados de acesso foram já enviados por email a todos os docentes e orientadores de projecto.

O relatório enconta-se, na sua totalidade, abaixo:

 

 

Ainda abaixo encontram-se, para acesso facilitado, todas as entregas feitas neste blog, por ordem cronológica:


09
Jun 11

 Formato dos Testes


De forma a começar os testes de usabilidade, foi primeiro necessário decidir qual o formato que iria ser usado. Após alguma deliberação, o grupo optou então por usar um guião cognitivo, seguido de um curto inquérito escrito pós-teste.

Guião e Inquérito


De seguida foi decida a melhor forma de analisar. Para esse feito, fez-se recurso de um programa de captura de ecrã para gravar os testes, juntamente com o áudio. Juntamente com cada um dos utilizadores estavam presentes dois membros do grupo: um para dar apoio em qualquer questão ou dificuldade encontrada, outro para ir anotando as observações em uma grelha de análise, que mais tarde foi complementada com uma análise mais completa recorrendo aos vídeos capturados.

 

Grelha de análise



Execução

Os testes foram executados com alguns contratempos, o primeiro de não ter havido sala disponível para o dia em que haviam sendo agendados, o segundo de termos apenas conseguido assegurar um utilizadores experiente, pelo que tivemos de usar cinco utilizadores novatos. Aqui devemos ainda agradecer à Bárbara Macedo que nos conseguiu arranjar utilizadores suficientes para termos efectivamente seis utilizadores teste.

Um outro factor importante a ter em consideração foi o facto de termos agendado os testes para a sexta-feira antes da data de entrega dos mesmos ter sido alterada, sendo nos impossível remarcar. Assim tivemos menos tempo para angariar utilizadores e assegurar as melhores condições para realizar os testes, para além de corrigir problemas encontrados anteriormente.


Resultados e Análise Final

Tendo concluído os testes foi então possível analisar os vídeos, juntamente com os inquéritos e as observações registadas durante os mesmos. A estratégia utilizada foi a de medir o tempo demorado em cada passo contra o tempo demorado por um utilizador padrão. Seguido de uma análise da quantidade de erros dada em cada passo. Com estes dois pontos esperou-se conseguir identificar as áreas problemáticas na utilização da aplicação. Por fim iria-se fazer uma análise cruzada das respostas ao inquérito, juntamente com observações registadas na grelha e em vídeo.

 




Neste gráfico podemos então ver o tempo demorado pelo utilizador padrão, seguindo o mesmo guião que foi dado aos utilizadores de teste.




Neste gráfico encontram-se representados os tempos demorados em cada passo pelos seis utilizadores. É importante notar que os passos 3, 5 e 7 implicam desenho, pelo que variam conforme o tempo que cada utilizador dedicou a criar o desenho.

Nesta fase não se detectou nenhum problema grave, apesar de se notarem dificuldades com o 4º passo e o 8º passo que se verifica ser por uma certa falta de feedback.

 

 

O gráfico acima mostra os erros dados por cada utilizador em cada um dos passos, assumindo-se como erros não se ter preenchido um campo essencial ou navegar para secções contrárias às indicadas pelo guião quando tentando concretizar um dos passos.

Assim conseguiu detectar-se problemas em dois dos passos, nos quais vários utilizadores deram vários erros. Os passos em que houve problemas foram o oitavo e o nono. Após a análise notou-se que os erros no 8º passo passavam por uma falha em notar o campo de captcha que era necessário preencher, enquanto que no 9º passo, adeviam de uma combinação de falta de feedback com, novamente, o campo te captcha, para além de uma falta de familiaridade com o funcionamento dos fórums.


Conclusão

Tendo finalizado os testes e a sua análise, pode-se concluir que a maioria dos problemas encontrados eram derivados, no site em geral, de uma falta de feedback que por vezes confundia os utilizadores, relativamente a se tinham tido efeito as suas acções ou para onde ir a seguir.
Por outro lado, as dificuldades com a ferramenta de desenho em si originavam não de problemas de feedback mas de uma falta de adaptação, sendo que procuravam atalhos e as ferramentas onde se esperaria de os encontrar em ferramentas de desenho vectorial locais como o Illustrator. Um facto curioso é a falta de familiaridade com fórums e a utilização do logo do site como link que redirecciona para a homepage, assumindo apenas a existência dessa funcionalidade o utilizador experiente.
Um outro bug que persistiu ao longo dos testes foi a falha ao gravar, ocasionalmente e bastante aleatoriamente recusando-se a salvar uma imagem ou alteração.


Soluções

Para corrigir os problemas é então necessário aumentar a quantidade de feedback devolvida pela aplicação. Dar maior destaque a mensagens de erro e sucesso, esconder todos os elementos não necessários quando não em uso e tornar o captcha mais visível (algo que desde então já foi corrigido, sendo trocado por um com maior visibilidade).

Quanto ao bug de salvar estamos de momento a assumir estar resolvido, após termos colocado os quatro membros do grupo a criar imagens, utilizando diversos browsers, sistemas operativos e perfis novos e antigos, sem conseguir voltar a reproduzir o erro. Uma possibilidade no entanto é o problema não estar localizado no site em si ou na aplicação, mas sim no servidor.

O fórum também se revelou problemático devido à falta de familiaridade das pessoas, pelo que a solução poderá passar por criar um pequeno guia de utilização do mesmo, duas ou três linhas no topo, para dar alguma direcção e melhorar a legenda visto um dos erros notado foi a tentativa de clicar na legenda em vez das linhas de discussão.

A falta de familiaridade dos utilizadores com a funcionalidade do logo ser um link para a homepage também pode ser contornado, colocando um link mais visível para a página principal.

Por fim é necessário procurar resolver um bug encontrado na ferramenta de desenho, em que por vezes recusa-se a trocar a cor sem antes se clicar na palette, algo já vindo com a API do svg-edit, mas que podemos tentar resolver.


Implementações Futuras

Um dos campos do inquérito era referente a sugestões para aplicação. Uma das sugestões que se destacou era a possibilidade de criar uma resposta a um desenho, com um novo desenho, algo diferente de uma derivação, quase como competição entre os dois. É um conceito interessante e que futuramente talvez possa ser adicionado à aplicação.

Outra sugestões interessantes incluem um destaque para o melhor desenho do mês/semana (talvez uma nova criação nesse tempo que angarie o maior número de votos) e expandir a biblioteca de formas pré definidas incluídas na ferramenta de desenho.


Para os testes de compatibilidade foram utilizados os seguintes dispositivos:

 

  1. Monitor de 24" Widescreen
  2. Monitor de 19" 4:3
  3. Android 3.5"
  4. Magalhães
  5. EeePC
  6. Macbook 13"
  7. iPhone 4

Tentámos abranger a maior variedade de dispositivos utilizados pelo nosso público alvo, desde dispositivos móveis com ecrãs de baixa resolução, até Desktops com grandes monitores.

Os seguintes sistemas operativos foram considerados:

 

 

  1. Windows ( 7, Vista, XP)
  2. Mac OSX 10.6
  3. Linux Caixa Mágica


E os seguintes browsers:

 

  1. Internet Explorer (7,8,9)
  2. Mozilla Firefox
  3. Google Chrome
  4. Safari
  5. Opera
  6. Browser default do Android
  7. Safari (iOS)

Para a selecção de browsers, consultámos os dados estatísticos de utilização mais recentes do site w3schools.com, de modo a saber quais os browsers mais utilizados na actualidade.

Por fim, as seguintes resoluções foram consideradas:

 

 

  1. 800x600
  2. 1024x768
  3. 1280x800


O teste realizado consistiu no seguinte percurso:

  1. Login;
  2. Consulta da página de perfil;
  3. Criação de um desenho na ferramenta. Gravação do mesmo;
  4. Consulta do perfil de um outro utilizador. Abertura e modificação de um dos seus desenhos;
  5. Comentar uma das criações de outro utilizador;
  6. Logout.


Os resultados dos testes podem ser encontrados na seguinte tabela.


De maneira geral, concluiu-se que o site weDraw funciona na maioria das combinações de dispositivos utilizados actualmente. No entanto, é recomendada a utilização no Firefox ou no Chrome. É também recomendada uma resolução igual ou superior a 1024x768, já que o site é, de momento, compatível com resoluções inferiores. Também de momento a ferramenta não é compatível com dispositivos móveis (smartphones, pda's), já que a interacção e o desenho requerem as funcionalidades de um rato, não reproduzíveis em ecrãs de toque.

 



Começamos por relembrar os parâmetros de segurança que o grupo se comprometeu a testar, delineados no post Módulo 6 - testes:

  1. Copiar urls internos sem login para tentar aceder às páginas;
  2. Alterar parâmetros de url para tentar aceder a perfis e outras áreas exclusivas;
  3. Colocar valores inválidos nos campos de input e analisar a resposta do sistema;
  4. Tentar aceder directamente a ficheiros e directórios;
  5. Testar Captcha, submissões em massa;
  6. Manter registos de tentativas falhadas;
  7. Verificar encriptação na base de dados de palavras-chave. Tentar assegurar existência de salt;
Vamos passar a apresentar os resultados dos testes, assim como soluções que as problemáticas apresentadas nos levaram, entretanto, a implementar, de forma a aumentar a segurança no site.

1. Copiar urls internos sem login

Felizmente, o Drupal permite configurar o acesso quer a páginas quer a funcionalidades (base ou providencias por módulos) mediante o tipo de utilizador. Neste caso, os utilizadores do nosso site dividem-se em 3 tipos:
  • Utilizador anónimo/não registado
  • Utilizador autenticado/registado
  • Administrador

Sendo que o utilizador anónimo apenas tem acesso à página inicial, à ferramenta de criação e aos nós do tipo imagem, blog e fórum, embora possa apenas visualizar o conteúdo destes. A notar que na versão final haverão imagens de destaque na página inicial a que o utilizador anónimo poderá aceder. Quando às páginas de blog e de fórum, o acesso a elas será bloqueado na apenas na versão final, não se tratando no entanto de uma falha de segurança de grande gravidade.

 


2. Alterar parâmetros de url para tentar aceder a perfis e outras áreas exclusivas

Assim como no ponto 1, o acesso a certas funcionalidades e áreas exclusivas está limitado, tanto pelo tipo de utilizador como pela autoria e relação entre o utilizador com sessão iniciada e a página a ser visualizada. Assim, a título de exemplo, só o utilizador a que a página de perfil pertença tem acesso ao botão de edição de perfil no mesmo. Da mesma maneira, é impossível aceder à página principal de qualquer utilizador que não seja o que tem a sessão iniciada, já que o contéudo dessa é determinado pelo utilizador que tem a sessão iniciada.

 


3. Colocar valores inválidos nos campos de input e analisar a resposta do sistema

Este era, à partida, o ponto onde poderiam existir mais problemas. Isto devido à integração do Drupal com a ferramenta de edição e, mais especificamente, aos formulários aí presentes que poderiam não funcionar, em termos de verificação dos seus dados, ao mesmo nível de segurança dos formulários do Drupal.

Assim, testou-se a submissão de código HTML, PHP e JavaScript, tanto no formulário de login, registo e de gravação de imagem. Em todos os casos, todo o código é passada como texto simples, não havendo a hipótese de injecção de código através deste método. O mesmo acontece nos formulários nativos do Drupal.

Exemplo de tentativa de injecção de código HTML, PHP e JS.
 


4. Tentar aceder directamente a ficheiros e directórios

O acesso a directórios é impossível (o servidor retorna sempre um erro 403 - falta de permissões). Quanto a ficheiros, é possível a um utilizador que tenha conhecimento da estrutura de directórios e dos nomes dos ficheiros aceder aos mesmos, nomeadamente a todas as imagens e ficheiros svg gerados pelo editor. Contudo, há que notar que esses ficheiros são gravados com o formato nome dado à imagem pelo utilizador + timestamp unix (número único; Ex: 1306854392) + extensão do ficheiro. Assim, a menos que o utilizador tenha tido acesso ao nome do ficheiro (dentro de uma sessão iniciada, por exemplo), ser-lhe-há extremamente difícil de ganhar acesso aos ficheiros directamente. Mais, mesmo que consiga ter assim acesso aos ficheiros, não ganha com isso mais do que ganharia se fosse um utilizador registado, já que esses podem fazer download desses ficheiros de forma livre. Quando às permissões de escrita do servidor, só se encontram ligadas onde tal é necessário para o funcionamento da aplicação, como na pasta de ficheiros.

 


5. Testar Captcha, submissões em massa
 
(Devido a constrangimentos de tempo e de horários, não se pode testar a submissão em massa de conteudos.)

Convém notar neste ponto uma mudança importante, relativa à aplicação testada relativamente à usabilidade. O módulo usado nesses testes, captcha, foi abandonada, assim como o foi o método de captcha através de perguntas matemáticas. No seu lugar, foi adoptado o serviço anti-spam Mollom, que oferece mais opções a nível de segurança, como por exemplo:

  • Verificação automática do contéudo submetido (se for considerado spam, o contéudo é automaticamente recusado. Caso o contéudo não seja obviamente spam nem contéudo genuíno, é pedido o preenchimento de um captcha);
  • Personalização do tipo de verificação por formulário de submissão (permite que alguns formulários sejam controlados por captcha e outros pela análise de contéudo);
  • Mais informação sobre o serviço pode ser consultada aqui.
Utilizando o modo de teste do módulo (que permite testar o comportamento do mesmo mediante vários tipos de contéudo), a performance deste encontrou-se dentro do “publicitado”.
 
 

6. Manter registos de tentativas falhadas

A resolução deste ponto esteve implementada desde a instalação inicial do CMS, já que este contém de raiz uma série de tabelas que registam todos os eventos no sistema, incluindo tentativas de acesso inválidas e, integrado com o módulo Mollom já mencionado, estatísticas relativas a tentativas de spam bloqueadas.


 Excerto da página de registos.

 

7. Verificar encriptação na base de dados de palavras-chave. Tentar assegurar existência de salt

Para garantir a encriptação das palavras-chave e apesar do Drupal já realizar uma encriptação MD5, foi instalado o módulo Secure Password Hashes, que utiliza a framework Portable PHP password hashing para passar as palavras-chave gravadas por múltiplas rondas de hashing e salting.
 
 
Em adição a todos esses parâmetros, o site foi passado por duas ferramentas de testes de segurança de sites: Websecurify e Acunetix Web Vulnerability Scanner. Ambos passam o site por uma bateria de testes de segurança, incluindo:
  • Injecção SQL;
  • Local and Remote File Include;
  • Cross-site scripting;
  • Cross-site Request forgery;
  • Session Security;
  • Analizador de scripts (segurança de AJAX e aplicações Web 2.0);
  • Teste de ferramentas de penetração;
Os resultados de ambos foram bastante positivos. O Websecurify encontrou 59 erros, mas nenhum considerado grave. Os erros encontrados foram relativos a emails presentes dentro de ficheiros de script (informação relativa aos autores do script geralmente incluída no início do ficheiro, comentada) e a funcionalidade activa de auto-complete nos formulários de login e registo. O relatório completo pode ser consultado, em formato PDF, no link disponibilizado no fim do post. O Acutinex só revelou 4 erros e todos relativos a vulnerabilidades no servidor MySQL.

Convem mencionar, por último, que foi também implementado um módulo que permite controlar de forma mais exacta as sessões,Persistent Login, que implementa a opção “remember me” aquando do login que cria um cookie que controla a sessão para o utilizador. Se essa opção não for seleccionada, a sessão do utilizador é terminada aquando do fecho do browser.

Links:
Relatório de segurança do Websecurify
Relatório de segurança Acutinex (screenshot da aplicação)

 


08
Jun 11

 

Partimos para a versão beta com objectivos ambiciosos a nível da implementação de funcionalidades que na altura estavam por desenvolver ou em desenvolvimento (essas mesmas foram detalhadas no post Módulo 6 - componentes a desenvolver e a sua consulta é recomendada). Neste post vamos fazer um levantamento do estado actual do desenvolvimento da plataforma weDraw, com destaque ao que foi desenvolvido e ao que ficou ainda por desenvolver.

 

Relativamente às componentes marcadas como sendo de prioridade urgente (Página principal, ficheiros, versões anteriores, editor e competições), só o desenvolvimento das competições foi deixado para a versão final, dada a sua complexidade maior que o inicialmente previsto. Os restantes componentes ficaram já bastante próximos das suas versões finais, com as seguintes melhorias/implementações relativas à versão anterior:

 

Página principal (Esta página não estava de todos implementada na versão anterior):

  • O login do utilizador normal redirecciona para esta página;
  • Informação relativa à actividade recente dos utilizadores a que o utilizador com sessão iniciada subscreve;
  • Informação relativa aos posts mais recentes no fórum;
  • Galeria com as criações mais recentes dos utilizadores subscritos;
  • Galeria com as criações mais recentes de toda a comunidade;
     

Página de ficheiro:

  • Botões no topo da imagem para abrir a mesma no editor, ver a imagem em tamanho inteiro (num overlay), fazer o download da imagem (PNG), editar as propriedades da imagem (nome, descrição, tags, só aparece caso o utilizador seja o autor da imagem OU o admin) e apagar a imagem (mesmas restrições que a opção anterior)
  • Implementação de tags funcionais associadas à imagem
  • Implementação de uma galeria com as versões anteriores da imagem, permitindo acompanhar a evolução da mesma. É possível, com um clique sobre qualquer uma das versões, abri-la no editor;
  • Monitorização no número de visualizações de uma imagem (para posteriormente se poder criar, por exemplo, uma galeria com as imagens mais vistas);
  • Implementação de sistema de votos nas imagens;
  • Implementação de links de partilha da imagem em várias redes sociais, incluindo o Twitter e o Facebook, com opção de fazer like à imagem;
  • Aspecto gráfico dos comentários completamente revisto, em conformidade com o que foi idealizado na fase de especificação gráfica
  • Sistema de votos (up and down) nos comentários, sendo que comentários que fiquem abaixo de um determinado número de votos negativos ficam acinzentados;

 

Versões anteriores:

  • Funcionalidade completamente implementada. Se o autor de uma determinada imagem a abrir com o editor e voltar a gravar, é criada uma nova versão da mesma. Se o utilizador a gravar a imagem não for o autor, a imagem é gravada como uma imagem nova, havendo informações relativas à mesma a referênca à imagem da qual a nova foi derivada.

Editor:

  • Feedback de que o ficheiro está a ser gravado;
  • Correção dos bugs mais graves da versão anterior, com destaque àqueles que comprometem a gravação de imagens;
     

No editor, fica apenas por resolver os bugs relativos à utilização de campos de password nos formulários e à visualização de layers novas. Pediu-se a ajuda à comunidade relativamente ao primeiro, mas não se obteve qualquer tipo de resposta (o pedido de ajuda pode ser consultado aqui). Dado que nenhum destes bugs compromete a utilização da ferramenta nem a realização dos testes de usabilidade da mesma, a sua resolução foi deixada para a versão final da aplicação.

De resto, todos os bugs detectados na versão anterior foram corrigidos, com excepção do bug de prioridade baixa relativo ao envio do formulário de contacto, que provavelmente requerirá certas configurações a nível do servidor, para permitir o envio de emails.

 

Voltando ao que foi desenvolvido para a versão beta, passamos para os que foram marcados como sendo de prioridade alta:

 

Perfis:

  • Implementação de um campo com a actividade mais recente do utilizador do perfil. Os itens da actividade mais recente aparecem escritos na segunda pessa se o utilizador que estiver a ver o perfil for o a que o perfil pertence;
  • Adição de um campo que mostra um preview do post mais recente do blog do utilizador;
  • Adição de um botão para editar o perfil, visível ao utilizador a que o perfil pertence e ao admin;
  • Referência ao número de seguidores e subscrições que o utilizador tem. Essas informaçãos têm um link associado que redirecciona para páginas com a lista dos seguidores/subscrições. A notar que a página dos seguidores não funciona de momento, mas terá o aspecto da página das subscrições;

Os comentários ao ficheiro e as listas de amigos já foram referenciados. Fora o bug acima mencionado, os componentes encontram-se completamente implementados.

Os componentes mencionados como sendo de prioridade normal e baixa foram, regra geral, deixados para a versão final, juntando-se à funcionalidade de competições mas com uma complexidade de execução, comparativamente, bastante baixa.

De forma geral, as componentes comunitárias da aplicação encontram-se todas implementadas ou, não estando ainda implementadas, já foram plantadas as "sementes" para a sua implementação (Ex: o sistema de votos nos ficheiros e o registo do número de visualizações).

Para a versão final ficam, então, por implementar, os seguintes componentes:

  • Competições
  • Notícias
  • Ajuda
  • Documentação

Fora as Competições, já referidas neste post, as Notícias são de fácil implementação (criação de nós de texto limitada ao administrador, acessíveis aos outros utilizadores), assim como o são toda a documentação de ajuda, termos de utilização e guias, do domínio da criação de conteúdo.

Outros componentes, já parcialmente implementados, precisam apenas de serem aprimoradas relativamente aos seus layouts (Mensagens pessoais e pesquisa).

 

É possivel aceder à aplicação no seguinte link: Link da Aplicação.

As credenciais de acesso são iguais às do módulo anterior, quer as de administrador como as dos utilizadores-tipo.


30
Mai 11

Para assegurar um bom funcionamento da aplicação e uma experiência agradável por parte do utilizador é necessário realizar uma série de testes. Esses testes incidem principalmente sobre três pontos: Usabilidade, Compatibilidade e Segurança.

 

Usabilidade

Os testes de Usabilidade giram em torno da experiência do utilizador, para tal é importante analisar a forma como interagem com a aplicação. Para essa análise vamos recorrer a seis utilizadores tipo, para representar o nosso público-alvo, três dos quais serão artistas novatos, enquanto outros três serão artistas com já alguma experiência.

 

Juntamente com o guião cognitivo iremos ter um dos membros do grupo juntamente com o utilizador para o guiar ao longo do teste, enquanto que as suas interacções serão gravadas através de uma aplicação de captura de ecrã. Adicionalmente iremos usar ou uma câmara para filmar a experiência, ou com a presença de um segundo membro do grupo, mais distante que irá registar erros e outros detalhes em uma tabela de análise.

Caso tudo corra bem, os testes de usabilidade serão executados ao longo da próxima sexta-feira.

 

Compatibilidade

Os testes de compatibilidade têm como objectivo assegurar uma igual experiência de utilização da aplicação em diversos dispositivos. Para tal é necessário testar o funcionamento em diversas combinações de browsers, resoluções e sistemas operativos, registando os resultados numa tabela, descrevendo os problemas e diferenças detectadas. Os problemas encontrados serão depois inseridos na ferramenta de bug tracking para manter um registo e facilitar a sua resolução e priotirizar a sua resolução conforme a gravidade.

 

Segurança

A função dos testes de segurança é assegurar a protecção tanto da aplicação como dos utilizadores, como prevenir spam. Para tal iremos realizar os seguintes testes:

 

- Copiar urls internos sem login para tentar aceder às páginas.

- Alterar parâmetros de url para tentar aceder a perfis e outras áreas exclusivas.

- Colocar valores inválidos nos campos de input e analisar a resposta do sistema.

- Tentar aceder directamente a ficheiros e directórios.

- Testar Captcha, submissões em massa.

- Manter registos de tentativas falhadas.

- Verificar encriptação na base de dados de palavras-chave. Tentar assegurar existência de salt.

 

Os resultados serão então registados e quaisquer problemas detectados, tal como com os testes de compatibilidade, serão inseridos na ferramenta de bug tracking.

 

 

 


Após uma analise ao protótipo de alta fidelidade, elaboramos uma lista dos bugs encontrados. Esta lista foi construída utilizando a ferramenta code.ua, que será utilizada daqui para a frente, não só para bug tracking mas também para controlar o desenvolvimento das funcionalidades ainda por implementar. A página do projecto pode ser consultada aqui. Os bugs são categorizados segundo a sua prioridade e tipo. Achamos ainda importante diferenciar se é um bug do svg-edit ou do Drupal.

 

(ver pdf)

(download pdf)

 

Para a resolução dos bugs do svg-edit relacionados com a interacção com o Drupal (login/registo e gravação de imagens), vão ser usadas várias técnicas de verificação de código em PHP, nomeadamente:
    •    fazer o "dump" para um ficheiro de texto de todas as variáveis passadas ao longo do código;
    •    Criar variáveis de verificação que incrementem no início e no final de cada função;
    •    Retirar o código de redireccionamento para a página do nó criado, de forma a poder examinar, com recurso ao Firebug e outras ferramentas similares, os dados passados por POST;
    •    Comentar selectivamente determinados grupos de código, como forma de chegar mais perto da fonte do problema;

 

Os bugs relacionados com funcionalidades nativas ao svg-edit, como o das layers, vão requerer uma pesquisa a fundo, no código-fonte, das zonas de onde o problema possa originar. Adicionalmente, será pedido apoio à comunidade de desenvolvimento da ferramenta e os fóruns de discussão da mesma pesquisados, na eventualidade de soluções já existirem.

 

Relativamente aos erros do Drupal, utilizando o perfil de administrador, iremos verificar se todas as permissões estão delegadas de acordo com as funcionalidades pretendidas. Nos problemas que não envolvam permissões, iremos na secção de administrar e construir, modificar e ajustar os parâmetros necessários a resolução dos bugs. Para qualquer problema que não tenha uma solução imediata, iremos recorrer a ajuda no site do CMS e a sua comunidade.

Link para a folha de cálculo da listagem de bugs.


26
Mai 11

O presente módulo, último antes da entrega final, envolve dar continuidade ao desenvolvimento da plataforma até esta chegar à versão beta e, a partir desta versão, realizar um conjunto de testes de usabilidade, compatibilidade e segurança.

Neste post vamos definir as componentes a desenvolver, tendo por base o mapa do site até agora usado.

 

 

(ver pdf)

(download pdf)


Como no módulo anterior, as componentes foram agrupadas por prioridades, sendo contudo a legenda deste mapa mais complexa que a anterior.

Prioridade urgente (Página principal, ficheiros, versões anteriores, editor, competições)

  • Os componentes marcados com este nível prioritário são os que têm de ser completos o mais cedo possível, dada a importância e complexidade das suas funcionalidades. Os componentes de ficheiros e editor já foram iniciados no módulo anterior mas ainda contêm alguns pontos em falta ou, no caso do editor, alguns bugs a corrigir. As competições são, a seguir ao editor, o que há de mais complexo por implementar na plataforma. As versões anteriores já se encontram quase implementadas e são fundamentais para o funcionamento da plataforma.


Prioridade alta (Perfis, comentários a ficheiros, listas amigos)

  • Estes são componentes também bastante importantes, mas menos complexos que os anteriores. São todos fáceis de implementar ou já parcialmante implementados e como tal ficam atrás.


Prioridade normal (Página inicial, comentários a perfil, pesquisa)

  • Componentes que não são fundamentais para a versão beta, mas são relativamente simples de implementar ou já estão parcialmente implementados.


Prioridade baixa (Notícias, mensagens pessoais, posts, gerir competições, ajuda, documentação)

  • Componentes que não necessitam de ser desenvolvidos para este módulo e apenas o serão na versão final.

 


20
Mai 11

O presente módulo TP5 que termina hoje consistiu no desenvolvimento do protótipo de alta fidelidade da nossa aplicação.


(As áreas da aplicação onde os esforços se centraram foram detalhadas no post Módulo 5 - Mapa do site [Final], que pode ser revisitado aqui.)


Assim sendo, começámos por abordar os elementos de maior prioridade, com especial atenção ao desafio da interacção entre a ferramenta de edição vectorial svg-edit e o CMS Drupal. Essa interacção foi detalhada anteriormente mas revelou-se agora em toda a sua complexidade, obrigando ao grupo desenvolver código largamente original e fora do conforto de tutoriais ou documentação existente. Salvo algumas inconsistências funcionais o desafio foi ultrapassado. Ainda assim, as dificuldades na sua concretização acabaram por atrasar outras áreas do protótipo. Mais, algumas funcionalidades como o histórico de ficheiros e forking ficaram por desenvolver.


Contudo sentimos que, tendo sido ultrapassadas as barreiras principais do desenvolvimento, estamos em condições de desenvolver essas restantes funcionalidades e bugs que persistam com relativa facilidade.


A nível gráfico, toda a estrutura da interface original da ferramenta foi alternada para maximizar o conforto e a funcionalidade. Adoptámos um aspecto o mais semelhante possível a ferramentas a que o público-alvo esteja já habituado a utilizar (Illustrator, Aviary, etc). Também nesse sentido optámos por utilizar uma versão alpha da ferramenta, por esta oferecer um grande número de funcionalidades que achamos fundamentais, como:

  • Pen tool;

  • Grelhas;

  • Rulers;

  • Right-click menu com funcionalidades clipboard e ordenação de ficheiros;

  • Color picker;

     

A nível do CMS, o maior desafio foi a falta de familiaridade com o ambiente de desenvolvimento, nomeadamente alguns módulos mais complexos mas fundamentais para criar um site dinâmico e interessante. Dos restantes elementos considerados de alta prioridade, o que ficou de longe mais desenvolvido foi a página de perfil.


Aí foram implementadas funcionalidades como uma galeria das imagens criadas pelo utilizador, carregada dinâmicamente, mecanismos de subscrição e subscrições, notificações de actividade recente e vário contéudo carregado dinâmicamente. O próprio layout da página foi feito com recurso a um módulo, Panels, que permite criar layouts complexos de forma rápida.


A página de ficheiro já permite recuperar no editor os ficheiros anteriormente gravados, apesar da falta das funcionalidades de histórico e forking já mencionadas.


A nível gráfico, foi implementado com sucesso o estilo visual apresentado na fase de especificação gráfica, tanto a nível de cores e tipos de letras como a nível de utilização da grelha que nos comprometemos a respeitar. Já ao nível das interacções, o Drupal suporta de raíz um sistema e mensagens de feedback que aproveitamos, assim como overlays para formulários de login, registo e contacto. Por fim, o próprio menu é animado para tornar a sua navegação mais simples e agradável.


Dos elementos propostos como sendo de baixa prioridade, existiram também alguns conflitos relativos aos módulos do Drupal, pelo que a secção dos “Posts” também só irá ficar completa até ao final da próxima semana. De resto e tirando a página principal que, após reunião com os orientadores, se decidiu manter apenas como conteúdo estático, os restantes elementos foram concluídos.


Seguidamento temos os elementos de conteúdo estático. Aqui conseguimos avançar mais do que nos tínhamos proposto, sendo que quase todos os elementos marcados foram concluídos. Adicionalmente, as secções de discussões e de mensagens privadas ficaram completamente funcionais, precisando apenas de alguns retoques gráficos. Por fim o back office, sendo providenciado pelo próprio Drupal, também está completamente funcional.


Outro objectivo a que nos tínhamos proposto com os nossos orientadores era o de traduzir toda a aplicação para uma só lingua, já que svg-edit e Drupal se encontravam em línguas diferentes. Tendo optado pelo português, traduzimos o svg-edit e o próprio Drupal e respectivos conteúdos, reforçando o desejo de que esta seja uma comunidade de portugueses e para portugueses. No entanto,alguns módulos revelaram-se mais complicados de alterar o que, juntamente com as dificuldades já referidas, resultaram numa tradução menos que perfeita, mas perfeitamente funcional para este estado de desenvolvimento. A mesma vai ser finalizada no próximo momento de trabalho.


De forma geral e apesar dos diversas contratempos encontrados, especialmente tendo em conta as dificuldades de integrar e interligar a ferramenta de edição vectorial e o Drupal, consideramos ter feito um progresso considerável por diversas áreas da aplicação e preparado o caminho para um desenvolvimento futuro mais fácil. Acima de tudo, foi adquirida uma quantidade considerável de experiência na criação e edição de contéudos no Drupal, nomeadamente na utilização dos módulos Panels e Views, responsáveis pela estruturação de layouts complexos e pela injecção de contéudos, respectivamente.


Em jeito de comparação com o mapa apresentado anteriormente, foi elaborado o mapa com o estado de desenvolvimento da aplicação após a fase de prototipagem:



 

(ver pdf)


Algumas aspectos menos bem conseguidos e/ou bugs a ter em consideração, nesta versão da aplicação:

  • Devido à falta de tempo para solucionar todos os problemas, a aplicação é melhor visualizada no Firefox, nomeadamente na sua versão mais recente. Outros browsers apresentam problemas a nível da ferramenta de edição vectorial;

  • Como se decidiu que a página principal deveria ser deixada como estática e sendo ela principalmente uma agregação de links, o link do logo leva o utilizador imediatamente à página de perfil, ao invés de para a página principal.

  • Um bug presente no svg-edit previne que o campo de password esteja encriptado, pois se assim estiver, ao inserir a password, irá ao mesmo activar as ferramentas do svg-edit através dos atalhos do teclado. Já contactámos a comunidade de desenvolvimento do mesmo, mas até à hora desta entrega não tivemos resposta à nossa questão.


É possivel aceder a aplicação no seguinte link: Link da Aplicação.


Por questões de segurança as credenciais de administrador serão enviados por email aos docentes e aos orientadores, assim como as credenciais dos utilizadores-tipo já criados, correspondentes às personas referenciadas na demo gráfica.

 

 


02
Mai 11

Após a reunião da semana passada com os orientadores e da aula de hoje e as sugestões e dúvidas nelas apresentadas pelos docentes, efectuámos algumas alterações ao mapa do site previamente apresentado. Estas alterações foram essencialmente no sentido de clarificar a distinção entre as funcionalidades mais importantes e de maior prioridade na construção do protótipo de alta fidelidade.


Assim, podemos destacar a divisão das funcionalidades nas seguintes categorias: prototipagem de alta fidelidade; conteúdo estático; a desenvolver.

 

ver pdf


Dentro da primeira categoria, existem dois níveis de prioridade. Os itens marcados com "prioridade alta" são os que serão desenvolvidos com o objectivo de que todas os seus requisitos funcionais fiquem completamente implementadas. Por outro lado, itens marcados como tendo "prioridade baixa" só serão trabalhados ao pormenor caso todos ou outros sejam fechados.

Nas páginas categorizadas como "conteúdo estático", apenas o layout será trabalhado, sendo que, em todas as regiões onde apareceria conteúdo dinâmico, este será substituído por placeholders.

Por último, as páginas "a desenvolver" irão estar sinalizadas como estando em construção.

As páginas a que foram dadas o nível de prioridade máxima são: editor, ficheiros, galerias e perfis. Estas formam, na nossa opinião, o núcleo do nosso site, permitindo ao utilizador criar, partilhar, comentar e visualizar imagens. Também são as secções de maior complexidade técnica, envolvendo a interacção entre a ferramenta de criação vectorial e o CMS, assim como a organização das imagens em vários tipos de galerias.


Julho 2011
Dom
Seg
Ter
Qua
Qui
Sex
Sab

1
2

3
4
5
6
7
8
9

10
12
13
14
15
16

17
18
19
20
21
22
23

24
25
26
27
28
29
30

31


arquivos
pesquisar blog
 
subscrever feeds
blogs SAPO