Seja qual for o projeto, o mais importante de tudo sempre será o conteúdo.

Agora, somarei ao assunto o que acredito ser um grande tabu no trabalho dos webdesigners: descobrir a dosagem exata de como projetar design, sem esquecer da importância do conteúdo¹.

¹ – Chamo de conteúdo tudo o que deve ser levado em conta para conceber um projeto: o propósito, a definição, o público alvo, os benefícios e etc.

O que importa é o conteúdo

Design é casual. É arte com propósito de venda. Por conta disso, não deve ser encarado como fatia determinante em um projeto web. O papel do design é chamar atenção aos olhos para um conceito, porém, assim como a propaganda de TV, ele não tem o poder de obrigar o consumo daquilo.

Tomemos como exemplo o Twitter. As primeiras versões da sua página web eram modestas, porém o poder da ferramenta era aparente. Façamos, agora, uma comparação com o Meme do Yahoo!. É notável que a sua interface foi desenhada com todo cuidado, porém será que a beleza da ferramenta era o bastante para encantar os usuários de Twitter ao ponto de fazê-los migrar para lá?

Outro exemplo interessante é o Delicious. Nos seus primórdios a sua interface — apesar de usual — era bem pobre de estilo. Ainda assim, naquela época o Delicious era considerado uma das melhores ferramentas de social bookmarking (quiçá a melhor).

Conclusão

Não quero ser polêmico ao ponto de dizer que design não é importante. Eu adoro navegar em sites bonitos e gosto mais ainda de usar ferramentas bem desenhadas. Aliás, tenho certeza de que todas as pessoas também gostam. Contudo, saber a dosagem certa do design para web e aplicá-lo da forma correta ao propósito do projeto é muito importante, até porque, não nos esqueçamos, sem conteúdo não há webdesign. :)

Eu e a galera do #horaextra organizamos as Lightning Talks e as sessões de Dojo. O pessoal do Dojorio e da PythOnRio completaram a turma.

Para quem viu e quer saber mais ou para quem não viu, segue a lightning talk que eu apresentei:

• A Mágica dos CSS Sprites (slideshare)
• Baixe o código exemplo

A essência do design aplicado na web

O ponto mais importante de todos talvez seja: não tente imaginar a mídia web como se fosse mídia impressa. São realidades completamente diferentes! Na mídia impressa usamos CMYK, na web RGB. A mídia impressa usa centímetros, já a web usa pixels. Na mídia impressa a tipografia é estática (como uma foto), na web a tipografia muda de acordo com o ambiente (como se tivesse vida).

Nós precisamos entender que a essência do design é sempre mesma¹, porém a aplicabilidade deve ser sempre de acordo com o tipo de trabalho. Nenhum website é entregue encadernado.

¹ – Uma sucinta explicação do que é design: imaginar, elaborar e confeccionar algum artefato, utilizando a arte criativa para conceber o resultado.

Webdesign não é print screen

Imagine a seguinte cena: o programador abre sua IDE de desenvolvimento, programa todas as rotinas necessárias para uma determinada funcionalidade ter vida, salva um arquivo .txt e apresenta para a sua equipe. Não tenha dúvidas de que a maioria vai pensar: “Legal, código bonito, mas não seria melhor ver como ele funciona?”. A sensação que eu tenho sobre o que nós pensamos sobre webdesign é a mesma. O indivíduo abre o Photoshop, faz uma deslumbrante tela e apresenta o resultado em imagem estática. Pensem: uma página web é como um organismo vivo, que pode se manifestar de formas diferentes de acordo com o ambiente. Ou seja, o que determina a boa disposição de um layout são os textos, imagens, multimídia ou qualquer outro compontente que o componha.

Completando sabiamente o assunto, Zeldman outro dia disse:

Content precedes design. Design in the absence of content is not design, it’s decoration.

Seja qual for o projeto, o mais importante de tudo sempre será o conteúdo.

Não quero dizer que todo webdesigner deve ser um guru de HTML, CSS e — quem sabe — JavaScript, mas é imprescindível que se tenha a noção de quais recursos usar para tornar um print screen realidade. Eu costumo julgar a qualidade de uma marcação HTML/CSS da mesma forma que julgo layouts. Penso ser tudo parte de um mesmo universo. O webdesigner precisa entender que aquele título feito em 20pt no Photoshop precisa ser um <h1> ou <h2> (dependedo do caso), para atribuir SEO ao site, por exemplo.

Webdesign e as Metodologias Ágeis²

Tenho percebido que há uma carência muito grande de webdesigners que saibam trabalhar com Metodologias Ágeis. E isso é uma pena, porque o sentido da metodologia ágil — ao pé da letra — é tornar a equipe unida e produtiva em toda as fases do projeto. Estariam os webdesigners sendo individualistas?

² – Uma metodologia ágil é aquela que une diversos princípios para melhorar a comunicação entre todos os envolvidos num projeto (inclusive o cliente) e também ajuda na concepção do que realmente precisa ser feito, sempre respondendo às mudanças que o produto sofre, não se apegando à especificações imaginárias.

Falando especificamente de Metodologias Ágeis, alguns Scrum Masters optam por adiantar os sprints de design, fazendo, assim, os chamados mini-waterfalls, outros, como eu, preferem integrar as tarefas de design junto das demais. Cada um tem a sua justificativa (o link do mini-waterfall explica um pouco disso) e a minha está ligada ao que falei acima: conteúdo precede o design. Não vai ser útil ter só a tela do photoshop, porque aquela paginação pode precisar de 20 itens por página e não 10, aquela galeria pode precisar de um controle para remover a foto que o webdesigner não imaginou no seu desenho, o nome do usuário fulano pode ser grande o suficiente para quebrar a caixa de profile e assim por diante.

Fazendo o webdesigner pensar fora da caixa

• O webdesigner precisa descobrir que desenhar em marcação é possível! Isso vai facilitar, inclusive, o trabalho dos programadores;
• Precisa estar próximo da sua equipe e interagir com ela;
• Precisa entender que o seu trabalho não é meramente decorativo. É evolutivo. Do wireframe à marcação. Da marcação à UI/UX. Da UI/UX à identidade visual.
• Conheço diversos programadores que gostam de entender o mundo do webdesign para tornar seu trabalho melhor. É essencial que o webdesigner tenha a mesma motivação. Entender de social coding pode ser um excelente começo.

¹ – Defino website como qualquer tipo de site, hotsite, blog ou portal; apesar de alguns portais terem características de sistema agregados.

Conceitos de User Experience e User Interface

UX ou UE é, basicamente, a forma de criação da arquitetura e das interfaces de um produto com foco na Experiência do Usuário, como o próprio nome se refere. Ou seja, trata de todos os aspectos de interação do usuário com o produto. Aí entra o papel da UI: tranformar a UX em algo visualmente atrativo e eficiente.

Confesso que é deveras complicado chegar numa construção de Design UX/UI que seja agradável ao usuário tanto pela usabilidade, quanto pela aparência. Mas é aí que entra a parte interessante da história: experimentar!

Agora, as comparações

1. Masthead

Em sistemas web, o Masthead define um menu horizontal na parte superior direita da tela. É uma forma rápida e prática para apresentar links de perfil de usuário e saída do sistema. Estes links podem ser encontrados, por exemplo, em qualquer serviço Google, como o Gmail.

Em websites a coisa muida de figura, já que é difícil encontrar um cenário em que o masthead se encaixe. O link “pular para conteúdo” pode ser uma boa “simulação” de um masthead. Este link, inclusive, pode ser encontrado neste meu blog.

2. Boxes (ou caixas)

Os boxes (ou caixas) são uma forma muito interessante de organizar várias seções de um sistema numa mesma tela. O administrador do WordPress utiliza muito deste conceito.

O interessante é que a utilização de boxes pode ser muito similar nos websites. Portais jornalísticos utilizam muito deste conceito também.

3. Largura do layout

Descobri — depois de muitas experimentações — que o layout fluido (ou elástico) é a melhor pedida para desenvolver sistemas web. Este formato abre o leque de possibilidades para a criação de controles, boxes adicionais e formulários. Além disso, é possível incluir uma sidebar fixa que se movimenta junto com o tamanho do canvas do browser do usuário.

Em websites a largura do layout é um assunto um pouco polemizado, porém ao meu ver é algo muito simples de imaginar: basta saber a característica do negócio. Um blog talvez tenha uma interface mais bem trabalhada numa estrutura fixa e não tão larga. Já um portal jornalístico (como pode ser visto acima) necessita de um layout mais amplo, visto a quantidade de informação que precisa ser organizada.

4. Iconografia

Penso ser indispensável a utilização de ícones em sistemas web², mas em suas devidas proporções. É importante deixar claro para o usuário que tipo de informação ele vai encontrar em determinado link (um menu por exemplo).

² – Acho fantástica a iconografia incluída no WordPress 2.7, no estilo barra de ferramentas do PhotoShop.

Para utilizar ícones em websites também é preciso — assim como na escolha da largura do layout — entender a característica do negócio. É muito comum websites não utilizarem ícones e ainda assim serem usuais. Porém é importante levar em conta questões como contraste nas cores e no tamanho da fonte dos títulos que compõem a tipografia, por exemplo.

5. E por falar em tipografia…

Uma boa tipografia dá elegância a qualquer projeto. Por conta disso não há uma regra que me faça comparar as tipografias de sistemas web e websites, exceto em dois aspectos:

• Sistemas web podem ter seções com fonte de tamanho reduzido e os parágrafos não precisam ter o line-height acentuado, já que é rara a utilização de textos longos.
• Websites precisam receber maior cuidado na separação dos textos (veja este meu artigo que trata um pouco disso).

6. Footer

Alguns webdesigners não se preocupam muito com ele, mas ao meu ver o footer (rodapé) tem tanta importância quanto o header (cabeçalho) de um website. Em sistemas web ele pode ser mais discreto.

O footer talvez seja a seção que tenha mais diferenças entre os dois cenários deste artigo. Um website com um footer rico melhora — e muito — a navegabilidade. Já num sistema web praticamente todos os recursos estão dispostos acima dele, o que dispensa sua incrementação.

Considerações finais

Os cenários deste artigo são fruto de experimentações que fiz (e faço) ao longo do tempo. De qualquer forma, não tomo estes conceitos como regra: sou a favor da flexibilidade. Cada projeto é um projeto e tudo é válido na construção de uma interface usual, bonita e agradável ao usuário final. :D

A grande problemática do projeto foi o tempo, pois dispunha de um prazo pequeno para implementação. Mesmo assim, o pessoal da Improve It foi bem solícito e tivemos uma boa sinergia no andamento do trabalho.

Por fim, nasceu o template “mosaico”, com uma paleta de cores mesclada entre o azul e o marrom.

Em breve, mais novidades minhas no Be on the Net. :)

1. Compatibilidade dos browsers

A expectativa é de que em 2009 (data programada para um novo rascunho) o HTML5 já esteja suportado na maioria dos browsers modernos, mas não por completo.

Assim como a guerra dos browsers propõe, cada browser deve se basear primeiramente naquilo que lhe convém. Dentro deste tema, será interessante ver a abordagem das tags <audio> e <video> que certamente implicarão em interesses pessoais de Microsoft (Media Player) e Apple (QuickTime).

2. Implementação incompleta

Veja uma pequena lista de implementações catalogada pelo pessoal do whatwg, cujo trabalho é voltado exatamente no HTML5.

Veja outra lista no wikipedia. O Opera Browser (Presto Engine), como já é de se esperar, tem o melhor suporte até então.

3. Cultura

Passamos um bom tempo até chegarmos numa web satisfatória (mesmo que numa percentagem pequena ainda). Poucos anos atrás, não existia a preocupação nos desenvolvedores em manter a marcação de seus sites organizada, que dirá pensar em standards: era perda de tempo demais!

Agora, nos deparamos com uma nova realidade, já que até quem trabalha com XHTML 1.x poderá se converter para o HTML5. Mas, será que os desenvolvedores querem mesmo isso? Esse ponto é importantíssimo para aqueles que correlacionam padrões web apenas com XHTML. Ledo engano.

John Resig, aquele do Jquery, escreveu no início do ano sobre uma forma prática de implementar sempre o mais recente DOCTYPE nas marcações. Essa técnica será válida para o HTML5. Assim, os desenvolvedores poderiam continuar com seu HTML4 e ir adicionando funcionalidades ao longo do tempo — de acordo com a compatibilidade dos browsers — dentro da marcação HTML5. Como o DOCTYPE não define a versão da marcação, ele sempre procurará corresponder à mais recente encontrada.

O código é simples:

<!DOCTYPE html>

Essa seria uma forma interessante de comerçarmos a nos acostumar com o HTML5.

Conclusão

Apesar de existir um longo caminho até o HTML5 substituir completamente o HTML4, estamos próximos de conseguirmos utilizá-lo aos poucos, já com certa compatibilidade de recursos nos browsers. De qualquer forma, penso que a “cultura” que trato neste artigo está diretamente ligada à previsão de 2022 tratada no artigo anterior, visto que certamente haverá um bom tempo até que alguma parte dos desenvolvedores/webdesigners se conscientizem da nova realidade. Vale lembrar que tínhamos bom suporte à HTML standard há muitos anos (mais de uma década) e só agora, desde poucos anos atrás, nos tocamos disso. :P

A velocidade crescente dos serviços web 2.0 (sim, hoje não temos mais portais, temos serviços) tratou de aumentar a curiosidade dos profissionais que antes não atentavam para a nova web. E em meio a essa avassaladora mudança, algumas implementações da web semântica podem confundir.

Os tempos mudando

Neste mês de setembro o Google lançou seu navegador, o Chrome. Com ele o Google acabou conseguindo — com sua conhecida persuasão — fazer com que pessoas com pouco conhecimento de internet entendessem que a internet não está diretamente ligada ao IE.

E onde o HTML5 entra nisso tudo?

Com a vinda do Chrome e o suporte a CSS 3 cresendo nos browsers modernos, um outro trabalho entrou em check: e o HTML5, como anda?

Semana passada, Jeff Croft tocou num assunto interessante: segundo a previsão, o HTML5 só estará definitivamente recomendado para uso em 2022!

Em entrevista ao blog TechRepublic, Ian Hickson, editor do HTML5, estimou a seguinte linha de tempo:

• Primeiro rascunho da W3C em outubro de 2007;
• Próximo rascunho programado para outubro de 2009;
• Chamada para contribuições em testes em 2011;
• Recomendação candidata em 2012;
• Primeiro rascunho dos testes em 2012.
• Segundo rascunho dos testes em 2015.
• Versão final dos testes em 2019.
• Mais uma chamada para rascunho em 2020.
• Recomendação proposta em 2022.

Quanto tempo, não? A resposta para a demora é de que o HTML4 foi pouco documentado e o HTML5 pretende chegar com muitos novos recursos, assim como o CSS3 também propõe. Para os que não costumam trabalhar com XHTML, o jeito é continuar com o HTML4 por mais um tempo.

Como ter um site standard trabalhando com HTML4

Simples! Como disse no início, tudo depende da definição do DOCTYPE. Não importa o DOCTYPE, desde que você não deixe de usá-lo.

Roger Johansson, do 456 Berea Street já trata do assunto faz tempo. Em 2006 ele explicou porque decidiu pelo uso do HTML em suas marcações. Até hoje ele mantém seu site em HTML4, e válido!

Então, enquanto o HTML5 não chega, tratemos de nos preparar para ele, começando pelo uso de um DOCTYPE adequado e seguindo todas as premissas para um projeto standard de verdade. :)

Atualização 2008-09-16: um DOCTYPE recomendável em HTML4 seria como o a seguir:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

Adeus 800×600

A primeira providência que tomei foi tornar o layout fixo. Não interessava mais manter algo fluido, já que a porcentagem de uso da resolução 800×600 vem caindo consideravelmente. Resolvi, então, manter um layout fixo de 960px de largura, composto de: ~160px de área livre à esquerda, 480px de conteúdo e 280px de barra lateral direita.

Aproveitando a formação do grid, resolvi ajustar o rodapé a esta estrutura de colunas, tornando, de fato, o layout um grid layout.

Novo logotipo

Talvez não tão novo, porém redesenhado. A mudança significante está na tipografia. Deixei de lado a Garamond e apostei numa fonte até então desconhecida para mim, mas que ganhou meu apreço.

A fonte chama-se “IPAP” e foi encontrada num dos utilíssimos artigos do Smashing Magazine.

Novo menu

O menu sofreu algumas alterações no espaçamento e na estilização dos links, tornando, assim, o que era “solto” algo mais integrado.

Outras mudanças

A seguir, check-list de alguns dos itens modificados:

• Novo alinhamento de logotipo (trazido para a esquerda) e sidebar;
• Nova estilização das listas da sidebar e do rodapé;
• Novo recuo das listas do conteúdo;
• Novo estilo para as datas;
• Inserção de comentários randômicos no conteúdo extra do rodapé;
• Alinhamento do conteúdo extra em colunas, respeitando o alinhamento das áreas superiores.

E assim a busca continua… ;)

Analizei a estrutura dos arquivos e fiquei entusiasmado. O projeto Blueprint é, sem dúvida, uma das melhores referências livres de CSS da atualidade.

O projeto é dividido nas seções que se seguem:

• Estilização de versões para impressão;
• Estilos para botões;
• Grid Layouts;
• Tipografia.

Planos futuros:

• Suporte a PNG para IE 5.5+;
• Desenho de layouts líquidos.

Vale a pena conferir, novamente, o link.

Blueprint é uma ótima solução para desenvolvedores experientes padronizarem seus trabalhos e para iniciantes pegarem o foco do que é, efetivamente, desenvolver para web semanticamente. :).

Safari para Windows é como um browser de teste

Acho difícil não associar o uso do Safari para PC apenas para desenvolvedores. Já temos o “melhor browser que ninguém usa“¹ para a mesma finalidade.

¹ – Termo engraçado e muito bem sacado por Carlos Cardoso, num artigo do meiobit.

Jonathan Snook, arremata:

When asked why Safari is being released for Windows, a few people have said that it is intended for developers to be able to check their sites without having to own a Mac. It’ll definitely be nice to have something on the PC that comes close to comparing the two. [...]

E… Onde entra o cross-browser na história?

Cross-broswer, basicamente, é:

Cross-browser refere-se à habilidade de um site, Aplicação Web, contructor HTML ou script side-client suportar múltiplos navegadores.

Wikipédia – A enciclopédia livre

O Safari para Windows chegou como mais uma possibilidade de teste/debugging para desenvolvedores que não possuem Mac.

Lembrando que ele ainda está em fase Beta e precisa de várias correções de bugs. Ainda não está 100%, mas já é bom saber que não haverá mais a desculpa de que não se testa em Safari por não se ter Mac. :P

Atualização 2007-06-24 – Os problemas com os negritos e itálicos que não apareciam no Safari (Win) já foram corrigidos. Assim sendo, testes de layout já podem ser efetuados sem problema.