Parte das perguntas reflecte um panorama profissional que não é o nosso (a distinção minuciosa de cargos e competências não é algo que faça parte do meu quotidiano) e mesmo considerando que o trabalho que ainda faço como web designer se vai reduzindo e não é a parte mais significativa dos meus planos para o futuro, achei importante participar, para que a amostra seja tão completa e representativa quanto possível.

Por isso, cá fica o aviso: se achar que também deve participar, lembre-se que só tem até ao dia 26 de Agosto.

A pensar nisso, aparentemente, apresenta-se agora uma nova abordagem à evolução de standards e browsers que é pouco mais do que virar o bico ao prego: a partir do IE8, propõe-se que abandonemos a estratégia do browser sniffing, em que o programador escreve variantes do código para diferentes browsers, versões e plataformas, servidas em função da sua (difícil e, por vezes, ineficaz) detecção, para deixarmos que sejam os novos browsers a detectarem a(s) versão(ões) testada(s) na fase de desenvolvimento para adaptarem o render da página de acordo com a intenção primária do programador.

A mudança sugerida é radical e difícil de digerir. Acompanhei com gosto a reflexão do Eric Meyer a esse respeito e dou por mim a pensar que o maior risco que se corre quando se vira o bico ao prego é não saber exactamente quem é que está a segurar o martelo.

Essa é uma questão que é abordada ao de leve nesta última edição da A List Apart, mas não fica muito clara nos artigos quer do Aaron Gustafson, quer do Eric Meyer, mas usando as palavras deste último:

For one thing, “browser sniffing” at present means “writing code to check what browser is being used and make adjustments to the markup/CSS/JS/server response/whatever accordingly.” Version targeting reverses that completely, making it “the browser checking the page to see when it was developed and making adjustments to its behavior accordingly.” In other words, version targeting frees web developers from sniffing and places the onus on browser developers instead.
[isto é virar o bico ao prego]

That’s not a change to be lightly dismissed. Browser implementors, for all they frustrate us with (often justified) pleas of limited resources, still command far more resources and expertise in regression testing than any of us can muster. Furthermore, browser developers have a far more vested interest in making sure the version targeting works as promised and doesn’t break old sites than site authors do in updating their old sites to work in new browsers. [isto é reconhecer que quem segura o martelo é o outro e ter fé que ao outro não lhe interessa acertar-nos nos dedos]

(…)
Besides which, we’ve written enough scripts and hacks to make our pages adjust to browsers. Isn’t it about time browsers started adjusting to our pages? [isto é reconhecer que se está cansado]

(…)
The biggest concern is fidelity. Will the backwards-compatible code for IE8 always act exactly like IE8 did, or will there be subtle changes that still break old sites? Might there even be, dare we mention it, new bugs that affect the backwards compatibility of future browsers? After all, the door swings both ways: vendors might get lax about their backward-looking code just as developers might get lax about their forward-looking code. Talk about irony. [isto é reconhecer que pode continuar a correr muito mal]

As web designers (and developers and information architects, and so on), we have a lot more to offer than making pretty pictures or giant red buttons. Take the reins and change the relationship you have with your clients—become a partner, not a vendor. Including clients in your work can do more to build great working relationships than you might imagine.

É comum ter referências a artigos publicados no A List Apart, ali na barra do lado direito do blog, onde uso o del.icio.us para marcar leituras recentes. Mas, nem sempre os artigos que me marcam mais ficam convenientemente destacados.

Senti isso com a questão da escrita na web, a que dei destaque num post, e acho que este artigo da Sarah B. Nelson sobre o papel dos clientes nos processos de design e sobre as formas de gerir processos colaborativos merece também algum destaque.

O artigo em si não apresenta nada de verdadeiramente explosivo ou revolucionário, mas como é comum dar por mim em situações em que há uma grande confusão acerca de como se articula a relação entre um designer-projectista e um cliente e como já senti na pele as vantagens e as desvantagens da aposta na ideia da parceria, acho que vale a pena para ler, reflectir e adaptar às várias realidades em que nos vamos mexendo.

A minha experiência diz-me que uma das únicas formas de convencer um cliente ansioso de que a estruturação e escrita correcta de conteúdos relevante (que consome tempo e dinheiro) é uma fase fundamental dum processo de criação dum site é tentar explicar que o Google e os restantes motores de busca não passam de leitores “compulsivos”, que lêem na diagonal, parando brevemente nos títulos, sub-títulos e destaques e digerindo rapidamente tudo o que se lhes apresenta como texto^*.

Quem percebe isto, está disponível para o processo de análise, composição e depuração exigível. Mas é mesmo muito raro.

* – estou perfeitamente consciente de que “content is king, but linking is queen” e que, quase tão relevante como o conteúdo propriamente dito é o número e qualidade das hiperligações estabelecidas para a página em apreciação. Mas o que podemos fazer pela qualidade e relevância estrutural do conteúdo das nossa páginas é muito mais do que o que podemos fazer pelo número inbound-links relevantes… aliás a melhor coisa que podemos fazer pelos inbound-links é garantir a qualidade e relevância estrutural do nosso conteúdo, certo?