Bush: idiota ou *%#&<3s)? Um exemplo de tiro no umbigo usando CMS

Após a reeleição de Bush, o portal CNN/Netscape publicou uma foto do presidente norte-americano com o nome “moron.jpg” (idiota, em espanhol). Antes disso, o mesmo portal já havia publicado uma foto de Bush com o nome “asshole.jpg” (prefiro não traduzir). Erro proposital? Gafe? Falha humana? Esse problema foi escamoteado pelo CMS (Content Management System) da empresa.


Um dos grandes argumentos dos defensores dos CMS é a autonomia de publicação. Pois é justamente essa autonomia que dá margem a graves problemas de publicação. Alguém poderia dizer que o editor sabia do erro e publicou conscientemente a notícia. Sim, isso pode ter acontecido, pois supostamente ele contornou o problema trocando o vocábulo por outro um pouco menos agressivo. Porém, esse erro poderia passar batido, uma vez que o workflow de publicação normalmente o permite.

Obviamente é esperar demais que o CMS tenha um filtro ortográfico para palavras de tal calão, inclusive porque o mesmo deveria, obrigatoriamente, filtrar o código HTML para achar o erro. De qualquer forma, este problema reflete a fragilidade dos CMS ao publicar contéudo e esconder informações de quem publica a informação.

Com certeza esse erro também poderia acontecer num processo de publicação convencional, causado por uma falha humana, mas é através do CMS que esse erro é abafado e automatizado. Existem algumas hipóteses para a causa do erro, através do CMS:

(1) O escritor apenas associou uma imagem à notícia, pois o CMS mostrava apenas o atributo “ALT” da mesma, além de um thumbnail, “escondendo” o nome físico do arquivo, como normalmente acontece em interfaces voltadas a usuários não-técnicos.

(2) O escritor selecionou uma foto, clicando numa janela popup recheada de imagens thumbnail, onde o atributo “ALT” não estava definido e nem o nome físico do arquivo aparecia, associando esta imagem à notícia.

Assim, a complexidade habitual da ferramenta esconde o erro, sem que o escritor ou editor o percebam. Se a imagem fosse selecionada a partir de um campo do tipo “Procurar”, na máquina local, e fosse feito o upload da mesma manualmente, como no processo convencional, o escritor só não veria o palavrão, se realmente não quisesse.

Essa é uma pequena amostra dos diversos problemas que ocorrem quando o cliente tem o poder de publicação na mão. Não que este cliente seja desqualificado – inclusive webdesigners cometem erros diversas vezes na correria do dia-à-dia, tais como gerar imagens de tamanhos errados para a web, não formatar corretamente o texto, esquecer de aplicar CSS adequadamente etc – mas, imagine o impacto na usabilidade e arquitetura da informação que o operador do CMS pode causar, além da trivial nomenclatura de um arquivo .JPG? Existem riscos que um mero mecanismo de “preview” não previne. Isso sem falar na geração de código (X)HTML e CSS aderentes a webstandards e padrões modernos de desenvolvimento web, o que deve ser mandatório para um CMS de qualidade.

Com certeza estas falhas não são aferidas e consideradas na análise de risco de um CMS, bem como no cálculo do ROI. Qual o custo de um erro destes? Qual o impacto para a imagem da empresa? Qual o prejuízo para o usuário, ao navegar em um portal com problemas graves gerados por uma “publicação cega” ou sem critérios?

Embora as ferramentas de publicação – desde os simples blogs até os mais complexos ECM (Enterprise Content Management) – confiram diferentes graus de autonomia ao cliente, dando liberdade ao mesmo, é fortemente recomendável que a publicação passe pela mão de um webdesigner ou arquiteto da informação. A menos que o CMS seja muito bem construído, preveja possíveis inconsistências e possua um fluxo de trabalho consistente e revisado, existem detalhes que ainda requerem mão e olhar humanos para que o usuário tenha um site de qualidade no seu browser.