O documento discute aplicações responsivas e webdesign responsivo. Resume três principais técnicas de webdesign responsivo: layout fluído com valores percentuais, imagens flexíveis e consultas a mídias. Também discute performance como aspecto crucial para aplicações móveis.

1. Aplicações Responsivas
Jackson F. de A. Mafra

2. Jackson F. de A. Mafra
http://about.me/jacksonfdam
https://bitbucket.org/jacksonfdam
https://github.com/jacksonfdam
http://linkedin.com/in/jacksonfdam
@jacksonfdam

3. Aplicações
Responsivas

4. Arquitetura
Responsiva
O termo Arquitetura responsiva foi
dado pelo pesquisador Nicholas
Negroponte que inicialmente
concebeu nos anos 1960 durante o
design de espaços onde foram
explorados os conceito de
cibernética para a arquitetura.
http://en.wikipedia.org/wiki/File:NNe
goponte_USNA_20090415_.jpg

5. Arquitetura responsiva é aquela que as condições
do espaço e ambientes podem mudar e se
adaptar a condições pre-definidas ou desejáveis ,
por meio de sensores, alterando as características
de forma, cores, espaços e todos os elementos
que compõem o espaço arquitetônico de modo
responsivo. Para tal são utilizados sensores e
atuadores robóticos.

6. Webdesign
Responsivo
O termo utilizado para definir um web
desing responsivo foi criado por Ethan
Marcotte, em seu artigo no site A list apart.
Marcotte consolidou três principais
técnicas para este modelo: Layout fluído,
Imagens flexíveis, e Consultas a mídias
(Media queries) em uma abordagem
unificada, que o nomeou de web design
ágil.
http://www.flickr.com/photos/z
eldman/6495074887/
http://www.alistapart.com/artic
les/responsive-web-design/

7. Layout fluído
A técnica de layout fluído se baseia em usar
valores percentuais ao invés de absolutos para as
tags que delimitam as áreas do site (div), ou seja,
ao invés de declarar a largura do site com valores
absolutos em pixels (px), usamos valores
proporcionais em percentual (%). Desta forma o
site e suas subpartes ocuparão uma área relativa
ao tamanho da janela do navegador do usuário.
Larguras em "%". Textos
em "em".

8. Imagens flexíveis
Tão importante quanto um layout que responda
aos diversos tamanhos de tela. As imagens
também devem adaptar-se ao tamanho de tela
do device em que está sendo acessado, utilizando
valores proporcionais em percentual (%).

9. Media queries
São seletores em CSS3 que consulta as mídias do
navegador quando o seu site for acessado. Com
as Medias Queries configuradas, o navegador
exibe o layout de acordo com o dispositivo que
está acessando o site, ou seja, o navegador
interpreta o tamanho de tela que foi configurado
na media querie e exibe o layout que foi definido
no CSS.

10. Case: skinnyties
http://skinnyties.com/

11. “Não importa o
dispositivo e sim
o usuário final”
Horácio Soares

12. Redimencionar
não é tudo.

13. Mobilize, don’t
miniaturize
Miniaturizing “treats the mobile environment and
technology as a
subset of the desktop environment.”
Miniaturizar "trata o ambiente mobile e a tecnologia como
um subconjunto do ambiente de desktop. "
Barbara Ballard UX Designer, 2007

15. Prototipar
Papel e Lapis são ótimos e baratos.
01 A4 – Paisagem = Desktop
01 A4 dobrado ao meio / 02 A5 = 02 Telas de
iPad
01 A5 dobrado 03 vezes = 03 Telas de iPhone

16. Mockups
Ferramentas Balsamiq,
mokk.me,mockupbuilder,proto.io

17. Frameworks
Twitter Boostrap
Foundation

18. http://alistapart.com/article/div
e-into-responsive-prototyping-
with-foundation

19. Dividir as telas
em modulos
Grid,texto,menu, tabelas

20. Grids

21. Textos
Não usar textos com tamanho em px pela
aplicacao, use no body e os demais em em

22. Menu
Melhor disposição para a navegação.
Sidebar Nav, Dropdown, Select Menu, PullDown

23. Tabela
Ajustar os dados, ocultar colunas.

24. Don’t shrink,
rethink
Jeff Hawkins (Fundador da Palm) em 1998

25. Zoom
Um zoom de 200%, na prática, faz 1px
no CSS ser renderizado como 2px na
tela. No fim, se você estiver em um
notebook de 1280px de tela, a página
passaria a renderizar com um
viewport de 640px.

26. Zoom
Todos os navegadores suportam esse tipo de
recurso: Firefox, Chrome, Android, Opera, Internet
Explorer e Safari. Só há um bug no Webkit –
Chrome, Safari, Android – que faz a media query
ser aplicada apenas se o usuário der zoom e
depois um refresh na página; em todos os outros, a
media query é aplicada imediatamente de
acordo com o zoom.

27. Zoom
 O zoom dos navegadores modernos aumenta a
página toda – texto, imagens, CSS etc. Nos
navegadores antigos – como IE6 ou IE7 –, não
existia isso e era comum o usuário aumentar o
tamanho da fonte. Era bem mais simples: só o
font-size base mudava e a página só aumentaria
se você usasse em nas medidas CSS.
 Aliás, esse era um argumento forte a favor de
em na época, mas hoje em dia os browsers dão
zoom inclusive em medidas com px fixos.

28. Zoom
 As telas pequenas dos smartphones ensinaram
algo simples para os usuários: se algo estiver
pequeno, apenas arraste os dedos (pinch) e dê
zoom! É um gesto básico de dispositivos touch e
conhecido por todo mundo. Mas, mesmo assim,
muitos sites bloqueiam o zoom nas páginas. Não
faça isso.
<meta name="viewport" content="width=device-
width, user-scalable=no”>
<meta name="viewport" content="width=device-
width, minimum-scale=1, maximum-scale=1">

29. A funcionalidade
mobile mais
importante
A mais importante funcionalidade do
seu site para um usuário mobile é
performance.

30. Performance
 Em mobile, é absolutamente essencial. E apesar
das limitações de hardware e rede dos
aparelhos, 71% dos usuários esperam que um site
abra tão rápido no celular quanto no Desktop.
Um site mobile não otimizado simplesmente não
será usado.

31. Performance
 O Yahoo! descobriu que, para cada 400ms de
melhora na performance, seu tráfego aumenta
em 9% (fonte).
 Ao cortar 2,2s da landing page do Firefox, a
Mozilla aumentou o número de downloads em
15%, totalizando um ganho de mais de 60
milhões de cópias por ano.
 A Amazon concluiu que apenas 100ms de
melhora aumentam 1% seu faturamento.

32. Performance
 A Microsoft mostrou que 2s a mais de latência no
Bing diminuíam o faturamento em 4,3%.
 Em um de seus vários experimentos, o Google
aumentou o número de resultados por página
de 10 para 30. Isso aumentou o tempo de
carregamento de 0.4s para 0.9s, o que diminuiu
em 20% o tráfego das buscas.
http://blog.caelum.com.br/por-uma-
web-mais-rapida-26-tecnicas-de-
otimizacao-de-sites/

33. Performance
 1 – Habilite GZIP
 2 – Minifique JavaScript
 3 – Minifique CSS
 4 – Comprima o HTML
 5 – Não redimensione imagens no HTML
 6 – Otimize as imagens
 7 – Pense no formato das imagens
 8 – Diminua cookies e headers
 9 – Junte arquivos JavaScript
 10 – Juntar arquivos CSS
 11 – Use Sprites
 12 – Use Data URIs
 13 – Configure os headers
 14 – Tire firulas do design
 15 – Especifique o tamanho das imagens
 16 – Coloque o JavaScript no fim
 17 – Coloque o CSS no topo
 18/ 19 – Adie o carregamento do que puder e Abuse do
carregamento assíncrono
 20 – Otimize o First-View e o Above the Fold Time
 21 – Design performático
 22 – Automatize
 23 – Use ferramentas de diagnóstico
 24 – Pré-carregue componentes
 25 – Escreva código eficiente
 26 – Dispare logo o onload

34. Performance
Passe longe do jQuery em sites mobile.
São 32 KB de dados gzipados para se transferir numa
rede potencialmente ruim como 3G. E quando os
dados chegam, ocupam 95 KB sem gzip (mesmo
minificado). E tudo isso tem que ser lido e parseado
antes mesmo de se pensar em executar seu código.
As estatísticas de carregamento do jQuery em
dispositivos móveis são assustadoras. Num iPad 2 topo
de linha, só o parsing e eval do jQuery demora 5x mais
que no Desktop. Um iPhone 3, que, apesar de antigo,
é melhor que a maioria dos celulares que as pessoas
têm em seu bolso, demora incríveis 850ms. E mesmo
um iPhone 4 gasta uma eternidade se comparado ao
Desktop – 320ms vs. 35ms.

35. Performance
O cache do iPhone, por exemplo, não guarda
nenhum componente acima de 15 KB, e isso sem
gzip (fonte). O Zepto.JS tem 24 KB na sua versão
atual já minificada (o jQuery tem 95 KB). Se der,
prefira JavaScript puro e talvez alguns
microframeworks pra complementar – o excelente
hammer.js, por exemplo, adiciona eventos touch
por apenas 5 KB (2KB gzipped).

36. Performance
Os widgets de redes sociais como Facebook,
Twitter e Google+ então são atrocidades mobile.
Já são lentos no Desktop e trazem problemas sérios
de indisponibilidade se não carregados
assincronamente. No celular? São suicídio. Mas o
legal é que a maioria da plataformas móveis já
vem com recurso de Compartilhar embutido.
Tanto no iOS quanto no Android você pode
compartilhar uma página no Facebook ou Twitter
direto do navegador sem nenhum widget.

37. Performance
 Não use display: none pra esconder conteúdo
no celular. Ele será carregado mesmo assim.
(uma imagem, ou anúncio)
 Uma ideia melhor é fazer carregamento
condicional de conteúdo via Ajax por exemplo.
Usando Mobile First, você pode fazer seu HTML
inicial apenas com o conteúdo usado por todos
os devices. E se houver mais conteúdo para telas
maiores, por exemplo, carregue via Ajax
posteriormente.

38. Recomendações de Follow
 Sérgio Lopes - @sergio_caelum
 Tárcio Zemel - @tarciozemel
 Bernard de Luna – @bernarddeluna
 Zeno Rocha - @zenorocha
 Horácio Soares - @horaciosoares

39. Fontes
 Sergio Lopes - http://sergiolopes.org/palestra-mobile-web/#slide-capa
 Ethan Marcotte - http://www.abookapart.com/products/responsive-web-design
 Luke Wroblewski - http://www.abookapart.com/products/mobile-first
 Smashing Magazine - http://www.smashingmagazine.com/
 Brad Frost - http://bradfrostweb.com/
 Steve Souders - http://www.stevesouders.com/blog/
 Brendan Eich – http://brendaneich.com
 Paul Kinlan – http://paul.kinlan.me/
 Arquitetura de Informacao - http://arquiteturadeinformacao.com/2012/07/22/5-coisas-que-
aprendi-em-um-projeto-mobile-first-responsive-design-para-o-google/
 Mobile book - Smash Magazine - https://shop.smashingmagazine.com/the-mobile-book-deluxe-
bundle.html

40. Obrigado.