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.
2. Jackson F. de A. Mafra
http://about.me/jacksonfdam
https://bitbucket.org/jacksonfdam
https://github.com/jacksonfdam
http://linkedin.com/in/jacksonfdam
@jacksonfdam
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.
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
14.
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
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">
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
Design Responsivo x AdaptativoUma versãoqueflui de acordo com o deviceUma versãoespecificaparacada device (desktop, tablet, smartphone)http://www.templatemonster.com/infographics/responsive-web-design-interactive-guide.phpCOMO O DESIGN RESPONSIVO É VISTO PELOS BUSCADORESO design responsivo já é defendida por muitos já faz algum tempo, mas só recentemente começou a ganhar destaque depois que o Google confirmou indiretamente que para a área de SEO (otimização para buscadores) o design responsivo é o mais indicado. É mais fácil para o Google perceber que o www.exemplodesite.com.br tem um layout que se adapta a qualquer tela do que entender que o www.outroexemplo.com.br, o m.outroexemplo.com.br e o tablet.outroexemplo.com.br são todos o mesmo sites e não estão apenas copiando conteúdo um do outro."Google recomenda que os webmasters sigam a melhor prática da indústria usando design responsivos, oferecendo o mesmo código HTML para todos os dispositivos e usando apenas media queries de CSS para decidir como a informação deve ser renderizada."
A List ApartUso das CSS Media Queries em 2010RWD – Responsive Web Design
Uso de Grids
Nãoadiantaredimensionar a imagem, se ela continua com mais de 5mb e o usuárioestana 3G/2G.Video – Responsivo.Uso do http://adaptive-images.com/Add .htaccess and adaptive-images.php to your document-root folder.Add one line of JavaScript into the <head> of your site.Add your CSS Media Query values into $resolutions in the PHP file.OUhttp://wil.to/picturefill/Uso da tag <picture> com polyfill baseado nos elementos source usando os atributos media e srcset.
Uso de Media Queries érecomendacaodesde 19 de junho de 2012 - http://www.w3.org/TR/css3-mediaqueries/http://responsive.is/typecast.comÉ preciso escolher os melhores breakpoints“Breakpoints” são as larguras de tela (em pixels) onde o site começa a se transformar e adicionar conteúdo extra dependendo do dispositivo onde você está navegando. Por exemplo: a partir dos 410px de largura, entendemos que o usuário não está mais navegando em um smartphone no modo “retrato”, e sim no modo “paisagem”. E então servimos a ele um conteúdo e uma interface específica para aquele tipo de navegação.MobileMobile LandscapeTabletTablet LandscapeDesktop
Sóusar media-queries e trocar tudopraporcentagem no cssnãovaifazer a aplicaçãoserresponsivaouter a melhorexperienciapara o usuário.Existemvarios outros desafios. O queimportaé o conteúdo. Fazer um car sort, com usuarios e designers e ver o queéimportante, o quedeveaparecerounão.Analisar a persona, qual o goal de cada um.
Dedo é diferente de mouseNo celular, não existe o estado hover, tão comum no Desktop. Você não tem como passar o dedo em cima de algo sem causar um clique.
http://sergiolopes.org/media-queries-retina/0.75dppx (= 72dpi) - Androidlow-end, tipo Galaxy 5.1dppx (= 96dpi) - Notebooks, desktops e vários celulares e tablets.1.33dppx (= 127dpi) - Nexus 7.1.5dppx (= 144dpi) - Vários Androids, como Atrix ou S2.2dppx (= 192dpi) - Telas retina da Apple, celulares e tablets mais modernos como S3.3dppx (= 288dpi) - Celulares ultra modernos, como Droid DNA e Galaxy S4.
xhdpi (extra high dpi) - pixel ratio 2 - ex. Galaxy S3, Galaxy Note 2, Nexus 4.hdpi (high dpi) - pixel ratio 1.5 - ex. Galaxy S2, Motorola Atrix, NexusOne.tvdpi - pixel ratio 1.33 - usado só no tabletNexus 7.mdpi (mediumdpi) - pixel ratio 1 - telas normais, comuns em smartphones simples.ldpi (lowdpi) - pixel ratio 0.75 - aparelhos low-end como o Galaxy 5.dpi altíssimo (ainda sem nome) - pixel ratio 3 - aparelhos Full HD com tela 1920x1080 como o HTC Droid DNA e o Galaxy S4.O viewport é o quanto de conteúdo cabe na tela, em CSS pixels, não device pixels. Todos os iPhones mostram 320px de conteúdo, não importando se é retina (com 640px físicos) ou não. Precisa ser assim, pois os pixels físicos são muito pequenos na tela retina. Seria péssimo pro usuário mostrar 640px de conteúdo, tudo ficaria muito pequeno.No fim, pra usabilidade, conta mais o tamanho do viewport que o tamanho físico da tela.Quando lemos comparativos sobre aparelhos, é comum ver as pessoas citando DPIs físicos. Por exemplo:iPhone não-retina tem 163 dpi com largura de 320pxiPhone retina tem 326 dpi com largura de 640pxGalaxyS tem 233 dpi com largura de 480pxGalaxyY tem só 133 dpi com largura de 240pxOlhando novamente pra lista de aparelhos vemos que todos têm a mesma largura de viewport e a variação na densidade de CSS pixels é bem menor:iPhone não-retina tem 163 dpi de conteúdo com viewport de 320px de larguraiPhone retina tem 163 dpi de conteúdo com viewport de 320px de larguraGalaxyS tem 155 dpi de conteúdo com viewport de 320px de larguraGalaxyY tem 177 dpi de conteúdo com viewport de 320px de largura
Nem só de jQuery é feito o mundo dos frameworks JavaScript. Há vários inclusive focados em mobile! O famoso jQuery Mobile é um plugin cheio de componentes para mobile, com temas interessantes e muitas funções. Há ainda o jqTouch e o fantástico SenchaTouch.Não use nenhum deles se você vai fazer um site mobile. O SenchaTouch, outro poderoso framework JavaScript com foco mobile, atinge inacreditáveis 580 KB em sua versão completa, e o jQuery Mobile, incríveis 91 KB, além dos 95 KB do jQuery em si. Esses frameworks de componentes são indicados para mobile apps construídas na Web, em especial se você for empacotá-las, usando algo como o PhoneGap. Pra sites, são um tiro no pé. Obviamente eles podem melhorar muito em próximas releases, mas há muito a ser enxugado para serem candidatos a um site web mobile.