Introdução ao Google Material Design Lite

Imagine o seguinte cenário: sempre que um novo sistema precisa ser criado, a equipe se divide em alguns passos, como definição da arquitetura inicial (client e server side), seleção do banco de dados, servidores (rede, arquivos, banco, ftp, etc.), dentre outros. Mas talvez um dos passos que sempre geram uma certa dor de cabeça seja a definição do layout/design do sistema. Dependendo da empresa/projeto/equipe que se esteja trabalhando, ele poderá se dar de várias formas:

· Ou o designer (que não necessariamente precisa ter conhecimentos sobre jQuery, JavaScript ou frameworks de componentes, como o Bootstrap, por exemplo) precisa fazer todo o trabalho criando telas estáticas para aprovação inicial do cliente, bem como HTML/CSS do mesmo para disponibilizar para os desenvolvedores;

· Ou os desenvolvedores entram nessa tarefa e trabalham em conjunto com o designer para “casar” as definições;

· Ou a equipe sequer faz uso de designer (exceto para imagens, o básico) e trata de ela mesma usar alguma biblioteca pronta para tal finalidade.

Esse é um processo bem flexível e, na verdade, é bom que seja. Assim, garante-se que a união de várias opiniões e experiências defina o que for melhor para o projeto final. Entretanto, suponha que você está criando seu próprio projeto, ou que sua equipe é muito pequena e não terão recursos para contratar um designer. Qual o primeiro passo que você tomaria para a definição de um design que atenda às cada vez mais exigentes expectativas dos seus usuários (design responsivo, componentes vivos, design bonito, fácil de usar, etc.)? Alguns provavelmente pensarão em copiar o design de alguma página estrangeira, ou quem sabe contratar um freelance para fazer apenas o design. Dentre as várias opções em mãos, a mais apropriada para os dias de hoje é, sem dúvida, usar alguma biblioteca de componentes pronta.

Um framework desse tipo já traz tudo que precisamos: vários componentes prontos que vão desde botões, barras de navegação, menus, formulários, listas, tabelas, até páginas e templates inteiros como a página de contato de um site, ou até mesmo um carrinho de compras.

Variáveis como linha de aprendizado, simplicidade, tamanho dos arquivos, quantidade de recursos disponíveis, bem como navegadores suportados e, sobretudo, preço, estão constantes nesse passo do ciclo de vida do layout. Partindo de um ponto de vista mais realista, poderíamos usar o Bootstrap. Ele é flexível, atende a todas as exigências que comentamos, é gratuito, tem um suporte enorme e excelente da comunidade, é open source e tem como dono nada mais nada menos que o Twitter. Sim, o Bootstrap é uma ótima opção. Entretanto, recentemente, tivemos o lançamento de um novo framework de componentes que promete inovar o mercado web, principalmente por se tratar de um padrão adotado por mais uma gigante do Vale do Silício, o Google. Trata-se do Google Material Design, que usamos para definir boas práticas de design em layouts para aplicativos móveis no Android. O sucesso com essa nova plataforma foi tão grande que o Google a redesenhou para se adaptar a todo tipo de dispositivo existente, desde smartphones, tablets, TVs, relógios e óculos inteligentes, e agora, inclusive, para a web.

A especificação original e final foi lançada em meados de 2014, com o objetivo de fornecer todas as instruções para um design bom e bonito para todos os dispositivos, independente do fabricante. Para as versões que fazem uso de simples HTML, CSS e JavaScript, damos o nome de Material Design Lite (MDL), uma terminologia mais apropriada considerando-se os ambientes onde irão executar. Dentre as inúmeras vantagens dele, destaca-se a sua leveza (lite) com um tamanho máximo de 27KB (em modo gzip) em código fonte, além das suas poucas dependências externas. Na seção Links encontramos a URL para a página oficial do projeto.

Neste artigo trataremos de expor os principais recursos desse novo framework, com alguns exemplos práticos próximos da realidade de aplicações web (que envolvem um aparato de codificação, não apenas design).

Detalhes da arquitetura

Se dermos uma olhada mais a fundo do framework veremos que, na verdade, ele é uma implementação complementar do projeto Paper elements, um subprojeto do framework Polymer que já faz uso dos conceitos de Material Design para construir interfaces web ricas, com elementos interativos, transições, efeitos, etc. Isso significa que podemos integrar o MDL com o Polymer facilmente e tirar proveito de seus componentes para criar designs de forma rápida e responsiva.

A maioria dos componentes que usamos em outras plataformas está disponível no MDL também, desde tooltips, campos de formulários diversos, spinners, até uma grid responsiva característica desse tipo de layout.

Além de ser suportado por todos os browsers mais recentes (Chrome, Firefox, Opera, Edge, etc.), os fontes do MDL são escritos em Sass usando BEM (contração para Block, Element, Modifier), trata-se de uma metodologia que visa aumentar a velocidade e produtividade no desenvolvimento de uma forma geral. As suas siglas significam:

· Block: um componente lógico e funcional independente, o equivalente a um componente nos famosos Web Components. Um block (ou bloco) encapsula comportamento (via JavaScript), templates, estilos (CSS) e outras tecnologias implementadoras. O conceito de independência é usado para facilitar o reuso de estruturas, assim como facilitar o desenvolvimento do projeto e o processo de suporte ao mesmo. Na Figura 1 vemos um modelo simples de como tais blocos se ajustam uns em relação aos outros; por exemplo: um bloco de cabeçalho (head) pode ter uma logo incluída, um formulário de busca e um bloco interno de autorização (login do usuário);

· Element: é uma parte constituinte de um bloco que não pode ser usada de fora do mesmo. Por exemplo, um item de menu não pode ser usado de fora do contexto de um bloco de menu, portanto ele é um element (ou elemento).

· Modifier: é uma entidade BEM que define a aparência e comportamento de um bloco ou elemento. Eles são similares aos atributos HTML, em essência. Um mesmo bloco tem aparência diferente em relação a outro quando usa um modifier (ou modificador) ...