Código Bala!

Há algum tempo atrás, eu havia escrito um texto no meu blog pessoal que comentava os benefícios do desenvolvimento em camadas. Achei que ficaria um pouco constrangido em reler, mas tanto ele quanto a discussão (curta) que se seguiu estão bem mais atuais do que eu imaginava.

Pesquisando alguns anúncios e vagas na área de interfaces por todo o Brasil, me surpreendi o quão esquizofrênico continua o mercado. Há grandes avanços, especialmente em empresas menores, que conseguem sacar mais rápido as mudanças tecnológicas e as demandas decorrentes disso. Algumas empresas grandes também estão se mexendo, mas estamos longe de ver algo mais definido no que diz respeito às competências a serem desenvolvidas, tanto por designers quanto por codificadores de front-end e programadores.

Citarei um exemplo anônimo, para ilustrar. O anúncio da vaga é real, só omiti o nome da empresa e mudei um pouco para descaracterizar a forma. A essência, no entanto, permanece intacta.

Cargo: Web Designer
Descrição: webdesigner com muita criatividade e conhecimentos em design visual e recursos de programação web.

Domínio de: html, css, javascript, php, photoshop, flash. Desejável ASP.

Todos sabemos bem que web designer é um termo tão vago quanto o famigerado webmaster, mas será que só eu fico desconfortável que o cara tenha tenha que dominar Photoshop, Flash e linguagens de programação? A discussão aqui é ampla, mas sigo na posição que externei nesse comentário: conhecimento adicional sempre é benéfico, mas será que alguém tem condições de desempenhar papéis tão diversos de uma forma tão uniforme? A pergunta é: um designer conseguiria entregar layouts de qualidade ao mesmo tempo em que precisa se preocupar com a programação do banco de uma loja virtual?

A resposta deve ser sim, porque esse tipo de anúncio continua dominando os classificados. Conheço milhares de faz-tudo realmente competentes, que se desdobram e fazem websites de cabo a rabo. Mas não conheci um que não pecasse de alguma forma em alguma das partes. Ora se faz um layout magnífico e um script pra funcionar, ora temos um layout fraco com um banco muito bem estruturado e programado.

E quem fomenta essa situação? São as empresas (por quererem contratar uma pessoa para fazer de forma meia-boca o trabalho de três), os clientes (por desconhecimento das práticas envolvidas, o que é bastante perdoável), mas, principalmente, o profissional (que não se valoriza em sua área específica na hora de aceitar um trabalho ou porque, como sabemos, a realidade é dura e temos que botar comida no prato).

O anúncio que reproduzi é nacional, mas é muito comum ver isso em qualquer site de empregos, seja daqui, de Londres ou da Irlanda. O multi-tarefa que atira para todo lado é buscado em todo o mundo e, infelizmente, o webmaster ainda não morreu, como preconizou o Felipe Memória no seu excelente livro. Nós queremos enterrá-lo, mas não será assim tão fácil.

E existe alguma luz? Claro que sim. Comentei antes que algumas empresas estudam e incorporam melhores rotinas de desenvolvimento, mas que isso infelizmente ainda é para a minoria. Procurando apenas por “html” no MyCareer da Austrália, a primeira ocorrência foi um anúncio bem diferente do anterior. Reproduzo os trechos mais relevantes:

HTML Developer

Job Role:

* Developing websites from wireframes using XHTML, CSS and JavaScript.
* Liaising with creative design team.
* Develop content for integration into .NET projects.
* Involvement in the design process, assessing the creative look and feel.

Skills:

* Advanced CSS, XHTML, JavaScript and web browser DOM support.
* Knowledge of SEO techniques.
* Full understanding of the W3C compliance standards.
* Knowledge of Interface Design, Accessibility, and Usability principles.

Para mim, isso parece muito mais razoável e focado. O cargo pode parecer meio genérico (ou simplista), mas a descrição das competências e dos conhecimentos necessários para desempenhá-la me pareceu perfeita. Tomara que isso torne-se mais comum no meio da confusão instaurada.

Web design is the creation of digital environments that facilitate and encourage human activity; reflect or adapt to individual voices and content; and change gracefully over time while always retaining their identity.

O Rei acerta na mosca mais uma vez. Num artigo discutindo, afinal, o que diabos é esse maldito web design, Jeffrey Zeldman faz analogias brilhantes envolvendo diagramação, arquitetura e tipologia para nos brindar com insight fabuloso sobre essa atividade.

Esse é para imprimir e colar onde todos possam ver.

O Instituto de Informática da Universidade Federal do Rio Grande do Sul (UFRGS) é um dos poucos lugares no Brasil onde você pode fazer cursos de pós-graduação (especialização) em Engenharia de Usabilidade em Sistemas Interativos. Agora, além disso, eles estão oferecendo dois cursos de extensão, bem mais curtos e focados em áreas mais específicas da usabilidade de sistemas.

Sei que o Instituto é referência nacional no assunto, mas não posso deixar de achar os preços meio salgados. O curso Avaliação de Usabilidade e Acessibilidade de Sistemas Interativos, com 15 horas/aula, custa R$ 306,00 (trezentos e seis reais). Em comparação com outros cursos de extensão da UFRGS, pelo menos, é bem mais caro. Outro departamento bastante prestigiado na instituição, o de Fotografia, cobra R$ 250,00 por uma extensão com o dobro de horas/aula. Não reclamo nem discuto o mérito dos dois, apenas acho importante fazer a comparação.

E só para encher o saco e não dizerem que só falo mal de designers: bem que a UFRGS poderia fazer como a PUC e chamar estudantes de comunicação ou design para refazer seus sites. Todos eles.

Para quem perdeu ou quiser rever as apresentações da etapa gaúcha do Word Usability Day 2007, uma boa notícia: o conteúdo já está disponível. O evento foi bastante bom, então recomendo que se dê ao menos uma passada de olhos em todos os slides.

Os pontos altos, na minha opinião, foram as oficinas. Marcos Nähr e Renato Rosa se saíram muito bem, tanto nas suas exposições quanto nas atividades propostas. Botar o pessoal para analisar sites com base nas heurísticas do Nielsen foi uma idéia muito feliz do Rosa, porque deu para ver que pouca gente (eu incluso) realmente bota a mão na massa depois de ler esse tipo de conceito. Lemos, entendemos, mas dificilmente pegamos um site problemático para criticar e realmente tentar buscar alternativas para melhorar a experiência do usuário. E o produto disso são discussões muito oportunas e vários pontos de vista que ajudam (e muito) a melhorar a experiência de cada profissional.

Já tinha gostado bastante da fala do Nähr no EWD 2006 aqui em Porto Alegre, e a oficina dele no WUD também rendeu. Dividir a platéia conforme os estilos de aprendizagem de Kolb foi legal porque realmente enfatizou o que eu disse antes: diversas impressões diferentes sobre um mesmo assunto (no caso, a usabilidade da nova Amazon). Incrível descobrir que, mesmo num universo reduzido (umas 30 pessoas), o tipo de reação a um mesmo objeto de análise pode variar muito. Todos acharam problemas e virtudes na loja, mas o caráter da crítica variou, indo da admiração à defenestração completa (alguém falou que todo o layout parecia jogado aleatoriamente e que eles pareciam não se importar com design, do que eu discordo frontalmente).

Tomara que o WUD continue rendendo frutos e, especialmente, mudanças no mercado no que diz respeito à usabilidade de projetos web.

Um dos paradigmas mais recorrentes no momento de conceber uma interface para a Internet diz respeito a um mito que tornou-se bastante popular com o passar dos anos: o de que usuários não usam a barra de rolagem (scroll) para navegar pelo conteúdo. Isso se origina de uma premissa parcialmente verdadeira, o que produz a confusão citada. Usuários não usam o scroll se a navegação não for fluida o suficiente, ou se ela não fornecer elementos que justifiquem tal ação.

Outro mito antigo, que já caiu por terra há um bom tempo, é de que os usuários só navegam pelos links fornecidos dentro do site em si. Isso é um absurdo, dado que já é senso comum que o botão "voltar" do browser, por exemplo, é o segundo elemento de navegação mais utilizado, depois dos próprios hyperlinks (NIELSEN, 1999). Ainda assim, pessoas continuam tentando interferir nas escolhas do usuário, que é quem deve decidir como quer fazer as coisas.

A respeito dessa sensação de onipotência sobre o que o internauta vai poder fazer enquanto navega, já ouvi pessoas querendo bloquear o aumento e redução de fontes feitos pelos softwares. Acho engraçado essa gente jamais perguntar por que seu layout quebra quando as letras mudam de tamanho e o que se pode fazer para corrigir isso no nível de codificação. Não, é muito mais sedutor tentar exercer um poder de cima para baixo, condicionando o visitante a uma (má) experiência.

Voltando ao scroll, que é um problema ainda bastante recorrente: clientes até pedem por isso, algumas vezes. Me parece que é um condicionamento oriundo dos designers, que ainda insistem nessa prática ou são seduzidos por abrir um site num pop-up despido de comandos de navegação padrão. Claro, a culpa não é toda deles, porque sempre vem alguma ordem superior. Mas eles têm sua cota de participação na história, é inegável.

Sobre isso, o Jared Spool fez um comentário rápido e incisivo, no contexto de sua apresentação sobre aroma da informação (tradução livre de scent of information):

Users scroll. Designers usually create barriers for this.

Como justificativa, usou um exemplo extremo. O site de uma empresa de componentes eletrônicos listava todos os seus produtos numa só página na capa, em três colunas divididas horizontalmente por categorias. Todos os produtos eram apresentados com seus nomes, linkados diretamente no texto azul e sublinhado. Horror para designers e arquitetos de informação, mas uma tentativa de mudança nessa estrutura redundou numa enxurrada de reclamações de clientes, que não consigam mais achar o que procuravam.

Como dito, o exemplo é extremo. O público é muito específico (engenheiros eletrônicos e entusiastas), e provavelmente outras pessoas não teriam paciência de rolar uma tela imensa cheia de itens. No entanto, nesse contexto, uma tentativa de "facilitar" a navegação evitando o uso de scroll quase tornou-se desastrosa.

Por isso é tão importante refletir sobre esse ponto, não simplesmente decretando "não vamos usar rolagem" ou "teremos rolagem horizontal para diferenciar-nos do resto". Cada situação é diferente, e depende sempre do tipo e quantidade de informação, bem como os perfis de público que potencialmente tentarão se beneficiar dela.

Está mais do que claro para desenvolvedores que um código de marcação bem formado e obedecendo critérios semânticos é a chave para que um site se saia bem em todos os aspectos: usabilidade, acessibilidade, SEO e integração com bancos de dados e CMS. Vender esse conjunto de especificidades é simples na teoria, e pode parecer também fácil na prática. Só que não é bem assim.

Sobre isso, há um bom post do Élcio respondendo uma pergunta feita depois da sua palestra no Intercon 2007: como fazer com que o cliente pague por padrões web, acessibilidade e toda essa qualidade, quando há gente por aí desenvolvendo sites a R$ 70,00?

Padrões web, usabilidade, acessibilidade, Ajax, tudo isso tem um custo, mas não é isso que seu cliente compra. (…) É uma questão de números, R$ 25.000,00 pode ser muito barato se você puder mostrar a ele que vale a pena.

Mostre a seu cliente quanto dinheiro ele vai ganhar, ou quanto ele vai poupar. Dê a ele segurança disso, e ele vai achar seu preço barato.

Esse discurso deve ser aliado à explicitação dos benefícios que um bom código pode trazer: melhor posicionamento nas buscas do Google, maior acessibilidade a pessoas com deficiências ou dificuldades técnicas, melhor portabilidade para dispositivos móveis, entre outros. Mas, por incrível que pareça, às vezes tudo isso pode simplesmente não funcionar.

Já consegui deixar clientes plenamente cientes das vantagens de um site desenvolvido seguindo web standards, evitando texto e navegação em Flash e animações que levam 15 minutos para carregar numa conexão banda larga. Chegaram até mesmo a concordar com a direção sugerida para a produção do projeto.

Só que isso pode simplesmente mudar de uma hora para outra. Algum diretor pode aparecer do nada e dizer que o site precisa ser todo em Flash, igual ao dos seus concorrentes (que são horríveis e funcionam mal). Nada importa nesse momento, a não ser a (falsa) impressão visual vendida pela maioria das agências digitais do país.

O desenvolvedor fica de mãos atadas até mesmo quando alia seu conhecimento técnico a uma explicitação clara de vantagens competitivas e de retorno de investimento. Assim como existem executivos que não compram esse negócio de site aí, como o próprio Élcio falou, também ocorre o segundo fenômeno: quero um troço bonito e que encante, não importa quanto vai custar, nem que 70% dos usuários fechem o site na capa sem nem mesmo esperar carregar o Flash de abertura. E o pior: algumas vezes essas pessoas reconhecem que você está certo, mas respondem algo como vamos deixar o site acessível e bom para dispositivos móveis num segundo momento. Alguns não se importam nem quando é provado que isso implicará em custos adicionais que poderiam ser abatidos num único projeto bem feito!

Já li muitos artigos a respeito disso, e quase sempre se toca em dois pontos: educação (de cliente, mercado e dos próprios desenvolvedores) e falar a língua certa (mostrar onde e como se vai ganhar mais dinheiro e/ou reduzir custos). Ambos estão corretos e precisam ser considerados, mas vejo pouca gente considerar o fator do horror absoluto e aleatório presente em todos os fatos da vida: às vezes simplesmente não dá para usar a razão, e as coisas nem sempre podem ser previstas.

Particularmente, estou adotando o lema do Zeldman para os casos mais graves da aleatoriedade sem sentido. Alguns profissionais são do tipo “deixa comigo” e fazem tudo que o cliente quer. Realmente admiro gente assim, porque conseguem tocar todos os projetos até o fim, seja qual for o obstáculo no caminho.

Eu devo ser mais temperamental, ou possuir um instinto maior de auto-preservação. Portanto, quando aparece um caso como relatei anteriormente (surge um elemento que passa por cima de tudo que já foi acordado), geralmente pego minha mochila e dou no pé. Se precisar sobreviver fazendo outra coisa, corto a grama dos vizinhos, que é algo bem mais digno.

Tive o prazer de estar presente no An Event Apart San Francisco desse ano. Entre outras palestras interessantíssimas, o fechamento do segundo dia de evento teve uma fala bombástica do grande Jeffrey Zeldman.

Em Selling Design, o papa do dos web standards focou-se na relação do desenvolvedor com seus clientes. O paralelo mais importante que foi traçado, na minha opinião, foi o de um encontro amoroso. O conceito mais relevante: aprenda a farejar problemas. Se você vai ao seu primeiro encontro com uma pessoa que lhe desperta interesse, um pedido de casamento depois de um mísero sorvete é sinal de alerta, no mínimo. É importante se dar conta disso também em relações profissionais.

A frase que resumiu todo o raciocíonio apresentado por Zeldman: your emergency is not my problem. Se um cliente chega até você pegando fogo, pedindo um trabalho para amanhã e até mesmo pagando muito bem, significa que:

• Ele dá pouco valor para seus projetos e, conseqüentemente, para o trabalho que você irá fazer;
• Outras pessoas mais atarefadas ou mais inteligentes já recusaram o projeto antes, o que é sinal de perigo.

Obviamente, recusar-se pura e simplesmente a fazer o trabalho não é o caminho. Mas é necessário ter em mente que tipo de cliente você deseja atender, se é que você realmente se importa com qualidade e prazo dos projetos que executa. Maus clientes podem pagar muito bem e estressar muito, bons clientes podem pagar quase nada, mas render uma experiência prazerosa, compensadora e, a médio prazo, até mais satisfatória financeiramente.

A idéia de ter um blog dedicado a desenvolvimento na web sempre esteve presente. Faltavam os meses de indecisão e dúvida para finalmente colocar a idéia em prática, e acho que agora é o melhor momento possível.

Trabalho com o que se convém chamar de front-end development desde 2000. Comecei estagiando num pequeno núcleo digital de uma agência de publicidade de Porto Alegre, mas comecei a mexer com HTML muito antes. A primeira conexão caseira à Internet foi em 1996, quando a Plug-In ainda era um provedor de acesso, e modems de 14.400kps eram um luxo só.

Como quase todo mundo, tive uma "página pessoal", que não tinha serventia alguma, mas me forçava a mexer em código sem ter a menor noção do que estava fazendo. O saudoso Composer foi muito útil. Jamais usei o FrontPage, porque naquela época a superioridade da Netscape era tão evidente que não parecia fazer sentido tentar usar produtos da Microsoft. Algum tempo depois, migrei para o insubstituível Allaire Homesite que, pasmem, uso até hoje. Claro, na versão 5.5, já comprada pela Macromedia, e descontinuada para todo o sempre em favor do intragável Dreamweaver. Sim, já tentei umas cem vezes, mas nunca vou conseguir usar esse aplicativo confortavelmente. Coisas da vida.

Depois daquele estágio, fiz três anos de residência (como gosto de apelidar) no portal Terra, trabalhando no que chamávamos e ainda chamamos de webmaster. Entrei para popular a ferramenta de busca antiga que, como quase tudo, era alimentada à mão. Google existia, mas nem se cogitava que pudesse fazer frente ao Yahoo. Logo, a automatização foi inevitável, e eu me voltei para o que já sabia fazer: atualizar sites, colocar conteúdo novo, fazer alguns do zero sozinho ou com mais gente. Aquela mistura inevitável de HTML, CSS incipiente, Photoshop intuitivo e um pouco de sorte. Era bastante divertido.

Resumindo um pouco mais a história, fiquei quase seis anos na empresa, e assumi de vez o título de desenvolvedor de interfaces. Minha equipe mudou de nome umas três vezes, sempre tentando melhor adaptar-se à necessidade dos clientes internos e à realidade do mercado e da profissão. Não preciso dizer que isso nunca deu muito certo, e que a porcentagem de pessoas que sabiam o que fazíamos efetivamente era de, no máximo, uns 10%. Isso é uma realidade que permeia essa atividade e outras correlatas, e certamente me aprofundarei no tema em posts vindouros.

Para finalizar, quero distingüir bem a missão desse blog:

• Não farei tutoriais: isso é o que mais tem por aí, e pessoas muito mais qualificadas do que eu. Sempre que houver algo técnico legal para indicar, farei-o;
• Não copiarei conteúdo de outros blogs, nacionais ou internacionais: a maioria dos blogs de desenvolvimento que vejo se resumem a copy/paste de coisas que se leu em outro lugar, com no máximo uma linha de autoria própria que geralmente não serve para muita coisa. Como no item anterior, se houver alguma recomendação de leitura, darei a referência e era isso;
• Criticarei a atividade e suas áreas correlatas: o hype atual em torno dos termos design de interfaces, arquitetura da informação e usabilidade é quase insuportável. Tudo é ciência, tudo é arte, tudo está começando, e quanto mais fala-se a respeito, mais confuso fica. Martelarei muito esse assunto, porque otimismo demais vira euforia descontrolada, e isso faz mal;
• Haverá possivelmente entrevistas com profissionais e colaborações. Não será um blog coletivo, mas publicarei artigos de gente boa que, ainda bem, existe por aí.

É por aí. Tenho várias idéias, mas é melhor parar de ficar elocubrando e começar a escrever. Assim que houver um número mínimo de posts, acho que ficará mais clara a identidade do blog todo (o que ainda é um mistério mesmo para mim).

Obrigado pelo interesse, e espero que todo mundo se divirta.