Aplicacoes responsivas

891 visualizações

Publicada em

Palestra sobre Aplicações Responsivas, para o 15 Encontro Locaweb em Porto Alegre.

Você nao deve pensar so no fron-end mas em todo o conjunto do projeto.
E isso se aplica a Mobile em geral, Aplicações nativas ou web.

Publicada em: Tecnologia
  • Seja o primeiro a comentar

Aplicacoes responsivas

  1. 1. Aplicações ResponsivasJackson F. de A. Mafra
  2. 2. Jackson F. de A. Mafrahttp://about.me/jacksonfdamhttps://bitbucket.org/jacksonfdamhttps://github.com/jacksonfdamhttp://linkedin.com/in/jacksonfdam@jacksonfdam
  3. 3. AplicaçõesResponsivas
  4. 4. ArquiteturaResponsivaO termo Arquitetura responsiva foidado pelo pesquisador NicholasNegroponte que inicialmenteconcebeu nos anos 1960 durante odesign de espaços onde foramexplorados os conceito decibernética para a arquitetura.http://en.wikipedia.org/wiki/File:NNegoponte_USNA_20090415_.jpg
  5. 5. Arquitetura responsiva é aquela que as condiçõesdo espaço e ambientes podem mudar e seadaptar a condições pre-definidas ou desejáveis ,por meio de sensores, alterando as característicasde forma, cores, espaços e todos os elementosque compõem o espaço arquitetônico de modoresponsivo. Para tal são utilizados sensores eatuadores robóticos.
  6. 6. WebdesignResponsivoO termo utilizado para definir um webdesing responsivo foi criado por EthanMarcotte, em seu artigo no site A list apart.Marcotte consolidou três principaistécnicas para este modelo: Layout fluído,Imagens flexíveis, e Consultas a mídias(Media queries) em uma abordagemunificada, que o nomeou de web designágil.http://www.flickr.com/photos/zeldman/6495074887/http://www.alistapart.com/articles/responsive-web-design/
  7. 7. Layout fluídoA técnica de layout fluído se baseia em usarvalores percentuais ao invés de absolutos para astags que delimitam as áreas do site (div), ou seja,ao invés de declarar a largura do site com valoresabsolutos em pixels (px), usamos valoresproporcionais em percentual (%). Desta forma osite e suas subpartes ocuparão uma área relativaao tamanho da janela do navegador do usuário.Larguras em "%". Textosem "em".
  8. 8. Imagens flexíveisTão importante quanto um layout que respondaaos diversos tamanhos de tela. As imagenstambém devem adaptar-se ao tamanho de telado device em que está sendo acessado, utilizandovalores proporcionais em percentual (%).
  9. 9. Media queriesSão seletores em CSS3 que consulta as mídias donavegador quando o seu site for acessado. Comas Medias Queries configuradas, o navegadorexibe o layout de acordo com o dispositivo queestá acessando o site, ou seja, o navegadorinterpreta o tamanho de tela que foi configuradona media querie e exibe o layout que foi definidono CSS.
  10. 10. Case: skinnytieshttp://skinnyties.com/
  11. 11. “Não importa odispositivo e simo usuário final”Horácio Soares
  12. 12. Redimencionarnão é tudo.
  13. 13. Mobilize, don’tminiaturizeMiniaturizing “treats the mobile environment andtechnology as asubset of the desktop environment.”Miniaturizar "trata o ambiente mobile e a tecnologia comoum subconjunto do ambiente de desktop. "Barbara Ballard UX Designer, 2007
  14. 14. PrototiparPapel e Lapis são ótimos e baratos.01 A4 – Paisagem = Desktop01 A4 dobrado ao meio / 02 A5 = 02 Telas deiPad01 A5 dobrado 03 vezes = 03 Telas de iPhone
  15. 15. MockupsFerramentas Balsamiq,mokk.me,mockupbuilder,proto.io
  16. 16. FrameworksTwitter BoostrapFoundation
  17. 17. http://alistapart.com/article/dive-into-responsive-prototyping-with-foundation
  18. 18. Dividir as telasem modulosGrid,texto,menu, tabelas
  19. 19. Grids
  20. 20. TextosNão usar textos com tamanho em px pelaaplicacao, use no body e os demais em em
  21. 21. MenuMelhor disposição para a navegação.Sidebar Nav, Dropdown, Select Menu, PullDown
  22. 22. TabelaAjustar os dados, ocultar colunas.
  23. 23. Don’t shrink,rethinkJeff Hawkins (Fundador da Palm) em 1998
  24. 24. ZoomUm zoom de 200%, na prática, faz 1pxno CSS ser renderizado como 2px natela. No fim, se você estiver em umnotebook de 1280px de tela, a páginapassaria a renderizar com umviewport de 640px.
  25. 25. ZoomTodos os navegadores suportam esse tipo derecurso: Firefox, Chrome, Android, Opera, InternetExplorer e Safari. Só há um bug no Webkit –Chrome, Safari, Android – que faz a media queryser aplicada apenas se o usuário der zoom edepois um refresh na página; em todos os outros, amedia query é aplicada imediatamente deacordo com o zoom.
  26. 26. Zoom O zoom dos navegadores modernos aumenta apágina toda – texto, imagens, CSS etc. Nosnavegadores antigos – como IE6 ou IE7 –, nãoexistia isso e era comum o usuário aumentar otamanho da fonte. Era bem mais simples: só ofont-size base mudava e a página só aumentariase você usasse em nas medidas CSS. Aliás, esse era um argumento forte a favor deem na época, mas hoje em dia os browsers dãozoom inclusive em medidas com px fixos.
  27. 27. Zoom As telas pequenas dos smartphones ensinaramalgo simples para os usuários: se algo estiverpequeno, apenas arraste os dedos (pinch) e dêzoom! É um gesto básico de dispositivos touch econhecido por todo mundo. Mas, mesmo assim,muitos sites bloqueiam o zoom nas páginas. Nãofaç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">
  28. 28. A funcionalidademobile maisimportanteA mais importante funcionalidade doseu site para um usuário mobile éperformance.
  29. 29. Performance Em mobile, é absolutamente essencial. E apesardas limitações de hardware e rede dosaparelhos, 71% dos usuários esperam que um siteabra tão rápido no celular quanto no Desktop.Um site mobile não otimizado simplesmente nãoserá usado.
  30. 30. Performance O Yahoo! descobriu que, para cada 400ms demelhora na performance, seu tráfego aumentaem 9% (fonte). Ao cortar 2,2s da landing page do Firefox, aMozilla aumentou o número de downloads em15%, totalizando um ganho de mais de 60milhões de cópias por ano. A Amazon concluiu que apenas 100ms demelhora aumentam 1% seu faturamento.
  31. 31. Performance A Microsoft mostrou que 2s a mais de latência noBing diminuíam o faturamento em 4,3%. Em um de seus vários experimentos, o Googleaumentou o número de resultados por páginade 10 para 30. Isso aumentou o tempo decarregamento de 0.4s para 0.9s, o que diminuiuem 20% o tráfego das buscas.http://blog.caelum.com.br/por-uma-web-mais-rapida-26-tecnicas-de-otimizacao-de-sites/
  32. 32. 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 docarregamento 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
  33. 33. PerformancePasse longe do jQuery em sites mobile.São 32 KB de dados gzipados para se transferir numarede potencialmente ruim como 3G. E quando osdados chegam, ocupam 95 KB sem gzip (mesmominificado). E tudo isso tem que ser lido e parseadoantes mesmo de se pensar em executar seu código.As estatísticas de carregamento do jQuery emdispositivos móveis são assustadoras. Num iPad 2 topode linha, só o parsing e eval do jQuery demora 5x maisque no Desktop. Um iPhone 3, que, apesar de antigo,é melhor que a maioria dos celulares que as pessoastêm em seu bolso, demora incríveis 850ms. E mesmoum iPhone 4 gasta uma eternidade se comparado aoDesktop – 320ms vs. 35ms.
  34. 34. PerformanceO cache do iPhone, por exemplo, não guardanenhum componente acima de 15 KB, e isso semgzip (fonte). O Zepto.JS tem 24 KB na sua versãoatual já minificada (o jQuery tem 95 KB). Se der,prefira JavaScript puro e talvez algunsmicroframeworks pra complementar – o excelentehammer.js, por exemplo, adiciona eventos touchpor apenas 5 KB (2KB gzipped).
  35. 35. PerformanceOs 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ériosde indisponibilidade se não carregadosassincronamente. No celular? São suicídio. Mas olegal é que a maioria da plataformas móveis jávem com recurso de Compartilhar embutido.Tanto no iOS quanto no Android você podecompartilhar uma página no Facebook ou Twitterdireto do navegador sem nenhum widget.
  36. 36. Performance Não use display: none pra esconder conteúdono celular. Ele será carregado mesmo assim.(uma imagem, ou anúncio) Uma ideia melhor é fazer carregamentocondicional de conteúdo via Ajax por exemplo.Usando Mobile First, você pode fazer seu HTMLinicial apenas com o conteúdo usado por todosos devices. E se houver mais conteúdo para telasmaiores, por exemplo, carregue via Ajaxposteriormente.
  37. 37. Recomendações de Follow Sérgio Lopes - @sergio_caelum Tárcio Zemel - @tarciozemel Bernard de Luna – @bernarddeluna Zeno Rocha - @zenorocha Horácio Soares - @horaciosoares
  38. 38. 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
  39. 39. Obrigado.

×