weDraw - Relatório Final by weDraw

Universidade de Aveiro | DeCA | NTC | Projecto 3º Ano

Relatório de Projecto 2010/2011

Docentes:

Orientadores:

Discentes:

Prof. Benjamin Júnior

Profª Ana Veloso

André Horta – 46236

Profª. Margarida Almeida

Prof. Pedro Amado

Francisco Ferreira – 46110

Prof. Nuno Ribeiro

João Tavares – 46681

Prof. Pedro Amado

Paulo Alves – 47661

Relatório de Projecto Índice Índice de Figuras ........................................................................................................................... 3 Agradecimentos ............................................................................................................................ 4 Resumo.......................................................................................................................................... 4 Abstract ......................................................................................................................................... 4 Capítulo 1 – Introdução ................................................................................................................ 5 1.1 – Caracterização do Projecto .............................................................................................. 5 1.2 – Proposta Inicial ................................................................................................................. 5 1.3 – Estado da Arte .................................................................................................................. 6 1.4 – Público-Alvo...................................................................................................................... 7 1.5 – Requisitos funcionais........................................................................................................ 7 1.6 – Viabilidade Técnica ........................................................................................................... 8 Capítulo 2 - Design Funcional ........................................................................................................ 9 2.1 – Especificação .................................................................................................................... 9 2.1.1 – Nome ......................................................................................................................... 9 2.1.2 – Logo ......................................................................................................................... 10 2.1.3 – Sistema Visual e Layout ........................................................................................... 10 2.1.4 – Cores ........................................................................................................................ 11 2.1.5 – Tipografia................................................................................................................. 12 2.2 – Prototipagem.................................................................................................................. 13 2.2.1 – Demo Gráfica ........................................................................................................... 13 2.2.2 – Protótipo de Alta-fidelidade .................................................................................... 13 2.3 – Versão Beta .................................................................................................................... 14 2.4 – Versão Final .................................................................................................................... 14 Capitulo 3 – Design técnico ......................................................................................................... 15 3.1 – Especificação .................................................................................................................. 15 3.1.1 – Arquitectura do site................................................................................................. 15 3.1.2 – Mapa de navegação ................................................................................................ 15 3.1.3 –Fluxogramas ............................................................................................................. 16 3.1.4 – Módulos CMS .......................................................................................................... 17 3.2 – Prototipagem.................................................................................................................. 18 3.2.1 – Demo Técnica .......................................................................................................... 18 3.2.2 – Protótipo de Alta-Definição..................................................................................... 18 3.3 – Versão Beta .................................................................................................................... 21 3.4 – Versão Final .................................................................................................................... 24

Relatório de Projecto Capitulo 4 – Síntese dos testes efectuados................................................................................. 27 4.1 – Tipos de testes................................................................................................................ 27 4.2 – Resultados ...................................................................................................................... 27 4.2.1 – Listagem de bugs encontrados ................................................................................ 27 4.2.2 – Testes de segurança ................................................................................................ 28 4.2.3 – Testes de compatibilidade ...................................................................................... 32 4.2.4 – Testes de usabilidade .............................................................................................. 33 Capítulo 5 – Síntese da estratégia de manutenção e suporte .................................................... 36 Capítulo 6 – Análises Finais ......................................................................................................... 36 6.1 – Análise Critica ................................................................................................................. 36 6.2 – Sugestões de desenvolvimentos futuros ....................................................................... 37 6.3 – Problemas Encontrados e Soluções ............................................................................... 38 Capítulo 7 – Conclusões .............................................................................................................. 39 Referências Bibliográficas ........................................................................................................... 39 Bibliografia .............................................................................................................................. 39 Webgrafia ................................................................................................................................ 39 Anexos ......................................................................................................................................... 40

Relatório de Projecto Índice de Figuras Fig. 1 - Logo ................................................................................................................................. 10 Fig. 2 – Três Colunas .................................................................................................................... 10 Fig. 3 – Sistema 960.gs ................................................................................................................ 10 Fig. 4 – Grelha Final ..................................................................................................................... 11 Fig. 5 – Paleta de Cores ............................................................................................................... 11 Fig. 6 – Exemplos Tipografia ........................................................................................................ 12 Fig. 7 – Dimensões em uso .......................................................................................................... 12 Fig. 8 – Secção da Arquitectura ................................................................................................... 15 Fig. 9 – Mapa Final ...................................................................................................................... 16 Fig. 10 – Fluxograma para download .......................................................................................... 16 Fig. 12 – Escolha de ramos a desenvolver ................................................................................... 19 Fig. 11 – Diagrama de Interacção ................................................................................................ 18 Fig. 13 – Estado do desenvolvimento após prototipagem .......................................................... 21 Fig. 14 – Áreas de desenvolvimento para a versão Beta ............................................................ 21 Fig. 15 – Resposta do sistema a valores inválidos....................................................................... 29 Fig. 16 – Registo de actividade .................................................................................................... 31 Fig. 17 – Dispositivos ................................................................................................................... 32 Fig. 18 – Sistemas Operativos ..................................................................................................... 32 Fig. 19 – Browsers ....................................................................................................................... 32 Fig. 20 – Tempo vs acção (utilizadores) ...................................................................................... 35 Fig. 21 – Tabela de erros ............................................................................................................. 35

Índice de Tabelas Tabela 1 - Caraterísticas a integrar ............................................................................................... 7 Tabela 2- Tabela de bug tracking ................................................................................................ 27 Tabela 3 - Resoluções .................................................................................................................. 33

Relatório de Projecto Agradecimentos Antes de começar gostaríamos de agradecer aos nossos orientadores pelo apoio prestado ao longo do desenvolvimento desta aplicação e aos docentes da disciplina de Projecto. Agradecemos também à professora Olinda Martins e aos estudantes de design por se terem disponibilizado a participar nos nossos testes de usabilidade e ao Professor Hélder Caixinha que se mostrou sempre prestável em relação às nossas dúvidas. Por fim agradecemos também aos nossos colegas que de uma forma ou outra nos foram ajudando ao longo deste caminho.

Resumo Este documento apresenta e descreve uma aplicação Web de desenho vectorial desenvolvida no âmbito da disciplina de Projecto, do 3º ano do curso de Novas Tecnologias da Comunicação (NTC) na Universidade de Aveiro durante o ano lectivo de 2010/2011. Neste relatório apresentamos as soluções técnicas e gráficas adoptadas ao longo da construção deste projecto. Adicionalmente, é descrita a evolução dos nossos conceitos e ideias, as dificuldades por nós encontradas e os passos tomados para as resolver. Por fim, também é descrito todo o processo de trabalho desde a ideia inicial até à conclusão da versão final. No 1º capítulo caracterizamos o projecto, comparamos o mesmo com a proposta inicial e descrevemos o estado da arte e o público-alvo. No 2º capítulo criamos uma análise da evolução das soluções gráficas desde o inicio até à versão final, enquanto que no 3º capítulo é feito o mesmo para as soluções técnicas. No 4º capítulo analisamos os tipos de testes efectuados à aplicação e os resultados obtidos. O 5º capítulo irá centrar-se em questões de suporte e sistemas de ajuda, enquanto que o 6º capítulo é dedicado a uma análise mais crítica sobre o projecto desenvolvido. Por fim no 7º capítulo são analisadas as maiores dificuldades encontradas e soluções utilizadas e com o 8º capítulo efectuamos algumas reflexões finais.

Abstract This document introduces and describes a vector drawing web application developed in the Projecto (Project) class, of the 3rd year of the Novas Tecnologias da Comunicação course (New Communication Technologies) at the University of Aveiro during the academic year of 2010/2011. In this report we present the technical and graphical solutions adopted throughout the construction of this project. Additionally we describe the evolution of our concepts and ideas, the difficulties we encountered and the steps taken to resolve them. Finally, the entire work process from the initial idea to the completion of the final version is described.

Relatório de Projecto Capítulo 1 – Introdução 1.1 – Caracterização do Projecto Este projecto foi realizado no âmbito da disciplina de Projecto e têm por base elaborar uma aplicação Web social 2.0 de desenho vectorial colaborativo com o nome weDraw. Um dos conceitos chaves da Web 2.0 é o foco nos utilizadores: as interacções entre os mesmos e a colaboração e a partilha de uma multiplicidade de ideias diferentes em comunidades online. Levar a que os utilizadores sejam não só consumidores estáticos, mas também os principais produtores de conteúdo do site. Pretende-se então que os utilizadores possam criar documentos de desenho vectorial - tanto online e directamente na aplicação como off-line - e partilhá-los com a restante comunidade. Ao serem submetidos, esses ficheiros podem ser sujeitos a revisões e criticas por parte de outros utilizadores, ou então apropriados para inspiração, incorporação em documentos da sua autoria ou simplesmente para ver o processo ou técnicas utilizadas na sua concepção. Adicionalmente, o site também adquire uma componente semelhante às diversas wikis existentes, permitindo que os autores possam apropriar-se das criações uns dos outros e utilizá-las como base de inspiração para as suas próprias obras ou aprender novas técnicas Sendo para isso necessário que todos os conteúdos sejam abertos e editáveis, seguindo a lógica do modelo Wiki. Todas as submissões podem também ser comentadas, criticadas e votadas por outros utilizadores. Existem também espaços de discussão para incentivar a participação na comunidade e partilhar ideias e tutoriais, principalmente sobre desenho vectorial mas também sobre outros interesses para fortalecer a comunidade. Por fim, existem também espaços de competição para desafiar os artistas a serem cada vez melhores e irem além do que já estão habituados, tentando criar algo novo.

1.2 – Proposta Inicial A proposta original no briefing proposto pelo Prof. Pedro Amado e pela Prof. Ana Veloso, com o nome Wikigráfica, tinha como tema a criação de uma plataforma online de desenho vectorial que permitisse a criação, partilha e interacção entre os seus utilizadores. Mais especificamente, pretendia-se uma aplicação Web 2.0 de partilha de informação em que os utilizadores fossem consumidores e produtores de conteúdos. Os objectivos pretendidos eram a criação e revisão de desenhos vectoriais. A criação de portefólios de desenhos. A interacção

Relatório de Projecto e partilha dos mesmos e por fim. A possibilidade de se apropriar e recriar os diversos ficheiros vectoriais. O grupo deparou-se então com o seu primeiro dilema. A aplicação Web iria necessitar de dois grandes componentes, a ferramenta de desenho vectorial em si e toda a comunidade e interacção envolvente. Visto o tempo não possibilitar o desenvolvimento de ambas as partes, após deliberação entre o grupo e juntamente com os orientadores, optou-se por fazer diferenciar a aplicação pelo aspecto mais social e “wiki” visto essa componente ser a mais incomum de momento.

1.3 – Estado da Arte Durante o levantamento do estado da arte relativa ao nosso projecto, o grupo optou desde o inicio por não restringir a pesquisa apenas a projectos similares, mas também em alargar as nossas perspectivas e pesquisar comunidades existentes de partilha de vários tipos de media. Tendo então em consideração as premissas iniciais para este projecto, o grupo dedicou-se à investigação e análise de todas as aplicações online encontradas, organizando-as numa tabela para melhor processar os dados e focar as características mais relevantes de cada uma para o nosso projecto, não só para o manter competitivo como também para ajudar a superar a concorrência. De entre as comunidades analisadas, deu-se destaque a plataformas e API’s de desenho online (bitmap e vectorial), formas de partilhar e editar conteúdos, formas de interacção entre utilizadores e os métodos usados para atingir os públicos-alvo e incentivá-los a visitar regularmente o site em questão. De entre os métodos para incentivar os utilizadores, destacam-se formas de recompensa como sistemas de reputação, utilizados em conjunto com “badges” e rankings para premiar utilizadores por contribuições à comunidade. Relativamente à estrutura, destacou-se a possibilidade de criar galerias pessoais para utilizar como portefólio digital. Quanto às aplicações de desenho, a possibilidade de editar conteúdo directamente no site revela-se muito importante, mas a capacidade de importar ficheiros criados off-line em Illustrator ou programas semelhantes também é uma característica essencial, deixando aqueles que se queiram envolver no site, mas que prefiram usar outras ferramentas, possam participar. Por fim, quanto ao suporte, a maioria dos sites analisados assenta em plataformas de CMS, em detrimento de wikis ou outros formatos (a tabela com o trabalho desenvolvido nesta fase, encontra-se no anexo 1).

Relatório de Projecto Consideraram-se as seguintes aplicações online como exemplos que integram as características mais importantes a integrar no nosso projecto: Nome da

Endereço URL

Aplicação Stack Overflow

http://stackoverflow.com/

Características. Sólido sistema de pontuação e sistema de badges. Sistema de pontuação inovador e grande

Newgrounds

http://www.newgrounds.com /

colaboração na partilha de materiais criativos por entre os utilizadores, criando obras colaborativas.

DeviantArt

Aviary

http://www.deviantart.com/

http://www.aviary.com/tools/ vector-editor

Interacções sociais e organização de galerias e pontuação. Aplicação de desenho vectorial muito bem desenvolvida. Inspiração e concorrência directa.

Tabela 1 - Caraterísticas a integrar

1.4 – Público-Alvo Parte importante do desenvolvimento de um produto é o estabelecimento de um público-alvo a atingir. No caso da weDraw, considera-se ter como público-alvo alunos e artistas gráficos, cujas características incluem alguma literacia tecnológica, espírito cooperativo, maturidade e gosto por aprender mais. Dá-se especial destaque aos que estejam em inicio de carreira, visto terem mais ânsia de aprender diversos truques e dicas para melhorar e facilitar o seu trabalho, mas sem descuidar artistas mais experientes, com carreiras estabelecidas e gosto pelo desenho vectorial, pela partilha e por experimentar coisas novas.

1.5 – Requisitos funcionais Antes de averiguar a viabilidade técnica, foi primeiro necessário determinar os requisitos funcionais para o projecto. Para tal, criou-se uma tabela como uma listagem de todas as acções que seriam desejadas no produto final e de seguida dividiu-se essa tabela em três áreas de colunas: os Requisitos propriamente ditos, os Perfis de utilizador e Prioridade/Importância, atribuída aos vários requisitos de acordo com as perspectivas de várias personas, representativas do público-alvo. Com esta divisão, pretendemos averiguar o que cada tipo de

Relatório de Projecto utilizador poderia querer da aplicação e assim adequá-la para atrair o maior número possível de pessoas. Na coluna dos Requisitos, listaram-se as funcionalidades desejadas no produto final. Estes foram divididos em front-end e back-end, e posteriormente agrupadas em conjuntos semelhantes de funcionalidade. No front-end: 

Requisitos relativos aos ficheiros: operações que envolvam a utilização da ferramenta de desenho vectorial. Edição, o upload, o download, etc.



Requisitos relativos à interacção: operações direccionadas para a componente social da comunidade; funções de interacção entre os diversos utilizadores.



Requisitos pessoais: operações fundamentais para a interacção do utilizador com o site. Inclui todas as funções de criação de conta, alteração de perfil, login, logout, etc.



Requisitos relativos à ajuda: operações com vista à diminuição da dificuldade na utilização do site.



Requisitos relativos à pesquisa: operações de pesquisa por parte do utilizador. Visa a localização de ficheiros, pessoas, etc.

No back-end: Incluíram-se as operações de melhoria do funcionamento do site (como edição geral, mensagens globais, etc) assim como as de desenvolvimento da comunidade (atribuir recompensas, iniciar competições). Após a criação de uma primeira versão da listagem dos requisitos funcionais, o grupo deparou-se com o desafio de como filtrar a informação aí recolhida. A solução passou pela criação de arquétipos de utilizadores: personas baseadas nos vários tipos de utilizadores criados anteriormente e representantes do público-alvo. Encarnando então cada uma dessas personas, para cada requisito representado na tabela foi atribuída uma pontuação, a partir da qual foi feita uma média relativamente à sua importância. Foi então possível ver que a secção de interacção e pessoal se relevaram as mais importantes, estando o público-alvo potencialmente mais interessado nos aspectos comunitários, do que na ferramenta de desenho em si, apesar de esta também deter bastante importância. Tendo por fim estes resultados, verifica-se então que a área mais essencial para o sucesso da aplicação - e potencialmente a mais complexa - é a conjugação da ferramenta de desenho com a comunidade. A tabela completa pode ser visualizada em anexo.

1.6 – Viabilidade Técnica Recorrendo à listagem (anexo 3) dos requisitos necessários e tendo os mesmos em consideração, o grupo partiu em busca das melhores tecnologias a utilizar. Dividiu-se então em

Relatório de Projecto quatro categorias necessárias para pesquisar: Linguagens Server-Side, Linguagens Client-Side, CMSs e APIs de desenho vectorial. Convém mencionar a necessidade de um suporte físico em si para a aplicação, no caso deste projecto esse suporte são os servidores linlab da UA, visto serem os que nos estavam mais facilmente disponíveis. Relativamente às linguagens Server-Side, existe uma pletora de soluções possíveis de implementar. Entre elas encontram-se: PHP, ASP, ColdFusion e Lasso. Aqui a opção recaiu sobre o PHP pois ser a linguagem que nos era mais familiar e fácil de utilizar. As linguagens Client-Side incluíam como soluções Flash, Silverlight e Javascript. Para manter boas práticas de utilizações, optou-se por uma combinação de HTML+CSS+Javascript, conseguindo assim alcançar o maior número de utilizadores e dispositivos possíveis. De forma a facilitar não só o trabalho de criação como também o de manutenção, optou-se por utilizar um CMS ou plataforma de construção de redes sociais, aqui novamente o grupo dispunha de várias opções, sendo elas: Wordpress, Drupal, Joomla!, Elgg e Pligg. De entre eles, o Drupal aparentou ser o mais versátil e robusto de eles todos, pelo que foi ele o CMS adoptado. Por fim, uma das componentes mais importantes era a API de desenho vectorial. Aqui o grupo dispunha de duas soluções. A primeira era o SVG-edit, uma API open source de desenho vectorial sem restrições de uso. A segunda opção era a API de desenho vectorial da Aviary, o Raven. Esta última para ser utilizada precisava de um contrato de uso para ser utilizada. Visto a falta de tempo para ver se seriamos autorizadas a utilizá-la e à falta de vontade de utilizar as ferramentas da concorrência, a escolha recaiu naturalmente sobre a API SVG-edit.

Capítulo 2 - Design Funcional 2.1 – Especificação 2.1.1 – Nome O primeiro passo para a construção da identidade do nosso projecto foi a decisão sobre qual iria ser o nome, visto ser uma das componentes mais importantes da identidade de um site, precisando de ser sonante, reconhecível e fácil de dizer. Para tal, o grupo começou por analisar os nomes já existentes no mercado e procurar nomes que passassem a ideia das duas grandes componentes do projecto. A partir dessa pesquisa criou-se uma lista com diversos termos relacionados, que se tentaram combinar em um novo nome. Após várias iterações e sessões

Relatório de Projecto de brainstorming, juntamente com alguma colaboração por parte dos Orientadores, chegámos a uma lista final de cinco nomes: Draw It!, Canvas 2.0, Canvanize, Tabula Rasa, weDraw. No fim, a escolha recaiu sobre o último nome, visto a conjugação das palavras “we” e “draw” passar a ideia de um local onde se desenha em conjunto, tocando assim tanto a componente da comunidade e colaboração, juntamente com a do desenho e arte.

2.1.2 – Logo O logo weDraw retirou a sua inspiração de um dos termos que se utilizou durante a criação do nome e também em um dos conceitos Web 2.0. Este termo é o Cloud. Não tendo sido usado como nome por haver aplicações semelhares já usando o nome, optou-se por o usar na construção do logótipo. Dessa forma, temos aqui representado o aspecto da comunidade através de Fig. 1 - Logo

uma nuvem, que simboliza conceitos internet, partilha e trabalho

colaborativo. Juntamente com a nuvem foram adicionadas “pingas” de tinta, deixando transparecer o aspecto artístico de desenho aqui presente. Por fim, temos o próprio nome inserido no logótipo, fazendo recurso à fonte “Hiruko Black Alternate”, devido às suas formas simples e arredondadas, que tanto se adequam com o próprio desenho da nuvem, como com a ideia de vectorial (construção do logo demonstrada no anexo 4).

2.1.3 – Sistema Visual e Layout A base do sistema visual do projecto é o sistema 960gs (960 grid system) de 12 colunas. O que isto significa é que o layout do weDraw possui uma largura de 960px, divididos em 12 colunas, cada uma com uma largura de 60px e uma margem de 10px em cada um dos lados. Isto efectivamente leva a que exista uma

Fig. 3 – Sistema 960.gs

margem de 10px em cada um dos lados do layout, uma goteira de 20px entre as colunas e uma área útil de 940px de largura. Adicionalmente, utilizou-se uma grelha de baseline com intervalos de linha definidos em 15px como forma de melhor organizar e alinhar os conteúdos de texto com os conteúdos de Fig. 2 – Três Colunas

Relatório de Projecto imagem e dispositivos de interacção. A maior vantagem da utilização deste sistema de grelha é a sua modulação, podendo ser usado em diferentes configurações. No caso da weDraw, optou-se por um sistema de 3 colunas, cada uma com 300px. A partir dai, pudemos criar vários estudos de cinzentos para decidir efectivamente o layout de cada uma das páginas e construilo a pouco e pouco, ao longo de várias iterações que evoluíram desde o demo gráfica até ao produto final onde pequenos ajustes foram efectuados. Por fim, criou-se um template no drupal do nosso projecto e seguindo o estudo de cinzentos e desenhos de layout, fazendo recurso a css, php e os próprios módulos do drupal.

Fig. 4 – Grelha Final

2.1.4 – Cores A ideia inicial que se teve para o esquema cromático era a da aplicação ser como uma tela onde os vários autores se pudessem expressar e portanto não sobrecarregar a visão com muitas cores nem com

Fig. 5 – Paleta de Cores

cores fortes. Optou-se então por usar bastante o espaço em branco. Como não se pode ter um site somente em branco no entanto, usou-se um cinzento-escuro para a barra do footer e para os textos. Para os títulos e outras áreas da aplicação optou-se por um azul semelhante ao de logo e próximo do ciano. Escolheu-se essa cor por se acreditar que é uma cor agradável à vista e ser próxima de uma das cores básicas do sistema CMYK. Por fim, para obter algum contraste e destaque nos links, usa-se de forma bastante conservadora o magenta, que também é uma componente do sistema CMYK tanto usado em aplicações vectoriais. Assim conseguimos obter um contraste agradável e suave ao olhar.

Relatório de Projecto

2.1.5 – Tipografia Tratando-se de uma aplicação Web, é importante escolher fontes que sejam comuns aos diversos sistemas operativos e versões alternativas semelhantes às originais para quando essas não estiverem disponíveis, de forma a manter a coerência do site. Existem então dois tipos de fontes usados: Gill Sans MT para os títulos como primeira opção, com a Trebuchet MS como alternativa caso a primeira não esteja presente no sistema. Para os restantes textos, usa-se Verdana como primeira opção, seguido de Helvetica. Em último caso, se nenhuma das opções estiver presentes, o default para todos os textos e títulos é a Arial.

Fig. 6 – Exemplos Tipografia

Por fim definiram-se as seguintes dimensões para os textos, sempre com um leading de 15px: 

36pt para os títulos de maior dimensão;



18pt para os elementos na barra de navegação;



16pt para os títulos de menor dimensão;



12pt para os textos restantes e links;

Fig. 7 – Dimensões em uso

Relatório de Projecto Um caso único é a utilização de texto a 11pt no footer a cinzento com informação weDraw.

2.2 – Prototipagem 2.2.1 – Demo Gráfica Para o desenvolvimento do protótipo de baixa fidelidade o grupo ainda não dispunha de templates desenhados, tendo simplesmente listas de requisitos e um simples mapa de site. Optou-se então por não começar já a fazer recurso das várias linguagens de programação e construção de sites no desenvolvimento da parte gráfica do protótipo, mas sim por fazer um vídeo. O passo inicial foi então o de fazer vários mockups de uma landing page para a aplicação, acabando por se optar o que possuía um aspecto mais neutro e cujo layout nos pareceu mais interessante. Seguidamente, definiram-se dois percursos de interacção para as personas criadas (Artista Novato e Artista experiente, os perfis detalhados com mapas conceptuais de todas as personas podem-se encontrar em anexo) e criaram-se mockups para as secções que iriam ser visitadas por cada um. Por fim, criou-se uma animação em flash, narrada, que apresentou as duas personas que seriam seguidas ao longo do vídeo, as razões para utilizarem a aplicação e o seu percurso ao interagirem com a aplicação, juntamente com breves explicações sobre os passos que faziam e um pouco de humor para melhor captar a atenção. Um exemplo do mockup encontra-se no anexo 5. 2.2.2 – Protótipo de Alta-fidelidade Antes do desenvolvimento da versão Beta, foi antes necessário criar um protótipo de altafidelidade. O que isso significou foi a necessidade de definir concretamente um estilo gráfico para a aplicação, começando por rever o look and feel dos mockups para os transformar em algo que pudesse ser usado na versão final. A versão dos mockups fazia grande uso de cores escuras e cinzentos, mas como isso dava um aspecto algo sombrio, optou-se por inverter as cores e fazer uso do branco, juntando então à paleta as cores mencionadas anteriormente. Assim conseguiu-se um aspecto mais fresco e acolhedor. Relativamente ao layout, manteve-se essencialmente semelhante aos mockups, havendo ajustes ao longo de todas as páginas, em especial a de ficheiro e o desenvolvimento de novos templates para as páginas não tocadas anteriormente e algumas alterações no footer. No geral, 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. Adicionalmente, toda a estrutura da interface original da ferramenta de desenho foi alternada para maximizar o conforto e a funcionalidade. Adoptámos um aspecto o mais semelhante

Relatório de Projecto 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;

2.3 – Versão Beta Após finalizado o protótipo de alta-fidelidade, partiu-se para a construção da versão beta. Aí, tendo em consideração as críticas efectuadas ao protótipo e a adição de funcionalidades em falta e algumas novas, foram efectuadas novas, pequenas alterações ao longo de toda a aplicação, com vista a melhorar o seu aspecto, mas sem alterar de forma significativa o layout, de forma a incluir integração com redes sociais, melhor posicionamento dos dispositivos de votos, uma melhor organização dos perfis e formas de editar os mesmos. A partir desta altura, já se encontra algo fechado o design, pelo que não existem profundas mudanças relativamente ao criado anteriormente.

2.4 – Versão Final Tendo chegado à versão final, relativamente ao design e estilos gráficos da aplicação as únicas alterações efectuadas, são com o intuito de fazer um número de correcções gráficas, para corrigir alguns bugs visuais e tornar as acções dos utilizadores mais intuitivas e os resultados das mesmas mais perceptíveis, aumentando a qualidade do feedback devolvido, tendo como base falhas detectadas durante as fases de testes. Relativamente aos conteúdos, foram adicionados os elementos que estavam em falta e alguns textos alterados para tornar as suas funções mais perceptíveis.

Relatório de Projecto Capitulo 3 – Design técnico 3.1 – Especificação 3.1.1 – Arquitectura do site A especificação começa com a arquitectura do site. Nela, o grupo tentou da melhor forma descrever as relações entre as várias componentes do projecto, com especial atenção à relação entre o CMS e a ferramenta de desenho e, dentro do próprio CMS, aos diversos módulos escolhidos para a implementação dos requisitos funcionais definidos. O diagrama completo encontra-se em anexo 6.

Fig. 8 – Secção da Arquitectura

3.1.2 – Mapa de navegação De seguida apresentamos o mapa de navegação do site. Este pesa por alguma complexidade, inerente à complexidade do projecto. Como tal, encontra-se legendado, quer por tipo de funcionalidades como por nível de acesso, fazendo-se aí a distinção entre utilizador não registado, utilizador registado e moderador/administrador. Ao longo do seu desenvolvimento, o mapa foi sofrendo pequenas alterações ao longo do seu desenvolvimento, nomeante nas áreas que estariam acessíveis a cada pessoa e a adição ou remoção de áreas que estavam, respectivamente, em falta, ou desnecessárias. Um exemplo disso é a consolidação de todos os tipos de Galerias em uma só. A versão completa do mapa e outras versões podem ser visualizadas nos anexos 7.

Relatório de Projecto

Fig. 9 – Mapa Final

3.1.3 –Fluxogramas Tendo em conta que é na integração da ferramenta com o CMS que jaz o desafio central técnico da execução do projecto, os fluxogramas são centrados nas funcionalidades relevantes à gravação, upload e download de documentos vectoriais, servindo como forma de melhor compreender o funcionamento dos scripts presentes e os passos necessários para concretizar tarefas. Outras funcionalidades serão conseguidas recorrendo a diversos módulos já existentes e serão realizadas pelo Drupal de um modo quase automático e, de certa forma, algo opaco, pelo que não foram criados fluxogramas para as funções relacionadas com pesquisa, back office, pessoal ou interacção. Dos fluxogramas criados o mais complexo é, de longe, o relativo à

Fig. 10 – Fluxograma para download

gravação de documentos vectoriais. Essa questão foi já abordada anteriormente, onde se incluiu uma explicação inicial do processo. Este fluxograma detalha de forma mais aprofundada o processo de criação de um ficheiro representativo do documento vectorial e a interacção com a base de dados do Drupal e com o CMS em si, aquando da criação de nós. Considera questões como a autenticação de

Relatório de Projecto sessão, a identificação das criações e a gravação de versões - essenciais tanto para a definição do histórico de um documento como para a criação de documentos novos a partir de uma base já existente, o chamado forking. Outro dos fluxogramas criados, detalha a funcionalidade de upload de documentos vectoriais no formato SVG é também detalhada e incorpora em si o script de gravação de documentos vectoriais. Por último, o fluxograma relativo ao download quer de documentos vectoriais quer das respectivas representações bitmap, em formato PNG (anexo 8).

3.1.4 – Módulos CMS Para o desenvolvimento do projecto e após uma exaustiva pesquisa, criou-se uma lista sobre quais os módulos do Drupal a utilizar, assim como as suas funcionalidades e dependências. É importante referir que alguns módulos necessitam de outros para funcionar. Os módulos “pai” são: Views, ImageAPI, Content Construction Kit e votingAPI. Construção do site 

   

 

cck (Content Construction Kit) - permite a criação de “nodes” personalizados assim como a sua implementação; o linkimage - permite transformar imagens em links; dhtml menu - implementação de dropdown menus; pathauto - simplificação de urls; tagadelic - gestor de tags ImageAPI - “toolkit” para imagens; o Imagecache - processador de imagens; o imagefield - extenção de funcionalidades de nós do tipo imagem o thickbox - overlay de “moldura” para imagens; views - criação de queries personalizadas e mostrar os resultados; quicktabs - criação de blocos de contéudo com várias tabs;

Pessoal    

content profile - extensão das funcionalidades de criação de perfis (depende do módulo Content Construction Kit); logintoboggan - extensão das funcionalidades de login; activity - permite que utilizadores sigam a actividade dos amigos node_gallery - criação de galerias de imagens

Interacção    

organic groups - permite criar grupos de utilizadores e respectivas páginas de grupo; simplenews - permite criar e publicar newsletters; privatemsg - permite envio de mensagens privadas entre utilizadores; votingAPI - “toolkit” para sistemas de votos;

Relatório de Projecto o o o

 

plus1 - sistema de votos; fivestar - sistema de rating (depende do módulo Views); buddylist2 package - pacote para gerir amizades; Advanced Forum Flat Forum

É ainda importante referir que todas estas especificações são relativas e inseridas no contexto da especificação técnica inicial do projecto.

3.2 – Prototipagem 3.2.1 – Demo Técnica Para o desenvolvimento da Demo Técnica, o primeiro passo foi enunciar os passos que iriam ser demonstrados, para termos uma melhor ideia do que, ao certo, seria necessário fazer. Os passos decididos foram então os seguintes: 

Funcionamento de ferramenta de edição vectorial ;



Gravação de documento vectorial;



Listagem de documentos vectoriais criados pelo utilizador;



Recuperação de documentos gravados;

Para concretizar o vídeo e demonstrar os efeitos das acções, utilizou-se o MySQL workbench para aceder à base de dados e comprovar que o script PHP criado para ligar o SVGedit ao Drupal já se encontrava em funcionamento. Um diagrama foi usado para ilustrar de certa forma as acções a concretizar e um vídeo narrado para explicar os passos e o que esta a acontecer ao certo (O diagrama pode ser visualizado no anexo9). Fig. 11 – Diagrama de Interacção

3.2.2 – Protótipo de Alta-Definição Tendo em vista os objectivos para o desenvolvimento do protótipo de alta-fidelidade, utilizámos o mapa do site previamente construído e decidimos sobre quais as funcionalidades a implementar. Sendo um protótipo de alta-fidelidade, a sua construção será em “T”. Como demonstrado na figura seguinte, todas as páginas derivadas da página principal serão construídas, contudo, o detalhe de cada uma delas será diferente.

Relatório de Projecto

Fig. 12 – Escolha de ramos a desenvolver

Dentro da primeira categoria, existem dois níveis de prioridade. Os itens marcados com "prioridade alta" são os que foram desenvolvidos com vista a que todos os seus requisitos funcionais fiquem completamente implementados. Por outro lado, itens marcados como tendo "prioridade baixa" só foram trabalhados ao pormenor caso todos ou outros sejam fechados. Nas páginas categorizadas como "conteúdo estático", apenas o layout foi trabalhado, sendo que, em todas as regiões onde apareceria conteúdo dinâmico, este foi substituído por placeholders. As páginas a que foram dadas o nível de prioridade máxima foram: editor, ficheiros, galerias e perfis. Estas formavam, 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. Tendo estabelecido o que seria necessário fazer, 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. Esta interacção, revelou-se neste ponto com 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 e algumas funcionalidades como o histórico de ficheiros e forking ficaram momentaneamente por desenvolver.

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.

Relatório de Projecto Aí foram implementadas funcionalidades como uma galeria das imagens criadas pelo utilizador, carregada dinamicamente, mecanismos de subscrição e subscrições, notificações de actividade recente e vário conteúdo carregado dinamicamente. 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 nível das interacções, o Drupal suporta de raiz 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” tendo demorado um pouco mais para ficar completa. 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. 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 a este ponto se encontrava completamente funcional. Outro objectivo a que nos tínhamos proposto era o de traduzir toda a aplicação para uma só língua, 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. De forma geral e apesar dos diversos contratempos encontrados, especialmente tendo em conta as dificuldades de integrar e interligar a ferramenta de edição vectorial e o Drupal, foi feito um progresso considerável nesta fase do projecto, ao longo das diversas áreas da aplicação, preparado o caminho para as fases seguintes. Acima de tudo, foi adquirida uma quantidade considerável de experiência na criação e edição de conteúdos 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 conteúdos, 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, o mesmo pode ser visualizado com maiores dimensões em anexo.

Relatório de Projecto

Fig. 13 – Estado do desenvolvimento após prototipagem

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. 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 nesta versão levava 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.

3.3 – Versão Beta 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.

Fig. 14 – Áreas de desenvolvimento para a versão Beta

Relatório de Projecto 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: 

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;

Relatório de Projecto 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, novamente ficou 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. Dado que nenhum destes bugs comprometia 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. 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ções têm um link associado que redirecciona para páginas com a lista dos seguidores/subscrições.

Relatório de Projecto Os comentários ao ficheiro e as listas de amigos já foram referenciados. Fora o bug acima mencionado, os componentes encontravam-se a esta altura 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 encontravam-se já todas implementadas ou, não estando ainda implementadas, com o caminho preparado para as implementar. Para a versão final ficaram, então, por implementar, as seguintes componentes: 

Competições



Notícias



Ajuda



Documentação

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

3.4 – Versão Final O desenvolvimento da versão da versão final foi marcado por três fases bastante distintas.

A primeira fase resultou da mudança do servidor linlab onde o site está aplicado. Essa mudança trouxe bugs no funcionamento da aplicação, nomeadamente a nível da integração entre o SVG-edit e o Drupal.

De forma a não só voltar a colocar a aplicação ao nível de funcionamento anterior, mas também a garantir que tais erros não se voltem a verificar, todas funções referentes à gravação de imagens foram optimizadas com vista a permitir o seu funcionamento em qualquer servidor sem ser necessário editar código.

Outro problema com a mudança de servidor prendia-se com os links, associados a cada imagem, para abrir a mesma de novo no SVG-edit. Como estes links são introduzidos manualmente na base de dados e não são links relativos, não havia maneira de os alterar

Relatório de Projecto automaticamente aquando de uma mudança de servidor. Para colmatar esta falha foi escrito um pequeno script em PHP que permite actualizar estas ligações automaticamente.

Resolvidos estes problemas inesperados, foi possível entrar na segunda fase de desenvolvimento da versão final. Nesta fase, centrámos a atenção na funcionalidade de competições.

Esta revelou-se mais difícil de implementar do que o inicialmente previsto. Apesar de existirem diversos módulos para a votação de conteúdo e para a construção de galerias de imagens, não existe nenhum (há excepção do Competition http://drupal.org/project/competition, que não é compatível com a versão 6 do Drupal usada por nós) que permita fazer as competições como definidas por nós, que consistem em:

Administrador cria uma competição; Utilizadores podem submeter uma imagem já criada na competição; Utilizadores votam na galeria de imagens submetidas (tipologia de votos +1/-1); Administrador fecha competição; Imagem vencedora aparece em destaque na página da competição fechada.

Sendo assim, recaiu sobre o grupo a responsabilidade de criar de raiz as funcionalidades acima descritas. O resultado presente assemelha-se mais a uma prova de conceito que a uma versão finalizada da funcionalidade, mas responde já de forma satisfatória aos primeiros 3 passos, através de uma combinação de código-fonte criado de raiz por nós com funcionalidades de módulos já instalados.

Estando minimamente implementada a funcionalidade cuja ausência era mais gritante, passámos para a última fase de desenvolvimento. Nesta fase, o trabalho passou mais pela resolução de bugs de prioridade menor e da adição de pormenores de menor importância mas que, juntos, resultam numa melhoria significante da experiência de utilização do site. Estas melhorias são:

Back office/administração: 1. Barra de navegação para o perfil de administrador; 2. Criação de um tipo de conteúdo para divulgar notícias sobre o site, press releases, actualizações, etc.;

Relatório de Projecto Barra de navegação: 3. Adição de links no sub-menu comunidade: blogues, notícias, competição, lista de utilizadores; 4. Adição de um formulário de pesquisa; 5. Adição da opção “escrever mensagem” no sub-menu de “mensagens”;

Página principal: 6. Notificação de mensagens privadas novas recebidas; 7. Bloco de informação com as notícias mais recentes publicadas pelo administrador do site; 8. Bloco de discussões recentes com link para o fórum

Perfil: 9. Adição de botão para enviar mensagem privada ao utilizador 10. Adição de botões para seguir/deixar de seguir o utilizador 11. Edição dos textos das áreas “Entrada mais recente no blog” e “Actividade recente”. O utilizador que esteja a ver o seu próprio perfil é apresentado aí com vários links para criar conteúdo ou participar no site; 12. Páginas com listas de subscrições e seguidores funcionam correctamente e têm um link para regressar ao perfil

Página de ficheiro: 13. Votação em criações individuais (tipologia de 5 estrelas); 14. Botões de partilha com vários serviços e redes sociais; 15. Sistema de comentários refinado visualmente e com possibilidade de votar nos comentários (up/down, com comentários abaixo de determinado limite negativo de votos a ficarem acinzentados);

Por implementar ficou apenas a secção de ajuda e de documentação. Também o aspecto visual de alguns componentes do site pode ainda ser melhorado.

Relatório de Projecto Capitulo 4 – Síntese dos testes efectuados

4.1 – Tipos de testes A fase de testes tem como objectivo principal a investigação e utilização da aplicação, em contexto, para encontrar seus defeitos. Na timeline do projecto, a fase de testes está relacionada com a versão beta. Desta forma, os resultados apresentados serão todos relativos a esta versão. Com o objectivo de melhorar o projecto nas suas varias componentes, realizamos uma listagem dos bugs encontrados, testes de compatibilidade entre browsers, sistemas operativos e resoluções de ecrã, testes de segurança e testes de usabilidade.

4.2 – Resultados 4.2.1 – Listagem de bugs encontrados Após uma análise ao protótipo de alta-fidelidade, elaboramos uma lista dos bugs encontrados. Esta lista foi construída utilizando a ferramenta code.ua, não só para bug tracking mas também para controlar o desenvolvimento das funcionalidades ainda por implementar. Os bugs são categorizados segundo a sua prioridade e tipo. Achámos ainda importante diferenciar se é um bug do SVG-edit ou do Drupal.

Tabela 2- Tabela de bug tracking

Para a resolução dos bugs do SVG-edit relacionados com a interacção com o Drupal (login, etc.), foram usadas várias técnicas de verificação de código em PHP, nomeadamente: 

Fazer "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 semelhantes, os dados passados por POST;

Relatório de Projecto 

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.

4.2.2 – Testes de segurança 

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 de palavras-chave e tentar assegurar a existência de salt;

Vamos passar a apresentar os resultados dos testes, assim como as soluções que os problemas encontrados nos levaram 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 ( de base ou graças a 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 e 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 apenas na versão final, não se tratando no entanto de uma falha de segurança de grande gravidade.

Relatório de Projecto 2. Alterar parâmetros de url para tentar aceder a perfis e outras áreas exclusivas Tal como no ponto anterior, 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 conteúdo 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.

Fig. 15 – Resposta do sistema a valores inválidos

4. Tentar aceder directamente a ficheiros e directórios O acesso a directórios é impossível (o servidor retorna 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

Relatório de Projecto 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 Convém notar neste ponto uma mudança importante, relativa à aplicação testada quanto à usabilidade. O módulo usado nesses testes, Captcha, foi abandonado, 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 conteúdo submetido (se for considerado spam, o conteúdo é automaticamente recusado. Caso o conteúdo não seja obviamente spam nem conteúdo 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 conteúdo);



Mais informação sobre o serviço pode ser consultada aqui: Mollom.

Utilizando o modo de teste do módulo (que permite testar o comportamento do mesmo mediante vários tipos de conteúdo), 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.

Relatório de Projecto

Fig. 16 – Registo de actividade

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 Acutinex só revelou 4 erros e todos relativos a vulnerabilidades no servidor MySQL. Convêm 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.

Relatório de Projecto Se essa opção não for seleccionada, a sessão do utilizador é terminada aquando do fecho do browser.

4.2.3 – Testes de compatibilidade Para os testes de compatibilidade foram utilizados os seguintes dispositivos: 

Monitor de 24" Widescreen



Monitor de 19" 4:3



Android 3.5"



Magalhães



EeePC



Macbook 13"



iPhone 4

Tentámos abranger a maior variedade de dispositivos

Fig. 17 – 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: 

Windows ( 7, Vista, XP)



Mac OSX 10.6



Linux Caixa Mágica

E os seguintes browsers: 

Internet Explorer (7,8,9)



Mozilla Firefox



Google Chrome



Safari



Opera



Browser default do Android



Safari (iOS)

Fig. 18 – Sistemas Operativos

Fig. 19 – Browsers

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.

Relatório de Projecto Por fim, as seguintes resoluções foram consideradas:

Tabela 3 - Resoluções

O teste realizado consistiu no seguinte percurso: 



Consulta da página de perfil;



Criação de um desenho na ferramenta. Gravação do mesmo;



Consulta do perfil de um outro utilizador. Abertura e modificação de um dos seus desenhos;



Comentar uma das criações de outro utilizador;



Logout.

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. Os resultados com maior detalhe podem ser encontrados nos anexos (os resultados destes testes podem ser visualizados no anexo 10).

4.2.4 – Testes de usabilidade 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. Os mesmos podem ser encontrados no anexo 11. De seguida foi decidida a melhor forma de analisar os resultados. 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

Relatório de Projecto 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 (A grelha encontra-se em anexo).

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, aluna de Design 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.

Relatório de Projecto

Fig. 20 – Tempo vs acção (utilizadores)

Neste gráfico podemos então ver o tempo demorado pelo utilizador padrão (um dos membros do nosso grupo), seguindo o mesmo guião que foi dado aos utilizadores de teste. Para além do utilizador padrão, encontram-se representados os tempos demorados em cada passo pelos seis utilizadores e compará-los com os resultados do utilizador padrão no gráfico anterior. É 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.

Fig. 21 – Tabela de erros

O gráfico acima mostra os erros dados por cada utilizador em cada um dos passos, assumindose 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

Relatório de Projecto captcha que era necessário preencher, enquanto que no 9º passo, provinham 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. No entanto, 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.

Capítulo 5 – Síntese da estratégia de manutenção e suporte Uma das grandes vantagens da utilização do Drupal, é o backoffice por ele disponibilizado. Dessa forma, é possível a qualquer pessoa com privilégios de Administrador, editar o conteúdo presente na aplicação e assim corrigir quaisquer eventuais problemas. Em suporte dos utilizadores existem as secções de Perguntas Frequentes, contendo respostas para as dúvidas mais comuns. Um link no footer presente a todos os tempos abre um formulário de contacto para enviar as dúvidas directamente aos responsáveis pela aplicação. Por fim, existe uma secção no fórum dedicada ao suporte dos utilizadores onde também podem colocar as suas dúvidas ou ver se alguém já teve um dúvida semelhante e as respostas que teve. Por fim, caso se pretenda inserir novo conteúdo ou editar o já existente, foi criado um manual de identidade, contendo as regras de construção, utilização do logo, tipografia, sistema cromático e sistema visual.

Capítulo 6 – Análises Finais 6.1 – Análise Critica Ao longo do desenvolvimento do projecto, um dos maiores obstáculos com que nos deparámos, foi a integração da API do SVG-edit com o Drupal, mas apesar de a nossa solução

Relatório de Projecto talvez não ser a mais elegante, é sólida e funcional. Sentimos que alguns dos problemas e bugs que o mesmo nos deu talvez fossem resolvidos com recurso à comunidade de apoio e desenvolvimento do SVG-edit, mas infelizmente não obtivemos nenhum apoio da mesma, pelo que tivemos de contar apenas com nós mesmos. Em relação ao layout, olhando para trás, vemos sempre formas de o tornar mais eficiente ou atractivo, apesar de estarmos contentes com o que desenvolvemos, mas infelizmente, um redesign completo da aplicação nas últimas fases de projecto era simplesmente algo que não podíamos fazer sem comprometer as outras áreas de desenvolvimento e perder muito trabalho já feito, para além de não haver nenhum problema grave que o justificasse. Em relação à programação, a utilização do Drupal foi tanto uma vantagem como uma desvantagem. Por um lado, permitiu-nos obter logo de partida um backoffice completo e facilidade na construção de páginas e funcionalidades, por outro, tornou mais complicada a integração com o SVG-edit, mas em última análise, consideramos uma boa escolha termos optado por esse CMS para este projecto. Por fim, em relação ao grupo, consideramos que nos conseguimos articular e dividir da melhor forma para concretizar todas as tarefas necessárias, utilizando da melhor maneira as habilidades de cada membro.

6.2 – Sugestões de desenvolvimentos futuros Chegando à conclusão do projecto, existem sempre novas ideias que vão surgindo que não são implementadas por falta de tempo. Uma dessas funcionalidades seria a possibilidade dos utilizadores criarem galerias em conjunto, funcionando quase como um grupo de amigos. Outras funcionalidades, como sugeridas pelos utilizadores de teste, seriam a possibilidade de um utilizador criar um desenho como resposta, ao desenho de um outro utilizador (um funcionamento semelhante aos vídeos de resposta no youtube) e uma secção onde surgissem as criações mais votadas do dia, semana, mês, entre outros. Uma funcionalidade que ficou por implementar foi a de, tal como se pode ver a galeria das versões do ficheiro, ver-se também uma com as criações derivadas (ou forks) dele. Também o formulário de contacto não se encontra funcional, devido a questões do funcionamento do servidor que não tivemos oportunidade de esclarecer. Assim, o desenvolvimento da funcionalidade de perguntas frequentes foi descartado para uma ocasião futura. Apesar dela não existir, estamos confiantes que já existem canais de comunicação suficientes (blogs,

Relatório de Projecto notícias, comentários, fóruns) para dar resposta a quaisquer dúvidas que os utilizadores possam ter relativamente à utilização da ferramenta de desenho ou do site em geral. Relativamente ao layout, tivemos ideias para criar versões diferentes, pelo que futuramente, seria uma mais valia criar layouts alternativos, ou outros esquemas de cores e dar aos utilizadores a opção de escolher qual prefere, visto que nem todos gostam da mesma coisa e tratando-se isto de uma comunidade para artistas, os seus gostos serão ainda mais variados. A tradução tanto dos textos originalmente em inglês também é um outro ponto que futuramente poderá ser melhorado, clarificando os textos e eliminando eventuais erros. Por fim, um dos desenvolvimentos futuros mais importantes que se poderia fazer, era melhorar o funcionamento da API do SVG-edit, contribuindo para a aplicação que tornou este projecto possível, ou ainda melhor, desenvolver uma ferramenta de desenho vectorial de raiz para a weDraw.

6.3 – Problemas Encontrados e Soluções Ao longo do desenvolvimento, foram surgindo vários problemas e dificuldades, a maioria de pequenas dimensões e facilmente resolvidos, outros mais graves, requereram uma análise mais profunda. O maior problema com que nos deparámos foi a integração do Drupal com o SVG-edit e a passagem de valores entre ambos. Não existia nenhum módulo que o fizesse por nós, nem havia qualquer informação online sobre alguém que o tivesse antes, pelo que foi necessário criar um script de raiz para fazer a ligação. Infelizmente, tratando-se de duas componentes distintas, com páginas de código extensivas, essa ligação revelou-se por vezes instável mas conforme o projecto foi sendo desenvolvido, os bugs foram gradualmente sendo eliminados até ficarmos com um sistema muito funcional. Outro dos problemas encontrados já na recta final do projecto e ainda ligado com o SVG-edit, foi a troca de servidor do linlab. Visto as referências ao mesmo não estarem construídas da melhor maneira tiveram de ser substituídas, desta vez usando variáveis para indicar o caminho e apenas ter efectivamente a morada do servidor num único lugar, fácil de alterar. Isto irá permitir bastante facilidade caso seja necessário trocar de servidor futuramente.

Relatório de Projecto Capítulo 7 – Conclusões Para concluir, acreditamos que atingimos de boa maneira todos os objectivos, tanto aqueles que nos haviam sido propostos, como aqueles a que nos havíamos nós proposto. Ao longo do desenvolvimento deste projecto, também crescemos consideravelmente de forma técnica, desenvolvendo competências com o Drupal, com o qual nenhum nós havia trabalhado antes e com o desenvolvimento de layouts, através da utilização de grelhas e do sistema 960.gs, uma forma de trabalhar que anteriormente desconhecíamos. De forma geral, todos sentimos ter aprofundado os nossos conhecimentos e terminamos este semestre e este projecto, tendo desenvolvido competências que podemos usar futuramente no desenvolvimento de novos projectos e no melhoramento de projectos criados anteriormente.

Referências Bibliográficas Bibliografia SAFUTO, Robert, Beginners Guide to Drupal, 2011 HERREMANS, Dorien, Drupal 6: Ultimate community Site Guide, 2009

Webgrafia Google – www.google.com Drupal – www.drupal.org http://drupal.org/node/751826 Stackoverflow – www.stackoverflow.com w3schools – www.w3schools.com Drupalcontrib–http://drupalcontrib.org/ NetTuts+–http://net.tutsplus.com/tutorials/javascript-ajax/submit-a-form-without-pagerefresh-using-jquery/

Relatório de Projecto Anexos Índice de anexos: Anexo 1 – Gantt . ……………………………………………………………………………………………………………………41 Anexo 2 – Estado da arte .……………………………………………………………………………………………………..41 Anexo 3 – Listagem de requisitos…………………………………………………………………………………………...42 Anexo 4 – Construção do logo………………………………………………………………………………………………..43 Anexo 5 – Mock-ups especificação gráfica………………………………………………………………………………44 Anexo 6 – Arquitectura de sistema…..………………………………...………………………………………………….45 Anexo 7 – Historial Mapas de Navegação………..……………………………………………………………………..46 Anexo 8 – Fluxogramas…………………………………………………………………………………………………………..47 Anexo 9 – Diagrama de interacção…………………………………………………………………………………………48 Anexo 10 – Resultado dos testes de compatibilidade……………………………………………………………..49 Anexo 11 – Formato dos testes de usabilidade……………………………………………………………………….50

Relatório de Projecto Anexo 1 - Gantt

Anexo 2 - Estado da arte Devido às suas grandes dimensões, optamos por disponibilizar o link para a tabela que está alojada online.

Relat贸rio de Projecto Anexo 3 - Listagem de requisitos

Requisitos #

Requisito

Perfis

Prioridade / Importância

Utilizador Não Registado

Utilizador Registado

Moderador

Admin

Artista Experiente

Artista Novato

Administrador do site

Moderador do site

Crítico

Média (arredondada)

- Front End 1

Criação de documentos vectoriais (editor)

✓

--- Criação de shapes pré-definidas

✓

--- Criação de shapes originais (pen tool)

✓

--- Desenho livre (pencil tool)

✓

--- Edição de pontos

✓

--- Layers

✓

--- Edição/Definição de preenchimento

✓

--- Edição/Definição de strokes

✓

--- Inserção de texto

✓

--- Brushes

✓

Importação de ficheiros para o editor (SVG)

✓

Gravar documentos vectoriais (online)

✓

Edição/revisão de documentos vectoriais

✓

Acesso ao histórico do documento vectorial

✓

Upload de ficheiros para o site (SVG)

✓

Download de ficheiros (PNG/SVG)

✓

Colocar/remover tags documento vectorial

✓

Competições

✓

--- Participar em Competições

✓

--- Desistir de Competições

✓

--- Ver Resultados de Competições

✓

Criar Comentários

✓

3 3

--- Editar Comentários

✓

--- Apagar Comentários

✓

--- Reportar Comentários

✓

--- Promover Comentários (karma/reputação)

✓

--- Despromover Comentários

✓

Criar Discussões

✓

Criar Galerias

✓

Promover Discussões/Ficheiros (karma/reputação) Enviar Pedidos Amizade

✓

Aceitar/Recusar Pedidos Amizade

✓

Seguir actividade de outros utilizadores

✓

3 3

Requisitos #

Requisito

Perfis Utilizador Não Registado

Utilizador Registado ✓

Prioridade / Importância Moderador

Admin

Artista Experiente

Artista Novato

✓

Administrador do site 3

Moderador do site

Crítico

Média (arredondada)

Bloquear utilizadores

Partilhar links com outras redes

✓

Registo

✓

Fechar Conta

✓

Recuperar Password

✓

Editar Perfil

✓

3 3 3 3 3

Ver Lista de Amigos

✓

--- Remover Utilizador da Lista de Amigos

✓

Ver Perfis

✓

Ver Notícias

✓

Ver Galerias

✓

Ver Documentos Vectoriais

✓

Enviar/Responder/Ver Mensagens Privadas

✓

3 3 3 3 3 3

Feedback de interacção

✓

Perguntas Frequentes

✓

Tooltips/Ajuda Contextual

✓

Documentação

✓

--- Mapa do Site

✓

--- Guias de utilização do site

✓

--- Guias de utilização da ferramenta de edição

✓

--- Termos de utilização

✓

Vídeo/animação introdutória

✓

Formulário de contacto

✓

--- Envio de perguntas (a colocar nas FAQs)

✓

--- Envio de sugestões

✓

--- Envio de reclamações

✓

3 3

Pesquisa Documentos Vectoriais

✓

Pesquisa Utilizadores

✓

Pesquisa Discussões

✓

Pesquisa por Tags

✓

Organizar resultados pesquisa

✓

--- Popularidade (nº visualizações)

✓

Requisitos #

Requisito

--- Data de criação

--- Data de última edição

Perfis Utilizador Não Registado ✓

Utilizador Registado ✓

✓

Prioridade / Importância Moderador

Admin

Artista Experiente

Artista Novato

✓

Administrador do site 2

Moderador do site

Crítico

Média (arredondada)

✓

- Back End 69

Criar Competições

✓

--- Fechar Competições

✓

Atribuir Recompensas/Karma

✓

Editar Contéudos

✓

--- Editar Comentários

✓

--- Editar Discussões

✓

--- Editar Notícias

✓

Mover Discussões

✓

Banir Utilizadores

✓

Enviar Mensagens Globais

✓

Criar Notícias

✓

3 3

Ver Reports (contéudo ofensivo, etc)

✓

Editar Estatuto Utilizadores

✓

Legenda: Ficheiros Editor Gráfico Interacção Pessoal Ajuda Pesquisa Back End Importância/Prioridade: 1 - Pouco Importante 2 - Importante 3 - Muito Importante

✓

Relatório de Projecto Anexo 4 -Construção do logo O desenvolvimento do logótipo teve como base a fonte Hiruko, a partir dela ajustaram-se as letras com modificações nos vectores, com vista a torná-las mais interessantes. Através de uma combinação de elipses com strokes da própria letra, foi então possível construir a nuvem para o elemento de fundo ao qual foram adicionadas as gotas. Juntando tudo têm-se então finalmente, o nosso logótipo.

Relatório de Projecto Anexo 5 –Mock-ups Especificação gráfica Página Principal Fazendo uso do sistema de 3 colunas, agrupa menus na coluna esquerda, usando as outras duas em junção para conteúdos.

Ferramenta de Desenho Tendo em conta a necessidade de um canvas grande, nesta página optou-se por usar a largura inteira da janela em vez de apenas os 940 pixels

Relat贸rio de Projecto Anexo 6 - Arquitectura de sistema

ARQUITECTURA DE SISTEMA

SERVIDOR

CLIENTE

INTERNET

PHP png gravado no servidor link p/ imagem adicionado a BD

BROWSER

imagem png criada

POST

SITE

(dados da imagem)

node imagem criada no drupal

SVG EDIT

POST

DRUPAL

(dados da imagem)

COMMUNITY MODULES Construção do site

CORE MODULES

Content Construction Kit Link Image

DRUPAL API

Pessoal

CCK Filefield

CCK Imagefield

DHTML Menu QuickTabs

Content Profile Activity

Buddylist2

Embedded Media Field

Pathauto

Views

Node Gallery

Interacção

Organic Groups Tagadelic

Logintoboggan

Fivestar

Plus1

VotingAPI

ImageCache

Privatemsg ImageField

ImageAPI

Thickbox

A depende de B

Esta é a arquitectura de sistema do projecto weDraw, representativa das interacções efectuadas a nível do servidor e entre o servidor e o cliente. O projecto weDraw pretende criar uma comunidade para artistas, novatos ou experientes, unindo uma ferramenta de desenho vectorial online robusta com um sistema de ranking, competições, discussões e mais! weDraw 2011 - Projecto de NTC - DeCA - UA

Vector art de laptop, servidor, nuvem e bd de: http://www.clker.com

Relatório de Projecto Anexo 7 - Historial Mapas de Navegação

Página Inicial

Página Principal

Competições

Discussões

Notícias

Galerias

Comentários discussão

Comentários noticia

Editor

Perfis

Comentários Perfil

Lista Amigos

Mensagens Pessoais

Gerir Competições

Interacção Pessoal Ajuda Pesquisa Back End

Posts

Versões Anteriores

Comentários Ficheiro

Back Office

Gerir Utilizadores

Gerir Contéudos Utilizadores

Gerir Notícias

Reports

ACESSÍVEIS EM TODAS AS PÁGINAS E A TODOS OS UTILIZADORES

LEGENDA Editor Gráfico

Ficheiros

Galerias

Utilizador não registado

Footer Header Ajuda

Utilizador registado Moderador/Administrador Acessível a partir da página inicial (destaques) a qualquer tipo de utilizador.

Pesquisar

FAQ

Documentação

Contacto

Termos de Utilização

Guia de utilização do site

Guia de utilização da ferramenta

Resultados da Pesquisar

Este é o mapa de site do projecto weDraw, representativo da páginas constituintes do projecto e a da relação entre elas. As páginas estão codificadas por funcionalidades. Os caminhos estão codificados por nível de acesso. O projecto weDraw pretende criar uma comunidade para artistas, novatos ou experientes, unindo uma ferramenta de desenho vectorial online robusta com um sistema de ranking, competições, discussões e mais! weDraw 2011 - Projecto de NTC - DeCA - UA

PROTOTIPAGEM - ESCOLHA RAMOS

Página Inicial

Página Principal

Competições

Discussões

Notícias

Galerias

Comentários discussão

Comentários noticia

Mensagens Pessoais

Perfis

Galerias

Comentários Ficheiro

Comentários Perfil

Lista Amigos

Editor

Ficheiros

Back Office

Pesquisar

Ajuda

Resultados da Pesquisar

Versões Anteriores

FAQ

Posts

Gerir Competições

Gerir Utilizadores

Documentação

Gerir Contéudos Utilizadores

Gerir Notícias

Contacto

Reports

Guia de utilização do site

Este é o mapa do site tendo em conta a especificação dos compontentes da plataforma a serem desenvolvidos na fase de prototipagem. Esses componetnes estão assinalados a azul.

O projecto weDraw pretende criar uma comunidade para artistas, novatos ou experientesm, unindo uma ferramenta de desenho vectorial online robusta com um sistema de ranking, com petições, discussões e mais! weDraw 2011 - Projecto de NTC - DeCA - UA

Termos de Utilização

Guia de utilização da ferramenta

Página Inicial

Página Principal

Competições

Discussões

Notícias

Galerias

Comentários discussão

Comentários noticia

LEGENDA

Mensagens Pessoais

Perfis

Ficheiros

Galerias

Comentários Ficheiro

Comentários Perfil

Lista Amigos

Editor

Back Office

Pesquisar

Ajuda

Documentação

Resultados da Pesquisar

Versões Anteriores

FAQ

Posts

Contacto

Prototipagem Alta Fidelidade

Prioridade Alta

Prioridade Baixa

Gerir Competições

Gerir Utilizadores

Gerir Contéudos Utilizadores

Gerir Notícias

Reports

Layout (Contéudo estático) A desenvolver

Este é o mapa do site tendo em conta a especificação dos compontentes da plataforma a serem desenvolvidos na fase de prototipagem.

Guia de utilização do site

Termos de Utilização

Guia de utilização da ferramenta

MAPA DO SITE - FIM DA FASE DE PROTOTIPGEM

Página Inicial

Página Principal

Competições

Discussões

Notícias

Galerias

Comentários discussão

Comentários noticia

LEGENDA

Mensagens Pessoais

Perfis

Ficheiros

Galerias

Comentários Ficheiro

Comentários Perfil

Lista Amigos

Editor

Back Office

Pesquisar

Ajuda

Documentação

Resultados da Pesquisar

Versões Anteriores

FAQ

Posts

Contacto

Prototipagem Alta Fidelidade

Prioridade Alta

Prioridade Baixa

Gerir Competições

Gerir Utilizadores

Gerir Contéudos Utilizadores

Gerir Notícias

Reports

Layout (Contéudo estático) A desenvolver

Este é o mapa do site tendo em conta a especificação dos compontentes da plataforma que foram desenvolvidos na fase de prototipagem.

Guia de utilização do site

Termos de Utilização

Guia de utilização da ferramenta

VERSÃO BETA - DESENVOLVIMENTO

Página Inicial

Página Principal

Competições

Discussões

Notícias

Galerias

Comentários discussão

Comentários noticia

LEGENDA (prioridade de desenvolvimento)

Mensagens Pessoais

Perfis

Ficheiros

Galerias

Comentários Ficheiro

Comentários Perfil

Lista Amigos

Editor

Back Office

Pesquisar

Ajuda

Documentação

Resultados da Pesquisar

Versões Anteriores

FAQ

Posts

Contacto

Prioridade baixa

Prioridade normal

Gerir Competições

Gerir Utilizadores

Gerir Contéudos Utilizadores

Gerir Notícias

Reports

Prioridade alta

Prioridade urgente

Módulo concluído

Este é o mapa do site tendo em conta a especificação dos compontentes da plataforma que foram desenvolvidos na fase de prototipagem.

Guia de utilização do site

Termos de Utilização

Guia de utilização da ferramenta

Relat贸rio de Projecto Anexo 8 - Fluxogramas

FLUXOGRAMA DE DOWNLOAD DE DOCUMENTOS VECTORIAIS E FICHEIROS PNG

Utilizador está na página do ficheiro

Ficheiro público?

sim

não

utilizador com sessão iniciada?

não

Overlay login/registo

sim

Botões download "png "png" e "svg"

sim

Utilizador tem permissões p/ aceder ficheiro?

sim

não Carregou png?

Enviar pedido amizade

não

sim

download svg

download png

FIM

Este é o fluxograma representativo da funcionalidade de download de documentos vectoriais e respectivas representações bitmaps. Os links de download de svg e png recebem os respectivos dados da tabela Files: dados svg e path da imagem png. O projecto weDraw pretende criar uma comunidade para artistas, novatos ou experientes, unindo uma ferramenta de desenho vectorial online robusta com um sistema de ranking, competições, discussões e mais! weDraw 2011 - Projecto de NTC - DeCA - UA

Pedido aceite?

não

FIM

FLUXOGRAMA DE GRAVAÇÃO DE DOCUMENTOS VECTORIAIS

A extensão activada, server_open save, é incluída com a ferramenta SVG Edit e permite, aquando da gravação de um documento, a chamada de um script PHP.

SVG Edit + Extensão server_opensave

Utilizador grava doc. vectorial

script "svg_editor_save.php" carregado

image data (png) image data (svg)

Dados passados, por POST, para o script.

1. VERIFICAÇÃO DE SESSÂO E DADOS ADICIONAIS

DRUPAL API Funções necessárias para interagir com o Drupal

require './includes/bootstrap.inc'

Acesso a dados de sessão e base de dados

drupal_bootstrap (DRUPAL_BOOTSTRAP_FULL)

Utilizador tem sessão iniciada?

Overlay Login/Registo

não

Utilizador tem conta?

sim sim

não

Overlay gravação (nome, tags)

Form. gravação submetido

Feedback erro

não

Nome introduzido?

sim

2. GRAVAÇÃO DE FICHEIRO PNG E DADOS SVG (Função criada pelo grupo)

Estes são os dados sobre a imagem passados inicialmente, assim como os introduzidos pelo utilizador no formulário anterior.

data/vars (imagedata, doc title, tags)

EXTENSÃO PHP FILESYSTEM

Gravação ficheiro PNG

Funções Filesystem (Criar ficheiro+escrever dados png)

PNG gravado como "doc title"+ timestamp +".png"

Estabelecer ligação c/ BD Drupal

[Files] ID de versão original

Ficheiro já gravado?

sim

Query SELECT

Criação Registo

não

+path, title, svgdata ref. a id de original

Criação Registo

+path, title, svgdata

+Coluna tabela Files

3. CRIAÇÃO DE NODE NO DRUPAL

Recuperação de file id da coluna criada

Função Drupal Criação Node

Criação array c/ dados node

4. EDIÇÃO DE TABELA DE LIGAÇÃO ENTRE NODES E FILES

Query SELECT

[Nodes] ID do node criado

Query UPDATE

+file id

[Content_type_image] onde id = ID do node criado

Página Drupal da imagem nova

MODELO BD DRUPAL (RELAÇÃO ENTRE TABELAS RELEVANTES) FILES

NODES node id

file id ... svg data id de versão original

CONTENT_TYPE_IMAGE

...

id node id file id ...

Este é o fluxograma representativo da funcionalidade de gravação de documentos vectoriais criados através da ferramenta online. Mostra a integração inédita estabelecida pelo grupo entre a aplicação SVG Edit e o CMS Drupal. O projecto weDraw pretende criar uma comunidade para artistas, novatos ou experientes, unindo uma ferramenta de desenho vectorial online robusta com um sistema de ranking, competições, discussões e mais! weDraw 2011 - Projecto de NTC - DeCA - UA

FLUXOGRAMA DE UPLOAD DE DOCUMENTOS VECTORIAIS

Utilizador escolhe "Upload" no menu de navegação

Overlay Upload

Utilizador submete form Feedback erro

Ficheiro escolhido?

não

sim

Ficheiro válido? (svg)

não

sim

Nome introduzido?

sim

Upload SVG

Reunir dados a serem passados p/script gravação (nome, svg data, png data)

SCRIPT DE GRAVAÇÃO DE DOCS. VECTORIAIS

FIM

Este é o fluxograma representativo da funcionalidade de upload de documentos vectoriais criados através de ferramentas externas. Utiliza, para a inserção da imagem no Drupal, o script de gravação de documentos vectoriais. O projecto weDraw pretende criar uma comunidade para artistas, novatos ou experientes, unindo uma ferramenta de desenho vectorial online robusta com um sistema de ranking, competições, discussões e mais! weDraw 2011 - Projecto de NTC - DeCA - UA

não

Relatório de Projecto Anexo 9 -Diagrama interacção

Relat贸rio de Projecto Anexo 10 - Resultado dos testes de compatibilidade

Suporte IE7

Aspecto 2

Navegação 3

Ferramenta 0

Pontos Positivos

Pontos negativos

Todas as zonas do portal são acessíveis. O login/logout não revela problemas.

Em termos de aspecto, os rollovers não funcionam corretamente. A ferramenta não funciona (não aparecem os ícones).

IE8

IE9

Firefox

Chrome

Safari

Opera

Android (default browser)

Todas as zonas do portal são acessíveis. O login/logout não revela problemas. O aspecto é o pretendido. Todas as zonas do portal são acessíveis. O login/logout não revela problemas. O aspecto é o pretendido. A criação de conteúdos na ferramenta é funcional. O site é totalmente funcional.

O site é funcional. (Bug na importação de svg)

A ferramenta não funciona.

Não é possível abrir criações mais complexas.

Mais lento em relação ao Chrome. Ao desagrupar o conteúdo de um *. svg importado, alguns atributos como as cores são alterados completamente

Todas as zonas do portal são acessíveis. O login/logout não revela problemas. O aspecto é Nao carrega as imagens mais o pretendido. A criação de complexas conteúdos na ferramenta é funcional. Todas as zonas do portal são acessíveis. O login/logout não Nao carrega as imagens mais revela problemas. O aspecto é complexas. A navegação é o pretendido. A criação de consideravelmente mais lenta em conteúdos na ferramenta é relação aos restantes navegadores. funcional. Impossível criar imagens. Resolução Para pequenas consultas de do site inapriopriada para galerias,etc, é aceitável. dispositivos móveis. Impossível realizar login.

Suporte

iOS (Safari)

Legenda: 3. 100% funcional, sem qualquer problema estético 2- 100% funcional; alguns problemas de aspecto que não afectam o funcionamento 1- Problemas gerais de funcionamento; bugs. 0- 100% Não funcional

Aspecto

Navegação

Ferramenta

Pontos Positivos

Pontos negativos

Para o mesmo propósito do Android, apesar de ser dotado de melhor qualidade de visualização e navegação. A resolução elevada do ecrã utilizado no iPhone4, em conjugação com as ferramentas de zoom, tornam possível a navegação.

A utilização da ferramenta é praticamente impossível (apenas permite "cliques"). Impossível realizar o login.

Relat贸rio de Projecto Anexo 11 - Formato dos testes usabilidade

Grelha de Análise

Nome do Inqurido: #

Tempo Utilizado

Data: Erros

Observações

weDraw / NTC / DECA-UA / Junho 2011

Guião Cognitivo

Siga os passos enunciados na tabela e após conclusão responda às questões no final. Foi providenciado um espaço para curtos comentários sempre que ache que tal é relevante. Caso tenha alguma dúvida de interpretação não hesite em pedir esclarecimento.

# 1

Passos Registe-se na aplicação

Abra o editor vectorial.

Utilize as ferramentas ao seu dispor para criar e salvar um simples desenho.

Actualize os campos do seu perfil de utilizador.

Actualize um dos seus desenhos e mude por exemplo as cores.

Visite os perfis de outros utilizadores

Abra a criação de um outro autor e faça uma simples alteração.

Dê o seu feedback à criação de outro autor.

Participe nas discussões do fórum.

Termine a sua sessão.

weDraw / NTC / DECA-UA / Junho 2011

Guião Cognitivo

Por favor responda às seguintes questões:

1 - Sentiu alguma dificuldade com qualquer um dos passos?

2 - Achou algum dos passos ou funcionalidades pouco intuitivo?

3 - Existe alguma funcionalidade que sinta que esteja em falta e gostaria de ver adicionada?

4 - De 1 a 5, sendo 1 não interessado e 5 muito interessado, como classificaria o seu interesse em voltar a utilizar esta aplicação? 1

5 - Conhece outras aplicações online similares?

6 - Tem alguma sugestão para corrigir ou melhorar as funcionalidades percorridas?

weDraw / NTC / DECA-UA / Junho 2011