22.11.04

Debugando um fornecedor


WebDesign se mescla a diversas áreas do conhecimento: informática, design, marketing, arquitetura da informação etc. Realmente não é fácil lidar com tanta informação, todo dia. E lidar com fornecedores, não é diferente. Quando um fornecedor convida para uma palestra técnica, saiba que atrás do coffe-break impecavelmente servido no saguão daquele hotel 6 estrelas, da bela pastinha com caneta estilizada e bloco de notas hiper-branco e daquela aura mágico-empresarial se escondem pseudo-verdades, prontas a invadir sua empresa. Eis uma receita para enfrentar um "vendedor-técnico" performático, de ótima lábia e apresentações PowerPoint reluzentes.

- Desconfie racionalmente do fantástico ROI prometido. ROI é complicado de estimar. ROI para a Web é mais complicado ainda.

- Desconfie das estatísticas esteticamente redondas, do tipo: aumentamos a produtividade em 30%, reduzimos o tempo de resposta em 40%.

- Desconfie das palavras de desprezo em relação à concorrência. Se ela fosse tão ruim assim, não teria abocanhado tantas fatias do mercado. E o fornecedor não estaria tão empenhado em capturar você.

- Desconfie do fantástico produto para a web que será gerado pela metodologia de desenvolvimento X, a nova geração da Web! A Web deve ser guiada fortemente por instituições plurais e independentes como o W3C. E deve passar cada vez mais longe de técnicas e tecnologias proprietárias. Quando alguém vier com uma solução mágica, desconfie da procedência do coelho recém saído da cartola.

- Desconfie de estudos de caso mirabolantes. Nem tudo funciona perfeitamente como contado. Nem tudo acontece rápido, com redução de custos e cumprimento ortodoxo de prazos. A vida real é a vida real, você sabe bem disso.

O mundo estéril das apresentações técnicas está diametralmente oposto à realidade árida de quem desenvolve para a web. Tente ler nas entrelinhas. Certifique a origem dos dados apresentados. Estatísticas são uma faca de dois legumes. Esse legume tende a ser pepino!

Enfim, confie em quem possa oferecer credibilidade. Ah! E não deixe a endorfina dos salgadinhos refinados e a beleza da recepcionista concorrentemente sinuosa, magérrima e de olhos verdes influenciar seu processo decisório.

12.11.04

Tente enxergar além do CMS


Desde que surgiram, os CMS (Content Management System) prometem redução de custos, agilidade e robustez na manutenção de portais. Porém, nem tudo acontece realmente como profetizam seus defensores. Afinal, por que usar um ônibus espacial para comprar picolé na esquina? Critério e pesquisa são fundamentais para acertar na aplicação deste recurso promissor. Principalmente para buscar o melhor retorno neste investimento.


Como assim, CMS?

Em primeiro lugar, existem diferenças gritantes entre gerenciadores de conteúdo, gerenciadores de portais, gerenciadores de documentos e, modernamente falando, ECM (Enterprise Content Management).

De forma bastante simplificada, um CMS serve para gerenciar conteúdo: notícias, informações, texto, imagens e, em pequena escala, alguns documentos para download. Um gerenciador de portais serve para gerenciar, além de conteúdo, algumas funcionalidades como newsletter, enquetes, fóruns e outros serviços comuns a portais. Gerenciadores de documentos têm o foco na administração de documentos, versões e armazenamento/disponibilização dos mesmos. E os ECM's são ferramentas mais robustas, que prometem integrar todos esses recursos de forma corporativa (de forma análoga a um software ERP), sendo, portanto, exponencialmente mais complexos.


Basta escolher um CMS na prateleira?

Um dos primeiros problemas na escolha de um CMS é a própria escolha. Ora, mas basta escolher! Não, não é tão simples assim. A maioria das empresas atende ao canto das sereias, migrando seu processo tradicional de gerenciamento de conteúdo para um CMS sem saber exatamente por que estão adquirindo tal ferramenta. Assim, o problema não se resume a escolher um CMS, mas sim a entender as razões pelas quais se necessita um CMS.

Muitas vezes o cliente necessita de algum recurso de publicação simples como um blog ou um simples aplicativo em linguagem server-side como ASP, nada mais do que isso. Tentar encaixar um sistema muito complexo num problema simples tende a jogar recursos financeiros e técnicos fora. Muitas vezes, a urgência de publicação não é tão grande, a ponto de ser necessária uma publicação online. Nesse caso, a publicação convencional cabe. Diversas vezes, numa ânsia por novas tecnologias o cliente quer um CMS sem saber exatamente as funcionalidades e, em contrapartida, o custo e complexidade aumentam com a adoção destes.

Portanto, levantar exatamente as necessidades é o primeiro passo, antes de sair escolhendo um CMS ansiosamente, jogando dinheiro pela janela.


Por quê?

A princípio, um CMS deveria facilitar a vida do cliente, isolando a “parte técnica” da tarefa de atualização através de uma interface web. Ou seja, a tarefa de atualizar se resumiria ao preenchimento de determinados campos de formulário e algumas configurações básicas. Deste modo, a parte de montagem das páginas, transferência de arquivos e publicação fica transparente ao usuário. Ele pode se dedicar à elaboração do conteúdo e cortar passos, publicando via web, ao invés de enviar informações para a área de tecnologia o fazer.

O cliente também pode atribuir privilégios a diversos usuários que também poderão escrever e submeter esse material a um editor, que tem a incumbência de analisar e aceitar/rejeitar esse matrial, publicando-o ou enviando-o de volta ao autor. Este seria um trivial fluxo de trabalho.

Até aí, um cenário perfeito e comum em diversos portais. No entanto, usar um CMS se justifica se houver efetivamente estas necessidades. Para clientes com pouco volume de informações e usuários a se relacionar, o uso de um CMS começa a ser questionado. Bem como aquele usuário que não precisa publicar a informação imediatamente. Afinal, vale à pena sair voando de ônibus espacial para comprar picolé na esquina? Cometer esse erro é mais comum do que se pensa, não somente na área de web, mas na área de tecnologia da informação em geral.


Interface complexa

Muitos CMS possuem uma interface complexa. Muito mais complexa que o trivial modo de publicação convencional, via FTP ou alguma ferramenta como o Dreamweaver. Isso definitivamente provoca desgaste para o cliente e usuários. Não adianta trocar a tarefa – difícil para o usuário, por natureza – de atualizar o site por uma forma mais complicada ainda através de um CMS complexo. Se isso acontecer, a justificativa de simplificar as coisas vai por água abaixo.


E a usabilidade?

Um dos grandes problemas – não só do usuário leigo, mas do webdesigner – é a usabilidade. Diversas vezes, na correria do dia-à-dia, acontecem erros na publicação de sites, atropelando bons critérios de usabilidade. Numa publicação através do CMS esse erro pode passar despercebido pois, na maioria das vezes, a checagem de critérios de usabilidade não é feita através da ferramenta.

Ou seja, uma publicação apressada, onde imagens em tamanho errado, links quebrados, falhas de navegação, não aderência a critérios do W3C etc, pode engolir pequenas falhas que se tornam um entrave para quem está navegando no portal.


ROI subjetivo

Estabelecer o retorno de investimento num CMS é bastante subjetivo. Muitos fornecedores alegam que um auxiliar de escritório custa R$ 5,00 a hora, enquanto um webdesigner custa R$ 25,00. Assim, um auxiliar de escritório, usando um CMS acabaria custando menos e publicaria mais rápido o conteúdo, supondo que os dois levassem o mesmo tempo para terminar a tarefa.

Esse cálculo é simplista demais e chega a ser absurdamente inaplicável. Existem diversos custos do produto, a considerar no cálculo do ROI, tais como licenças, atualizações, suporte, assistência, treinamento, consultoria, tempo dispendido com a famosa curva de aprendizado, dentre outros.

Ora, não é apenas o valor/hora do técnico à frente da máquina que conta. Existem, inclusive, questões de projeto que devem ser consideradas (e devidamente contabilizadas) como análise de risco, impacto na usabilidade, tolerância a erros (fortemente dependente do grau de robustez da ferramenta) e também o processo interno da empresa que, pode ou não, se encaixar num CMS.


A vida dos sistemas, como ela é

Sabe-se da engenharia de software que um sistema é uma abstração da realidade. Assim, um sistema apenas reflete uma realidade "não informatizada". Se a realidade é "torta", o sistema também vai ser. Criar um sistema para consertar algo já problemático, no mundo real, não é aplicável.

O mesmo vale para o CMS. Se uma empresa, possui processos obtusos, um CMS dificilmente vai pôr ordem na casa. Nesse caso, primeiro revise seus processos e tenha consciência plena deles.


Mudando para pior

Além da necessidade de combater problemais reais do gerenciamento de conteúdo, um CMS deve ter a propriedade de não bagunçar o portal, criando mais problemas para o cliente e os usuários. Assim, a arquitetura da informação criada deve ser preservada, sem que o usuário passe a ter um serviço prejudicado na navegação e busca das informações. Se o CMS for um entrave à manutenção da estrutura, devido a sua pouca flexibilidade ou a enorme complexidade em gerenciar o conteúdo, deve-se refletir muito sobre a sua utilidade.

Não mude para pior, se o CMS trouxer mais dor de cabeça.


Tem certeza?

Uma conhecida máxima diz que a informática chegou para resolver problemas que antes não existiam. Esse pensamento deve guiar aquele que busca um CMS para o seu portal.

Você realmente ainda tem certeza que necessita um CMS? Se o seu problema passou por essa intensa bateria de reflexões, você realmente pode começar a pensar em testar algum CMS, mas isso é papo para artigos posteriores.

5.11.04

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.

3.11.04

Usabilidade de paginação de resultados: Orkut, BuscaPé, Submarino e Google


Um dos grandes e persistentes problemas de usabilidade é a navegação entre os resultados de uma busca. Nem sites famosos escapam deste problema. Veja como o Orkut, BuscaPé, Submarino e Google se comportam nessa situação.


A motivação

Ao navegar no Orkut, percebi que aquele menuzinho de navegação no canto superior direito possui uma fonte bem pequena, linkando cada página dos resultados (ocorrências). Ora um algarismo tem uma largura muito pequena, utilizando tamanho de fonte padrão do browser (sem alterações personalizadas no CSS). Assim, tomei este site e mais 2 nos quais lembrava que existia algum tipo de páginação (BuscaPé e Submarino) e, para finalizar, peguei o Google, uma referência na web atual.


Teoria

Algumas heurísticas de usabilidade orientam para exibir um link que seja fácil de clicar, no sentido de poupar do usuário habilidades de arqueiro, ao posicionar o mouse em cima de um link. Esse tipo de coisa acontece frequentemente em menus drop-down, mas é paginação que ele se faz presente, constantemente.


Navegação, na prática

Com exceção do Submarino, que pagina por intervalos (1-50, 51-100, etc), todos os outros utilizam apenas o algarismo a que se refere à página. Ou seja, um largura extremamente curta para ser clicado. Além, é claro, da formatação que não ajuda muito.


Como fica o CSS?


Orkut: Verdana, 11px.



BuscaPé: Verdana, 10px, além de aplicar STRONG direto no HTML.



Submarino: Arial, 11px.



Google: Arial, 10pt.


Deste modo, com fonte em torno de 11px (ou 10px + STRONG, o que não ajuda muito, no BuscaPé) o algarismo solitário ainda fica difícil de ser clicado. É claro que na paginação de "10" para cima a coisa melhora, pois uma dezena tem largura maior. Mas isso não resolve o problema.


Situações pontuais

Quando o usuário utiliza 800 x 600 ou uma configuração que torna a fonte maior, o problema é minimizado. Mas não é conveniente forçar o usuário a adora uma configuração tal ou então aplicar um CSS personalizado, bem como aumentar a fonte (Ctrl + no FireFox).


Contornando o problema

Exibir links como o Submarino faz, pode ser adequado em situações específicas. Se o resultado de uma busca oferecer uma quantidade pequena de registros, forçar a criação de intervalos (mesmo que pequenos) pode ser inconveniente para o usuário. Portanto, essa solução não pode ser gereralizada.

Uma solução possível é aplicar, dentro da tab "a href" um espaço em branco antes e depois do algarismo, aumentando a área clicável do link, aplicando o HTML: n . Essa solução não é semanticamente perfeita, piora um pouco a acessibilidade (força a leitura de um "espaço em branco" nos leitores de tela) mas valida corretamente o código e torna a usabilidade melhor.

Essa solução é extremamente fácil de ser implementada pelas linguagens server-side, uma vez que no loop de geração da páginação pode ser incluído facilmente "&NBSP;" antes e depois do algarismo a ser linkado, quando este link é gerado dinamicamente.


Conclusão

O problema de criar links com má usabilidade é muito comum na paginação. Sites famosos ainda cometem este erro, sistematicamente. No entanto, não podemos forçar usuários com dificuldades de coordenação motora ou pouca acuidade visual a ficar "catando" o link de uma paginação de resultados.