Não é comum usar o blog para isso, mas neste caso achei que valia muito a pena abrir uma exceção.

Há muito pensei em escrever a respeito de validação HTML, prós e contras, mas acabei deixando de lado por falta de tempo para pesquisar mais a fundo e acabei esquecendo do assunto.

Contudo, hoje me passaram no twitter um excelente artigo intitulado “The value of HTML validation“, escrito por Nicholas C. Zakas falando de tudo que eu gostaria de escrever e indo muito além.

Fica a recomendação.

Os pontos que surgiram na conversa foram os seguintes:

Falta de foco:

Acreditamos que este seja o principal problema. Em nenhum momento falou-se claramente “isso serve pra aquilo” – só se falou que era um milhão de possibilidades, que as pessoas iam ter orgasmos com os recursos mágicos, só que… Não se falou como. Os exemplos apresentados do que fazer com a ferramenta foram pífios e, até onde eu sei, ninguém fez algo que fosse digno de nota usando o Wave.

Interface diferente “Pero no mucho”:

A idéia vendida foi de uma interface revolucionária. A estrutura ousa muito pouco (repare que a diagramação e distribuição, exceto pela caixa de texto, é quase a do Gmail) e, no pouco que ousou, ficou confuso e sem atrativos – caso do box de texto, que tem um monte de recursos mas nenhum exatamente novo.

Por exemplo pra que diabo fazer uma enquete se pode-se usar um Spreadsheet com o próprio Google Docs com mais recursos e sem todo o ruído visual do Wave ao redor?

Excesso de expectativa

Criou-se muita expectativa de revolução para uma ferramenta que foi lançada inacabada. Mesmo que tivesse uma proposta inovadora, a chance de causar uma boa impressão foi totalmente perdida – muitos usuários não dão segundas chances para ferramentas, especialmente se vierem a se sentir “burros” ao usar.

Alguém lembra do vídeo de uma hora e tra-la-lá apresentando o produto e das pessoas em extase assistindo à demonstração? Até a risada gravada do chaves parecia mais sinceras que aquilo.

Ferramentas tardias

Vários recursos desejáveis relacionados à usabilidade só surgiram muito depois do lançamento, como uma forma de aviso sobre novos waves ou a possibilidade de excluir-se de uma lista Wave (embora implementado é MUITO ruim a navegação e são vários cliques até conseguir).

Tudo bem que melhorias podem sempre ser feitas posteriormente, mas creio que a idéia deles que as pessoas querem ficar conectadas às outras para sempre em tudo que for compartilhável é bem errada – até porque, se verdade fosse, divórcio não existiria.

O Wave não é uma onda, é uma ilha

Na ânsia de tentar ser a nova ferramenta de comunicação da internet, rede social, messenger, email e chat tudo ao mesmo tempo, não foi criada forma alguma de interface com outras ferramentas já existentes. Sequer um RSS.

Entendemos que, de forma até prepotente, o Google tentou apresentar um novo paradigma e romper com todos os antigos – mas foi inocência demais acreditar que pessoas largariam ferramentas que usam há anos e começassem a focar tudo no Wave, e que elas não quereriam integração com mais nada. Por que não uma possibilidade de conectar algo ao Facebook? Por que, no começo, sequer com o próprio Gmail tinha conexão? Já foram adquiridos muitos hábitos nos últimos 15 anos, e uma cultura deste tipo não é jogada para o alto de uma hora pra outra.

Para saber da dificuldade de mudar um hábito é só pensar quanto tempo demorou pro e-mail substituir o fax. Para algumas empresas, aliás, isso ainda é uma realidade.

Documentação ruim / falta de incentivo aos desenvolvedores

Por conta talvez da já citada falta de foco, a documentação voltada a desenvolvedores (que poderiam ter sido umas das fontes de salvação) foi escrita de maneira péssima, tornando a possibilidade de que boas idéias vindas da comunidade minguasse muito.

Poucos heróis aventuraram-se a fazer algo para o Wave, mas a maioria resolveu esperar para ver no que dava antes de perder precioso tempo estudando algo que pudesse dar em água. E deu.

Entrada por convite

Outra coisa que frustrou pessoas: se você já tem Gmail, conta no Orkut, conta no Picasa, Gtalk e etc, por que cargas d’água precisa ser convidado para usar uma ferramenta que, em tese, já é parte das suas aplicações/contas Google? Convites são feitos para coisas que são extremamente desejáveis e, se feitos ao acaso, gera uma expectativa de “é bom valer a pena”. Dá sensação de pagar pra entrar num clube privado e descobrir lá dentro que é só um boteco comum.

Tudo que se propôs a resolver já tinha solução

Concordo, muita coisa até pode ser melhor solucionado no Wave, caso por exemplo da função de edição conjunta e compartilhamento de documentos. Mas… As pessoas já faziam isso no Google Docs há anos. E já eram familiares à estrutura “word-like” lá utilizada, afinal, todos já estão bem adestrados desde o win 3.11 a usar aquela estrutura. Não importa o quão mais simples seja a interface, para aquele tipo de solução de editor será, sempre, muito difícil propor algo novo.

Integração demais = lentidão

As possibilidade de juntar tudo e todos é tão grande que por vezes é insustentável manter um wave por muito tempo. Tantos são os aplicativos, replys, icones de participantes, referências internas, referências externas, etc, que só com muita memória RAM você consegue usar o Wave de forma decente.

Puxando a Sardinha para o Chrome

O Google pedia descaradamente para você usar o Wave no Chrome. Sim, é mais do que verdade que o Chrome é um tremendo de um browser, com o melhor “motor” para interpretação de Javascript feito até então, não só o Wave, mas tudo que usa Ajax como base para interface web.

O caso é que o usuário não sabe disso. Se o site está lento, para o usuário a culpa não será do IE6, será do site. Mesmo no Firefox, que é um browser bastante decente, fica insuportável de lento, forçando a usar o Chrome.

Não importa o quão verdadeiro é o fato de que o Chrome lida melhor com Javascript com os outros: a campanha/lavagem cerebral pelo browser da casa sempre vai deixar com aquele fundinho de que foi sabotagem nos outros navegadores (coisa que não foi MESMO). E como tem neurótico a rodo nessa terra, especialmente entre desenvolvedores (isso, aqueles mesmos que poderiam ter salvo aspectos da aplicação), é mais um motivo que afasta os potenciais usuários.

O nome do produto não é “iWave”

Se o google wave fosse produzido pela Apple ou fosse uma app para iPhone, os geeks moderninhos certamente ajudariam a vendê-lo como uma idéia de outro mundo.

Falando mais sério, essa foi outra falha na estratégia do Google: eles tentaram fazer algo que a Apple faz há anos, que é vender qualquer idéia como se fosse revolucionária (mesmo que seja só um iPod grandão com menos recursos que o original).

O lance é que a Apple assume essa postura e o risco do produto não dar certo. Eles perdem com o que não da certo, mas é um risco menor: a Apple conhece bem seu público e já percebeu qual é a forma que eles tendem a agir, então raramente dá uma bola fora (e quando dá sabe exatamente o que falar para o público continuar sentindo-se querido e feliz com o status de ser um possuidor de um produto deles).

Conclusão

De megalomania aos problemas de projeto, é realmente uma pena ver uma ferramenta morrer deste jeito, sem chegar a atingir todo seu potencial. Engraçado, pois uma das coisas que comentamos durante o papo é que, depois de algumas experiências, ela era um bom lugar para juntar material de pesquisa e pequenos Brainstorms (com direito até a descobrir nesse exato momento que há um novo recurso voltado para mind map, que sempre foi um recurso do qual sentimos muita falta).

Quando finalmente achamos o que fazer com a ferramenta o Google decide enterra-la.

Na primeira parte dei uma visão simples e geral sobre o que é SEO.

Na segunda, falei sobre o que é e pra que servem as Meta Keywords .

No terceira, o por quê de ainda preocupar-se com Meta Description e o motivo de te-la bem feita.

Nesta parte, a última desta sequência, vou explicar como pode-se “pegar carona” na relevância de outros sites através de links.

Aumentando a relevância por links

Daí o cidadão vai lá e pergunta como fazer o texto dele “subir no Google” e, alguém com um pouco mais de manha, sugere para selecionar as palavras chaves e nomes e linkar para sites externos. O cidadão olha torto e solta os cães, dizendo coisas como “que absurdo, colocar links para sites externos, isso vai tirar os leitores do nosso site e mimimi mimimim mimimim mimimim mimimimimi”.

Sim, eu já ouvi isso…

Em primeiro lugar, ponto de vista humano: as pessoas vão dar é muito mais valor para os textos do site pelo simples fato que a informação oferecida é mais completa – e se o site não tem em si mesmo a informação, o autor aponta, sem medo, pra algum outro que a tenha.

Segundo lugar, ponto de vista dos Search Engines: nossos camaradas buscadores aumentarão a sua importância em muito pelo mesmíssimo motivo citado no primeiro lugar. A lógica é: quanto mais referência para outras páginas/sites com assuntos relacionados, maior a chance do usuário encontrar um conteúdo satisfatório. Levando em conta que os buscadores tem os dados de relevância das páginas que você referenciou de seu texto, quanto maior a qualidade do link dado maior será a relevância emprestada para o seu texto. Entedeu?

Vamos a um exemplo prático que o Alex Borges me indicou: se voce digitar “Restaurante Italiano” no Google hoje, 4 de agosto de 2010, o primeiro resultado será http://www.emsampa.com.br/r_11.htm.

Pelas regras básicas que o SEO sugere, veremos de cara 3 erros graves:

• Erro 1 : URL com link bizarro, que não quer dizer absolutamente nada, ao invés de uma url amigável;
• Erro 2:  Código “sujo” e confuso, inteiro feito em tabela, provavelmente feito com editor visual mal-configurado;
• Erro 3: Número de meta keywords muito alto.

… E por aí vai.  Tem mais erros, mas estes já deveriam ser suficientes pra mandar o link lá pra nona página – mas isso não acontece, ele está em primeiro. Como? Sequer as palavras “Restaurante” e “Italiano” é repetida muitas vezes, qual o segredo pra justo este link estar no topo?

O motivo mais provável é que, pelo fato desta página ter um índice imenso de links para diversos sites de restaurantes italianos, possivelmente com a grande maioria com um pagerank razoável, isso é o suficiente para que o buscador acredite que é uma fonte confiável para a referência “restaurante italiano”.

Em outros casos você poderia, por exemplo, citar uma empresa e linkar diretamente para o site dela – especialmente se o site em questão vier em primeiro no resultado. Em geral, se o site-referência for muito ruim ou inexistente, você ainda pode apelar para a Wikipedia, que é sempre uma ótima saída para este fim.

Bom, acredito que seguindo estes passo, já é possível melhorar e muito a relação com os buscadores. Obvio que é mais extenso que isso e, por conta das regras mudarem todo dia, dá pra pirar muito mais dentro deste assunto.

Para saber mais:

SEO na Wikipedia – história, teoria e mais algumas regras básicas.

Blog oficial do Google – melhor referência de todas para aprofundar-se no assunto. Se qualquer regra muda, se há alguma boa prática a ser seguida, certamente sairá aqui.

Google Webmaster Tools – Ferramentas para verificar qualidade de conteúdo do ponto de vista do buscador, diagnósticos de meta tags redundantes, etc.

Yahoo Site Explorer – mesma pegada do link anterior, mas nas regras do Yahoo.

Google Trends – Mas e aí, as pessoas procuram mais pela palavra “Carro” ou por “Automóvel”? Qual delas trará mais acessos? O Google Trends te ajuda com isso.

Artigos Mestre SEO - particularmente eu não gosto muito deste site, por vezes tenho a impressão que muito do material é só reescrito de tempos em tempos com palavras diferentes, tornando-o um pouco redundante – mas eu sou chato pra cacete com algumas coisas, então pode ser só cisma minha. De qualquer forma, mesmo com o porém que eu falei, tem bastante coisa legal e vale a consulta para tirar dúvidas.

E este é o final desta série, senhoras, senhores e crianças. Quem quiser debater o assunto pode entrar em contato comigo pelo próprio blog ou pelo twitter.

Até!

Vamos falar um pouquinho mais de meta-tags, mais especificamente da meta description.

Meta Description

O nome é auto-explicativo: é uma descrição do texto que segue, enfatizando os principais pontos. Deve ser o mais resumido possível afim de evitar penalização (algo em torno de 150 caracteres) e deve ir, como as outras metas, dentro da tag head.

<meta name="description" content="Um bom exemplo de meta descrição resume bem o conteúdo do texto, enfatizando os principais tópicos" />

Três pontos a frisar:

1) Muita gente usa como texto de descrição os primeiros X caracteres ou mesmo o primeiro parágrafo inteiro do texto no body. Isso NÃO é legal pois corre-se risco de ser penalizado pelo buscador - como disse no texto anterior sobre Keywords, buscadores não gostam de "ecos" dentro da página, lembram?

2) Assim como as Keywords, não use descrições repetidas em todas as páginas. Novamente, se não for possível criar as descrições de forma individual, prefira não usar nenhuma deixando toda a relevância por conta do texto contido no body (afinal, também como nas Keywords, uma description redundante ou que tenha qualquer espécie de conflito de informação com o texto pode vir a trazer muito mais prejuízo do que ajuda).

3) Oriente os responsáveis pelos textos a escrever esta síntese "com amor". Quando a description existe na página, o buscador a usará para gerar o resultado de busca - ou seja, podemos dizer que ela tornar-se-á o cartão de visitas do texto e, quanto melhor escrito/resumido, mais convidativo ao clique será ao nosso amigo usuário.

Mas e aí, quão importante é isso?

Depende do ponto de vista. Como dito em outros textos, tudo o que mais importa para os buscadores hoje em dia encontra-se no BODY do texto, e os demais requisitos até servem pra incrementar (urls amigáveis, microformatos, meta-tags, robots.txt, etc) mas, de um modo geral, é a qualidade da sua informação que fará a diferença.

O próximo texto e último dessa série (o que não quer dizer que eu não vá voltar ao assunto) falarei um pouco a respeito do que é essa qualidade de informação, e como qualidade pode ser "emprestada" ou repassada.

Até!

Esta é a forma como a especificação DOM define um “DOM”:

O Document Object Model (DOM) é um Application Programming Interface (API) para HTML válido e documentos XML bem formatados. Ele define a estrutura lógica dos documentos e o modo como um documento é acessado e manipulado.

Em outras palavras, o DOM é uma forma padrão para permitir que as linguagens de programação interajam com documentos HTML / XML. O W3C fornece, o que é chamado de linguagem de vinculações, para o ECMAScript. Isto significa que as funcionalidades definidos na especificação DOM foram implementadas nessa linguagem.

ECMAScript é uma “uniformização” da língua (script) dos “homens das cavernas” – Netscape JavaScript e Microsoft JScript para que todos os browsers possam compreender instruções escritas usando o ECMAScript.

Agora, existem três grandes “dialetos” do ECMAScript: JavaScript (Firefox / Chrome / Safari), JScript (IE), e ActionScript (Adobe Flash / Flex). Estes são chamados dialetos como suporte a código escrito antes da normalização e fornecem alguns recursos não disponíveis no ECMAScript ou em outros dialetos.

Os navegadores fornecem uma implementação das interfaces do DOM que permite ECMAScript (ou dialetos suportados) interagirem com o DOM de um documento XML/HTML. Assim, a maioria dos browsers decentes, lançado conforme os padrões, dizem qual ECMAScript é suportado para cada versão do seu navegador.

O DOM de uma página HTML tem uma “árvore-como estrutura” quando visualizadas. É importante notar que o DOM não representa o conteúdo do HTML, mas representa apenas objetos através dos quais o conteúdo pode ser acessado. Esses objetos são modelados após a marcação que existe na página HTML. As relações, funções, comportamentos e atributos desses objetos são identificados pelo DOM.

Bom, é isso! Você normalmente não precisa de saber sobre interfaces DOM principalmente se você trabalhar com uma biblioteca JavaScript. Mas se você estiver interessado, Quirksmode (http://www.quirksmode.org) tem uma excelente introdução ao DOM.

Em meio às tecnologias para troca de dados e comunicação entre aplicações pela web como REST, SOAP, WSDL etc, se destacam também as APIs que fornecem dados com simples requisições http diretamente do site via browser, sem a necessidade de processamento do lado do servidor pelo cliente do serviço. Para esses casos temos o JSONP como uma alternativa “bem em conta” para resolver problemas conhecidos. O objetivo desse post é dar uma introdução do que é e como usar o JSONP.

AJAX vs JSONP

Tecnicamente, JSONP não é AJAX, vamos a uma explicação bem breve da diferença:

AJAX se trata de requisições assíncronas por meio dos objetos XMLHttpRequest e XMLHttpResponse, que trafegam dados no formato XML ou texto puro. Esses dados são manipulados pelo programa javascript, que finalmente monta seus trechos de html sem a necessidade do recarregamento da página.

Já o JSONP requisita dados de forma assíncrona, assim como o AJAX, porém não utiliza os objetos XMLHttp e  só trabalha com objetos no formato JSON.

JSON – JavaScript Object Notation

Formato de dados que vem sendo fortemente utilizado para transporte de dados entre aplicações, principalmente web. Está ganhando seu espaço devido a sua simplicidade de implementação e leveza. É um subconjunto das notações de objetos javascript. Além disso, a manipulação dos dados em um objeto JSON requer um parse simples (usando o método eval do javascript) e não se faz necessária a navegação por DOM entre os nós e atributos de um XML, e por isso a preferência pelo JSON ao invés de XML para ajax na web.

Same Origin Policy

Existe uma limitação para o uso do Objeto XMLHTTPRequest no que se trata de requisições entre diferentes sites. Existe um padrão de segurança, implementado por linguagens de programação, nesse caso o javascript, chamado Same Origin Policy, ou Política de Mesma Origem. Essa recomendação de segurança impede que um documento leia ou envie informações para outra origem.

São considerados de origens diferentes quaisquer documentos que estejam em domínios diferentes, portas diferentes ou que utilizem protocolos de comunicação diferentes entre si.

Considerando a url: “http://www.afronteirafinal.com/”, podemos ter requisições que irão ter sucesso ou falhar nas seguintes situações:

JSONP – JSON with Padding

JSONP é entendido como um “pseudo-protocolo” que permite realizar requisições http e trafegar dados no formato JSON entre documentos de origens diferentes.

Como funciona:

A implementação do JSONP e bastante simples, porém é necessário que o serviço responsável pela entrega os dados forneca a opção de entrega na estrutura necessária para que os dados possam ser manipulados.

Não existem restrições para o carregamento de imagens e scripts de outras origem, por meio do atributo “src” das tags. A técnica por tras do JSONP se aproveita dessa possibilidade para carregar scripts externos conforme a necessidade, manipulando o DOM da página.

O que faz acontecer o JSONP é a inclusão de uma TAG “script” no header “<head>” da página. Essa tag “script” recebe um atributo “src” apontando para o site externo, que responde objetos no formato JSON , esse resultado é “parseado” e fica disponível para manipulação via JavaScript.

O que é o “padding”?

Padding ou prefix é o nome passado na requisição ao serviço, para que na resposta o método envolva os dados em formato JSON após a resposta. Quando a requisição é feita dessa forma:

<script type="text/javascript" src="http://domain1.com/getjson?jsonp=parseResponse" target="_blank"></script>

A palavra “parseResponse” será a o nome da função que envolverá o json, como um callback. O resultado será algo parecido com isso:

parseResponse({“name”:”Jujuzinho”, ”idade”:10, brinquedos:[“bola”,”pipa”,”ioiô”]})

Você, como um esperto desevolvedor, já terá declarado esse método (parseResponse) em seu programa, e este saberá como sabiamente utilizar os dados recebidos.

Suporte nos frameworks

Os frameworks JavaScript geralmente dão um bom suporte às implementações do JSONP, resolvendo a maioria das questões que teríamos que nos preocupar fazendo tudo “na unha”.

No caso do jQuery, ele abstrai as particularidades entre jsonp e ajax e incorpora o JSONP com mais um formato de dados para o seu objeto Ajax.

Em caso de dúvidas, primeiro procure a documentação do framework porque certamente ele trará informações de como implementar jsonp sem mais traumas.

No próximo episódio…

No próximo post sobre o assunto falaremos sobre o futuro. Como será feito o transporte de dados pela web. Protocolos de comunicação de verdade para rodar no browser. Que projetos já estão em andamento e como eles poderão resolver problemas que travam o avanço da comunicação entre apps web.

O QUE É SVG?

SVG é uma linguagem para descrever gráficos bidimensionais e aplicações gráficas em XML. Alguns exemplos de SVG são: o logo da Wikipedia (http://upload.wikimedia.org/wikipedia/commons/7/77/Wikipedia_svg_logo.svg) e o “Hello World” do SVG chamado de “Tiger” (http://www.amplesdk.com/examples/svg/tiger). Veja o fonte desses dois arquivos SVG para ver como SVG parece.

Demo SVG:

<svg xmlns:svg="http://www.w3.org/2000/svg"
  xmlns="http://www.w3.org/2000/svg"
  viewBox="0 0 200 100"
  width="200px" height="100px">
  <circle cx="50" cy="50" r="30"
  style="stroke:none; fill:#ff0000;"/>
  <g transform="translate(100, 20) scale(1.65)">
  <polygon points="36 25, 25 36, 11 36, 0 25,
  0 11, 11 0, 25 0, 36 11"
  style="stroke:none; fill:#0000ff;" />
  </g>
  <rect x="60" y="20" height="60" width="60"
  style="stroke:none; fill:#00ff00;
  fill-opacity: 0.5;" />
</svg>

O QUE É CANVAS?

A especificação do HTML 5 define da seguinte forma: “Elemento de tela que representa um processamento gráficos “bitmap” para gerar imagens, gráficos, jogos através de JavaScript”.

Vladimir Vukićević da Mozilla, em 2006, deu uma boa explicação sobre as diferenças entre o SVG e Canvas:

- SVG é baseado em XML. Isto significa que, cada elemento está disponível no DOM SVG (útil quando você deseja anexar os manipuladores de eventos javascript para um elemento). Canvas não é baseado em XML.

- Canvas é processado pixel por pixel. SVG é um monte de vetores e precisa ser manipulado como um grupo de formas. Uma analogia no mundo Photoshop seria, criar um retângulo usando a “ferramenta forma” contra usar o “PaintBrush”.

Demo Canvas:

E aqui está o JavaScript que o criou o desenho:

function drawSimpleCanvas() {
 var canvas =
 document.getElementById("simpleCanvas");
  if (canvas.getContext) {
  var ctx = canvas.getContext("2d");
  ctx. (); // the circle
  ctx.fillStyle = "#ff0000";
  ctx.arc(50, 50, 30, 0, 2*Math.PI, true);
  ctx.closePath();
  ctx.fill();
  ctx.save();
  // move and resize the octagon
  ctx.translate(100, 20);
  ctx.scale(1.65, 1.65);
  ctx.fillStyle = "#0000ff";
  ctx.beginPath();
  ctx.moveTo(36, 25); ctx.lineTo(25, 36);
  ctx.lineTo(11, 36); ctx.lineTo(0, 25);
  ctx.lineTo(0, 11); ctx.lineTo(11, 0);
  ctx.lineTo(25, 0); ctx.lineTo(36, 11);
  ctx.closePath();
  ctx.fill();
  // restore graphics as they
  // were before move and resize
  ctx.restore();
  ctx.fillStyle = "#00ff00";
  ctx.globalAlpha = 0.5;
  ctx.beginPath();
  ctx.rect(60, 20, 60, 60);
  ctx.closePath();
  ctx.fill();
 }
}

QUEM VAI GANHAR?

Mesmo que sejam completamente diferentes na sua natureza e finalidade, há várias coisas que pode ser feito usando “Canvas” e “SVG”. A recente popularização do elemento “Canvas” parecem para algumas pessoas a morte do SVG. Mas pelo que notei está longe da verdade.

O “Canvas” é tão bom como uma imagem – mas ele não manipula pixel por pixel. Neste momento, elemento Canvas não suporta os “manipuladores” de eventos (por exemplo, ter um retângulo 20x60px dentro de um canvas que seja clicável). Já com o SVG isso é possível.

Canvas em seu estado “natural” não é acessível. O SVG, porém, é bastante acessível.

No entanto existe diferenças significativas de desempenho entre Canvas e SVG. O resultado do experimento descrito no link (http://www.borismus.com/canvas-vs-svg-performance) é que: Canvas é mais adequado para um “gráficos intensivos” onde o objeto são os redesenhos com freqüência (como um jogo), enquanto o SVG é melhor para aplicações que envolvem grandes áreas de processamento (como Google Maps).

POSSO USÁ-LOS AGORA?

Sim, pode. Existem muitas iniciativas para permitir que os navegadores que não suportam SVG ou Canvas tornarem-se “usáveis” por outros meios. O Google tem um impressionante projeto SVG Web (http://code.google.com/p/svgweb/) que usa o Flash para renderizar SVG em navegadores que não suportam SVG nativamente. Para Canvas, o Google tem uma biblioteca “explorecanvas” (http://code.google.com/p/explorercanvas/) que utiliza VML (ou Silverlight) para processar os elementos Canvas (basta incluir o arquivo excanvas.js, e ele deve funcionar) no Internet Explorer.

ENTÃO… QUEM GANHA?

Ambos. Estas é uma fase fantástica para SVG e Canvas. Finalmente temos uma alternativa natural para o “Flash” e animação de necessidade básica. Mantenha seus olhos abertos no “mailing list” do “W3C HTML Working Group” (http://lists.w3.org/Archives/Public/public-html/) para as últimas notícias.

Se você não é desenvolvedor deve se perguntar nesse momento:

“- Eu não sou desenvolvedor, devo me perguntar nesse momento se preciso mesmo saber sobre meta tags?”

Bom, sim e não.  Você não precisa necessariamente saber onde aplica-las no código, mas tem que saber como funcionam e para que servem pois pode existir um campo específico para isso no seu publicador.

Existem algumas dúzias de meta tags que se pode usar no código mas, uma vez que a proposta é não sair do básico do SEO, vamos falar somente das mais importantes nessa série de textos. Aliás, vamos falar uma coisa que pouca gente aborda em textos sobre SEO: em geral as pessoas dão enfase à aplicação, enquanto aqui pretendo falar o real porquê  de usa-las de forma x ou y.

Palavras Chave – Keyword

As keywords são declaradas no topo das páginas e servem basicamente para enfatizar para nossos amigos buscadores sobre o que estamos falando no nosso texto. Há muitos e muitos anos, quando as estrelas eram jovens e Yahoo e Cadê já eram antigos, elas foram o principal campo de consulta dos robots de pesquisa. No código aparecem similar a isto aqui, dentro das tag de head:

<meta name="keywords" content="festa,sandices,quadrinhos" />

A relevância das palavras chave não é mais tão importante quanto já foi por causa dos espertinhos da Web: o camarada ia lá nas keywords dele e lançava “Sabrina Sato pelada, putaria, bunda”.  Daí o buscador ia lá todo feliz fazer a classificação e entregava o resultado pro usuário e, este último, frustrado, descobria que o texto era sobre coleções de selos do século 20 ao invés da referida moça desnuda.  Quem perdia credibilidade nessa história? O buscador, é claro.

Mas aí? Vale a pena usar?

Mas mesmo com essa falta de crédito, o uso bem feito de keywords pode ajudar um pouco na relevância da sua página. Tenha em mente que as palavras usadas nas keywords devem estar contidas no texto, se possível mais de uma vez ou, se não for o caso, ser um sinônimo ou estar estritamente correlacionada ao assunto em questão. Mesmo que você monte um set de palavras que pareçam favorecer o texto, tenha em mente que a má escolha delas pode detonar o seu posicionamento no buscador – logo, se não tiver certeza que aquelas são as melhores escolhas, PREFIRA NÃO USAR NENHUMA KEYWORD. Keywords que não tenham nenhuma ou que tenham pouca conexão com o texto prejudicam ao invés de ajudar.

Exemplo: você escreveu um texto sobre sorvete de jaca e em algum momento disse “seria legal que a Kibon lançasse o sorvete de jaca”.  “Sorvete” e “jaca” seriam palavras importantes como keyword, já Kibon, sendo citado uma única vez no texto e sem nenhuma informação relevante além da menção,  se usada como palavra chave seria a âncora que afundaria tua página por posições e mais posições – afinal, você disse pro buscador que seu texto era relevante sobre isso, ele acreditou, e te classificou na seção “textos relevantes da kibon” e não no “textos relevantes sobre sorvete de jaca”, que era seu assunto principal.

Reciclagem de keywords pode?

“-Entendi, tio Vespa. Posso então escolher as mesmas 5 keywords fodonas e pô-las em todo meu sáite?”

NÃO! Keywords repetidas em várias páginas é como dizer que todo seu site é uma imensa redundância, mesmo que isso não seja verdade. Se o site não tem uma forma rápida de “taguear” todas as páginas, use a regra do não usar nada ou aplique palavras chave apenas no que for conteúdo novo. Você pode usar a mesma palavra várias vezes, mas nunca no mesmo conjunto. Se numa pagina você usou “água, fogo, terra” na próxima poderia usar “água, fogo, ar” que não teria problema – mas nunca “água, fogo, terra” pra duas ou mais.

Outro ponto importante é a quantidade de keywords usadas, evite usar mais do que 5. Muitas keywords poluem o código e caem na regra que citei no texto anterior, “se todo mundo é especial então ninguém é especial”, mandando a relevância pro brejo.

Alguns sistemas, em especial blogs, tem aproveitado a capacidade de gerar tags dos publicadores para reaproveitar o tagueamento nas Keywords. Já vi gente que defende que essa reciclagem não é boa – buscadores são entidades ariscas e não gostam de redundância, ainda mais se for na mesma página. Eu discordo disso por um fato muito simples: keywords são palavras texto, simples, separados por vírgula, enquanto as tags são as mesmas palavras mas com um fatorzinho diferente: elas estão linkadas, logo não estão totalmente redundantes, estão complementando informação já citada – então acredito que não seja algo realmente prejudicial, embora acredite que seja melhor variar um pouco a informação de uma e de outra por questão de aumentar abrangência.

Bom, creio que a respeito de Keywords é o que há de principal a se falar. No próximo episódio falaremos a respeito de meta description. Até!