Enfim, o assunto não é esse. Mesmo tendo mudado de título definitivamente (de quase-programador para aprendiz-de-designer), não nego a importância da programação para o Web designer. Você tem sim que saber um pouco de XHTML e CSS, mas um pouco de programação não faz mal. Não é questão de prioridades, de se focar num assunto específico, isso é bobagem. O profissional deve ser bom sim no que faz, mas sempre deve estar aberto e ter conhecimento do trabalho do colega ao lado.

Eis que então, meus amigos, como é de conhecimento de vocês, eu já tenho alguma experiência básica com CakePHP. Começamos a utilizá-lo na agência onde eu e o Julio trabalhamos, e eu realmente fiquei surpreso com o grande potencial tanto do framework quanto do PHP. Li por várias vezes a documentação, a API, e as entranhas do Cake, e vi como o funcionamento é simples.

PHP, de fato, não é uma linguagem ruim. Eu digo que não gosto da sintaxe do PHP, pois prefiro a do Ruby, mas nem por isso odeio o PHP. Essa é a minha opinião. Quanto mais eu conheço a linguagem, mais estou gostando dela. Até pouco tempo utilizava PHP4, mas em 2008 comecei a entender toda a lógica por traz da orientação a objetos. Isso me abriu as portas para entender esse potencial do PHP.

PHP, apesar da sintaxe não tão legal (opinião pessoal), está bastante madura, a julgar pela quantidade de extensões existentes, sem falar na grande abrangência desta linguagem.

Como eu havia dito, independente da linguagem cada um tem que procurar ser mais produtivo. Talvez eu não seja mais produtivo que o pessoal que comentou lá (cujo tom de arrogância de alguns faz parecer que estes sabem tudo de PHP), mas eu sei que estou amadurecendo e que estou me tornando produtivo se comparado a mim mesmo há um ano. Inclusive no design.

Espero não entrar mais nessas discussões, pois já disse aqui várias vezes o que penso e que estou me distanciando um pouco da programação pois - salvas excessões - há muita arrogância e ignorância entre os programadores.

Como eu estou decidido que quero seguir na carreira de designer, já estou tomando providências. Trabalho com design e, mais do que isso, estudo design. Só acho ridículo - e confesso com vergonha que já fui assim - que muitos que se dizem designers não estudam e não se interessam pelo estudo do design e da arte.

A ferramenta não faz o designer

Você pode ser o ninja do Photoshop, saber tudo de Fireworks e Flash. Mas nada disso é válido se você não souber como utilizar essas ferramentas para tornar o seu design efetivo.

Design é função

É isso o que difere design de arte. Você faz um trabalho de arte, e ele pode ser tão subjetivo, tão abstrato, que ninguém pode entendê-lo. Seu design não pode ser assim. E arte só é design quando esta arte for aplicada. Você deve fazer com que o seu design - ou melhor, a mensagem que você quer passar - seja compreendido pelo seu público-alvo, pelo seu consumidor. Você faz design para vender seu produto ou idéia, não pela simples expressão do seu eu interior. O design Web possui técnicas que, quando bem dominadas, tornam seu serviço, site ou campanha na Web realmente funcional.

Claro, existe uma liberdade gigante na criação, e prova disso é a enorme variedade de peças distribuídas no mundo, mas perceba que os projetos de sucesso seguem algumas orientações básicas, entre elas o alinhamento racional, a escolha da boa tipografia e a harmonia de cores.

Web 2.0: uma nova abordagem ao design na Web

Por muitos anos, a abordagem que vigorou pelos então designers de Web foi o design centrado na utilização, na tarefa. Nesta abordagem, todo o design era focado nos objetivos e tarefas que envolviam um produto ou serviço on-line, sem preocupações com o que o usuário realmente precisava e conseguia utilizar. Com o estouro da bolha uma nova tendência se fortaleceu, e os novos serviços - chamados “2.0″ - seguiam (e ainda vêm seguindo) a abordagem do design centrado no usuário (UCD), que se preocupa diretamente com as limitações e capacidades do usuário final.

O design centrado no usuário foi um marco para o design da Web por dar o merecido valor ao usuário final. Nesta abordagem de design, os designers de Web não apenas projetam interfaces de acordo com o que consideram melhor para o usuário final, mas testam e avaliam a efetiva funcionalidade de suas telas. Isto ocorre pois os designers possuem experiências que divergem das do usuário final, o que influencia também na maneira com que fazem design para Web. Assim, o que é simples e intuitivo para eles pode não ser para o grande público.

São quatro os elementos principais do design centrado no usuário: visibilidade, acessibilidade, legibilidade e linguagem.

Visibilidade

A visibilidade ajuda o usuário a construir um modelo mental. O modelo mental ajuda o usuário a formar uma imagem sobre o funcionamento do seu serviço, e também prever os efeitos das suas ações. Eu já escrevi sobre isso. Seu site deve ter navegação clara, e o usuário deve saber exatamente onde está, para onde pode ir e por onde já passou.

Acessibilidade

Não são apenas os cegos e pessoas com dificuldades motoras que são o alvo da acessibilidade de um site. No design de interação, todos os usuário possuem suas particularidades e são, pois alvo da acessibilidade. Cada usuário possui - devido às experiências anteriores - um modelo mental de como sites geralmente funcionam. Esperam um logo no canto superior, navegação logo abaixo ou em barra lateral, e busca no canto superior direito.

Quando algum desses itens não está presente, o usuário pode se sentir desorientado. Assim, um projeto de design na Web, geralmente na forma de um site, deve manter sempre claras e visíveis as informações básicas que o usuário deve ter. Além disso, o conteúdo deve ser escrito de maneira a tornar fácil a leitura e escaneamento do texto, pois o usuário provavelmente não lerá o conteúdo todo para encontrar o que precisa.

Legibilidade

Nunca esqueça que o usuário está em seu site em busca de conteúdo, e que geralmente este se encontra em forma de texto. Tornar esse texto legível e escaneável, então, é o mínimo que você pode fazer. Lembre-se de dar preferência às fontes sem serifas, que são mais legíveis em monitores do que as serifadas, pois a resolução dos monitores é muito inferior à dos livros impressos. Além disso, a relação das cores do texto com a cor do fundo é importante para a legibilidade, pois se o texto for pouco contrastante fica difícil a leitura.

Linguagens

Algo que está escrito em todos os livros de usabilidade que já li: use terminologias comuns, não específicas e nem aquelas que fazem sentido apenas a um grupo específico. Ou seja, “marketês” pode não fazer sentido para a grande maioria. Além disso, se a sua empresa utiliza nomenclaturas internas (jargões) para produtos e seções do site que diferem do vocabulário esperado pelo usuário, pense novamente.

Por onde começo?

Resumindo: para ser um Web designer, você precisa estudar design. Se não souber nada de tipografia, teoria de cores, alinhamento e posicionamento, semiótica, estética e comportamento humano, você não está nem perto de ser um designer, quem dirá um Web designer. Li esses dias no Plurk alguém que disse “ainda bem que escolhi design, assim não preciso ler tanto”.

Muito pelo contrário, meus colegas. Leitura é essencial em qualquer área, o conhecimento é muito, e livros são uma ótima maneira de adquiri-lo. Se você freqüenta uma universidade, sua biblioteca deve ter bons títulos sobre o assunto.

Conclusão

As ferramentas não fazem um bom designer, e um Web designer não é um Web designer se não souber a teoria básica sobre design. Vejo que falta em muita gente a vontade de estudar e aprender design. Talento é importante e conta, mas se você tem talento e não possui técnica e teoria, você é uma pedra preciosa não lapidada. Estude, estude e estude, e você brilhará.

Sua página inicial é o ponto de partida para todo o site

Nunca tire isso da mente. As páginas iniciais devem prover informações claras sobre o que é o site, o que o usuário encontrará no site e amostras de conteúdos importantes. As páginas testadas no livro de Nielsen possuem, em média, 770 pixels de largura e até três telas de comprimento (em resolução 1024X768). Tome cuidado para não desperdiçar espaço na sua página inicial com conteúdo ambíguo.

Se seu site possui busca, coloque-a na página inicial

Usuários começam a navegar em seu site ou através de links, ou através da busca. Sobre a sua busca funcionar corretamente ou não, fica para um próximo artigo, mas ela deve sim estar presente na página inicial, pelo fato de ser um dos grandes pontos de partida para a navegação. Segundo as estatísticas das análises de Nielsen, o lugar mais apropriado para colocar sua caixa de busca é no canto superior direito. Sua caixa deve ter, no mínimo, 27 caracteres de extensão, para permitir que os usuários consigam rever o que digitaram, e o botão mais apropriado deve ter a palavra “Buscar”.

Comunique a proposta de seu site

Seja claro sobre o que sua empresa faz e para que serve o seu site, logo de cara. Para tal use algum texto introdutório curto e sem “marketês”. Além disso, aposte em uma tagline clara e objetiva, que seja curta mas que explique exatamente a proposta do seu site.

Não ofereça formulários de registro sem dar vantagens

É interessante e importante que seu usuário registre-se no seu site. Informações de registro, como um link, devem estar disponíveis logo na página inicial. Contudo, é importante citar vantagens de ser um usuário registrado naquele momento, e não apenas um link do tipo “Clique para Registrar”. Ofereça conteúdo mais atrativo, como  “Registre-se agora e ganhe descontos nos produtos”, que explicita realmente alguma vantagem em efetuar um cadastro.

Sobre as boas-vindas

Dar as boas vindas aos usuários se mostrou não tão efetivo, a menos que acompanhado do nome da pessoa. Dizer “Seja bem vindo”, apenas, não traz vantagem alguma para a simpatização do usuário com seu site. Se ele for registrado e estiver logado, aí sim vale utilizar uma mensagem customizada como “Olá Rafael, seja bem vindo”.

Atenção aos gráficos animados

Os usuários, ao longo dos anos, desenvolveram um instinto inigualável para evitar anúncios. Eles têm associado os banners à propaganda e hoje muitos possuem uma certa “cegueira” aos anúncios. O problema então é que se você tiver algo em sua página que lembre um banner, há grandes chances de que esta seção seja descartada pelo usuário. Preste atenção, então, ao uso de gráficos animados e mesmo gráficos coloridos e chamativos demais, principalmente quando estiverem em formato de anúncio. Eles podem ser totalmente ignorados pelo visitante.

Estas são algumas conclusões que eu tirei da leitura do livro de Jakob e Marie. São muitas as análises feitas durante o livro, todas muito bem justificadas. Vale ressaltar que trata-se de um livro de 2002, e mesmo que algumas falhas na usabilidade permaneçam, como a Web está mudando e o usuário está mudando, precisamos ter certo discernimento que nem tudo que Nielsen disse há 6 anos é válido hoje.

Além disso, Jakob Nielsen é radical em sua opinião sobre usabilidade. Fica com você avaliar o que mudou, o que não mudou, e quanto radicalismo você pretende impor à sua criação. De qualquer maneira, todos os livros que li de Nielsen até então são muito esclarecedores e abriram a minha mente para o lado crítico que precisamos ter.

Desconsiderando o fato do grande atraso na publicação do episódio, está no ar o quinto podcast de CodeCast! Nesta edição, temos um convidado especial, Jader Rubini, que conversou conosco sobre linguagens de programação e frameworks Web, CakePHP para PHP, Ruby on Rails para Ruby e Django para Python, e jQuery como framework de Javascript.

Esperamos realmente que vocês gostem, pois o papo rendeu e o podcast está comprido (56 minutos). Falamos também do Plurk, serviço de microblogging, e também respondemos aos e-mails dos ouvintes. Desta vez está pesando 39MB, mas vale a pena.

Mas hoje estou aqui pra anunciar mais um trabalho que estive/estou envolvido de umas semanas para cá. É o blog de tecnologia TechZilla. Fiz o redesign do blog e agora, como serviço periódico, estarei por lá postando artigos legais sobre tecnologia. Desde já agradeço pela oportunidade ao Julio Câmara, que me convidou para esta tarefa. Me sinto muito feliz de saber que divido um blog com gente grande da blogosfera.

A única coisa que posso dizer é que o conteúdo é bem legal, e que vocês podem descobrir mais entrando e conhecendo nosso conteúdo. www.techzilla.com.br.

E voltamos agora com nossa programação normal.

Mesmo trabalhando com design, a gente acaba fazendo um pouco de código também, é bom e faço questão de continuar fazendo. Vejo meu progresso no design diariamente, a cada trabalho entregue, a cada cliente satisfeito. Mas na programação eu estive um pouco relaxado nos últimos anos. Fiz um bom trabalho com Padrões Web, e hoje domino XHTML e CSS. Mas com PHP era diferente.

Eu já tinha começado a estudar CakePHP um tempinho atrás. A idéia do framework era ótima, mas eu não entendia como ele funcionava, pois todo o código é orientado a objetos. Esse ano resolvi estudar um pouco sobre os conceitos da orientação a objetos e também um pouco da organização de software seguindo o pattern MVC. Foi aí que Ruby on Rails e CakePHP começaram a fazer muito sentido para mim. São ambos frameworks que, no meu ponto de vista, são muito parecidos no funcionamento.

A questão não é se eu prefiro Rails, Django ou Cake, mas a questão é que eu estou usando um framework. Ponto. Depois de assistir algumas palestras do Elcio, a gente aprende que precisa mesmo ser mais produtivo, e que uma das melhores maneiras é usar um framework, ou criar o seu próprio. Estou me distanciando um pouco da programação ultimamente; reconheço. Mas mesmo assim, toda esse estudo tem valido a pena.

Acho interessante, mais do que usar um framework criado por outros, criar o seu próprio. Ou sua biblioteca, que seja. Eu já tinha percebido que reinventava a roda a cada novo site que começava, e já tinha feito uma pequena biblioteca padrão para os novos sites. Isso é bem bacana, evita bastante retrabalho.

Próximo passo: Controle de versão

No início é complicado, e parece trabalhoso. Pode até ser, mas estamos perseverantes. Queremos tentar usar controle de versão pois, se não fosse bom, tanta gente não estaria falando tão bem. Não me lembro de ter perdido arquivos por conta de trabalho em equipe, mas já sofri com código espalhado em vários lugares. Por isso, é interessante pensar na implantação do controle de versão do código.

Conclusão: Não seja preguiçoso!

Permanecer no status quo é fácil, muito cômodo. Anime-se, desenvolvedor! Tanto comodismo é prejudicial à produtividade, e quem ainda nem se importa com isso não tem muito futuro. A programação se torna divertida quando há organização, pois tomando certas medidas para aumento de produtividade, o trabalho se torna muito mais fácil.

Não há hoje, em termos de Web, software mais polêmico que o Adobe Flash. Neste episódio do CodeCast discutimos sobre ele, e sobre como foi nossa experiência com ele. Falamos da história do software, dos prós e contras, de ActionScript e do Silverlight, a tentativa da Microsoft de desbancar o Flash. Além disso, lemos alguns comentários dos ouvintes, e no final dei uma dica de um software bem bacana.

Nesta edição o arquivo pesa 14MB, e possui duração média de 30 minutos. Para baixar acesse o site do CodeCast. Espero que goste!

Você sempre pode ir além, é claro. Existem mais maneiras, tão simples quanto as outras, de escrever código CSS ainda mais estruturado. As dicas que seguem são especialmente dirigidas àqueles que mantêm grandes quantidades de código, aos que atualizam seus CSS’s com freqüência, ou àqueles que trabalham em equipe - onde todos podem fazer eventuais alterações.

Grandes sites, que conseqüentemente possuem folhas de estilo maiores, exigem certa modularidade em todo o processo de desenvolvimento. Do Javascript ao PHP, do HTML ao banco de dados, passando (é claro) pelo CSS, o código inteiro carece de constante atualização. Como otimizar, então, nossos estilos para que nossa vida seja mais fácil?

Nada como código comentado

Use e abuse dos comentários para descrever seletores complexos, e para organizar todo seu CSS de maneira geral.

Zerar os estilos

Cada browser faz sutis modificações na maneira com que os estilos são renderizados. Para evitar a dor de cabeça posterior, algo interessante de se fazer ainda no início de desenvolvimento é o reset de estilos, que já falei sobre anteriormente.

Crie estilos padrão para elementos comuns

Seus elementos a, cabeçalhos h1, h2, h3, h4, h5, h6, parágrafos p, listas não-ordenadas ul e ordenadas ol - entre outros - geralmente possuem exatamente a mesma formatação em todo o site. Por isso, você pode aplicar certas propriedades diretamente ao elemento. Por exemplo, se seus links são sempre verdes, não coloque um color: green; em cada lugar que os links aparecem, como em #sidebar a, #post a, #header a, #footer a, .caixa a { color: green; }.

Prefira definir um estilo padrão, como a { color:green }, e então faça modificações apenas onde for necessário. Isso evita que seu código fique muito ambíguo, o que torna difícil a manutenção, pois se você determina a mesma cor para os links dentro de diferentes elementos, a cada modificação serão vários lugares a serem alterados.

Com os cabeçalhos, de h1 a h6, você pode e deve definir os tamanhos, pois a medida padrão para os cabeçalhos pode mudar um pouco de acordo com o browser.

Crie um índice com o conteúdo do arquivo

Pode ser uma boa, caso você não tenha o costume de identar o código. Defina uma TOC no início do documento, utilizando texto comentado, e então insira as marcações sinalizando o início de uma nova seção ao longo do código. Se isso ajuda ou não, depende de cada um. Só um código bem identado às vezes já vale mais do que esta estruturação com índice.

Separe seu código CSS em arquivos diferentes

Se você optar, pode separar cada pedaço do seu CSS em outros arquivos, e então chamá-los em um global. Isso é ótimo na manutenção, já que você sempre saberá exatamente onde procurar cada trecho de código, e o encontrará mais fácil pois cada arquivo não será tão extenso.

Importante: Leve sempre em consideração a performance, a velocidade de carregamento. Quanto mais arquivos forem chamados, mais requisições HTTP serão necessárias e mais tempo levará para o carregamento completo. Use esta dica com moderação.

Otimize seu CSS automaticamente com PHP

Chegamos na dica interessante do dia. Você provavelmente, em busca de otimização e melhora de performance, deve ter a sua própria maneira de otimizar o CSS antes de enviá-lo ao site. Existem inúmeros sites, como o CSS Cleaner, que otimiza o código para você, só que a cada alteração é necessário passar todo o código pelo otimizador novamente. Ou então, alguns preferem escrever todas as propriedades na mesma linha, etc, etc. Queremos uma boa manutenção, mas não podemos abrir mão da performance.

Trouxe um macete bem legal, mas é só para quem usa PHP. Adicione ao arquivo .htaccess da pasta dos seus arquivos CSS o seguinte código:


<Files otimizar.css>

SetHandler application/x-httpd-php

</Files>

Nesta mesma pasta, crie um arquivo chamado otimizar.css, e inclua nele o seguinte código.

<?php

header('Content-type: text/css');

ob_start("comprimir");

function comprimir($buffer){
$buffer = preg_replace('!/\*[^*]*\*+([^/][^*]*\*+)*/!’, ”, $buffer);

$buffer = str_replace(array("\r\n", "\r", "\n", "\t", ' ', ' ', ' '), '', $buffer);

return $buffer;

}

include($_GET['file'].”.css”);

ob_end_flush();

?>

A partir de então, passe a chamar seus arquivos CSS pelo endereço otimizar.css?file=nome_do_css. A alteração no arquivo .htaccess tornará possível a execução de scripts PHP no arquivo otimizar.css, e o arquivo otimizar.css removerá espaços, comentários e quebras de linha no seu arquivo, retornando um CSS compactado do jeito que você gosta. Este código não é de minha autoria, mas como não lembro mais de onde tirei, não posso dar os devidos créditos.

Espero que tenham gostado, pessoal. Deste e do primeiro artigo sobre Otimização de CSS.

CSS é, na maioria dos casos, a ovelha negra das linguagens no que se refere à manutenção. Já aconteceu com você de ter que mudar algum detalhe nos estilos de um site meses depois de ele ter sido concluído e custar um pouco até achar os seletores e propriedades corretas? Ou então, de criar seletores ambíguos, apenas com nomes de classe diferentes, e quando você precisa fazer alterações precisa mexer em mais de um lugar? Você ultimamente tem se perdido em centenas (milhares?) de linhas de código CSS?

Faça um esforço, e traga a organização que você já possui com seus scripts para a sua folha de estilo em cascata. Não é dificíl, pois as orientações você provavelmente já conhece e aplica, quase naturalmente. São algumas das sugestões que eu vi por aí e outras que eu mesmo sugiro a você.

Identação

Mantenha seu código CSS identado de acordo com a hierarquia que os seletores representam. No exemplo acima, #topo ul li pertence à #topo ul, e este pertence à #topo - assim como #topo img também pertence à #topo. Repare então que cada bloco de código recebeu uma identação de acordo com seu nível hierárquico. Identar seu CSS é importante justamente para visualizar facilmente a estrutura do seu site, sem necessariamente ter que ver o HTML todo novamente.

Ordem alfabética nas propriedades

Alguns de vocês podem julgar esta dica um tanto inútil. Na hora de escrever o código pela primeira vez, colocar as propriedades em ordem alfabética pode ser um pouco chato, cansativo. Mas se você reparar, na hora de fazer manutenção, você quase sempre fica procurando as propriedades no meio da confusão de caracteres. Para mim faz bastante diferença colocá-las nesta ordem, já deixa o código pronto para o futuro.

Agrupamento das propriedades

Os seletores #certo e #errado já dizem tudo. Você pode e deve resumir, por razões óbvias, a declaração das propriedades. Acredite, os dois blocos de código fazem exatamente a mesma coisa.

Na continuação desta série, veremos dicas avançadas para otimizar e estruturar seu CSS. Lembre-se sempre que todo esforço é sempre recompensado, e você é quem ganha quando precisar fazer manutenção e encontrar um código estruturado e intuitivo.

Acho que a imagem fala por si, pessoal. Vocês não sabem o quanto sou grato e quanto eu aprendi escrevendo e interagindo com vocês. Ainda estou pensando em uma maneira de recompensar vocês (spoiler: haverá sorteio por aqui). Obrigado pela audiência e pela feedelidade.