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

A demo técnica apresentada neste post segue o formato screencast e é narrada pelo membro do grupo Francisco Ferreira.

 

 

 

 

A demo segue, quase à letra, a lista de funcionalidades enunciada no post anterior, "Demo Técnica: o que está para vir", com algumas excepções:

  1. A criação de conta foi ignorada, sendo uma conta "admin" criada anteriormente usada. Sendo a criação de uma conta um aspecto básico de qualquer CMS, este passo foi considerado negligível;
  2. A recuperação de documentos é demonstrada, mas não é uma funcionalidade que se encontre, de momento, implementada, por motivos que são explicados no decorrer do vídeo. A demonstração foi feito com acesso à base de dados através do programa MySQL Workbench;

Uma versão do vídeo com maior qualquer vai ser, até ao fim de amanhã, carregada, sendo nessa altura este post alterado com a nova versão.

 

EDIT: Como foi dito, apesar do atraso, já se encontra disponível uma versão do vídeo com mais qualidade, consultável acima. O vídeo original continua acessível aqui.


Na reunião de hoje, mostramos o trabalho realizado nas duas demos. Ambas estão na fase final, faltando apenas terminar alguns pormenores e fazer o vídeo. Foi também necessário alterar a maneira como o percurso de interacção da demo gráfica estava estruturado para facilitar a sua leitura e compreensão. Relativamente a demo técnica, definiu-se como iríamos transformar em vídeo a integração das tecnologias utilizadas (drupal, svg-edit).


Activity – faz uma listagem de toda a actividade que os membros realizam e a qual os seus amigos têm acesso.

http://drupal.org/node/328429

Author Pane – guarda a informação sobre o utilizador quando realiza posts ou comentários.

http://drupal.org/node/367288

Buddylist Package – pacote com quatro modulos para redes sociais. Estes módulos tratam dos convites para amigos e contêm uma aplicação para encontrar a “rota” mais curta entre dois uilizadores.

http://drupal.org/documentation/modules/buddylist2

Comment Notify – Notifica os utilizadores através de e-mail sobre comentários realizados onde eles próprios já tenham comentado.

http://drupal.org/node/252697

Facebook-style Micropublisher – imita o “mural” do facebook.

http://drupal.org/node/876500

Front – este modulo desenvolve uma pagina de entrada onde é mostrado ao utilizador os membros do seu grupo de amigos e os eventos agendados.

http://drupal.org/documentation/modules/Front

Gigya – autentica utilizadores através de outras redes sociais. Os utilizadores podem enviar convites para o site. Manda actualizações de estado para outras redes sociais.

http://drupal.org/node/538106

Profile setup – permite ao utilizador personalizar e definir os tipos de perfis.

http://drupal.org/node/604360

Radioactivity – permite votos e comentarios como formas de definir o que é popular ou não na rede.

http://drupal.org/node/338101

Slinky – crianção de ícones “Share This”

http://drupal.org/node/1083302

User tag – os utilizadores definem-se com “tags” sendo depois possível agrupa-los consoante essas mesmas “tags”.

http://drupal.org/node/44158


29
Mar 11

Aqui estão os esboços dos percursos de navegação e interacção a ser incluidos na demo gráfica. Os ecrâs são apenas representativos e não finais, sendo isto um work in progress.


Percurso Artista Novato:

 

1º - Acede à pagina inicial e clica para se registar

2º - O registo em si. 3º - Acede à página principal e clica nas discussões

4º - Acede à página das discussões e clica em um tutorial

 

5º - Visualiza um tutorial e acede às paginas de ajuda

6º - Da página de ajuda, clica no botão "create" para ir ter à ferramenta de desenho

7º - Na ferramenta em si, tenta criar algo que depois submete

8º - Ao submeter, é levado para á pagina do ficheiro, onde o visualiza


Percurso Artista Experiente:

1º - Acede à página inicial e clica para exprimentar imediatamente a ferramenta de desenho

2º - Cria algo na ferramenta que tenta salvar, sendo levado para a página de registo

3º - O registo em si.

4º - Completado o registo, é levado para a página do ficheiro, onde o visualiza, recebe comentários e carrega em "see all" para os visualizar a todos

5º - Lê os comentarios e por curiosidade clica no nome de um dos utilizadores, sendo levado ao perfil dele.

6º - Observa as criações  recentes listadas no perfil e clica em uma, sendo levado para a página desse ficheiro.

7º - Escreve no campo de comentário algumas "dicas", sendo levado de volta ao perfil do utilizador ao submeter

8º - Visualiza novamente o perfil e clica em follow para adicionar o utilizador à lista de amigos



A galeria está representada mas não está ligada a nenhum dos percursos, está presente meramente para mostrar um exemplo da página que surgiria após uma pesquisa de ficheiros ou a visualizar os ficheiros ou galerias de um utilizador.

 

Ambos os Percursos
Artista Experiente
Artista Novato

Na aula de projecto de 2ª feira, e em conversas subsequentes com os orientadores, ficaram definidas as especificações para a demo técnica, trabalho para à cuja já tinha sido iniciada no fim de semana.

Foi decidido que as seguintes funcionalidades serão demonstradas:

  1. Criação de conta no CMS eleito na fase anterior (Drupal);
  2. Funcionamento de ferramenta de edição vectorial (svg-edit);
  3. Gravação de documento vectorial;
  4. Listagem de documentos vectoriais criados pelo utilizador;
  5. Recuperação de documentos gravados;

A funcionalidade de gravação de documentos vectorais já se encontra implementada e segue a lógica mostrada na seguinte imagem:

 

 

Para a recuperação de documentos, basta abrir o editor passando os dados svg+xml por GET.


18
Mar 11

Tecnologias Client-Side - APIs


Independentemente do CMS escolhido, ou mesmo se optarmos pela construção de raiz, teremos sempre em conta que este projecto irá utilizar uma ferramenta de edição vectorial online. Criar uma de raiz foi um desafio que foi já posto de parte. Sendo assim, foi feito uma pesquisa no sentido de encontrar soluções possíveis de serem implementadas na aplicação. As opções que temos neste aspecto são:


SVG-EDIT:





AVIARY:




Ambas as ferramentas cumprem os nossos requisitos funcionais e têm uma facilidade de integração relativamente semelhante.


Se optarmos pelo svg-edit, teremos acesso a todo o código da ferramenta (desenvolvido em Javascript e open source) e o controlo completo da sua implementação, funcionalidades e interacção com o resto da aplicação. Há o senão de não haver nenhum módulo, em qualquer dos CMS considerados, que faça a integração com este API, ficando a mesma a nosso cargo.


Com o Aviary, estaríamos a utilizar uma ferramenta proprietária e desenvolvida em Flash. Isto levanta vários problemas: os documentos vectoriais gravados seriam armazenados na base de dados da Aviary - seria necessária a conexão entre as contas do Aviary e as contas de utilizadores da nossa plataforma. Também há o aspecto de utilizar funcionalidades de um aplicação efectivamente “concorrente”, que iria guardar na sua base de dados todas as criações dos nossos potenciais utilizadores, com potencial desvio de parte do nosso público-alvo para uma aplicação concorrente. Essa dependência também significa a perca de controlo de um dos pilares da nossa aplicação: a existir, por exemplo, uma falha na aplicação do Aviary, a nossa aplicação ficaria comprometida sem que nada pudesse ser feito do nosso lado para repor a funcionalidade. Por outro lado, o Aviary garante-nos uma ferramenta de qualidade superior ao svg-edit, para além de que a implementação, a nível do Drupal, está já assegurada por parte de um módulo existente.


 

Conclusão


Todo o trabalho de levantamento de requisitos e de soluções técnicas serviu, para ancorar o projecto que ainda se encontrava pouco definido. O desenvolvimento da lista de requisitos funcionais ajudou a definir melhor e é, salvo revisões futuras pontuais (como sempre acontecem), o documento orientador para as escolhas finais.


A nível das soluções técnicas, avançamos com as soluções que melhor respondem aos critérios estipulados para as prioridades dos diferentes perfis de utilizador, implementação técnica da ferramenta de desenho e integração na comunidade. Uma vez que o grupo não tem experiência de trabalho em muitas das tecnologias consideradas (CMSs, APIs), só na fase de prototipagem é que será possível averiguar qual é a solução mais adequada. Sendo assim, decidimos apresentar por ordem os conjuntos de soluções mais realistas, tendo em conta todas as análises acima apresentadas. Como já foi referido, a tecnologia a usar, de forma genérica, para todo o aspecto client-side da aplicação, será o conjunto HTML+CSS+Javascript. A partir daí, surge um número de “combinações” possíveis, entre os CMS e APIs considerados.


Solução escolhida

A nossa primeira opção passa pela combinação do CMS Drupal com a API de desenho vectorial svg-edit. O foco está na manutenção do controlo sobre todos os aspectos da aplicação.

Esta é a solução mais ambiciosa, mas que representa um desafio técnico mais interessante, enquanto experiência de aprendizagem, uma vez que estas plataformas nos podem fornecer um know-how inovador.


Alternativas

Caso algum desses elementos (CMS ou API) não seja viável, irá ser usada a solução alternativa de Joomla como CMS (caso seja o Drupal a falhar) ou então de Raven (a API do Aviary) como ferramenta de desenho.


A última opção centra-se, não na utilização de um CMS, mas na criação do código manualmente recorrendo às tecnologias de PHP/MYSQL, apoiadas por CSS e Javascript. Relativamente à API irá se manter como na primeira opção, dando-se prioridade à API svg-edit e em segundo lugar à API do Aviary (Raven).

 


Tecnologias Client-Side - CMSs



Para a construção e desenvolvimento do site, podemos utilizar alguns dos conhecimentos previamente adquiridos e construí-lo de raiz, ou utilizar um CMS (Content Management System) que através das suas funcionalidades e extensões, permitem chegar ao mesmo resultado. Cada uma destas opções tem as suas vantagens e desvantagens. Ao optarmos pela construção de raiz, temos um maior controlo sobre o código e teremos mais liberdade durante o desenvolvimento utilizando as nossas soluções. Se escolhermos utilizar um CMS, encontramos o desafio de aprender algo em que nenhum elemento do grupo tem experiência. Nesta opção, deparamo-nos também com grandes comunidades de “developers”, que, com o seu trabalho para estas plataformas, desenvolveram muitas das soluções que queremos utilizar. Desta forma teríamos que desenvolver alguma agilidade na filosofia dos CMS e conseguir integrar da melhor maneira os módulos ou extensões já desenvolvidas. Os CMS que se seguem demonstram ter as características necessárias ao desenvolvimento do nosso projecto.

Wordpress: “Express yourself. Start a blog”






Joomla: “The dynamic portal engine and content management system”




Drupal:” Come for the software, stay for the community”



 


 

 

Elgg: “Providing you with the core components you need to build out socially aware applications”

 


 

Pligg: “The Social Publishing CMS”

 




 


(carregar na imagem para aceder ao documento)


Através desta tabela, pretendemos demostrar as fraquezas e as forças de cada um destes CMs. Concluimos que as melhores opções são o Drupal, Joomla e Wordpress. O Drupal, embora tenha uma curva de aprendizagem que nos pode dificultar a vida, tem uma grande comunidade de “developers” e uma grande variedade de módulos e expansões que facilitam a integração de funcionalidades. O Joomla revela-se uma boa opção pelas mesmas razões que o Drupal e por ainda possuir um plug-in direccionado a construção de redes sociais. O WordPress tem como vantagens a inexistência de publicidade nos templates (banners publicitários por exemplo), a grande variedade de widgets e aplicações, a sua grande comunidade, e a sua ferramenta de construção de redes sociais (“Buddy Press”), representa também uma boa opção de CMS a utilizar.

 


Tecnologias Client-Side


Da perspectiva client-side, dividimos as possibilidades em três grupos ,uma vez que não seria de todo útil avaliar algumas das tecnologias individualmente, como o CSS e o JavaScript, que são utilizados num contexto de integração no HTML.


Analisámos também o XML, uma vez que este desempenha um papel fundamental na manutenção dos dois últimos suportes por nós referenciados.


XML

O que é?

XML (de Extensible Markup Language) é um conjunto de regras para codificar documentos num formato legível pelas máquinas, produzido pelo W3C e com foco na simplicidade de uso e utilização pela internet.


Forças

  • Foi originada numa instituição de padronização, a W3C.

  • É baseada em texto.

  • Suporta Unicode.

  • É editável, devido à popularidade do XML nos dias de hoje, com diferentes níveis de automação, em qualquer ambiente.


Fraquezas

  • Demasiado complexo, ao lado das alternativas. Dificilmente utilizável pelo utilizador "leigo".

  • Pode ser substituído por formatos mais simples como o YAML e JSON.


Fontes


CSS + HTML + Javascript

O que é?

O conjunto mais utilizado actualmente no desenvolvimento para Web. A ideia seria utilizar o css para estruturação de layouts/aspecto gráfico, o HTML como base, e o JavaScript para animações e interacção avançada.


Forças

  • As páginas desenvolvidas deste modo tendem a ser mais "leves" que as geradas nas outras duas tecnologias aqui apresentadas.

  • Após a implementação do template, a facilidade de manutenção é bastante elevada. Os conteúdos respectivos aos 3 pólos (css, html, javascript) são armazenados em documentos separados.

  • Fácil estruturação e separação do conteúdo (HTML / CSS / JavaScript).

  • Páginas suportadas pela maioria dos dispositivos móveis.

  • Funcionalidades de animação cada vez mais complexas (em termos de visualização), mas facilmente implementáveis através de inúmeros plugins (como o jQuery) .


Fraquezas

  • Exigem um grau superior de literacia (comparado com as restantes tecnologias aqui apresentadas) e competências de programação (javascript). Existem no entanto disponíveis bastantes bibliotecas de funções, e plugins, que têm como objectivo a simplificação da introdução de recursos. (jQuery, Prototype, Dojo).

  • Alguns elementos mais avançados nas últimas versões de CSS e JavaScript, não são suportados por todos os browsers.

  • Alternativas como o Adobe Flash são mais orientadas para designers e animadores, sendo possível "escapar" às linguagens de programação.


Fontes


Adobe Flex ( + Adobe Flash )

O que é?

O Flex é uma tecnologia desenvolvida pela Adobe para a criação de aplicações ricas na Internet, baseadas na plataforma do Flash. É o concorrente directo do Mircosoft Silverlight, partilhando algumas funções como a compatibilidade multi-plataformas, a integração da linguagem XML, orientação da linguagem para objectos, ferramentas dedicadas à compilação, e suporte directo com JAVA e AJAX.


Forças

  • Destaca-se no entanto por ter ferramentas direccionadas para designers, e pela integração com os diversos produtos da Adobe.

  • Linguagem orientada para objectos

  • Acesso facilitado a serviços web e comunicação directa com todo o tipo de tecnologias server-side

  • Ferramentas dedicadas ao Design

  • Suporte directo com JAVA e AJAX, para além de suporte para XML


Fraquezas

  • Falta de integração de linguagens de programação utilizadas no restante desenvolvimento para Web e offline.

  • Não é adequada para a implementação da totalidade de um website, mas sim para aplicações e secções da aplicação.

  • Os resultados não são tão fluídos como os apresentados utilizando CSS+HTML+JavaScript.

  • Problemas de integração com os motores de busca


Fontes



Microsoft Silverlight

O que é?

O Silverlight tem todos os aspectos referidos anteriormente, apresentando também algumas vantagens. É importante realçar que aparece 10 anos mais tarde em relação ao Flash, que se encontra neste momento integrado na maioria dos sistemas.


Forças

  • Nos pontos positivos é importante destacar o suporte com Visual Basic, e C#.

  • Conteúdos facilmente identificáveis pelos motores de busca

  • Linguagem orientada para objectos

  • Acesso facilitado a serviços web XML

  • Suporte directo com JAVA e AJAX


Fraquezas

  • A tecnologia e muito recente, sendo então pouco desenvolvida e tendo prevista uma fraca penetração no mercado a curto prazo.

  • Incompatível com versões antigas do Windows, como o Windows 2000 e 98.

  • Necessidade de software específico para suporte.


Fontes


Optou-se pelo uso de HTML + CSS + Javascript, por todas as vantagens apresentadas anteriormente. O desenvolvimento de uma aplicação em Silverlight ou Flex, apresentaria uma maior complexidade de interacção com as bases de dados que acabaria por não compensar. As tecnologias escolhidas são do domínio do grupo, o que facilita a aposta em outras vertentes do trabalho.


A utilização tanto do Flex (Flash) com o do Silverlight, traria acima de tudo problemas de fluidez de utilização do portal. Uma vez que se pretende agrupar bastantes funções, a simplicidade é um factor fundamental que terá que ser respeitado ao máximo.


No seguimento dessa escolha, há toda uma série de tecnologias para o desenvolvimento quer de comunidades quer da ferramenta de edição vectorial que necessitam de ser analisadas. A nível da construção dos mecanismos que irão possibilitar a interacção entre utilizadores e a manipulação da base de dados subjacente, foram considerados vários Content Management Systems, a apresentar de seguida.


Viabilidade Técnica


Tendo sido feito o levantamento dos requisitos funcionais, pode passar-se para a elaboração do estudo de viabilidade técnica. As categorias atrás mencionadas tornam-se desnecessariamente específicas, dado que quaisquer tecnologias que sejam, em última análise, utilizadas na concretização das várias funcionalidades da comunidade (interacção, pessoal, ajuda, etc) são bastante abrangentes.


Assim, para efeitos de viabilidade técnica, é feita a divisão entre server-side e o client-side, e aí a distinção entre as tecnologias usadas necessárias para o desenvolvimento da ferramenta de edição vectorial e as usadas em todo o resto da aplicação. necessárias para o desenvolvimento da comunidade online.


Relativamente às tecnologias server-side, convém notar, antes de mais, a incógnita relativamente às características do servidor da UA. Sem conhecer todos os detalhes do mesmo é impossível tomar uma decisão final relativamente a este campo.


Feita essa ressalva, foram consideradas várias tecnologias server-side, a apresentar de seguida.


Tecnologias Server-Side

Uma das componentes mais importantes, senão essencial, para o desenvolvimento de uma aplicação web são as tecnologias e linguagens do lado do servidor. É graças a elas que se torna possível a implementação de vasto número de funcionalidades e a criação de comunidade virtuais, algo que não é viável somente com recurso a HTML e tecnologias client-side.


PHP

O que é?

PHP (originalmente de Personal Home Pages, actualmente de PHP: Hypertext Preprocessor), é uma linguagem server-side e orientada a objectos, que pode ser embebida em html e é utilizada para o desenvolvimento e construção de páginas web dinâmicas.


Forças

  • Pode ser utilizado em diferentes plataformas. (Windows, Linux, Unix, etc.)

  • É compatível com virtualmente todos os servidores utilizados actualmente (Apache, IIS, Mysql, etc.)

  • Fácil de aprender e eficiente.

  • Gratuito e com documentação em diversas línguas.

  • Flexível.

  • Comunidade muito extensa de utilizadores.


Fraquezas

  • Linguagem pouco restrita pode levar a problemas de programação e resolução de erros.

  • Inicialmente mais lento a executar que outras linguagens.

  • Devido a actualizações, algumas funções têm funcionalidades ambíguas.


Fontes


ASP

O que é?

ASP (Active Server Pages) é uma linguagem server-side, para a geração dinâmica de páginas web criada pela Microsoft. Possui propriedades semelhantes ao PHP.


Forças

  • A utilização de ASP.NET melhora a performance da linguagem em numerosos aspectos.

  • Módulo de Data Caching que reduz a utilização da memória.

  • Flexibilidade de programação, podendo também usar VBScript ou Microsft JScript para programar, com módulos para python, perl e outras linguagens.

  • Facilidade de uso visto ser apenas necessário embeber o código em uma página de HTML.


Fraquezas

  • A necessidade de ASP de correr em servidores Windows aumenta consideravelmente os custos de utilização.

  • Velocidades mais baixas devido à arquitectura COM.

  • Dependente de produtos Microsoft.

  • Necessita algum conhecimento de Virtual Basic para migrar para ASP.


Fontes


ColdFusion

O que é?

A ColdFusion é uma linguagem de desenvolvimento ágil para a web, desenvolvida pela Macromedia e agora pertencente à Adobe.


Forças

  • Não necessita de servidores de teste.

  • Linguagem vêm junta com uma aplicação que ajuda na sua escrita.

  • Suposta um variado número de sistemas operativos.

  • Parecença com HTML torna-a fácil de aprender.


Fraquezas

  • Não é uma ferramenta gratuita.

  • Pode ser instável e lenta online por ser baseada em Java.

  • Estrutura da linguagem é muito restritiva e obriga a utilizar uma linguagem secundária chamada CFScript.


Fontes


Lasso

O que é?

Lasso, desenvolvido pela LassoSoft, é uma linguagem server-side orientada a objectos que também integra as capacidades de um servidor (Como Apache ou Mysql). É utilizada para o desenvolvimento de aplicações online.


Forças

  • Fácil de utilizar e implementar, especialmente para quem tenha pouca experiência de programação.

  • Abstracção de dados permite que não se programe para uma fonte de dados em especifico e facilita a sua transição.

  • Pouca divulgação permite uma maior segurança.

  • Suporte para muitas plataformas.


Fraquezas

  • Linguagem paga, com custos elevados.

  • Abstracção de dados abranda várias etapas do processo criativo.

  • Pequena comunidade de apoio.


Fontes


Destas quatro tecnologias server-side analisadas, a “Lasso” e a “ColdFusion”, devido aos seus custos proprietários elevados, são excluídas de uso no desenvolvimento do projecto. Resta então o “PHP” e o “ASP”.


De entre essas duas tecnologias, o “ASP” depende do uso de servidores Microsoft, que são menos versáteis e trazem um custo associado. O “PHP” no entanto, é open source, gratuito e algo que funciona bem com o MYSQL que se encontra instalado nos servidores UA. Optou-se então pela utilização do “PHP”, evitando assim custos e conflitos de servidores.

 

 

 


 

"Em todas as épocas da história a hora que se apresentou actual foi de indecisão e de escolha; em todas elas, para que alguma obra surgisse, foi necessário um projecto; o projecto parte do presente, só pode existir mesmo no presente, mas é uma condição de futuro; simplesmente, para que ele se realize, para que depois nele se baseiem outras organizações de ideias, é necessário um acto de vontade."

Agostinho da Silva

 

No fim de todo o processo imaginativo, chega altura de pôr mãos à obra. As ideias não faltam (felizmente não surgiram até à data problemas de tal ordem), assim como a vontade comum em erguer um projecto pioneiro. É nesta fase que tomamos consciência dos nossos conhecimentos actuais e dos conhecimentos que necessitamos de adquirir (e qual a sua viabilidade).


Apresentamos então o nosso trabalho das duas últimas semanas, concentrado em dois aspectos fundamentais: Os Requisitos Funcionais, e a Viabilidade Técnica.

 

 

Requisitos Funcionais

 

 

 

Tabela_Requisitos

(carregar na imagem para aceder ao documento)

 

 Na área dos requisitos funcionais, dividimos a 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 a perspectivas das várias personas, representativas do público-alvo.


Na coluna dos Requisitos, listámos as funcionalidades desejadas no produto final. Estes foram divididos em front e back-end, e posteriormente agrupados em conjuntos semelhantes de funcionalidade.


No front-end:

  • Requisitos relativos aos ficheiros: todas as operações que envolvem a utilização da ferramenta de desenho vectorial. Inclui funções como a 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ímos 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).

 

Exercício de Análise:


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. Através dessas personas, foi-nos possível obter novas perspectivas sobre o projecto e lançar um novo olhar sobre os requisitos do mesmo.

Encarnando então cada uma dessas personas, para cada requisito representado na tabela foi atribuída uma pontuação. No final, foi feita uma média que nos permitiu organizar por nível de relevância para o público-alvo os requisitos. Com essa informação, torna-se então possível saber onde concentrar inicialmente os esforços para atrair e manter o público-alvo, tal como também identificar as ferramentas de menor interesse para as melhorar.

 

 

(carregar na imagem para visualizar)

 

 

Para realizar o exercício foram criadas no total 5 personas: O artista experiente, o artista novato, o critico, o moderador e o administrador. Para cada um também foi criado um mapa conceptual de interesses, baseado na listagem de requisitos e em um mapa conceptual desenvolvido para a aplicação.

  


O Artista Experiente

  

 

Esta persona representa um utilizador tipicamente numa faixa etária mais alta, com idades compreendidas entre os 25 e os 40 anos. Este utilizador já acabou os seus estudos, frequentando então a aplicação como forma de melhorar as suas habilidades de trabalho e de expor o seu portefólio, ou então como um hobby, exprimindo-se criativamente e aconselhando utilizadores menos experientes. Está também interessado em participar em competições, pelas razões acima descritas.

 

 

O Artista Novato

 

O artista novato está numa faixa etária mais extensa mas maioritariamente jovem, entre os 14 e os 30 anos. Ainda não concluiu os seus estudos, pelo que é um estudante (na maioria ligado às artes) ou um entusiasta cultivando um hobby. Esta persona ainda teve um contacto muito limitado com desenho vectorial, que resulta em pouca experiência. Assim, irá valorizar as discussões, documentos de ajuda, tutoriais e a ferramenta online gratuita (considerando que muitos não terão um programa dedicado ao seu dispor).


O Crítico

 

 

Estando em uma faixa etária mais alargada, este tipo de utilizador é tipicamente mais velho, já com alguma experiência mas mais consumidor de conteúdos do que produtor. Demonstra então mais interesse pela comunidade em volta da aplicação e as ferramentas de discussão, comentários e busca. Frequentemente cria criticas às criações de outros utilizadores e produz recursos e tutoriais para o uso de outros.



O Moderador

  

Este utilizador faz parte de um grupo reduzido, com uma idade mais madura, bom senso e paciência. Tem uma idade algures acima dos 28 anos e foi parte da comunidade desde cedo ou então contratado pelo administrador/dono da aplicação. O seu foco é assegurar a qualidade da aplicação ao invés de produzir conteúdos. O moderador vai então, de forma mais neutra possível, regular os comentários e submissões dos outros utilizadores, removendo tudo o que seja ofensivo e mantendo a ordem.

 

 

O Administrador

  

Um grupo ainda mais reduzido que o dos moderadores, a preocupação destes utilizadores centra-se quase exclusivamente em assegurar o bom funcionamento da aplicação. Vão geralmente ser mais velhos, com os seus estudos concluídos e integrados no mercado de trabalho. Ocasionalmente farão uso das ferramentas mais sociais, mas em geral deixarão isso ao cargo dos moderadores. 

 

Estando criadas as personas e atribuídas as pontuações de cada uma aos requisitos, foi criada uma média para averiguar quais os requisitos mais importantes. Essa média, no entanto, era pouco realista, visto cada perfil ter um peso igual quando na realidade,  a distribuição estatística dos membros da comunidade entre os vários perfis não ser equitativa (o conjunto de moderadores e administradores irá constituir uma percentagem muito reduzida da comunidade, por exemplo). Para colmatar essa discrepância, atribuíram-se diferentes pesos a cada uma das personas, ficando por escala de importância, na seguinte ordem:

  1. Artista Novato

  2. Artista Experiente

  3. Critico

  4. Moderador

  5. Administrador.


Foi dada importância nesta ordem, visto o nosso público-alvo ser principalmente composto de estudantes e entusiastas de desenho vectorial. De forma a cativá-lo, é essencial então dar mais atenção às funcionalidades que ele considera mais importantes. A seguir vem o Artista Experiente, reflectindo também a componente de ensino da comunidade. Visto já ter experiência, dar relevância aos requisitos que considera importante ajuda a que o público-alvo tenha as ferramentas que precisa para aprender mais. O Crítico, sendo principalmente consumidor, irá participar mais na componente de interacção do , ajudando então a hierarquizar essa secção dos requisitos de forma a torná-la mais útil. Por fim, o Moderador e o Administrador, que sendo mais preocupados com o bom funcionamento da aplicação, têm o menor peso nos requisitos presentes no front-end. No entanto, a ordem da lista torna-se inversa na secção de back-end, sendo então mais importantes as opiniões do Moderador e do Administrador do que a do público-alvo.


A funcionalidades mais importantes, por categoria, após a contagem, são:

  • Ficheiros:

    • Acesso ao histórico do documento vectorial;

    • Download de ficheiros (PNG/SVG);

    •  
  • Interacção:

    • Ver resultados de competições;

    • Criar comentários;

    • Criar discussões;

    • Promover Discussões/Ficheiros (karma/reputação);

    • Aceitar/Recusar Pedidos Amizade;

    • Seguir actividade de outros utilizadores;

    • Bloquear utilizadores;

  • Pessoal:

    • Registo;

    • Login/Logout;

    • Fechar conta;

    • Recuperar password;

    • Editar perfil;

    • Remover Utilizador da Lista de Amigos;

    • Ver perfis;

    • Ver notícias;

    • Ver galerias;

    • Ver documentos vectoriais;

    • Enviar/Responder/Ver Mensagens Privadas;

  • Ajuda:

    • Documentação;

    • Envio de sugestões;

    • Envio de recomendações;

  • Back End:

    • Editar notícias;

    • Enviar mensagens globais;

    • Criar notícias;

Estando feita a média, 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, coincidindo então com o aspecto mais fundamental e diferenciador deste projecto. Tendo isso em consideração, o trabalho prático vai começar pela parte mais importante e complexa, de assegurar o bom funcionamento dessa simbiose entre ferramenta e comunidade. 

 


Março 2011
Dom
Seg
Ter
Qua
Qui
Sex
Sab

1
2
3
4
5

6
7
8
9
11
12

13
14
16
19

20
21
22
23
24
25
26

27
28
30


arquivos
pesquisar blog
 
subscrever feeds
blogs SAPO