Todos os dias há perguntas postadas nos fóruns de WordPress sobre alguns dos problemas mais comuns que novos usuários enfrentam. É fácil de instalar e divertido de trabalhar com WordPress e os novos usuários se animam, rapidmente, com os poderosos recursos oferecidos por muitos de seus plugins e temas.

Eventualmente, os neófitos se deparam com perguntas, questões e problemas que muitos antes deles também já se depararam. WordPress tem uma enorme comunidade global de usuários por trás, então, não importa o problema que um usuário esteja enfrentando, há uma boa chance de que alguns outros usuários já o tenham enfrentado e que já exista uma solução disponível para corrigir esse problema ou responder a essa pergunta.

Neste artigo, vamos discutir alguns desses problemas comuns de WordPress e aprender, através de suas soluções, como resolvê-los.

Consumo de memória do WordPress

Quando um site rodando em WordPress cresce em popularidade e pageviews, o consumo de memória é um dos primeiros (se não, o primeiro) problema que os mantenedores do site enfrentam. Se eles estão em uma hospedagem compartilhada ou um VPS, seus webhosts enviarão e-mails sobre o uso de memória e limite alocado. Pelo menos, os bons hosts farão isso; se for um de baixa qualidade, seu site pode apenas cair e você sequer vai ficar sabendo disso a tempo…

Felizmente, existem diversas soluções para esse problema.

O motivo pode ser um plugin ou tema mal feito rodando. Para descobrir, instale o plugin WP-Memory-Usage. Desative todos seus plugins, exceto o WP-Memory-Usage e, em seguida, vá ativando um por um. Observar como vai ficar o uso de memória depois de ativar cada plugin pode ajudar a descobrir qual(is) é(são) o(s) vilão(ões) da história.

Depois dessa verificação inicial, se os temas e plugins estiverem funcionando dentro do esperado, então pode ser uma ótima ideia instalar um plugin de cache, como W3 Total Cache ou WP Super Cache. Se um plugin de cache não reduzir significativamente a memória com as configurações padrão, será preciso uma configuração mais específica, alterando parâmetros tais como compressão, minify de scripts, aumentar o intervalo dos caches, etc.

Leia estes excelentes artigos (em inglês) sobre como otimizar instalações de WordPress:

• WordPress Optimization
• WordPress Optimization Bible
• WordPress Shared Hosting Performance

Sites em WordPress hackados

Outro problema comum de WordPress é descobrir que seu site foi invadido! As chances de tal coisa acontecer em seu site podem ser significativamente reduzidas seguindo algumas dicas práticas de segurança para WordPress.

Existem diferentes tipos de hacks que os usuários do WordPress enfrentam. O mais comum deles é quando um site redireciona para algum outro site com conteúdos ilegais e/ou obscenos, links injetados para outros sites, códigos estranhos em arquivos de temas, etc. Lembre-se de que, na maioria das vezes, é fácil corrigir esses problemas.

• Mantenha sempre a instalação do WordPress atualizada com a última versão
• Faça backups regulares de sua instalação e banco de dados WordPress
• Execute o WP-Security-Scan, um excelente plugin para detectar códigos suspeitos em seus temas, plugins e arquivos principais do wordPress. Se você encontrar algo suspeito em plugins ou temas, apague! Se você encontrar algo suspeito no core do WordPress, substitua por novos!
• Verifique regularmente seu arquivo .htaccess por mudanças e códigos suspeitos
• Leia o artigo “My site was hacked” no Codex do WordPress, peça ajuda em fóruns, peça a ajuda do seu provedor de hospedagem para ter certeza que não aconteceu um ataque em todo o servidor.

Perda da senha de admin e/ou e-mail

É realmente surpreendente quantas pessoas instalam o WordPress e esquecem seus nomes de usuário, senha e e-mail utilizados durante a instalação. Existem várias maneiras de recuperar senha e nome de usuário e é importante conhecer algumas delas.

Recuperar senha do WordPress via PHPMyAdmin

Se você tiver acesso ao banco de dados através do phpMyAdmin, vá até lá e encontre a tabela wp_users. Clique na aba “Procurar” e, em seguida, encontre seu user_login. Clique no ícone “Editar”, à esquerda da linha. Agora você vai ver sua senha encriptada; exclua e substitua por qualquer senha que quiser. Haverá um drop-down “Funções” ao lado. Clique sobre ele e selecione “MD5″. Clique em “Executar” e pronto, você atualizou sua senha!

Recuperar senha do WordPress por FTP

Conecte em seu site via FTP, vá em wp-content/themes/SEU_TEMA. Substitua “SEU_TEMA” com o nome do tema ativo em seu site. Edite o arquivo functions.php (se você não tiver um no seu tema, crie). Adicione esta linha:

wp_set_password('NovaSenha', 1);

Substitua “NovaSenha” com qualquer senha que você quiser. O “1″ é o para o user_ID – supondo que você é o admin do site e não excluiu o primeiro usuário que criou durante a instalação.

Faça upload do arquivo editado de volta para o servidor. Agora, faça o login usando a senha que você adicionou no functions.php. Uma vez que você tenha conseguido logado, lembre-se de apagar esta linha de seu arquivo de funções.

Escrevendo código em posts e widgets

Para fazer o WordPress mais seguro e proporcionar um ambiente confiável e consistente, por padrão a plataforma não permite que os usuários insiram códigos nos posts, comentários e widgets. No entanto, depois de algum tempo a maioria dos novos usuários se sente confortável o suficiente com o WordPress para querer adicionar funcionalidades diferentes nessas áreas.

Por exemplo, para mostrar os códigos deste artigo, não é possível simplesmente colar o código. Ele seria retirado pelo WordPress e não seria mais legível.

Adicionando código nos posts do WordPress

O Codex do WordPress sugere o uso de entidades HTML para escrever código, mas esta é uma forma muito custosa de se fazer isso. Então, se você pretende compartilhar regularmente trechos de código com os visitantes de seu website, então você precisa de algum plugin específico, tal como o Syntax Highlighter Evolved.

O plugin permite escrever código em seus posts e estilizar códigos com shortcodes. É muito fácil de usar, personalizável e suporta várias linguagens incluindo PHP, JavaScript, HTML e CSS.

Adicionando código nos widgets da barra lateral

Também pode haver a necessidade de exibir trechos de códigos em Widgets ou adicionar uma função ou tag em um widget. Para isso, é possível instalar algum plugin, como PHP Code Widget ou Widget Logic.

Conclusão

Certamente, deve haver outras perguntas comuns, questões e problemas que os novos usuários de WordPress muitas vezes se deparam. A primeira coisa a se fazer quando se deparar com qualquer problema com seu site WordPress é pesquisar.

Faça buscas usando diversos termos e você vai ver que muitas pessoas já forneceram soluções para esses problemas de WordPress. Se não, você pode sempre fazer perguntas no Fórum WordPress, IRC e outros fóruns WordPress relacionados.

E você, conhece algum problema comum de WordPress e a solução adequada?

Artigos Relacionados

• Preciosas dicas de segurança e otimização para WordPress
• WP-Syntax: destacar códigos fonte em artigos de blogs WordPress
• 5 dicas para temas WordPress melhores
• 15 fantásticos comandos SQL para WordPress
• Otimização WordPress: aumente a performance e desempenho de seu blog / site
• Truques de configuração do WordPress
• Como criar sumários dinamicamente com o TOC (Table of Contents) jQuery plugin
• Newsletter no WordPress com o plugin Ajax Newsletter (wp-ajax-newsletter)
• Como usar qualquer tipo (fonte tipográfica) em seu blog WordPress
• Maneira simples de saber quem faz referências a seu blog WordPress

A HTML5, apesar de ainda demorar para ser uma recomendação oficial do W3C, já está sendo muito usada no desenvolvimento web no mundo inteiro – incluindo este humilde blog. Mas, devido ao “boom do HTML5″ causado pela ânsia dos desenvolvedores começarem a usar a linguagem imediatamente, alguns menos atentos estão sujeitos a cometer alguns erros que a nova especificação do HTML pode dar ensejo.

Para o caso, é preciso prestar atenção em alguns detalhes importantes para evitar erros comuns de HTML5.

Não use section como contêiner para estilização

Um dos problemas mais comuns que está acontecendo em relação à implementação da HTML5 é os desenvolvedores, arbitrariamente, estarem substituindo <div> por <section> para usar na estilização. No HTML4 ou XHTML, é normal um código como:

<div id="wrapper">
    <div id="header">
        <h1>T&iacute;tulo prim&aacute;rio</h1>
    </div>
 
    <div id="main">
        <!-- conteúdo -->
    </div>
 
    <div id="secondary">
        <!-- conteúdo -->
    </div>
 
    <div id="footer">
        <!-- conteúdo -->
    </div>
</div>

Então, sem nenhum motivo plausível, alguns estão alterando seu código para:

<section id="wrapper">
    <header>
        <h1>T&iacute;tulo prim&aacute;rio</h1>
    </header>
 
    <section id="main">
        <!-- conteúdo -->
    </section>
 
    <section id="secondary">
        <!-- conteúdo -->
    </section>
 
    <footer>
        <!-- conteúdo -->
    </footer>
</section>

E isso, apesar de poder estar certo, na grande maioria dos casos, está errado… Se é preciso um elemento somente para estilização, não faz nenhum sentido deixar de usar <div>; o elemento <section> não foi criado para isso! Segundo sua documentação,

O elemento <section> representa um documento genérico ou seção de aplicação[...]. O elemento <section> não é um elemento contêiner genérico. Quando um elemento é necessário para fins de estilo ou como uma conveniência para execução de scripts, os autores são incentivados a utilizar o elemento <div>.

Ou seja, as indicações de uso do <section> para 99% dos casos são:

• Não usá-lo apenas como “gancho” para estilos ou scripts (para isso, já existe <div>)
• Não usá-lo se o <article>, <aside> ou <nav> forem mais apropriados
• Não usá-lo a menos que exista, naturalmente, um título no início da seção

Só use header e hgroup quando forem necessários

Não faz sentindo escrever HTML de forma a ferir a semântica, certo? Infelizmente, não é difícil encontrar elementos <header> e <hgroup> sendo usados de forma inapropriada. Procure se informar mais a respeito da função deles, mas, resumindo:

• <header> representa um grupo introdutório e/ou navegacional e, usualmente, contém o(s) título(s) de <section>
• <hgroup> agrupa um conjunto de elentos <h1>-<h6> quando o título de uma seção tem vários níveis, tais como subtítulos, títulos alternativos, etc

Uso excessivo de header

O elemento <header> pode ser usado quantas vezes forem necessários num documento, o que está causando confusões do tipo:

<article>
    <header>
        <h1>T&iacute;tulo prim&aacute;rio</h1>
    </header>
 
    <!-- conteúdo -->
</article>

Se o <header> contém somente um elemento de título, na verdade, ele não precisa ser usado. O elemento <artcile> já garante que o título vai constar no outline do documento, e, porque <header> não contém múltiplos elementos (como consta em sua definição), por que escrever código desnecessário? A solução é simples:

<article>
    <h1>T&iacute;tulo prim&aacute;rio</h1>
    <!-- conteúdo -->
</article>

Uso incorreto de hgroup

Basicamente, não se deve usar <hgroup> com <header> quando:

• Há somente 1 elemento-descendente de título
• O <hgroup> funcionaria bem por conta própria (ou seja, sem <header>)

O primeiro problema pode ser visto no código:

<header>
    <hgroup>
        <h1>T&iacute;tulo prim&aacute;rio</h1>
    </hgroup>
 
    <!-- conteúdo -->
</header>

No caso, deve-se, simplesmente, remover o elemento <hgroup>:

<header>
    <h1>T&iacute;tulo prim&aacute;rio</h1>
    <!-- conteúdo -->
</header>

O segundo problema é outro caso de incluir o elemento quando ele não se faz necessário:

<header>
    <hgroup>
        <h1>T&iacute;tulo prim&aacute;rio</h1>
        <h1>T&iacute;tulo secund&aacute;rio</h1>
    </hgroup>
</header>

Se não há elementos adicionais dentro de <header> (isto é, irmãos de <hgroup>), basta remover o <header>:

<hgroup>
    <h1>T&iacute;tulo prim&aacute;rio</h1>
    <h1>T&iacute;tulo secund&aacute;rio</h1>
</hgroup>

Não englobe todas listas de links com nav

Com mais de 40 novos elementos (no dia da publicação deste artigo), não é incomum haver dúvidas e erros de HTML5 na hora da utilização de alguns destes. Infelizmente, ainda é o caso com o elemento <nav>. Como consta em sua especificação,

Nem todos os grupos de links em uma página precisam estar contidos em um elemento <nav> – o elemento se destina, principalmente, a seções que consistem em blocos de navegação principal. (Grifo nosso)

Atenção ao grifo “blocos de navegação principal” que, apesar de ser aberto a algumas interpretações, identifica-se mais com:

• Navegação primária
• Navegação secundária
• Navegação in page (dentro de um artigo longo, por exemplo)

Como diretivas gerais (e seguindo a lógica contida na especificação), não se aplica o elemento <nav> a:

• Controles de paginação
• Social links
• Categorias e Tags (de um artigo de blog, por exemplo)
• Navegação terciária
• Rodapés muito elaborados

Nos momentos de dúvida ao usar <nav>, pergunte-se a si mesmo: “Essa é uma navegação principal?”. Para ajudar a responder, considere as seguintes “regrinhas”:

• Não use <nav> a menos que você pense que <section> também seria apropriado com <hx>
• Você adicionaria um link “Pular para o conteúdo” por questões de acessibilidade?

Se a resposta para essas perguntas for “não”, então, provavelmente, não se trata de um <nav>.

Os novos elementos não foram criados para que os desenvolvedores tivesse trabalho de escrever código a mais. Pensar isso é um erro comum de HTML5. Algumas pessoas, ao “atualizarem” seus sites para HTML5, colocam o elemento <figure> em todas as imagens! Fazer isso não serve pra nada e a pessoa só está aumentando o próprio trabalho…

A especificação define <figure> como

algum conteúdo de fluxo, opcionalmente com um <figcaption>, que é auto-contido e, tipicamente, referido como uma unidade única a partir do fluxo principal do documento.

E é aí que reside a beleza do elemento <figure>: ele pode ser afastado do conteúdo principal (para uma barra lateral, por exemplo) sem afetar o fluxo do documento.

Se se tratar de uma imagem puramente de apresentação, que não é referenciada em outras partes do documento, definitivamente não se trata de um <figure>. Outros casos de uso variam, mas, pra começar, pergunte-se a si mesmo: “Esta imagem é necessária para compreender o contexto atual?”. Se não, provavelmente não é um <figure> (pode ser um <aside>, talvez). Se sim, pergunte-se novamente: “Eu poderia movê-lo para um apêndice?”. Se a resposta para ambas as perguntas for “sim”, então, provavelmente, trata-se de um <figure>.

O logo não é um figure

Os mesmos princípios mostrados acima também se aplicam ao logo do site. Não é tão incomum se ver por esses dias códigos parecidos com:

<header>
    <h1>
        <figure>
            <img src="/img/logo.png" alt="Nome do site" class="hide">
        </figure>
 
        Nome do site
    </h1>
</header>

Isso, simplesmente, não está certo… E não estou dizendo sobre o fato de o logo estar dentro de um <h1> – isso, por si só, renderia um artigo inteiro. A real questão é o abuso do elemento <figure>! No caso, a marcação poderia, simplesmente, ser feita assim:

<header>
    <h1>Nome do site</h1>
</header>

figure pode ser mais que uma imagem

Ao contrário do que muitos pensam, <figure> pode ser áudio, vídeo, um gráfico (em SVG, por exemplo), uma citação, uma tabela, um bloco de código ou qualquer combinação destes e muito mais!

Não se limite a usar <figure> somente em imagens. Nosso trabalho como aficionados por padrões web também é de descrever com precisão nosso conteúdo através de uma correta marcação.

Não inclua atributos de tipo desnecessariamente

Este é, provavelmente, um dos erros mais comuns de HTML5. Embora não seja, tecnicamente, um erro, é uma boa prática evitar a inclusão de atributos de tipo.

Em HTML5, não há necessidade de incluir o atributo type em <script> e elementos <style>. Embora possa ser um pouco custoso remover o atributo se ele está sendo colocado automaticamente pelo CMS em uso, não há, realmente, nenhuma razão para incluí-lo se você está codificando na mão ou se tiver absoluto controle sobre o código que está sendo usado.

Uma vez que todos os navegadores esperam que scripts sejam JavaScript e estilos sejam CSS, isso se faz desnecessário:

<link type="text/css" href="styles.css" rel="stylesheet">
<script type="text/javascript" src="scripts.js"></script>

Use somente:

<link href="css/styles.css" rel="stylesheet">
<script src="js/scripts.js"></script>

Uso incorreto de atributos de formulários

Provavelmente, você deve estar ciente de que o HTML5 introduziu uma série de novos atributos para formulários (bem, você deveria). Com isso, alguns erros, por parte dos desenvolvedores, também começaram a aparecer.

Atributos booleanos

Vários dos novos atributos de formulário são booleanos, ou seja, sua simples presença na marcação assegura o comportamento esperado. Esses atributos incluem:

• autofocus
• autocomplete
• required

Então, alguns desenvolvedores começaram a escrever coisas do tipo:

<input type="text" name="name" required="true">
<input type="email" name="email" required="1">

O parser do navegador ainda vai considerar o campo como obrigatório pelo simples fato de “required” estar lá, mas, e se o valor pretendido fosse outro?

<input type="email" name="email" required="false">

O parser ainda verá o atributo required e implementará o comportamento, mesmo que essa não tenha sido a intenção!

Há 3 maneiras válidas para um atributo booleano ser aplicado (a segunda e a terceira opções só se aplicam para XHTML):

• required
• required=""
• required="required"

Portanto, em HTML5 é somente:

<input type="email" name="email" required>

Conclusão

Certamente, é impossível listar todos os erros de HTML5 que os desenvolvedores cometem, mas estes são alguns dos mais vistos nos códigos – que podem ser encontrados em qualquer site de “galeria HTML5″.

Que outros erros comuns de HTML5 você está vendo por aí? Na sua opinião, quais áreas exigem mais atenção? Comente!

Artigos Relacionados

• JSON – JavaScript Object Notation
• Perguntas ao cliente para antes e depois de um projeto
• 8 características de User Interfaces (UI) de sucesso
• Gestalt aplicado ao design web (parte 5): exemplos web do princípio do alinhamento
• Gestalt aplicado ao design web (parte 3): exemplos web do princípio da proximidade
• Microdata API e Schema.org: dando significado ao HTML
• Usando Modernizr para detectar features de HTML5 e CSS3
• Não use IDs como seletores em CSS
• Como usar .ready() antes de incluir a jQuery
• 10 dicas que desenvolvedores web iniciantes devem saber

A HTML fornece diversos elementos para que possamos dar algum significado ao conteúdo. Como sabemos, cada tag serve a um propósito e, usá-las de maneira adequada, pensando na semântica web, faz parte do trabalho do desenvolvedor web.

Então, se é preciso exibir uma lista de produtos num site, por exemplo, é possível usar o elemento de listas não ordenadas, ul, para marcar esse conteúdo e dar algum significado à informação. Dizemos ao “interpretadores” do código (sejam browsers, leitores de tela, bots de sistemas de busca, etc): “Isto é uma lista com alguns itens”. Mas, somente com essa marcação, não é possível informar que esta é uma lista de produtos.

Para dar esse passo além na semântica de documentos web é que está sendo criada a Microdata API.

O problema do significado

Quando uma pessoa faz uma busca por “melhores bancos do brasil”, ela está procurando as melhores instituições financeiras do país ou os melhores móveis para se sentar? Certamente, a pessoa que está fazendo a busca, sabe, mas, será que o buscador a que a busca foi submetida interpretará isso de maneira adequada?

A pessoa que fez essa busca, ao entrar em um dos links da SERP, verá se a página que entrou é sobre instituições financeiras ou móveis. Se ela estiver procurando pelas primeiras e acessar uma página sobre os segundos, entrou em um link que não era de seu interesse devido ao fato de o buscador ter mostrado uma informação errônea no momento de exibir os resultados. Afinal, mesmo com os relativamente inteligentes algoritmos que os melhores buscadores possuem, este tipo de situação ocorre com frequência.

Usando a API de microdata (ou microdados), é possível auxiliar as máquinas (não somente buscadores) a descobrir o significado dos conteúdos nos web sites; é possível informar que uma lista no site é uma lista de produtos; é possível informar que seu site é sobre instituições financeiras, ao invés de móveis. Em suma, através da Microdata API, é possível dar mais  significado ao conteúdo.

Conhecendo a Microdata API

A Microdata API tem como objetivo dar mais significado aos documentos web que fazemos. Usando Microdata, é possível informar aos robôs significados além do que uma marcação “tradicional” poderia/conseguiria, agregando maior valor semântico ao conteúdo dos sites, o que, por consequência, traz inúmeros benefícios. E isso é feito através de marcações específicas nos códigos.

Sintaxe da microdata

Basicamente, o modelo de microdata consiste em grupos de pares nome-valor, conhecidos como itens e cada item pode ter 1 ou mais tipos de item; cada item, pode ter 1 ou mais propriedades, que podem ter 1 ou mais valores. Para criar um item, o atributo itemscope é usado e, para adicionar uma propriedade a um item, o atributo itemprop é usado.

É possível usar microdata sem a intenção de reutilização, mas, concordemos, isso não faz sentido. O interessante é termos “especificações” de microdados que podem ser usadas amplamente, por quem quer que seja. Por isso, geralmente se identifica o tipo de item através da indicação de um URI que contenha essa especificação. Usar microdata é usar vocabulários.

Por exemplo, vamos ver a “marcação padrão” de uma ração de gatos num site qualquer:

<section>
    <h1>Siamês</h1>
    <p>Gato-siamês é uma raça de gato oriental, caracterizada por um corpo elegante e longilíneo e uma cabeça marcadamente triangular.</p>
    <img src="siames.jpg" alt="Gato siamês">
</section>

Agora, este mesmo código sendo marcado com microdata:

<section itemscope itemtype="http://example.org/animals#cat">
    <h1 itemprop="name">Siamês</h1>
    <p itemprop="desc">Gato-siamês é uma raça de gato oriental, caracterizada por um corpo elegante e longilíneo e uma cabeça marcadamente triangular.</p>
    <img itemprop="img" src="siames.jpg" alt="Gato siamês filhote">
</section>

No exemplo, o item “http://example.org/animals#cat” possui 3 propriedades, um “name” (“Siamês”), uma “desc” (“Gato-siamês é uma raça…”) e “img” (“siames.jpg”) e, como vimos, é possível haver mais de um valor por propriedade (inclusive, que seja a indicação de outro “vocabulário”):

<section itemscope itemtype="http://example.org/animals#cat">
    <h1 itemprop="name http://example.com/fn">Siamês</h1>
    <p itemprop="desc">Gato-siamês é uma raça de gato oriental, caracterizada por um corpo elegante e longilíneo e uma cabeça marcadamente triangular. Suas cores, normalmente, são <span
 itemprop="http://example.com/color">branco</span> (enquanto crias), <span
 itemprop="http://example.com/color">branco sujo</span> ou <span
 itemprop="http://example.com/color">creme</span>, com extremidades <span
 itemprop="http://example.com/color">castanho</span> muito escuro (quase <span
 itemprop="http://example.com/color">preto</span>), <span
 itemprop="http://example.com/color">cor de chocolate</span>, e, raramente, <span
 itemprop="http://example.com/color">azul acinzentado</span> ou <span
 itemprop="http://example.com/color">lilás acinzentado</span>.</p>
    <img itemprop="img" src="siames.jpg" alt="Gato siamês filhote">
</section>

Sem sombra de dúvidas, esta marcação é mais trabalhosa de se fazer e, não raramente, pode haver erros de sintaxe na marcação, devido a relativa complexidade e volume. Existe uma maneira de testar se tudo está nos conformes, a ferramenta Rich Snippets Testing Tool.

Ao inserir uma URL (ou trecho de código HTML, diretamente), é possível ter um preview de rich snippet no Google e, caso o código tenha microdados, ele exibe, de forma organizada, esta estrutura. Como consta na própria página de explicação de Rich Snippets,

Se o Google compreender o conteúdo de suas páginas, podemos criar rich snippets — e informações detalhadas para ajudar os usuários com consultas específicas. Por exemplo, o snippet para uma página de receitas pode mostrar o tempo total de preparo, uma foto e a avaliação dos comentários da receita. O snippet para um restaurante pode exibir a avaliação média e a faixa de preços. Já o snippet para um álbum de músicas pode listar as músicas junto com um link para reproduzir cada uma delas. Esses rich snippets ajudam os usuários a identificar se o site é relevante para a pesquisa e podem resultar em mais cliques em sua página.

Você pode ajudar o Google a revelar essas informações relevantes adicionando uma marcação HTML extra em suas páginas. Essa marcação ajuda o Google a reconhecer certos tipos de dados e a exibi-los de maneira útil nos rich snippets.

Estão entendendo, agora, a diferença que o uso de microdata pode fazer? “O snippet para um restaurante pode exibir a avaliação média e a faixa de preços”?! Isso é muito incrível! Com toda a certeza, a exibição de um snippet dessa qualidade é a diferença entre receber, ou não, mais uma visita em seu site!

Concorda que um snippet de receita como este é muito mais atrativo e informativo que o snippet padrão da SERP do Google? Ele é muito mais útil à pessoa que está buscando, por exemplo, um “Pão de Banana”, apresenta informações que são muito mais relevantes e, no momento, caso você consiga que seu site seja um dos poucos a conseguir um rich snippet desta qualidade, ele é totalmente diferenciado dos demais!

Microdata DOM API

A Microdata API também conta com uma série de métodos JavaScript: Microdata DOM API. Por exemplo, temos o método getItems(), que provê acesso ao itens marcados com microdata. Ele retorna uma NodeList contendo os itens dos tipos especificados (ou todos os itens, se nenhum argumento for passado).

var cat          = document.getItems('http://example.org/animals#cat')[0];
var colors       = cat.properties['http://example.com/color'].getValues();
var colors_total = colors.length;
var result;
 
if (colors_total == 0)
{
    result = 'Cor desconhecida.';
}
else if (colors_total == 1)
{
    result = 'Cor: ' + colors[0];
}
else
{
    result = 'Cores:';
    for (var i = 0; i < colors_total; i += 1)
    {
        result += ' ' + colors[i];
    }
}

Na verdade, estes são somente alguns exemplos de uso e apresentação da Microdata API. Caso se queira aprofundar no assunto, o que é altamente recomendado, é preciso estudar a documentação oficial da Microdata API.

Schema.org

Como vimos, é mais interessante haver conjuntos de vocabulários comuns, acessíveis e centralizados e prontos para serem usados por qualquer pessoa. Felizmente, isso já existe! Trata-se do Schema.org. O Schema.org é um vocabulário de marcação de microdata compartilhado, que torna mais fácil para nós, pessoal do desenvolvimento web, decidir sobre um esquema de marcação.

Mas, realmente, adianta usar o vocabulário de microdata do Schema.org? Sim, adianta, e muito, já que os melhores buscadores do mundo, tais como Google, Bing, Yahoo! e Yandex, ratificaram o projeto e seus respectivos spiders e SERPs já fazem uso dessa tecnologia! Já foi mostrado que, por exemplo, o Google já faz uso deste tipo de marcação para aprimorar seus snippets e, por experiência pessoal, afirmo que, também, contribui para a melhora do posicionamento nos resultados de busca.

Exemplo de uso do Schema.org

No próprio site do Schema, eles apresentam um exemplo bastante didática para mostrar o conceito por trás dos microdados. Imagine que alguém marca como título principal (h1) “Avatar”. Mas essa página diz respeito àquela imagem que as pessoas utilizam em seus perfis de redes sociais ou ao filme Avatar, de James Cameron? Usando o schema correto, é possível auxiliar aos buscadores a entender melhor do que trata aquele documento.

<div itemscope itemtype ="http://schema.org/Movie">
    <h1 itemprop="name">Avatar</h1>
    <span>Director: <span itemprop="director">James Cameron</span> (born August 16, 1954)</span>
    <span itemprop="genre">Science fiction</span>
    <a href="../movies/avatar-theatrical-trailer.html" itemprop="trailer">Trailer</a>
</div>

E, como já vimos anteriormente, é possível, inclusive, fazer “embedded” de outros itens:

<div itemscope itemtype ="http://schema.org/Movie">
    <h1 itemprop="name">Avatar</h1>
    <div itemprop="director" itemscope itemtype="http://schema.org/Person">
        Director: <span itemprop="name">James Cameron</span> (born <span itemprop="birthDate">August 16, 1954</span>)
    </div>
    <span itemprop="genre">Science fiction</span>
    <a href="../movies/avatar-theatrical-trailer.html" itemprop="trailer">Trailer</a>
</div>

Usando o vocabulário do Schema.org

O Schema.org possui uma série de “tipos” (itens), cada um com suas respectivas propriedades. Cada um desses tipos é chamado de schema (faz sentido…). Então, para darmos mais significado e complementarmos a semântica de nossos documentos HTML, é preciso percorrer a lista dos diferentes schemas disponíveis e saber o que se pode usar no momento.

Perceba que cada tipo pode ter, também, subtipos, que herdam as características de seus ancestrais e possuem suas próprias. Por exemplo, o schema Movie possui suas propriedades distintas e, também, as propriedades de seus ancestrais CreativeWork e Thing.

Lembrando que, não necessariamente, todas as propriedades, próprias ou herdadas, precisam ser usadas ao mesmo tempo.

Em geral, quanto mais conteúdo você marcar, melhor. No entanto, como regra geral, você deve marcar apenas o conteúdo que é visível para as pessoas que visitam a página, não o conteúdo oculto.

Tipos esperados versus texto.

Ao navegar entre os vários schemas, você vai notar que muitas propriedades têm “tipos esperados”. Isto significa que o valor da propriedade, por si só, pode ser um item incorporado (embedded). Mas este não é um requisito – não há problema em incluir somente texto ou uma URL. Além disso, sempre que um tipo esperado é especificado, também não há problemas em incorporar um item descendente. Por exemplo, se o tipo esperado é Place, também é permitido incorporar um LocalBusiness.

Usando a propriedade “url”

Algumas páginas da web são sobre um item específico. Por exemplo, você pode ter uma página web sobre uma única pessoa, que você pode marcar com Person.

Já outras páginas podem ter uma coleção de itens descritos nelas. Por exemplo, o site de uma empresa pode ter uma página com a lista de funcionários com um link para uma página de perfil de cada um. Para páginas como esta, com uma coleção de itens, você deve marcar cada item separadamente (neste caso como uma série de Person) e adicionar a propriedade url no link correspondente a cada item, assim:

<ul>
    <li itemscope itemtype="http://schema.org/Person">
        <a href="jose-das-coves.html" itemprop="url">Jos&eacute; das Coves</a>
    </li>
 
    <li itemscope itemtype="http://schema.org/Person">
        <a href="joao-da-silva.html" itemprop="url">Jo&atilde;o da Silva</a>
    </li>
</ul>

Teste a marcação

Como já comentamos, é interessante passar seu código pela Rich Snippets Testing Tool para testar se tudo está como deveria. Caso algum “esquecimento” tenha ocorrido no momento de marcar os schemas, a ferramenta vai ser de muita valia ao apontar quais equívocos foram esses.

Conclusão sobre Microdata API e schemas

Como os desenvolvedores web devem (ou deveriam) saber, muita coisa neste ramo está mudando (para melhor) com o advento do HTML5. Certamente, uma dessas melhorias é a Microdata API, que permite, a partir de então, darmos mais significado ao conteúdo do site, provendo uma maneira simples e eficiente de melhorar a significação de nossos conteúdos.

Para auxiliar neste propósito, os schemas estão, aí, para centralizar, organizar e prover um vocabulário unificado e acessível de microdata para ser usada e abusado. Não deixe de conferir a documentação completa do Schema.org. E, para clarear ainda mais as explicações, veja o excelente post do pessoal do Loop Infinito sobre microdata e os vocabulários do Schema.org, com direito a gráficos em SVG e tudo o mais! :-D

Tanto por indicações “vindas de cima” – como no caso de os grandes buscadores já darem suporte e incentivar o uso de microdados -, quanto por experiências próprias comprovadas, usar microdata em projetos web, a partir de agora, é praticamente uma obrigação!

Artigos Relacionados

• JSON – JavaScript Object Notation
• Melhorando a interação em formulários de busca
• URLs amigáveis (slug) à WordPress
• 15 fantásticos comandos SQL para WordPress
• 6 mitos de SEO que você deve evitar
• Como criar sumários dinamicamente com o TOC (Table of Contents) jQuery plugin
• Como pegar parte do conteúdo (dados) de outro site com PHP
• Problemas comuns de WordPress e como resolvê-los
• Evitando erros comuns de HTML5
• Usando Modernizr para detectar features de HTML5 e CSS3

Recentemente, tive a oportunidade de conhecer o DevCast e assistir a algumas das conferências já realizadas. Hoje, gostaria de chamar a atenção para uma, em especial, que trata sobre os desenvolvedores front-end e seu papel e atuação (e limitações) no mercado de trabalho.

A conferência contou com a participação do Diego Eis, do Tableless, que, para quem já é atuante na área, meio que dispensa apresentações e, para o pessoal novo, provavelmente vocês ainda lerão e verão material web do Diego rodando por aí. Ele é um dos pioneiros brasucas de desenvolvimento web e, além da parte técnica, tem também um embasamento teórico bastante interessante, como ele, próprio, comenta na apresentação.

Sem mais delongas, assistam à conferência “Desenvolvedores de Front-end e Mercado“. Vale a pena. Mesmo!

Opiniões divergentes

O Diego, devido a suas credenciais, é uma pessoa que considero bastante. Entretanto, isso não impede de eu discordar de algumas coisas que ele comentou, como, por exemplo, sobre responsive web design, que, definitivamente, não considero como uma “moda”, e sim como um novo padrão/necessidade de desenvolvimento que está surgindo e será tão comum/necessário dentro de pouco tempo quanto hoje o é o próprio HTML!

De jeito nenhum somente sites que tem a “clientela” usando 2 ou 3 dispositivos específicos se beneficia disso. Aqui no desenvolvimento para web, mesmo, que possui acesso bem inferior aos 90k/mês do Tableless, que ele citou, tem acesso em mais de 50 resoluções diferentes (sendo quase 40 com largura inferior a 640px)! E olha que é um site mais específico, imagina um que possui centenas de milhares ou milhões, voltado ao “público, em geral”…

Discordei, também, sobre as considerações feitas sobre o LESS (que, por sinal, receberá um artigo aqui, no blog, brevemente). É evidente que projetos menores não se beneficiam tanto quanto os maiores ao usar LESS, mas, certamente, ele ajuda, e muito, na hora de organizar, manusear e lidar, de maneira em geral, com o CSS.

Sim, é possível fazer tudo sem usá-lo, assim como é possível programar um site inteiro num editor de texto puro… Possível, é, mas existem soluções mais desejáveis, que melhoram a produtividade? Neste caso, acredito que sim, e o LESS faz justamente isso! O fato de ser preciso compilar o CSS é um passo necessário para desfrutas de todas suas boas características, mas, pessoalmente, não vejo como algo ruim ou tão prejudicial, assim, que deva ser critério de decisão para a ferramenta não ser usada.

Considerações finais

No mais, certamente esta foi uma conferência muito boa, que vai ao encontro do objetivo proposto pelo Diego de conscientizar mais os desenvolvedores web frontend quanto a sua área de atuação, o que esperar da profissão e como contribuir para sua mudança para melhor! O cara é um dos grandes do ramo, já trabalho para empresas realmente grandes e, devido a sua experiência, é preciso, no mínimo, prestar atenção e refletir sobre o que ele disse.

Também espero que a profissão melhore o quanto antes, que o nível de maturidade dos profissionais também evolua e que a valorização – em todos os sentidos da palavra – aconteça antes mesmo do que se espera, e que tenhamos a consciência de que, realmente, “a revolução começa na trincheira”, que são os próprios desenvolvedores os responsáveis pelo atual estado e status em que nos encontramos e que, para que isso mude, primeiramente temos, cada um de nós, que mudar!

Bom trabalho, pessoal do DevCast, e nos vemos por aí!  ;-)

Artigos Relacionados

• Sobre parcerias de trabalhos em desenvolvimento web
• Como montar um portfolio sem ter clientes
• Fechamento de contratos e designs para web: teoria e prática
• Usando Modernizr para detectar features de HTML5 e CSS3
• Não use IDs como seletores em CSS
• 10 dicas que desenvolvedores web iniciantes devem saber
• Elementos de design aplicados à web
• Cores na web: guia completo
• Erros comuns em desenvolvimento web para campanhas de SEO
• Estratégia Web de Pirâmide: guia para uma estratégia de web equilibrada

Os recursos e técnicas que estão surgindo com HTML5 e CSS3 são fenomenais e estão levando a web para um próximo nível. Mas o que fazer se já for preciso usar alguns destes recursos já? Como lidar com browsers que ainda não suportam todas as features de HTML5 + CSS3? A solução tem nome: Modernizr.

Modernizr é uma biblioteca JavaScript que detecta quais features de HTML5 e CSS3 o navegador de quem visita o site suporta. Isso permite aos desenvolvedores testar algumas das novas tecnologias e, em seguida, fornecer fallbacks para navegadores que ainda não as suportam. Isto é chamado de feature detection (detecção de característica) e é muito mais eficiente do que browser sniffing.

Também é importante ter em mente que o Modernizr não “preencher as lacunas” (polyfill). Ele só detecta quais características são suportadas. Mas é possível usar usar o Modernizr como parte do processo de polyfilling.

Começando a usar o Modernizr

Primeiramente, vamos precisar de um pouco de HTML (HTML5, claro!):

<!DOCTYPE html>
<html class="no-js" lang="en">
    <head>
        <meta charset="utf-8">
        <title>Hello Modernizr</title>
        <script src="modernizr.js"></script>
    </head>
 
    <body>
    </body>
</html>

É possível notar no código acima que o arquivo modernizr.js é necessário. É preciso gerar e baixar o arquivo no site do Modernizr, escolhendo as características que serão precisas serem detectadas. Isso ajuda a ter um arquivo modernizr.js com tamanho adequado às necessidades do projeto, já que não é preciso detectar tudo o que o Modernizr é capaz. Há, também, uma versão “development” no site para começar o desenvolvimento rapidamente. Mas, quando for colocar o site em produção, lembre-se de gerar um arquivo personalizado!

Tela de download do Modernizr

Ainda observando o trecho de código acima, veja que na segunda linha há uma classe “no-js” no html. O Modernizr funciona substituindo essa classe pela classe “js”; então, ele adiciona classes para todas as features que o navegador suporta e, também, para os recursos que ele não suporta, pré-fixando estas com “no-”. Por exemplo:

<html class="js no-flexbox canvas canvastext no-webgl no-touch geolocation postmessage no-websqldatabase no-indexeddb hashchange no-history draganddrop no-websockets rgba hsla multiplebgs backgroundsize no-borderimage borderradius boxshadow no-textshadow opacity no-cssanimations no-csscolumns no-cssgradients no-cssreflections csstransforms no-csstransforms3d no-csstransitions fontface generatedcontent video audio localstorage sessionstorage no-webworkers no-applicationcache svg inlinesvg smil svgclippaths">

Detecções explícitas com Modernizr

O Modernizr cria um objeto JavaScript global Modernizr que permite consultar diferentes propriedades desse objeto para realizar a detecção de recursos, chamando Modernizr.<feature>. Por exemplo, para testar o suporte a canvas, o código seria:

<script>
if (Modernizr.canvas)
{
    alert("Seu browser suporta HTML5 canvas!");
}
</script>

Como bons desenvolvedores web que somos, nosso objetivo é escrever JavaScript não obstrusivo e progressivo para que todos possam usar o site, portanto, é preciso tomar alguma ação para o caso da feature não ser suportada:

<script>
if (Modernizr.canvas)
{
    alert("Seu browser suporta HTML5 canvas!");
}
else
{
    alert("Seu browser NÃO suporta canvas...");
}
</script>

Ou, caso se queira testar somente a “negação”:

<script>
if ( ! Modernizr.canvas)
{
    alert("Sem canvas aqui...");
}
</script>

Detecção de recursos e Polyfilling com YepNope

Antes de continuar, caso ainda não saiba o que é “Polyfill”, veja este definição do Paul Irish:

Um shim que imita uma API futura, fornecendo funcionalidades de fallback para navegadores mais antigos.

Para maiores informações, leia (em inglês) o artigo “What is a Polyfill?” de Remy Sharp. Voltando ao artigo…

Nos exemplos JavaScript acima, foi mostrada a maneira mais simples de detectar um recurso de browsers usando o Modernizr. Mas e se você quiser detectar um recurso e usar um polyfill para tornar a performance do navegador melhor? É possível, usando YepNope.

YepNope é um carregador condicional, que significa que ele só irá carregar os scripts que são necessários para o browser. E ele já está incluso no Modernizr! Dessa forma, não é preciso se preocupar com downloads e links para outros arquivos JavaScript. Mas como usar o YepNope junto com o Modernizr?

Utilizando canvas como exemplo novamente, geralmente é preciso uma alternativa (fallback) para os navegadores que não o suportam (por exemplo, IE8). A maneira usual de se fazer isso é um link para um polyfill, tal como o FlashCanvas:

<script src="http://flashcanvas.net/bin/flashcanvas.js"></script>

O problema dessa abordagem é que todos os navegadores irão baixar este script. Isso é desnecessário, pois impacta a performance do site, e deve ser evitado sempre que possível. É possível envolver o elemento script em comentários condicionais, mas, caso seja possível manter os arquivos condicionais fora da marcação, então isso é preferível. Isso é possível de ser feito usando Modernizr.load(). Já que o Modernizr tem o YepNope embutido, é facilmente possível testar um recurso e, em seguida, fornecer um polyfill:

O uso básico da função .load() permite que testar a presença de uma feature. Veja este exemplo em que o Modernizr testa o suporte para canvas e, caso o browser não a suporte, ele carrega o FlashCanvas:

Modernizr.load({
    test: Modernizr.canvas,
    nope: 'http://flashcanvas.net/bin/flashcanvas.js'
});

Usando as developer tools do IE8, na aba “Network” é possível ver o download e inicialização do flashcanvas.js. Legal, hã? ;-)

Modernizr + YepNope: checando downloads condicionais no IE8

Vamos a um exemplo mais prático que detecta o suporte a <input type="date">. Se não for suportado, haverá o carregamento de 2 arquivos jQuery e um arquivo CSS para gerar um seletor de datas:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<script src="modernizr.js"></script>
<script>Modernizr.load({
    test: Modernizr.inputtypes.date,
    nope: [
        'http://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js',
        'http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.7/jquery-ui.min.js',
        'jquery-ui.css'
    ],
    complete: function() {
        $('input[type=date]').datepicker({
            dateFormat: 'yy-mm-dd'
        });
    }
});
</script>

Na maioria dos navegadores, o jQuery será carregado, mas, no Opera, não haverá essa necessidade, já que ele já possui um seletor de datas nativo por já suportar <input type="date">.

Seletor de datas no Firefox

Seletor de datas no Opera

E, como você já deve ter imaginado, carregar ou não 2 arquivos JavaScript e uma folha de estilos gera uma grande diferença na performance do site.

Comparação de recursos ao carregar datapicker: Firefox x Opera

Observe como os 2 arquivos jQuery são carregados duas vezes. Isso acontece, mesmo, no YepNope: primeiro ele carrega o recurso e, em seguida, executa-o. Então, não se preocupe, pois isso é normal. E veja, também, todas as propriedades do objeto de teste do YepNope, conhecê-las pode ser bastante útil!

Conclusão

Como pôde ser visto, Modernizr é uma poderosa biblioteca de detecção de features. Ela permite verificar se o navegador suporta vários recursos e, dependendo do resultado, permite que sejam usados polyfills. Este artigo analisou como gerar um arquivo Modernizr e suas 2 maneiras de uso: usando diretamente o objeto Modernizr (Modernizr.<feature>) e, em seguida, usando YepNope.

Com isso, damos mais um passo rumo ao desenvolvimento de uma web melhor, mais profissional e com desenvolvedores mais conscientes das limitações intrínsecas aos diversos dispositivos que podem ser usados para se acessar um site. Sabíamos do “mal”, agora conhecemos a cura.

Artigos Relacionados

• Não use IDs como seletores em CSS
• Como usar .ready() antes de incluir a jQuery
• Ferramentas e recursos para desenvolvimento web
• 8 características de User Interfaces (UI) de sucesso
• 10 fontes de inspiração para fazer logotipos de qualidade
• Gestalt aplicado ao design web (parte 5): exemplos web do princípio do alinhamento
• Gestalt aplicado ao design web (parte 3): exemplos web do princípio da proximidade
• Evitando erros comuns de HTML5
• Microdata API e Schema.org: dando significado ao HTML
• Desenvolvedores front end e o mercado

Quando estamos aprendendo a trabalhar com HTML e CSS, é comum aprendermos logo de cara as diferenças entre IDs e classes e quais vantagens tirar disso, como e quando usar um ou outro e assim por diante. Mas, após a realização de alguns testes de performance, pode ser que esse nosso aprendizado “de raiz” precise de uma pequena revisão.

Quando se é desenvolvedor web, fazer com que nossos códigos e/ou marcações, seja lá em que linguagem form, sejam cada vez melhores, é praticamente inerente ao ofício. E, com isso em mente, após fazer alguns testes com performance em folhas de estilo, algumas considerações interessantes podem ser encontradas, principalmente em relação a usar seletores de ID em CSS.

Mas existem alguns pontos que merecem ser levados em consideração:

1. Perfomance
2. Fragmentação
3. Tradição

Performance

Pode perguntar para qualquer codificador CSS e ele vai responder que os seletores de ID são os mais rápidos. Mas isso vem com uma grande limitação: IDs são os seletores mais rápidos somente se eles forem os seletores-chave. O que é isso? Bem, nós lemos os seletores da esquerda para a direita, mas, caso não saiba, os navegadores leem da direita para a esquerda! Dê uma olhadinha nas explicações do SelectORacle que você vai ver.

Para um seletor #home a chega ser até normal supor que o browser vai localizar o elemento de ID “home” e aplicar os valores das propriedades em todos seus links. Super rápido, não é? Agora, veja o que realmente acontece: o browser pega todos os elementos a, então, verifica se são descendentes imediatos de #home e, caso não seja, vai checando os ascendentes até chegar em <html>.

Então, será, mesmo, que a diferença de performance é tão grande? Para ter certeza, foram feitos 3 testes usando o Criador de Testes CSS de Steve Souders, cada um deles utilizando 1000 elementos a que foram selecionados a partir de IDs individuais, classes ou IDs com os seletores a. Então, as páginas foram recarregadas diversas vezes para pegar a média dos resultados (números em ms).

Então, para as 1000 regras testadas, os IDs se mostraram cerca de 1 milésimo de segundo mais rápido do que as classes como um seletor-chave, ou seja, a diferença de desempenho entre IDs e classes é irrelevante!

O cenário mais comum de se usar um ID como  “namespace” de um elemento (onde o elemento é o seletor-chave) é realmente mais lento do que usando uma classe, mas, novamente, somente com  13 milissegundos de diferença. Isso também é válido para os poucos bytes extras para adicionar uma classe num elemento que já tenha um ID, por exemplo, mudando <div id="search"> para <div id="search" class="search">.

Mas isso não quer dizer que todos os seletores são iguais. O seletor universal * e alguns seletores CSS3 têm desempenho relativamente fraco quando usado como seletor-chave.

No entanto, não se torna um problema caso o uso seja para 1 a 2 seletores (elementos e/ou classes), usando seletores CSS3. O impacto na performance de seletores é pequeno se comparado a outras coisas como otimização de imagens ou redução de requisições HTTP. Esse tipo de coisa é o que realmente importa quando se tem a performance do site como fator preponderante.

Fragmentação

Além de serem “anzóis de estilo”, IDs são utilizados como identificadores de fragmentos específicos da página (um href que termina em #ancora leva ao elemento de ID “ancora”) e para uso de JavaScript. Se já existem IDs na página por outras razões, por que não reutilizá-los para estilizar? O problema é que isso torna o código fragmentado: há dependências entre CSS e JavaScript e/ou um identificador de fragmento. Usando classes, é possível decidir mudar para um (novo) esquema de nomeação a qualquer momento e tudo o que é preciso se preocupar é alterar alguns nomes no CSS e HTML.

Existem muito poucos casos em que estilos baseados em ID nunca serão reutilizados. Um exemplo é usar #search para a caixa de busca do site. Pode-se decidir mais tarde que uma nova caixa de busca será adicionada em outro local (abaixo dos resultados de busca, por exemplo). Mesmo #search sendo único nesse projeto, talvez você queira um pouco de CSS rápido para copiar e colar em um projeto futuro – que também pode ter uma caixa de pesquisa no rodapé da página. Mesmo para um grupo complexo de folhas de estilo, é possível dividir esses padrões em vários trechos reutilizáveis ​​de CSS. Usar classes ao invés de IDs impede que esses potenciais problemas venham à tona.

E, ao contrário de IDs, não há nenhuma restrição em usar várias classes, tanto em mais de uma vez na página, quanto várias classes em um mesmo elemento. Navegadores ainda estilizarão IDs, mesmo se, por engano, houver duplicação em um página. Mas se aventurar fora do HTML válido o torna propenso a problemas…

Tradição

Estilizar com IDs e classes são uma das primeiras coisas que aprendemos sobre CSS, por isso, pode ser um desafio ouvir “não use IDs em seletores CSS”. No entanto, o ramo do desenvolvimento web está sempre mudando. Ocasionalmente, precisamos reavaliar o que funciona e o que não funciona ao invés de apenas ficar com o que está nos servido bem, sem questionamentos.

No momento, estamos passando por um renascimento maciço com HTML5, CSS3, desempenho de JavaScript incrível e lançamentos de navegadores rápidos, por isso é um grande momento para esse repensar. No entanto, é importante examinar as razões de forma racional e decidir se as questões apresentadas são, realmente, válidas, ao invés de rejeitá-las de antemão.

Conclusão

Como pôde ser constatado no artigo, parece que não há razões convincentes para usar IDs em seletores CSS – a não ser para “namespaces”, uso de widgets e plugins específicos em CMSs e casos similares. Em CSS, classes podem fazer tudo o que IDs podem! Pense nisso na próxima vez em que iniciar um projeto e, ao invés de um IDs, tente trabalhar com classes, deixando os IDs para identificadores de fragmentos ou hooks para JavaScript.

Polêmica ou assustadora demais essa história de não usar IDs como seletores em CSS? O que, realmente, você pensa sobre isso? Comente!

Artigos Relacionados

• Usando Modernizr para detectar features de HTML5 e CSS3
• Elementos de design aplicados à web
• Erros comuns em desenvolvimento web para campanhas de SEO
• Estratégia Web de Pirâmide: guia para uma estratégia de web equilibrada
• 8 maneiras de melhorar a performance de um site
• Como otimizar imagens para web: guia de otimização de imagens
• 8 características de User Interfaces (UI) de sucesso
• Pergunte-se a si mesmo: questões para desenvolver um bom site
• Meta tags
• Compatibilidade CSS e o Internet Explorer: tabela comparativa de compatibilidade CSS/IE

Uma das mais “tradicionais” regras de performance de sites é colocar as chamadas para javascripts externos no final do documento HTML, antes do fechamento da tag body. Mas não são raras as ocasiões em que nós, desenvolvedores web, precisamos inserir códigos que dependem da jQuery no meio do documento (posição que fica antes do indicado para se chamar a própria jQuery). Como proceder?

Antes de continuarmos, é importante saber que existem diferentes sintaxes possíveis para “ativar” o jQuery:

$(handler) // "handler" é a função a ser vinculada
 
$(document).ready(handler);
 
$().ready(handler) // maneira não recomendada
 
$(document).bind('ready', handler);

E existe solução para usar .ready() antes de incluir o jQuery?

Sim, existe solução para usar .ready() antes de incluir o jQuery e, felizmente, a solução é eficaz em todas essas possibilidades apresentadas – e, talvez, até em algumas outras, quem sabe…

Em termos práticos, a solução é:

<!-- No <head> -->
<script type="text/javascript">
(function(w,d,u){w.readyQ=[];w.bindReadyQ=[];function p(x,y){if(x=="ready"){w.bindReadyQ.push(y);}else{w.readyQ.push(x);}};var a={ready:p,bind:p};w.$=w.jQuery=function(f){if(f===d||f===u){return a}else{p(f)}}})(window,document)
</script>
 
<!-- No <body> (imediatamente após a jQuery) -->
<script type="text/javascript">
(function($,d){$.each(readyQ,function(i,f){$(f)});$.each(bindReadyQ,function(i,f){$(d).bind("ready",f)})})(jQuery,document)
</script>

Claro que não dá pra entender a lógica olhando script comprimidos. Vejamos o de head:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

(function (w, d, u) {
 
    // Define duas queues para os handlers
    w.readyQ = [];
    w.bindReadyQ = [];
 
    // Insere um handler na queues correta
    function pushToQ(x, y) {
        if (x == "ready") {
            w.bindReadyQ.push(y);
        } else {
            w.readyQ.push(x);
        }
    }
 
    // Define um objeto alias (para uso posterior)
    var alias = {
        ready: pushToQ,
        bind: pushToQ
    }
 
    // Definir a função jQuery "fake" para capturar os handlers
    w.$ = w.jQuery = function (handler) {
        if (handler === d || handler === u) {
            // Coloca na queue $(document).ready(handler), $().ready(handler)
            // e $(document).bind("ready", handler), retornando um objeto com
            // os métodos de "alias" para pushToQ
            return alias;
        } else {
            // Queue $(handler)
            pushToQ(handler);
        }
    }
 
})(window, document);

O script de body (imediatamente depois da jQuery):

1
2
3
4
5
6
7
8
9
10
11

(function ($, doc) {
 
    $.each(readyQ, function (index, handler) {
        $(handler);
    });
 
    $.each(bindReadyQ, function (index, handler) {
        $(doc).bind("ready", handler);
    });
 
})(jQuery, document);

Usa-se o $.each() para associar corretamente todos os handlers na fila para o DOM pronto, mas, porque $(document).bind(“ready”, handler) pode ter sido chamado antes, é preciso dar um bind, também, da maneira correta.

Exemplo de uso

OK, realmente é um pouco confuso de se entender de primeira, por isso, vejamos este exemplo de como usar o $.ready() antes da jQuery, seguido de suas respectivas saídas num console.

Exemplo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

<!DOCTYPE html>
<html>
    <head>
        <title>Example</title>
        <script>(function(w,d,u){w.readyQ=[];w.bindReadyQ=[];function p(x,y){if(x=="ready"){w.bindReadyQ.push(y);}else{w.readyQ.push(x);}};var a={ready:p,bind:p};w.$=w.jQuery=function(f){if(f===d||f===u){return a}else{p(f)}}})(window,document)</script>
    </head>
    <body>
        <script>
            $(document).bind("ready", function () {
                console.log("Examplo D: $(document).bind(\"ready\", handler)");
            });
            $(document).ready(function () {
                console.log("Examplo A: $(document).ready(handler)");
            });
            $().ready(function () {
                console.log("Examplo B: $().ready(handler)");
            });
            $(function(){
                console.log("Examplo C: $(handler)");
            });
        </script>
        <script src="//ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js"></script>
        <script>(function($,d){$.each(readyQ,function(i,f){$(f)});$.each(bindReadyQ,function(i,f){$(d).bind("ready",f)})})(jQuery,document)</script>
    </body>
</html>

Console:

1
2
3
4

Example A: $(document).ready(handler)
Example B: $().ready(handler)
Example C: $(handler)
Example D: $(document).bind("ready", handler)

Haha! Viu, só? Apesar de, no código, o scripts do “Exemplo D” ter sido o primeiro, na saída do console os exemplos executaram perfeitamente na ordem “A, B, C, D”!   \o/

Conclusão

E, com isso, vimos que é perfeitamente possível – e relativamente simples – usarmos chamadas ao .ready() da jQuery de forma “não ordenada”. Isso faz abrir um leque de possibilidades interessante, pense bem!

Se gostou e/ou tem alguma ideia de como usar isso para melhorar seus scripts, comente e compartilhe! Ajude a desenvolver a web! ;-)

Artigos Relacionados

• Usando Modernizr para detectar features de HTML5 e CSS3
• Evitando erros comuns de HTML5
• Microdata API e Schema.org: dando significado ao HTML
• Não use IDs como seletores em CSS
• Como otimizar códigos jQuery e aumentar a performance do front-end
• JSON – JavaScript Object Notation
• Como fazer loading em conteúdos do site
• 5 dicas para temas WordPress melhores
• Melhorando a interação em formulários de busca
• 8 maneiras de melhorar a performance de um site

Este é um “meta artigo” para os leitores e visitantes saberem sobre o novo tema do desenvolvimento para web, o dpw2012! Vou comentar um pouco sobre este novo tema e as novidades que vêm por aí! Continue lendo…  ;-)

Motivações para um novo tema, o dpw2012

Bem, pessoal, as motivações que me levaram a criar este novo tema acho que são as mesmas de qualquer um que trabalho no desenvolvimento web – e goste do que faz, obviamente: aprendizado, inovações, testes de novas técnicas, etc. Com isso em mente, há alguns meses atrás cheguei à conclusão de que o tema anterior estava “meio antiguinho” (leia-se: defasado), tanto em relação à aparência, quanto nas tecnologias usadas… Por isso, cá estamos nós, com este novíssimo tema, com muitas novidades!

dpw2012: tecnologias

Vamos a alguns pormenores das tecnologias envolvidas e como eu consegui desenvolver este tema usando algumas das tecnologias de desenvolvimento web mais recentes que podemos encontrar, hoje em dia.

HTML5 e HTML5 Boilerplate

Já algum tempo, mesmo antes de ter a ideia de desenvolver este tema, já havia começado a estudar sobre HTML5. Li bastantes artigos e alguns livros a respeito e, como não estamos falando de uma tecnologia pronta, continuo os estudos e fico de olho nas novidades – inclusive, podem esperar artigos sobre HTML5, claro!

No meio da história, tive a felicidade de conhecer o HTML5 Boilerplate! O HTML5BP é simples uma das melhores coisas que surgiu para desenvolvimento web nos últimos tempos: trata-se de um “modelo HTML5″ para se começar a desenvolver rapidamente; mas não é somente isso.

Ele conta com muito mais coisas além de um excelente modelo de HTML5: javascripts, folhas de estilo, um .htaccess robusto demais e muitas, muitas coisas. Para terem uma ideia, aprendi mais sobre desenvolvimento web em 1 semana estudando o HTML5BP que em muitos meses passados… Vale a pena!

Twitter Bootstrap

O Twitter Bootstrap já está bem conhecido entre os desenvolvedores estadunidenses e europeus, mas, confesso, ainda não vi tantos sites em território nacional que se valham desse fabuloso e estupendo toolkit para desenvolvimento web. O Twitter Boostrap conta com um CSS incrível (com LESS), que garante um sistema de grid bem facinho de se mexer, além de elemento de UI muito eficientes e javascripts para fazer tudo isso ficar ainda melhor!

Imagine, você, encontrar prontos, funcionais e testados por desenvolvedores web de primeira linha elementos de navegação, botões, tabs e pills, menus drop down e muitos outros componentes de UI, que são cross-browser e ainda contam com javascript próprio! Bem, isso é Twitter Bootstrap…!

Há alguns dias atrás, também conheci um “complemento” ao Bootstrap que me foi bastante útil. A grande maioria dos ícones que vocês estão vendo no site, na verdade não são ícones: é uma fonte! O projeto Font Awesome foi criado visando aprimorar o Twitter Bootstrap, tornando possível substituir o uso de imagens por uma fonte. Ele usa todos os ícones padrão do Bootstrap e ainda estendeu com mais alguns! Realmente, “awesome”!

Design Responsivo

Oh, yeah! Somos responsivos, baby!  ;-)

Também antes de começar a desenvolver este tema, já estava estaudando sobre design responsivo. Quando comecei a colocar a mão na massa, já tinha certeza de que queria que assim o fosse – afinal, este é um novo padrão de desenvolvimento web, não uma “tendência”, como querem forçar alguns! Havia algumas possibilidades para isso: escrever tudo do zero; usar algo que ajudaria, com estilo parcialmente pronto; pegar um tema pronto para WordPress.

Como podem ver, fiquei com o meio termo. Desenvolver tudo do zero, acredito não haver necessidade e, pegar tudo pronto, acaba com toda a graça, não é verdade? Portanto, fiquei com Twitter Bootstrap responsivo + HTML5 Boilerplate fantástico! Uma boa combinação, eu diria.

Microdata API + schema.org

Também é algo que só vi em 1 site brasuca conceituado, até então, e o dpw2012 também faz uso: Microdata API + Schemas. Grosso modo, são nomes padronizados de classes e atributos HTML que dão maior significado ao conteúdo apresentado em web sites. Os principais buscadores reconhecem este padrão, embora (teoricamente) ainda não estejam usando como fatores de classificação. De qualquer maneira, está, aí, o site preparado para quando isso acontecer – se é que já não está acontecendo “na surdina”.

<update>
Para os que não acompanham o twitter do desenvolvimento para web, a possível eficiência da Microdata API juntamente com os padrões do schema.org está ainda mais perto de ser confirmada.

Para sanar a dúvida do combo HTML5 + Schema: semana passada estava em 10º para "desenvolvimento web"; hoje, em 2º! o/

2 de April de 2012 5:35 pm via HootSuiteReplyRetweetFavorite

@desenvolvweb

desenvolvweb

Estou usando, basicamente, os schemas de Blog, BlogPosting, mas ainda vou explorar mais schemas para incluir. Apesar de eu não garantir a eficiência disso, #FicaADica para o estudo e implementação, já que é bem divertido!

Novo logo

Pra quem segue @desenvolvweb, deve ter notado (ou não) o seguinte tweet, cerca de 1 mês atrás:

E esse é o novo logo do blog! http://t.co/PfIIuJV8 // Fora a qualidade do upload, o que acharam? ;-D

24 de February de 2012 7:57 pm via HootSuiteReplyRetweetFavorite

@desenvolvweb

desenvolvweb

Quer dizer, o logo já estava pronto e sendo “maturado” no twitter e, agora que o lançamento do tema aconteceu, me pareceu apropriado usá-lo oficialmente. Mais uma vez, obrigado a Alanna Couto!  ;-)

Considerações finais

Pra mim, o blog teve um ganho incrível com a implementação desse novo tema: com um toque mais clean, agora os conteúdos estão melhor apresentados, o leitor vai direto ao ponto e, com o design responsivo, tudo ficou muito mais acessível e agradável!

O fato de estar usando menos imagens e ter limado bastante de javascript desde a última versão, também contribui para a leveza do carregamento e, apesar de eu já estar usando cache nas páginas, performance do site é sempre uma boa coisa!

Meu “Obrigado!” a todos os que deram seus pitacos construtivos para que o tema ficasse melhor do que eu esperava, contando o pessoal do grupo html5-css3-brasil, tanto os que apareceram publicamente, quanto os que entraram em contato em particular.

E, se possível, gostaria de contar a sua ajuda, também! Caso encontre algum bug e/ou tenha sugestões a fazer, por favor, comente neste artigo ou envie uma mensagem. O desenvolvimento para web é um espaço de testes e, por aqui, nada está acabado ou é feito de maneira que não possa se alterar.

Muito obrigado, leitores assíduos, leitores do feed e até mesmo os visitantes casuais! Espero continuar contando com vocês!  ;-)

Artigos Relacionados

• Nenhum artigo relacionado...

Como havia anunciado num tweet de alguns dias atrás, a Novatec Editora fechou uma parceria com o blog. A partir de agora, serão publicadas resenhas dos livros relativos a desenvolvimento web da editora.

E, para começar esta parceria com o pé direito, vamos à resenha do excelente livro Guerreiro SEO!

Informações sobre o livro Guerreiro SEO

Guerreiro SEO é a tradução do livro SEO Warrior, escrito por John I. Jerkovic e publicado pela O’REILLY; tradução esta feita por Rafael Zanolli e que, com exceção de um ou outro lapso, ficou bastante interessante.

A tradução do livro, contanto com informações editoriais, sumário, apêndices e índices, ficou com mais de 500 páginas – incluindo as imagens, que são em P&B. À primeira vista pode até parecer que o livro é grande e intimida um pouco, mas a leitura é bastante suave e, tirando uma ou outra parte mais densa, é possível ler dezenas de páginas, de uma só vez, sem se cansar.

É um livro bem feito, bem acabado, que pode ser manuseado sem maiores desconfortos, mesmo quando se está mais para o início ou mais para o fim e a relação de páginas para “cada lado” é totalmente desproporcional; em outras palavras, dá pra ler confortavelmente sentado ou deitado.

Guerreiro SEO: capítulos e conteúdo

A evolução de leitura e da temática do livro ficou boa. Começa-se com temas bastante básicos e mais abstratos e, a medida em que a leitura vai tendo continuidade, mais atenção e foco são requeridos para se acompanhar as dicas, técnicas e indicações a respeito de SEO que vão sendo dadas.  Nesta primeira edição do livro, a divisão dos 18 capítulos ficou assim:

1. Uma visão geral. Capítulo que, não surpreendentemente, apresenta uma visão geral sobre o que é SEO e como se dá o processo de SEO.
2. Introdução aos mecanismos de busca. Explica como funcionam os mecanismos de busca e de que tipo e categoria podem ser.
3. O essencial sobre websites. Explicações básicas sobre como funciona o processo de registro de domínios, opções de hospedagem, considerações sobre design e usabilidade e até algumas dicas sobre performance!
4. Fatores de classificação internos. Aqui a coisa já começa a ficar um pouco mais séria e a parte técnica de SEO começa a ser apresentada em dicas de otimização on-site, como tag title, meta tags, textos-âncora, proximidade, proeminência, etc.
5. Fatores de classificação externos. Fatores de SEO off-site, incluindo link building, idade do site e como lidar com alguns problemas (muitas vezes não vistos como tal) que podem acontecer.
6. Monitoramento de estatísticas web. Capítulo que fala sobre monitoramento em sites, apresentando alguns conceitos básicos a respeito (visitantes únicos, total de visitantes, etc) e mostrando algumas ferramentas interessantes de monitoramento, inclusive para se instalar diretamente no servidor.
7. Google Webmaster Tools e Google Analytics. Justificadamente, um capítulo dedico a essas 2 ferramentas praticamente indispensáveis para uma boa análise de SEO. O capítulo apresenta as ferramentas, de modo geral, e ensina o básico sobre como localizar algumas estatísticas.
8. Armadilhas para mecanismos de busca. Capítulo muito interessante, que mostra que no mundo do SEO existe uma parte dedicada às “armadilhas” que existem quando o assunto é otimização para mecanismos de busca: conteúdo JavaScript, AJAX, iframes e muito mais.
9. Protocolo de exclusão de robôs. Informações e histórico do Robots Exclusion Protocol (REP), bastantes informações sobre como trabalhar com o robots.txt e outras formas de controlar acessos de bots usando meta tags e até configurações no lado do servidor. Capítulo essencial!
10. Sitemaps. Outra parte do livro que não poderia faltar, o capítulo dedicado aos sitemaps explica o que eles são, como é seu formato padrão, importância de uso e algumas dicas especiais a respeito.
11. Pesquisa de palavra-chave. Dicas e macetes muito, muito importantes, sobre como definir uma estratégia de palavras-chave, sua relação com a linguagem (alternadores, radiciação, etc), e como se dá o processo de pesquisa de keywords, com detalhes e pormenores de ferramentas indispensáveis para tal.
12. Construção de links. Ou link building, para os mais íntimos, que é abordado neste capítulo com estratégias realmente diferentes do que se encontra em sites de SEO, dicas realmente preciosas e, até então, não pensadas pela maioria, de como fazer um link building de qualidade. É sério!
13. Pesquisa e análise da concorrência. Pelo menos pra mim, foi um “capítulo-surpresa”. Afinal, pesquisar a concorrência é um tema não específico de SEO, que poderia não ter sido incluso. Mas, felizmente, o foi, e nele é possível encontrar dicas preciosíssimas de como conhecer, avaliar e monitorar a concorrência.
14. Considerações de conteúdo. Outra parte bastante interessante e importante, que trata sobre SEO preditiva, conteúdo de curto e longo prazo, criação de conteúdo e considerações sobre duplicação de conteúdo.
15. O fenômeno das redes sociais. Como aumentar a visibilidade de um site/projeto web usando blogs, twitter e digg-likes. Também como montar uma boa estratégia de Social Media Optimization (SMO) e um apanhado geral sobre o futuro dos buscadores: buscas em tempo real.
16. Marketing nos mecanismos de busca. Trata de Search Engine Marketing, mostrando como se dá o processo de SEM e funcionamento e estratégias de palavras-chave no Google AdWords.
17. Spam e mecanismos de busca. Como acontece o SPAM em mecanismos de busca, o que evitar fazer para não ser considerado um spammer e medidas para o caso seu site seja penalizado pelos buscadores.
18. A agitação do mercado. Considerações sobre o Google SearchWiki, ferramentas para analisar resultados de busca em diversos buscadores, nofollow e como se manter atualizado no mundo de SEO.

“Apanhado geral” sobre o livro Guerreiro SEO

Quando estava lendo Guerreiro SEO, até, mais ou menos, o capítulo 7, pensei se tratar de mais um livro introdutório sobre algum tema relativo a desenvolvimento web (no caso, SEO). Mas qual não foi minha surpresa quando continuei a leitura e, apesar de ainda encontrar sobre muita coisa que já sabia, me deparei com dicas e “pulos do gato” que, apesar de ainda não ter feito testes práticos, realmente fazem todo o sentido e podem fazer uma diferença significativa numa classificação de uma página em SERPs.

Além disso, achei muito interessante o fato de o livro abordar dicas não somente voltadas ao Google, mas, também, ao Yahoo! e ao Bing. Apesar da já sabia supremacia do Google na área, existe uma porcentagem importante de visitantes que, dependendo do caso/estratégia do negócio, se encontra nos outros buscadores.

Outro diferencial é que o autor, durante todo o livro, apresenta sugestões de uso de scripts para apresentação de dados importantes e automatização de tarefas de SEO e, para a felicidade dos leitores, disponibiliza-os, na íntegra, para serem usados nas estratégias e trabalhos de SEO!

Conclusão

Dando minha sincera opinião, o Guerreiro SEO é livro que atende primordialmente a quem está começando ou começou a pouco tempo na área, mas, com certeza, tem muito a oferecer com que já é do ramo através de dicas de “micro otimização”, inclusive para mecanismos de busca específicos, e através de suas sugestões de estratégias e disponibilização de scripts que automatizam parte do trabalho de SEO.

Portanto, seja você iniciante na área ou já veterano, ter este livro no acervo para consultas constantes é, de fato, uma opção séria a ser considerada.

Bônus!

Ah, uma coisa que esqueci de comentar… A parceria com a Novatec também garantiu um código promocional especialmente para os leitores do desenvolvimento para web! Com este código, você pode adquirir Guerreiro SEO e qualquer outro título da editora com 20% de desconto!

E fique ligado também no twitter do desenvolvimento para web, pois a qualquer momento pode haver uma promoção e você ser contemplado com um dos livros da Novatec! ;-)

Artigos Relacionados

• Nenhum artigo relacionado...

A maioria já compreendeu que desenvolvimento web é o ramo / campo de atuação mais dinâmico que existe atualmente. Todos os dias novos conteúdos, técnicas e abordagens sobre seus diversos segmentos são descobertos, divulgados, testados e aprovados, começando novamente num ciclo de constante aprimoramento.

E essa dinamicidade não diz respeito a somente conteúdos sobre o que já existe; também é sobre novas ramificações do conhecimento web que surgem. É o caso da Estratégia de Conteúdo.

Visão Geral

Estratégia de Conteúdo ou Content Strategy é uma área de atuação emergente dentro do mundo do desenvolvimento web – considerada por alguns especialistas como uma parte do Design de Experiência do Usuário (User Experience Design ou UXD), mas isso não é unânime.

A Estratégia de Conteúdo também descreve os papéis, produtos de trabalho, abordagens, conhecimentos, técnicas, metodologias e perspectivas do profissional da área, o estrategista de conteúdo.

Conteúdo

Conteúdo é substância. Não importa a plataforma, publicação ou formato, o conteúdo se refere a tudo o que transmite um significado:

• “Conteúdo inclui texto, gráficos, vídeo e áudio que compõem uma experiência interativa.” – Kristina Halvorson
• “Tecnicamente, o conteúdo da Web pode ser qualquer coisa que aparece em um site, incluindo palavras, imagens, vídeo, sons, arquivos para download (PDF), botões, ícones e logos.” – Richard Sheffield
• “Informação e experiências que pode proporcionar valor para um end-user/audiencia em contextos específicos.” – Wikipedia
• “Tudo é conteúdo.” – Rachel Lovinger citando Chris Sizemore
• “Simplesmente, o conteúdo são dados contextualizados.”

Estratégia de Conteúdo

Estratégia de Conteúdo é um campo emergente de prática que engloba todos os aspectos de conteúdo, incluindo a sua concepção, desenvolvimento, análise, apresentação, medição, avaliação, produção, gestão e governança.

Kristina Halvorson, autora de Content Strategy for the Web, define Estratégia de Conteúdo como “a prática de planejamento para criação de conteúdo, entrega e governança”.

Rahel Anne Bailie estendeu a definição de Estratégia de Conteúdo como “um processo repetitivo ou metodologia que gerencia conteúdo dentro de seu ciclo de vida inteiro”. Esta definição reconhece que ciclos de vida iterativos conteúdo vão além da entrega e, não necessariamente, começam com a criação de conteúdo.

No livro The Web Content Strategists Bible, Richard Sheffield dá ênfase à importância do processo editorial da Estratégia de Conteúdo.

Ciclo de Vida do Conteúdo, segundo Erin Scime (clique para aumentar)

Estratégia de Conteúdo: metodologias

Como é que se aplica este pensamento ou “se faz” Estratégia de Conteúdo? Rahel Bailie partilha a sua metodologia:

O Ciclo de Vida do Conteúdo é um sistema de repetição que rege a gestão de conteúdo. Os processos dentro de um Ciclo de Vida do Conteúdo são “agnósticos”. Os processos são estabelecidos como parte de uma Estratégia de Conteúdo e implementados durante o Ciclo de Vida do Conteúdo.

O Ciclo de Vida do Conteúdo abrange quatro fases macro: Análise Estratégica, Coleta de Conteúdo, Gestão do Conteúdo e Publicação (que inclui a publicação e a pós-publicação). O Ciclo está em vigor se o conteúdo é controlado por um CMS ou não, se ele é traduzido ou não, se ele é excluído no final de sua vida ou revisado e re-utilizado. O quadrante de análise compreende a Content Strategy; os outros 3 quadrantes são mais de natureza tática, com foco na implementação da Estratégia de Conteúdo.

Ciclo de Vida do Conteúdo segundo Rahel Bailie (clique para ampliar)

Análise

Na fase de Análise, o Ciclo de Vida do Conteúdo diz respeito aos aspectos estratégicos do conteúdo. Um estrategista de conteúdo (ou Analista de Negócios ou Arquiteto da Informação ou Escritor) examina a necessidade de vários tipos de conteúdo dentro do contexto do negócio e dos consumidores de conteúdo para várias saídas em múltiplas plataformas.

A Análise tem uma influência sobre a forma como a Estratégia de Conteúdo é implementada em outros quadrantes do Ciclo de Vida do Conteúdo. Em um novo projeto com novos conteúdos, este é o início do processo. Na maior parte do tempo, o processo vai começar em algum outro lugar no ciclo; depende muito de uma multiplicidade de fatores envolvidos na mudança de conteúdo de um estado atual para um estado futuro.

Coleta

A Coleta pode se dar através do desenvolvimento de conteúdo – criação de conteúdo ou edição de conteúdo de terceiros -, conteúdos de outras fontes, incorporação de conteúdo ou um híbrido de integração de conteúdo e convergência – por exemplo, mashups.

Gestão

O quadrante da Gestão concerne ao uso eficiente e eficaz do conteúdo. Em organizações que usam a tecnologia para automatizar o gerenciamento de conteúdo, o aspecto da gestão assume o uso de um CMS. Em organizações com pequenas quantidades de conteúdo, com pouca necessidade de controle de fluxo de trabalho, um gerenciamento manual é até possível. No entanto, em grandes empresas, há muito conteúdo e há muitas variações da produção de conteúdo, portanto um CMS se faz obrigatório.

O potencial de configuração de conteúdo é enorme e se baseia nas informações recolhidas durante a fases de Análise e Coleta. As soluções serão muito contextualizadas e giram em torno das entradas e saídas, as variáveis ​​conteúdo exigido, a complexidade do pipeline de publicação e as tecnologias em jogo. As perguntas mais básicas giram em torno da adoção de padrões e tecnologias e determinação de componentes, granularidade de conteúdo e o quão longe o pipeline de publicação irá implementar técnicas específicas.

Publicação

O quadrante da Publicação trata dos aspectos de conteúdo que acontecem quando o conteúdo é entregue para a plataforma de output. Publicar o conteúdo é apenas um ponto na iteração do Ciclo de Vida; existem considerações na pós-publicação, tais como reutilização e políticas de retenção que requerem atenção.

Estrategistas de Conteúdo

Mas as perspectivas estrategistas de conteúdo dependem bastante da formação, educação e influência do profissional.

Por exemplo, alguns se especializam em Análise de Conteúdo, que é mais sobre trabalhar com metadados, taxonomia, SEO e as maneiras em que a boa aplicação desses conceitos dá suporte ao conteúdo.

Outros preferem rumar para estratégias de Web Editorial, diretrizes e ferramentas que pode se estender a gestão da mudança organizacional. Esta forma de Estratégia de Conteúdo pode estar preocupada com o desenvolvimento de novas formas de conteúdos, tais como multimídia ou várias tecnologias de “gestão de presença”, como microblogs.

Há, também, outra corrente que simpatiza mais com os objetivos da Arquitetura da Informação. Neste caso, a Estratégia de Conteúdo envolve a escrita do Copy do site para as páginas do site novo e adaptar o conteúdo para as já existentes.

Todos os estrategistas de conteúdo estão familiarizados com uma grande variedade de aplicações e ferramentas e, muitas vezes, são responsáveis ​​pela implementação e treinamento de pessoas para melhor usá-las.

Colaboração com Estrategista de Conteúdo, por Richard Ingram (clique para ampliar)

Educação e Formação Profissional

Estrategistas de conteúdo surgem de uma variedade de disciplinas acadêmicas formais e profissionais:

• Biblioteconomia e Ciência da Informação
• Ciência da Computação
• Artes Cênicas
• Publicidade e Marketing
• Retórica e Composição
• Redação Técnica e Comunicação
• Jornalismo
• Comunicações
• Consultoria de Gestão

Empregadores proeminentes de estrategistas de conteúdo

Apesar de ser uma profissão relativamente nova, mega-empresas de renome internacional já contrataram ou estão contratando estrategistas de conteúdo. Alguns exemplos:

Estratégia de Conteúdo: Produtos de Trabalho (ou Entregas)

Os Produtos de Trabalho (ou Entregas) típicos de Estratégia de Conteúdo são diversos e dependem das necessidades da empresa e do know-how do estrategista de conteúdo. Shelly Bowen diz:

Alguns estrategistas de conteúdo também são (no fundo) escritores, editores, designers ou arquitetos de informação. Esse background influencia não apenas a estratégia, mas, também, as Entregas.

A mesma Shelly Bowen também indica esta lista Estregas como guia:

O que se quer alcançar?

• Resumo dos objetivos da empresa

O que se tem?

• Inventário de Conteúdo ou Auditoria
• Avaliação de Conteúdo (qualidade e quantidade)

O que está faltando?

• Análise de lacunas de conteúdo
• Análise comparativa de conteúdo
• Análise competitiva

Como apresentar as palavras?

• Personas
• Cenários (pense em histórias verossímeis)
• Estratégia Editorial
• Estratégia de mensagens
• Conteúdo de amostra
• Modelos de conteúdo
• Estratégia de SEO
• Estratégia de marca
• Estratégia de metadados
• Guia de estilo
• Glossário

Aonde se quer chegar?

• Estratégia de canais
• Estratégia de conversão/migração de conteúdo
• Esquema do Fluxo de Conteúdo
• Comunidade e Estratégia Social
• Recomendações de visual
• Wireframes

Como fazer acontecer?

• Workflow da aprovação de conteúdo
• Planos de comunicação
• Políticas de moderação comunitárias
• Oficinas e workshops de produção de conteúdo
• Revisão de fornecedores de conteúdo e planos (pessoas, ferramentas, orçamento, tempo)

Como se manter organizado?

• Requisitos de CMS
• Regras de Negócio
• Taxonomias
• Responsabilidades
• Horários

Como saber se se está correto?

• Requisitos de CMS
• Testes de usabilidade
• Benchmarks
• Resumo dos objetivos da empresa
• Métricas de sucesso

O que vem a seguir?

• Calendário Editorial

Aqui está algumas ideias e exemplos concretos de aplicação de Estratégia de Conteúdo, mostrados por Colleen Jones.

Modelos e Guias para download

A seguir, alguns recursos de Estratégia de Conteúdo, fornecidos por Kevin P. Nichols.

• Inventário/Auditoria de Conteúdo (.xls)
• Matriz de Mercado de Conteúdo(.xls)
• Matriz de Conteúdo(.xls)
• Guia de Protocolo de Estado Atual de Stakeholder(.pdf)

Leitura Complementar

Blogs sobre Estratégia de Conteúdo

• Brain Traffic
• Content Insights
• Eat Media
• Notes on Content
• Pybop
• Scatter Gather

Livros sobre Estratégia de Conteúdo

• Clout: The Art + Science of Influential Web Content
• Content Strategy for the Web
• The Elements of Content Strategy
• The Web Content Strategist’s Bible

Artigos e publicações importantes

• Margot Bloomstein; “The Case for Content Strategy – Motown Style“, A List Apart, 18 ago 2009.
• Kristina Halvorson; “The Discipline of Content Strategy“, A List Apart, 16 dez 2008.
• Colleen Jones; “Make Your Content Make a Difference“, Smashing Magazine, 12 abr 2011.
• Colleen Jones; “Toward Content Quality“, UXmatters, 13 abril 2009.
• Matt Kinsman; “From Editor to ‘Content Strategist:’ Semantics or Fundamental Change?“, Folio, 1 jul 2008.
• Fred Leise; “Content Analysis Heuristics“, Boxes and Arrows, 26 February 2007. 12 mar 2007.
• Rachel Lovinger; “Content Strategy: The Philosophy of Data“, Boxes and Arrows, 26 fev 2007.
• Jeffrey MacIntyre; “Content-tious Strategy“, A List Apart, 16 dez 2008.
• Jeffrey MacIntyre; “The Next Big Headache for Digital Publishers“, PaidContent, 6 ago 2009.
• Karen McGrane; “Content Strategy: Content Is King!“, From Business to Buttons, 11 jun 2009.
• Peter Merholz; “The Marginalization of Content“, adaptivepath.com, 22 maio 2008.
• Kaitlin Pike, “Why You Need to Hire a Content Strategist“, Web 2.0 interview with Margot Bloomstein, 7 jul 2010.
• Theresa Putkey; “Exploring the Content Strategist Title“, Boxes and Arrows, 22 maio 2007.
• Erin Scime; “The Content Strategist as Digital Curator“, A List Apart, 8 dez 2009.

Conclusão

No Brasil, pouco se tem falado a respeito, mas, como pôde ser visto no artigo, Content Strategy, apesar de ser uma área de atuação relativamente nova, já conta com uma excelente bagagem advinda de outras áreas de conhecimento e muito, muito conteúdo para ser estudado e aprendido.

A entrada de cada vez mais empresas no ambiente digital, aliada à necessidade das que já estão em aprimorar sua presença e atuação, certamente o estrategista de conteúdo começará a ser um profissional bastante requisitado e, não duvide, será um elemento-chave para o meio online futuro.

Assim como hoje não é sequer imaginável um projeto web sem alguém com conhecimentos de Usabilidade, Design e Programação, brevemente o mesmo acontecerá para a Estratégia de Conteúdo.

Artigos Relacionados

• Problemas comuns de WordPress e como resolvê-los
• Microdata API e Schema.org: dando significado ao HTML
• JSON – JavaScript Object Notation
• Cores na web: guia completo
• URLs longas apresentadas corretamente com CSS
• Novas tecnologias exigem novas maneiras de se comunicar
• Erros comuns em desenvolvimento web para campanhas de SEO
• URLs amigáveis (slug) à WordPress
• 15 fantásticos comandos SQL para WordPress
• Breadcrumbs: guia completo com exemplos e melhores práticas

Se você é um desenvolvedor iniciante, pode ser confuso sobre onde você deve começar no mundo do desenvolvimento web, já que o ramo é amplo e oferece muitas opções de escolha. Há muitas perguntas a serem feitas, tais como “Que linguagem de programação quero aprender?” ou “Eu deveria saber sobre front-end ou apenas back-end?”, e existem, literalmente, centenas de outras.

Mas, para que você não fique tão perdido, esta lista de 10 dicas que desenvolvedores web iniciantes devem saber realmente pode ajudá-lo a iniciar sua carreira como desenvolvedor ou, caso já tenha começado, pode servir de norte para você perceber se realmente escolheu a área certa ou se vai mudar.

Decida quais habilidades você quer

Ao iniciar na carreira de desenvolvedor web, você realmente precisa se concentrar em alguma coisa e aceitar o fato de que não é possível ser um “generalista”. Acredite: mesmo dando muita vontade de atuar em vários e vários campos do desenvolvimento web, isso é impossível! Além do mais, geralmente o mercado valoriza mais um expert numa área do que um “faz tudo web”.

Não há nada de errado em querer em ser excelente em vários campos, mas você realmente não poderá fazer isso no começo. O que você pode fazer é centrar seus esforços no aprendizado em uma habilidade e se tornar um perito nesse campo. Pode ser PHP, Ruby, ASP.net ou C #, mas tem que ser bom no que faz… Muito bom! Depois de dominar um deles, você pode seguir em frente, mas não faça isso até que você tenha grande conhecimento nesse campo.

Esta dica também é bom para front-end designers, que sempre começam com HTML e CSS, depois passam para JavaScript, jQuery, AJAX, ou quaisquer outros que estiverem interessados ​. Claro, é possível aprender HTML e CSS ao mesmo tempo, mas isso é porque eles meio que trabalham em conjunto. Você não pode realmente dominar PHP e ASP.net ao mesmo tempo – a menos que você gaste 20 horas de estudos por dia, o que, definitivamente, não é recomendado -, portanto, você tem que adquirir suas habilidades uma a uma.

Mas, já que você é um novato e, provavelmente, não deve saber muito sobre linguagens de programação hardcore, escolher uma área para começar pode ser complicado, mas há uma solução: pense no que você quiser desenvolver: se for temas para WordPress, então seu caminho é o PHP; se for sistemas de gestão personalizados, tente ASP.net; jogos de iPhone, aprender C# e assim por diante.

Basta pesquisar um pouco sobre o que cada linguagem pode fazer e começar a aprender. E, neste caminho, você certamente vai aprender que é possível fazer as mesmas coisas usando diferentes linguagens…

Aprenda direito

Outra dica para novatos é, independentemente da linguagem que você escolher, aprenda direito! Se você aprender HTML codificando layouts com tabelas, isso não é nada certo – e eu tenho certeza que outros especialistas concordam comigo. Codificar usando os mais recentes padrões da web parece inútil para alguns, mas é realmente importante e é altamente recomendado a aprender assim, já que isso não vai só melhorar a velocidade de carregamento de seus projetos, mas também será mais fácil e fará mais sentido.

Google é o seu melhor amigo

Realmente não importa que tipo de problema que você tem, estou certo de Google pode resolvê-lo (na maioria dos casos, pelo menos).

Fóruns de programação são altamente recomendados, também, mas, antes de postar uma pergunta em algum fórum, tente buscar uma solução no Google porque, na maioria das vezes, você vai encontrar uma resposta para sua pergunta – ou, pelo menos, uma resposta que irá guiá-lo para resolver a questão.

Analise o código alheio

Isso vale principalmente para designers, mas, às vezes, desenvolvedores têm conhecimentos de design de front-end e fazem seus próprios layouts antes de começar a codificá-los. É importante olhar outros sites para entender como eles são codificados. Se você gosta de algum estilo ou elemento de um site, olhe para o código fonte e o analise! O Firebug funciona maravilhosamente bem nestes casos. Esta é a maneira pela qual a maioria das pessoas aprende a codificar.

O que não é aconselhado é roubar o design do alheio. Isso é imperdoável e digno de um “Que deselegante!”, além de mostrar uma falta de respeito e tremenda falta de profissionalismo, mas, geralmente, a comunidade de desenvolvedores não vê maiores problema em “pegar emprestado” alguns trechos de código (caso isso não infrinja alguma lei ou patente, claro).

Portanto, fica a “regrinha”: você pode até copiar algum código aqui e ali – este é o caminho para aprender a fazer as coisas – mas nunca roube um design!

Entre numa rede de conhecimentos

Outra coisa importante é participar de uma rede dentro de seu campo de conhecimento. Nunca é demais conhecer outros desenvolvedores e designers. Um cenário não muito interessante é você ter que voltar trás e buscar coisas no Google; um cenário melhor é você ter discussões interessantes e poder obter ajuda através de discussões com pessoas da mesma área. Você pode até colaborar com seu colegas desenvolvedores em projetos maiores, o que, quase sempre, é bom para todos os envolvidos.

Você está perto de conseguir um projeto mas não tem certeza se você pode lidar com o tipo de trabalho solicitado? Recomende um de seus colegas desenvolvedores! Ele(s) provavelmente irá(ão) executar o trabalho melhor do que você – se for(em) especialista(s) nessa área específica – e você pode fechar algum tipo de parceria em algum momento futuro. Faça parte de uma rede e a mantenha ativa e sempre por perto. Há sempre a demanda por um desenvolvedor que esteja “ao redor”.

A própria ideia de tradução deste artigo surgiu no grupo de discussão html5-css3-brasil e viu como isso foi uma boa coisa?  ;-)

Entenda os designers

É altamente aconselhável que você compreenda os designers, caso não tem ideia de como eles trabalham. E isso vale tanto para designers gráficos quanto para front-end designers.

É sempre bom para aprender como eles trabalham e porque eles podem entregar páginas estáticas que realmente não correspondem aos mais recentes padrões da web. Aprenda a conversar com eles e explicar o que está errado e saber pedir para corrigir seus próprios erros. Dessa forma, sua relação de trabalho será mais próxima e o resultado bem melhor.

Use ferramentas profissionais

Apesar de HTML e CSS poderem ser feitos até com o Bloco de Notas, isso não é recomendado. E, se isso não é aconselhado para HTML e CSS, é igualmente desaconselhado para PHP, ASP.net ou Ruby. Trabalhe com ferramenta profissionais como Eclipse, Aptana, NetBeans ou outra qualquer, mas use o que os profissionais usam, caso contrário você não será um deles!

Esse tipo de ferramenta verifica erros, tem autocomplete e dá sugestões durante a codificação. Há uma razão pela qual Eclipse e NetBeans são 2 dos IDEs (Integrated Development Environment ou Ambiente de Desenvolvimento Integrado) mais usados no mundo: eles fazem o trabalho em grande estilo!

Então comece a trabalhar agora, mesmo, com alguma ferramenta profissional, caso ainda não o tenha feito!

Deixe as coisas legais por último

Cada linguagem tem a sua própria “versão cool”. Por exemplo, HTML tem HTML5, CSS tem CSS3, JavaScript e AJAX tem jQuery e assim por diante. É muito melhor se você aprender a linguagem básica e depois estudar mais até chegar no estágio cool. E, também, as coisas “cool” trabalham a partir dos elementos básicos, então você não será capaz de desenvolver e entender um controle deslizante com jQuery se você não compreender o JavaScript básico.

Mantenha-se informado e atualizado

É sempre bom se manter informado e atualizado sobre o que está acontecendo no mundo do desenvolvimento web, em especial da(s) área(s) que você atua. Você pode fazer isso através da leitura de feeds, livros “de verdade”, blogs e screencasts. Fique atualizado e certifique-se de que você é um dos primeiros a oferecer produtos desenvolvidos com a tecnologia mais recente.

No começo, pode não funcionar muito (as pessoas podem querer manter o “velho” até que as novas tecnologias mostrem seu valor), mas, certamente, também há aquelas pessoas que querem ter um produto totalmente novo, desenvolvido com as mais recentes tecnologias – e isto lhe dará uma vantagem e fará você conhecido no ramo.

Continue com o processo de aprendizagem

Depois de se tornar um especialista no campo que escolheu, trilhe seu caminho rumo ao aprendizado de outras linguagens e/ou áreas de atuação. Fique de olho aberto nas linguagens mais importantes e aprenda aquelas que julgar serem as mais interessantes. Quando você domina duas, vá para a terceira e assim por diante.

E continue até  que não haja muito mais para aprender – embora, como já foi dito, isso seja impossível. Este é o caminho para o sucesso!

Conclusão

É bastante comum que desenvolvedores iniciantes passem por tempos difíceis neste campo profundo do desenvolvimento web, mas estas dicas servem justamente para ajudar que cada um encontre seu caminho.

Nem sequer importa muito por onde começar, tudo o que importa é você comece! Isso geralmente é o que leva mais tempo, então não desperdice estes dias preciosos e comece agora a estudar e a desenvolver a web!  ;-)

Artigos Relacionados

• Sobre parcerias de trabalhos em desenvolvimento web
• Quando o cliente (pensa que) sabe mais
• Web sites genéricos e a ilusão dos preços baixos
• Como montar um portfolio sem ter clientes
• Evitando erros comuns de HTML5
• Desenvolvedores front end e o mercado
• Não use IDs como seletores em CSS
• Elementos de design aplicados à web
• Wireframes para web: guia completo de desenvolvimento
• 10 erros básicos de web design

Otimizar códigos jQuery em um site significa aumentar sua performance. E, como qualquer desenvolvedor web deveria saber, os componentes e recursos do front-end são responsáveis por, pelo menos, 80% da performance de páginas web!

O jQuery, em relação a JavaScript “puro”, já é bem simples de se aprender e possui uma gama de recursos incrível! Entretanto, principalmente quem está começando e/ou ainda não entendeu bem a dinâmica da biblioteca, desconhece alguma dicas simples que, se aplicadas, garantem que o desempenho seja aumentado escrevendo menos código! É isso que vamos ver neste artigo e aprender como melhorar códigos jQuery para conseguir um desempenho melhor.

Otimização de seletores

Para começar, vejamos como é possível otimizar os seletores no jQuery, otimizando as consultas realizadas e aumentando a performance do código.

Velocidade de seletores

Muito do poder do jQuery vem de sua capacidade de selecionar elementos DOM e agir/interagir com eles através de seus selectors e, através deles, o jQuery provê uma tonelada de maneiras de escolher qual(is) elemento(s) em uma página se quer trabalhar. No entanto, um número surpreendente de desenvolvedores web não sabe que os seletores não são todos iguais e que é incrível a diferença de desempenho entre 2 seletores que, à primeira vista, parecem quase idênticos.

Como exemplo, vejamos 2 maneiras de selecionar todas as tags de parágrafo dentro de uma div com id específico:

$('#id p');

$('#id').find('p');

É surpreendente o fato de que a segunda maneira pode ser 2 vezes mais rápida!

Há muitas maneiras diferentes de selecionar elementos usando jQuery; estas podem ser (virtualmente) divididas em 5 diferentes métodos. Em ordem, do mais rápido para o mais lento, são:

• $('#id'). Sem dúvidas, este é o selector mais rápido, já que mapeia diretamente o document.getElementbyId() nativo do JavaScript. Sempre que possível, os seletores descendentes devem ser feitos com um seletor de ID conjuntamente ao método .find(), que limita o escopo do que está sendo pesquisado (tal como no exemplo $('#id').find('p') anterior).
• $('p'), $('input'), $('form'), [...]. Selecionar elementos pelo nome da tag também é rápido, já que mapeia diretamente para o método nativo document.getElementsByTagname().
• $(".class"). Selecionar por nome de classes é um pouco mais custoso. Enquanto isso é executado muito bem por navegadores modernos, pode ser que uma lentidão seja causada em versões do IE baixo da 9. Por quê? Porque o IE9 foi a primeira versão do Internet Explorer a dar suporte para a função document.getElementsByClassName(), nativa do JavaScript. Para interpretar isso, browsers mais antigos têm de recorrer ao usos de artifícios bem mais custosos, que realmente afetam o desempenho do seletor.
• $('[attribute="value"]'). Não há nenhum método JavaScript nativo para este tipo seletor, então, a única maneira que pode realizar essa busca, é procurar por todo o DOM em busca de combinações que satisfaçam à condição do seletor. Navegadores modernos que suportam o método querySelectorAll() terão um desempenho melhor em certos casos, mas, em geral, este tipo de seletor é bastante lento.
• $(':hidden'). Assim como o caso anterior, não existe um método JavaScript nativo para usar este tipo de seletor. Pseudo-seletores podem ser extremamente lentos, já que a consulta tem que ser executada em cada elemento da página. Novamente, navegadores modernos que suportam o método querySelectorAll() se saem ligeiramente melhores, mas tente evitar este tipo de seleção. Se realmente for necessário, é possível amenizar um pouco usando o .find(), como visto anteriormente. Por exemplo: $('#list').find(':hidden').

Encadeamento

Quase todos os métodos jQuery retornam um objeto jQuery. Isto significa que, quando um método é executado, seus resultados são retornados e é possível continuar a implementação de mais métodos em sequência, o que é conhecido como encadeamento ou chaining. Ao invés de escrever o mesmo seletor várias vezes, esta característica da biblioteca permite que várias ações possam ser executadas de uma vez.

Sem encadeamento:

$('#object').addClass('active');
$('#object').css('color','#F0F');
$('#object').height(300);

Com encadeamento:

$('#object').addClass('active').css('color','#F0F').height(300);

Isto tem um duplo efeito ao tornar seu código mais curto e mais rápido. Métodos encadeados são executados mais rapidamente do que vários métodos de um seletor em cache e, de ambos os jeitos, são muito mais rápidos que vários métodos através de seletores sem cache. Mas, esperem… “Seletor em cache”? O que é isso?

Seletores em cache

Outra maneira fácil de melhorar a performance do código jQuery – e que parece ser um mistério para a maioria dos desenvolvedores – é a ideia de fazer cache de seletores. Pense em quantas vezes você acaba escrevendo o mesmo seletor em seus códigos. Cada $('.element') tem que varrer todo o DOM procurando por combinações o tempo todo, independentemente se este seletor tenha sido executado antes. Executando a seleção uma vez e depois guardando o(s) resultado(s) em uma variável, significa que a busca no DOM tem que ser feita apenas uma única vez. Uma vez que os resultados de um seletor tem sido armazenada em cache, é possível fazer qualquer coisa com eles.

Primeiro, executa-se o seletor desejado (como exemplo, pegar todos os li dentro de uma ul de id “blocks”):

var blocks = $('#blocks').find('li');

Agora, é possível usar a variável blocks em qualquer lugar que se queira, sem ter que percorrer todo o DOM novamente em cada vez:

$('#hideBlocks').click(function(){
    blocks.fadeOut();
});
$('#showBlocks').click(function(){
    blocks.fadeIn();
});

Portanto, fica essa preciosa dica: qualquer seletor que é executado mais de uma vez deve ser armazenado em cache! Veja este teste no jsperf que mostra o quão mais rápido e eficiente é um seletor cacheado em detrimento a um não cacheado.

Delegação de Evento ou Event Delegation

Event listeners consomem memória. Em sites e aplicações complexos não é incomum ter um monte de event listeners implementados e, felizmente, jQuery fornece métodos realmente fáceis para umaa gestão eficiente event listeners através da delegação.

Num exemplo extremo, imagine uma situação em que uma tabela 10×10 precisa ter um event listener em cada uma de suas células para que, quando ocorrer um clique em alguma delas, seja adiciona ou removida uma classe que define a cor de fundo da respectiva célula. Uma maneira comum de implementar isso (e algo bastante comum de ser visto em códigos jQuery) é:

$('table').find('td').click(function() {
    $(this).toggleClass('active');
});

O jQuery, a partir de sua versão 1.7, passou a oferecer um novo método de escuta de eventos: .on(). Ele age como um utilitário que envolve todos os event listeners anteriores do jQuery em um único e conveniente método e a forma que ele é implementado determina como ele se comporta. Ao reescrever o exemplo acima usando .on(), tem-se o seguinte:

$('table').find('td').on('click',function() {
    $(this).toggleClass('active');
});

Bastante simples, certo? Mas o problema aqui é que, mesmo com a mudança, o código ainda conta com um event listener para cada célula da tabela… Uma maneira muito melhor de fazer isso funcionar é criar um único event listener para monitorar os eventos na própria tabela! Uma vez que a maioria dos eventos faz bubbling (vai percorrendo seus ancestrais em sequência) na árvore do DOM, é possível vincular um único listener para um elemento (neste caso, table) e esperar eventos serem disparados a partir de seus descendentes. A melhor maneira de fazer isso usando o .on() é:

$('table').on('click', 'td', function() {
    $(this).toggleClass('active');
});

Com essa mudança simples, o número de event listeners passou de 100 (10×10 células da tabela) para 1! Acredite: a diferença de performance entre os 2 exemplos acima é impressionante!

Se você está usando alguma versão do jQuery abaixo da 1.7, é possível fazer a mesma coisa usando .delegate(). A sintaxe é diferente, mas uma consulta à documentação vai esclarecer as coisas.

Manipulação de DOM

Com jQuery é fácil de manipular o DOM. É trivial criar novos nós, inserir, retirar outros, mudar as coisas ao redor e assim por diante. o código para fazer isso é simples de escrever, mas, toda vez que o DOM é manipulado, o navegador tem que revisar o DOM, o que pode ser muito custoso e impactar a performance do front-end. Um exemplo evidente em que isso acontece é em um loop longo, seja através de um loop for(), while() ou $.each().

Como exemplo, vamos supor que existe um array cheio de URLs de imagens de um banco de dados ou alguma chamada em AJAX e, o que se pretende, é colocar todas essas imagens numa lista não ordenada. Comumente, o código que se encontra para isso é:

var arr = [reallyLongArrayOfImageURLs];
 
$.each(arr, function(count, item) {
    var newImg = '<li><img src="' + item + '"></li>';
    $('#imgList').append(newImg);
});

Existem alguns problemas com isso. Para começar, há a seleção de $('#ImgList') em cada iteração do loop – e, como vimos anteriormente, isso não é nada bom para a performance. O outro problema é que, a cada vez que o loop repete, é adicionado um novo li ao DOM. Cada uma dessas inserções consome recursos e, se o array é muito grande, isso poderia levar a uma grande perda de performance ou, até mesmo, ao temido alerta “Um script desta página está tornando a página lenta”…

Uma outra maneira de implementar a solução é:

var arr = [reallyLongArrayOfImageURLs],
    tmp = '';
 
$.each(arr, function(count, item) {
    tmp += '<li><img src="' + item + '"></li>';
});
 
$('#imgList').append(tmp);

O que foi feito, aqui, foi a criação de uma variável tmp para receber cada li criado. Quando o loop termina, a variável contém todos os itens de lista na memória e estes podem ser anexados ao ul todos de uma vez! Como navegadores trabalham melhor com operações de objetos na memória ao invés de diretamente atualizando o DOM a cada vez, este código é bem mais rápido e eficiente!

Conclusão

Logicamente, estas dicas de como otimizar códigos jQuery para aumentar a performance do front-end não são as únicas existentes, mas, certamente, estão dentre as mais simples de implementar. Embora algumas das mudanças, individualmente, façam apenas alguns milésimos de segundo de diferença, ao somar isso, dependendo de sua aplicação, é possível ter um aumento de performance de quase 70%!

Estudos mostram que o olho humano é capaz de discernir delays de 100ms (!), portanto, fazer algumas mudanças no código pode, facilmente, ter um efeito notável sobre o modo (e a percepção) de quão bem um seu site ou aplicativo é executado.

E você, tem alguma outra dica de otimização de código jQuery para compartilhar? Comente!

Artigos Relacionados

• Como fazer loading em conteúdos do site
• 5 dicas para temas WordPress melhores
• Melhorando a interação em formulários de busca
• Textarea: dicas e truques que você sempre quis saber
• Ferramentas e recursos para desenvolvimento web
• 8 dicas para fazer códigos melhores com jQuery
• Truques de configuração do WordPress
• Pergunte-se a si mesmo: questões para desenvolver um bom site
• Dicas para otimizar códigos PHP
• Microdata API e Schema.org: dando significado ao HTML

O design é dividido em uma série de princípios básicos que se aplicam a todo o projeto, seja ele do “mundo real” ou do mundo virtual. No entanto, especialmente na web, às vezes essas regras tendem a ser esquecidas e nós apenas trabalhamos com o que sentimos ser o “certo”.

Em uma das séries do desenvolvimento para web foram abordados alguns dos principais estudos sobre Gestalt para web, e isso foi um grande passo sobre o que estamos tratando aqui, pois pudemos estudar como é a percepção e entendimento das pessoas no ambiente online. Agora, veremos alguns dos elementos de design aplicados à web.

Equilíbrio

Equilíbrio é um assunto complexo. Existem dois tipos de equilíbrio: equilíbrio simétrico e equilíbrio assimétrico. Quase todos nós estamos familiarizados com imagens simétricas. A maioria de nós, nos tempos de criança, provavelmente já fez algum tipo de recorte em papel de forma que o resultado final ficasse perfeitamente simétrico. Enquanto o equilíbrio simétrico é fácil de detectar (as coisas aparecem como imagens num espelho), o equilíbrio assimétrico é menos perceptível, mas, aparentemente, mais importante.

Subtraction: exemplo de Equilíbrio Assimétrico

A figura acima é um excelente exemplo de equilíbrio assimétrico (aplicado em vários lugares), especialmente a imagem do cachorro. Nesse exemplo P&B, a colocação do animal nessa posição deixa muito peso para o preto na metade esquerda da composição, que é equilibrada pelo aparentemente aleatórios “X” na parede, à direita (1). Esta pequena adição cria um senso de equilíbrio que quase faz você se sentir como se o cachorro esteja no centro da imagem, quando, na verdade, ele não está. Confira.

Enquanto a imagem do cachorro demonstra um equilíbrio gráfico há, também, algum equilíbrio assimétrico no cabeçalho do site (2). A barra de menu é bastante pesada, tanto em seu tamanho, quanto na cor. No entanto, a linha mais fina acima de “Subtraction” usa o espaço negativo acima e abaixo para criar um equilíbrio visual entre os dois. Então, a área em branco acima da barra de menu fica como mesmo peso visual que a barra de navegação preta mais abaixo.

Um desenho simétrico, apesar de ser um conceito extremamente simples, pode ser surpreendentemente poderoso.

Apple: exemplo de Equilíbrio Simétrico

Apple, uma das atuais referências de design, usa um layout completamente simétrico em sua página inicial (atualmente a página deles está diferente que a desse screenshot). Como você pode ver na imagem, cada elemento é correspondido do outro lado da linha, criando uma harmonia visual simples.

Proporção

Escolher o tamanho certo para os elementos vai além de simplesmente selecionar um tamanho legível para o corpo do conteúdo ou a largura das colunas. Deve-se levar em conta a proporção, que está entre o equilíbrio e dominância, baseados nas proporções de certos objetos. Se num site “tradicional”, por exemplo, com uma coluna maior para conteúdo e uma menor para menus e meta-informações, a coluna do conteúdo é maior justamente por ser mais importante. Se os menus e meta-informações fossem colocados na coluna principal, certamente a primeira reação dos visitantes será de pensar que a página não tem o conteúdo que estão procurando.

Enquanto algumas pessoas preferem usar grids com módulos fixos, outros preferem usar abordagens diferenciadas, tais como a usada aqui, no desenvolvimento para web – pelo menos na data de publicação deste artigo -, que tem como base a Proporção Áurea: a largura da coluna do conteúdo é, aproximadamente, 1,625 maior que a coluna da barra lateral.

A proporção também pode ser usado para, simplesmente, atribuir importância a elementos na página.

Elementos de design aplicados à web: proporção

Apesar de a página atual estar diferente deste screenshot, o pessoal da Panic fez um bom trabalho em usar elementos proporcionalmente dimensionados para atribuir não somente uma hierarquia visual, mas significado entre eles. Começando com o logo do produto (1), passando, mais baixo, para as três call to action (2) – que são ligadas por tamanho e aspectos relacionais, como os ícones à esquerda – e, finalmente, títulos e texto importante (3). Combinado com um design muito unificado, esta página é quase uma obra-prima da web (especialmente para os que adoram um javascript bem feito aplicado a user interfaces).

Ritmo

Ritmo na web é algo presente principalmente em dados. É especialmente importante para sites que contêm páginas compridas e/ou grandes quantidades de informação. Este screenshot do Digg mostra que o site cai em ambas as situações e, também, é um excelente exemplo de ritmo através da repetição:

Digg: exemplo de Ritmo

O site cria um ponto de partida no cabeçalho com sua navegação horizontal estabelecendo a direção de leitura (1) para, logo em seguida, cair no conteúdo principal, que é idêntico para cada artigo. Isso cria um ritmo consistente que o usuário segue inconscientemente (2). Esta técnica é repetida na barra lateral.

Uma boa maneira de pensar sobre o ritmo no design está na mesma definição que vem à mente quando pensamos em música. Cada projeto tem um pouco de um “pulso visual” que, dependendo de onde você está na página, convida a uma leitura rápida, uma pausa numa imagem interessante ou a uma orientação para um botão de download.

Um site que é muito consistente no seu ritmo pode sofrer no fato de que todos os elementos na página acabam ficando com uma quantidade igual de peso ao redor, podendo deixar os visitantes ligeiramente desorientados. Muitas variações, por outro lado, podem fazer com que a página se torne um caos! O importante é estabelecer uma coerência dentro de certas seções do site, como demonstrado acima, no Digg: cada parte tem seu próprio ritmo interno, segundo seu propósito; mas, como um todo, a página inteira é unificada e tudo instantaneamente tem significado apenas com base na cor, forma e proporção.

Dominância (ou Ênfase)

Não há nada mais poderoso no design do que uma forma circular, especialmente em um mundo de retângulos, como a web. Um círculo chama a atenção simplesmente por sua forma. Ele não precisa ser especialmente vibrante em cores ou espaço em branco. E o melhor lugar para aproveitar todas essas boas características está no logotipo.

A List Apart: exemplo de Dominância

Como é possível ver na imagem, A List Apart está usando não um, mas um par de círculos para fazer a dominância ao seu logotipo (1). Isso é reforçado pelo símbolo com o número da edição, adjacente ao logo. Há, também, outros “selinhos” como esse usados ​​no lado direito (2) para chamar a atenção para algum ponto específico (no caso, venda de camisetas).

Outra forma de alcançar uma posição dominante é através do uso de espaço em branco e/ou cores. Estes podem ser combinados com uma forma dominante, mas, raramente, você sempre precisa combinar todos eles; um ou dois geralmente já é o suficiente.

Google: outro exemplo de Dominância

Google usa ambos, espaço em branco e dominância de cores, para puxar o olho para a área principal da página (1). O lúdico colorido do logotipo do Google, combinado com a quantidade de espaço em branco que envolve esta área, força de seu olho a se concentrar lá imediatamente. Embora o Google pode fornecer excelentes resultados para as buscas, a chave para seu sucesso na web é a sua facilidade de uso, que é naturalmente fácil de se usar devido a suas tendências visuais básicas.

Unidade

O conceito de unidade é muito mais aberto a interpretações. A unidade é, na verdade, um sentimento de que todos os elementos estão ligados, conectados de alguma forma, e isso dá uma ideia de um todo. Um grande exemplo de unidade é o portfolio de Dave Werner, no qual cada página do site apresenta escrita à mão, alfinetes e todo o tipo de outros elementos que, quando analisados em conjunto, produzem um sentimento de unidade. Não há nada que se sente estar fora do lugar e tudo compartilha o mesmo estilo:

Dave Werner: exemplo de Unidade

Mesmo pedaços do site que, como entidades separadas, naturalmente podem parecer diferentes umas das outras, são cobertas de notas e esboços, trazendo até mesmo esses aspectos do site para o portfolio. Não há nada no site que você não esperaria ver alfinetado num quadro de camurça de projetos!  ;-)

Conclusão

Embora ninguém vá se tornar um “guru do design” somente com essas dicas, certamente essas explicações e exemplos ajudam a conceber projetos de forma mais consciente, que podem impor a hierarquia visual necessária e realmente guiar os olhos do visitante através da página da maneira que planejada.

Sem este tipo de estudo (e o de Gestalt aplicado ao web design) esses elementos você não ganha nada além de muito trabalho e retrabalho em busca de uma solução visual que você sinta ser a certa ou a “bonita”. Os princípios, em si, são muito simples; o mais importante é estar ciente de que eles existem e, a partir de agora, começar a refletir sobre eles na hora dos projetos e partir para a prática que, como sabem aqueles que já sentem um pouco da experiência dos anos de trabalho na área, sempre recompensa com trabalhos cada vez melhores.

Artigos Relacionados

• Não use IDs como seletores em CSS
• Wireframes para web: guia completo de desenvolvimento
• 10 erros básicos de web design
• Erros comuns em desenvolvimento web para campanhas de SEO
• Estratégia Web de Pirâmide: guia para uma estratégia de web equilibrada
• Ferramentas para criação de wireframes
• 4 elementos de design para um bom call to action
• User Interface em dicas rápidas
• Como otimizar imagens para web: guia de otimização de imagens
• 8 características de User Interfaces (UI) de sucesso

Wireframes são uma das partes mais importantes de um projeto web, portanto, desenvolver wireframes para web sites é uma etapa que, mesmo frequentemente negligenciada, abandonada, mesmo, não o deveria ser.

Neste artigo, veja mais sobre a importância desta etapa do projeto web e conheça algumas diretrizes importantíssimas para se preparar wireframes de qualidade, que realmente façam a diferença na qualidade final e nível de profissionalismo e produtividade de seus web projects.

A maioria dos designers desenvolve wireframes para seus projetos, de uma forma ou de outra, mesmo que sejam apenas esboços rápidos na parte de trás de alguns papéis de rascunho. Wireframe é uma parte importante do processo de desenvolvimento web, especialmente para projetos mais complexos.

Por que fazer wireframes

Wireframes realmente são úteis quando você está se comunicando com clientes, pois lhes permite visualizar suas ideias mais facilmente do que quando você apenas as descreve verbalmente. Para casos em que o “cliente” é a próprio empresa em que se trabalha ou para quando se tratam de projetos pessoais, a afirmativa também é verdadeira.

Então, que esteja claro: desenvolver wireframes é realmente um passo necessário no processo de design! Mesmo se o site que se está projetando seja incrivelmente minimalista e simples, fazer o wireframe ajuda a esclarecer exatamente o que precisa ser feito nos diferentes tipos de página do projeto.

Ao dedicar tempo para criar, pelo menos, um wireframe simples, tenha certeza de que seu web design levará em conta todos os elementos das diferentes páginas que compõem o projeto e precisam ir para o design. Além disso, eles estarão posicionados na melhor localização a que o estudo destes elementos chegou.

Além disso, o processo de produção de wire frames é muito mais simples, fácil e barato de ser feito do que quando se “pula” essa etapa e se parte direto para o HTML/CSS: wireframes podem ser facilmente revistos, adaptados ou descartados.

Wireframes x Modelos x Protótipos

Wireframe, modelo (mockup) e protótipo são frequentemente usados ​​como sinônimos, mas são três coisas diferentes (embora, frequentemente, haja alguma sobreposição entre eles). Cada um tem um propósito diferente do outro e sua própria importância no processo de design:

• Wireframes. São “ilustrações básicas” da estrutura e componentes de uma página web. Geralmente são o primeiro passo no processo de design (depois da concepção mental, obviamente).
• Modelos. Geralmente focam sobre os elementos de design visual do site. São muitas vezes bastante próximos ou idênticos ao web design final efetivo e incluem todos os gráficos, tipografia e outros elementos da página. Mockups geralmente são apenas arquivos de imagem.
• Protótipos. São layouts semi-funcionais das páginas e servem para dar um preview de maior fidelidade do site real. Esta fase antecede a programação da lógica de negócios do site. Enquanto eles não podem ter toda a funcionalidade, eles geralmente dão aos clientes a capacidade de interagir com os elementos e simular a forma como o site irá, eventualmente, trabalhar. Protótipos podem ou não incluir elementos de design finalizado.

Em suma, o wireframe vêm em primeiro lugar, seguido do modelo (ou mockup) e, caso seja possível/viável, haverá inúmeros benefícios ao se fazer o uso de protótipo (às vezes chamado “wireframe funcional“).

Como criar wireframes

Criar wireframes é tão simples ou tão complicado quanto você queira. Em sua forma mais básica, um wireframe poderia ser nada mais do que um esboço numa folha de papel. Outros “wireframes” são criados digitalmente e são realmente mais como protótipos, com objetos clicáveis ​​e toda a interatividade prevista.

O tipo de wireframe que será criado vai depender do que o projeto demanda. Projetos mais complicados provavelmente requerem wireframes mais elaborados, enquanto sites simples pode ter wireframes simples.

O que incluir em um wireframe

Os wireframes devem incluir informações suficientes para refletir o que precisa aparecer em cada página do projeto web. Pense sobre os elementos gerais da maioria das páginas web: cabeçalhos, rodapés, barras laterais, áreas de conteúdo, meta-informação, busca, widgets, gráficos, etc. Depois de ter uma idéia do que terá o site, comece a criar os wireframes com base nesses elementos.

O quão detalhado deve ser o wireframe também depende do projeto e de sua finalidade. Se o wireframe servirá apenas como um documento orientador para referência, então talvez não seja uma boa ideia dar muito foco nesta etapa; por outro lado, se ele vai ser usado por mais de um designer ou desenvolvedor – ou apresentado a clientes – então ele precisa ser melhor trabalhado.

Wireframes de baixa fidelidade x Wireframes de alta fidelidade

Existem algumas opções quando se trata do “estilo” de wireframes. Alguns designers optam por wireframes de baixa fidelidade , que são basicamente linhas sobre um fundo liso com alguns rótulos. Estes incluem tanto os desenhados a mão, como wireframes digitais, e são geralmente muito simples.

Wireframe de baixa fidelidade

Wireframes de alta fidelidade vão um passo além ao usando determinados elementos de design dentro do próprio wireframe. Isto pode incluir o logotipo ou alguns outros elementos gráficos básicos, bem como o esquema de cores e outros elementos visuais de design.

Wireframes assim começam a se aproximar do nível de modelos, mas eles podem ser inestimáveis ​​para transmitir uma sensação de como o site será, especialmente para os casos em que se tem dificuldade em vislumbrar como o site será ao ver wireframes de baixa fidelidade.

Técnicas para fazer wireframes

Existem dezenas de maneiras diferentes para criar wireframes que vão desde simples – caneta e esboços em papel –  a diagramas mais complexos – que parecem quase tão eficientes quanto sites em produção.

Existem, também, abordagens diferentes para o propósito e o raciocínio por trás da criação de wireframes, dependendo das necessidades do projeto e dos designers envolvidos nisto.

Aqui estão alguns recursos sobre diferentes procedimentos para a criação de wireframes para web (em inglês):

• Wireframes com InDesign e Illustrator. Esse é um artigo da  UXmatters sobre como criar wireframes usando Adobe InDesign e o Illustrator. Eles falam sobre o que o levou até a decisão de usar o InDesign e o Illustrator em detrimento a outros outros produtos até chegar na parte sobre como usar esses 2 aplicativos para criar wireframes.
• Método Caixa Cinza. Jason Santa Maria tem um post fantástico sobre o “Método Caixa Cinza” de criação de wireframes. Ele descreve seu processo inteiro de criação de wireframes, desde esboçar no papel até criar uma escala de cinza no Illustrator. Artigo com vários exemplos.
• O Futuro dos Wireframes. Inclui informações valiosas sobre processos e métodos de criação de wireframes, especialmente em termos de como fazer o processo de wireframe melhor para designers, desenvolvedores e proprietários de sites.
• 20 Passos para Fazer Wireframes Melhores. Este artigo estabelece 20 passos sobre o que você deve fazer para criar wireframes melhores. É um post fantástico para verificar se você é completamente novo na arte de fazer wireframes ou apenas infeliz com o seu processo atual.

Processo do wireframe

Existem muitas variações, mas há um punhado de passos fundamentais para a criação de um wireframe. É provável que você comece com uma lista de coisas que o site precisa incluir ou um documento de especificação formal de design. Outros já gostam de começar com um “olhar geral” do design e ir acrescentando detalhes, uma vez que se tem os fundamentos básicos do layout.

Quer você decida rabiscar algumas coisas no papel ou trabalhar com algum software, ainda não descarte um ou outro método. Alguns designers fazem esboços no papel e depois os passam para software específicos; outros vão direto para o software; outros ainda ficam somente no “wireframe de papel”. Tenha em mente que, caso se depare com algum “entrave criativo”, mudar os formatos com que se trabalha pode fazer maravilhas para sua criatividade!

É muito comum experimentar várias idéias e possibilidades diferentes com wireframes antes de tomar decisões finais em um projeto. Aliás, é justamente para facilitar/agilizar isso que é muito bom trabalhar com wireframes, já que, como se tem o mínimo de tempo e energia investidos, é possível facilmente fazer alterações e tentar coisas novas.

Uma vez que um wireframe básico é criado, você pode enviá-lo para outros membros da equipe para análise ou colocá-lo um pouco de lado por 1 ou 2 dias para analisar novamente. Quando estiver satisfeito, é hora de mostrá-lo ao cliente ou, caso não seja o caso de haver um cliente, começar a trabalhar em modelos baseados no wireframe.

Ferramentas para criar wireframes

Existem muitas ferramentas para wireframe disponíveis. Algumas são feitas especificamente para wireframes, enquanto outros são mais gerais, apesar de cumprirem bem seu papel quando trabalho é esse.

As ferramentas que você vai usar vão depender de preferência pessoal e dos requisitos do projeto. Não há “melhor” ferramenta para fazer wireframes, mas sim aquela na qual você se sente melhor usando e que funciona melhor para você.

Papel e caneta

Caneta (ou lápis) e papel são as ferramentas mais básicas que você pode usar para criar um wireframe. Também é útil usar papel quadriculado para criar elementos em proporção.

Você pode querer usar um lápis para o seu esboço inicial, para que você possa apagar as coisas sem ter que começar de novo. Então, a medida que for finalizando os elementos, pode passar caneta por cima para evitar apagar o que não precisa mais ser apagado.

Você também pode considerar usar canetas coloridas (ou lápis coloridos) para diferenciar elementos e dar mais sentido ao wireframe. Por exemplo, uma cor para um grupo de elementos pode ser útil, pois ajuda a identificar instantaneamente outros itens.

Wireframe com papel e caneta em papel quadriculado

Programas para criação de wireframes

Existem diversos programas para criar wireframes disponíveis no mercado. Alguns são pagos, outros de graça, outros mais completos e alguns nem tanto; mas todos com o objetivo de ajudar na criação de wireframes para facilitar e agilizar o processo de desenvolvimento web.

Recomendamos fortemente que dê uma lida no artigo “Ferramentas para criação de wireframes“. Lá você vai encontrar uma boa lista com os principais programas para criação de wireframes com descrição e imagem de cada um.

Modelos para wireframes

Usar modelos (templates) para criar seus wireframes pode acelerar bastante o processo, especialmente se você optar por usar caneta e papel ou programas que são capazer de cumprir este propósito (como o Adobe Illustrator). Veja alguns bons modelos, kits e elementos de interface gratuitos para serem usados na elaboração de wireframes:

• Free Web UI Wireframe Kit. Fuel You Interface oferece, neste kit, diversos elementos para wireframes, tais como botões, breadcrumbs, caixas de diálogo, campos de busca e mais.
• Yahoo! Developer Network Design Stencils. Conhecidíssimo set de UI da Yahoo! para o desenvolvimento de wireframes. Eles disponibilizam os modelos para vários programas como OmniGraffle, Visio, Illustrator e Photoshop.
• Wireframe Symbols. Contém formas e elementos diversos, como botões, cabeçalhos, listas e tabelas para criar wireframes com o Illustrator.
• Free Sketching & Wireframing Kit. Conjunto de elementos para wireframe disponível em vários formatos de arquivo: Adobe Illustrator, SVG, PDF e EPS.
• Sqetch. Kit para Illustrator que inclui modelos e elementos, incluindo para iPad, elementos GUI e elementos de formulário.
• Dragnet Kit for Fireworks. Kit para Adobe Fireworks que inclui uma variedade de elementos da interface como botões, menus, combobox e abas.

Frequentemente esta lista com modelos para wireframes será revisada e novas fontes serão incluídas. Portanto, fique atento a este artigo para saber quando novos recursos forem disponibilizados.

Utilize wireframes para pensar o projeto

Wireframe manual

Trabalhar com wireframes pode ser uma ótima maneira de pensar o design de um projeto web sem gastar horas trabalhando em modelos no Photoshop ou codificando projetos preliminares. A flexibilidade dos wireframes permite trabalhar com diversas idéias de design e layout rapidamente e com pouco custo.

Dê uma olhada nos documentos de especificação de projeto; eles dirão quais elementos são necessários para o site. Em seguida, comece a organizar tudo em wireframes. Não tenha medo de tentar coisas não tradicionais nesta fase. Lembre-se: são apenas wireframes. Um erro ou uma tentativa fracassada neste momento, não definirá um fracasso ou fará com que você tenha muito retrabalho. Libere sua criatividade nesta fase!

Wireframes como resultado final do projeto

Apresentar wireframes para o cliente pode ser uma valiosa forma de se certificar de que todos estão em sintonia com o projeto antes de criar os modelos do projeto real. É muito mais fácil alterar a posição dos elementos quando você está trabalhando com wireframes do que quando está com o projeto no Photoshop ou páginas já codificadas.

Se for esse o caso, de haver a etapa de apresentação dos wireframes, isso também pode mostrar a habilidade do designer e agrega valor ao projeto, como um todo. Certifique-se, portanto, de que a etapa para criação, apresentação e aprovação dos wire frames constam no escopo do projeto – e isso acarreta em um impacto no tempo total, obviamente – e, por consequência, haverá um impacto no processo geral de design.

Wireframe em rascunho x Wireframe elegante

Um dos maiores considerações ao criar wireframes que será apresentado é a forma como eles devem parecer. Geralmente há duas formas de pensar sobre este assunto. Um ponto de vista sobre esta debate wireframe em rascunho contra wireframes elegantes (mais bem elaborados/apresentados) afirma que: tudo o que será apresentado a um cliente deve ser o mais polido e formalizado possível.

O outro ponto de vista argumenta que oferecer ao cliente um wireframe “polido” faz do cliente menos propensos a solicitar alterações, já que as coisas passam o sentimento de “finalizado”. Em outras palavras, wireframes em rascunhos dão mais margem para que o cliente não goste do resultado e/ou solicite mudanças. Há prós e contras em cada uma das abordagens.

Wireframes elegantes muitas vezes podem ajudar um cliente a visualizar melhor o layout do site e ter uma ideia melhor de como tudo vai funcionar e se parecer. Acrescentando coisas como cor ou gráficos você chega ainda mais perto deste objetivo. No entanto, você corre o risco de que seu cliente não oferece um feedback verdadeiro por sentir que a proposta já está “muito finalizada”.

Wireframe elegante

Por outro lado, wireframes em forma de rascunhos são mais como “idéias cruas” e parecem mais convidativos ao feedback do cliente. A desvantagem é que os clientes que não são particularmente orientados visualmente – ou que não têm familiaridade com o que wireframes são – podem ter dificuldade em imaginar qual realmente é a proposta e como o site irá se parecer no final de todo o desenvolvimento.

Recursos de wireframes

Para concluir este guia sobre desenvolvimento de wiframes, aqui estão diversos recursos na web dedicados ao design/produção de wireframes:

• I ♥ Wireframes Flickr Group. Milhares de wireframes para se ver e milhares de membros cadastrados colocando novos conteúdos com frequência.
• I ♥ Wireframes Tumblr. Excelente lugar para se ver muitos wireframes e se inspirar (é associado ao grupo do Flickr acima).
• Wireframe Showcase. Site que apresenta um “antes e depois”, mostrando wireframes com seus respectivos projetos finais. Excelente!
• Wireframes Magazine. Cobre todas as coisas relacionadas a wireframe, incluindo toneladas de stencils e modelos, bem como exemplos para inspiração.

Esta lista de recursos para wireframes será constantemente atualizada. Fique ligado!

Conclusões

Depois de acompanhar este guia completo de wireframes, é possível chegar a algumas conclusões importantes sobre o assunto.

Como o wireframe deve ser, depende do objetivo do projeto e/ou do perfil do cliente. Caso haja maior espaço para troca de ideias, opte pelo wireframes no estilo rascunho; caso apresente algo mais elegante, um wireframe melhor trabalhado – podendo até conter cores, gráficos, etc -, o impacto da apresentação é melhor, contudo, isso não abre tanto espaço para discussões, pois causa sentimentos de completude e imutabilidade.

De qual maneira se vai fazer os wireframes, também é algo opcional: há pessoas que preferem wireframes em papel e caneta; outros em programas de editoração de imagens; e ainda os que preferem programas específicos para construção de wireframes, modelos e protótipos. Mais uma vez, é você quem decide qual destes será melhor.

Deve haver, no projeto, a importantíssima etapa de elaboração de wireframes. É preciso que dentro do prazo – e orçamento – conste os períodos estimados para a feitura, edição, entrega, feedback e revisão de cada wireframe. É logicamente mais rápido, fácil e dispende menos recursos financeiros se alterar elementos num wireframe do que numa estrutura HTML/CSS já pronta.

Caso queira que seu projeto dispense retrabalhos e que possíveis mudanças sejam pensadas e mostras de maneira mais rápida, podendo ser feitas com um custo baixíssimo, então usar wireframes em seus projetos é de extrema importância!

Artigos Relacionados

• 4 elementos de design para um bom call to action
• User Interface em dicas rápidas
• Elementos de design aplicados à web
• 10 erros básicos de web design
• Melhores editores WYSIWYG para seu projeto
• Breadcrumbs: guia completo com exemplos e melhores práticas
• Diferenças entre IDs e Classes
• Evitando erros comuns de HTML5
• Não use IDs como seletores em CSS
• 10 dicas que desenvolvedores web iniciantes devem saber

Uma das principais áreas do desenvolvimento web é o web design. Ao se comunicar com outras áreas correlatas, é  através de um bom planejamento visual que o web design proporciona uma boa experiência visual ao visitante, garantindo que a qualidade do projeto web seja incrementada e esteja mais perto do sucesso!

O contrário disso é um web design que não consegue atender às necessidades do projeto e acaba por piorar a situação… Para corrigirmos um problema, é preciso conhecê-los antes; por isso, vamos a essa lista de 10 erros básicos de web design que você deve evitar!

Acredito que as pessoas têm tanta experiências em ver/analisar web design quanto é seu tempo de navegação na web. Eu poderia garantir que você vê mais web design ruim do que bom. Eu também vejo dessa maneira: existe um monte de sites que tem web design ruim. A seguir, veja 10 erros básicos de web design para que você possa analisar e saber o que não deve fazer em seus sites!

Erro básico de web design 1: usar fontes ruins

Sabe quando você visita um site com com uma fonte tão estranha ou extravagante que fica muito difícil de ler? Determinadas fontes “extravagantes” não devem ser usado no corpo do texto, caso contrário, o leitor não será capaz de ler e/ou a leitura ficará tão cansativa a ponte de fazer com que esse visitante desista da leitura e abandone o site.

Use fontes que são fáceis de ler!

Outro erro é que algumas pessoas usam fonte não-padrão em seus sites. Se o seu leitor é apenas uma pessoa comum que não têm tantas fontes adicionais instaladas, ele vai se confundir e dizer: “Por que é que o tamanho da fonte deste site é tão pequena?”. Infelizmente, isso faz as pessoas se queixarem sobre o site. Basta usar font comuns como Arial, Helvetica, Verdana, Georgia, ou Times New Roman, que a grande maioria tem em seu computador.

Erro básico de web design 2: não usar imagens, apenas texto puro

Acredite, as pessoas vão ficar entediadas se veem apenas texto e deixarão seu site uma vez que estão cansados ​​de ler um oceano de palavras… Isso é internet, não um livro de auto-ajuda. Se você não tem idéia sobre que imagem você deve colocar, basta usar qualquer imagem relacionada com o título do conteúdo. Evite deixar o “corpo” do texto sozinho, sem qualquer imagem.

Obviamente que existem algumas (que podem ser consideradas) exceções, como manuais técnicos, sites com tutoriais específicos e afins. Mas, ainda nestes casos, sempre que possível é interessante inserir algumas imagens/ilustrações contextualizadas.

Erro básico de web design 3: textos longos sem parágrafos

Mesmo que você tenha inserido imagens no conteúdo de seu site, é importante lembrar de separar as coisas usando parágrafos. Imagine que você está lendo um artigo com mais de 500 palavras sem qualquer parágrafo. É cansativo e pode ser confuso! Com algumas frases separadas por parágrafos, as pessoas conseguirão ler seus conteúdos com mais facilidade.

Mas acho que todos que cursaram o primário já sabem disso, não é?  ;-)

Erro básico de web design 4: fonte muito pequena

Alguma vez você já visitou um site e você teve que ampliar o tamanho da fonte através de recursos do navegaor para ler o conteúdo? Isso é ruim. Faça com que seu texto tenha um tamanho equivalente de, pelo menos, 12pt, para se certificar de que o conteúdo será legível o suficiente. Se não, as pessoas terão que apelar para ferramentas de terceiros e, certamente, podem querer ir para um site que não tenha o mesmo problema…

Adicionalmente, você pode fornecer aos visitantes uma ferramenta simples para controle do tamanho da fonte. Com isso, mesmo usando o texto com um tamanho mínimo aceitável, os visitantes que, mesmo assim, quiserem algo maior, terão essa possibilidade de personalização e facilitação de sua leitura.

Erro básico de web design 5: flash muito pesado

Quando se opta por utilizar Flash em um site, geralmente o objetivo é agregar valor à percepção visual dos visitantes. Infelizmente, o uso do flash faz com que o site seja mais lento para abrir e aumenta as chances de os visitantes deixá-lo rapidamente. Reduza o uso de Flash, a menos que seja extremamente necessário para alguma função específica.

Assim que o HTML5 ficar mais madura e amplamente utilizado, provavelmente esta dica ficará obsoleta.

Erro básico de web design 6: texto por cima de background coloridos

A maioria dos web sites usam backgrounds de cor única para melhorar a legibilidade. Se você pensa que usar fundo colorido vai tornar as coisas melhores e mais agradáveis, você está absolutamente errado! Isso só faz as pessoas ficarem cansadas de ler seu conteúdo, porque a cor do texto se mistura com o background.

Perceba que não há “proibições” em usar cores para o background, o problema está em usar patterns ou imagens sem tratamento algum que, inevitavelmente, fazem com que a experiência de leitura seja um desastre… Bom senso, pessoal!

Erro básico de web design 7: publicidade demais

Provavelmente você já deve ter visto sites cheio de banner e anúncios de publicidade, das mais variadas maneiras e possibilidades cabíveis. Você, mesmo, pode dizer o quão desagradável isso é, sem ninguém falar pra isso pra você. Jamais priorize anúncios em detrimento do conteúdo!

Bons web sites sempre colocam anúncios em lugares estratégicos de modo a não incomodar o visitante e não atrapalhar o conteúdo principal. Inspirar-se nos bons geralmente é uma boa estratégia.

Erro básico de web design 8: pop ups indesejados

Eu odeio (e tenho certeza de que você, também) sites com pop-ups indesejáveis! Eles realmente irritam! Eu quero olhar para a informação, mas o pop up interfere e faz com que eu perca meu tempo. Existe um motivo pra isso, claro, mas isso continua sendo um ato odiável…

Erro básico de web design 9: conteúdos muito extensos

Conteúdos (como artigos, por exemplo) muito extensos causam um efeito: geralmente as pessoas ficam entediadas para lê-los… Algumas pessoas apregoam a diretiva de que conteúdos devem ter, no máximo, 1000 palavras – com alguma adição de imagem para torná-lo mais atraente do que um texto simples. Pessoalmente, não sou muito apegado a números precisos e sim ao bom senso. Este artigo que você está lendo neste exato momento, por exemplo, tem mais de 1000 palavras mas, segundo o contexto em que está, não é cansativo.

O importante é fazer suas palavras simples e compreensíveis e ter em mente que a maioria das pessoas não gosta de artigos muito longos, mas que isso não é uma verdade absoluta e que esta “regra” pode ser “flexível”, dependendo do nicho a que o conteúdo está destinado.

Erro básico de web design 10: links invisíveis

Certifique-se de que a cor do link tenha uma cor diferente do texto simples. Simplesmente isso. Isso ajuda o leitor a identificar quais os links que visitaram e também o ajuda a não clicar nos links sem querer. Uma dica básica sobre boas user interfaces que é preciosa e não deve ser negligenciada.

Alguns ainda afirmar que a cor dos links deve ser diferente da cor dos títulos. Pessoalmente, não vejo muita necessidade para isso já que, teoricamente, a apresentação de um título é bem diferente da apresentação de um link textual. De qualquer forma, fica a seu critério.

Conclusão sobre erros de web design

Como vimos, estes são 10 erros básicos de web design que você deve evitar cometer em seus projetos web. Evidentemente, nenhuma das dicas aqui apresentadas são inflexíveis e/ou constituem-se verdades absolutas. Como já tivemos a oportunidade de ressalvar em diversos artigos aqui no desenvolvimento para web, no fim das contas, o que melhor guia seu projeto ao sucesso é o seu bom senso!

E você, apontaria mais algum erro básico de web design? Comente!

Artigos Relacionados

• Elementos de design aplicados à web
• Wireframes para web: guia completo de desenvolvimento
• Rolagem com fundo transparente com CSS
• 7 ferramentas para web designs melhores
• 4 elementos de design para um bom call to action
• User Interface em dicas rápidas
• Diferenças entre IDs e Classes
• CSS float: considerações, dicas e macetes para bons layouts na web
• Gestalt aplicado ao design web (parte 6): princípio da experiência passada
• Gestalt aplicado ao design web (parte 5): exemplos web do princípio do alinhamento

Já não é nenhuma novidade no mundo de desenvolvimento web o uso e abuso da tecnologia JSON. Entretanto, nem todos conhecem este padrão de intercâmbio facilitado de dados entre aplicações. Não é obrigatório, mas saber JSON pode ser bastante útil em projetos um pouco mais sofisticados e/ou que necessitam de uma demanda/política de transferência de dados mais simples, leve e eficiente.

Usar JSON proporciona inúmeras vantagens ao desenvolvedor web. Desde a simplicidade em tratar os dados à maneira fácil como é possível integrar tecnologias client-side com server-side, o JSON certamente é bastante recomendado.

O que é e para que serve JSON

JSON é o acrônimo para “JavaScript  Object  Notation“. Como é possível notar pelo nome, originalmente o JSON foi concebido para se trabalhar com javascript, mas, já adiantando, não é necessariamente obrigatório o uso de javascript para seu uso, dado que, atualmente, é possível utilizar JSON com mais de 20 linguagens de programação diferentes.

Uma definição interessante é a do Wikiédia:

JSON (com a pronuncia djeisón), um acrônimo para “JavaScript Object Notation”, é um formato leve para intercâmbio de dados computacionais. JSON é um subconjunto da notação de objeto de JavaScript, mas seu uso não requer javascript, exclusivamente.

O formato JSON foi originalmente criado por Douglas Crockford e é descrito no RFC 4627. O media-type oficial do JSON é application/json e a extensão é .json.

Mas uma definição que explica, de forma bem mais simples e objetiva, é a de Tiago Belem, em seu artigo “Introdução a JSON e PHP“, no qual consta que

JSON é um padrão de formatação de dados que serão transmitidos entre duas aplicações de linguagens diferentes.

Quer dizer, JSON é usado, principalmente, para permitir a troca de dados entre linguagens. Mas não só isso, ele também é ótimo para lidar com webservices e tem muitos outros usos.

Vantagens em se usar JSON

A descrição de dados em JSON é bem fácil, não passando de um documento de texto puro disposto em um padrão simples. Conforme foi explicado, JSON é excelente para intercâmbio de informações entre aplicativos.

Mas também existem outras maneiras de se fazer isso, por exemplo, com XML. Entretanto, o JSON apresenta vantagens bastante interessantes, o que, após uma análise do caso de seu aplicativo ou sistema web, pode levá-lo a optar por ele. Algumas das vantagens são:

• Sintaxe simples, de fácil aprendizado e implementação;
• Tamanho do arquivo bem menor em relação a outras “linguagens intermediárias”, tais como XML;
• Facilidade de desenvolvimento e alto desempenho nas aplicações que o utilizam.

Estruturas JSON

É possível ver alguns diagramas das estruturas no próprio site oficial do JSON; basicamente, é o seguinte:

Vamos ver, então, como podemos descrever dados simples usando o que a sintaxe que ele nos oferece.

Arrays

Por exemplo, vamos ver como seria um array dos dias da semana:

["Domingo", "Segunda", "Terça", "Quarta", "Quinta", "Sexta", "Sábado"]

Perceba que strings devem ser indicadas com aspas duplas.

Elementos separados por vírgulas entre colchetes é a notação JSON para um array (naturalmente, a vírgula delimita cada item). A maioria dos desenvolvedores prefere identar um pouco o código para facilitar a leitura:

[
	"Domingo",
	"Segunda",
	"Terça",
	"Quarta",
	"Quinta",
	"Sexta",
	"Sábado"
]

É possível, também, misturar diversos tipos de dados em um só array:

[
	33,
	"Segunda",
	TRUE,
	3.14159265,
        NULL,
        "maçã"
]

Objetos

Como vimos, arrays são representados por colcechetes. No caso de objetos, estes são representados por chaves; cada chave é identificada por uma string e, depois de um dois-pontos, os valores de cada item especificados. Fica mais claro com um exemplo:

{
	"Domingo" : "Folga",
	"Segunda" : "Viagem",
	"Terça"   : "Pagamentos",
	"Quarta"  : "Piscina",
	"Quinta"  : "Churrasco",
	"Sexta"   : "Carteado",
	"Sábado"  : "Festa"
}

Perceba que não tem importância haver espaços a mais ou a menos entre a descrição da chave, o separador “:” e o valor desta. Tudo será interpretado corretamente.

Alguns exemplos

É bastante simples descrever JSON, você viu. Como os objetos de qualquer outra linguagem de programação, é possível armazenar quaisquer tipos de dados e quantos dados se desejar. Veja este exemplo:

{
    "Marconildo":
    {
        "url": "http://www.marconildo.com.br/",
        "idade": 34
    },
    "Joanorta":
    {
        "url": "http://www.joanorta.com.br/",
        "idade": 22
    },
    "Estripafurgia":
    {
        "url": "http://www.estripafurgia.com.br/",
        "idade": 47
    }
}

Perceba que, neste caso, cada objeto possui, “url” e “idade” (provavelmente este não seria um exemplo “da vida real”, mas dá para ilustrar bem o conceito), mas, não necessariamente, todos devem possuir o mesmo número de propriedades. Poderia haver um ou mais elementos com “url”, “idade”, “altura”, “endereco”, etc. É possível, inclusive, a utilização de arrays:

{
    "Marconildo":
    {
        "url": "http://www.marconildo.com.br/",
        "idade": 34
    },
    "Joanorta":
    {
        "url": "http://www.joanorta.com.br/",
        "idade": 22
    },
    "Estripafurgia":
    {
        "url": "http://www.estripafurgia.com.br/",
        "idade": 47,
    	"diasDeTrabalho":
	 [
	     "Segunda",
	     "Quarta",
	     "Sexta"
	 ]
    }
}

E, até, um array de objetos!

{
    "Marconildo":
    {
        "url": "http://www.marconildo.com.br/",
        "idade": 34
    },
    "Joanorta":
    {
        "url": "http://www.joanorta.com.br/",
        "idade": 22
    },
    "Estripafurgia":
    {
        "url": "http://www.estripafurgia.com.br/",
        "idade": 47,
    	"dependentes":
    	[
    	    "Astolfinho":
	    {
	        "sexo" : "m",
	        "idade": 16
	    },
    	    "Mariazinha":
	    {
	        "sexo" : "f",
	        "idade": 10
	    }
    	]
    }
}

JSON e javascript

Agora você já aprendeu as notações básicas do JSON, mas o que fazer com isso, como usar, efetivamente, o poder do JSON nas aplicações do dia-a-dia usando javascript? Veja um exemplo simples:

var funcionarios = '
	{
	    "Marconildo":
	    {
	        "url": "http://www.marconildo.com.br/",
	        "idade": 34
	    },
	    "Joanorta":
	    {
	        "url": "http://www.joanorta.com.br/",
	        "idade": 22
	    },
	    "Estripafurgia":
	    {
	        "url": "http://www.estripafurgia.com.br/",
	        "idade": 47
	    }
	}
';
 
var funcionario = JSON.parse(funcionarios);
 
alert(funcionario.Marconildo);
alert(funcionario.Marconildo.idade);

Foi criada a variável “funcionarios” e colocado uma string JSON nela. Usando a função JSON.parse, convertemos a string para, efetivamente, JSON na variável “funcionario”e, a partir daí, foi possível acessar todas suas propriedades com a notação padrão de OO.

Esse foi um exemplo ilustrativo. Em aplicações “de verdade”, seria bastante eficiente, por exemplo, realizar requisições em AJAX para procurar retornos em JSON e, a partir daí, realizar quaisquer tipos de operação com o data retornado. Trataremos disso em artigos futuros. Assine o feed para conferir.

$.getJSON

O jQuery possui uma poderosa ferramenta para trabalharmos com JSON, é a função $.getJSON, que serve para carregar dados no formato JSON usando requisição HTTP GET. Na verdade, esta função é somente uma espécie de atalho para $.ajax() usando “json” no dataType, mas usá-la num contexto JSON fica bastante coerente.

Não há mistério algum para usar, ele segue a mesma “linha” do $.ajax(), como podemos encontrar neste exemplo disponibilizado no próprio site do jQuery:

$.getJSON('ajax/test.json', function(data) {
  var items = [];
 
  $.each(data, function(key, val) {
    items.push('<li id="' + key + '">' + val + '</li>');
  });
 
  $('<ul/>', {
    'class': 'my-new-list',
    html: items.join('')
  }).appendTo('body');
});

E, como nos mostra Gabriele Romanato, é possível verificar se o resultado da requisição é realmente um objeto JSON de maneira simples:

$.getJSON(url, function(data)) {
  if(typeof data !== 'object') {
    // Erro!
  }
});

Dessa maneira, é possível economizar bastante tempo ao procurar erros e a estrutura de código fica mais profissional e mais facilmente manutenível.

JSON e PHP

O PHP também possui algumas funções para se trabalhar com JSON. Vamos a um exemplo simples de como gerar PHP a partir de JSON:

$funcionarios = '
	{
	    "Marconildo":
	    {
	        "url": "http://www.marconildo.com.br/",
	        "idade": 34
	    },
	    "Joanorta":
	    {
	        "url": "http://www.joanorta.com.br/",
	        "idade": 22
	    },
	    "Estripafurgia":
	    {
	        "url": "http://www.estripafurgia.com.br/",
	        "idade": 47
	    }
	}
';
 
$funcionario = json_decode($funcionarios);
 
echo $funcionario->Marconildo . '<br />';
echo $funcionario->Marconildo->idade;

Bem simples, bem direto, dispensa explicações. Agora, se você preferir tratar o JSON como se fosse array, basta inserir um segundo parâmetro à função, dessa maneira:

$funcionario = json_decode($funcionarios, TRUE);

Ferramentas JSON

JSON é bastante simples e intuitivo para qualquer programador, mas, para quem está começando a mexer agora e/ou para os que precisam de algumas ferramentas para JSON, segue o link de alguns parser, validadores e ferramentas, em geral, para se trabalhar com JSON:

• Json Parser Online
• JSONLint – The JSON Validator
• Online JSON Viewer
• Convert JSON Strings to a Friendly Readable Format

Conclusão sobre JSON

Uma das principais funcionalidades do JSON é o intercâmbio de dados entre aplicativos e linguagens diferentes. Sua sintaxe simples, sua leveza e objetividade, aliados ao suporte por dezenas de linguagens de progrmação o tornam uma excelente alternativa quando a necessidade é esta. O fato de milhares de webservices de qualidade usarem JSON deve ser um bom indicativo de que usá-lo é uma boa escolha.

Usando as ferramentas apresentas, é possível validar seu JSON, testá-lo, verificar se está produzindo uma hierarquia correta, enfim, aperfeiçoar e refinar o código para que atinja o máximo possível de desempenho. Ao se trabalhar com JSON, logo se percebe seu poder e simplicidade, o que agiliza bastante o processo de programação, ao mesmo tempo em que o formato não se torna um empecilho à produtividade; pelo contrário, a aprimora!

Por essas e outras a notação JavaScript Object Notation, mais conhecida como JSON, é altamente recomendada para desenvolvimento web!

Artigos Relacionados

• Evitando erros comuns de HTML5
• Microdata API e Schema.org: dando significado ao HTML
• Erros comuns em desenvolvimento web para campanhas de SEO
• Breadcrumbs: guia completo com exemplos e melhores práticas
• Perguntas ao cliente para antes e depois de um projeto
• 6 mitos de SEO que você deve evitar
• Mastering Twitter, o manual completo sobre twitter para desenvolvedores e marketeiros
• 8 características de User Interfaces (UI) de sucesso
• Como criar sumários dinamicamente com o TOC (Table of Contents) jQuery plugin
• Web sites e comunicação: 21 maneiras de os sites se comunicarem com seus visitantes

Recentemente, uma leitora do blog escreveu pedindo algum material sobre cores na web, perguntando se poderia publicar um artigo sobre este assunto tão importante no desenvolvimento para web. Como já tivemos a oportunidade de mostrar, as cores são uma das maneiras de os sites se comunicarem com seus visitantes, imprescindível para se fazer web sites de qualidade.

O assunto, além de complexo e, em alguns pontos, controverso, é bastante amplo. Por isso, ao invés de escrever um artigo ou uma série a respeito, decidi que a contribuição seria maior ao indicar fontes e referências sobre o tema. Certamente compartilhar o que outras pessoas já escreveram sobre as cores na web (e cores, em geral) será uma contribuição muito maior.

Referências sobre teoria das cores para web

O uso da teoria das cores na web, na verdade, não é assunto exclusivo da web. O que se faz é pegar todo o este conteúdo teórico e, simplesmente, realizar algumas adaptações para que este seja mais “compatível” e traga resultados mais eficientes no ambiente online. Portanto, quando se faz este tipo de estudo, você encontra os mesmos termos, terminologias, conceitos e constatações, seja no “mundo online” ou “mundo offine”.

Então, uma boa forma de começar o estudo das cores é acessando o site de Maria Claudia Cortes, Color in Motion, no qual, através de interações do próprio visitante, ela mostra o significado, melhor combinação, efeitos psicológicos, significado nas diferentes partes do mundo, etc, das cores vermelho, laranja, amarelo, verde, azul e roxo. Além disso, há uma animação que envolve os personagens das cores, mostrando algumas das principais respectivas características. Realmente vale a pena o acesso!

É importante, também, já que o assunto são cores na web, conhecer um pouco da parte técnica que envolve a exibição de cores em monitores, diferença entre CMYK (real) e RGB (virtual), diferença ao representar as cores usando RGB ou Hexadecimal, dentre outros. E, para isso, existe uma explicação-base bastante simples de se entender, que pode ser encontrada no site da Hi-Midia, em um artigo sobre as cores na web.

Uma das grandes referências na área é Daniele Viana que, em seu blog, fez uma série de artigos a respeito. O interessante é que, dentre esses artigos, existem aqueles que abordam, especificamente, as principais cores e seus efeitos em web designs. Artigos estes que, numa disposição didática, seriam:

• O uso das cores em webdesign
• Breve análise das cores
  • Amarelo
  • Azul
  • Cinza
  • Laranja
  • Marrom
  • Preto
  • Rosa
  • Roxo
  • Verde
  • Vermelho
• Como criar combinações de cores mais inteligentes

Ferramentas para cores na web

Já tivemos a oportunidade de mostrar algumas ferramentas para cores na web, como, por exemplo, o Colorblind Web Page Filter. Mas, para compor este artigo melhor, faz-se necessária uma lista mais incrementada. Portanto, segue uma lista completa de ferramentas de cores para web:

• Amostras/Combinações de cores
  • 0to255
  • Color Schemer Scheme Gallery
  • COLOURlovers
  • ColorBurn Winners
  • Color Combos
  • Color Schemes
  • Kuler
• Montagem de esquemas de cores
  • Color Blender
  • Color Jack: Sphere
  • Color Palette Generator
  • Color Scheme Designer
  • Color Schemer Online
  • EasyRGB: Color Harmonies
• Cores a partir de imagem
  • Color Palette Generator
  • Palette Generator
  • What’s Its Color
• Outros
  • Color Blender
  • Colour Check
  • Colour Selector
  • I Like Your Colors

Conclusão

Quando se trata de cores e exibição de imagens na web, algo que deve ser feito depois de o serviço feito, é “ajustar” o trabalho para a web. Então, confira o artigo “Como otimizar imagens para web – guia de otimização de imagens“.

Existem muitos e muitos sites que tratam sobre a teoria das cores na web. Alguns tratam de forma mais geral; outros mais pormenorizada. Mas são tantos e tantos que tentar sistematizar todos em um único artigo é algo bastante difícil de se fazer. Portanto, caso tenha algum complemento a fazer e/ou ferramenta para indicar, comente!

Artigos Relacionados

• CSS float: considerações, dicas e macetes para bons layouts na web
• Gestalt aplicado ao design web (parte 6): princípio da experiência passada
• Gestalt aplicado ao design web (parte 5): exemplos web do princípio do alinhamento
• Gestalt aplicado ao design web (parte 4): princípio da boa continuidade ou princípio do alinhamento
• Gestalt aplicado ao design web (parte 3): exemplos web do princípio da proximidade
• Gestalt aplicado ao design web (parte 2): princípio da proximidade
• Gestalt aplicado ao design web (parte 1): origem do termo, significado e utilidade
• Desenvolvedores front end e o mercado
• Usando Modernizr para detectar features de HTML5 e CSS3
• Não use IDs como seletores em CSS

Quando o assunto é desenvolvimento web, os visitantes de sites não têm muita paciência para esperar… Estudos mostram que se o site não apresentar algum feedback (mostrar alguns elementos/conteúdos) em poucos segundos, a pessoa desiste de esperar e abandona o site – com grandes probabilidades de não mais retornar.

Uma das funções mais interessantes é apresentar um loading (vulgo “carregamento”) indicando quantos por cento (%) do site estão carregados e o que ainda falta, mostrando para o visitante este feedback que ele precisa para ter certeza de que “coisas” estão acontecendo.

Depois do advento do AJAX, nos anos 90 do século passado, e surgimento de muitos bons frameworks para front-end depois disso, tais como jQuery, os programadores contamos com excelentes ferramentas e recursos para acelerar o carregamento e melhorar a performance de sites, sendo possível realizar funções, efeitos e interações que, pouco tempo atrás, não eram sequer imaginadas.

Uma das interações é fazer loading em conteúdos do site, ou, mesmo, em páginas inteiras do site, e uma das maneias de se fazer isso é usando o plugin para jQuery jLoader.

jLoader: dinâmica

É possível ver no site oficial do jLoad que está licenciado sob a GNU GPL v3, então seu uso é grátis e pode ser feito sem maiores complicações.

O que o plugin permite é mostrar uma barra de carregamento para elementos específicos da página (lembrando que “body” também é um elemento da página). Quer dizer, é possível tanto carregar elementos específicos da página (e o jLoader permite fazer múltiplos carregamentos simultâneos), quanto carregar a página inteira, colocando o loader no documento inteiro.

Algumas das características do jLoader são:

• Múltiplos loadings simultâneos na mesma página
• Acompanha redimensionamento da janela
• Se o elemento-alvo tiver imagem de background ou for uma imagem, isso é levado em consideração
• Função para interromper loadings em triggers de eventos
• Dentre outros

jLoader: funcionamento

O plugin é leve (8KB) e conta com somente 1 arquivo (nada de CSS externo). Como citado, é possível fazer carregamento para vários elementos da página ao mesmo tempo; para cada um deles, o método construtor pode receber argumentos de personalização:

• overlayColor. Hexadecimal da cor de background do loading (padrão “#000″).
• userCallback. Função para quando o carregamento termina (padrão “null”).
• showProgress. Se a barra de loading vai ou não aparecer (padrão “false”).
• showProgressText. Se o número da porcentagem vai ou não aparecer (padrão “false”).
• progressColor. Hexadecimal para a cor da barra de progresso (padrão “#FFF”).
• textColor. Hexadecimal para a cor dos números da porcentagem (padrão “#FFF”).
• textSize. Tamanho do texto para os números da porcentagem (padrão “15″).
• loaderPosition. Reposiciona o loader no overlay; por padrão é centalizado (usa-se “loaderPosition:{top:y,left:x}”).

Não são tantas opções, assim, mas já dá para fazer um nível de personalização bem interessante. Vamos ver em alguns exemplos.

jLoader: exemplo 1

Como primeiro exemplo, vamos imaginar que queremos fazer loading em um elemento de id “escopo”, mostrando a barra de progresso e o texto da porcentagem de carregamento com texto 20 e, após o fim do carregamento, dar o trigger para a função showContent().

1
2
3
4
5
6
7
8
9
10
11
12

jQuery(document).ready(function($){
    var loader = new Loader('#escopo',
        {
	    showProgress:true,
	    showProgressText:true,
	    textSize:20,
	    userCallback:showContent
	}
    );
 
    loader.Start();
});

jLoader: exemplo 2

Loadin no elemento de id “noticias”, com fundo “#0B274C” e cor da barra de carregamento “#F6911E”.

1
2
3
4
5
6
7
8
9
10
11
12

jQuery(document).ready(function($){
    var loader = new Loader('#noticias',
	{
	    showProgress:true,
	    showProgressText:true,
	    overlayColor:'#0B274C',
	    progressColor:'#F6911E'
	}
    );
 
    loader.Start();
});

jLoader: exemplo 3

Loading o site inteiro, com todas as configurações padrão, exceto o tamanho do texto, que será “10″.

1
2
3
4
5
6
7
8
9

jQuery(document).ready(function($){
    var loader = new Loader('body',
	{
	    textSize:10
	}
    );
 
    loader.Start();
});

Outras customizações

Estamos falando de arquivos javascript, meus amigos, e, mesmo que não haja uma função pré-definida e/ou você queira fazer ajustes mais “pesados”, diretamente no core do plugin, basta abrir o arquivo que você baixou e realizar as mudanças que quiser…

Por exemplo, se quiser aumentar a espessura da barra de loading (que, por padrão, é de 1px), simplesmente abro o arquivo, procura o trecho de código que especifica essa características (na atual versão do jLoader, a 1.1.1, esta característica está na linha 139 do arquivo jLoader.js).

Assim como foi explicado no artigo sobre criação de URLs amigáveis com slugs, o mesmo vale para qualquer script pronto: basta abrir, estudar e fazer as modificações que cabem ao projeto/resultado pretendido.

Conclusão

Certamente, uma das maiores questões de muitos desenvolvedores é como fazer loading no site. Usando o jLoader, isto está resolvido.

Mas, atenção: não é só porque existe o recurso de carregamento, que este deve ser usado em todo e qualquer elemento de todos os sites do mundo… Há que se levar em consideração o escopo do projeto e se, realmente, existe a necessidade e/ou conveniência em usar o recurso.

Se realmente for necessário, use o jLoader para fazer loadings de elementos no site (ou páginas completas) e desfrute das facilidades de fazer isso de forma tão simples, aumentando a boa experiência que os visitantes terão!

Artigos Relacionados

• Como otimizar códigos jQuery e aumentar a performance do front-end
• 5 dicas para temas WordPress melhores
• Otimização WordPress: aumente a performance e desempenho de seu blog / site
• Como criar sumários dinamicamente com o TOC (Table of Contents) jQuery plugin
• 25 extensões para o Firefox para aumentar a produtividade no dia-a-dia na web
• Problemas comuns de WordPress e como resolvê-los
• Usando Modernizr para detectar features de HTML5 e CSS3
• Não use IDs como seletores em CSS
• Como usar .ready() antes de incluir a jQuery
• Wireframes para web: guia completo de desenvolvimento

Muitas pessoas usam o WordPress como plataforma para blogging, sites, portais e outros tipos de projetos online. Depois de instalar o WordPress, a maioria dos usuários de WordPress normalmente vai em busca de um tema pronto para não usar o tema padrão que vem com o WP.

Quer você use temas gratuitos ou pagos (ou, mesmo, desenvolva seus próprios temas), existem muitas maneiras de melhorá-los através de dicas para fazer temas WordPress melhores!

Use favicon personalizado

Quando um site não tem um favicon personalizado, ele pode parecer não-profissional. Certifique-se que o seu tema WordPress tenha um favicon próprio. Você pode conferir uma lista de geradores de favicon para ajudar.

Para fazer referência ao seu ícone no WordPress, basta colocar o seguinte código, normalmente dentro arquivo header.php que pode ser encontrado na pasta raiz do seu tema (levando em conta que o arquivo da imagem também está na pasta raiz):

<link rel="icon" href="favicon.ico" type="image/x-icon" />

Estilize a legenda das imagens

Quando você faz upload de uma imagem para colocar em um post ou página do WordPress, dentre outras opções, é possível inserir uma legendas para colocar uma descrição para a imagem. Um bom tema WordPress deve incluir regras CSS para estilizar as legendas da imagens. Para estilizar as legendas segundo o padrão do WordPress, insira as seguintes linhas em seu arquivo CSS (geralmente chamado styles.css):

.wp-caption {
background-color: #f3f3f3;
border: 1px solid #ddd;
border-radius: 3px;
margin: 10px;
padding-top: 4px;
text-align: center;
 
-khtml-border-radius: 3px;
-moz-border-radius: 3px;
-webkit-border-radius: 3px;
}
 
.wp-caption img {
border:0 none;
margin:0;
padding:0;
}
 
.wp-caption p.wp-caption-text {
font-size:11px;
line-height:17px;
margin:0;
padding:0 4px 5px;
}

Veja o artigo com o guia completo sobre breadcrumbs para visualizar imagens com captions estilizados corretamente.

Use PHP Flush

Chamando a função flush() do PHP imediatamente depois do cabeçalho HTML, você será capaz de acelerar seu site WordPress. Basta adicionar esta linha com a chamada à função após o </ head> (por padrão, no arquivo arquivo header.php):

<?php flush(); ?>

Esse código simplesmente força seu servidor web a enviar cabeçalho do site antes de enviar o restante do conteúdo. Usando a função flush(), o navegador tem tempo para baixar todas as folhas de estilo referenciadas no cabeçalho enquanto espera pelas outras partes da página.

Minimize os arquivos de seu tema WordPress

É muito útil ter os arquivos CSS e javascript de seu tema minimizados para reduzir seu tamanho, consequentemente realizando uma transferências de arquivos mais rápido, aumentando a velocidade do site, em geral. Minimizar os arquivos significa retirar caracteres desnecessários deles, como espaços e tabs (e, no melhor caso, juntar todos os arquivos do mesmo tipo em um só).

Existem diversas ferramentas gratuitas na internet para minimizar arquivos CSS e javascript. Para javascript, existem, dentre outros, os excelentes JavaScript Compressor, /packer/, jsCompress e YUI Compressor Online. Para fazer um minify em arquivos CSS, confira o item “Otimizadores e Formatadores de CSS” do artigo de ferramentas e recursos para desenvolvimento web.

Existem, também, vários plugins para WordPress para minimizar e otimizar os arquivos, como o WP Minify e W3 Total Chache, que fazem o serviço de minify de forma bastante transparente e, ainda, melhoram outros aspectos para otimização de temas WordPress, tais como manipulações de cache, combinação de arquivos, e outros para melhorar a velocidade do site.

Substitua funções e hooks por conteúdo estático

Os arquivos de temas que podem ser baixados na web precisam ser bem flexíveis, para atender ao maior número de pessoas que os queiram usar. Por isso, existem diversas chamadas a funções e hooks que permitem que um tema funcione nas mais diversas formas e situações.

No entanto, isso pode acarretar em uma perda de performance e desempenho das página, já que cada vez que uma página é gerada, ela precisa fazer várias chamadas a hooks/funções para renderizar a página.

Inspecione os arquivos do tema que você escolheu para seu site/blog e perceba as chamadas desnecessárias. Por exemplo, no header.php, você pode encontrar uma linha parecida com esta:

<title><?php bloginfo('name'); ?></title>

Essa função serve para mostrar o nome do seu site (definido nas configurações no Painel Administrativo) na barra de títulos do navegador. Na verdade, o nome do site não se altera quase nunca, então, para que deixar mais uma chamada a função? Isso consome recursos do servidor e reduz o tempo de carregamento do site. Você pode, facilmente, substituir por:

<title>Nome do Site<title>

Eis um outro exemplo do que pode ser encontrado no header.php:

<link rel="stylesheet" href="<?php bloginfo('stylesheet_url'); ?>" type="text/css" />

Essa linha usa a função para referenciar o caminho de onde se encontra o arquivo “style.css” do tema. Mais uma vez, é possível poupar recursos do servidor com uma simples mudança:

<link rel="stylesheet" href="http://www.site.com/wp-content/themes/themename/style.css" type="text/css" />

Esses foram somente 2 exemplos, mas existem muitas outra chamadas a funções “desnecessárias” quando se baixa um tema, seja ele gratuito ou pago. Vasculhe os arquivos do tema usado e substitua por conteúdo estático sempre que possível.

E você, tem mais alguma dica para o desenvolvimento de temas WordPress melhores? Comente!

Artigos Relacionados

• Otimização WordPress: aumente a performance e desempenho de seu blog / site
• Truques de configuração do WordPress
• Problemas comuns de WordPress e como resolvê-los
• Como otimizar códigos jQuery e aumentar a performance do front-end
• Como fazer loading em conteúdos do site
• 15 fantásticos comandos SQL para WordPress
• Ferramentas e recursos para desenvolvimento web
• 8 dicas para fazer códigos melhores com jQuery
• Newsletter no WordPress com o plugin Ajax Newsletter (wp-ajax-newsletter)
• Pergunte-se a si mesmo: questões para desenvolver um bom site

Principalmente em blogs sobre desenvolvimento web – ou que não sejam, mas que precisem, eventualmente, apresentar URLs longas -, a indicação de endereços completos da internet e/ou da web geralmente se faz necessária. Mas é preciso saber como estilizar corretamente estes endereços através de regras CSS para que sua apresentação não fique “quebrada” dentro do layout feito.

Para apresentar corretamente URLs longas, seqüências de texto e outros conteúdos, basta utilizar esta regra CSS em qualquer elemento em nível de bloco (por exemplo, é perfeito para tags <pre>):

pre {
white-space: pre;           /* CSS 2.0 */
white-space: pre-wrap;      /* CSS 2.1 */
white-space: pre-line;      /* CSS 3.0 */
white-space: -pre-wrap;     /* Opera 4-6 */
white-space: -o-pre-wrap;   /* Opera 7 */
white-space: -moz-pre-wrap; /* Mozilla */
white-space: -hp-pre-wrap;  /* HP Printers */
word-wrap: break-word;      /* IE 5+ */
}

Por padrão, o valor da propriedade white-space é definido como “normal”. Então, você pode ver algo como isto quando tenta “forçar” URLs longas e outras seqüências contínuas de texto:

Para “forçar” fragmentos de texto longos e contínuos que são “envolvidos” dentro da largura do <pre> (ou outro elemento nível de bloco, como <div> ou <p>), é necessário um valor diferente para a propriedade white-space. As opções possíveis são:

• normal. O valor padrão para a propriedade white-space. Sequências de espaços em branco são “recolhidos” a um único espaço em branco. O conteúdo de <pre> irá se adequar à largura do elemento.
• nowrap. Sequências de espaços em branco são recolhidos a um único espaço em branco. Os conteúdos de <pre> pulam de linha SOMENTE em elementos com <br />.
• pre. Todos os espaços em branco são preservados e o conteúdo de <pre> irá pular de linha de forma implícita. Esse é o comportamento padrão do elemento <pre>.
• pre-line. Sequências de espaços em branco se recolhem a um único espaço em branco; o conteúdo de <pre> irá dar wrap em espaços em branco e quebras de linha acontecem de acordo com a largura do elemento.
• pre-wrap. Todos os espaços em branco são preservados e o conteúdo de <pre> irá se comportar de acordo com os espaços em branco e quebras de linha de acordo com a largura do elemento.
• inherit. Valor de white-space herdado do elemento pai.

Em um mundo perfeito, nós poderíamos simplesmente usar “white-space:pre-line” dessa forma:

pre {
white-space: pre-line;
width: 300px;
}

Embora a propriedade white-space seja, teoricamente, suportada por todos os principais navegadores, infelizmente muitos deles falham e não conseguem aplicar corretamente a propriedade para strings longos.

Diferentes navegadores farão o wrap (“quebrar” o texto) em textos longos, mas exigem valores diferentes de white-space para trabalhar. Felizmente, podemos aplicar os valores necessários para cada navegador incluindo várias declarações de white-space. Essa é exatamente a solução apresentada no código CSS mostrado no início do artigo.

Os comentários incluídos na solução CSS mostram qual solução se aplica a cada browser. Observe que algumas das regras são específicas de alguns navegadores (veja os prefixos específicos dos fornecedores), enquanto outros declaram valores default a partir de diferentes especificações CSS.

A estranha propriedade “word-wrap” é uma invenção da Microsoft que foi incluído no CSS3. Graças às “CSS forward compatibility guidelines”, é perfeitamente possível incluir várias instâncias da mesma propriedade. Em poucas palavras:

• Propriedades não reconhecidas são ignoradas
• Para várias declarações da mesma propriedade, somente a última tem validade

A solução de código apresentada neste artigo parece funcionar bem em todos os navegadores, mas ela não valida (segundo o W3C) devido à louca propriedade da Microsoft.

Para ver os conceitos aqui mostrados na prática, veja uma página de exemplo e, para uma discussão mais completa sobre a quebra automática de texto, confira o artigo Perfect Pre Tags, também do blog Perishable Press.

Artigos Relacionados

• Problemas comuns de WordPress e como resolvê-los
• Microdata API e Schema.org: dando significado ao HTML
• Estratégia de Conteúdo ou Content Strategy
• Elementos de design aplicados à web
• Wireframes para web: guia completo de desenvolvimento
• 10 erros básicos de web design
• JSON – JavaScript Object Notation
• Erros comuns em desenvolvimento web para campanhas de SEO
• URLs amigáveis (slug) à WordPress
• 15 fantásticos comandos SQL para WordPress

É bastante comum ao desenvolvedor web se deparar com casos em que deve justificar as ações que toma em seu trabalho – chamado por alguns de “defesa do trabalho”. E, nessas situações, é importante saber como argumentar com o cliente, às vezes sobre como a comunicação na web é diferente e peculiar em relação a outras mídias.

Recentemente, conheci o excelente vídeo (que vi no Publicidade na Web) intitulado “Como a internet mudou a propaganda” que, de uma maneira bastante simples de se entender, explica algumas dessas peculiaridades, reforçando o conceito de que novas tecnologias exigem novas maneiras de se comunicar!

Artigos Relacionados

• Web sites genéricos e a ilusão dos preços baixos
• Evitando erros comuns de HTML5
• Não use IDs como seletores em CSS
• Estratégia de Conteúdo ou Content Strategy
• 10 dicas que desenvolvedores web iniciantes devem saber
• Elementos de design aplicados à web
• Wireframes para web: guia completo de desenvolvimento
• 10 erros básicos de web design
• JSON – JavaScript Object Notation
• Cores na web: guia completo

Passar muitos argumentos no URL

Quando o site é dinâmico, os desenvolvedores web precisam ter uma referência sobre o qual a página, o produto ou categoria o visitante quer ver. Normalmente um ID é necessário para recuperar os dados do banco de dados. Em outros casos, devido à complexidade do projeto ou devido a más técnicas de programação, mais variáveis são necessárias para identificar uma determinada página. Aqui está um exemplo de um URL dinâmico:

http://www.exemplo.com/produtos.php?id=30&categoria=2&cor=verde

Infelizmente, este tipo de URL não é amigável nem para pessoas, nem para mecanismos de busca. Segundo é possível ler nas Diretrizes Técnicas das Diretrizes para Webmasters da Central do Webmaster Google,

Se você decidir usar páginas dinâmicas (por exemplo, o URL que contém um caractere “?”), saiba que nem todos os spiders de mecanismos de pesquisa rastreiam as páginas dinâmicas e estáticas. Isso ajuda a manter os parâmetros curtos e a quantidade desses parâmetros pequena.

Por isso, é altamente recomendado usar algum tipo de reescrita de URL, como mod_rewrite, para converter as URLs dinâmicas para URLs amigáveis. Qual é o risco, se isso não for feito? Bem, se há muitos parâmetros em URLs: os motores de busca podem não indexar as páginas; além disso, geralmente  URLs não amigáveis não contém palavras-chave importantes no endereço, então, não raramente você pode conseguirá rankings inferiores para essas páginas do que se elas tivessem URLs amigáveis.

Usar muito JavaScript, frames/iframes, AJAX, Flash e Silverlight

JavaScript, frames/iframes, AJAX, Flash e Silverlight são ferramentas úteis e alguns deles, quando bem usados, melhoram a experiência do usuário. Mas nenhum deles é search engine friendly.

As mesmas Diretrizes Técnicas do Google citadas, indicam:

Use um navegador de texto como o Lynx para examinar o seu site, pois muitos spiders de mecanismos de pesquisa veem o site do mesmo modo que o Lynx. Se recursos especiais como JavaScript, cookies, IDs de sessão, frames, DHTML ou Flash permitirem que você veja todo o site em um navegador de texto, os spiders dos mecanismos de pesquisa poderão ter dificuldade em rastrear o seu site.

Se o objetivo é que o site seja amigável aos mecanismos de busca, devemos verificar se eles podem ser vistos usando browsers de texto simples como o Lynx (que é como o googlebot “vê” os sites). É possível usar emuladores do Lynx ou desabilitar CSS e imagens diretamente no navegador (se usar, Firefox, uma ótima opção é usar o plugin Web Developer).

Não usar o atributo alt em imagens e não otimizar o caminho das imagens

Os motores de busca (e computadores, em geral) não são muito bons em identificar o que é representado em uma imagem. Portanto, a fim de compreender sobre o que uma imagem é, os bots analisam o nome e o atributo “alt” das imagens.

O Google Image Search pode trazer uma quantidade significativa de tráfego. Se você não garantir o “apoio” a mecanismos que permitam a otimização de imagens, você pode perder uma boa fonte de tráfego. Assim, garanta que você use corretamente ambos, o atributo alt e o nome da imagem – usar um CMS que permita esse tipo de otimização é uma boa dica.

Usar métodos incorretos para oferecer suporte a idiomas diferentes

Quando você tem sites multilíngue, tenha certeza de que a arquitetura está correta. Não há uma única forma “correta” para fazer isso. Basicamente, há três maneiras corretas para suportar um site em vários idiomas e cada um dos métodos a seguir tem alguns prós e contras:

• Subdomínios. Exemplo: fr.example.com, gr.example.com, etc
• Subdiretórios. Exemplo: www.example.com/fr/, www.example.com/gr/, etc
• Diferente domínios. Exemplo: www.example.fr, www.example.gr, etc

A dica é evitar o envio de conteúdo baseado em IP sem ter a mesma versão do site disponível para todos. Também não implementar soluções ruins como passar o idioma como uma variável GET, por exemplo www.example.com/?lang=fr.

Não se preocupar com o tempo de carregamento da página

Recentemente o Google informou que passou a usar a velocidade de carregamento dos websites em seus algoritmos de classificação (apesar de isso não estar valendo para sites de todos os países do mundo). Há um debate sobre se esse recurso deve ser incluído, uma vez que não tem nada a ver com a relevância de um site. No entanto, a velocidade aumenta a experiência do usuário. Além disso, ter um site leve, que carregue rapidamente, pode melhorar seu ROI e diminuir a carga do seu servidor (conheça 8 maneiras de melhorar a performance de um site).

7 dicas de desenvolvimento web

Algumas dicas para guiar o desenvolvimento de suas páginas web são:

• Colocar menus, cabeçalhos e rodapés em arquivos separados, a fim de realizar mudanças globais rápidas (funções “include);
• Tentar usar subdomínios em sites multi idioimas;
• Usar caminhos absolutos para cada página, imagem, CSS e javascript do site;
• Usar canonicals para evitar conteúdo duplicado;
• Usar redirecionamento 301 ao invés de 302 quando o caminho para a página mudar e nunca apagar páginas;
• Redirecione corretamente as versões sem “www” para as que tenham “www” e vice-versa;
• Não adicionar IDs de sessão nas URLs.

E você, conhece algum outro erro comum em desenvolvimento web que pode atrapalhar uma campanha de SEO e o que fazer para evitar/corrigir?

Artigos Relacionados

• Meta tags
• Maneiras práticas para melhorar a visitação de seu blog e fidelizar seus leitores
• Não use IDs como seletores em CSS
• Elementos de design aplicados à web
• JSON – JavaScript Object Notation
• Estratégia Web de Pirâmide: guia para uma estratégia de web equilibrada
• Breadcrumbs: guia completo com exemplos e melhores práticas
• 6 mitos de SEO que você deve evitar
• Como otimizar imagens para web: guia de otimização de imagens
• Mastering Twitter, o manual completo sobre twitter para desenvolvedores e marketeiros

Melhorar a interação do campo de busca de um site permite que as pessoas que usam tal formulário para buscar tenham uma melhor experiência de uso (leia-se: usabilidade). Com pequenos detalhes, um pouquinho de bom-senso e algumas poucas linhas de jQuery, é possível promover efeitos interessante no campo de busca.

Para ficar claro, será abordada a seguinte interação:

• Campo de busca é “populado” com um termo pré-definido;
• Quando o campo recebe o foco, caso tenha o termo pré-definido, é limpo para a pessoa escrever o que pretende;
• Quando o campo perde o foco, se o conteúdo for o mesmo do termo pré-definido (ou em branco), este termo reaparece;
• Quando o botão é pressionado, caso o valor seja termo pré-definido ou esteja em branco, o form não submete e o foco passa ao campo apropriado.

O formulário de busca

Um exemplo de um formulário simples de busca, que pode ser usado em “sites reais”, profissionalmente, pode ser do tipo:

<form method="get" action="script.php" name="form" id="form">
    <input type="text" id="form-input" name="form-input" value="Snippets ou Scripts" />
    <input type="submit" id="form-submit" name="form-submit" value="Buscar" />
</form>

Termo pré-definido

A expressão “termo pré-definido” é mais adequada, já que cada site pede um “label” de indicação diferente, conforme as especificações e necessidades deste. Algumas pessoas preferem o termo “Buscar” ou “Procurar” com um botão de label “OK” ou “Vai”; já alguns sites preferem explicitar a função da busca com algo do tipo “Produtos ou Serviços”, acompanhado de um botão com o label “Buscar” (o que é uma abordagem bem interessante).

De uma maneira ou de outra, é preciso definir que termo será esse. Para nosso exemplo, vamos supor que seja um site voltado a desenvolvimento web e o termo pré-definido será “Snippets ou Scripts“. Vamos criar uma expressão regular simples com uma parte do termo pré definido:

patt = new RegExp('Snippets ou');

E por que não colocar a expressão inteira? Também poderia ser feito, mas o “esforço” para identificar o padrão aumenta em relação ao tamanho/complexidade da mesma. Sinta-se à vontade para fazer vários testes.

Melhorando a interação do formulário de busca

A melhora da interação se de duas formas:

• Interção com o campo;
• Interação com o botão;

Interação com o campo

Segundo o planejamento, o que se pretende é “Quando o campo recebe o foco, caso tenha o termo pré-definido, é limpo para a pessoa escrever o que pretende”. A lógica é testar a expressão regular: caso o teste seja positivo, o campo é limpo e recebe o foco para a pessoa escrever. Ao perder o foco, “se o conteúdo for o mesmo do termo pré-definido (ou em branco), este termo reaparece”.

$('#form-input')
.focus(function(){
    if (patt.test($(this).val()))
    {
        $(this).val('');
    }
})
.blur(function(){
    if ($(this).val() == '')
    {
        $(this).val('Snippets ou Scripts');
    }
});

Interação com o botão

A interação com o botão também é importante – e, infelizmente, é um ponto esquecido por muitos desenvolvedores. A ideia é, ao se clicar no botão, testar se a expressão “bate” ou o campo está em branco e, caso seja um desses casos, dar o foco no campo.

$('#form-submit').click(function(){
    if ((patt.test($('#form-input').val())) || ($('#form-input').val() == ''))
    {
        $('#busca-bottom').focus();
        return false; // Impede que o form seja submetido
    }
});

Não é necessário dar a instrução de limpar o campo no foco porque a peça de script anterior, sobre a interação com o campo, já faz isso.

JavaScript final

Juntando os pedaços de códigos, já devidamente explicados, tem-se o seguinte:

$('#form-input')
.focus(function(){
    if (patt.test($(this).val()))
    {
        $(this).val('');
    }
})
.blur(function(){
    if ($(this).val() == '')
    {
        $(this).val('Snippets ou Scripts');
    }
});
 
$('#form-submit').click(function(){
    if ((patt.test($('#form-input').val())) || ($('#form-input').val() == ''))
    {
        $('#busca-bottom').focus();
        return false; // Impede que o form seja submetido
    }
});

Conclusão sobre a melhora da interação em formulários de busca

Certamente essas não são as únicas melhorias cabíveis para a melhoria de usabilidade e interação de um formulário de busca simples, mas, certamente, são 2 medidas muito bem-vindas para que a experiência e “agradabilidade” sejam melhoradas.

Poderia haver, por exemplo, uma tooltip com o que se pode encontrar no site e/ou fornecendo algum exemplo de termo; implementar uma solução de autocomplete; ou, ao invés de limpar o campo, apenas selecionar todo o termo para, já digitação, substituí-lo pelo o que está sendo digitado. Depende da necessidade do projeto.

E você, tem alguma dica ou solução interessante para melhorar a interação em formulários de busca?

Artigos Relacionados

• Microdata API e Schema.org: dando significado ao HTML
• Como otimizar códigos jQuery e aumentar a performance do front-end
• Textarea: dicas e truques que você sempre quis saber
• Como criar sumários dinamicamente com o TOC (Table of Contents) jQuery plugin
• Evitando erros comuns de HTML5
• Usando Modernizr para detectar features de HTML5 e CSS3
• Como usar .ready() antes de incluir a jQuery
• Wireframes para web: guia completo de desenvolvimento
• JSON – JavaScript Object Notation
• Como fazer loading em conteúdos do site

Textarea é um elemento básico de (X)HTML (especialmente formulários). Mas, muitos desconhecem, textareas possuem muitas peculiaridades, dicas e truques que permitem efeitos e interações interessantíssimas. Eis uma bela coleção de 9 truques e dica simples que você pode fazer com textareas. Aproveite!

Imagem como background da textarea (desaparece quando recebe foco)

É possível adicionar uma imagem de fundo para um textarea (assim como quase para qualquer outro elemento). Às vezes, por algum motivo qualquer, quando se adiciona um background, isso pode “quebrar” o estilo padrão do navegador para o textarea: o estilo de borda padrão – 1px sólido – é substituído por uma espessa borda chanfrada. Para restaurar o padrão do navegador, é possível, apenas, reestilizar a textarea.

textarea {
    background:url(img/textarea-background.png) center center no-repeat; /* "Quebra" o padrão de textarea */
    border:1px solid #888; /* "Restaura" o padrão */
}

Essa imagem de fundo certamente irá interferir com a legibilidade do texto quando as palavras começarem a “passar por cima”. Para resolver isso, basta uma solução simples (com jQuery) que faz o seguinte: retirar a imagem de background quando o textarea recebe foco e o coloca de volta no blur, caso nenhum texto tenha sido digitado.

$('textarea')
  .focus(function() { $(this).css('background', 'none') })
  .blur(function() { if ($(this)[0].value == '') { $(this).css('background', 'url(img/textarea-background.png) center center no-repeat') } });

Texto com placeholder HTML5

No HTML5, haverá um novo atributo: placeholder. Ele mostra um texto em cinza clarinho na área de texto que desaparece quando o textarea está em foco ou tem algum valor.

<textarea placeholder="A vingança nunca é plena, mata a alma e a envenena!" cols="30" rows="5"></textarea>

Texto via HTML5 placeholder funciona no Safari 5, Mobile Safari, Chrome 6 e Firefox 4 alpha.

Texto com placeholder, HTML5 e jQuery

É possível testar se um determinado elemento suporta um atributo, em particular, por meio de testes com JavaScript:

function elementSupportsAttribute(element, attribute) {
    var test = document.createElement(element);
    if (attribute in test) {
        return true;
    } else {
        return false;
    }
};

Então, dá para escrever o código de modo que se o browser suporta o atributo placeholder, ele o usa; se não, seu comportamento é “imitado” através de jQuery:

if (!elementSupportsAttribute('textarea', 'placeholder')) {
  // Fallback for browsers that don't support HTML5 placeholder attribute
  $("#example-three")
    .data("originalText", $("#example-three").text())
    .css("color", "#999")
    .focus(function() {
        var $el = $(this);
        if (this.value == $el.data("originalText")) {
          this.value = "";
        }
    })
    .blur(function() {
      if (this.value == "") {
          this.value = $(this).data("originalText");
      }
    });
} else {
  // Browser does support HTML5 placeholder attribute, so use it.
  $("#example-three")
    .attr("placeholder", $("#example-three").text())
    .text("");
}

Remover o brilho azul

Todos os browsers WebKit, o Firefox 3.6 e Opera 10 colocam uma borda azul brilhante ao redor de textareas quando estão em foco. É possível removê-lo da seguinte forma:

textarea {
outline:none;
}

Você também pode aplicar à pseudo-classe :focus que vai funciona de qualquer maneira. Que saibamos, ainda não foi encontrada uma maneira de remover o brilho do Firefox e Opera. Se souber, por favor, comente!

Remover resizer da textarea

Navegadores baseados em WebKit colocam um pequeno elemento de UI no canto inferior direito das textareas para que os usuários possam redimensionar a área de texto. Se, por qualquer motivo, você quiser remover isso, uma regra CSS simples é tudo o que você precisa:

textarea {
resize:none;
}

Adicionar resizer na textarea

A resizeable interaction do jQuery UI pode ser usada em textareas. Ela funciona em todos os browsers e substitui a versão do WebKit nativa, já que essa versão tem todos os tipos de coisas mirabolantes (como callbacks e animações).

Para usar a interação, é preciso carregar jQuery e jQuery UI em sua página e usar o seguinte javascript:

$("textarea").resizable();

Fica a pergunta: usar jQuery e jQuery UI somente para adicionar o resize handle a suas textareas vale a pena? Não uma “resposta certa” para a pergunta; só você pode julgar se isso é adequado às necessidades e especificações de seu projeto.

Auto-redimensionar conforme o conteúdo

James Padolsey tem um script jQuery muito bom para auto redimensionar textareas conforme o conteúdo. A textarea começa com um tamanho normal razoável e, conforme você digita mais e mais conteúdo, ela se expande para incluir todo o texto, ao invés de mostrar a barra de rolagem padrão.

O plugin tem uma variedade de opções (confira), mas, em sua forma mais simples de uso, basta carregar o arquivo do script e usar assim:

$('textarea').autoResize();

Nowrap (sem quebra de linha automática)

Para evitar a quebra de texto com CSS normalmente é usada a regra “#seletor { white-space: nowrap; }“. Mas, por alguma razão, isso não funciona com textareas. Se a interação que você procura nas textareas é a linha não quebrar até que o Enter seja pressionado, é preciso usar o atributo “wrap” com o valor “off”, da seguinte maneira:

<textarea wrap="off" cols="30" rows="5"></textarea>

Remover barra padrão do Internet Explorer

O infame Internet Explorer coloca uma barra de rolagem vertical por padrão em todas as textareas. É possível ocultar isso com “overflow: hidden”, mas será um problema se a barra de rolagem realmente for necessária em função da quantidade de texto digitada. Felizmente, a propriedade overflow tem o valor “auto”, que exibe a barra de rolagem somente quando esta se fizer necessária. Fica assim:

textarea {
overflow:auto;
}

Conclusão

Você já tinha pensado que tantas interações e modificações fossem possível em um elemento de HTML tão básico como textarea? Se você quiser ser ainda mais ousado, com javascript e CSS é possível obter efeitos e interações ainda melhores! A propósito, os exemplos mostrados no artigo podem ser testados nesta página.

Se tiver alguma outra dica e/ou quiser mostrar algo de interessante que tenha feito em textareas, comente!

Artigos Relacionados

• Como otimizar códigos jQuery e aumentar a performance do front-end
• Melhorando a interação em formulários de busca
• Microdata API e Schema.org: dando significado ao HTML
• Wireframes para web: guia completo de desenvolvimento
• Como fazer loading em conteúdos do site
• 5 dicas para temas WordPress melhores
• URLs amigáveis (slug) à WordPress
• Gradiente CSS cross browser: degradês em CSS sem usar imagens
• Melhores editores WYSIWYG para seu projeto
• 15 fantásticos comandos SQL para WordPress

O desenvolvimento web em WordPress é excelente! O CMS já vem com diversas funções e funcionalidades para facilitar a vida de desenvolvedores e, até mesmo, de pessoas que não tem o mínimo conhecimento em programação (um dos objetivos é esse, mesmo).

Mas muitos desenvolvedores, principalmente os ainda incipientes, esquecem que o WordPress nada mais é do que PHP! Claro, o WP é nada mais, nada menos, que um sistema feito em PHP, como você e eu poderíamos ter feito. Mas, por motivos que me fogem ao conhecimento, as pessoas esquecem isso… Talvez o nível de abstração em programação que o CMS proporcione seja o “culpado”, mas, sinceramente, não tenho certeza.

Então, se você tiver a curiosidade de vasculhar os arquivos PHP que fazem do WordPress o que ele é, vai ter uma grata surpresa e encontrar uma rica fonte de scripts, funções e funcionalidades que você sempre quis implementar e não sabia como!  :-D

URLs amigáves à WordPress

Por exemplo, muitos querem implementar uma estrutura de URLs amigáves (gerar os famosos “slugs”) em sistemas desenvolvidos do zero  – seja através de frameworks ou em PHPU (“PHP Unha”) -, mas não sabem como. Ora, se sabemos que o WordPress possui um ótimo sistema de geração de slugs e temos acesso a seu código-fonte, tudo o que é preciso é vasculhar o código-fonte e encontrar as funções certas.

Seguindo o exemplo de gerar slugs, procurando um pouco, é possível saber que as funções necessárias se encontram em /wp-includes/formatting.php. E, como era de se esperar, as funções estão devidamente documentadas com seu escopo, parâmetros e retorno. Precisa de mais?

Para gerar URLs amigáveis à WordPress, são necessárias 4 funções. 3 “preliminares” que são:

E, com essas funções devidamente estabelecidas, a função que gera os slugs, propriamente dita:

Então, para gerar um slug em seu próprio sistema depois de implementar as funções mostradas, basta escrever:

1

sanitize_title_with_dashes($var);

Achou o nome da função grande ou feio? Você tem o código, altere como bem entender!

Considerações finais

O WordPress é software livre (registrado sob a licença GPL), então você pode pegar essas 4 funções e implementar em seu site/sistema/softwares sem o medo de receber uma cartinha do advogado da equipe WordPress amanhã ou depois.

Fica uma pergunta: você tem um software livre à disposição e fica quebrando a cabeça em busca de soluções de código que já existem e estão implementadas nele? Vasculhe todo o código fonte (veja alguns recursos que ajudam no artigo sobre ferramentas e recursos para desenvolvimento web) e procure por aquilo que vai lhe ser útil!

Não seja tímido! ;-)

Artigos Relacionados

• Microdata API e Schema.org: dando significado ao HTML
• 15 fantásticos comandos SQL para WordPress
• 6 mitos de SEO que você deve evitar
• Problemas comuns de WordPress e como resolvê-los
• Estratégia de Conteúdo ou Content Strategy
• Como otimizar códigos jQuery e aumentar a performance do front-end
• JSON – JavaScript Object Notation
• 5 dicas para temas WordPress melhores
• URLs longas apresentadas corretamente com CSS
• Erros comuns em desenvolvimento web para campanhas de SEO