Na campo do web design e desenvolvimento, estamos rapidamente chegando ao ponto de ser incapaz de prosseguir com as resoluções infinitas e novos dispositivos. Para muitos websites, foi criando uma versão website para cada resolução e novo dispositivo seria impossível, ou pelo menos impraticável. Devemos apenas sofrer as conseqüências de perder visitantes de um dispositivo? Ou existe outra opção?

Responsive Website é a abordagem que sugere onde design e desenvolvimento deve responder ao comportamento do usuário e ambiente baseado na plataforma, tamanho de tela e orientação. A prática consiste em uma mistura de grades flexíveis, layouts, imagens e um uso inteligente de consultas de media CSS. Como o usuário hoje é “portável”, ele sai de seu laptop e vai para iPad, o website deve alternar automaticamente para acomodar o novo tamanho de tela, resolução imagem e habilitar scripts específicos. Em outras palavras, o site deve ter a tecnologia para responder automaticamente a preferências do usuário. Isso eliminaria a necessidade de um design diferente para cada novo dispositivo no mercado.

O Conceito de Responsive Website

“Ethan Marcotte” escreveu um artigo introdutório sobre a abordagem, “Responsive Web Design“, para o “A List Apart”, dando uma noção de design arquitetônico responsável, no qual fala sobre “espaços” que se ajusta automaticamente ao número e fluxo de pessoas dentro dele.

Transpondo esta disciplina para o Design de sites, temos uma idéia similar. Por que deveríamos criar um design web personalizados para cada grupo de usuários; afinal, arquitetos não projetam um edifício para cada tamanho e tipo de pessoas que passes através dela? Como na arquitetura inteligente o site deve se ajustar automaticamente. Não deve requerem incontáveis soluções personalizadas para cada nova categoria de usuários.

Obviamente, não podemos usar sensores de movimento e robótica para realizar isto. Um Design Web “adaptável” exige uma forma mais abstrata de pensar. Entretanto, algumas idéias já estão sendo praticadas: layouts fluido, media queries e scripts que podem reformatar uma página web e fazer um “mark-up” automaticamente.

Mas um Responsive Website não é somente sobre resoluções de tela ajustável e imagens automaticamente redimencionadas, mas sobre uma maneira inteiramente nova de pensar sobre design web. Vamos falar sobre todos esses recursos e os conceitos associados.

Ajustando a Resolução da Tela

Com novos dispositivos no mercado, a variedade de resoluções de tela, definições e orientações são cada vez maiores. Novos dispositivos com novos tamanhos de tela estão sendo desenvolvidos diariamente, e cada um desses dispositivos pode ter variações nas corres, tamanho e funcionalidade. Alguns estão na orientação paisagem, outras em retrato, e outro ainda completamente quadrado. Como sabemos, a partir da crescente popularidade dos smartphones, iPhone e iPad, os novos dispositivos são capazes de mudar de retrato para paisagem no capricho da vontade do usuário. E como fazer um projeto para essas situações?

Além de projetar para ambos, paisagem e retrato, devemos considerar as centenas de diferentes tamanhos de tela. Sim, é possível agrupa-los em categorias principais e fazer cada design ficar tão flexível quanto necessário.

“Morten Hjerde” e alguns de seus colegas identificaram, em estatísticas, que aproximadamente 400 dispositivos vendidos entre 2005 e 2008 usam alguns dos tamanhos abaixo:

Desde então mais dispositivos saíram para o mercado. E é óbvio que não podemos manter/criar soluções personalizadas para cada um deles. Mas como lidamos com a situação?

Parte da Solução: Deixe tudo Flexível

Alguns anos atrás, quando layouts flexíveis eram quase um “luxo” para websites, as únicas coisas que eram flexíveis em um design foram as colunas do layout e o texto. Imagens poderiam facilmente quebrar seu layout, e mesmo tendo uma elementos estruturais flexíveis, quebrava o layout. Designs flexíveis não eram realmente tão flexível; eles poderiam dar ou ocupar algumas centenas pixels, mas eles freqüentemente não poderia ajustar a uma tela de computador grande para uma de netbook.

Agora podemos tornar as coisas mais flexível. Imagens podem ser automaticamente ajustadas, e temos soluções alternativas para o layout não quebrar. Embora não seja uma correção completa, a solução nos dá uma opção. É perfeito para dispositivos que alternam de orientação facilmente (de retrato para paisagem) ou para quando os usuários passam de um computador grande para um iPad.
No artigo de “Ethan Marcotte”, ele criau um “Responsive Website” de demonstração que mostra melhor as características este layout flexível:

O design inteiro é uma mix encantador de grids fluido, imagens fluido e mark-up inteligente onde necessário. Criando grids fluido é razoavelmente é uma prática comum, e há um número de técnicas para criar imagens fluido:

- Escondendo e Revelando Parte de Imagens
- Criando Sliding Composite Images
- Images Foreground escaláveis com o tamanho do layout

Para mais informações sobre criação de websites fluido, recomendo o livro “Flexible Web Design: Creating Liquid and Elastic Layouts with CSS” por Zoe Mickley Gillenwater, e baixar o capítulo exemplo “Criando Imagens Flexíveis“, além de uma extensa lista de tutorials, resources e melhores práticas sobre criação de grids flexível e layouts: “Essential Resources for Creating Liquid and Elastic Layouts”
Enquanto que do ponto de vista técnico tudo isso é facilmente possível, mas não se trata apenas de ligar esses recursos e tudo está feito.

Imagens flexível

Um grande problema que precisa ser resolvido com um “Responsive Website” são as imagens. Há uma série de técnicas para redimensionar imagens proporcionalmente, e muitos são facilmente aplicadas. A opção mais popular é usar CSS max-width para um reparo fácil.

img { max-width: 100%; }

Enquanto nenhuma outra regra de largura em imagem for usada para substituir essa, cada imagem será carregada em seu tamanho original, a menos que a área de visualização torna-se menor que a largura original da imagem. A largura máxima da imagem é definido como 100% da tela ou largura do navegador, então quando que 100% torna-se mais estreito, o mesmo acontece com a imagem. Essencialmente, como Jason Grigsby observou: “A idéia por trás imagens de fluidos é fornecer imagens no tamanho máximo que será usado. Você não declarar a altura e a largura em seu código, mas sim você deixa o browser redimensionar as imagens quando necessário ao usar CSS para orientar seu tamanho relativo”. É uma grande técnica e simples para redimensionar imagens.

Note-se que max-width não é suportada no IE, mas um bom uso de width: 100% em um arquivo CSS específico resolveria o problema. Mais uma questão é que quando uma imagem é redimensionada para um espaço menor, em alguns navegadores mais antigos no Windows, a renderização não é tão clara como deveria ser. Mas existe alguns scripts JS quem corrigem este problema.

Sabemos que o tamanho da imagem original é destinado a dispositivos de grande porte. Mas se as imagens forem renderizadas em um dispositivo móvel, o que poderiamos fazer para não impactar significativamente o tempo de download e ocupar um espaço desnecessário?

Imagens Responsável por Grupo

Esta técnica, apresentada por Grupo, leva em consideração não apenas o redimensionamento de imagens proporcionalmente, mas também em diminui a resolução da imagem em dispositivos menores, paras as imagens grandes não desperdiçarem um espaço desnecessário em telas pequenas.

Esta técnica requer alguns arquivos, os quais estão disponíveis no Github. Primeiro, o arquivo JavaScript (rwd-images.js) e o arquivo .htaccess. Então, podemos usar apenas um pouco de HTML para fazer referência tanto a resolução de imagens maiores e menores:

- Primeiro, a imagem pequena e em seguida uma referência para a imagem maior usando o parâmetro “full“.

<img src="smallImg.jpg?full=largeImg.jpg">

O parâmetro “full” definido no arquivo relacionado acima e para qualquer tela que é maior do que 480 pixels, a imagem de maior resolução (largeImg.jpg) será carregado; telas menores não precisariam carregar a imagem maior, e assim a imagem menor (smallImg.jpg) será carregada.

O JavaScript insere no arquivo de imagem um elemento base que permite a página decidir qual a melhor usar para aquela determinada resolução. Quando a página carrega, todos os arquivos são reescritos para sua forma original, e apenas as imagens grandes ou pequenas são carregadas quando necessário. Com outras técnicas, todas as imagens de alta resolução teriam que ser carregados, mesmo que as versões maiores nunca seriam usados. Principalmente para sites com muitas imagens, esta técnica pode economizar muito no consumo de banda e tempo de carregamento.

Esta técnica é totalmente suportado em navegadores modernos, como o IE8+, Safari, Chrome e Opera, bem como os dispositivos móveis que usam esses navegadores mesmo (iPhone, iPad, etc.) Navegadores mais antigos (IE7 e Firefox) degradam muito bem e ainda redimensionam a imagem de resposta quando esta sendo carregada, mas para ambos em resoluções menores esta técnica é nula.

Redimensionamento de imagens no iPhone

Uma coisa legal sobre o iPhone e iPod Touch é que website se redimensiona automaticamente para caber na tela pequena. Um projeto normal só iria diminuir proporcionalmente no browser para um tamanho minúsculo, sem a necessidade de deslocamento para uma versão mobile. Então, o usuário poderia facilmente dar um “zoom in/out”, conforme necessário.

Mas isso gera um problemas quando redimencionamos as imagens proporcionalmente conforme o tamanho da tela. As imagens ainda são carregadas na sua forma original.

Para resolver este problema podemos usar uma meta tag específicas da Apple, colocando em seu site, dentro da tag <head> o código abaixo:

<meta name="viewport" content="width=device-width; initial-scale=1.0">

Definindo o initial-scale para 1 substitui o padrão de redimensionamento das imagens, deixando como é que a largura do site fique com a mesma largura do dispositivo (nos modos retrato ou paisagem). A documentação da Apple tem muito mais informações sobre a meta tag viewport.

Estrutura de layout personalizado

Para mudanças de tamanhos extremos, podemos querer alterar o layout totalmente, através de uma folha de estilo separada ou, de forma mais eficiente, através de uma consulta de mídia CSS. Este mudança não deve ser problemática, a maioria dos estilos pode permanecer o mesmo, enquanto as folhas de estilo específicas podem herdar estes estilos e os elementos podem ser decorados como “carros alegóricos”.

Por exemplo, poderíamos ter uma folha de estilo principal (que também seria o padrão) que define todos os principais elementos estruturais, tais como #conteiner, #header, #content , #sidebar, #nav, #footer, juntamente com cores, fundos e tipografia. Larguras com padrões flexíveis também poderia ser definido.

Se uma folha de estilo fez o layout muito estreito/curto (largura ou altura), poderíamos então detectar isso e mudar para uma nova folha de estilo. Esta nova folha de estilo “filha” adotaria esta a folha de estilo padrão e acrescentaria apenas o necessário para redefinir a estrutura do layout.

Aqui está o base.css (padrão) de conteúdo:

* link para o arquivo base.css

Media Queries

O CSS3 suporta todos os mesmos tipos de mídia como CSS 2.1, tais como screen, print e handheld, mas acrescentou dezenas de novos recursos de mídia, incluindo max-width, device-width, orientation e color. Novos dispositivos feitos após o lançamento do CSS3 (como o iPad e dispositivos Android) vai certamente dar suporte a recursos de mídia. Então, chamar uma consulta de mídia usando recursos CSS3 para esses dispositivos iria funcionar muito bem, e seria ignorado se acessado por um computador com um navegador mais antigo que não suporta CSS3.

Exemplo:

<link rel="stylesheet" type="text/css" media="screen and (max-device-width: 480px) href="sheetland.css" />

Esta consulta de mídia é bastante auto-explicativa: se o navegador exibe esta página em uma tela (ao invés de impressão, etc), e se a largura da tela (não necessariamente o viewport) é de 480 pixels ou menos, então carregar sheetland.css.

Novos recursos CSS3 também incluem “orientation” (paisagem e retrato), device-width, min-device-width e muito mais. Pode-se criar várias folhas de estilo, bem como alterações no layout básico, definido para atender faixas de larguras e orientações (paisagem/retrato). Não deixe de olhar o artigo “Meet the media query” para mais exemplos e uma explicação mais aprofundada.
Várias consultas de mídia também podem ser descartadas para uma folha de estilo único, que é a opção mais eficiente quando utilizado:

/* Smartphones (portrait and landscape) ----------- */
@media only screen and (min-device-width : 320px) and (max-device-width : 480px) {
    ....
    styles here
    ....
}
/* Smartphones (landscape) ----------- */
@media only screen and (min-width : 321px) {
    ....
    styles here
    ....
}
/* Smartphones (portrait) ----------- */
@media only screen and (max-width : 320px) {
    ....
    styles here
    ....
}

O código acima é de um modelo livre para várias consultas de mídia entre dispositivos populares por Andy Clark. Veja as diferenças entre esta abordagem e incluindo arquivos estilo diferente folha no mark-up como mostrado no post “Hardboiled CSS3 Media Queries”

Consultas de Mídia CSS3

Acima estão alguns exemplos de consultas como a mídia, tanto do CSS 2.1 e CSS3 poderia funcionar. Vamos agora olhar para alguns casos específicos de como usar consultas de mídia em CSS3 para criar projetos Web responsáveis. Muitos destes usos são facilmente aplicados hoje, e todos serão definitivamente aplicáveis em um futuro próximo.

As propriedades min-width e max-width fazer exatamente o que eles sugerem. O min-width propriedade define um browser mínimo ou largura da tela que um determinado conjunto de estilos (ou folha de estilo separada) seria aplicada. Se alguma coisa está abaixo deste limite, o link folha de estilo ou estilos serão ignorados. O max-width propriedade faz exatamente o oposto. Qualquer coisa acima da largura do navegador ou na tela de máxima especificada não se aplica à consulta respectivas mídias.

Nota nos exemplos abaixo que estamos usando a sintaxe para consultas de mídia que poderiam ser usados ​​todos em um folha de estilo. Como mencionado acima, a forma mais eficiente de usar consultas de mídia é colocá-los todos em uma folha de estilo CSS, com o resto dos estilos para o site. Desta forma, várias solicitações não têm que ser feitas para várias folhas de estilo.

@media screen and (min-width: 600px) {
  .myClass { width: 30%; float: right; }
}

Na consulta de mídia acima a classe ( .myClass ) irá funcionar apenas se o navegador ou a largura da tela for acima de 600 pixels. Em outras palavras, esta consulta de mídia será executado somente se a largura mínima for de 600 pixels.

@media screen and (max-width: 600px) {
  .aClassforSmallScreens { clear: both; font-size: 1.3em; }
}

Agora, com o uso do max-width, esta consulta de mídia só se aplica a quando a largura da tela (ou navegador) for no máxima de 600 pixels ou mais estreita.

As consultas min-width/max-width podem ser aplicadas em qualquer tamanho de tela ou largura de navegador, às vezes é necessário fazer uma consulta de mídia que é relevante para um dispositivo específico. Isto significa que mesmo se um navegador ou área de visualização for minimizado para algo menor, a consulta de mídia ainda se aplicam ao tamanho do dispositivo real. O min-device-width e max-device-width são propriedades de consulta de mídia usados para atender um grupo de dispositivos com dimensões definidas, sem aplicar os mesmos estilos de outros tamanhos em um navegador que “imita” o tamanho do aparelho.

@media screen and (max-device-width: 480px) {
  .classForiPhoneDisplay { font-size: 1.2em; }
}

@media screen and (min-device-width: 768px) {
  .minimumiPadWidth { clear: both; margin-bottom: 2px solid #ccc; }
}

Há também outros truques com consultas de mídia para dispositivos de destino específico. Thomas Maier escreveu dois pequenos trechos e explicações para a segmentação do iPhone e do iPad apenas:

- CSS for iPhone 4 (retina display)

- How To: CSS para o iPad

Para o iPad especificamente, há também uma propriedade consulta de mídia chamado de orientação. O valor pode ser paisagem (orientação horizontal) ou retrato (orientação vertical).

@media screen and (orientation: landscape) {
  .iPadLandscape { width: 30%; float: right; }
}

@media screen and (orientation: portrait) {
  .iPadPortrait { clear: both; }
}

Infelizmente, esta propriedade só funciona no iPad. Para determinar a orientação para o iPhone e outros dispositivos o truque é usar o max-device-width e min-device-width.
Há também muitas consultas de mídia que fazem sentido quando combinados. Por exemplo, o min-width e max-width podem definir um estilo específico.

@media screen and (min-width: 800px) and (max-width: 1200px) {
  .classForaMediumScreen { background: #cc0000; width: 30%; float: right; }
}

O código acima nesta consulta de mídia só se aplica quando a tela/browser tiver uma larguras entre 800 e 1200 pixels. Um bom uso dessa técnica é mostrar determinados conteúdos ou sidebars inteiro, dependendo da quantidade de espaço horizontal disponível.

Alguns desenvolvedores front-end preferem um link para uma folha de estilo separada para determinadas consultas de mídia. Se os benefícios organizacionais superarem a eficiência perdida – Tudo bem!. Para dispositivos que não mudam de orientação ou para telas cuja largura não podem ser alterados manualmente, usar uma folha de estilo separada são uma ótima alternativa.

Outro exemplo é um projeto flexível, destinado a telas de computadores com navegadores redimensionável. Se o navegador pode ser redimensionado manualmente, colocar todas as consultas variáveis de mídia em uma folha de estilo  é a melhor saida.

No entanto, a organização pode ser a chave, e um desenvolvedores front-end pode querer definir consultas de mídia em uma tag de link HTML:

<link rel="stylesheet" media="screen and (max-width: 600px)" href="small.css" />

<link rel="stylesheet" media="screen and (min-width: 600px)" href="large.css" />

<link rel="stylesheet" media="print" href="print.css" />

JavaScript

Outro método que pode ser usado é o JavaScript, especialmente como um back-up para dispositivos que não suportam todas as opções de consulta de mídia CSS3. Felizmente, já existe uma biblioteca JavaScript pronta que faz com que os navegadores mais antigos (IE5+, Firefox 1+, Safari 2) oferecer suporte a consultas de mídia CSS3. Se você já está usando essas consultas, basta pegar uma cópia da biblioteca e incluí-lo no seu código: css3-mediaqueries.js.

Além disso, você pode optar por uma abordagem mais “hands-on” como no código jQuery abaixo. Que detecta a largura do navegador e muda a folha de estilo.

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js">
<script type="text/javascript">
  $(document).ready(function(){
    $(window).bind("resize", resizeWindow);
    function resizeWindow(e){
      var newWindowWidth = $(window).width();
      // If width width is below 600px, switch to the mobile stylesheet
      if(newWindowWidth < 600){
        $("link[rel=stylesheet]").attr( {href : "mobile.css"} );
      }
      // Else if width is above 600px, switch to the large stylesheet
      else if(newWindowWidth > 600){
        $("link[rel=stylesheet]").attr( {href : "style.css"} );
      }
    }
  });
</script>

Existem muitas soluções em JavaScript para consultas de mídia CSS. Lembre-se que as consultas de mídia não são uma resposta absoluta, mas são ótimas opções para Web Developers quando se trata de soluções baseadas em CSS puro. Com a adição do JavaScript que podem acomodar variações muito mais abrangentes. Para obter mais informações leia o artigo “Combinação de consultas Mídia e JavaScript”

Mostrando ou ocultando Conteúdo

É possível diminuir as coisas proporcionalmente e reorganizar os elementos necessário para fazer caber tudo (razoavelmente bem), quando uma tela fica menor. Mas fazer todo o conteúdo de telas grandes disponíveis em uma tela menor ou dispositivo móvel nem sempre é a melhor alternativa. Temos como boas práticas para ambientes móveis: uma navegação mais simples, o conteúdo mais focado, listas/linhas em vez de múltiplas colunas.

O Web Developer não deve apenas saber como criar um layout flexível em uma ampla gama de plataformas e tamanhos de tela. Ele deve também deixar o usuário escolher o conteúdo. Felizmente, via CSS é possível mostrar e ocultar o conteúdo com facilidade!. Utilizando o “display: none;”

Basta declarar “display: none” para o elemento HTML que precisa ser escondido, em uma folha de estilo específica ou detectar a largura do navegador, e fazê-lo através de JavaScript. Além de esconder o conteúdo em telas menores, também podemos esconder os blocos em nossa folha de estilo padrão.

Note que não falamos do “visibility: hidden”, isso apenas deixa o conteúdo invisível (embora ele ainda está lá), enquanto a propriedade “display: none” esconde dele completamente. Para dispositivos menores, não há necessidade de manter o mark-up na página – isso poderia causar uma deslocamento desnecessário ou até quebrar o layout.

Aqui está o nosso mark-up:

<p>
  <a href="#">Left Sidebar Content</a> | <a href="#">Right Sidebar Content</a>
</p>
<div id="content">
  <h2>Main Content</h2>
</div>
<div id="sidebar-left">
  <h2>A Left Sidebar</h2></span>
</div>
<div id="sidebar-right">
  <h2>A Right Sidebar</h2>
</div>

Em nossa folha de estilo padrão a seguir, temos escondido os links para o conteúdo da barra lateral. Porque a nossa tela é grande o suficiente, podemos exibir este conteúdo no carregamento da página.
Aqui está o base.css (padrão) de conteúdo:

#content { width: 54%; float: left; margin-right: 3%; }
#sidebar-left { width: 20%; float: left; margin-right: 3%; }
#sidebar-right { width: 20%; float: left; }
.sidebar-nav { display: none; }

Agora em seguida, nós escondemos as duas barras laterais e mostramos os links de navegação para estes pedaços de conteúdo. Como alternativa, os links de navegação poderiam ser chamados via JavaScript, apenas para cancelar o “display: none”, quando clicado as barras laterais poderiam ser exibidas abaixo do conteúdo (#content).

Aqui está o conteúdo (mais simples) mobile.css:

#content { width: 100%; }
#sidebar-left { display: none; }
#sidebar-right { display: none; }
.sidebar-nav { display: block; }

Com a facilmente mostrar e ocultar conteúdo, reorganizar os elementos de layout e redimensionar automaticamente imagens, elementos de formulário e muito mais, um projeto pode ser transformado para atender a uma enorme variedade de tamanhos de tela e tipos de dispositivos. Quando a tela fica menor, reorganizar os elementos para se adequar as diretrizes móveis, por exemplo, use um script ou folha de estilo alternativa para aumentar o espaço em branco ou para substituir imagens de navegação em dispositivos móveis para uma melhor usabilidade (ícones seria mais benéfico em telas menores).

Abaixo estão alguns dos recursos pertinentes:

- Mobile Web Design Trends For 2009
- 7 Usability Guidelines for Websites on Mobile Devices

Alguns exemplos de Responsive Website

Abaixo temos alguns exemplos de Responsive Websites em prática hoje. Para muitos desses sites, existe várias soluções para uma variedade de navegadores, e alguns até mesmo ajustam os elementos dinamicamente dependendo do tamanho da tela e dimensões específicas do navegador. Visite cada um destes, e ajuste o tamanho do navegador ou dispositivos de mudança de vê-los em ação.

Galeria de “Media Queries”

http://mediaqueri.es/

Food Sense

http://foodsense.is/

Fonte: Smashing Magazine, A List Apart, 24 ways, Impressive Webs

Como tudo mais nessa fina arte, há algumas receitas para atrair mais pessoas também na forma como se escreve o texto. E, como tudo nessa vida, deve ser usada com parcimônia – não vá fazer um texto muito quadrado, voltado somente para o buscador. Lembre-se: você tem que ser achado, mas um texto de qualidade é o que fará a pessoa voltar ao seu site (senão eu aplicava 100% das regras a seguir nos meus próprios posts e fazia este blog viver de buscadores), ter milhares de acessos do buscador é só um número inflado de leitores que não trarão nenhum benefício para seu produto.

Descubra os termos mais relevantes

O primeiro ponto para se escrever um texto com um bom SEO é, depois de escolhido um assunto, fazer um exercício e pensar: “se EU estivesse procurando por isso no todo poderoso buscador, o que eu digitaria?”.

A minha sugestão é sempre pensar em por volta de 5 a 8 termos associados a isto e tentar utiliza-lo no texto. Não precisa ser exatamente 5 a 8, um pouco mais ou menos não vai matar ninguém – mas quanto mais você conseguir sintetizar a informação melhor.

E já que eu estou falando de uma receita de SEO para turbinar o seu texto, que melhor outro exemplo eu poderia usar do que uma receita culinária? Vamos então falar de um assunto mais polêmico que mamilos: vamos falar de PURÊ DE MAÇÃ.

Primeiro ponto: o que eu, D. Vespa, sei sobre purê de maçã?

Bom, eu sei que é um prato típico holandês e alemão também. Sei que é bom para acompanhar carne suína e aves e, em geral, é servido junto com purê de batata para dar um contraponto salgado para o adocicado da maça.

Partindo do parágrafo acima, já temos alguns bons termos para começar:

• • Carne de aves
• • Carne Suína
• • Acompanhamento
• • Culinária Holandesa
• • Cozinha Alemã

Já temos uns termos interessantes baseado no que EU sei a respeito do assunto. Mas… Será que meu conhecimento é o mesmo do público que quero atingir? Como faço pra saber se, de repente, se as palavras que eu buscaria também fazem sentido pras outras pessoas?

Termos relacionados do Google e Yahoo

Há um cantinho na página de resposta do Google que volta uma pesquisa de termos relacionados aos termos que você procurou. Não são sempre lá muito precisos – mas você pode encontrar algumas boas sugestões no qual pode não ter pensado:

No Yahoo estes resultados relacionados podem ser vistos aqui:

Detalhe importante: ELES NÃO APARECEM SEMPRE, só quando usamos um termo mais popular. Então, se não encontra-los de vez em quando, não se desespere.

Olhando a imagem acima, percebo que o purê de batata também é um termo que merece destaque – então vamos acrescenta-lo a lista e lembrar de dar algum destaque a ele. Culinária também é um termo bom, deve ser frisado pelo menos uma vez no texto.

Mas… Peraí, peraí… Bateu uma dúvida agora: “culinária” e “cozinha” são, neste contexto, sinônimos. Qual destes termos é mais procurado pelas pessoas? E os termos “carne de porco” e “carne suína”, qual deles é mais apropriado?

Para isso podemos usar o… (tchanaaaan!)

Google Trends, o juíz

Muito simples, pequeno gafanhoto, o nosso amigo Google tem uma ferramenta bem bacana chamada Google Trends que compara os termos para você e mostra qual deles teve mais procura nos últimos meses/anos.

E, segundo esta estatística é melhor dar preferência para “cozinha” ao invés de “culinária” e para “carne de porco” ao invés de “carne suína”. Legal, não? Tem algumas funçõezinhas mais específicas como filtro de país, uma indicação se houve algum evento que potencializou a busca por determinado termo em alguma época específica, etc… Mas isso é bem fácil de descobrir fuçando lá.

E que tal umas imagens também, aproveitando a mão na massa?

Mas usar imagens melhora o SEO?

Lembrando que existe busca de imagens, então sim, ajuda muito. Pare pra pensar que, além de mais dois elementos reforçando palavras chave no seu texto, os buscadores de imagens usam as palavras próximas a elas para classificar sua posição na página de resposta – então sim, você vai ganhar alguns acessos por conta disto também.

Detalhes: bold e links, as cerejas do bolo

… embora no purê de maçã não vá cereja.

Ao escrever o seu texto, sempre que um termo surgir pela primeira vez marque-o em negrito. Se você estiver escrevendo o código de formatação na unha, certifique-se que o seu negrito é uma tag STRONG e não um simples B – a prioridade do STRONG, dentro da escala de importância de cada tag HTML, é superior ao B – e acredito que essa classificação estenda-se aos buscadores também. (Se você não entendeu muito bem este parágrafo, não se preocupe, apenas marque o negrito que tiver no seu editor de texto e tudo ficará bem, não há consequências graves. ).

E quanto aos links, é a mesma lógica que já abordei em outro post: quanto mais links externos e internos você tiver falando a respeito daquele assunto (cozinha alemã/holandesa, receitas de maça, acompanhamentos, etc) mais bem visto será seu texto por um buscador.

O resultado de tudo que escrevi acima esta aqui, na receita de purê de maçã para microondas.

Estou curioso para ver como os buscadores irão reagir em relação a este texto pois, embora totalmente estruturado para ter uma classificação relevante no resultado de busca, o fato de estar publicado em um blog de tecnologia pode influenciar na hora de criar esta classificação. De qualquer forma, acompanharei quantos resultados voltarão a partir deste texto “bastardo” para o nosso blog e, se for interessante, quem sabe não rende um novo post?

Caso voce tenha curiosidade e queira ir mais a fundo na fina arte do SEO, abaixo há mais alguns artigos que escrevi a respeito:

• SEO sem crise – Uma visão simples e rápida
• SEO sem crise parte 2 – Meta tags: Keywords
• SEO sem crise – Parte 3 – Meta Description
• SEO sem crise – Parte 4 – Relevância por links

Purê de maça é um acompanhamento típico da cozinha holandesa e da alemã. É uma excelente opção para servir com carne de porco (como pernil e salsichas) ou aves. Recomenda-se servir o purê de maça e à carne junto a purê de batatas, que fará contraponto ao doce da maçã e dá um sabor especial a todo o conjunto.

Para esta saborosa receita você vai precisar de:

• • 3 maçãs inteiras
• • Canela em pó
• • Meia colher de gengibre em conserva
• • Meio copo de água

Descasque as maçãs e use um ralador para transforma-la numa pasta. Coloque numa forma refratária e acrescente o gengibre, água e canela a gosto. Coloque por cinco minutos no microondas em potência média. Espere esfriar por alguns minutos e sirva enquanto estiver morno.

Serve duas pessoas.

Mais receitas de Purê de maçã:

• Purê de maçã no Cybercook
• Purê de maçã com limão no receitas e menus
• Receita de tender com purê de maçã no tudo gostoso

Resolvi escrever algumas impressões a respeito de iPad por dois motivos: primeiro por recentemente ter visto uma palestra a respeito de como os designers gráficos estão migrando as revistas impressas para suas versões online. O segundo motivo foi o bem humorado artigo do amigo Rogério Fratin sobre a não-exploração dos recursos do iPad enquanto plataforma,  tornando este meio algo só um pouquinho mais sofisticado que qualquer dispositivo que tenha um Adobe Reader instalado – só que muito mais caro.

De cara já quero por em xeque a afirmação que vi em alguns lugares dizendo que o iPad é o substituto do notebook/desktop: isso é besteira da grossa, se considerarmos todos os contextos. Um tablet tem tudo para substituir um notebook no caso do usuário comum, aquele sujeito que usa seu computador para apresentar um PPT, jogar, ler emails e usar algumas funções organizacionais (como agendas ou acompanhamento de dados interfaceados), enquanto o notebook continuará encarregado de tudo isso (com uma experiência de usuário mais simples) mais a realização de tarefas que exijam maior complexidade, como tratar imagens, diagramar, programar, gerar wireframes, ilustrar, gerenciar sistemas de interfaces mais complexas ou via terminal, etc.

Mas não é este meu ponto ainda.

Como qualquer outra mídia nova, as pessoas responsáveis pela gênese dos que será divulgado a partir dela usam o mesmo processo de sempre: usam como base algo que já existia, até que a novidade comece a criar sua própria identidade – foi assim a transição do jornal impresso pro rádio, do rádio pra TV, da TV/Rádio/impresso para os videogames e computadores e todas derivações e variações em torno destas mídias.

O grande porém do iPad é que, talvez por uma resistência tradicionalista, talvez pela fobia que o “mercado impresso” tem de ser suplantado por alguma outra mídia (o que na minha opinião NÃO vai ocorrer), as pessoas estão vendo no iPad a “cura” para este fantasma que meios como a internet e os games trouxeram – e estão tropeçando DE NOVO nos mesmos erros que foram feitos há 15, 20 anos.

iPad não é impresso

Algumas redações assumiram que a idéia de revista virtual é simplesmente converter a impressa para um formato de arquivo que possa ser lido na tela. Tudo bem, pode ser feito assim – mas qual a vantagem então de estar no iPad, desconsiderando os custos de produção/impressão? Existe um desespero das companhias em “demarcar território” nas novas mídias, para usar a expressão “saímos na frente” em campanhas de marketing. Mas vale a pena ter este título a qualquer custo? Uma experiência pobre num meio que promete tanto é frustrante para o consumidor e, uma vez que se cria uma imagem ruim, é muito difícil reverte-la.

Este mesmo erro foi cometido anos atrás com a própria internet, os primeiros sites de revistas tentaram (e em alguns casos ainda tentam) ser uma cópia literal da versão impressa. Cheguei a ouvir absurdos de editores que queriam que o site fosse a revista exatamente como na banca, com animação de virar de páginas e tudo mais para emular a experiência do impresso.

Não valeria mais a pena estudar melhor as possibilidades antes de botar a mão na massa?

A internet já fez isso antes

Esquecendo um pouco a febre dos aplicativos que é assunto pra outro post, a tentativa de verter conteúdo impresso para digital já foi feita e já tem característica própria há muitos anos. Por que não se valer dessas experiências?

Uma coisa que vejo de diferencial do texto para web para o de e-revistas é que, dado que o formato das tablets é muito mais cômodo para transporte e leitura,  pode dar-se ao luxo de usar textos longos igual ao das revistas – e não só os míseros parágrafos como os que escrevo agora, limitado pela paciência do usuário para ler blogs (da qual já abusei se você chegou até aqui). :p

Percebi que, ávidos por essa possiblidade, redações montaram não só o texto, mas as próprias revistas como seriam feitas para as gráficas – mesmo que se tenha alterado estilos para o novo tamanho e uma ou outra animação para justificar o meio digital. Os resultados? As interações de iPad são simples como as já oferecidas em 2000 pelo flash 3.0 e o arquivo final é EXTREMAMENTE pesado, às vezes chegando até 1/2 giga numa revista completa, coisa simplesmente absurda ainda mais se tratando dum dispositivo que tem só 64 gigas de memória.

Problemas simples como compressão das imagens de forma correta já baixariam o peso destes arquivos substancialmente. O problema do download é outro que remete também ao final dos anos 1990, quando tinha-se que carregar um arquivo completo para poder lê-lo/interagir com ele. Já que as tablets são voltadas para o uso de internet, não seria mais inteligente usar um sistema para baixar em lotes, como também já foi resolvido com flash e ajax e outros formatos web? Vi alguns testes relativos a isso, mas muito tímidos ainda para melhorar algo de maneira efetiva.

Texto eletrônico não-indexavel é texto morto

Alguns softwares voltados para a conversão das revistas para iPad são, basicamente, print screens tirados do inDesign transformando textos e imagens numa coisa só. Numa pesquisa em impressos você pode, ao ir a uma biblioteca, consultar um índice de cartões separados por autor e por assuntos para tentar encontrar o livro de seu interesse. Num sistema digital, as suas opções são ou usar um sistema de índice de hyperlinks (que pode ser falho, pois normalmente só traz o título da matéria/assunto) ou um sistema de busca, próprio para identificar um termo buscado em partes do texto.

Mas se é um print screen, como se faz isso? É simples: não faz. Você até tem a opção de usar um sistema de índice por hyperlinks, mas… E se o título da matéria for, por exemplo, uma metáfora ou um trocadilho e não refletir claramente o contéudo? Há o recurso de hotspot (um trecho de texto que abre em layer quando clicado, como um popup. Pode ser usado como descritivo), mas realmente não acredito que seja uma solução boa.

Imagine isso num futuro não muito distante, quando houver umas 20 revistas na memória da tablet ou HD exerna, você vai MESMO lembrar que edição falava sobre aquele determinado assunto? Não, você vai querer dar um crtl+f e buscar nos arquivos – o que não vai acontecer se o texto for imagem.

Conclusão

Eu sei que muitos dos problemas citados se devem às experiências de como os Tablets estão sendo aceitos e a cultura de uso que se forma ao redor deles, mas a maioria a meu ver é injustificável – simplificando ao máximo a solução, a colaboração direta de pessoas que já trabalham com mídias digitais mais a conhecimento vindo do meio impresso (em especial na questão da diagramação) geraria uma experiência muito mais empolgante para o usuário.

Mas realmente acredito que não se demorará a criar uma fórmula mais interessante, a maior parte das soluções já está aí, tudo pronto para se usar, é só questão de tempo até se organizarem – e gente capacitada para isso é o que não falta.

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.

@font-face{
	font-family:'Comic Book';
	src:local('Comic Book'),url('Comic Book.ttf') format('TrueType');
}
p{font-family:'Comic Book',arial,helvetica,sans-serif}

Valores:

• O valor “local” informa se a fonte já existe no sistema operacional do usuário antes de ser instalada
• O valor “url” informa o caminho da fonte que será instalada
• O valor “format” informa qual é o formato da fonte que será instalada

Formatos:

Os formatos aceitos pelos browsers são:

• Embedded OpenType – .eot
• OpenType – .otf
• Scalable Vector Graphics – .svg e .svgz (formato .svg “gzipado”)
• TrueType – .ttf

O Internet Explorer suporta apenas o formato Embedded OpenType (.eot), portanto deverão ser declarados dois formatos, sendo um exclusivo para as versões do Internet Explorer (.eot) e/ou outro(s) para os demais browsers (.otf, .svg, .svgz e .ttf). Exemplo:

@font-face{
	font-family:'Comic Book';
	src:url('Comic Book.eot'); /* IE */
	src:local('Comic Book'),url('Comic Book.ttf') format('TrueType'); /* DEMAIS BROWSERS */
}
p{font-family:'Comic Book',arial,helvetica,sans-serif}

Exemplo declarando outros formatos:

@font-face{
	font-family:'Comic Book';
	src:url('Comic Book.eot'); /* IE */
	src:local('Comic Book'),
	    url('Comic Book.otf') format('OpenType');
	    url('Comic Book.svg') format('Scalable Vector Graphics');
	    url('Comic Book.svgz') format('Scalable Vector Graphics');
	    url('Comic Book.ttf') format('TrueType')
}
p{font-family:'Comic Book',arial,helvetica,sans-serif}

Compatibilidade:

A propriedade @font-face é compatível com os principais sistemas operacionais e browsers (inclusive o Internet Explorer 6):

• Linux – Chrome e Firefox
• Mac OS – Chrome, Firefox, Opera e Safari
• Windows – Internet Explorer 6, 7, 8 e 9, Chrome, Firefox, Opera e Safari

Talvez ajude…

• @font-face Generator – Gerar fontes para outros formatos
• Free Font Converter – Converter fontes para outros formatos