# 5 armadilhas de web design responsivo a evitar

> Evite erros comuns em design responsivo. Aprenda sobre performance, conteúdo, contexto e experiência mobile para criar sites verdadeiramente adaptáveis.

URL: https://dpw.dev/design/5-armadilhas-de-web-design-responsivo-a-evitar/  
Publicado em: 2013-06-03  
Categoria: design  
Tags: interface, layout, planejamento  
Autor: Tárcio Zemel

Criar grandes **experiências responsivas** requer muito mais do que o uso de media queries. O fato é que é preciso entregar aos visitantes uma experiência sólida para um número crescente de dispositivos com acesso à web e a criação de experiências totalmente diferentes por dispositivo é simplesmente inviável. Criar experiências de adaptação é um bom caminho a se seguir, mas isso não significa que essa abordagem não tem seus próprios desafios.

A seguir, veja **5 armadilhas de web design responsivo** que você deve evitar a fim de desenvolver e proporcionar às pessoas que visitam seus sites responsivos.

> Artigo baseado em [Five responsive web design pitfalls to avoid](http://www.netmagazine.com/features/five-responsive-web-design-pitfalls-avoid).

## Esconder conteúdo

Devido ao fato de sites responsivos compartilharem uma única base de código, eles têm uma melhor chance de alcançar a [paridade de conteúdo](http://bradfrostweb.com/blog/mobile/content-parity/), o que é ótimo. No entanto, isso não significa que tudo são flores. Existem, ainda, muitos sites responsivos que escondem ou removem conteúdo para telas menores, a fim de lidar com suas restrições intrínsecas.

Siga esta dica simples: **não penalize as pessoas pelo dispositivo que estão usando para acessar seus sites**! As pessoas estão vindo aos nossos sites e serviços com expectativas e é nosso trabalho ter certeza de que eles são capazes de atingir seus objetivos. Pessoas com dispositivos móveis farão tudo o que as que usam desktop fariam, mas é preciso apresentar as coisas de uma forma utilizável. Então, faça tudo o que puder para garantir que o maior número possível de pessoas possam acessar seus conteúdos e funcionalidades.

Importante lembrar, também, que o conteúdo que fica escondido com CSS ainda é baixado, o que é terrível para o desempenho e, automaticamente, leva à próxima armadilha a ser evitada.

## Inchaço de conteúdo

Tudo bem, então você não está escondendo conteúdo para telas menores e fez um esforço para entregar uma experiência completa, independentemente do contexto. Tudo está correto, então? Bem, não, porque, agora, você tem um monte de coisas para carregar e isso leva tempo.

[74% das pessoas com dispositivos móveis abandonarão o site depois de 5 segundos](http://www.gomez.com/wp-content/downloads/19986_WhatMobileUsersWant_Wp.pdf) (.pdf) de espera para uma página para carregar; e a triste realidade é que apenas [3% das versões de sites para telas pequena](http://bradfrostweb.com/blog/mobile/bdconf-guy-podjarny-presents-performance-implication-of-mobile-design/) são significativamente mais leves do que suas contrapartes de tela grande. Isso significa que as pessoas carregam o fardo de fazer downloads potencialmente enormes!

Uma [página normal no site responsivo "Barack Obama"](http://www.barackobama.com/pa) pesa mais de **4MB**. Quatro... Megabytes... Isso é inaceitável para qualquer padrão, mas é especialmente alarmante quando você considera que as pessoas podem estar em EDGE, 3G ou uma má conexão sem fio.

Para um site cujo objetivo é chegar à "população, em geral" (todos com diferentes raças mobile, credos mobile, cores mobile e religiões mobile), isso causa questões de acessibilidade graves:

Um dos maiores desafios da criação de projetos responsivos é o balancear da entrega de uma experiência completa ao mesmo tempo em que se mantém o visitante "ligado".

[Corte os excessos](http://adactio.com/journal/4523/), siga as [melhores práticas de desempenho](http://developer.yahoo.com/performance/), não assuma uma boa conexão por padrão e procure maneiras de explorar técnicas como [carregamento condicional](http://24ways.org/2011/conditional-loading-for-responsive-designs) para manter o tamanho da página inicial pequeno.

## Ignorar convenções contextuais

Um telefone não é um tablet que não é um laptop que não é um desktop que não é uma TV.

Cada dispositivo possui seu próprio e único "fator de forma", convenções de interface, restrições e oportunidades. É preciso atenção com todas essas variantes a fim de criar experiências que sejam naturais ao usuário. Veja que o que se está sugerindo não é a recriação da UI nativa de cada plataforma no navegador, mas é preciso estar consciente de como as pessoas seguram seus dispositivos, que ícones estão acostumadas a ver, e assim por diante. Uma boa **experiência responsiva** extrapola a sandbox que é o navegador e é simpática à pessoa e ao contexto do dispositivo.

Web design responsivo, por definição, não é design para dispositivos móveis; por isso, cabe aos desenvolvedores introduzirmos elementos contextualmente relevantes aos projetos. Isso significa lidar com [navegação responsiva](http://bradfrostweb.com/blog/web/responsive-nav-patterns/) de uma maneira que faz sentido para os visitantes, em todos os contextos; isso significa [projetar para touch](http://globalmoxie.com/blog/buttons-are-a-hack.shtml); isso significa evitar forçar as pessoas com dispositivos móveis a rolar longas quantidades de conteúdo díspares para encontrar o que estão procurando.

## Servir uma experiência num-tamanho-cabe-tudo

Mobile é [muito mais](http://tripleodeon.com/2010/10/not-a-mobile-web-merely-a-320px-wide-one/) do que várias telas pequenas e esses contextos emergentes desbloqueam casos de uso, padrões e possibilidades totalmente novos. Não devemos nos limitar a somente criar layouts responsivos. Por exemplo, às vezes nos esquecemos de que os telefones podem [obter a localização do usuário](http://dev.w3.org/geo/api/spec-source.html), [iniciar chamadas telefônicas](http://bradfrostweb.com/blog/mobile/a-tel-tale-sign/) e muito mais. Em breve, navegadores em todos esses dispositivos terão acesso a [ainda mais APIs](http://bradfrostweb.com/blog/mobile/bdconf-james-pearce-presents-this-web-goes-to-11/), expandindo ainda mais os limites do que é possível na web.

Faça tudo o que puder para tornar toda a experiência responsiva a o quê o dispositivo é capaz de fazer. [Levando em conta, primeiro, as restrições](http://www.html5rocks.com/en/mobile/responsivedesign/), provê uma base sólida de sustentação para, então, surgir o foco na utilização de _[progressive enhancement](http://easy-readers.net/books/adaptive-web-design/)_ e _[feature detection](/css/modernizr-detectar-features-html5-css3/)_ para levar a experiência para o próximo nível.

## Basear-se em dimensões de dispositivos

320px. 480px. 768px. 1024px. "Abaixo da dobra"...

O fato é que não é possível controlar o tamanho do navegador dos visitantes nem as dimensões que os fabricantes decidem fazer seus dispositivos - [e este foi alerta dado em relação ao Screensize.es](https://plus.google.com/u/0/114896277363762090056/posts/PYpeaGfudiB).

![](/images/blog/5-armadilhas-de-web-design-responsivo-a-evitar/5-armadilhas-de-web-design-responsivo-a-evitar-devices.webp)

Além disso, "abaixo da dobra" nunca foi uma medida única por causa da barra de favoritos, estilização e moldura (chrome) de cada navegador e eventuais outras barras que estejam sendo usadas. Mas, agora, no mundo web móvel, uma experiência web muitas vezes não é vista através das "lentes" dos navegadores.

É possível acessar sites através do Facebook, Twitter e outros aplicativos, cada um dos quais com sua própria "moldura" customizada. Obviamente,hierarquia de conteúdo ainda importa (e muito) e todos querem chegar ao principal de uma página o quanto antes, mas você não pode ficar incomodado em relação àltura em pixels disponível; aprenda a deixar isso pra lá.

Em seu artigo "[A fanfarra do breakpoint comum](http://adactio.com/journal/5425/)", Jeremy Keith eloquentemente afirma que "não é sobre o que acontece nos breakpoints; é sobre o que acontece entre breakpoints". Isso significa que os designs devem se manter coesos independentemente de qualquer dimensão, em particular.

Deixe o design, por si, mesmo, resolver onde os breakpoints devem ocorrer. [Um excelente conselho de Stephen Hay](http://bradfrostweb.com/blog/mobile/bdconf-stephen-hay-presents-responsive-design-workflow/) é:

> "Comece com a tela menor e, em seguida, expanda até parecer muito ruim. É hora de inserir um breakpoint!"

Ao permitir que o conteúdo, em si, determine os breakpoints de projetos responsivos, o que você está fazendo é preparando esses projetos para ficarem preparados para o amanhã!

## Faça a evolução

Ainda estamos na ponta do iceberg quando o assunto é a criação de experiências responsivas totalmente adequadas. Embora existam essas **5 armadilhas de web design responsivo** (e muitas mais, não abordadas nesse artigo), elas não são desculpa para fugir e não tentar criar boas experiências responsivas.

Com mais dispositivos conectados, de todas as formas e tamanhos, entrando em cena todos os dias, nós, como criadores de web, temos a oportunidade de estar lá quando eles chegarem. Embora seja reconhecidamente um pouco assustador, devemos aceitar o desafio e abraçar a oportunidade de alcançar as pessoas onde quer que estejam!

---

Fonte: [dpw - desenvolvimento para web](https://dpw.dev/) (pt-BR).
Guia para agentes: https://dpw.dev/llms.txt
Índice completo: https://dpw.dev/sitemap-index.xml
Feed: https://dpw.dev/rss.xml