Design Patterns em usabilidade

Devido a preocupação com a usabilidade do FEBRACEv, na quinta da semana passada, conversamos com a prof Lucia Filgueiras, que é especialista em IHC e usabilidade do PCS.

Ela disse que basicamente existem duas formas de fazer um estudo de usabilidade. Uma é fazendo a aplicação de heurísticas e a outra é fazendo testes com usuários. No caso de aplicação de heurísticas, existe o que chamam de Design Patterns, que é um conceito de arquitetura. Nesse caso, pattern não possui o mesmo sentido de standard (padrão), mas sim de “estampa”, coisas que se repetem com frequência.

A prof Lucia indicou vários sites sobre o assunto, os quais compartilhamos com vocês.

A grande pesquisadora de patterns é a Jenifer Tidwell e que ela tem vários matérias disponíveis na web:
http://jtidwell.net/ (site pessoal)
http://designinginterfaces.com/ (site do livro dela)
http://www.time-tripper.com/uipatterns/ (site com os patterns dela)
http://www.mit.edu/~jtidwell/interaction_patterns.html (site com uma parte do conteúdo do livro dela)

Outro site legal que tem vários exemplos de patterns é o Quince: http://quince.infragistics.com/UX-Design-Patterns.aspx

Outra pessoa que mexe com isso é o Van Welie e o no site dele tem vários patterns disponíveis: http://www.welie.com/patterns/index.php

Bom, essas são as dicas de hoje!

A preocupação com a usabilidade no FEBRACEv

Uma preocupação desde o início do projeto é com a usabilidade da rede social.

Mas o que é usabilidade?

Segundo Nielsen, usabilidade é um atributo qualitativo que avalia o quanto fácil é uma interface de usuário para ser usada. A palavra “usabilidade” também se refere ao método de melhorar a facilidade de uso durante o processo de design.

Usabilidade é definida por cinco componentes qualitativos:

• Aprendizado: Quão fácil é para usuários realizar tarefas básicas na primeira vez que eles defrontam-se com o design?
• Eficiência: Uma vez que os usuários aprenderam o design, quão rápido eles podem realizar as tarefas?
• Memorização: Quando os usuários retornam para o design depois de um período sem usá-lo, quão fácil eles podem restabelecer a proficiência?
• Erros: Quantos erros os usuários cometem, qual a gravidade desses erros, e quão fácil eles recuperam dos erros?
• Satisfação: Quão é agradável de usar o design?

Há muitos outros atributos qualitativos importantes. Um dos mais importantes é a utilidade, que remete para a funcionalidade do design: Será que o design permite aos usuários fazer o que eles necessitam? Usabilidade e utilidade são igualmente importantes: pouco importa que algo é fácil de fazer, se não é o que você quer fazer.

E porque a usabilidade é importante na web?

A usabilidade é uma condição necessária para se “sobreviver” na web. Se o usuário achar difícil usar seu site, ele simplesmente não usará mais e irá procurar outro que ofereça a mesma coisa. Se a home do site não for clara em transmitir o que o site faz e para que serve, o usuário não entenderá e irá embora. Se os usuários se sentirem perdidos no site, eles simplesmente sairão dele. Se as informações do site forem difíceis de ler ou de entender, outro motivo que eles o abandonarão. Enfim, se o usuário encontrar dificuldades em usar seu site, ele simplesmente o abandonará sem maiores constrangimentos. Isso mostra a importância do design na retenção de usuários no seu site.

Não é a toa que essa é uma preocupação que temos na construção no nosso sistema. Afinal, queremos reter e atrair usuários para a rede social e isso será decisivo para o sucesso e o cumprimento de um dos nossos principais objetivos que é o de fomentar e estimular os jovens a discutir e fazer ciência.

Como a parte de programação do projeto está praticamente terminada no FEBRACEv, a partir de agora nos focaremos em melhorar a usabilidade dele.

Continuaremos postando aqui as novidades do projeto.

Sobre Python e Django

No último post falamos sobre módulos reusáveis em Django, porém não falamos anteriormente o que é o Django. Para corrigir essa pequena falha, este post tratará sobre isso.

O Django é um framework para desenvolvimento web. A linguagem de programação usada com esse framework é o Python.

O Python é uma linguagem de programação de alto nível, interpretada, imperativa, orientada a objetos, de tipagem dinâmica e forte. Foi lançada por Guido van Rossum em 1991. Atualmente possui um modelo de desenvolvimento comunitário, aberto e gerenciado pela organização sem fins lucrativos Python Software Foundation.

Uma das principais características do Python é ser uma linguagem de fácil leitura e entendimento. Para a separação de blocos de código, a linguagem usa espaços em branco e indentação ao invés de delimitadores visuais como chaves (C, Java) ou palavras (BASIC, Fortran, Pascal). Diferente de linguagens com delimitadores visuais de blocos, em Python a indentação é obrigatória e não só uma boa prática de programação.

O Django usa uma arquitetura conhecida como MTV, Model-Template-View, que nada mais é que uma variação do modelo MVC (Model, View, Controller), arquitetura na qual separam-se as regras de negócios (Controller), os dados e métodos de acessos aos mesmos (Model) e as regras de apresentação (View). Essa separação tem por objetivo o desacoplamento da lógica entre essas camadas, de maneira que cada uma delas pode ser modificada sem alterar o funcionamento das outras. Essa arquitetura também facilita a modularidade do sistema.

No caso da arquitetura MTV, o framework Django é o que faz as vezes de controlador da arquitetura MVC. Sendo assim, na arquitetura MTV, o Controller não é responsável pela lógica do negócio e sim pelo funcionamento do sistema. Além de models, views e templates, no Django há também o URL dispatcher, middlewares e handlers e são estes que são encarados como Controller.

O URL dispatcher é o componente responsável em analisar os endereços requisitados pelo cliente e redirecionar essa requisição para a aplicação correta. Já o middleware é um conjunto de componentes que realizam pré e pós filtragens nas requisições, o que possibilita funcionalidade como internacionalização de uma aplicação e gerenciamento de sessões autenticadas.

No Model, são escritas as classes que designarão as tabelas no banco de dados. A manipulação dessas tabelas ocorre através do ORM (mapeamento objeto relacional) e, por isso, não é necessária a escrita de querys em SQL para a persistência dos dados. Uma outra vantagem é baixa preocupação com qual sistema gerenciador de banco de dados será usado, uma vez que o ORM suporta vários sistemas. Há suporte atualmente para MySQL, PostgreSQL e SQLite.

Nessa camada também devem ser escritas as regras de acesso às informações, regras para os eventos de cada modelo (métodos save, delete, etc.), e também regras genéricas para eventos que podem ser usados em mais de um modelo (sinais). Toda a lógica de manipulação da informação de uma aplicação estará em seu modelo.

Na camada View, são escritas as regras de negócio e as regras de apresentação do sistema.

Na camada Template é definida a forma de apresentação dos dados que a View envia. Com o sistema de templates do Django é possível criar heranças, ou seja, um template base contendo a estrutura básica do sistema e templates específicos que herdam as características deste template base e atribuem/criam suas próprias características.

Com o uso do framework Django, um projeto é um conjunto de aplicações. Uma aplicação é uma determinada funcionalidade que compõe um projeto. Por causa disso, há a idéia de aplicações plugáveis no Django que é uma aplicação que pode ser usada em mais de um projeto com nenhuma ou quase nenhuma alteração de código. Isso quer dizer que a aplicação deve ter seus próprios modelos, suas próprias views, seus próprios templates e encapsular o máximo possível de código que não se enquadre em um desses elementos.

Para quem deseja aprender Django uma boa referência é o Django Book, que é um livro disponível na web, escrito pelo Bennet, que é um desenvolvedor bastante conceituado em Django.

Outra referência bastante completa é a própria documentação disponível no site do django (http://docs.djangoproject.com/en/dev/).

Até mais!

Módulos reusáveis em Django

O FEBRACEv está em fase adiantada de desenvolvimento.

O que muito ajudou para que isso fosse possível foi o uso de modelos reusáveis em Django.  Existe um site que agrega muitos modelos reusáveis de boa qualidade que é o Django Pluggables.

A vantagem de usar módulos reusáveis é não ter que implementar novamente funcionalidades muito comuns em diversos aplicativos. Por exemplo, muitos sites possuem um fórum para discussão e é muito interessante que isso seja um módulo reusável que pode ser usado nos diversos sites sem a necessidade de cada um reprogramar isso.

No caso do FEBRACEv, os modelos reusáveis são todos de código-aberto. A vantagem dos módulos serem de código-fonte aberto é a possibilidade de alteração deles para que se adequem para o nosso caso. Apesar dos modelos possuírem funcionalidades “padrão”, algumas vezes é necessário fazer alguma adaptação para se integrar ao aplicativo em específico. Por exemplo, no nosso caso temos uma galeria de fotos, porém foi necessário fazer algumas alterações no código-fonte para que cada projeto pudesse ter a sua própria galeria e só os participantes de um determinado projeto pudessem alterá-la.

Os módulos reusáveis que usamos no FEBRACEv foram:

• Django Profiles: módulo para a criação, edição e gerenciamento de perfis para rede sociais. O autor desse módulo é Bennet, que é um dos desenvolvedores mais conceitados em Django. Está disponível no Bit Bucket;
• Django Photologue: módulo para gerenciamento de galerias de fotos. É bem completo e pelo que pudermos perceber e ler por aí é o módulo mais completo em Django para essa funcionalidade. Está disponível no Google Code;
• Django Basic Blog: módulo para gerenciamento de blog. Ele é bem simples e é um sistema para um blog só. Está disponível no Google Code;
• Django Tagging: módulo que permite associar tags com algum conteúdo. Está disponível no Google Code;
• Django Registration: módulo para cadastro de novo usuário e para login em um sistema. Está disponível no Bit Bucket e
• Django Messages: módulo para envio de mensagens diretas entre dois usuários. Possui uma caixa de entrada, uma caixa de saída e lixeira onde os usuários podem verificar suas mensagens e respondê-las. Está disponível no Google Code.

A grande maioria dos módulos reusáveis já possuem templates bem simples, o que faz com que eles sejam bem simples de “plugar” na sua aplicação. Na grande maioria dos casos, basta você alterar o settings.py da sua aplicação, adicionando na lista INSTALLED_APPS o novo módulo e alterar o urls.py para filtrar as urls para redirecionar para a pasta certa.

É isso!

Faz tempo…

Faz um bom tempo que não postamos nada aqui, mas não é porque o projeto está parado. É exatamente pelo o oposto! Muito trabalho a fazer e pouco tempo disponível, isso fez com que praticamente abandonássemos o blog.

Nesse meio tempo, ocorreram muitas coisas. Houve a banca do projeto de formatura no PSI no fim de junho e tivemos que correr para implementar mais funcionalidades para apresentação. Também tivemos que correr para escrever a monografia (ou pelo menos uma primeira versão dela para entregar no PSI). No final, tudo deu certo! Apresentamos no PSI e os professores gostaram muito do projeto. E o Leandro se formou, pois só faltava essa matéria para ele…

Bom, depois dessa correria, não páramos não. Ainda temos que apresentar o projeto em dezembro no PCS, mas claro que uma versão mais refinada da que foi apresentada no PSI. E o trabalho prossegue!

Vamos fazer mais alguns posts em breve contando mais uma coisinhas do projeto!

Como “especificar” um projeto usando XP?

Tivemos que enfrentar um grande problema na atual fase do projeto. Esse problema veio do fato desse ser um projeto de formatura.

Normalmente disciplinas de projeto de formatura baseiam suas avaliações fortemente no acompanhamento das documentações desenvolvidas pelos grupos. O problema é que isso é incompatível com o uso das metodologias agéis de desenvolvimento de software. Essas metodologias preferem obter um software funcionando a ter uma documentação extensa sobre o sistema.

Nesse mês, teríamos que entregar a especificação do nosso projeto para a avaliação final da disciplina. Nosso problema era como fazer uma “especificação ágil”? Coloco entre aspas porque qualquer agilista me mataria ao me ouvir falar em especificação de software…

Nossa primeira atitude foi procurar na bibliografia existente sobre o assunto alguma resposta para esse grande dilema. Achamos bons artigos com relatos sobre o uso de metodologias agéis em projetos de formatura. Porém, apesar de úteis para nosso projeto, não resolviam a nossa questão inicial, pois eram relatos de professores que decidiram introduzir o XP nas disciplinas de projeto de formatura. Inclusive, em um desses artigos, o autor comenta que teve que alterar o critério de avaliação da disciplina de modo a avaliar coerentemente o andamento dos projetos, já que não havia mais uma documentação para ser avaliada.

O problema no nosso caso é que não são os professores que querem introduzir o XP no projeto de formatura e sim os alunos de um projeto em específico que querem usá-lo, e que sabem que o critério de avaliação leva em conta principalmente a documentação produzida.

Já que a bibliografia não nos ajudou a resolver nosso problema, então decidimos apelar para algum professor especialista na área. Porém, na Escola Politécnica não há nenhum professor da área de Engenharia de Software que trabalhe com metodologias agéis, todos trabalham com RUP. Enfim, entramos em contato com o professor Fabio Kon do IME que é especialista na área.

Foi relatado que eles já haviam tentado em uma disciplina de Engenharia de Software (na qual estavam usando XP como metodologia de desenvolvimento) gerar também documentação e o resultado foi um fracasso.  O que eles fizeram foi criar um adaptador entre o professor e o time. O professor explicava o que queria (diagramas, relatórios e etc) e o time transforma em cartões e tentava não só gerar documentos, mas também gerar código junto. Isso não deu certo, porque no final, a sequência de coisas era muito mais parecida com cascata do que com ágil, e para manter os documentos atualizados a sobrecarga era grande.

Percebemos que estávamos tentando unir dois mundos que pareciam não se conversar muito bem. Como não achamos respostas na bibliografia e nem com especialistas percebemos que nós mesmos teríamos que definir o que seria o nosso documento de especificação de acordo com o “bom senso”.

Tínhamos duas alternativas. A primeira era usar a documentação usada pelo RUP com seu levantamento de requisitos, modelo de casos de uso, modelo de classes e de seqüência, modelo de banco de dados, arquitetura de software e plano de testes. Se usássemos essa documentação estaríamos fadados aos problemas que o professor do IME nos havia dito, sendo que um de nossos principais objetivos do projeto de formatura não seria atingido (explorar o XP para o desenvolvimento de um projeto de formatura).

A segunda alternativa era criar uma especificação mais leve e geral que não nos amarrasse e em que fosse possível que os requisitos mudassem sem que criasse uma grande sobrecarga para alterar toda a documentação feita. E foi isso que decidimos fazer. A nossa especificação foi definida como contendo as seguintes seções:

• Compilação das histórias iniciais levantadas através do jogo do planejamento com o cliente;
• Definição da 1a. iteração do sistema (quais dessas histórias seriam as primeiras a serem implementadas);
• Tecnologias a serem utilizadas e
• Arquitetura do software (mostrando seus módulos principais).

Com essa especificação a idéia não é fechar os requisitos para que estes não mudem mais, mas sim dar uma idéia melhor do que é a proposta do projeto. Por isso, colocamos as histórias iniciais, o que não quer dizer que não haja outras histórias que possam ser descobertas ao longo da implementação.

Acho até que resolvemos bem o dilema em que nos encontrávamos… Se alguém quiser ver a “especificação de software”, basta acessar aqui.

Trabalho de Automação

Ontem tive que apresentar um trabalho de automação que tinha que desenvolver ao longo desse quadrimestre. O interessante é que a proposta desse trabalho era fazer um estudo sobre o projeto de formatura. Os tópicos de estudo eram:

• O objeto do Projeto de Formatura
• As possíveis automações que possam ser associadas a esse projeto
• Os benefícios decorrentes da aplicação da automação escolhida
• A arquitetura do sistema de automação considerado
• A infra-estrutura de energia e de telecomunicações demandada pelo projeto
• A confiabilidade do resultado do projeto
• A qualificação de mão de obra para a elaboração, operação e manutenção
• Os riscos decorrentes da utilização do resultado do projeto
• Os aspectos éticos que tenham que ser observados
• As interferências com o meio ambiente que possam decorrer
• Os impactos sociais, positivos e negativos, que possam decorrer
• A disposição final dos resíduos após a vida útil do resultado do projeto
• Os possíveis melhoramentos que possam ser adicionados
• Os aspectos de inovação consideráveis
• A viabilidade da transformação do resultado num produto industrializado
• A abrangência de volume de aplicação estimado do resultado
• Os principais investimentos necessários para a industrialização
• Conclusão

Achei muito interessante o trabalho, pois, além de explorar os conceitos de automação, explorou outros aspectos muito importantes que dificilmente são pensados ao se fazer um projeto qualquer. Tenho certeza que a reflexão a cerca desses assuntos enriqueceu em muito o trabalho de formatura e pretendo incorporar alguns desses assuntos na monografia em si.

Para quem está fazendo algum projeto sugiro fazer o exercício de pensar nesses tópicos, sendo que enfatizo pensar nos riscos decorrentes da utilização do projeto, os aspectos éticos envolvidos, as interferências com o meio ambiente, os impactos sociais positivos e negativos, a disposição final dos resíduos após a vida útil do projeto, aspectos de inovação e a viabilidade do projeto. Com certeza, isso enriquecerá seu projeto, além de permitir uma visão mais ampla e sistêmica.

Para quem quiser ler o trabalho escrito produzido sobre o projeto de formatura a cerca desses tópicos, clique aqui.

2ª retrospectiva

No dia 13/03 fizemos a 2ª retrospectiva da projeto.

A retrospectiva é dividida em 3 momentos: tarefas realizadas, avaliação dos pontos positivos e negativos e idéias surgidas.

No período entre a 1ª e a 2ª retrospectiva, foram realizadas as seguintes atividades:

• questionário de perfil de uso: devido a algumas sugestões recebidas da equipe da FEBRACE e de outras pessoas com experiência em levantamento de dados com usuários foram feitos melhoramentos no questionário;
• aplicação do questionário: a FEBRACE ocorreu nos dias 17, 18 e 19 de março e durante esse período foram aplicados questionários para alunos e professores participantes, além de visitantes da feira. Ainda não houve tempo para a compilação dos dados dos questionários. Foram recolhidos 520 questionários;
• automação do processamento de dados coletados com os questionários: o método escolhido para a aplicação do questionário foi em papel. Porém, com o objetivo de facilitar a compilação desses dados será usada a ferramenta Lime Survey. Assim, os dados de cada questionário podem ser inseridos nessa ferramenta de forma mais rápida e prática, e, pelo fato de ser online, o trabalho poder ser mais facilmente entre os membros do grupo. Além disso, a ferramenta já faz gráficos e cálculos de desvio padrão;
• decisão das tecnologias a serem utilizadas no projeto: o projeto será desenvolvido em plataforma Linux, usando o servidor web Apache. A linguagem escolhida foi Python, com o uso do framework Django para a construção de aplicações web. Serão usadas ferramentas para teste automatizado de código como o PyUnit, o Twil e o Selenium. Uma possibilidade levantada pelo grupo é a do uso de componentes reusáveis do Django Plugables. O banco de dados a ser utilizado ainda está em aberto, sendo que para se decidir serão testados os desempenhos dos bancos de dados MySQL e PostgreSQL.

A 3ª apresentação de acompanhamento foi feita hoje e foi um sucesso!!! hehehe

1ª retrospectiva

Agora que já explicamos mais sobre a proposta, podemos já falar um pouco do andamento do projeto.

Como um das coisas que nós nos propomos a fazer é utilizar metodologias agéis de desenvolvimento de software, então já começamos com uma retrospectiva.

A restropectiva é uma reunião periódica na qual é avaliado o período anterior do projeto (entre aquela retrospectiva e a anterior). Nessa reunião participa toda a equipe de desenvolvimento e a idéia é levantar coisas que deram certo naquele período, coisas que precisam ser melhoradas e idéias (desde do projeto em si até coisas referentes ao ambiente de trabalho) que possam ter surgidos durante esse período. Não há um tempo pré-determinado entre retrospectivas, mas para equipes que trabalham em período integral juntas é aconselhável que sejam quinzenais, enquanto não é ideal que demorem mais que um mês para ocorrer.

Para o projeto FEBRACEv, foi decidido que essas restrospectivas ocorrerão mensalmente e com base nelas serão escritos os documentos de acompanhamento a serem entregues na disciplina de projeto de formatura. Bem e foi isso que tentamos fazer!

Agora falando um pouco do mês que se passou entre a entrega da proposta e a 1ª retrospectiva… O primeiro passo tomado por nós após a entrega da proposta foi o estudo dos conceitos de engenharia de software envolvidos na proposta como metodologias agéis, usabilidade e acessibilidade e desenvolvimento web. Esse estudo teve como principal objetivo ter maior contato com os esses conceitos, levantar uma bibliografia inicial para o projeto de formatura e definir os próximos passos.

Como um dos desdobramentos do primeiro passo percebeu-se a necessidade da adaptação da proposta das metodologias agéis de desenvolvimento de software ao contexto do projeto de formatura, visto que alguns documentos são necessários. Como este é um assunto novo em termos científicos (começou a ser desenvolvido a pouco mais de 10 anos) definiu-se que um dos focos principais do projeto será fazer um relato do processo de desenvolvimento da aplicação proposta, descrevendo com detalhes as adaptações necessárias no modelo para que ele se adeque a um contexto acadêmico. Uma decisão que foi tomada é que a monografia será escrita concomitatemente com o andamento do projeto devido a este objetivo. Vamos tentar também manter o blog atualizado nesse sentido de ajudar na documentação do projeto.

O outro desdobramento do primeiro passo veio através do estudo dos conceitos de usabilidade. Para se fazer um estudo válido de usabilidade verificou-se como necessário um levantamento prévio com possíveis usuários do sistema para verificar o seu perfil de uso e suas reais necessidades em relação a uma nova ferramenta computacional. Como a FEBRACE (Feira Brasileira de Ciências e Engenharia) irá ocorrer em breve (dias 17 a 19 de março) viu-se a possibilidade de fazer esse levantamento com os participantes da feira que são potenciais usuários da rede social. O método escolhido para fazer esse levantamento foi através de questionário e este já foi elaborado. O

Outra atividade realizada foi um planejamento preliminar de todo o projeto de formatura, porém este foi feito em linhas gerais. Uma das propostas das metodologias agéis é o constante replanejamento para que se consiga prever com maior antecedência se o projeto está sofrendo problemas e ter tempo para tomar decisões para correção.

Outra proposta também dessa metodologia é que um planejamento só pode ser feito com uma boa precisão para poucas semanas adiante da que você está agora. Aliando-se essas duas propostas temos o constante replanejamento (que deve ocorrer sempre que necessário) e a cada novo replanejamento as atividades das semanas seguintes são melhores especificadas.

Bom, é isso. Em breve mais novidades por aqui!

A proposta do Projeto

Hoje a tarde faremos a primeira apresentação de acompanhamento do projeto de formatura. O projeto está evoluindo bem…

Bem, até agora não explicamos muito sobre a proposta desse projeto, acredito que estejam curiosos por saber…

A Febrace (Feira Brasileira de Ciências e Engenharia), realizada todos os anos na Escola Politécnica da USP e organizada pelo Nate-LSI (Núcleo de Aprendizagem, Trabalho e Entretenimento do Laboratório de Sistemas Integráveis), é um projeto de ação contínua com o objetivo de estimular a criatividade, a reflexão, o aprofundamento e o raciocínio crítico nas atividades desenvolvidas por estudantes dos Ensinos Fundamental, Médio e Técnico, por meio da indução em realizar projetos investigativos em Ciências, Engenharia e suas aplicações.

Com o intuito de aumentar o alcance da Feira, levando-a por mais tempo a mais pessoas, e estimulando a criação de redes entre elas, o projeto propõe a criação de uma aplicação Web que possibilite o desenvolvimento e exposição dos projetos na Internet e que ofereça ferramentas que viabilizem maior interação entre os diversos envolvidos na Febrace (alunos participantes, professores orientadores, organizadores da Feira, avaliadores e público interessado).

Assim, propõe-se:

• Desenvolver e disponibilizar uma aplicação de código aberto que ofereça ferramentas para a exposição virtual de projetos de Ciência e Engenharia;
• Agregar à exposição virtual uma rede social que permita a interação entre os participantes da feira e que estes possam se ajudar com seus projetos e dirimir dúvidas de visitantes interessados em participar de suas futuras edições e
• Estudar e utilizar conceitos de usabilidade, acessibilidade e práticas de desenvolvimento web 2.0, aplicando metódos ágeis de desenvolvimento de software.

O que acharam na proposta do projeto? Gostaríamos de ouvir sugestões, palpites sem compromisso ou reclamações sobre ela! Canal aberto nos comentários…