Pensando Fora do Grid

por Molly E. Holzschlag

"Aerials, in the sky, when you lose small mind you free your life" ("Antenas, no céu, quando você perde a mente pequena você liberta sua vida.") - System of a Down

Voando para minha cidade natal de Tucson, no Arizona, tarde de uma noite de Novembro, fiquei impressionada como o grid do layout de uma cidade é rígido. Tucson é uma das cidades americanas planejadas, e do céu, é fácil perceber que os designers de Tucson tiveram sucesso em criar uma cidade onde tudo é desenhado de acordo com um plano preciso (figura 1).

Figura 1

Eu estava voltando de Londres, que em contraste, está longe de um grid rígido. Londres tem espirais, círculos, tangentes, e é bem mais espontânea em seu design (figura 2).

Figura 2

Por estar pensando neste artigo há algum tempo, a vista aérea destas cidades me mostrou uma boa metáfora para o grid de design na web. Com as tecnologias e técnicas de hoje, estamos livres para criar grids – ou podemos escolher por nos livrarmos completamente deles. Que esta simples escolha pode impulsionar um web designer é inquestionável: o grande desafio está na maneira em que nos forçamos a "perder a mente pequena" e pensar fora do grid.

Sense and the city

Se extendermos a metáfora do planejamento urbano para web design, existem paralelos muito interessantes. Design baseado em grids pode ser extremamente útil em sites que são previsíveis, de navegação fácil e de apelo visual. Grids são realmente bons para ajudar os designers a planejar aonde as coisas vão, e fácil de usar para os visitantes (figura 3).

Figure 3: Ryan Brill

Do lado positivo, Tucson certamente é fácil de andar; você não precisaria mais do que um mínimo de senso de direção ou um mapa de ruas. Os habitantes dão as direções para suas casas dando dicas baseadas no grid: "Estou na esquina sudoeste da Avenida Campbell com a Estrada Prince." Estradas e transportes públicos geralmente vão de norte a sul, ou de leste a oeste, tornando fácil a navegação na cidade.

Por outro lado, os designers de Tucson a planejaram somente para um certo crescimento, e isto causou inúmeros problemas em manter a facilidade de navegação e usabilidade da cidade quando ela cresceu além dos limites planejados. Além disso, as restrições do grid de Tucson não estimulam o crescimento de outros bairros e comunidades. Muitos habitantes de Tucson vão concordar que, como resultado, a cidade não tem um centro movimentado – ou várias comunidades – e quando estes focos isolados existem, eles são fáceis de chegar, mas as pessoas não se empolgam em sair para procurá-los.

Londres, ao contrário de Tucson, é um labirinto. Eu conheço londrinos que carregam um guia da cidade para ajudar na navegação! O sistema de transporte da cidade é tão difícil que os pretendentes a taxistas devem passar num teste demonstrando que eles possuem "O Conhecimento" para poderem dirigir os tradicionais carros pretos. O crescimento orgânico da cidade não a fez exatamente o melhor lugar para se navegar. Mas em Londres, comunidades maravilhosas e áreas interessantes surgiram e vizinhanças com ares distintos existem em todo lugar – e podemos certamente dizer que não existem apenas uma ou duas áreas de interesse cultural e da comunidade, mas várias. Enquanto a navegação talvez seja difícil, existem mais alternativas, e consequentemente as pessoas são mais motivadas a se envolverem nas ofertas da cidade.

Ao examinar designs desconstruídos e espontâneos, a metáfora persiste. Como as pessoas deveriam navegar em espirais e alamedas com facilidade? Por outro lado, pode-se produzir material visual ao se quebrar o rígido sistema que o ambiente de design e desenvolvimento da web tem, até agora, mantido. Na figura 4, você pode ver facilmente que quebrar os rígidos grids de layout desafia os designers a manterem a facilidade de uso enquanto criam layouts diferentes do que estamos tão acostumados a ver.

Figura 4: AIGA Los Angeles

Codificando o grid fantástico

É impressionante para mim, como uma pessoa que tende a ser um pouco mais centrada-em-código do que capaz-de-criar, ver como nossos designs têm sido presos ao código. Eu acho que foram os limites dos layouts baseados em tabelas que nos mantiveram num grid visual por tanto tempo (figura 5). Acrescente que só agora existe um emergente entendimento de layouts em CSS e fica fácil entender as razões.

Figura 5: k10k

Layout em tabelas são ótimos para design em grid. O próprio código reproduz um grid específico, e a tendência é que nós simplesmente preenchamos as caixas com imagens, textos, e elementos de interface que constroem nosso design (figura 6). Se realmente criarmos um design desconstruído ou espontâneo com uma complexidade visual, temos que usar muitas imagens dentro do documento para alcançar os resultados, tornando documentos mais pesados e o código mais complicado.

Figure 6: Weightshift

Existem algumas vantagens para grids baseados em tabelas, mas, como na metáfora do planejamento urbano, um ponto forte pode virar uma fraqueza. Grids baseados em tabelas nos permitem garantir que todas as células dentro dele trabalham em conjunto. Quer que todas as colunas fiquem do mesmo tamanho? Nós nem pensamos como fazer – é o comportamento natural das tabelas. Quer colocar mais espaço entre as células? De novo, é automático. É claro, e se você não quiser esse resultado "um-serve-para-todos"? A resposta dói: você não consegue.

O CSS desafia tudo isso, e é por isso que penso, junto com muitos outros, que ainda não aprendemos a desenhar para a web. O que estamos apenas começando a entender – particularmente aqueles que vêm para os layouts em CSS depois de anos trabalhando com tabelas – é que o modelo visual do CSS é muito mais conduzido para sair do grid e criar com elementos discretos e semânticos. Não é perfeito, já que em troca dos ganhos tornados possíveis com o CSS, nós perdemos outros. Alinhar colunas é definitivamente um problema no CSS, e o espaçamento de células também.

O modelo visual do CSS é todo em linhas e caixas. Essa é a idéia dos grids, certo? Bom, com certeza, se quisermos assim. Aí é que está a diferença fundamental. O CSS nos permite pegar uma caixa – qualquer uma – e fazer o que quisermos com ela, independente das outras caixas (figura 7).

Figure 7

Podemos usar uma propriedade de posicionamento ou "flutuar" (float) a caixa, e podemos adicionar imagens leves como fundo dos elementos. Ainda que estejamos trabalhando com caixas, podemos apresentar estas caixas em inúmeras formas visuais e técnicas eficientes. Isto inclui grids, mas também permite a criação muito mais eficiente de layouts sem grid, como você pode ver no Blood Lust de Dave Shea, um dos layouts que ele criou para o CSS Zen Garden (figura 8).

Figure 8: CSS Zen Garden: Blood Lust

A figura 9 mostra as caixas que criaram o design desconstruído do Blood Lust, de novo demonstrando como o CSS nos permite criar grids desconstruídos usando caixas que estão relacionadas, mas são independentes umas das outras.

Figura 9

Assim que entendermos o que podemos fazer com uma caixa, nossa habilidade em se livrar do grid que nos aprisionou por tanto tempo se torna muito mais clara. Considere este design (figura 10), que pode ser considerado altamente desconstruído, e até espontâneo:

Figura 10: Kutztown University: Communication Design Department

E as caixas posicionadas com o uso de CSS:

Figura 11

Além do código de tornar mais simples, o CSS é muito fácil para qualquer designer familiarizado com layout em CSS. E ainda, a apresentação na tela é incomum e rica, e mostra que um design sem grid pode ser concebido e útil também.

Para dentro da grande abertura

A beleza e o desafio de trabalhar com layouts modernos é que agora temos opções. Com CSS, temos maneiras de criar designs gerenciáveis, leves e visualmente ricos que podem ser grids se quisermos. Mas podemos também facilmente desconstruir o grid ou dispensá-lo completamente. Isto abre um mundo de oportunidades para o web designer contemporâneo. Mas o desafio remanescente é pensar nestas opções ao invés de voltar para os layouts em grid só porque eles são familiares.

Para aqueles que vêm de anos trabalhando com layouts baseados em tabelas, o desafio é especialmente difícil. Para muitos web designers veteranos, mudar a maneira de pensarmos como apresentar nosso conteúdo sem tabelas significa nos livrarmos de um sistema que usamos por tanto tempo. Para alguns, isto vem facilmente, mas para a vasta maioria de nós, é difícil fazer a troca. Parte da resposta está em nos educarmos sobre a maneira que o CSS e os modelos de navegadores funcionam, mas outra parte está em ter força de vontade de deixar as convenções para trás.

Existe uma nova criança no pedaço, e seu nome é "Eu nunca criei um site com uma tabela na minha carreira." Para ela, nossos velhos métodos parecem estranhos e restritos, e é nesta geração que muito provavelmente veremos mais divergências sobre as convenções de design que emergiram na última década.

A web está ficando madura, nossas relações com ela estão mudando, nossas oportunidades de inovação e criatividade estão mais aparentes do que nunca. Não estamos limitados a uma cidade planejada; podemos criar designs únicos e fazê-los funcionar bem. Como uma força conjunta, os poderosos veteranos e a juventude espontânea de hoje inspiram uma noção provocante de que o jeito que a web se parece hoje não é nada do que ela vai parecer amanhã. E para a maior parte, tenho certeza que irá concordar que isto é muito bom.

Leitura relacionada

A autora gostaria de dar crédito aos artigos de sistema de grids de Mark Boulton e ao livro Making and Breaking the Grid , de Timothy Samara, Rockport Publishers, 2002.

-----

Este artigo foi publicado originalmente na edição 209 da A List Apart e pode ser acessado aqui.

Traduzido por Luciano Rodrigues.

Formulários Sensíveis: Um Checklist das Usabilidades de Formulários

por Brian Crescimanno

Computadores deveriam tornar nossas vidas mais fáceis, não mais difíceis. Como designers conscientes sobre usabilidade, podemos fazer as vidas de nossos usuários mais fáceis pensando na maneira como as pessoas interagem com nossos websites, provendo direções claras, e colocando o peso de organizar os detalhes nas mãos do computador – e não dos usuários.

É desta última que iremos tratar aqui. Todos nós ouvimos e lemos sobre os grandes erros de usabilidade de tempos em tempos: "Não use navegação com imagens ou Flash", "Não use Javascript para links", e eu certamente espero que estejamos todos aplicando estas lições aos nossos trabalhos. Geralmente são os menores erros de usabilidade que trazem as maiores dores de cabeça para os usuários, principalmente quando se trata de formulários HTML. Siga estas regras, e você já terá um bom começo.

Use o campo correto para a tarefa

Com tantos elementos de formulários para escolher, cada um com suas vantagens e desvantagens, pode ficar difícil decidir qual elemento usar numa determinada situação. Use radio buttons, checkboxes e select boxes apropriadamente: Para radio buttons e checkboxes, use as tags <fieldset> e <legend> para agrupar logicamente os elementos dentro de um tópico óbvio. Este agrupamento mantém o formulário gerenciável para os usuários, já que ele pode ser quebrado em partes menores em suas cabeças.

Jakob Nielsen oferece estas recomendações para uso de checkboxes ou radio buttons:

• Radio buttons são usados quando existe uma lista de duas ou mais opções que são mutuamente exclusivas e o usuário deve escolher exatamente uma delas. Em outras palavras, clicando num radio button não-selecionado fará com que qualquer outro botão da lista seja desselecionado.
• Checkboxes são usados quando existem listas de opções e o usuário pode selecionar qualquer número de opções, incluindo nenhuma, uma, ou várias. Em outras palavras, cada checkbox é independente dos outros na lista, então selecionando um box não desseleciona os outros.
• Um checkbox sozinho é usado para uma opção única que o usuário pode selecionar ou não.

Fonte: " Checkboxes vs. Radio Buttons ."

Para campos em que uma única opção é necessária e existe um número grande de opções, pense em usar um drop-down para manter a aparência da tela. A barreira entre o que faz sentido como radio buttons e select boxes é algo como uma neblina e dependerá do contexto. Se você vai precisar de 5 ou mais radio buttons, talvez seja a hora de mudar para um select.

Se o campo permite opções múltiplas, se esforce ao máximo para evitar as tão comuns "multi-select boxes". Este elemento, na melhor das hipóteses, confunde o usuário, e na pior, torna o formulário inútil para aqueles que não entendem imediatamente sua funcionalidade. Se o número de opções for tão grande a ponto de se tornar um grande vulto representado como checkboxes, pense em consolidar algumas opções categorizando-as hierarquicamente para ficar mais fácil de entendê-las.

Dê espaço para eles digitarem

Tão importante quanto fazer a escolha certa de campo é especificar corretamente seus tamanhos. Só porque seu nome é Joe Tod não significa que outros usuários não precisarão de mais espaço para digitar seus nomes. Ofereça no mínimo 20 caracteres para os campos de nome e sobrenome. Além disso, não faça com que o tamanho do campo ocupe menos área do que o que deve ser digitado. Para text areas, faça questão de dar ao usuário espaço suficiente para digitar e ler seu texto. Colunas muito altas e estreitas são tão difíceis de ler como as baixas e largas. O valor exato vai variar dependendo do seu uso mas podemos estabelecer um mínimo de 50 caracteres de largura por 10 linhas de altura para garantir a leitura.

Encurte seus formulários e coloque campos "obrigatórios"

Para deixar seu formulário o mais conciso possível, recomendo uma verificação em dois passos para cada elemento do formulário. Para começar, pergunte a você mesmo as seguintes perguntas sobre cada elemento:

• Esta informação é valiosa para nós?
• Esta informação é tão valiosa que vale a pena negar o acesso do usuário se ele não quiser passá-la?

Um dos exemplos mais óbvios de um elemento que não passa no primeiro teste é a saudação. Geralmente não temos nenhum benefício real ao coletar esta informação, então por que estamos pedindo que o usuário nos dê? Não desperdice o tempo dos usuários pedindo informações inúteis.

O segundo teste ("devemos tornar este campo obrigatório?") é um pouco mais subjetivo. Um exemplo é o número do telefone. Existem muitas circunstâncias em que seria interessante ter o número do telefone. No entanto, ele geralmente não é obrigatório para continuar a transação. Devolva a escolha para as mãos do usuário.

Marque os campos obrigatórios claramente

Alguns campos devem ser preenchidos para completar a transação: se você está vendendo um bem físico, você obviamente vai precisar de um endereço de entrega. Como mensagens de erro, dê dicas visuais aos usuários para quais campos são obrigatórios. Muitas vezes, autores de formulários usam negrito ou itálico para demonstrar quais campos são obrigatórios e esperam que o usuário faça essa associação. Existem muitas outras opções explícitas que você pode usar para chamar a atenção para campos obrigatórios. Você pode usar um asterísco, "obrigatório" em parênteses depois do campo, ou podemos dividir o formulário em duas seções: informações obrigatórias e opcionais. Em qualquer caso, se você está usando qualquer tipo de símbolo ou destaque para se referir a campos obrigatórios, você deve oferecer uma legenda de fácil acesso que notifica o usuário sobre o significado dos símbolos.

Eu desaconselho o uso do vermelho para campos obrigatórios, porque esta cor geralmente indica um erro ou um aviso. Como discutirei em breve, você deveria oferecer fortes dicas visuais para indicar erros, então escolha uma cor que não será confundida com mensagens de erro.

Ofereça rótulos descritivos para todos os seus campos

Qual a vantagem de um campo de formulário que você não sabe o que digitar? Utilize a tag <label> para garantir acessibilidade a todos os usuários. Além disso, tenha certeza que seus rótulos (labels) são suficientemente descritivos para que os usuários não se questionem o que inserir naquele campo. Os nomes dos campos devem ser concisos e claros. Se informações adicionais ajudarem, o XHTML 1.1 possui a tag <caption> para inserir uma legenda descritiva e oferecer uma acessibilidade adequada. Para os menos aventurados, você pode sempre criar pequenas legendas de texto usando XHTML 1.0 e CSS.

Deixe o computador, e não o usuário, tratar o formato da informação

Poucas coisas confundem tanto os usuários como pedir que eles insiram a informação num formato específico. Pedidos de formato para informação como números de telefone são particularmente comuns. Existem muitas maneiras que estes números podem ser representados:

• (800) 555-1212
• 800-555-1212
• 800.555.1212
• 800 555 1212

No final, o formato que gostaríamos é aquele que contém somente números:

• 8005551212

Existem três maneiras de tratar isso. O primeiro método diz para o usuário que um formato específico de inserção é necessário e o devolve para o formulário com uma mensagem de erro se ele não consegue seguir esta instrução.

O segundo método é dividir o campo do telefone em três. Este método apresenta ao usuário duas impactantes barreiras de usabilidade para atravessar. Primeiro, o usuário pode tentar digitar todos os números de uma vez e se irritar porque eles acabaram de digitar o telefone completo num campo que só aceita três dígitos. A solução "ingênua" para este problema seria usar Javascript para passar automaticamente para o próximo campo quando o limite de dígitos for alcançado. Alguém aqui já usou esse tipo de formulário e passou pelo ridículo processo de tentar voltar o foco para o que o Javascript vê como um campo preenchido? Levante a mão; não tenha vergonha! Sim, eu vejo todos vocês.

Seja razoável; nós temos tanto medo de expressões regulares (regular expressions) que não conseguimos tirar caracteres excedentes de um único campo? Deixe os usuários digitarem seus telefones como eles quiserem. Podemos usar um pouquinho de programação para filtrar o que não precisamos.

Use mensagens de erro informativas

Quando comecei a trabalhar neste artigo, falei com a minha mãe, uma típica dona de casa, sobre o assunto. A questão dos erros de formulários foi a primeira coisa que ela falou, ou melhor, reclamou. Quando ela tentou fazer um pedido de um presente de Natal por um website recentemente, ela preencheu o formulário e clicou no botão "Comprar". Depois disso ela foi enviada de volta ao formulário com as palavras "Erro no Cartão de Crédito" em negrito e vermelho no topo da tela. Confusa, ela procurou pelo formulário para encontrar qualquer indicação de onde o erro tinha acontecido. Não encontrando nada, ela procurou de novo para achar o campo do cartão de crédito. Ela conferiu o número e a data de validade. Ela conferiu até seu nome, mas a cada vez que ela enviava o formulário, o mesmo erro era exibido.

No final, o problema era que o sistema de processamento de cartão de crédito do site estava fora. Nada que ela pudesse fazer com o formulário faria alguma diferença. Retornar um usuário para esta situação só os faz se sentirem ignorantes, e acredito que podemos concordar que insultar um usuário não está entre nossos melhores interesses.

Existem muitos passos que podemos tomar para tratar melhor os erros em formulários HTML. Primeiro , e mais importante, podemos oferecer mensagens mais informativas. Substituir mensagens encriptadas como "Erro no Cartão de Crédito", por mensagens de acordo com o contexto:

• "Ocorreu um erro no nosso sistema de processamento de Cartões de Crédito. Seu cartão não foi cobrado. Por favor, tente mais tarde ou entre em contato diretamente pelo telefone..."
• "Ocorreu um erro ao processar seu cartão de crédito; não foi possível verificar o número do cartão. Por favor, confira seu nome, número do cartão e data de validade do cartão. Lembre-se que eles devem estar idênticos ao que está no cartão"

Estas mensagens de erro estão completas e dizem ao usuário o que aconteceu. Estas mensagens também direcionam os usuários para possíveis soluções ao invés de simplesmente informá-los o que está errado e esperar que eles inventem suas próprias soluções.

O próximo passo que podemos tomar para evitar erros confusos é oferecer algumas dicas visuais de onde está o problema; não deixe seus usuários caçarem sozinhos as áreas com problemas. Com um pouco de CSS, você pode modificar o formulário original de diversas maneiras para que o usuário possa facilmente identificar os elementos que precisam ser corrigidos. Você também pode usar CSS para esconder campos que já foram preenchidos corretamente e só exibir aqueles que precisam ser corrigidos. Podemos fazer isso para grupos de campos (como a informação exigida para a validação do cartão de crédito) usando a tag <fieldset>.

Não retorne usuários para formulários alterados

Quantas vezes você digitou suas informações num formulário e clicou em enviar só para descobrir que deixou um campo obrigatório vazio? Se você se parece o mínimo comigo, acredito que isso aconteça com uma certa frequência. Enquanto pode ser só o preço que pago por enganar o formulário e tentar passar por ele o mais rápido possível, eu não deveria voltar para um formulário alterado se eu cometesse um erro.

Quando enviei meus dados, eu cliquei na opção em que disse que concordo com os termos de serviço. Eu também preenchi minha senha. E, se me lembro bem, eu definitivamente não cliquei naqueles boxes que dizem "Insira meu e-mail no maior número de listas possível". Então por que tantas vezes eu recebo um formulário preenchido pela metade?

Este exemplo é realmente uma combinação da preguiça do desenvolvedor com técnicas super- conservadoras de marketing. (Apesar de que o campo da senha voltar vazio seja uma precaução legítima de segurança). Para os departamentos de marketing por aí: lembre-se que marketing é satisfazer as necessidades do consumidor. Se a necessidade de um usuário é não receber suas solicitações, você deveria respeitar isso ao invés de tentar jogar as pessoas numa coisa que eles já disseram que não querem. E para os desenvolvedores, tenha certeza de que está populando cada elemento do formulário que o usuário já enviou. Não há razão para que eles tenham que re-aceitar seus termos de serviços ou entrar com a informação uma segunda vez por causa de um pequeno engano.

Lembre-se, quanto mais controle os usuários têm sobre sua experiência, mais felizes eles ficarão ao usar seu website.

-----

Este artigo foi publicado originalmente na edição 209 da A List Apart e pode ser acessado aqui.

Traduzido por Luciano Rodrigues.

Flash Satay: Inserindo Flash de acordo com os padrões

por Drew McLellan

Tenho trabalhado com Flash durante muitos anos e estou ligeiramente descontente com os códigos necessários para inserir uma animação em páginas web. Quando publiquei um site em XHTML, recentemente, meu descontentamento com os códigos tornaram-se maiores, enquanto eu percebia que não era válido e estava levando minhas páginas para níveis inaceitáveis. Um método mais simples de inserção de Flash era necessário.

O Método Requentado

O Flash sempre foi veio com algum método de geração de páginas HTML que contém suas animações. Inicialmente, era uma ferramenta chamada AfterShock. Desde o lançamento do Flash 4, os autores podem exportar páginas HTML com a animação pelo próprio Flash. Este código produzido pelo Flash, de fato, é o padrão que você irá encontrar em 99% dos sites que usam animações Flash.

<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com / pub / shockwave / cabs / flash / swflash.cab#version=6,0,0,0" width="400" height="300" id="movie" align="">

<param name="movie" value="movie.swf">

<embed src="movie.swf" quality="high" width="400" height="300" name="movie" align="" type="application/x-shockwave-flash" pluginspace="http://www.macromedia.com/go/getflashplayer">

</object>

Como você pode ver, é um pequeno monstro. Existem duas tags principais usadas para inserir a animação, fazendo com que todos os valores sejam declarados duas vezes. O Internet Explorer e os navegadores baseados nele usam uma tag; navegadores que são baseados no Netscape usam a outra. Chamemos isto de Método Requentado.

O elemento <object> é parte da especificação do XHTML, mas é mal implementado aqui. Ele é usado pelos navegadores baseados no IE para iniciarem um executável do Player do Flash e carregar a animação especificada. O elemento <param> é seu acompanhante, oferecendo qualquer quantidade de parâmetros desejada a ser passado ao player assim que o mesmo for iniciado.

O <embed> não é parte da especificação XHTML e impedirá sua página de ser válida. Ele é usado pelo Netscape e navegadores baseados nele para a exibição de animações em Flash. Parâmetros são passados dentro do elemento com o par de atributos nome/valor.

O Elemento <embed>

O elemento <embed> foi criado pela Netscape como seus métodos de inserção de plugins e players em páginas de internet. Ele não é parte da especificação do XHTML, e mesmo que navegadores diferentes do Netscape suportem-no, ele não é complacente aos padrões, então, está fora.

Tchau tchau, <embed> ... obrigado.

O Elemento <object>

Sem o <embed> , nos sobrou o elemento <object> , então, seria prudente compreender todas as suas capacidades. A grande novidade é que todos os navegadores de uso popular suportam o elemento <object> de uma forma ou de outra.

O elemento <object> não contém atributos obrigatórios, mas muitos estão disponíveis para o uso. Abaixo estão os mais interessantes, junto com alguns destaques da especificação do W3C.

classid (URI) Este atributo deve ser usado para especificar a localização da implementação do objeto via URI. Ele deve ser usado junto ou como uma alternativa ao atributo data (ver abaixo), dependendo do tipo do objeto envolvido.

codebase (URI) Este atributo especifica a base do caminho usado para URIs relativas especificadas pelo classid, data e atributos do arquivo. Quando ausente, seu valor padrão é o URI do documento atual.

data (URI) Este atributo deve ser usado para especificar a localização dos dados do objeto, ou generalizando, uma forma serial do objeto que pode ser usada para recriá-lo.

type (content-type) Este atributo especifica o tipo de conteúdo dos dados especificados no atributo data.

codetype (content-type) Este atributo especifica o tipo de conteúdo dos dados esperados quando baixamos o objeto especificado pelo classid.

Existem outros atributos que permitem fazer referências para a versão do arquivo, texto para ser exibido enquanto carregando (nós já podemos fazer isto pelo Flash), e assim por diante, como width , height , id , class e outros atributos comuns. Os listados acima são particularmente relevantes quando se está inserindo uma animação de Flash.

Outra coisa interessante que aprendi é que uma tag <object> pode conter elementos filhos que podem ser usados como alternativas se o navegador não possuir capacidade de exibir o objeto. De fato, é como o desagradável <embed> trabalha em navegadores Netscape - mas voltaremos nisso mais tarde.

O Processo

Armado com uma compreensão maior da codificação, comecei a testar em vários navegadores. Meu primeiro passo foi tentar a codificação da Macromedia com o <embed> removido e um XHTML limpo:

<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com / pub / shockwave / cabs / flash / swflash.cab#version=6,0,0,0" width="400" height="300">

<param name="movie" value="movie.swf" />

</object>

Infelizmente, este formato simples não funciona em navegadores não-baseados no IE. Depois de uma pequena acrobacia e algumas pesquisas no Google, descobri que o GUID usado no atributo classid era específico para a configuração ActiveX do navegador. Na verdade, isto estava fazendo com que o Netscape 7 e o Mozilla ignorassem completamente o arquivo. O atributo classid desempenha, de qualquer forma, uma função importante: diz ao navegador qual plugin utilizar. Então não podemos simplesmente removê-lo sem substituir sua função com alguma outra coisa.

Felizmente, o plugin do Flash está configurado para responder a conteúdos com o tipo MIME definidos para application/x-shockwave-flash . Isto é ótimo, porque o atributo type nos permite especificar um tipo de conteúdo. Portanto, sai:

classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"

... e entra:

type="application/x-shockwave-flash"

Codebase

A mudança acima por si só não faz com que as animações funcionem em navegadores Netscape. A próxima curiosidade da lista é o atributo codebase . Ele contém um caminho para uma cópia do plugin do Flash nos servidores da Macromedia. Isto é na verdade um uso incorreto do atributo, já que qualquer caminho dentro dele deveria estar no próprio domínio - por motivos de segurança.

Em muitos navegadores (principalmente no IE) este atributo desempenha outra função. O caminho contém uma especificação no fim que especifica qual versão do plugin o servidor deve enviar. Se a versão declarada for superior à versão atualmente instalada, o navegador pedirá ao usuário permissão para atualização. O lado ruim é que este atributo impede a animação de funcionar no Netscape e Mozilla quando utilizado desta forma, então ele deve sair. Discutiremos uma saída para esta funcionalidade mais a frente. Com o atributo codebase fora, nossa codificação está começando a ficar mais agradável:

<object type="application/x-shockwave-flash" width="400" height="300">

<param name="movie" value="movie.swf" />

</object>

Tente este código, e ele ainda não carregará a animação no Netscape. Chegando tão longe, achei que não existissem formas de usar uma codificação válida para colocar Flash em navegadores Netscape, e todas as respostas online para esta pergunta me disseram a mesma coisa. Então fiz o que eu sempre faço e comecei a testar coisas loucas.

Tendo Progresso

Quando tentei o atributo data, eu quase pulei de alegria, pois as animações repentinamente começaram a funcionar no Netscape e Mozilla. Retornando ao IE revelou que as animações funcionaram lá também.

<object type="application/x-shockwave-flash" data="movie.swf" width="400" height="300">

<param name="movie" value="movie.swf" />

</object>

Após testar com algumas animações pesadas, percebi algo estranho. Enquanto todos os navegadores estavam funcionando normalmente, IE/Windows não estava rodando - ele esperava pelo carregamento completo da animação antes de começar a apresentá-la. Isto é bom para animações pequenas, mas para algo sério, a perda da auto-reprodução é inaceitável. Percebi que era possível uma codificação válida para animações em Flash, mas somente quando a Microsoft tiver corrigido este problema com o IE/Windows.

O Método Satay

Alguns dias depois eu estava discutindo o ocorrido com Jeffrey Zeldman, expliquei como cheguei perto de uma solução mas não a encontrei. Ele ficou interessado por eu ter chegado perto, tendo experimentado o problema ele mesmo em projetos recentes. Isto me fez pensar, e enquanto dirigia de volta para casa, me veio a solução.

O único problema com o código que tinha era que o IE/Windows não auto-iniciava a animação. Ele aguarda o carregamento de toda a animação para iniciá-la. Isto é ótimo para animações bem pequenas, já que a espera não é perceptível. Então, que tal criar uma animação bem pequena como recipiente, na qual em seu primeiro frame carregue a animação que nós realmente queremos exibir?

Eu testei a possibilidade, e funcionou. É meio que um "hack", mas válido e justificável em minha opinião. A melhor coisa é que você não tem que criar uma "animação recipiente" para cada animação "verdadeira" - um pequeno recipiente pode funcionar com qualquer animação de Flash tendo as mesmas proporções.

Não importa se sua animação é feita de bife, carne de frango, ou carne de porco, você ainda precisa batê-lo e mergulhá-lo no molho para fazê-la funcionar. Nós chamamos isto de Método Satay.

A Animação Recipiente

Eu criei uma nova animação em Flash e inseri o seguinte ActionScript no Frame 1 diretamente na raíz da animação:

_root.loadMovie(_root.path,0);

Isto instrui o Flash-player a carregar uma animação, cujo nome está na variável path na raíz, no Nível 0 da animação atual. Tudo o precisamos é nos certificarmos de que o nome da animação que desejamos carregar está na variável path.

O Flash torna esta parte fácil. O player carrega qualquer nome/valor que seja passado para uma animação de Flash em uma variável na raíz da animação. Isto é útil para diversas aplicações, mas em nosso caso significa que precisamos apenas chamar a animação desta forma:

c.swf?path=movie.swf

A animação recipiente é c.swf . Estou passando para ela uma variável chamada path com o valor de movie.swf . Isto significa que nosso ActionScript, quando processado, se tornará isto:

_root.loadMovie("movie.swf",0);

Você pode modificar o comportamento da animação recipiente para fazer qualquer coisa que você deseje - desde que continue pequena. Você pode utilizar o método GET ou POST para passar as variáveis para o recipiente caso você necessite, por exemplo. No entanto, este método só funcionará bem se o recipiente possuir um tamanho de alguns Kb.

A Codificação

Isto nos deixa somente com a codificação para finalizar. Nós sumimos com diversos atributos, adicionamos alguns novos e remodelamos tudo:

<object type="application/x-shockwave-flash" data="c.swf?path=movie.swf" width="400" height="300">

<param name="movie" value="c.swf?path=movie.swf" />

</object>

Então aí está - simples, limpo e muito melhor para a interpretação. Mas e quanto à funcionalidade que perdemos ao remover o atributo codebase?

Compensando

O principal problema com a remoção do atributo codebase é que no IE e navegadores similares ele não informará mais sobre atualização do Flash Player. Isto é realmente útil, porque é, de fato, a única forma que a maioria dos usuários têm de manter seus players atualizados.

O trabalho é simples: apenas inclua uma sacrificante animação na página inicial do seu site com o atributo codebase incluso nela. Precisa ser uma animação sem nenhum propósito com o site - apenas uma animação em branco de 1Kb que avise o usuário caso ele tenha uma versão antiga do plugin. Não é uma solução limpa, mas é prática. Você não deve perder nenhum amigo com isso.

Conteúdo Alternativo

Lembra do comportamento da tag <object> que eu estava comentando antes, onde o navegador tentará executar um elemento filho se não conseguir funcionar pelo próprio objeto? É muito legal.

Se você olhasse o código fonte da página inicial da Macromedia.com, você veria que eles inserem uma imagem alternativa se o usuário não puder visualizar as animações em Flash. Eles detectam o Flash Player com JavaScript, e então usam JavaScript para escrever o HTML dinamicamente baseado na detecção. Feio, feio, feio. Eu faria assim:

<object type="application/x-shockwave-flash data="c.swf?path=movie.swf" width="400" height="300">

<param name="movie" value="c.swf?path=movie.swf" />

<img src="noflash.gif" width="200" height="100" alt="" />

</object>

Se o navegador não sabe como executar objetos com o tipo MIME de application/x-shockwave-flash , ele simplesmente irá para o próximo elemento filho e tentará executá-lo. Eu imagino que uma simples imagem deve estar de bom tamanho para a maioria das pessoas. Se ainda não funcionar, você pode simplesmente usar um texto.

Trabalho em progresso

Eu escrevi este artigo como um simples homem em busca do conhecimento, e dessa forma, um trabalho em progresso. Considere-o como uma teoria científica: o que eu digo hoje só é verdadeiro até que seja desmentido.

-----

Este artigo foi publicado originalmente na edição 154 da A List Apart e pode ser acessado aqui.

Traduzido por Rafael Cesar.

Web 3.0

por Jeffrey Zeldman

O Google, com a cooperação de renomadas bibliotecas, têm digitalizado livros para torná-los encontráveis. A prática excita os futuristas mas aborrece algumas editoras. Por necessidade, a digitalização cria cópias virtuais. As editoras reclamam que tal cópia viola os direitos autorais, mesmo que o conteúdo do livro esteja escondido do público. A Biblioteca Pública de Nova York, um dos parceiros do Google no projeto, recentemente organizou um debate público sobre o assunto.

Foi enquanto eu esperava por este debate que meu desconforto com a recente onda de um emergente gênero de desenvolvimento web se tornou num ódio mortal.

O grande salão estava lotado. Havia mais ingressos do que cadeiras. Mesmo assim, a poltrona na minha frente permanecia vazia. Cada vez que um esperançoso espectador se aproximava da cadeira – e isso acontecia a cada nanosegundo – o pobre desconhecido da cadeira ao lado tinha que explicar se desculpando, "Desculpe, a poltrona está ocupada."

Logo se tornou claro que o gentil desconhecido estava reservando o lugar, não para um amigo ou colega, mas para um estranho que impôs a tarefa a ele. Enquanto o camarada defendia a poltrona do outro contra uma chuva de participantes, o estranho estava em algum outro lugar mandando ver na champagne que a biblioteca oferecia. Eu fiquei imaginando que tipo de mané pediria a alguém que ele não conhece para guardar seu lugar por meia hora num evento lotado. Quando ele finalmente chegou, eu descobri.

Sinto cheiro de mané

"Você estava na conferência de Web 2.0?", o cara que chegava perguntou, como para agradecer ao outro por ter guardado seu lugar. O gentil desconhecido indicou que não. Isto era todo encorajamento que nosso homem precisava para iniciar um monólogo rico em adjetivos, pobre em fatos e alto o bastante para que metade do salão ouvisse.

De repente parecia que a Web 2.0 não era somente maior que o Apocalipse, mas também mais vantajosa. Vantajosa, quer dizer, para investidores como este cara. Ainda assim, esta nova onda não deve ser confundida com o "boom das .com" do fim dos anos 90:

"A Web 1.0 não era transgressora. Você entende? A Web 2.0 é totalmente transgressora. Você sabe o que é XML? Já ouviu falar de sites bem estruturados? Certo. Bom, de qualquer forma…"

E assim foi, como uma maquininha de obturação.

Primeiro eu tolerei a dor, modificando aquela famosa cena de Annie Hall ("Noivo Neurótico, Noiva Nervosa", filme de 1977 dirigido por Woody Allen):

ELE: Eu ministro um workshop de investimento de risco, então acho que minhas opiniões sobre XML são um tanto quanto válidas.

EU: "Ah, sério? Porque por acaso eu tenho o Mr. Bray aqui mesmo."

Depois eu comecei a morder meus dedos. Num determinado ponto, numa espécia de febre, eu provavelmente gemi. Abençoadamente, as luzes se apagaram e os verdadeiros falantes ganharam a noite.

Mas engolir os pensamentos daquele mané deixou um gosto ruim.

Menos barulho, mais sinal

Agora vamos definir e discordar.

O cara no evento da biblioteca estava apaixonado pelo seu próprio barulho, e o problema com braulho é que ele interfere nos sinais. Qual é o sinal? O que, se for alguma coisa, significa Web 2.0? Qual é a coisa boa que a moda pode esconder?

Bom, existem muitas coisas boas, me parece.

Alguns pequenos times de pessoas antenadas – pessoas que antes, talvez, trabalhavam para aqueles com visões mais limitadas – estão agora seguindo seus próprios instintos e desenvolvendo aplicações web inteligentes. Produtos como o Flickr e o Basecamp são divertidos, bem feitos e fáceis de usar.

Isto pode não parecer muito. Mas nosso meio é um em que, frequentemente, grandes times têm lentamente e custosamente trabalhado para produzir aplicações web complexas cuja usabilidade é praticamente nula e para clientes que possuem, na melhor das hipóteses, alguns vagos objetivos. A percepção de que times pequenos e auto-dirigidos suportados pelo Princípio de Pareto podem criar rapidamente coisas enxutas e que funcionam melhor não é meramente robusto mas também dinâmico. Assim como 100 bandas de garagem surgiram para cada disco do Velvet Underground vendido, a percepção de que um time pequeno pode fazer bem feito motiva 100 outros a tentarem.

Os melhores e mais famosos destes novos produtos web (como os dois que acabei de citar) agrupam comunidades e colaboração, oferecendo novas e enriquecidas maneiras de interação pessoal e profissional. A melhor de suas virtudes é que eles dominam suas categorias, o que é bom para os criadores, pois assim eles são pagos.

Também é bom para a indústria, porque a prospecção de riquezas inspira desenvolvedores espertos que antes passivamente recebiam ordens para começar a pensar em usabilidade e design, a tentar resolver problemas num nicho que eles podem dominar. Fazendo isso, alguns deles podem criar empregos e riquezas. E mesmo onde o dia de trabalho seja mais barato, este desenvolvedores podem alcançar o patamar de usabilidade e design. Isto é bom para todos. Se consumidores podem escolher aplicações melhores que custam menos ou são gratuitas, então a web trabalha melhor, e é mais provável que clientes peçam um bom (em usabilidade e design) trabalho ao invés do usual refugo.

É disso que eles se aproveitam

Além de favorecer soluções mais simples construídas por times mais simples, a coisa chamada de Web 2.0 costuma ter características tecnológicas em comum.

Por trás, ela é quase sempre provida de tecnologias de código aberto como PHP ou (especialmente) Ruby on Rails.

Na frente, é construída principalmente com os padrões web – CSS para layout, XML para dados, XHTML para marcação, Javascript e o DOM para o funcionamento – com algumas coisas da Microsoft no meio.

Quando os padrões com algumas coisas da Microsoft no meio são criados para criar páginas que podem interagir com o servidor sem recarregamento, o resultado são aplicações web iluminadas e, podemos até dizer, parecidas com Flash. Num relatório que foi realmente lido, o escritor / consultor Jesse Garrett deu um nome para o que eu acabei de descrever. Ele chamou de AJAX, e a abreviação não só pegou como também ajudou a interatividade provida destas tecnologias a ganhar espaço no mercado.

Aqui é onde os malandros enganam os confusos. Imagine o seguinte cenário:

Steven, um jovem guru da web, acaba de comemorar seu Bar Mitzvah. Ele recebeu uma dúzia de presentes e deve escrever uma dúzia de notas de agradecimento. Sendo um fã da web, ele cria um "Gerador de Notas de Agradecimento" online. Steven mostra o site para seus amigos, e logo o site ganha tráfego de todos os tipos de presentes, não só os de Bar Mitzvah.

Se Steven criasse o site com CGI e Perl e usasse tabelas para o layout, esta seria a história de um garoto que fez um website para seu próprio uso, talvez ganhando alguma moral no processo. Ele poderia até contribuir num painel da SXSW Interactive.

Mas Steven usou AJAX e Ruby on Rails, o Yahoo pagará milhões e Tim O´Reilly vai implorar para que ele dite as regras.

Quem se importa com o AJAX?

Vamos parar por um momento para considerar duas dores de cabeça relacionadas ao AJAX.

A primeira afeta o pessoal que faz websites. Desenhar AJAX é um saco. O melhor que nossa agência conseguiu foi a abordagem de Chuck Jones: desenhar os traços. Chuck Jones tinha uma vantagem: ele sabia o que o Pernalonga ia fazer. Nós temos que determinar todas as coisas que o usuário pode fazer, e prever os abençoados momentos de cada possibilidade.

O segundo problema afeta todos que usam um site feito com AJAX. Se os significados e convenções da web ainda estão em sua infância, então os significados relacionados ao AJAX estão no útero. Eu ainda estou descobrindo funcionalidades do Flickr. Não novas funcionalidades – as velhas. Você encontra algumas clicando num espaço em branco. Isto é como ler o jornal tendo que passar o "Detector de Tinta Invisível ACME" em todas as partes de papel que você ver até que você encontre algum que tenha uma palavra.

Não estou menosprezando o Flickr. Eu amo o Flickr. Eu gostaria de ter o dom das pessoas que o criaram. Estou simplesmente apontando problemas de design que não serão solucionados da noite para o dia ou por um único grupo. No Ma.gnolia, que está em beta, nós usamos pequenos ícones para indicar que outras ações poderiam ser tomadas e dar uma dica do que estas ações seriam. Nós tivemos sucesso ao perceber que desenhos de 16 por 16 px podem expressar conceitos como "você pode editar estas palavras clicando nelas".

Estes e outros problemas serão resolvidos, muito provavelmente por alguém que está lendo esta página. Alguém que direcione estas questões principalmente para reprimir uma emergente euforia impensada.

Bolha, bolha

Quando comecei a desenhar websites, se o cara do meu lado no avião me perguntasse o que eu fazia, eu tinha que dizer algo como "marketing digital" se quisesse evitar aquela cara de interrogação.

Alguns anos depois, se eu dissesse para o passageiro do meu lado que eu era um web designer, ele iria me parabenizar com um respeito geralmente reservado para um rock star ganhador do Prêmio Nobel.

Então a bolha estourou, e a mesma resposta para a mesma pergunta provocava olhares de pena e de desgosto contido. Me lembro de encontrar um grande empresário no início dos anos 2000 que me perguntou o que eu fazia. Eu deveria ter dito que fico rodeando playgrounds, roubando o dinheiro do lanche das crianças. Ele teria mais respeito por esta resposta.

Eu odiava a bolha. Eu odiava quando a Vanity Fair ou a New York Magazine tratavam fundadores de agências de web como celebridades. Eu odiava aquela mídia de massa e a sociedade que a consome ignorou a web ou a confundiu com uma versão eletrônica e sofisticada da indústria da moda.

Quando a bolha estourou, estes mesmos gênios decidiram que a web não tinha mais interesse nenhum. Engraçado, para mim estava mais interessante do que nunca. Para mim eram pessoas e organizações publicando conteúdo que de outra maneira nem poderiam nascer. Eram pequenas empresas com metas reais entregando valor e crescendo. Eram escritores tradicionais encontrando seu caminho num novo meio digital, ajudados pelos caras como eu e você. Eram novas maneiras de se falar e compartilhar e amar e vender e curar e ser. Incrivelmente imbecil.

De repente os desinformados deixaram de ver um deserto e começaram a ver bloggers, aos quais eles se referiam apenas àqueles que escreviam sobre política, geralmente de extrema esquerda ou direita. A web estava de volta mesmo que ela nunca tenha ido. (É claro, na quinta vez que você ouvir o Wolf Blitzer [jornalista da CNN] dizer "blogger" ou perguntar, "o que os bloggers têm a nos dizer sobre estes eventos de última hora?" a piada perde a graça e você deseja que aqueles que não entendem a web voltem a ignorá-la.)

Mas nada, nem mesmo a histeria dos bloggers políticos, foi tão excitante como a descoberta do dinheiro. Assim que as primeiras propriedades da Web 2.0 corretamente avaliadas começaram a encontrar compradores, uma loucura como aquela outra repentinamente voltou à vida. Quanto o Yahoo gastou? Quem o Google comprou? Ali muito sangue foi derramado.

Mas como convencer os outros tubarões do tanque que este banquete de sangue era diferente do primeiro boom? Simples: disfarce tudo que veio antes como "Web 1.0"

São apenas castelos queimando

Para aqueles que estão batalhando em cima de um software social baseado em AJAX e Ruby, boa sorte, Deus abençoe, e divirtam-se. Lembrem-se que outras 20 pessoas estão trabalhando na mesma idéia. Então deixe-a simples, e lance-a antes que outros o façam, e mantenha seu senso de humor mesmo que você fique rico ou se quebre. Principalmente se ficar rico. Nada é mais desagradável do que um típico multi-milionário.

Para aqueles que se sentem fracassados porque passaram o ano todo aprimorando suas técnicas de web e atendendo clientes, ou tocando seu próprio negócio, ou talvez publicando conteúdo, vocês são especiais e queridos, então mantenha a cabeça erguida, e nunca deixe que alguém veja suas lágrimas.

Quanto a mim, estou cortando o caminho e pulando direto para a Web 3.0. Por que esperar?

-----

Este artigo foi publicado originalmente na edição 210 da A List Apart e pode ser acessado aqui.

Traduzido por Luciano Rodrigues.

Em Busca do Santo Graal

por Matthew Levine

Desculpe. Mesmo. Eu não pretendo sobrepor sua importância ou menosprezar os outros, talvez mais respeitados, Santo Graals.

Mas o nome está aí, e todos nós sabemos o que significa.

Três colunas. Uma barra lateral fixa para sua navegação, outra para, digamos, seus anúncios do Google ou suas fotos no Flickr – e, como num passe de mágica, um miolo líquido para o que realmente interessa. Sua vasta versatilidade nesta época dourada de blogs, em conjunto com sua considerável dificuldade, foi o que deu a este layout o título de Santo Graal.

Muitos artigos foram escritos sobre ele. E muitos templates existem. No entanto, todas as soluções existentes envolvem sacrifício: ordem específica de código, rodapés de largura inteira e código pobre estão geralmente ligados à aplicação deste vago layout.

Um projeto recente levou minha busca pelo Graal ao fim. A técnica que vou descrever permitirá que você aplique o “Santo layout” sem comprometer seu código ou sua flexibilidade. Ele vai:

1. ter um miolo líquido com barras laterais fixas,
2. permitir que a coluna central apareça antes no código,
3. permitir que qualquer coluna seja a mais alta,
4. necessitar de uma única div adicional, e
5. necessitar de um CSS muito simples, com “patches” mínimos.

Nos ombros dos gigantes

A técnica apresentada aqui é inspirada pela brilhante One True Layout, de Alex Robinson. Alex até falou sobre o problema do Santo Graal em seu artigo, mas sua solução precisa de dois boxes externos e dificulta o “padding” sem o uso de uma div adicional em cada coluna.

Outro caminho veio da adaptação de Eric Meyer, que usa posicionamento para misturar diversos tipos de medida. Seu exemplo também conta com um layout de três colunas com laterais fixas e um miolo líquido. Infelizmente, ele se baseia em porcentagem aproximada e ocupa uma porção da área visível que varia dependendo da resolução.

Chega de papo – vamos ver o código

O HTML necessário é intuitivo e elegante.

(Para deixar clara a demonstração desta técinca, estamos intencionalmente usando os ids não-semânticos “center”, “left” e “right”. Recomendamos que você use ids semânticos em qualquer aplicação desta técnica.)

<div id="header"></div>

<div id="container">

<div id="center" class="column"></div>

<div id="left" class="column"></div>

<div id="right" class="column"></div>

</div>

<div id="footer"></div>

É isso. Uma única div adicional que contém as colunas é tudo o que você precisa; isto satisfaz até meus hábitos compulsivos de codificação.

O CSS é quase tão simples. Digamos que você quer uma coluna esquerda com uma largura fixa de 200px e uma coluna direita com uma largura fixa de 150px. Para simplicar os comentários, vou abreviar as colunas da esquerda (left), direita (right) e central (center) como LC, RC e CC, respectivamente. O CSS básico está aqui:

body {

min-width: 550px; /* 2x LC width + RC width */

}

#container {

padding-left: 200px; /* LC width */

padding-right: 150px; /* RC width */

}

#container .column {

position: relative;

float: left;

}

#center {

width: 100%;

}

#left {

width: 200px; /* LC width */

right: 200px; /* LC width */

margin-left: -100%;

}

#right {

width: 150px; /* RC width */

margin-right: -150px; /* RC width */

}

#footer {

clear: both;

}

/*** IE6 Fix ***/

* html #left {

left: 150px; /* RC width */

}

Simplesmente substitua os valores com as dimensões que desejar e ele é todo seu. A técnica funciona em todos os navegadores modernos: Safari, Opera, Firefox e (com o pequeno hack) IE6. Para suportar o IE5.5, precisaríamos de pelo menos um hack de box-model, que deixo como um exercício para o leitor.

Dê uma olhada e se impressione com a elegância.

Como funciona

A estratégia é bem direta. A div externa terá um miolo líquido e “paddings” fixos nas laterais. O truque está em fazer com que a coluna esquerda se alinhe com o “padding” esquerdo e a coluna direita com o “padding” direito, deixando a coluna central preencher a largura variável da caixa externa.

Vamos construir isto passo a passo.

Passo 1: Crie a moldura

Comece com o cabeçalho, rodapé e conteúdo.

<div id="header"></div>

<div id="container"></div>

<div id="footer"></div>

Definimos o padding do conteúdo com a largura que queremos para as colunas esquerda e direita.

#container {

padding-left: 200px; /* LC width */

padding-right: 150px; /* RC width */

}

Nosso layout se parece com isto:

Passo 1: Crie a moldura

Passo 2: Adicione as colunas

Agora que temos nossa moldura básica, vamos nos concentrar nas colunas.

<div id="header"></div>

<div id="container">

<div id="center" class="column"></div>

<div id="left" class="column"></div>

<div id="right" class="column"></div>

</div>

<div id="footer"></div>

Em seguida informamos as larguras apropriadas e definimos o “float” para exibí-las na mesma linha. Também precisaremos ajustar o rodapé para mantê-lo abaixo das colunas com “float”.

#container .column {

float: left;

}

#center {

width: 100%;

}

#left {

width: 200px; /* LC width */

}

#right {

width: 150px; /* RC width */

}

#footer {

clear: both;

}

Perceba que a largura de 100% da coluna central se refere à largura da caixa externa (#container), excluindo o padding. Veremos esta largura de 100% novamente quando o layout estiver completo, e ela vai continuar se referindo a esta largura central da “#container”.

Agora as colunas querem se alinhar na ordem, mas como a coluna central está ocupando 100% do espaço, as colunas esquerda e direita descem.

Passo 2: Adicione as colunas

Passo 3: Puxe a coluna esquerda para seu lugar

A única coisa que falta é alinhar as colunas ao padding da “#container”. A coluna central começa exatamente onde deveria, então vamos focar na esquerda.

São dois passos para colocar a coluna esquerda no lugar. Primeiro, colocaremos ela junto da coluna central com uma margem negativa de 100%. Lembre-se que estes 100% se referem à largura central da “#container”, que é exatamente a largura da coluna central.

#left {

width: 200px; /* LC width */

margin-left: -100%;

}

Agora a coluna esquerda está sobrepondo a central, compartilhando seu lado esquerdo. A coluna direita vai para a esquerda e se aproxima do lado direito da coluna central (mas ainda desce), nos deixando com o seguinte:

Passo 3: Puxe a coluna esquerda para seu lugar – quase lá

Para movermos a coluna esquerda pela distância restante, usaremos um posicionamento relativo com um valor que é exatamente a largura dela.

#container .columns {

float: left;

position: relative;

}

#left {

width: 200px; /* LC width */

margin-left: -100%;

right: 200px; /* LC width */

}

A propriedade right empurra a coluna para 200 pixels da borda direita, ou seja, para a esquerda. Agora a coluna esquerda se alinha perfeitamente com o “padding” esquerdo da “#container”.

Passo 3: A coluna esquerda em seu lugar

Passo 4: Puxe a coluna direita para seu lugar

A única coisa que falta é puxar a coluna direita para seu lugar. Para fazer isso, só precisamos puxá-la para fora da “#container” e dentro do padding. Novamente usaremos uma margem negativa.

#right {

width: 150px; /* RC width */

margin-right: -150px; /* RC width */

}

Agora tudo está em seu luigar, e a quebra desaparece.

Passo 4: Puxe a coluna direita para seu lugar

Passo 5: Desenvolva defensivamente

Se a janela do navegador for redimensionada até que a coluna central fique menor que a esquerda, o layout se quebra num navegador em conformidade com os padrões (standards-compliant). Definindo um min-width no body mantém suas colunas no lugar. Com o IE6 isto não acontece, então o fato de ele não suportar min-width não chega a ser um problema.

body {

min-width: 550px; /* 2x LC width + RC width */

}

É claro, nenhuma técnica de layout estaria completa sem precisar de algum tipo de gambiarra no Internet Explorer. A margem negativa puxa a coluna esquerda além do necessário para o IE6 (a largura inteira da janela). Precisamos empurrá-la de volta com mesma distância da coluna direita – usando o hack da estrela-html para escondê-lo de outros navegadores – e aí estaremos prontos.

* html #left {

left: 150px; /* RC width */

}

O motivo de precisarmos usar a largura da coluna direita envolve um pouco de álgebra. Não vou chateá-los com os detalhes; você pode tentar descobrir sozinho ou simplesmente considerar isto como um dos muitos charmes do IE.

Padding, por favor

Eu não sou designer, mas olhar para o layout acima ofende até meus sentidos sem estética. As colunas grudadas dificultam a visão e a leitura. Precisamos de espaço.

Uma das desvantagens de usar porcentagem com o One True Layout para criar layouts líquidos é que ele dificulta a definição do “padding” das colunas. “Paddings” em porcentagem tendem a ficar feios em algumas resoluções. “Paddings” fixos podem ser definidos, mas só se inserirmos uma div adicional dentro de cada coluna.

Com esta técnica, o “padding” não é um problema. Ele pode ser definido diretamente nas colunas esquerda e direita; simplesmente ajuste a largura correspondente. Para dar um “padding” de 10px à coluna esquerda no exemplo acima, mas manter sua largura (“padding” + largura) em 200px, simplesmente mude o CSS como abaixo:

#left {

width: 180px; /* LC fullwidth - padding */

padding: 0 10px;

right: 200px; /* LC fullwidth */

margin-left: -100%;

}

Aplicar o “padding” à coluna central requer um pouco mais de habilidade, mas nenhum código html e só alguns detalhes no CSS.

O “padding” mais a largura de 100% fazem com que a coluna central fique maior que a largura sem “padding” da “#container”. Para fazer com que ela volte ao lugar, precisamos aumentar a margem direita com o total do “padding”. Isto garante que a coluna central tenha a largura que esperamos.

Além disso, uma vez que a coluna central está maior, a esquerda tem uma distância maior a percorrer para ficar no lugar certo. Aumentando esta distância com o total do “padding” central faz o serviço.

Para concretizar, vou modificar o exemplo para adicionar um “padding” de 10px para cada lado das colunas (num total de 20px), e um “padding” de 20px para cada lado da coluna central (num total de 40px). O novo CSS se parece com isso:

body {

min-width: 630px; /* 2x (LC fullwidth + CC padding) + RC fullwidth */

}

#container {

padding-left: 200px; /* LC fullwidth */

padding-right: 190px; /* RC fullwidth + CC padding */

}

#container .column {

position: relative;

float: left;

}

#center {

padding: 10px 20px; /* CC padding */

width: 100%;

}

#left {

width: 180px; /* LC width */

padding: 0 10px; /* LC padding */

right: 240px; /* LC fullwidth + CC padding */

margin-left: -100%;

}

#right {

width: 130px; /* RC width */

padding: 0 10px; /* RC padding */

margin-right: -190px; /* RC fullwidth + CC padding */

}

#footer {

clear: both;

}

/*** IE Fix ***/

* html #left {

left: 150px; /* RC fullwidth */

}

Logicamente, “paddings” superiores e inferiores podem ser adicionados sem problemas. Veja esta simpática versão com “padding” para o template.

Esta técnica funciona tão bem para sem quanto para pixels. Infelizmente, você não pode misturar ems e pixels, então faça sua sábia escolha.

Colunas de alturas iguais

Esta técnica realmente fica completa quando as colunas ganham alturas iguais. O método que estou usando foi adaptado completamente do One True Layout, então não vou entrar em detalhes. Para aplicá-lo, simplesmente adicione o CSS abaixo:

#container {

overflow: hidden;

}

#container .column {

padding-bottom: 20010px; /* X + padding-bottom */

margin-bottom: -20000px; /* X */

}

#footer {

position: relative;

}

Aqui eu coloquei um “padding” adicional de 10px no inferior das colunas.

Os avisos comuns se aplicam. Fique atento com o bug de overflow:hidden do Opera 8 que deixa todas suas colunas enormes. Uma alternativa é detalhada no One True Layout; você pode usá-la, ou esperar que o Opera 9 (que corrige o bug) saia do beta.

Um outro problema deste layout é que o IE não corta o fundo das colunas no final da “#container”. Eles passam por cima do rodapé se a página não é tão alta quanto a janela. Isto não é um problema se você não tem um rodapé separado, ou se suas páginas são altas o suficiente para garantir que elas sempre serão maiores que a janela.

Mas se você precisa mesmo do rodapé, não tenha medo. Isto também pode ser arrumado, mas requer mais uma div . Adicione uma caixa externa ao rodapé, assim:

<div id="footer-wrapper">

<div id="footer"></div>

</div>

Agora use o mesmo truque com as colunas para fazer com que a caixa externa do rodapé se extenda para além da página, deixando o rodapé em si para que você faça como quiser.

* html body {

overflow: hidden;

}

* html #footer-wrapper {

float: left;

position: relative;

width: 100%;

padding-bottom: 10010px;

margin-bottom: -10000px;

background: #fff; /* Same as body

background */

}

Isto resolve o problema e nos deixa com o resultado desejado.

Ah, e tem mais uma coisa

Os extremistas por aí podem estar pensando se não existe um jeito ainda melhor de se fazer isso. Afinal, o método que apresentei utiliza uma “#container” não-semântica. Certamente não podemos ter uma div adicional atrapalhando nosso impecável código.

Se você, como eu, está pensando neste detalhe, não pense mais. Como um bônus especial, apresento a você o Santo Graal sem “container”, em toda sua glória minimalista. Uma div para cada seção do código – nada mais, nada menos. O supra-sumo semântico, quase merecedor do título de “Santo Graal”.

O princípio por trás do CSS é o mesmo. O “padding” foi aplicado diretamente ao body , eliminando a necessidade de “containers”. Margens negativas delimitam o cabeçalho e o rodapé para garantir que eles fiquem no lugar certo.

Esta versão funciona em todos os navegadores citados anteriormente, até no (quase um milagre) Internet Explorer. No entanto, as colunas de alturas iguais não funcionam e este layout ficará quebrado em janelas muito estreitas. Use-o com cuidado.

E agora?

Enquanto esta aplicação específica do Santo Graal é um tanto quanto restrita, a técnica pode ser bem generalizada. Por que não ter duas colunas líquidas? Por que não inverter a ordem das colunas? Estas aplicações estão além do escopo deste artigo, mas atingíveis com pequenas modificações. Use o Graal com sabedoria, e ele pode ser uma adição muito útil para sua bagagem de truques de CSS.

-----

Este artigo foi publicado originalmente na edição 211 da A List Apart e pode ser acessado aqui.

Traduzido por Luciano Rodrigues.

Objetivos de uma Home Page

por DEREK POWAZEK

Quando eu me sento para criar um website, eu faço ele ao contrário. Começo com o design do menor e mais profundo elemento: a página de produtos ou de resultados da busca. Então eu trabalho de trás pra frente para criar as páginas de seção e índices. E então, finalmente, eu trabalho na home page.

Eu faço isso porque cada seção deve definir adequadamente as expectativas para o que ela contém. Se a home page diz uma coisa, mas as páginas internas dizem outra, isso levará a uma falha na experiência do usuário.

Isto também significa que, quando eu começar a trabalhar na home page, já existem muitas coisas acontecendo. E qualquer ansiedade de demora será centralizada num lugar – na home page.

Home pages sempre criam ansiedade nas empresas. Ela é sua primeira impressão. E como diz o ditado, você só tem uma chance. Então as home pages por si só possuem um conjunto único de objetivos de design.

Antes de entrar nestes objetivos, vai aqui um pequeno detalhe. Todos os sites em que trabalhei tiveram médias de tráfego extremamente parecidas, e um se destaca. Lembra daquele menor e mais profundo elemento que mencionei antes? Este é o elemento átomo – para um site de notícias, é a página da notícia; para uma ferramenta de busca, é o resultado da busca; para uma loja, é a página do produto. Esta página corresponde de 60 a 75 por cento de todas as page-views do site. O resto pertence à home page.

Isto não quer dizer que a home page seja menos importante – é extremamente importante como uma primeira impressão. Mas olhando para os números, você terá muito mais estardalhaço para as páginas dos elementos átomos do que para a home page.

Posto isso, vamos para os desafios únicos que a home page possui. Lembre-se, quando digo home page, quero dizer a página que está em “qualquercoisa.com”. A primeira página que o usuário vê quando chega em frente à sua porta.

Qualquer home page possui quatro metas principais, nesta ordem:

Meta 1: Responda à pergunta, “Que lugar é este?”

Este é e sempre será a meta número 1 de qualquer home page. Se você ignorar esta meta, deixará seus visitantes no escuro.

A primeira coisa que um novo visitante faz quando chega a um site desconhecido é esta pergunta. Se o site não faz um bom trabalho em respondê-la em alguns segundos, o usuário se sentirá perdido, sairá, e nunca mais voltará. Afinal, o que você faria se conhecesse alguém que fizesse você se sentir como um idiota? Você gostaria de sair com essa pessoa de novo?

Isto tudo é causar uma primeira boa impressão.

Não fique com medo de usar textos fora de moda para dizer: “Estes somos nós, e é isto o que fazemos.” Aí você pode fazer um link para uma página mais detalhada. Desta maneira, as pessoas que precisam de ajuda possuem um lugar para encontrá-la. E faça questão que o texto que você usa seja dinâmico e positivo – e faça o leitor se sentir importante.

Não se prolongue muito, é claro. Tenha certeza de que todas as suas palavras tenham peso. Mas a explicação deve começar no início da primeira página – é a coisa mais importante que você pode fazer para tornar seus “novatos” em visitantes frequentes.

Isto é especialmente importante para empresas que estão tentando criar novas coisas. O Google pode se virar com uma home page nada amigável porque todo mundo já sabe usá-lo. Mas isto é uma exceção à regra. Se você está fazendo algo novo, às vezes você precisa explicar numa linguagem clara, como: O Flock é um navegador gratuito e de código aberto.

Se um visitante entra pela primeira vez em seu site e não entende do que se trata em três segundos, você falhou na meta número 1, então sinta-se à vontade para pular as outras. As únicas pessoas que usarão este site serão aquelas que já o conhecem. Ou, você sabe, masoquistas.

Meta 2: Não fique no caminho do visitante que já te conhece

Tudo isto dito, a segunda meta é sair do caminho dos visitantes que já sabem o que estão fazendo. Estes são os usuários como você, aqueles que já estiveram aqui antes e já entenderam o esquema.

Uma ótima técnica que engloba as duas primeiras metas é fazer uma área dinâmica na página. Esta área por exibir uma explicação aos novatos. Mas uma vez que o visitante esteja logado, substitua a explicação por uma informação específica para ele (o que também atende à meta 3).

O Flickr leva este método ao extremo, exibindo home pages totalmente diferentes se o usuário está logado ou não. Para eles, é perfeito. Este site é tão personalizado para quem está logado, e o serviço é tão diferente de outros sites, que faz o maior sentido oferecer uma experiência totalmente diferente para cada grupo, e isto atende perfeitamente às metas 1 e 2.

Meta 3: Mostre as novidades

Quando você chegar à Meta 3, você já satisfez as necessidades de usuários novos e antigos. Parabéns, agora todos estão na mesma página! Agora é hora de impressionar todos com novidades.

Muitos sites param depois de atender às metas 1 e 2. Mas depois que um usuário passou pela chateação de saber o que você faz e ainda retorna ao seu site, você deve alguma coisa a ele: o que há de novo. Você conhece seu site melhor do que ele, então seja seu guia. Sugira lugares para visitar, começando com alguma coisa nova. Blogs são muito bons para isso, com seu formato os-últimos-serão-os-primeiros.

Meta 4: Ofereça uma navegação consistente, confiável e global

Esta é uma meta para todo o site, mas é importante listar aqui porque as expectativas que você definir para a home page serão herdadas em todas as páginas do seu site. São as pequenas coisas que contam aqui. Se um link está na navegação global da home page, ele deveria estar no mesmo local em todo o restante do site. Se existem seis links no rodapé, estes mesmos links deveriam aparecer em todos os rodapés.

Linha final

Desenvolver para uma boa experiência do usuário é se comunicar claramente, definindo expectativas previamente e entregando o que você prometeu. Pense na sua home page como o primeiro verso de uma música. Tudo que você tem a fazer é ter certeza de que está no tom durante toda a experiência sonora do usuário.

-----

Este artigo foi publicado originalmente na edição 211 da A List Apart e pode ser acessado aqui.

Traduzido por Luciano Rodrigues.