Em meu esforço para criar uma série útil definindo o que constitui uma boa experiência de usuário, eu fiz uma enquete para ouvir das pessoas o que elas pensam sobre os ingredientes importantes para compor uma grande experiência de usuário. Aqui estão os resultados;

Esses resultados são muito parecidos com os que eu esperava. A usabilidade recebeu a maioria dos resultados, e todos os seguintes receberam a segunda maior quantidade de votos, você pode ver no gráfico acima que outras opções receberam consideravelmente menos votos, e alguns de vocês até curtiram um pouco comigo votando em nenhum dos acima.

Nesta série nós iremos observar os diferentes aspectos da experiência do usuário, definir seus diferentes elementos, e discutir sua importância para aqueles que interagem com aquilo que nós estamos criando. Nós iremos começar pela observação dos resultados e olhando o que eles nos dizem. Considerando que muitos dos votantes são colegas designers/desenvolvedores eu esperava que resultado mais alto fosse a usabilidade. Em primeiro lugar isso chama a minha atenção para duas coisas.

A maioria destes que votaram sabem o que é importante para um bom design.

A maioria destes que votaram sabem o que é importante para um bom design.

Não, isso não é um erro, deixe-me explicar… A maioria daqueles que votaram (incluindo eu mesmo) trabalha com algum tipo de ambiente de design/desenvolvimento todos os dias. Para alguns de nós isso tem fornecido muita experiência no desenvolvimento de websites, e outras interfaces de usuário, o que foi exibido no número de votos que a usabilidade recebeu em comparação com todo o resto (aparentemente a maioria de nós presta atenção no “Be-a-bá” do design).

Um bom design começa com a usabilidade. Então é bom ver que nós temos nossos fundamentos de um bom design alicerçando-nos. Eu acredito que a usabilidade é a prioridade quando criando um design/produto baseado no usuário… mas nós temos que ser cuidadosos ao definir usabilidade por aí da nossa maneira já que se ela é nosso Zorro os outros componentes avaliados que fazem uma boa experiência de usuário são deixados de lado (Tonto). Em tempos em que nós podemos nos aprofundar na maneira de saber o que sabemos razoavelmente bem, nós pensamos que nós sabemos o que o usuário precisa para ter uma boa experiência de usuário, e na maioria das vezes nós terminados como o pobre marido que dá uma bola de boliche para sua esposa no Natal, ele pensa que ela irá gostar do tempo juntos… jogando boliche. É claro que ele teve boas intenções, mas ele estava um pouco fora de sintonia com o que a sua esposa poderia realmente querer (uma viagem para um spa, pedicure ou simplesmente algo que demonstrasse que ele tem interesse nas suas necessidades.)

Nós devemos nos certificar do nosso crescente número de usuários, simplesmente porque nós “sabemos o que é importante para um bom design”, ou por “ser aquilo que sempre fizemos” Usabilidade é a chave… boa navegação que é fácil de seguir e leva os usuários aos resultados desejados, certificando-se de que a mensagem do projeto/produto é permeada com propósito e clareza, e outros elementos fundamentais precisam estar no lugar para o sucesso do design inicial, mas eu pessoalmente acho que a não ser que cerquemos esses elementos de um bom apelo visual, forte suporte auxiliar e uma boa quantidade de emoções (dando ao usuário as percepções secundárias) o design não será capaz de atingir seu completo potencial, e irá apenas cumprir com o mínimo proposto.

Assim como qualquer time de futebol tem uma estrela (ex.: um Ronaldinho, ou um Rivaldo) e isso definitivamente ajuda a aumentar as chances de sucesso ao ter aquele jogador chave… mas as vezes há algo que o time não consegue dominar, ou atingir altos níveis de sucesso até que seus jogadores sejam cercados de um conjunto de outros jogadores de qualidade dando-lhes apoio. Isso nos leva a entender porque “Todo o resto” recebeu o segundo montante de votos. (41 segundos para apenas 44 votos em usabilidade). Isso realmente nos remete à ideia de uma aproximação bem balanceada para nosso processo de design, nós realmente precisamos considerar o que a resposta ao usuário desejada que estamos tentando atingir é, e então, embasados na usabilidade e pelo time de apoio do apelo visual, da resposta emocional e do bom suporte auxiliar, nós seremos capazes de criar belos websites e experiências de usuário que levarão o usuário à resposta desejada, ajudando nossos clientes e funcionários a atingir um nível mais alto de sucesso.

Agora que observamos os resultados, e olhamos para a necessidade de uma aproximação equilibrada junto a todos os nossos elementos, nós iremos observar cada elemento individualmente. No próximo artigo nós iremos desenrolar a ideia de usabilidade, que nós concordamos ser vital para o processo, mas o que envolve fazer um site usável? Por onde nós devemos começar?

Eu adoraria ouvir o que você acha que é fundamental para desenvolver um site “amigável ao usuário” (compatibilidade com navegador, padrões, acessibilidade). Faça algum barulho e deixe-me saber o que você pensa. Obrigado novamente por ler e dar sua opinião,

Fonte: http://www.thisisaaronslife.com/defining-user-experience-pt1/

Já a definição de Mapas Mentais da Wikipédia diz que Mapa mental, ou mapa da mente ^[1] é o nome dado para um tipo de diagrama, sistematizado pelo inglês Tony Buzan, voltado para a gestão de informações, de conhecimento e de capital intelectual; para a compreensão e solução de problemas; na memorização e aprendizado; na criação de manuais, livros e palestras; como ferramenta de brainstorming; e no auxílio da gestão estratégica de uma empresa ou negócio.

Fontes: Mashable, Wikipédia

A empresa que desenvolveu o Ruby on Rails, a 37signals, também criou uma nova metodologia de desenvolvimento de aplicações web chamada “Getting Real”, que deu origem a um livro com o mesmo nome. A grande novidade é que esse livro agora está disponível para leitura on-line em português do brasil e pode ser encontrado nesse endereço.

É claro que existem outras metodologias, como a RUP, que é muito adequada para grandes projetos, principalmente os mais complexos, que contam com grandes equipes e que foca a organização e documentação prévia de cada detalhe do projeto, e a XP que é voltada para o desenvolvimento de aplicações privilegiando a comunicação com o usuário e a realização de ciclos rápidos de desenvolvimento focando a divisão do projeto em pequenas partes, aliada a modularização do projeto (e que deu origem a algumas técnicas marcantes, como a realização de testes unitários e a programação em pares).

Já a proposta do pessoal da 37signals foi criar uma metologia que privilegia a utilização de frameworks de desenvolvimento ágil, onde a preocupação com detalhes de implementação é totalmente abstraída e o desenvolvedor se foca apenas na construção da solução para o problema apresentado, podendo ser utilizada tanto em projetos pequenos quanto em grandes projetos. Além disso, as ferramentas de desenvolvimento ágil de aplicações web possuem recursos de auto-documentação e API‘s de fácil compreensão, além de serem desenvolvidas em linguagens de script, como as que eu citei inicialmente, onde o código fonte está sempre à disposição do desenvolvedor seguindo critérios de organização definidos pelo framework, que dentre outras coisas, também oferece a separação entre modelos, controladores e visões ( MVC).

Pois bem, se você leu até aqui eu creio que irá gostar de ler o livro. Ele é curto, divertido e de simples compreensão. Vale a pena perder um tempo e refletir sobre qual metodologia é mais adequada ao seu projeto.

Obs.: Tentei disponibilizar o máximo possível de links no texto pra dar uma força pra quem se sentir meio perdido. Espero que gostem. ]]> http://minholi.com/blog/2007/02/caindo-na-real-metodologia-para-desenvolvimento-de-aplicacoes-web/feed/ 3 http://minholi.com/blog/2006/11/a-sindrome-do-nao-inventado-aqui/ http://minholi.com/blog/2006/11/a-sindrome-do-nao-inventado-aqui/#comments Tue, 07 Nov 2006 21:16:00 +0000 Marcelo Minholi http://minholi.blogs.unipar.br/2006/11/07/a-sindrome-do-nao-inventado-aqui/ Tenho visto seguidamente ao longo dos anos que trabalho com tecnologia da informação (e estou certo que não sou o único) uma série de situações onde desenvolvedores de software simplesmente ignoram a existência de tecnologias e técnicas simplesmente por não levarem em consideração, ao longo de suas trajetórias, que outras pessoas podem ter feito a mesma coisa anteriormente com uma visão muito mais completa do problema.

Os argumentos para querer “re-inventar a roda” são tantos e tão variados que seria impossível enumerar uma quantidade significativa aqui, assim sendo, deixo aqui esse espaço para que os meus 2 ou 3 leitores ocasionais descrevam aqui as situações impares de NIH (Not Invented Here) pelas quais já passaram.

Apesar de já criticar largamente esse tipo de atitude há um bom tempo, só recentemente tomei conhecimento do termo própriamente dito depois que foi postado um texto sobre o assunto abordando a decisão dos desenvolvedores do Django, o Framework Web com o qual eu venho trabalhando, de não aproveitar o código de terceiros na sua composição, fato esse que vem sendo lentamente revertido mas que foi, de certa forma, até benéfico para a consolidação da ferramenta.

Mas quais benefícios e malefícios a decisão de aplicar ou não as idéias de terceiros podem trazer a um projeto? Pois bem. Quem aqui disse que é preciso usar unicamente um pedaço de software de outra pessoa para fugir da tal síndrome?

É preciso estar atento às mudanças, saber escolher dentro da miríade de opções de tecnologias e técnicas que aparecem todos os dias, aplicar apenas aquilo que traga algum benefício real ao projeto, optando por re-utilizar o código de terceiros ou, em segunda instância, aplicar engenharia reversa, ou ainda, apenas se basear em boas idéias alheias para criar algo que ofereça o melhor dos dois mundos, ou seja, o entendimento e controle total sobre o código e a eficiência já comprovada daquilo que realmente funciona bem em projetos de terceiros.

Fazer valer o ditado que diz que é sábio aprender com os erros dos outros é uma dádiva, principalmente em se tratando de aplicações para web e produtos que devem atender a critérios de usabilidade e acessibilidade. O fato de estar fazendo algo que não é completamente novo e que segue diversas tendências já consolidadas pode castrar de certa forma a criação, mas poupa tempo e esforço, sendo portanto mais produtivo e possibilitando um saldo de disposição para as etapas do projeto onde ela, a disposição, é mais necessária.