Código Bala!

Em novembro do ano passado, deixei meu antigo emprego atrás de mudanças. Durante alguns meses, atuei em pequenos projetos fazendo das coisas que mais gosto: XHTML e CSS, dessa vez do meu jeito, com codificação radicalmente focada em web standards.

Um pouco de canto, também participei de algumas consultorias rápidas em projetos de comunicação baseados em ferramentas de colaboração e redes sociais. Foi o vislumbre de um viés um pouco diferente na minha carreira, que eu comecei a levar paralelamente sem muita pretensão.

Eis que aqui estou, num hotel em Curitiba, me preparando para voltar para Porto Alegre no feriado e em breve dar mais um pulo em São Paulo. Agora, oficialmente, sou um consultor full time. Meu trabalho envolve temas que sempre estudei, mas que pouco apliquei por falta de oportunidades.

Então, meus poucos leitores podem se preparar para posts menos técnicos e um pouco mais relacionados a disciplinas derivadas ou relacionadas ao bom desenvolvimento web: análises de usabilidade, acessibilidade e arquitetura da informação certamente terão vez por aqui, já que agora estou podendo vivenciar a prática no dia a dia.

Espero que ninguém se ofenda com nada. E vamos lá.

O Wordpress 2.5 é fabuloso. Vi gente meio horrorizada quando testou, mas assim que se quebra o estranhamento natural de ver uma interface antiga substituída por uma nova, é puro deleite.

O redesign foi feito pela HappyCog, dos meus ídolos Jeffrey Zeldman e Jason Santa Maria. Eles pertencem ao farol que deveria guiar sempre design e desenvolvimento para web.

Há alguns minutos procurei informações sobre o ingresso de um show que pretendo assistir na semana que vem (Fernanda Takai, para os curiosos). Insatisfeito com o serviço de todos os guias culturais online da cidade de Porto Alegre, resolvi depositar minhas esperanças no site da produtora do evento. De fato, encontrei o que procurava (data, preços) de forma rápida, mas notei algo bastante interessante.

Está aí um exemplo do que acontece quando se negligencia a semântica do código de marcação do seu site. Associando-se uma navegação em Flash, temos mais que problemas de acessibilidade e usabilidade: o site é encontrado, mas a descrição dele não faz sentido algum. E pior, nesse caso: revela detalhes internos da produção (como esse comentário sobre o header), bastante dispensáveis num lugar tão nobre quanto a primeira colocação de um resultado de busca do Google.

Fiz uma busca por algo bastante determinado, pois já sabia que a Opus estava envolvida com o concerto. Mas se eu tivesse procurado por algo genérico, porém óbvio, como “fernanda takai porto alegre”, nada teria encontrado relacionando os dois. Pelo menos até a terceira página de resultados, o site da empresa não apareceu.

Ando acompanhando todo o debate sobre version targetting no IE 8 há um bom tempo. Legal ver que mesmo as opiniões mais extremadas têm seus fundamentos. Além do artigo do Diego Eis, recomendo dois textos com conclusões diferentes, mas que também acabam se complementando: Jeremy Keith, que acha que o IE 8 não renderizar segundo os web standards por default é o mesmo que decapitar alguém para curar dor de cabeça e; sempre ele, Jeffrey Zeldman, que acha que desenvolvedores e designers devem mais é comemorar pelo Explorer não ser mais um browser do demônio.

Resumo muito sintético para quem tá ouvindo falar disso pela primeira vez: em dezembro último, o IE 8 (que ainda não foi lançado) passou no teste Acid2 . Com isso, entrou para o time de browsers que renderizam sites seguindo os web standards da melhor forma possível, a exemplo do Firefox e do Opera.

No entanto, o pessoal da Microsoft tinha optado por criar uma chave (usando uma meta tag) para habilitar essa versão “boa”. Por padrão, o IE 8 continuaria renderizando sites de forma esdrúxula. O motivo: com o lançamento do IE 7 (que passou a se comportar 90% melhor que a praga do IE 6), milhões de sites mal codificados passaram a quebrar, deixando desenvolvedores tabajara e clientes desesperados. O nome disso em negócios todo mundo conhece: preju.

Essa chave foi o motivo de tanta discussão. Gente achando que era ótimo, pois pelo menos existia possibilidade de deixar o IE 8 “tunado”. E gente ultrajada e um tanto fanática, argumentando que colocar uma linha num código deixaria-o menos semântico, e que isso era um contra-senso e mais uma burrada infinita do pessoal de Redmond.

Pois bem: o time do IE anda apostando firme em ouvir a comunidade e dar suporte aos padrões. Sim, eles fizeram e sim, eles estão sendo muito corajosos: na verdade, o IE 8 será web standards friendly por padrão. Isso foi anunciado ontem, e deve ser comemorado com carros de bombeiros cheio de gente bêbada em cima.

Só irá desagradar algumas partes: os detratores irracionais, que atiram para todo lado para criticar qualquer suspiro da Microsoft e, talvez mais importante; o pessoal da Mozilla e outros, que terão de se mexer (e logo) para enfrentar, ao que tudo indica, a mais sangrenta das batalhas entre browsers de que se tem notícia.

Os beneficiados seremos nós. Que se matem.

[Depois de escrever esse post, agilizei-me e fui baixar o Internet Explorer 8 Beta. Testo-o nesse exato momento, e já achei simpático o botão “Emulate Ie7″ na barra de ferramentas].

Stephanie Sullivan, desenvolvedora front-end que participará da edição de abril do An Event Apart em New Orleans, responde ao público sobre algo que interessa a todos nessa área: depois de fazer tanta coisa diferente, como se concentrar em linguagem de marcação e ser valorizado pelo mercado?

Com a palavra, Mrs. Sullivan:

The companies that hire me, however, understand the value both to their bottom line in development and maintenance hours, and to their clients’ bandwidth savings and search engine placement. I’m contracted at times to oversee the plan for a project and advise on semantics and accessibility—to take code already written and make it more succinct and efficient, or to troubleshoot a challenge that has developed. I also train larger companies’ web departments to do what I do. I get great joy from helping people “get it.” To me, there’s nothing better than to watch that “aha” moment!

Nunca é demais lembrar dos benefícios trazidos por um código bem estruturado, limpo, organizado e semântico. E como ela mesmo diz, poupa horas de manutenção, banda dos servidores e ainda por cima melhora a achabilidade dos sites.

Se são chavões ou simplesmente um retrato da realidade, acho melhor concluir lendo todo o depoimento dela. Mas é interessante notar que, mesmo guinando sua área atuação em codificação, a utilidade dos conhecimentos pode (e deve) permear todo um projeto.

Já que o texto sobre os anúncios de emprego na área de desenvolvimento web gerou alguma movimentação, segui pesquisando. O panorama, em nível mundial, não é muito diferente daquele traçado no post, o que gera alguma ansiedade para saber quando as coisas vão mudar.

Mas como foi dito, sempre existem as gratas exceções, onde o descritivo da vaga parece realmente fazer sentido para o que ela representa profissionalmente. Um dos lugares com o maior índice de acertos, na opinião deste que vos escreve, é o quadro de oportunidades da Opera Software.

Amo o Opera incondicionalmente. É meu browser favorito, e não substitui o Firefox apenas pelo fato deste último ter plug-ins e extensões que são indispensáveis ao meu trabalho. Não fosse esse detalhe, abandonaria de vez a Raposa, que tem estado um tanto quanto dormente no que diz respeito a lançar a sua terceira versão e resolver problemas graves (como o fato do programa aberto, com umas duas abas, ocupar quase 70Mb de memória RAM). Usei o Beta do Firefox 3 e não tive nenhum vislumbre de melhora nesse quesito.

Voltando à Opera: além do compromisso com web standards, a empresa parece quase suplantar o Google quando o assunto é o trabalho dos sonhos. Fiquei particularmente cativado por esse aqui:

This job involves providing support for Opera’s developer customers and Opera’s internal developers through community evangelism, developer outreach, networking, and feedback solicitation. These goals are to be achieved via travelling to web development conferences across the world to represent Opera, blogging, e-mail, article publication, and any other appropriate methods of communication. Preferably, the individual would also contribute to the growing dev.opera.com developer resource site, through writing and editing articles, and responding to forum posts. (…)

Divulgar o Opera no mundo fazendo evangelização dos infiéis blogando, respondendo e-mails, publicando artigos e indo a conferências e ainda receber por isso? Nem me fale, tio. Agora, a cereja no topo é isso aqui:

Please submit your application using HTML 4.01 strict or XHTML 1 Strict.

Encerro aqui porque meus dedos estão se afogando na poça de lágrimas que virou o meu teclado.

Advertência: a palavra indentar é um neologismo. Não existe na língua portuguesa. Endentar aparece em alguns dicionários, mas não tem o mesmo sentido. Então, será adotado nesse blog o indentar que, assim com scanear, parece não ter nenhuma tradução adequada.

Bem, a pergunta do título é bem direta: você indenta seu código HTML? E o CSS? Essa é uma questão que pode parecer estranha entre programadores. Mas nós, front-end developers, estamos lidando com uma linguagem de marcação. O que fazer?

No meu caso, sempre combati a indentação em meu código. Sempre odiei a hierarquização automática gerada pelo Dreamweaver, que acabou virando regra na maioria dos casos. Até mesmo quem escreve código no bloco de notas acaba se acostumando a encher tudo de tabs, para dar uma organizada melhor, mas eu sempre achei isso muito mais confuso e dispensioso. Sem falar que, na soma final, acabava consumindo alguns bytes a mais, o que em projetos mais complexos realmente pode ter um peso indesejado.

Durante anos, também me acostumei a escrever meu CSS na horizontal. De novo, em projetos complexos, dava maior legibilidade a um bando de classes e IDs. Só que isso andou mudando.

Desde que adquiri minha cópia do Expression Web, parei um pouco de lutar contra a indentação automática. Em uma fase de testes e, aproveitando para treinar minha mente, tenho me esforçado duramente para manter tudo absolutamente hierarquizado no espaço de codificação, com resultados variáveis. No meu novo site pessoal, o CSS está indentado, mas o HTML segue o padrão antigo que usava. E se você conferir o CSS deste blog, poderá entender a que me referia quando falei sobre classes e IDs escritos na horizontal.

Ainda não decidi o que é melhor, mas nos dois últimos projetos em que trabalhei, indentei tudo. Logo devo fazer um teste de medir o peso dos documentos, nas duas formas, e ver se existe realmente alguma vantagem real em um ou em outro.

Como todo desenvolvedor também venho acompanhando, com um misto de curiosidade e temor, a discussão que gira em torno do próximo passo em linguagem de marcação para a Web.

Para resumir a questão: há uma divisão de gente trabalhando no HTML 5, alguns dentro do W3C, outros do lado de fora. Fora isso, temos as polêmicas documentações do XHTML 2.0 e as diretrizes de acessibilidade do WCAG2.0, que foram rechaçadas por quase toda a comunidade, que acabou na sua maioria abraçando uma errata da primeira versão.

No olho do furacão está o W3C, pretensamente vivendo uma crise de identidade e de liderança que já foram inquestionáveis no meio. Gente como o Zeldman acha que se está fazendo muito barulho por (quase) nada, mas reina uma desconfiança nunca antes vista em relação ao órgão que costumava balizar quase tudo no que diz respeito a desenvolvimento.

Em artigo essa semana no A List Apart, Lachlun Hunt dá uma geral na situação do HTML 5, esclarecendo alguns pontos que andavam um tanto obscuros. Há mais gente ajudando o W3C no projeto, o que é algo muito saudável para chegar-se a uma solução mais democrática. De organizações não-governamentais a empresas, parece haver um grupo bastante plural dando pitacos nos trabalhos.

No entanto, novos desenlaces estão gerando mais discussões acaloradas. Fora a previsão de término do projeto daqui quinze anos, há alguma polêmica com o novo modelo de marcação e as tags que serão usadas para isso.

Segundo o texto ilustrou, o que temos hoje em XHTML assim:

<div id=”header”></div>

<div id=”nav”></div>

<div id=”article”>

<div id=”section”></div>

</div>

viraria:

<header></header>

<nav></nav>
<article>

<section></section>

</article>

O argumento é que isso é mais claro, organizado e semântico no que diz respeito à interpretação correta dos elementos pelos dispositivos utilizados durante a navegação.

Mas será que isso não tornaria o HTML algo excessivamente específico? Apesar de longe do ideal no que diz respeito à organização, o XHTML 1.0 permite uma boa flexibilidade com o emprego de IDs. Quem conhece web standards sabe onde os elementos devem ser usados, que <h1> é um título de nível um e assim por diante. Entretanto, poder jogar com DIVs para fazer a divisão do código conforme a disposição do conteúdo é uma grande vantagem, ao meu ver.

O projeto, como visto, está longe de estar pronto. A discussão que surge até agora só beneficia todo mundo. Mas na hora de dar o passo adiante e adotar o novo caminho, não se pode prever se será um sucesso ou um grande tiro no pé.

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.