Como eu já havia anunciado no meu Twitter algumas vezes, eu estava trabalhando em um Framework CSS chamado Avante.

A maior parte do meu tempo nos projetos da empresa é dedicado a camada de views. Sou sempre responsável por design de interação em todos os projetos.

Me parece bem óbvio que design de interação sem interação, ou seja, sem validar os conceitos com alguém usando é apenas brincar de desenhar no Photoshop/Fireworks. Se você, como designer de interação, conta com um ajudante (as vezes chamado de prototipador) que fica ao seu lado o dia inteiro atualizando os mockups em html com seu psd, ótimo, mas felizmente esse não é o caso e conseguimos iterar bem rápido nesta parte.

Desta forma, eu preciso sempre poder rascunhar uma coisa no papel junto com o cliente, e em minutos ter um mockup funcional que o cliente possa interagir (clicar, rolar, navegar) com o design para ver se esqueceu algo ou se aquilo realmente tem chance de resolver seu problema.

Componentes

Entendido o ambiente, agora temos o problema. Em desktop e native mobile é comum você ter UIKits ou coisas do tipo com todos os principais elementos da interface. Elementos como botões, grids, menus e etc. Em web nós não temos isso, é uma vantagem pois podemos derivar qualquer layout em html.

Mas também uma desvantagem pois temos que, em todos os projetos, fazer markup para botões, menus e depois estilizar isso e só depois poder criar os mockups rapidamente com uma certa coerência visual. Alguns elementos são bem trabalhosos de serem feitos até o cliente (leigo) poder entender aquilo, elementos como modal,tabs, grids e paginações por exemplo .

A solução ideal para resolver esse problema é ter um UIKit com dezenas de patterns comuns em web (tabs, windows e etc) mas que também seja possível estender o layout e alterá-los completamente como abas horizontais se tornarem verticais.

Branding e visual design neutro

E aí surgem soluções como Twitter Bootstrap e Zurb Foundation para criar esse UIKit. Apesar de ter bons elementos (como o grid do Zurb ou modal do Twitter) esse elementos normalmente são agarrados ao branding da empresa que os fez.

Quando um site tem um branding próprio, eu não posso simplesmente “dropar” uma barra preta em cima e falar que isso é o menu.

Customizar essas coisas para sairem do layout do Twitter dão um trabalho enorme e tudo isso vem junto em um pacotão que não é possível customizar (Zurb tem problemas similares em escalas diferentes).

Grid responsivo opcional

Além dos patterns de UI é fundamental que algo para aumentar sua produtividade para prototipação e redesign precisar ter um Grid.

Grid não foi feito para quem tem pouco conhecimento de html/css conseguir alinhar as coisas mas sim para dar uma continuidade e lógica ao layout assim como na comunicação impressa (assunto para outro post futuro).

Já que é fundamental um grid e hoje temos zilhões de resoluções diferentes, nós precisamos fazer o que é chamado de design responsivo, MAS, nem sempre.

Verdade seja dita, design responsivo é bom e viável em coisas como sites de conteúdo e algumas web apps onde a equipe de design já pensa nisso desde o começo (caso raro quando equipe de design só brinca de Photoshop sem criar mockups reais).

Em projetos como intranet, máquinas de auto-atendimento, apps em html para aparelhos específicos e etc, não faz o menor sentido tentar responsive design pois só agrega custo de manutenção desnecessário para o cliente.

Ou seja, o grid precisa ser responsivo mas tem que ser opcional.

LESS vs SCSS

Outro problema que não da para abrir mão é a forma como escrevemos CSS3 hoje.

Convenhamos, CSS3 ainda é uma porcaria. Cada browser tem um prefixo e tem coisas que não fazem menor sentido, como estilizar a cor de um placeholder.

Então, algo para melhor a minha produtividade precisa resolver isso bem. A solução é algo como SCSS ou LESS, mas eu pretendo usar SCSS pois é o default do Rails e é o que usamos mais.

Poder usar SCSS por default ajuda em vários outros caso que expliquei na minha palestra no Café Com Tom ( disponível aqui )

Resultado: Avante

Com isso tudo em mente e precisando de uma solução para ontem, nos últimos seis meses venho testando todos os frameworks de grid e bootstraps da vida e juntando as coisas para resolver os problemas acima.

Sem poder esperar os donos dos frameworks resolverem esses problemas e já precisando usar nos projetos atuais, aos poucos isso foi tomando forma em nossos clientes.

Um dos projetos que estou atualmente como designer é o Libercar (Startup brasileira que entrará no ar nos próximos dias)… faz algum sentido, no layout abaixo, ter um menu preto com cara de twitter ou gastar 200 linhas para sobreescrever isso?

Com tudo que eu precisava no lugar, em Novembro resolvi dar um nome para isso e encapsular em um projeto próprio. Acabei criando uma Gem para facilitar o uso em projetos Rails mas mantendo o projeto separado também para usar em outros casos que preciso (projetos grails, php, django e etc).

Depois de bastante trabalho o resultado está aqui aqui, aqui e documentado aqui.

Projeto já está em uso em 3 projetos nosso e publicaria para comunidade opensource essa semana. No entanto, nesta mesma semana, Twitter Bootstrap teve o release da sua tão falada versão 2.

TW Bootstrap 2: responsivo e plugável

A versão 2 ainda tem opinião de mais com o branding do twitter, ainda pede markup maluco para coisas como formulários mas também tem features bem difíceis de serem feitas sem uma comunidade como 1500 bugs resolvidos, uma dezena de componentes simples para JS, responsive design com suporte a layout 100% liquid e etc.

A parte maravilhosa é que tudo isso agora é customizável eu não preciso ter um elemento chamando top-bar conflitando com o meu top-bar só porque eu quero usar o grid e botões do twitter bootstrap.

Com um sistema de grids melhorado e responsivo mas opcional eles também resolvem outro problema.

Ainda temos o problema do agnosticismo visual, ou seja, não vou gastar 200 linhas de css para customizar um menu que se feito do zero teria gasto 20. Mas sendo customizável o novo Bootstrap eu posso remover as coisas que não fazem sentido para meus projetos como forms e top-bar.

Sobra um último problema. Eu não quero ter que trocar de SCSS para Less em todos os projetos que vou mexer (TW bootstrap é feito com ele). Maior parte dos projetos que participo é como consultor ou designer por um tempo limitado, não posso chegar mudando tudo e também odeio a idéia de ficar tendo opinião de mais diferente do default do Rails para me morder daqui há dois anos.

A solução para este é simples. Não vou abrir mão da minha solução para bizarrices do CSS3 e outros mixins mas não quero mudar para LESS e nem quero deixar de usar coisas como nesting do SCSS. Então basta usar o TW Boostrap em CSS puro e extrair do Avante uma pequena extensão com estas necessidades (mixins, helpers e outras coisas em SCSS).

Conclusão: Morreu antes de ser publicado :)

Vai ter gente dizendo que eu poderia ter contribuído para o Twitter Bootstrap e ter evitado desperdiçar 2 meses de trabalho. Quem já contribui com projetos opensource sabe que é impossível embutir uma mudança arquitetural dessas sem ter uma guerra interna e meus clientes precisavam disso para Outubro :)

Outra coisa a pensar é que desperdicei 2 meses do meu trabalho sendo que poderia ter esperado, mas cliente tem urgência e não iria desenvolver CSS bagunçado já que estão me pagando para isso. Meu framework foi usado em 3 projetos nossos, todos com resultado muito bom e o CSS usado de base é super simples de manter e ler o fonte (mesmo que o avante não vá receber mais atualizações).

Então, baseado nisso tudo, a definição nossa aqui na empresa é usar o Twitter Bootstrap em todos os projetos web junto nossas extensões que devo publicar em um pequeno git repo.

Não vejo problema algum abandonar uma tecnologia ou matar um projeto quando existem alternativas melhores no mercado. Se tem algo que não tenho amor nenhum é código… então Avante já nasceu morto em favor do Twitter Bootstrap que é agora sim, é fantástico.