Ao invés de redesign, uma abordagem estilo Agile

Temos conversado muito aqui na Latitude14 sobre a aplicação dos conceitos de desenvolvimento ágil (ou Agile) no processo de design com foco na experiência do usuário. Tentamos herdar idéias como:

  • começar desenvolvendo somente a essência, a menor unidade de um sistema (sem perder a visão do todo, claro);
  • colocar o produto nas mãos do usuário para se ter feedback o mais cedo possível (iterar cedo para iterar mais); e
  • reduzir a burocracia e a documentação (documentos e relatórios mais “digeríveis”).

Falei um pouco disso num post anterior. A Karine também escreveu um post bem esclarecedor sobre o assunto no blog dela. Vemos que maioria dos projetos pode se beneficiar dessa abordagem, até mesmo produtos que já estão prontos.

Onde quero chegar com isso: existe uma cultura fortíssima de redesign no mercado. Pelo menos é o que constatamos, de forma muito evidente, aqui em Belo Horizonte, principalmente quando se fala em websites.

Não sei dizer se é uma estratégia das produtoras e agências para obter mais lucro, se ainda não pensaram em trabalhar de outra forma, ou se os clientes demandam redesigns sempre e elas não têm argumentos para justificar uma abordagem incremental. Talvez as três coisas.

Quando se faz um redesign completo, não há tempo de aprender o suficiente e acaba-se focando somente nos problemas principais do produto anterior. Fatalmente, numa nova versão, também surgem novos problemas, que serão cobertos muito depois, num novo redesign, já que a verba se foi toda no primeiro.

Como gostam de dizer os gringos, “joga-se fora o bebê junto com a água da banheira”. E aí ficamos nesse ciclo vicioso, no qual nunca se chega a um produto totalmente maduro. Melhoram-se alguns aspectos enquanto surgem novos, os projetos duram vários meses e, quando vão ao ar, já têm problemas congênitos.

Quando foi a última vez que você viu um redesign completo da Amazon ou da Netflix, por exemplo? O mesmo vale para o Google e o Yahoo!, que fazem melhoras constantes e seus produtos, ao invés de jogar tudo no chão e reconstruir do zero. São empresas que têm essa mentalidade, não porquê são grandes, mas porque precisam construir produtos sólidos, com o mínimo de risco possível.

Se é feito inicialmente um estudo mais criteiroso dos problemas que existem na versão atual de um produto, de forma a ordená-los em ordem de criticidade, é possível quebrar o grande redesign em pequenos projetos.

Refazer ou melhorar somente uma pequena parte ou aspecto de uma aplicação ou website faz com que aquele seja um produto melhor num prazo muito mais curto. Além disso, aprende-se sobre o contexto, os usuários e outros stakeholders no processo. E esse aprendizado é reaproveitado nos “mini-projetos” seguintes.

Novo visual e CMS próprio

O carnaval numa cidade parada pacata do interior mineiro, sem muita coisa pra fazer, me motivou a encarar uma empreitada que eu gostaria de ter realizado há algum tempo: a reformulação visual e técnica deste blog.

O antigo HTML ainda tinha resquícios de um template do Blogger de 2004, que utilizei na primeira versão (quem chegou a dar uma olhada no código fonte antigo deve ter visto que estava uma vergonha). E mesmo achando que o layout não havia envelhecido muito, quis limpar a interface e renová-lo visualmente.

Sem chance nenhuma de acesso à internet (no lugar não funciona nem celular), mas uma cópia do CodeIgniter no notebook e um template HTML da home, começado há alguns meses, produzi a aplicação de gerenciamento de conteúdo, somente com as funcionalidades estritamente necessárias: gerenciamento de posts, comentários e links da lateral (o tal blogroll).

Não deixei de gostar do Textpattern, mas ultimamente, com a facilidade de desenvolvimento usando frameworks, tenho dado preferência à flexibilidade de aplicações customizadas na maioria dos casos. Além disso, eu sempre achei o esquema de comentários do Textpattern meio esquisito – nunca consegui fazer funcionar redondinho.

Para a interface da área de administração de conteúdo, utilizei um padrão que viemos desenvolvendo durante os anos na Media Design. Atende muito bem para a maioria dos sites, com poucas adaptações.

Claro que ainda falta um bocado de coisa pra fazer. A princípio quero implementar um sistema de tags para os posts e colocar uma proteção contra os robôs de spam nos comentários, usando um CAPTCHA. Até lá, vou contando pra vocês sobre os ataques que receber.

Você quer um portal ou uma página?

Saiu hoje no Yahoo! News uma matéria sobre a enquete que supostamente elegeu as palavras de internet mais odiadas. Ganharam coisas como blog, netiquette, cookie e wiki. Me fez lembrar que também tenho duas palavrinhas que causam pelo menos coceira quando ouço: portal e página.

Chega a ser engraçado: muito empresário desavisado que quer refazer um site com um conteúdo mais abrangente que o anterior acaba concluindo que quer “criar o portal da empresa”. Como se portal fosse o superlativo de site. Vai entender…

Já a outra anda perdendo popularidade, mas vira-e-mexe a gente ouve por aí alguém dizendo que “tem uma página na internet”. Automaticamente me vem o comentário mental: “coitado… só uma?!”

É verdade que existem vários sites de uma página só que são bem legais, mas acho que não é bem isso que a pessoa quis comunicar.

Corrigir ou deixar pra lá?

Vídeo sobre acessibilidade na web

Se você ainda não viu, o vídeo Acessibilidade na web: custo ou benefício? pode ser assistido no Videolog do UOL ou baixado em vários formatos no site do grupo Acesso Digital.

É uma iniciativa extremamente importante que deve ser propagada e reforçada até que todos os profissionais ligados à web tomem consciência e passem a se importar de verdade com acessibilidade. Depende de nós ajudar nessa divulgação e, principalmente, colocar em prática essas idéias.

Uso correto de texto alternativo em imagens

Apesar ser a primeira coisa que consideramos ao pensar em acessibilidade no HTML, o texto descritivo das imagens (geralmente apresentado no atributo alt da tag img), quando é usado, dificilmente é aplicado de forma correta.

Hoje encontrei no site Web Accessibility in Mind o texto mais completo que já vi sobre o assunto e fiquei impressionado como uma coisa tão sutil pode criar tantas armadilhas na aplicação. Leia já!

E, se possível, leia também todo o resto do site.

Tags:

Minhas fontes de informação em OPML

Seguindo o meme lançado no Meio Bit e incrementado pelo Henrique, coloquei aqui neste site o arquivo OPML contendo a lista de feeds que leio com regularidade.

O objetivo do meme é fazer com que todos os blogueiros compartilhem suas fontes de informação de uma forma padronizada pra que cada um saiba o que o outro anda lendo.

Para ver minha lista, basta clicar no link OPML na barra lateral do site. Mas eu recomendo instalar o OPML Reader no seu Firefox, pois parece que a moda vai pegar. O OPML Reader é uma extensão que coloca no rodapé do browser um pequeno ícone que fica azul quando há um OPML disponível na página que está sendo visualizada. Ao clicar no ícone, o OPML é exibido no Grazr e você pode ler ali mesmo alguns dos feeds daquele autor.

Você vai notar que, em comparação com outros autores, não assino muitos feeds. É que tenho tentado resumir minhas fontes apenas ao essencial, justamente para ter mais tempo pra outras coisas

Tags: , , , ,

Agregadores mais populares

Seguindo a sugestão do Henrique, segue o top 10 de agregadores usados para ler este blog:

  1. Bloglines
  2. Firefox Live Bookmarks
  3. Netvibes
  4. NewsGator Online
  5. Safari RSS (Mac OS X)
  6. Google Desktop
  7. NetNewsWire (Mac OS X)
  8. Thunderbird
  9. FeedReader
  10. Opera RSS Reader

Assim como na lista do Henrique, é estranho ver que muita gente ainda usa agregadores de desktop. Eu mesmo já usei muito o NetNewsWire, um agregador desktop para Macintosh, mas depois que descobri o Bloglines nunca mais voltei.

Ultimamente estou ligado no Newshutch e, apesar da propaganda que já fiz por aqui, ele ainda nem apareceu na lista dos agregadores. Talvez por ser relativamente novo, o sistema de estatísticas do FeedBurner ainda não o reconhece. Ou então ele mesmo ainda não se identifica ao FeedBurner.

Não me faça pensar, segunda edição

Já saiu há algum tempo a segunda edição de um dos clássicos da usabilidade: o livro Não me faça pensar de Steve Krug. Como eu já disse antes, é leitura obrigatória pra qualquer profissional de internet. Esta nova edição tem três capítulos inéditos:

  • Usabilidade como um favor comum: Por que as pessoas realmente saem de web sites
  • Acessibilidade, cascading style sheets e você: tornando os sites usáveis e acessíveis
  • Socorro! Meu chefe quer que eu ___: sobrevivendo a caprichos de projetos de executivos

Ajax e acessibilidade

Até pouco tempo as atenções sobre os padrões web estavam voltadas somente para XHTML e CSS. Grande parte dos profissionais os adotou e aprendeu a se preocupar com acessibilidade, semântica, validação e tudo mais. Agora, com a popularização do Ajax, começa-se a explorar mais o DOM, a camada de comportamento.

É um passo importante e, para não corrermos o risco de perder o rumo novamente, não podemos esquecer as bases fundamentais aprendidas na chegada dos padrões. Me refiro ao frenesi em torno do Ajax e o que o mau uso dele pode acarretar em termos de acessibilidade. Vamos lembrar do que se fez com o Flash há algum tempo e evitar com todas as forças que aconteça de novo.

Traduzindo Jakob Nielsen numa entrevista:

A “nerdisse” do nome Ajax me dá esperança de que ele será usado para causas de mais valor que aquelas características do Flash. Arruinado por seu próprio nome, o Flash tinha potencial similar, mas foi tão abusado pelo design “flasheiro” que nunca teve sucesso em acrescentar alguma funcionalidade útil à web.

Com a manipulação do DOM em jogo, o ideal para se manter a acessibilidade intacta é fazer com que as páginas continuem a funcionar em qualquer dos três cenários possíveis:

  • XHTML puro (sem CSS e sem Javascript)
  • XHTML + CSS (sem Javascript)
  • XHTML + Javascript (sem CSS)

Ou seja: XHTML é a base estrutural e por isso deve ter a maior atenção. CSS e Javascript são seus servos e vêm para incrementar a experiência do usuário. Portanto, as funcionalidades do Javascript nunca devem substituir o processamento feito no servidor, da forma tradicional.

Leitura recomendada:

Livros sobre web standards em português

Numa varredura pela seção de livros sobre internet do Submarino, percebi que há outros em português falando de web standards, além do livro do Zeldman.

No meio de vários sobre programação, administração de sistemas e alguns velhos conhecidos, estavam alguns que eu nunca havia visto, como o Construindo Sites Adotando Padrões Web do Marcelo Silva Macedo, lançado em 2004 e este, de 2003: Criando Sites Web com Folhas de Estilo (Nilson Ruas).

Outro, aparentemente mais teórico, me interessou bastante e provavelmente será a próxima aquisição: Web Semântica: a Internet do Futuro

Aviso que, como não li nenhum desses livros, isto não é uma recomendação, OK? Se você conhece algum deles, deixe seu comentário.