Design & Usabilidade
Balsamiq Mockups: solução entre protótipos de alta e baixa fidelidade
Abr 9th
Levantamento de requisitos deficiente é um dos principais motivos dos problemas que ocorrem durante o desenvolvimento de um sistema. O cliente descreve como ele quer que o sistema seja feito, os requisitos principais, e “desenha” mentalmente uma imagem do que ele espera que seja o sistema. Só que quando o desenvolvedor recebe essa informação, ele também imagina como deve ser o sistema. Só que a visão que ele tem geralmente é bem diferente do que o cliente está imaginando. É a partir daí que surgirão argumentos como “está faltando um detalhe aqui”, “essa tela poderia funcionar de tal forma”, entre outros argumentos bem conhecidos pelos desenvolvedores.
Para tentar amenizar este problema, existem os protótipos, que são “rascunhos” das telas do sistema. Existem várias técnicas para elaboração desses protótipos, que vão desde o uso de ferramentas como PowerPoint até trabalhos manuais usando cartolina, papel, tesoura, giz de cera (agora eu esqueci o nome dessa técnica). Esses protótipos são classificados como “protótipos de baixa fidelidade” – simulando a interface do sistema com recursos que não serão utilizados para o desenvolvimento do mesmo, como o PICTIVE (lembrei o nome!) – ou “protótipos de alta fidelidade” – um exemplo seria a montagem das telas usando o Flex. Leia o restante desta postagem »
Como definir efeitos de transição em componentes no Flex 3
Dez 17th
O Flex provê diversos efeitos que podemos colocar em qualquer componente visual. A forma mais simples de fazer isso é definindo as propriedades dos triggers desses eventos.
Triggers são parecidos com eventos, mas não são iguais. Quando um evento é disparado, um eventListener captura esse evento e executa alguma função em AS. Quando um trigger é disparado, um efeito é executado. Um trigger não pode executar uma função em AS e versa-vice. Da mesma forma como associamos funções a eventos através dos eventListeners, precisamos associar efeitos a componentes através dos triggers. Vamos ver agora como fazer isso.
Temas do GMail e a experiência do usuário
Nov 21st
Eu sou o tipo de pessoa que não pode ficar muito tempo sem ver mudança em alguma coisa. Desde as coisas que ficam espalhadas na mesa até a interface de um programa ou alguma responsabilidade na empresa. Talvez por isso eu goste tanto do GMail.
Hoje quando acessei meu e-mail tive a atenção desviada para uma caixa de texto anunciando um novo recurso: os temas. Eu uso o BetterGMail 2, plugin para Firefox que permite, entre outras coisas, mudar a interface do sistema mas … eu já falei que adoro mudanças???
Na prática diária, esse novo recurso não teria implicação nenhuma se eu fosse muito conservador. Sei que vou acabar me acostumando com um único tema e deixá-lo ativo ad eternum, mas isso abre espaço para um comentário sobre o desenvolvimento de sistemas: a experiência do usuário.
Usando CSS no Flex
Nov 10th
O FlexBuilder agiliza muito a criação de interfaces, só que se você construir uma aplicação sem mudar em nada os estilos padrão do Flex, seu programa vai ficar com exatamente a mesma cara da aplicação do teu colega, o que não é muito legal.
Existem recursos avançados para se criar skins no flex, onde você define os estilos de cada cantinho da sua aplicação. Isso pode ser feito, por exemplo, com o próprio Flash, onde você define novos estilos para os botões, barras de rolagem, combo boxes e tudo o mais que você possa imaginar.
Mas neste breve artigo pretendo cobrir um assunto mais simples: a modificação da interface padrão através do uso de arquivos CSS.
Melhor visualizado em browsers com precisão cirúrgica …
Out 10th
Eu estava atualizando alguns recursos do blog e fui dar uma olhada no código fonte quando encontrei algo interessante: um tamanho de fonte que eu nunca havia usado antes.
A nuvem de tags (tag cloud) é esse monte de tags que ficam na barra lateral. Quanto mais artigos em uma determinada tag, maior ela será mostrada. Pois eu acredito que devo ter causado o cálculo de alguma dízima periódica, veja só o tamanho da fonte que foi calculada para a tag combobox:
Para renderizar essa fonte, o browser tem que ter uma precisão cirúrgica!
Será que o Chrome consegue? 
Como *não* elaborar uma mensagem de erro
Mai 2nd
Em design de interfaces, sempre existe um cuidado específico com a elaboração de mensagens de erro. Elas devem ser claras e objetivas, não podem assustar o usuário (ex: “ERRO FATAL”) e nem culpá-lo (ex: “Esta ação é proibida. Tente outra alternativa.”), e devem, no mínimo, dar uma idéia clara do aconteceu e, se possível, indicar uma solução.
Me lembrei desse conceito quando vi uma mensagem de erro apresentada pelo GIMP (editor de imagens um pouco parecido com o Photoshop, porém free). Eu estava montando um gif animado com dois frames para colocar em uma aplicação. Coisa simples. Na hora de salvar, especifiquei o delay entre os frames, o local onde o arquivo deveria ser salvo e cliquei em Salvar. o programa me apresentou a seguinte tela:
Confesso que fiquei assustado, confuso e frustrado: assustado por imaginar que um mísero gif de 1KB poderia devorar os dois núcleos do processador ou todos os 2GB do PC que eu estava usando. Confuso porque não tive a capacidade de entender ou imaginar o que poderia ter ocorrido, muito menos uma provável solução. E frustrado porque eu não sabia se o arquivo havia sido salvo ou não.
Olhei a pasta de destino do arquivo, e lá estava ele, salvo. Porém ele não estava são: tinha virado uma combinação dos frames que eu havia colocado no arquivo, ao invés de virar uma animação.
Como a parte de design não é a minha “praia”, criei coragem e voltei a me aventurar pelos menus e opções do programa. Marquei algumas opções que acreditei que poderiam resolver meu problema e mandei salvar novamente. Desta vez, sem nenhuma mensagem de suspeita de erro.
No final das contas, consegui criar o meu arquivo do jeito que eu queria. E também encontrei um bom exemplo do que não deve ser feito ao compor uma mensagem de erro.
Ainda bem que deu tempo terminar o trabalho antes que o PC fosse dominado pelo lado negro da força … 
Sites proibidos para !IE (não Internet Explorer)
Out 9th
Esses dias tive um problema em um cliente, que precisava acessar uma determinada página e o filtro de conteúdo de Internet não permitia. Fui ver do que se tratava, era o site de um órgão de classe muito sério, e com um outro problema igualmente sério: a página era acessada através da porta 87. Além disso, os menus não funcionavam no Firefox: os submenus apareciam, mas os cliques nos itens desse submenu não surtiam nenhum efeito.
Com a intenção de ajudar e ao mesmo tempo resolver o problema do cliente, mandei uma mensagem para a instituição, informando o erro e dizendo que o Firefox não abria o site, pelo fato de usar a porta 87 (o Firefox nem tenta acessar, ele bloqueia o acesso para prevenir algum tipo de fraude, comportamento perfeitamente correto).
Um dia depois recebi a resposta, com instruções para limpar o cache do navegador, excluir cookies, baixar o nível de segurança e todos aqueles procedimentos-padrão que sempre mandam. Mas um detalhe me chamou a atenção na mensagem, que copio a seguir:
Lembrando que a página do
[O nome da instituição foi retirado]foi desenvolvida para ser aberta apenas em navegadores “Internet Explorer” (Versão 5.0 ou posterior). Não é possível acessar a partir de outros navegadores (Firefox, Opera, etc.)
Como assim ??? Então se eu uso linux e não tenho máquina virtual, emulador ou qualquer outra coisa não posso acessar o site ??? Que absurdo !!!
Já pensou um mecânico que só conserta carros do ano 2000 em diante? Médicos que só atendem pacientes com mais de 25 anos? Teclados de computador que só servem para quem é destro? Celulares que só funcionam na região central da cidade?
Existem alguns sites que realmente aparecem de forma incorreta no Firefox (porque a pessoa que fez não se deu o trabalho de testar em outro browser que não seja o IE), mas pelo menos funcionam. Se for um blog, um fórum, um site de notícias, tudo bem, dá pra ficar sem se a pessoa não gostar. Mas e no caso dessa instituição, que muuuitas pessoas precisam acessar?
Desenvolva seus layouts e sistemas de forma que seu público-alvo (pelo menos) possa acessar. Senão, não adianta muito você disponibilizar o que quer que seja através da Internet. Testar seu site ou aplicação em diferentes versões do IE e no Firefox é o mínimo que você deve fazer antes de colocar o seu trabalho no ar.
Parece um botão, mas não é
Ago 24th
Esses dias vi um sistema de cadastro em um determinado site. Me chamou a atenção a forma como o sistema foi feito, pois era um sistema muito grande, e não tinha uma usabilidade muito boa.
Um exemplo que se destacou foram os botões. O cidadão fez um botão composto por um link sobre uma imagem. O problema era que, para se clicar no “botão”, não era possível clicar sobre qualquer ponto sobre ele, mas sobre o link.
Roubo de teclas de atalho
Ago 13th
Um dos princípios de usabilidade é a “familiaridade”. Esse princípio diz que os controles do sistema que será operado por um usuário pode remeter ao conceito de algo que já é familiar a ele.
Um exemplo disso, considerando somente o design de interfaces para aplicativos de computadores, é o menu das aplicações. As pessoas já estão acostumadas em encontrar um primeiro item de menu chamado “Arquivo”, que tem opções para salvar o que está fazendo, abrir outro documento, configurar a página, enfim, algo ligado ao arquivo; elas também esperam que o último item de menu seja o menu “Ajuda”.
Últimos Comentários