Designers versus Bootstrap

Bootstrap

Bootstrap

Embora eu não seja um web designer por formação, estou muito interessado na disciplina. Como tal, eu leio livros e blogs com foco em design.

Ocasionalmente, percebo que determinados temas provocam fortes emoções na comunidade. Temas como “Flat design: uma boa ideia ou a melhor ideia de todos os tempos”, “Qual é a punição correta para um CEO que redesenha o logotipo de sua empresa durante um final de semana?”.

Um desses tópicos de debate é se é uma boa ideia usar um framework front-end, como Bootstrap ou Foundation, em vez de construir um você mesmo. Como eu sou um grande fã desses frameworks, fiquei curioso quanto às razões de por que usar um seria uma má ideia.

Até onde eu posso dizer, a oposição aos frameworks front-end decorre das seguintes crenças:

Frameworks forçam você a uma marcação “não-semântica”

Marcação semântica é sobre HTML limitando apenas aquelas marcas necessárias para expressar o conteúdo da página, ao contrário de seu layout. Por isso, coisas como “container divs” são malvistas.

Bem, Bootstrap, de fato, faze uso liberal de elementos apenas de layout, como este:


1 <div class="container">
2   ...
3 </div>

 

 

Frameworks são muito super valorizados

Outra queixa comum é que em sua busca para ser todas as coisas para todas as pessoas, frameworks front-end possuem coisas das quais você pode nunca precisar. Por exemplo, Bootstrap permite várias maneiras de estruturar os links de navegação: como abas ou pills, com ou sem menus suspensos, fixos ou não, verticais ou horizontais. Se o seu site precisa de apenas um (ou talvez dois) deles, por que suas folhas de estilo incluem todos esses estilos estranhos?

Frameworks fazem tudo para parecer muito igual

Frameworks front-end te dão um conjunto de opções padrão para construir seus sites. Portanto, não é uma grande surpresa quando as pessoas constroem seus sites usando essas opções. O efeito colateral disso é que você olha e vê “Bootstrap” em todos os lugares.

Então Bootstrap não é bom?

Agora que eu já construí um bom espantalho com os argumentos da oposição, eu sou obrigado a tacar fogo no espantalho.

Marcação semântica onde faz sentido

Em primeiro lugar, vamos direto ao ponto de marcação semântica. Sim, na medida em que uma página HTML é um documento, ela deveria incluir o conteúdo e um pouco mais. A boa notícia é que para toda uma classe de páginas HTML este é um ajuste natural: blogs, sites de marketing, revistas, e assim por diante.

No entanto, a web está cheia de páginas HTML que servem a um propósito bem diferente: a de um contêiner de aplicativos. Para todos os clientes de e-mail, editores de documentos, formulários de pedidos de compra, análise de dashboards e assim por diante, a pureza semântica é legal, mas receber o app para expor corretamente é muito mais agradável.

Bootstrap, com todos os seus “container” divs, ajuda a resolver o problema de layout para aplicativos. Além disso, se a pureza semântica é uma preocupação forte, ele te fornece as ferramentas para gerenciar layouts sem violá-los.

Cheio de features, mas com features demais

Sim, Bootstrap tem uma tonelada de classes CSS nele, provavelmente milhares e milhares. No entanto, é 107k são minificados e altamente armazenávies em cache. Para efeito de comparação, uma simples adição de imagem do New York Times de hoje tem 20K.

Claro, existem sites para os quais vale a pena salvar entre 30-50K extras por pedido inicial. E nesses casos, pelo amor de qualquer coisa que você queira, personalize todos fora do CSS. Caso contrário, considere se o esforço extra vale a pena.

Ele só parece o mesmo se você deixar

A razão pela qual muitos sites construídos com Bootstrap parecem ser semelhantes é porque elas são feitas por desenvolvedores e não designers. A maioria dos desenvolvedores tem pouco interesse/habilidade de personalizar de forma eficaz os aspectos visuais de um site e, assim, usar o que já parece ser bom: o tema padrão.

Claro que, para aqueles que podem (ou querem) ajustar o visual, há muito que pode ser feito.

Algo mais?

Existem mais dois benefícios do uso de frameworks front-end que tenho que mencionar. O primeiro é o suporte para design responsivo. O Bootstrap 3.0 tem várias opções para fazer suas páginas parecerem agradáveis em diversos tipos de dispositivos. E mesmo que demore um pouco para envolver sua mente nessa abordagem, ela pode ser muito eficaz.

Em segundo lugar está o suporte para navegadores mais antigos (ou seja, IE8). IE8 é o grande devorador de tempo de desenvolvimento web. Ele pode levar horas e horas de ajustes e correções até que o seu layout que funciona muito bem em todos os outros navegadores finalmente fique decente. Embora não seja perfeito, o suporte do Bootstrap para IE8 é muito bom.

Reflexão final

Alguns designers dizem que nenhum designer que se preze usaria um framework que não criou. Eles temem perder o controle sobre o seu projeto, sem o benefício aparente suficiente para compensar essa perda. Eu costumava ter uma opinião similar sobre o uso de frameworks de desenvolvimento, mas aí eu superei isso e comecei a fazer o que tinha que ser feito.

—–

Artigo de Alex Tatiyants, publicado no iMasters.

DialHost
DialHost

Contamos com nosso DataCenter no Brasil de alta qualidade, estabilidade e confiança para hospedar seu site. Utilize poderosas ferramentas para otimizar o uso do seu serviço e seja sempre atendido de forma rápida e clara pelo nosso atendimento 24h.

Explorando o Composite Pattern JavaScript

Imagem ilustrativa

Imagem ilustrativa

Design Patterns é um assunto bem comum em todas as linguagens de programação, e o mais importante quando se trata em manutenção de código. Um pattern é uma solução reutilizável que pode ser aplicada em um projeto de desenvolvimento de software. Hoje, vamos explorar o Composite pattern com implementação JavaScript.

O composite pattern diz que um grupo de objetos pode ser tratado da mesma maneira que um objeto individual desse grupo.

Um uso bem comum de Composite Pattern que você provavelmente já tenha visto é o sistema de diretórios de um Sistema Operacional que utiliza estrutura de dados em árvore (considere que temos uma pasta e dentro dessa pasta temos várias outras pastas, e que dentro de cada uma dessas outras pastas temos mais algumas pastas, e assim por diante).

Nesse modelo, temos “N” objetos que possui “N” filhos que também pode ter mais “N” filhos. Entretanto, a quantidade de objetos não importa, porque a implementação é a mesma para todos eles. Ok? Vamos ver isso melhor na prática.

Exemplo: Construindo uma cidade com Composite Pattern

Vamos colocar a mão na massa e criar nosso próprio exemplo modificando um pouco o modelo apresentado acima, mas ainda seguindo a estrutura em árvore. No nosso exemplo vamos construir duas cidades que possuem bairros que, por sua vez, possuem algumas casas (lembre-se da estrutura em árvore). Algo bem simples e que vai ficar parecido com isto:

| cities
|
|– São Paulo/
| |– Liberdade
| |– Casa 1
| |– Casa 2
| |– Ipiranga
| |– Casa 3
|
|– Rio de Janeiro/
| |– Leblon
| |– Casa 4
| |– Lapa
| |– Casa 5
| |– Casa 6
|

O objeto possuirá os seguintes métodos específicos do nosso composite:

add: adiciona um novo filho para o objeto;
remove: remove um determinado filho do objeto;
getChild: retorna um filho do objeto;

Método auxiliar:

getElement: retorna o elemento HTML do objeto específico;

Criamos o objeto “Cidade” que terá o formato composite:


1 var City = function (title, id, className) {
2     this.children = [];
3     this.element = document.createElement('div');
4     var h2 = document.createElement('h2');
5
6     this.element.id = id;
7     if (className) this.element.className = className;
8
9     h2.textContent = title;
10     this.element.appendChild(h2);
11
12 }
13
14 City.prototype = {
15     add: function (child) {
16         this.children.push(child);
17         this.element.appendChild(child.getElement());
18     },
19
20     remove: function (child) {   
21         for (var node, i = 0; node = this.getChild(i); i++) {
22             if (node == child) {
23                 this.children.splice(i, 1);
24                 this.element.removeChild(child.getElement());
25                 return true;
26             }
27         }
28
29         return false;
30     },
31
32     getChild: function (i) {
33         return this.children[i];
34     },
35
36     getElement: function () {
37         return this.element;
38     }
39 }

Instanciamos os objetos e montamos a estrutura


1 var cities = new City('', 'cities');
2 var saoPaulo = new City('São Paulo', 'sao-paulo');
3 var rioDeJaneiro = new City('Rio de Janeiro', 'rio-de-janeiro');
4 var liberdade = new City('Liberdade', 'liberdade');
5 var ipiranga = new City('Ipiranga', 'ipiranga');
6 var lapa = new City('Lapa', 'lapa');
7 var leblon = new City('Leblon', 'leblon');
8 var casa1 = new City('Casa 1', 'casa-1', 'composite-house');
9 var casa2 = new City('Casa 2', 'casa-2', 'composite-house');
10 var casa3 = new City('Casa 3', 'casa-3', 'composite-house');
11 var casa4 = new City('Casa 4', 'casa-4', 'composite-house');
12 var casa5 = new City('Casa 5', 'casa-5', 'composite-house');
13 var casa6 = new City('Casa 6', 'casa-6', 'composite-house');
14 var casaRemover7 = new City('Casa remover 7', 'casa-remover-7', 'composite-house');
15
16 liberdade.add(casa1);
17 liberdade.add(casa2);
18
19 ipiranga.add(casa3);
20 ipiranga.add(casaRemover7);
21
22 ipiranga.remove(casaRemover7); // Removido
23
24 lapa.add(casa4);
25
26 leblon.add(casa5);
27 leblon.add(casa6);
28
29 saoPaulo.add(liberdade);
30 saoPaulo.add(ipiranga);
31
32 rioDeJaneiro.add(lapa);
33 rioDeJaneiro.add(leblon);
34
35 cities.add(saoPaulo);
36 cities.add(rioDeJaneiro);
37
38 document.body.appendChild(cities.getElement());

Se preferir, aqui está o demo de como ficou o exemplo funcionando. Composite pattern é interessante quando temos uma coleção de objetos que possuem o mesmo tratamento, é um ótimo pattern e bastante usado pelos desenvolvedores.

Espero que tenham gostado. Qualquer dúvida, sugestão ou crítica, fique à vontade para deixar seu comentário. Até a próxima!

—-

Artigo de Pedro Araújo, publicado no iMasters.

DialHost
DialHost

Contamos com nosso DataCenter no Brasil de alta qualidade, estabilidade e confiança para hospedar seu site. Utilize poderosas ferramentas para otimizar o uso do seu serviço e seja sempre atendido de forma rápida e clara pelo nosso atendimento 24h.

WHATWG a HTML5 são apenas uma versão do HTML?

html

HTML

É comum eu me deparar com dúvidas sobre a HTML5, não só em fóruns e listas de discussão, mas também em conversas com meus amigos desenvolvedores em eventos, que muitas vezes têm sua explicação relacionada com a filosofia de desenvolvimento da linguagem.

É um assunto interessante e curioso que vale uma reflexão, por isso escrevi esse artigo.

A filosofia de desenvolvimento de especificações do W3C prevê que uma especificação passe por uma série de estágios não necessariamente finais, pois pode haver volta a um estágio anterior, até que a especificação atinja o status de Recomendação do W3C, do qual não haverá mais volta, pois este é o estágio final e definitivo. O processo inicia-se novamente para uma próxima versão da especificação.

A WHATWG adota a filosofia de desenvolvimento da especificação sem o objetivo de alcançar uma versão final. O processo é contínuo e sempre direcionado para a tecnologia sem a necessidade de rotular cada estágio com um número, pois há somente um estágio, o atual.

Essa diferença de abordagem gerou confusão no processo de desenvolvimento da HTML, pois hoje temos um documento que descreve o desenvolvimento da especificação para a HTML5 e outro para a HTML5.1 no site do W3C e um documento que descreve o desenvolvimento da especificação para a HTML no site do WHATWG.

Para melhor entender o acabamos de dizer, leia a seguir, em tradução livre, duas afirmações retiradas do documento para as especificações HTML do WHATWG.

O termo “HTML5″ é um buzzword para designar as modernas tecnologias para web, muitas das quais (não todas) são desenvolvidas pelo WHATWG. Este documento é dedicado a uma destas tecnologias; outros estão disponíveis e estão relacionados no índice das especificações do WHATWG (http://kwz.me/wm).

Fica claro que para o WHATWG a HTML5 é muito mais que uma versão da HTML. É um conjunto de tecnologias, tais como, DOM, Fullscreen, Web Sockets, WebGL, Storage etc. Ao contrário do que considera o W3C com sua filosofia de especificação versionada e finalizada para a HTML.

Embora nós já tenhamos pedido para eles pararem com essa prática, o W3C continua publicando algumas partes da nossa especificação como uma especificação separada. Existem inúmeras diferenças entre estas especificações e as especificações do W3C; umas pequenas, outras significativas. Infelizmente não há, em lugar algum, um documento listando as diferenças, assim não há como saber quais diferenças são propositais e quais não são.

Sobre esta citação, deixo por conta do leitor concluir o que fica claro, mas aponto um exemplo das diferenças citadas: para o W3C o elemento hgroup não existe e obviamente não consta da sua especificação ao passo que para o WHATWG, aquele elemento consta da especificação em toda sua glória.

Hoje (agosto/2014), a especificação para a HTML5 encontra-se na fase de Candidata a Recomendação e as funcionalidades da linguagem devem ser estudadas baseando-se naquele documento hospedado no site do W3C.

Já existe um Rascunho do Editor do W3C que possivelmente será elevado ao status de Rascunho de Trabalho para as especificações da HTML5.1 – possivelmente a próxima versão da HTML. O documento encontra-se hospedado no site do W3C.

O WHATWG continua desenvolvendo a HTML, mas como dito anteriormente, para aquele Grupo de Trabalho não existe mais uma versão. A especificação encontra-se hospedada no site do WHATWG.

Será que um dia vão fazer as pazes? O que você pensa a respeito? Comente!

DialHost
DialHost

Contamos com nosso DataCenter no Brasil de alta qualidade, estabilidade e confiança para hospedar seu site. Utilize poderosas ferramentas para otimizar o uso do seu serviço e seja sempre atendido de forma rápida e clara pelo nosso atendimento 24h.

Falando sobre aplicações e conteúdo dinâmico acessível

Aplicações e conteúdo dinâmico acessível

Imagem ilustrativa: Tela de codificação

Conteúdos dinâmicos ainda tinham barreiras sérias de acessibilidade, inclusive porque as tecnologias assistivas não conseguiam acessar modais ou áreas que eram atualizadas sem um “refresh” completo da página. Para tornar esse conteúdo dinâmico acessível na Web o W3C publicou a recomendação WAI-ARIA 1.0, que se tornou uma Recomendação do W3C em março de 2014.

WAI-ARIA (Accessible Rich Internet Applications) define a forma de tornar conteúdo, principalmente aplicações Web, acessíveis para pessoas com deficiências. Essa documentação auxilia especialmente conteúdo dinâmico e interfaces de usuário com controles avançados. WAI-ARIA funciona com as tecnologias já existentes, como HTML e SVG e proporciona uma forma de aplicar os requisitos das WCAG para aplicações ricas na Web.

Aplicações web complexas tornam-se inacessíveis quando as tecnologias assistivas não podem determinar a semântica de partes de um documento ou quando o usuário não é capaz de navegar de forma eficaz em todas as partes do site ou aplicação. WAI-ARIA divide a semântica em roles (papéis), states e properties (estados e propriedades).

Roles servem para identificar o elemento ou a aplicação na interface e estão divididas em quatro tipos:

  •     Abstract Roles: Usadas para ontologias. Não devem ser utilizadas para conteúdo
  •     Widget Roles: Utilizadas para definir interfaces de widgets, como alert, dialog, slider, tab, etc.
  •     Document Structure Roles: descrevem as estruturas que organizam o conteúdo em uma página, por exemplo article, group, img, region, etc. Estruturas de documentos geralmente não são interativos.
  •     Landmark Roles: são regiões da página destinadas a marcação de navegação, por exemplo banner, main, navigation, etc.

A lista completa de roles está neste link.

Cada uma das “roles” pode ser manipulada e definida por diversos “states and properties”, por exemplo, um link definido como item de um checkbox pode ser definido como “true” ou “false” para que o usuário tenha um retorno acessível do resultado da ação.

<li role=”menuitemcheckbox” aria-checked=”true”>Link ativo</li>

A lista completa de states and properties para cada role está aqui.

Uma das principais diferenças entre as WCAG e ARIA é que a primeira utiliza os elementos semânticos do HTML para tornar o conteúdo acessível. Já WAI-ARIA possibilita a mudança da semântica de um elemento para torna-lo acessível. Eu explico.

Neste exemplo, o desenvolvedor precisa criar um cabeçalho que é um botão. Para esse caso a recomendação é:

  •     Não faça isso: <h1 role=button>botão</h1>
  •     Faça isso: <h1><button>botão</button></h1>
  •     Ou então isso: <h1><span role=button>botão</span></h1>

Porque se role=button for colocado dentro do H1, a estrutura de acessibilidade dos objetos tratará esse elemento como <button>botão</button> e perderá sua característica de cabeçalho.

Por esse motivo, WAI-ARIA deve ser utilizado somente onde não for possível utilizar a semântica do HTML para tornar o conteúdo acessível. Sempre dê prioridade para as WCAG.

A Web está em constante evolução e conforme ela evolui, navegadores e tecnologias assistivas devem acompanhar esse processo. Por esse motivo o W3C tem uma preocupação imensa com a acessibilidade. A Web foi criada com o intuito de ser acessível desde sua concepção e esse princípio deve acompanhar sua evolução. E nós, criadores e mantenedores dos códigos que circulam pela Web, temos uma responsabilidade imensa de manter esse legado de uma Web acessível para as atuais e futuras gerações, afinal, dentro de algumas décadas nós poderemos ser os usuários de tecnologias assistivas que vão acessar esse conteúdo na Web. E ele deve ser acessível. Para o nosso próprio bem.

——

Artigo de Reinaldo Ferraz, publicado originalmente no portal iMasters.

DialHost
DialHost

Contamos com nosso DataCenter no Brasil de alta qualidade, estabilidade e confiança para hospedar seu site. Utilize poderosas ferramentas para otimizar o uso do seu serviço e seja sempre atendido de forma rápida e clara pelo nosso atendimento 24h.

Templates de e-mail marketing amigáveis

templates amigáveis

Exemplo de construção de templates

Você planeja uma ótima campanha de e-mail marketing, mas vê que seu retorno foi muito abaixo do esperado – principalmente a abertura das mensagens. Um dos problemas pode ser a forma como o template foi construído: o ideal é utilizar um template montado em HTML, e nunca uma imagem exportada.

Ao transformar todo seu e-mail marketing numa única imagem, há o risco da mesma ser barrada, pois quase todos os serviços de e-mail têm um bloqueio padrão de segurança para exibição de qualquer formato de imagem que esteja em um e-mail.

Abaixo, algumas dicas simples para a montagem de um bom template, amigável e “legível” para os clientes de e-mail:

  • O ideal é fatiar a imagem e produzir as partes do texto no HTML. Lembre-se: quando o serviço de e-mail bloquear as imagens do template, sua única arma para cativar o leitor será o texto.
  • Diagrame o conteúdo em tabelas, e evite mesclar linhas e colunas através do conteúdo rowspan e colspan, que não são suportados pelo Outlook 2007.
  • Defina o alinhamento de todos os objetos do template, dando atenção especial a células e tabelas que contenham imagens e texto. Se não houver essa definição, os clientes de e-mail tendem a centralizar o conteúdo, o que pode ser prejudicial à leitura da mensagem pelo destinatário.
  • Coloque links nas imagens: mesmo se elas não forem exibidas, suas áreas serão clicáveis. Essa prática é bastante útil;
  • Fuja das propriedades de posicionamento position, left, clear, etc que, apesar de suportarem CSS inline, não são muito amigáveis aos clientes de e-mail.
  • Sempre faça a verificação do código HTML do e-mail de acordo com as recomendações da W3C, disponível em http://validator.w3.org/
  • Cuidados com as cores! Alguns clientes de e-mail têm restrições ao exibir a cor de fundo das mensagens. Utilize os atributos bgcolor do HTML e backgroud-color do CSS, juntos.
  • Não use imagens tipo “spacer” com dimensões de 1px de altura ou largura. Essa é uma prática comum de spammers para checar endereços de e-mails ativos, portanto considerada spam. Caso seja necessário inserir espaços vazios entre os elementos, faça a quebra de linha simples <br> ou utilize uma célula de tabela vazia <td> em que você possa controlar altura e largura.
  • HTML gerado por editores gráficos: definitivamente, não! Eles utilizam várias tags que “sujam” o código. Apesar de mais trabalhoso o HTML montado é pode trazer melhores resultados.
  • Lembre-se sempre em manter o código limpo e o css inline.
  • Deixe suas imagens de template em um servidor web e utilize sempre o caminho absoluto das imagens. Ex.: http://dm-img.dialmailer.com/cID11/DialMailer.jpg
  • Dica final, e a mais importante: não acredite no resultado apresentado no navegador. Envie mensagens de teste para os principais serviços de e-mail, como Outlook, Outlook.com, Gmail, Yahoo e confira o resultado. Este é o melhor jeito de confirmar que sua mensagem está perfeita.

Confira a nossa solução de E-mail Marketing para facilitar o gerenciar sua campanhas

DialHost
DialHost

Contamos com nosso DataCenter no Brasil de alta qualidade, estabilidade e confiança para hospedar seu site. Utilize poderosas ferramentas para otimizar o uso do seu serviço e seja sempre atendido de forma rápida e clara pelo nosso atendimento 24h.