Klaus Paiva

Esse texto surgiu de uma necessidade que é bastante comum pra nós, seres programadores de interfaces web.

Sabe quando o webdesigner desenha uma caixa de tamanho fixo (e largura variável, pra complicar um pouco), em que o texto deverá ficar contido ali dentro da caixa, e no caso do texto ser maior que o tamanho disponível, os famosos "três pontinhos" devem aparecer?

Pra ilustrar isso melhor, veja a imagem abaixo:

Caixa com dimensões fixas e conteúdo "ajustado" para caber

Um método comum de se fazer isso é contar o número de caracteres e colocar "...", caso o número de caracteres ultrapasse o número máximo de caracteres que ficarão visíveis. Claro que esse número máximo é uma estimativa e nem sempre o resultado fica bom. Além disso, pode acontecer do "corte" no texto acontecer no meio de uma palavra, gerando um resultado estranho ao visitante, "tipo isso aq...".

Nas CSS existe uma propriedade chamada "text-overflow" que, sob certas circustâncias, adiciona automagicamente "..." ao final do texto que não coube na área visível. OK! Problema resolvido então? Não exatamente...

O problema não está resolvido por conta de duas outras questões. Uma delas é que o Firefox ainda não implementa essa propriedade (sim, o IE tem! Moderno hein? ). A outra questão é que essa propriedade não se aplica nos casos em que o texto ocuparia mais de uma linha.

Se você quiser uma explicação mais detalhada (e exemplos) sobre a propriedade "text-overflow", acesse este texto no blog do PPK.

Voltando ao assunto original, agora precisamos resolver aquelas duas questões. Felizmente, com algum tempo de Google e mais algum tempo de pesquisa em fóruns, consegui encontrar algo capaz de ajudar nesta tarefa: o jQuery textOverflow Plugin.

O código é relativamente simples e oferece várias opções de customização. Aqui tem uma página de exemplo (exemplo 1) gerando algo similar ao que foi mostrado na imagem acima.

Caso você tenha vários elementos na página que vão receber esse tratamento, deixo uma dica: tome cuidado com a performance! Como é uma operação intensiva no DOM, a chance desse código deixar o navegador bastante lento é bastante alta.

Pra esses casos, se você realmente precisa dos "...", acho que vale a pena tentar juntar esse código com a solução de "execução de Javascript com pausas", proposta pelo Nicholas Zakas.

Fiz uma proposta com essa combinação. Ela pode ser vista aqui no exemplo 2 (com 100 elementos). Embora seja visualmente mais lenta, ela não trava o navegador em momento algum, mesmo no IE 6.

Bom, o texto ficou bem longo... mas acho que deu pra passar bem a ideia. Sugestões ou comentários, é só usar o formulário abaixo.

Pra quem não entendeu o motivo da questão no título deste texto, uma breve explicação: as duas opções são formas válidas para se definir qual é a versão "original" em casos de conteúdo duplicado.

Mas se são duas formas diferentes de se chegar ao mesmo resultado, qual delas escolher? Há vantagens e desvantagens? Há casos em que só uma delas se aplica? São essas perguntas que eu tentarei responder aqui neste texto.

Entendendo o problema do conteúdo duplicado

Para entender onde e como aplicar corretamente as soluções acima, é importante entender qual é o real problema com conteúdo duplicado. Para entender isso, vamos precisar de um exemplo: a página inicial desse blog encontra-se em http://blog.klaus.pro.br/ - mas nada impede que alguém faça um link para ela assim: http://blog.klaus.pro.br/?home. Note que ambos os endereços funcionam perfeitamente.

No caso acima, os dois endereços exibem a (mesma) página inicial deste blog. Agora pense como um robô indexador, será que os dois endereços mostram o mesmo conteúdo porque alguém quer me enganar, dando a impressão de que há mais conteúdo do que realmente há no site, ou simplesmente os dois endereços são considerados a mesma página pelo sistema do site em questão. E se os dois endereços realmente apontam para uma mesma página, qual deles eu devo considerar como "principal" ou "original"?

Para resolver essa ambiguidade e, de quebra, definir qual é a página "original", as duas soluções acima podem ser empregadas.

Onde as duas soluções se aplicam

Quando você está resolvendo a questão de conteúdo duplicado apenas dentro do domínio de seu site, as duas soluções são aplicáveis. Ou seja, usar a meta tag canonical ou um redirecionamento 301 resolve perfeitamente a questão, levando-se em conta a restrição de domínio acima.

Desta forma, para resolver o problema citado no começo deste texto usando a meta tag canonical bastaria eu colocar isso na página incial do meu blog:

<link rel="canonical" href="http://blog.klaus.pro.br/" />

Onde apenas a meta tag canonical se aplica

Nota: Este exemplo foi retirado deste vídeo.

Se no seu site você possui uma versão "normal" da página e uma versão para impressão, muito provavelmente as páginas serão muito parecidas, a ponto de parecerem conteúdo duplicado para um indexador de conteúdo.

Se você colocar um redirecionamento 301 na página de impressão, nenhum usuário vai conseguir ver a página, o que definitivamente não é uma solução para o problema . Já com a meta canonical você pode informar sem problemas que a página "normal" é a versão "original" daquele conteúdo.

Onde apenas um redirecionamento 301 (ou 302) se aplica

A meta canonical não é válida (ou seja, ela é ignorada) quando a página referenciada encontra-se em outro domínio. Nesses casos, para indicar que o conteúdo original encontra-se em outro lugar, sua única opção é fazer um redirecionamento permanente ou temporário (301 ou 302, respectivamente) para o conteúdo "original".

Conclusão

Se você precisa resolver o problema de conteúdo duplicado em páginas de domínios diferentes, suas opções são os redirecionamentos 301 ou 302. Se ambas as páginas precisam ser acessíveis pois seu conteúdo é muito parecido mas não é igual, use a meta tag canonical.

É isso!

Como já passamos da metade de setembro, já está mais do que na hora do nosso TCC começar a tomar suas formas finais.

O protótipo com tudo aquilo que levantamos nesse tempo de pesquisa e trabalho ficará pronto esta semana, possivelmente na quarta-feira. Já fizemos vários testes, digamos, "menos formais" enquanto o protótipo estava sendo desenvolvido e tudo correu bem.

Porém, assim que o protótipo estiver concluído, será a hora de aplicar alguns testes mais completos e fundamentados para garantir que aquilo que levantamos realmente tem algum valor.

Método de execução do testes

OK, precisamos testar e verificar os resultados... mas o que usar para concluir essa tarefa? Após alguma pesquisa chegamos ao "king of usability" como a Internet Magazine o definiu anteriormente e encontramos uma forma que se encaixou perfeitamente ao que precisamos cumprir: a avaliação heurística.

A ideia básica por trás da avaliação heurística é conduzir uma série de testes em um sistema a fim de identificar pontos com uma usabilidade ruim. Para descobrir esses pontos é necessário verificar após os testes se algo não obedece aos padrões de usabilidade definidos (daí a heurística do negócio).

O que validar?

Após definir a forma de executar os testes, era necessário descrever tudo aquilo que deve ser validado nos testes. Novamente contamos com a ajuda do Dr. Jakob Nielsen para isso.

O Dr. Jakob sugere uma lista com 10 itens que podem ser validados numa avaliação heurística de interfaces. Com base nessa lista e nas informações explicadas no texto, pudemos gerar a nossa lista de fundamentos fazendo diversas adaptações, correções e adições.

Testes com pessoas

Após termos essas duas fases concluídas, a próxima fase (que é a fase que estamos agora) é fazer o teste com pessoas reais (que se beneficiaram do sistema em seu estado final) e verificar os resultados.

Até aí tudo certo... Vamos testar com pessoas mas... Quantas pessoas? A pergunta parecia ter uma difícil resposta, mas novamente o Dr. Jakob já publicou um artigo oportunamente chamado "Why You Only Need to Test with 5 Users".

No artigo acima é demonstrado que com cinco usuários, estatisticamente, você consegue encontrar 85% dos problemas de usabilidade de um sistema. Com base nessa informação seus custos e tempo necessários para realizar os testes podem ser mantidos num patamar baixo e acessível, facilitando a execução dos testes mesmo quando se tem severas restrições orçamentárias.

Por fim...

A partir da semana que vem nossos testes começarão. Ao que tudo indica, o processo será trabalhoso mas está bem fundamentado e promete bons resultados. Logo saberemos.

Muita gente conhece o método String.replace do Javascript. De forma geral, ele é o método que permite substituir (jura? =) uma (sub)string por outra string.

É um método bastante usado em códigos Javascript, principalmente por possibilitar o uso de expressões regulares na hora de fazer as substituições. A forma mais comum de uso é algo do tipo:

"Javascript".replace( /[aeiou]/g, "" )

O trecho de código acima remove as vogais da string "Javascript" resultando na string "Jvscrpt", bem simples.

Mas o que nem todo mundo sabe (e eu costumo não lembrar também) é que o segundo parâmetro do método replace pode ser uma função qualquer, que será executada recebendo como parâmetro a parte da string que "casou" com a expressão dada.

Desta forma você pode manipular como bem quiser a parte que "casou" da expressão regular. Isso é útil, por exemplo, se você quer procurar URLs numa determinada string e reduzir aquelas com mais de N caracteres.

Fiz um código que mostra o exemplo acima funcionando. Veja o exemplo aqui.

Nota 1: A expressão regular para "casar" URLs está bem simples e contida para o exemplo... não "casaria" todos os formatos possíveis de URL.

Nota 2: O método substr no IE não funciona como esperado quando se tem parâmetros negativos. Que azar...