Monthly Archives: May 2006

Problogging

Publicidade – quando colocar

Published by:

Você cria um novo site, e questiona-se se deve ou não colocar publicidade nesse site. Questiona-se talvez se a deve colocar desde o inicio ou se o deve fazer mais tarde.

O Darian, no site Problogger.net, colocou online a noite passada um Post a que chamou How quickly after starting a blog should I put ads on it? (Quão depressa depois de começar um blog é que devo colocar-lhe anúncios?), em que refere duas situações distintas, e que vou aqui reproduzir e acrescentar uma terceira possibilidade.

As possibilidade avançadas pelo Darian são.

  • Colocar publicidade desde o dia 1
  • Conseguir leitores e depois adicionar leitores

A terceira possibilidade que eu me arrisco avançar é:

  • Nunca adicionar anúncios

Vejamos cada uma dessas situações, sendo que nas hipóteses avançadas pelo Darian concordo basicamente com ele, pelo que resumo aqui o post dele, e adiciono algumas notas pessoais:

Colocar publicidade desde o dia 1

Eu pessoalmente enquadro-me neste grupo, e foi este o principio que segui neste site. As razões para se colocarem anuncios desde o primeiro dia numa blog ou num site são várias:

  • Expectativas dos leitores – Criar um blog sem publicidade pode criar a expectativas nos leitores de que irá manter-se sempre assim, e desiludir alguns desses leitores quando esse situação for alterada. Alguns leitores podem não gostar.
  • Design – Colocar anúncios desde o inicio permite que estes já estejam contemplados no design original, e não sejam depois colocados de forma menos estética.
  • Receita – Colocar anúncios desde o principio permite ver retorno desde o principio. Pode não ser muito, mas permite verificar a sua evolução. Dois centimos na primeira semana, cinco na segunda e 10 na terceira são uma evolução e ainda que não paguem o tempo permitem percebe que se está a evoluir no sentido pretendido.
  • Aprender a optimizar anúncios – Colocar anúncios desde o ínicio permite fazer teste com eles enquanto o site tem poucos utilizadores, o que significa que poucas pessoas irão ver os erros que se cometem. Quando se colocam os anúncios quando o site já tem tráfego considerável mais pessoas percebem que se está a experimentar.

Conseguir leitores e depois adicionar publicidade

A teoria por detrás desta abordagem é que colocando anúncios desde o primeiro dia se podem afastar leitores do site, pois parecerá muito comercial, muito interessado em ganhar dinheiro.

A ideia é que se podem depois adicionar os anúncios mais tarde, à medida que vamos ganhando leitores.

Nunca adicionar anúncios

Se por um lado, com a maioria dos blogs profissionais a publicidade, independentemente da sua forma, é uma das poucas formas de rentabilizar um site, por outro lado há muitos sites em que, penso, a publicidade deve ser evitada.

Alguns exemplos deste tipo de sites:

  • Blogs pessoais – Num blog pessoal, em que não existe um foco numa àrea mais comercial ou técnica, onde, por exemplo, se comenta o dia a dia, se colecionam os poemas, as musicas ou os comentários aos filmes do fim de semana, de forma simples e despretenciosa dificilmente se conseguirá um retorno significativo, especialmente se não existir uma quantidade de tráfego razoável.
  • Sites empresariais – Em sites empresariais, onde anúnciamos os nossos produtos ou serviços, a última coisa que pretendemos é que os nossos potênciais clientes cliquem num anúncio e se vão embora. Principalmente porque o mais provável de acontecer é clicarem num anúncio de um concorrente, o que diminui consideravelmente a probabilidade de conseguirmos a nossa venda.
  • Sites com acesso pago – Poucos utilizadores gostam de pagar e ainda continuar a ver publicidade, especialmente se falamos de popups, intersticials, e outras formas de publicidade intrusivas, que alterar a experiência de navegação do utilizador. Este tipo de publicidade é sempre incomuda, mas se o utilizador já está a pagar para ter acesso ao site pior.

Leiam também o post do Darian, chamado How quickly after starting a blog should I put ads on it?.


Programação

PpW – A diferença nos URLs

Published by:

Quando se programa para WEB a solução mais fácil é utilizar os parâmetros para tudo o que seja informação dinâmica, como os identificadores das categorias, dos artigos, ou de qualquer outra coisa que se pretenda apresentar, criando URLs do tipo lista.php?id=123ou lista/index.html?id=123.

Nada de grava haveria a dizer desta prática não fosse realidade:

  • O Google não indexa links com o parâmetro id com valores com mais do que uma determinada dimensão (4 ou 5 digitos)
  • Os motores de pesquisa em geral não indexam, ou indexam de forma menos satisfatória URLs com mais do que 2 parâmetros.

Mas como podemos deixar de utilizar este tipo de URLs? Há várias formas e várias ferramentas que permitem resolver este problema.

A mais abrangente delas é talvez o mod_rewrite do Apache, servidor instalado na grande maioria dos hostings, e que permite tranformar URLs. Por exemplo, se pretendermos que o nosso URL lista.php?id=123 passe a ser lista/123.html, isso pode ser conseguido com o mod_rewrite, adicionando às configurações do apache, ou em alguns casos a um ficheiro .htaccess na raiz do seu site a seguinte linha:


RewriteRule ^/lista/(.*).html /lista.php?id=$1 [PT]

Esta simples regra faz com que sempre que um URL do tipo /lista/123.html for pedido ao nosso servidor, o mod_rewrite irá alterar o URL para /lista.php?id=123 que o apache depois tenta servir, processando assim o nosso script PHP original.

O mesmo pode ser feito para qualquer outro URL, e tendo em conta que o primeiro parâmetro é uma regular expression, quase qualquer transformação pode ser feita nos URLs. É preciso apenas um pouco de jeito, alguma persistência, e imaginação.

E a diferença que isso pode fazer na quantidade de páginas de um site nos indices principais do Google e dos outros motores de pesquisa faz TODA a diferença.

O maior trabalho num site já feito acaba por ser mesmo alterar todos os links, e todos os locais onde os links são criados para utilizar os novos URLs.

Claro que esta solução não passa de um remendo. Muitas linguagens e frameworks de programação para WEB já permitem por si só utilizar URLs dinâmicos, e permitem implementar directamente este tipo de URLs.


Programação

PPW – Parâmetros e Dados

Published by:

Introdução

POSTs e GETs, o que são

Na Web, quando uma página tem um formulário, os valores introduzidos nesses formulários podem ser enviados para o servidor de duas formas distintas.

A primeira é acrescentando no nomes dos campos e os respectivos valores ao URL. Este método chama-se GET, e tem várias vantagens e desvantagens.

Por um lado os GETs podem ser facilmente guardados em caches, sendo assim servidos mais rapidamente nas vezes seguintes que forem pedidos. Esta vantagem é também uma desvantagem, uma vez que isso significa que da próxima vez que o mesmo pedido for efectuado, este pode nunca chegar ao servidor, pois pode ser servidor por uma qualquer proxy que se encontre pelo caminho, a começar pelo proxy transparente que a maioria dos ISPs (telepac, netcabo, etc) têm.

Por outro lado, este método pode facilmente ser reconstruido e utilizado em links (o que acontece muitas vezes). É comum hoje vermos site com links do tipo index.php?id=12345. Estes links, na prática, estão apenas a tirar partido do sistema de GET pensado inicialmente para os formulários.

Os GETs, no entanto, não permitem tudo o que se pretende fazer actualmente com um formulário. O tamanho máximo dos URLs está limitado (o limite depende da implementação), e alguns tipos de dados, como os uploads de ficheiro, apenas podem ser feitos por POST.

Ao contrário dos GETs, nos POSTs os dados preenchidos nos formulários são enviados no corpo de pedido HTTP, pelo que não existem limites para a quantidade de dados enviados.

Ao contrário dos GETs, os POSTs nunca sao guardados em caches ou proxies, pois os proxies (normalmente) lêm apenas os headers dos pedidos HTTP, e por essa razão não conseguem destinguir dois pedidos feitos por POST. As definições do protocolo HTTP também definem que os POSTs não devem ser guardados em cache.

Utilizações dos dados

Os dados que os utilizadores colocam nos formulários, ou que são passados nos URLs são utilizados de diversas formas, sendo as mais comuns a alteração ou selecção de dados em bases de dados (que podem ser ficheiros em disco), o envio de emails, entre outras (o limite é a imaginação).

O exemplo mais simples talvez seja mesmo o parâmetro no URL, o index.php?id=1234 de que falamos acima. Normalmente este parâmetro será utilizado para selecionar numa base de dados um artigo, e mostrá-lo ao utilizador.

Assumindo que o index.php não faz mais nada, é suficiente o código seguinte para completar a tarefa pretendida (sem design, apenas o titulo e corpo do artigo, de uma tabela com 4 campos:

  • id – o id do artigo
  • title – o seu titulo
  • body – o corpo do artigo
  • publico – 1 se o artigo é publico, 0 se não o for.


<?php
$id=$_REQUEST['id'];
$db=mysql_connect('localhost','username','password');
mysql_select_db('sitedb',$db);
$query="SELECT title,body from stories WHERE id=$id AND publico=1";
if ($sel=mysql_query($query)) {
if ($res=mysql_fetch_assoc($sel)) {
echo "<h1>{$res['title']}</h1>{$res['body']}";
}
}
?>

Apenas algumas linhas de código, e um erro relativamente comum, especialmente em locais onde o ficheiro assim criado é utilizado “apenas” em listagens criadas automaticamente.

Sim, neste caso abrimos a porta a que qualquer artigo seja visivel, mesmo que o campo publico seja 0. Como?

Passando, por exemplo, no campo id o valor id=123 OR 1=0, o que irá fazer com que a nossa query passe então a ser:


SELECT title,body from stories WHERE id=123 OR 1=0 AND publico=1

Como o AND é verificado antes do OR, qualquer artigo com o id=123 passa a ser uma resposta válida para a query, uma vez que o conjunto 1=0 AND publico=1 é sempre falso, e consequentemente descartável, desde que id=123 seja verdadeiro.

Em php podemos evitar esta situação utilizando a função mysql_real_escape_string e colocando sempre os valores entre plicas (‘), como se segue:


<?php
$id=mysql_real_escape_string($_REQUEST['id']);
$db=mysql_connect('localhost','username','password');
mysql_select_db('sitedb',$db);
$query="SELECT title,body from stories WHERE id='$id' AND publico=1";
if ($sel=mysql_query($query)) {
if ($res=mysql_fetch_assoc($sel)) {
echo "<h1>{$res['title']}</h1>{$res['body']}";
}
}
?>

Duas pequenas alterações, mas que fazem toda a diferença. Deve colocar os valores entre plicas mesmo que os valores esperados sejam numéricos, ou então deve verificar se os valores têm realmente o formato esperado.

Conclusão

Isto é importante não apenas nos valores recebidos no URL, mas em todos os valores que sejam recebidos do utilizador, seja em URLs, seja em POSTs de formulários.

São pequenas alterações no seu código, mas que podem tornar a sua aplicação muito mais segura.

As linguagens e motores de base de dados que conheço têm um equivalente ao aqui apresentado. Se não existir implementado na que utiliza vale a pena perder uma ou duas horas, descobrir quais os caracteres que é preciso escapar no sistema que utiliza e implementar uma função que o faça, e que poderá reutilizar sempre que pretender.

Programar para web e manter os dados seguros não são necessariamente incompativeis. Basta seguir algumas regras simples. A maioria dos truques são muito simples, e mais simples ainda de impedir.

Em Destaque Programação

Programar para Web

Published by:

Quando se programa para Internet há todo um conjunto de considerações que é preciso ter, e que em ambientes fechados pouco ou nada se pensa nelas.

Quando falo em programar para web, falo de desenvolvimento de sites que estarão disponíveis para o grande publico, sites abertos. Há, claro, considerações especiais a ter quando se programam aplicações fechadas sobre ambiente WEB, mas isso são águas para outras moagens.

Há considerações de diversas ordens a fazer:

  1. Segurança – As considerações de segurança são as que vão no sentido de impedir que alterem o site de forma não pretendida, de impossibilitar que o site seja utilizado para propósitos que não aqueles para que foi concebido, e de não permitir a apropriação de informação que não se pretende que seja acessivel.
  2. Usabilidade – A usabilidade tem a ver com a facilidade de utilização do site, com a capacidade dos visitantes facilmente encontrarem a informação que pretendem, e de o fazerem da forma mais confortável possivel.
  3. Indexação – A indexação é uma das coisas que apenas quando se programa para Web se passa a considerar. E mesmo assim muitas vezes não se tem verdadeiramente noção da sua importância. Algumas pequenas alterações podem fazer toda a diferênça no tráfego de um site.

Segurança

Quando se fala de segurança fala-se de tudo o que tenha a ver com validar toda a informação que se recebe dos utilizadores de um site.

Muitas vezes essas verificações são feitas apenas nos formulários, e muitas vezes apenas do lado do utilizador, utilizando JavaScript.

Mas isto não é o suficiente. Ultrapassar validações efectuadas do lado do cliente é facil. Muito fácil.

Assim como também é simples alterar os parâmetros passados no URL, utilizados muitas vezes em links sem grande pudor ou cuidado.

Usabilidade

O local onde as coisas são colocadas num site pode fazer toda a diferença na performance desse site. Colocar um ménu à direita ou esquerda faz diferença. Toda a diferença.

Mas a usabilidade é mais do que isso. Como é que o site será visto por invísuais, que têm que recorrer à ajuda preciosa de programas que se baseiam na estrutura do código de um site para o apresentar?

Estão as coisas que pretende destacar nos locais que os utilizadores as procuram?

Indexação

Você todos os dias coloca novos conteúdos no seu site, tem já algumas centenas de artigos publicados, o seu site tem meses de existência, mas o tráfego que o seu site recebe dos motores de pesquisa é baixo, quase insignificante.

Será que o seu site está a ser correctamente indexado?

Estes temas serão tratados aqui ao longo dos próximos dias. Permaneça comigo, e fique a saber um pouco mais sobre como melhorar o seu site.

Artigos nesta série

Segurança

Usabilidade

Indexação

Performance

na Web

A sua assinatura no produto final

Published by:

Hoje adicionei mais meia duzia de feeds ao meu akregator, entre eles o de Lee Iwan, que anotava no seu blog um dia destes acerca de uma citação de Ray Evernham, chefe de equipa no NASCAR, num post a que chamou “Is your signature on the finished product?”

A citação é Toda a gente deve sentir-se como se a sua assinatura estivesse no producto final.

Pensando um pouco sobre o tema, e penso que nem precisamos de o fazer durante muito tempo, rapidamente concluimos que esse é muitas vezes um dos problemas generalidados na nossa sociedade.

A maioria de nós trabalho por dinheiro, e não tem muita preocupação com a qualidade do trabalho que executa, pois não sente que a sua assinatura irá ficar no trabalho final.

Mas que assinatura pode colocar cada um de nós no trabalho final? Sim, muitas vezes não se tem liberdade de se colocar a própria assinatura nos nossos trabalhos. As empresas muitas vezes, mesmo em áreas mais “intelectuais”, querem trabalho em série, querem mais do mesmo, muitas vezes sem se permitir que as pessoas que fazem o trabalho se identifiquem com ele, sem permitir que lhe coloquem a própria assinatura.

Mas isso faz com que as pessoas deixem de se idêntificar com os projectos, e globalmente com a empresa, e passem a trabalhar pelo dinheiro, quando muitas vezes estão em áreas de actividade em que até trabalhariam pelo prazer.

Não que dispensassem o ordenado pelo sentimento de posse, afinal precisam dele para pagar as contas, mas fariam certamente mais e melhor se lhes fosse dada a oportunidade de, cada um à sua meneira, marcar a diferença nos projectos em que trabalham.

E a diferença de produtividade de um trabalhador orgulhoso do trabalho feito não tem preço.

SEO

SEO: ALT e TITLE de Imagens

Published by:

Quando olhamos para a maioria dos sites hoje, verificamos facilmente que muitos deles sofrem de problemas graves. Muitos apenas têm uma imagem ou um flash, outros têm muito pouca informação, mas depois existem sites que á primeira vista teriam tudo para ser “best sellers”, mas depois não aparecem nos resultados de pesquisa para aquelas que seriam as palavras-chaves do site.

Na maioria das vezes isso não é sequer dificil de explicar ou de resolver quando se percebe. Por questões de design não é incomum coisas importantes, que normalmente seriam Headings (H1, H2, H3, etc), não passarem de imagens. Não que isto por si só sejam o fim do mundo, mas o facto de essas imagens não terem qualquer texto associado faz com que os motores de pesquisa não consigam perceber (correctamente pelo menos) quais são as palavras chave de uma página.

O problema é ainda mais grave quando essas imagens são a única referência real a essas palavras-chave. Por exemplo, suponhamos que o titulo deste post era apenas uma imagem, na qual se podia ler o texto ALTs e TITLEs, e que esse texto não aparecia em mais nenhum lugar do texto.

Seria possivel os motores de pesquisa associarem o post a essas palavras? A resposta é “Com a tecnologia actual, não!”.

Alt

Mas isso pode ser contornado. A Tag (X)HTML tem um campo, que em HTML é opcional, mas em XHTML é obrigatório, que é o ALT. O campo ALT das imagens serve para fornecer um texto alternativo, utilizado pelos browsers que têm as imagens desactivadas ou que não mostram de todo imagens… e pelos Robots dos motores de pesquisa, claro.

Estes texto devem ser ilucidativos acerca do conteúdo da imagem, mas curtos, pois serão utilizados em substituição da imagem.

Description

Se pretendermos, de alguma forma, descrever a imagem (site feito utilizando tecnologias XHTML e CSS 2.0, limitado a 800 pixeis de largura, com uma laterar laranja com texto verde e o fundo do corpo principal a cinza claro, com texto quase preto), poderemos utilizar o campo DESCRIPTION.

O description deve ainda ser utilizado por uma questão de usabilidade. A maioria de nós vê. Alguns de nós bem. Mas existem muitas pessoas que não têm essa capacidade, mas que conseguem navegar na internet, utilizando programas especialmente desenvolvidos para esse fim. E se em relação a todo o texto de uma página o programa com mais ou menos precisão consegue ler o texto, quando chega às imagens, não tem forma de explicar à pessoa que está junto ao computador o que representa a imagem. Apenas sabe que é uma imagem. Mas se a imagem tiver uma descrição, utilizando o campo description, a maioria dos programas utilizará essa descrição para descrever a imagem ao seu utilizador.

Title

O HTML permite ainda definir o texto que aparece (normalmente) quando passamos com o rato por cima da imagem, utilizando o parametro TITLE. Este valor pode ser tão grande quanto pretendermos, e é também associado pelos motores de pesquisa à imagem e à página em que a imagem se encontra.

o código de uma imagem, com ALT, TITLE e DESCRIPTION ficaria com esta aparência:

<img src='/caminho/para/imagem.gif'
   title='A minha melhor imagem'
  description='Uma descrição tão longa quando o pretenda para a imagem'>

Ah… não vale a pena abusar destes campos, os motores de pesquisa já começam a perceber quando estamos a tentar aproveitar-nos deles, e os seus algoritmos serão cada vez mais apurados. A melhor forma de vender os nossos conteúdos aos motores de pesquisa é sermos informativos, mas consistentes.

Lembro ainda que apesar de estes campos, muitas vezes não utilizados, darem aos motores de pesquisa informação acerca do que está na imagem, e ajudá-los a melhor indexar a página onde as nossas imagens estão, não lhes diz qual a relevância das imagens na página, pelo que este texto será, por norma, tratado com pouco mais relevância do que se de texto simples se tratasse.

Para que as nossas imagens sejam tratadas com mais relevância do que o restante texto da página é necessário que mais relevância lhe seja dada.

Se a imagem substitui o Titulo de uma artigo ou de uma listagem, porque razão é que não está dentro de um H1? Se é um sub-titulo, porque não um H2?

Porque depois quebra o design, ouço muito webmasters dizer… Não amiguinhos, o Design vem antes e depois. Quando se estrutura HTML, é apenas isso que se faz, cria-se a estrutura dos conteúdos. Ainda que se tenha que ter em consideração o Design, esse só é realmente importante depois de o conteúdo estar bem estruturado. Poucas (muito poucas) coisas não se conseguem fazer se o conteúdo estiver bem estruturado.

Não esquecer

Utilizar ALT em todas as imagens.

DESCRIPTION em todas as imagem que possam ser descritas.

TITLE em todas as imagens que possam ter mais a dizer.


na Web SEO

TrustRank to Yahoo!

Published by:

William Slawski do blog Seo by the Sea escrevia ontem (15 de Maio de 2006) sobre o Trust Rank do Yahoo!, num post denominado Trust and the Internet: Web Search Spam.

O TrustRank serve para quantificar a probabilidade de um site ser ou não spammer, e conseguir assim que os sites de spammers não sejam indexados.

O post do Slawski baseia-se em alguns dos papers que serão apresentados na 15th Annual World Wide Web Conference, numa workshop sobre “Modelos de Confiança para a Web”, especialmente no paper Propagating Trust and Distrust to Demote Web Spamda autoria de Baoning Wu, Vinay Goel e Brian Davison, da Universidade de Lehigh.

O Trust Rank baseia-se numa lista de sites, que são sementes de “confiança”, porque o Yahoo! considera que não contém links para sites de spammers. Assim, o nível de confiança desses sites é depois dividido pelos sites para os quais o site contém links.

Os problemas apontados ao sistema de Trust é o facto de não haver uma propagação inversa de desconfiança (se o site apontar um site de spammers, então é-lhe atribuida uma parte de nível de desconfiança do site apontado, reduzindo assim o nível de confiança do site que contém o link), e o facto de um site com mais actividade atribuir um nível menor de confiança aos sites indicados que um site com um nível menor de confiança.

Vale a pena ler o post do Slawski, bem como todo o blog, que tem outros posts relacionados, e muita outra informação relacionada com optimização web (SEO).

Empresas

Um flash para a sua empresa

Published by:

Nos últimos tempos tenho percorrido as páginas amarelas de negócios e olhado para os sites de algumas das nossas empresas, e em muitos casos tenho-lhes enviado emails a propor-lhes a criação de um novo site. Não o fiz para nenhuma empresa que eu achasse que tinha um site adequado.
Continue reading

Conteúdos Design

Conteúdos e Design

Published by:

Uma das questão mais frequentes que se coloca quando se desenvolve um site é a relevância que se deve dar ao design e ao conteúdo de um site. Se por um lado acho que a questão pode ser relevânte, por outro acho que as discussões habituais são mais irrelevantes e inconsequentes do que o problema inicial que as origina.
Mas a verdade é que este problema é na realidade a conjugação de dois problemas distinctos.

O primeiro problema é uma questão de gosto e de marca, de marketing. O segundo tem a ver com implementação.

O problema de Marketing

Este tem a ver com a própria aparência de um site, e cada um de nós tem gostos especificos no que a isto respeita. Eu, pessoalmente, gosto de sites com uma aparência limpa, que mostram em primeiro lugar o mais relevante, e que me permitem encontrar facilmento o que procuro, mas que não me tentar sobrecarregar com informação excessiva.

Da mesma forma que gosto de marcas focadas, que não englobam demasiados serviços ou productos que não estejam relacionados. Gosto de olhar uma marca e pensar “Estes são os gajos que fazem Telemóveis” (Nokia) ou “Estes são os gajos da pesquisa” (Google). Sim, eu sei que estas marcas englobam outros produtos, mas a verdade é que associo de forma mais ou menos automática estas marcas a estes produtos/serviços.

E gosto menos de marcas que não consigo identificar com um produto em particular, ou com um tipo de produtos, talvez porque são marcas que têm uma imagem mais dissolvida, como seja, por exemplo, a Mitsubishi, alguém me diz qual é o negócio deles? São os Medicamentos (pela Mitsubishi Pharma), os Carros (pela Mitsubishi Motors), os Electródomésticos (pela Mitsubishi Electrónics) ou a Consultoria (pela Mitsubishi Research Institute)? Como sabemos de qual delas estamos a falar quando a imagem que vemos é o triplo losanglo?

É neste sentido que gosto de sites mais focados, directos ao assunto, que falem de tudo o que se relacione com um assunto, mas que esse assunto esteja visivel em tudo o que se pode encontrar nesse site.

Da mesma forma que gosto de sites que sejam leves, com poucas imagens, sem animações desnecessárias, e que permitem ao utilizador com 5 segundos de observação saber que tipo de conteúdos pode encontrar no site, e como pode chegar até eles, e que lhe permita chegar a esses conteúdos com o minimo de dificuldade, sem passos desnecessários.

Mas isso é uma questão de gosto e de marketing, é uma questão pessoal e de marca. Pessoal no sentido em que o que eu considero um site bem conseguido pode ser simplista para outra pessoa, ou um site que outros consideram muito bom ter na minha opinião “demasiada bonecada”. O oposto pode acontecer, mas será raro. É uma questão de marca, pois tem mais a ver com o posicionamento e o mercado de uma marca, ou de um site.

O problema de implementação

Visto o problema de marketing, temos ainda o problema de implementação. O mesmo tipo de imagem pode ser implementada de várias formas, sendo as duas mais comuns e mais contrastantes a utilização de tabelas e de DIVs, isto é, utilizando posicionamentos controlados com tabelas ou utilizando blocos flutuantes, que depois são posicionados e alinhados utilizando CSSs.

Claro que estamos ainda a um nível razoávelmente superficial, que iremos em seguinda aprofundar. Mas mesmo a este nível as diferenças são grandes, principalmente no que respeita à quantidade de código HTML necessário para criar um mesmo design, e à flexibilidade que esse design tem.

Utilizando DIV, é facil, por exemplo, esconder um DIV quando se pretende imprimir uma página, criando apenas um código HTML para a página, e formatá-la de forma diferente consoante está a ser visto num monitor ou a ser impressa.

Mas, perguntam, podemos fazer com DIV e similares tudo o que fazemos com tabelas? Bem, talvez nem tudo, mas existem muito poucas situações em que sejam realmente necessárias as tabelas ou em que elas tragem realmente uma mais valia. Apesar disso existem algumas. Mas poucas ou nenhumas delas têm a ver com design, a maioria têm realmente a ver com a criação de tabelas de dados.

Mas que vantagem existem em utilizar DIVs em detrimento das tabelas, perguntam-me.

Bem, em primeiro lugar reduz bastante o tamanho do vosso código HTML, e se por um lado a dimensão de uma página já não é tão relevante quanto foi noutros tempos, ainda existe um número razoável de pessoas a utilizar modem de 56 Kbps (Kilobits por segundo), e que precisam de vários segundos para carregar uma página de 50 KB (Kilobytes – 1 byte equivale a 8 bits), e ainda sem contar com os diversos ficheiros associados a essa página.

Por outro lado a relevância agora é da quantidade de código necessário à formatação do conteúdo. A relação entre a quantidade de conteúdo encontrado numa página e a dimensão total dessa página é hoje um dos factores que os motores de pesquisa consideram quando indexam uma página nos seus indices, pelo que reduzir a quantidade de código HTML presente numa página é uma boa forma de começar a aumentar a relevância dessa página nos motores de pesquisa.

É ainda um problema de implementação a forma como os conteúdos se integram na estrutura e no design… mas isso é talvez assunto para aprofundar noutro post, um destes dias.