sergiolopes.org

Hipsters.tech #144: Tendências em Tecnologia pra 2020

2019-04-16T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Hipsters.tech #114: Performance e Otimizações na Web

2018-09-18T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Hipsters.tech #104: As Super Apps: o caso da Rapiddo

2018-07-10T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Hipsters.tech #100: Por trás do Hipsters: Caelum, Alura e Casa do Código

2018-06-12T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Hipsters.tech #98: Fake News

2018-05-29T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Nerdtech #26: Breve história da Apple

2018-04-06T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

PHP Experience: Performance Web, Criptomoedas e mais – Hipsters On The Road #01

2018-03-20T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Hipsters.tech #78: Ember

2018-01-09T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Hipsters.tech #77: Tendências para 2018

2018-01-02T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Hipsters.tech #72: Wordpress

2017-11-28T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Nerdtech #21: Software Livre

2017-11-03T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Nerdtech #20: Tecnologias Mortas

2017-10-06T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Hipsters.tech #60: Startups, E-commerce e Deploys

2017-09-05T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Hipsters.tech #58: Evolução e Especificação do JavaScript Moderno

2017-08-22T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Hipsters.tech #56: Ionic

2017-08-08T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Progressive Web Apps: a palavra-chave é Web, não App

2017-04-24T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Revisitando práticas de performance front-end depois do HTTP/2

2017-04-10T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Sprites ou imagens separadas?

2017-04-10T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Nerdtech #14: Filmes com programadores

2017-04-07T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Hipsters.tech #38: O reino encantado do JavaScript

2017-04-04T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Como é trabalhar no Grupo Caelum

2017-04-03T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Performance é UX

2017-03-29T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Quais impactos de performance ao usar serviços externos de fontes?

2017-03-27T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Como estimar a janela inicial de uma nova conexão TCP com Wireshark?

2017-03-14T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Nerdtech #13: Os navegadores da Internet

2017-03-03T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Hipsters.tech #31: Carreira em tecnologia

2017-02-14T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Hipsters.tech #25: Startups, música e Educação

2017-01-03T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Hipsters.tech #21: Acessibilidade na Web

2016-12-06T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Nerdtech #10: Page Rank e SEO

2016-12-02T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Hipsters.tech #13: HTTP/2, magia com o novo protocolo

2016-11-10T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Hipsters.tech #16: Single Page Applications

2016-11-01T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Por que você deve ficar sempre de olho na performance do seu site

2016-09-29T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Hipsters.tech #09: CSS, cansei de ser simples

2016-09-13T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Hipsters.tech #06: Web Components

2016-08-23T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Nerdtech #6: Ecossistema Mobile

2016-08-05T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Hipsters.tech #03: Progressive Web Apps

2016-08-02T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Nerdtech #4: Plataformas e Arquitetura de Sistemas

2016-06-03T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

HTTP/2 Server Push na prática

2016-04-25T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Performance Web no mundo real: porque o site do Alura voa

2016-03-07T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Nerdtech #3: Velocidade, performance e otimização

2016-03-04T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Nerdtech #1: Os buracos da tecnologia

2016-03-04T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

A arquitetura do novo site do Alura

2016-03-03T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

O site do Alura está de cara nova

2016-03-01T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Touch-first: como otimizar seu design responsivo para o mundo das touch screens

2015-11-03T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Vídeo – Progressive Web Apps #7Masters

2015-10-29T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Quem disse que eu preciso de jQuery?

2015-10-21T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Use Geolocation API do HTML5 e OpenStreetMaps para um formulário mais amigável

2015-07-11T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Porque você não deveria ligar para o tempo do onload (ou: as métricas que importam para performance real na Web)

2015-07-07T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Browser-sync, indispensável para desenvolver sites em vários dispositivos

2015-06-17T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Segunda edição do meu livro “A Web Mobile”, revista e ampliada

2015-05-27T00:00:00.000Z

Dois anos depois da publicação de "A Web Mobile", chegou a hora de uma revisão. Curioso que imaginei que precisaria atualizar muita coisa que já estaria velha. E não foi o caso. A maior parte do livro continua se aplicando agora em 2015 como se aplicava em 2013.

Tivemos novidades, claro. Como o lançamento do Microsoft Edge. Novos dispositivos. Até sites abrindo em smartwatches agora. Mas os pilares, os conceitos fundamentais da Web mobile continuam os mesmos. Falo sobre design responsivo, media queries, telas retina, touch screens, mobile-first, RESS e muito mais. Se você me acompanha aqui no blog, certamente vai gostar do livro.

Você pode ver lista completa de tópicos. Nesta segunda edição, as grandes novidades são:

Novos capítulos sobre imagens responsivas. Em especial sobre os novos <picture> e srcset. Mudei algumas recomendações de antes também. Recomendo.
Há também um novo capítulo sobre ::Coreografia de Conteúdo:: para sites responsivos, bem interessante.
Outras mudanças mais pontuais incluem seções sobre viewport units, negação de media queries, sobre o famoso atraso de 300ms no onclick em touch screen, explicações sobre novos dispositivos, atualização de screenshots, correção de bugs, novos exemplos e outros detalhes.

O livro custa R$ 29 em ebook, R$ 59 na versão impressa e R$ 69 ebook + impresso. Você pode comprar direto no site da editora Casa do Código. Se você comprou a 1ª edição digital, vai receber o update gratuito para 2ª edição.

Conteúdo original do blog sergiolopes.org.

Porque usar ‘em’ no seu CSS hoje em dia?

2014-09-30T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Entrevista no 'Setup' do Loopinfinito

2014-09-18T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Como negar uma media query

2014-08-27T00:00:00.000Z

Nessa altura do campeonato, todo mundo já escreveu alguma media query na vida. A sintaxe parece simples. Taca um @media (min-width: 600px) lá e pronto. Mas alguns desafios começam a surgir no dia a dia. Um interessante é como negar uma media query, escrever seu inverso.

Pegue essa media query mesmo: @media (min-width: 600px). Ela seleciona telas com largura maior ou igual a 600 pixels. Simples. Agora quero escrever o inverso disso. Parece simples certo?

A primeira tentativa pode ser um @media (max-width: 600px). Faz sentido até. Mas aí lembramos que as media queries consideram seu valor inclusive. Isso quer dizer que quando a tela for exatamente 600px, ambas as media queries vão ser verdadeiras. Não é o que queremos.

Podemos pensar então em um ajuste e chegar a @media (max-width: 599px). Isso pega telas até 599 pixels inclusive. E a outra pegava de 600 pixels pra cima, inclusive. Pronto. Será? Não.

Isso só funcionaria se você imaginar que não existe valor entre 599 e 600, o que pode fazer sentido pensando em pixels físicos na tela (ou não, hoje temos subpixels). Mas o px no CSS é uma medida relativa diferente de um pixel físico - a gente chama de CSS pixel. E muita coisa afeta o tamanho de um CSS pixel, como por exemplo o zoom do usuário. Outro fator são as telas retina e seus device pixel ratios.

Resumindo: muita água pode rolar entre 599px e 600px na Web de hoje em dia. De volta a prancheta.

Lembramos então que as media queries têm uma keyword not. Parece fácil. Tentamos um @media not (min-width: 600px) e... bam, não funciona. Sintaxe inválida. Mas a ideia é essa mesmo, usar o not. A sintaxe final fica:

@media not all and (min-width: 600px) {}

/* negativa de @media (min-width: 600px){} */

Aqui é importante ressaltar o funcionamento do not. Ele nega a expressão inteira, por isso usei o all and. É como falar not(all and (min-width:600px)). O all é verdadeiro sempre então a lógica acaba ficando equivalente a not(min-width:600px), justo o que queríamos.

Conteúdo original do blog sergiolopes.org.

Meu novo Workshop Web Design Responsivo na Caelum

2014-07-07T00:00:00.000Z

Está querendo começar em design responsivo e não sabe por onde? Ou conhece algum amigo nesse estágio? Meu novo workshop de web design responsivo é pra você. É um dia inteiro com diversos temas de design responsivo na prática, com muitas dicas e conhecimento. Além, claro, de poder tirar suas dúvidas e discutir em aula comigo.

O workshop é vendido e mantido pela Caelum. Por enquanto, só temos a primeira turma marcada em São Paulo, dia 26/07. Mais turmas em breve também.

Escrever um site responsivo não é só pegar seu site desktop, colocar meia dúzia de media queries e ver ele redimensionar bonitinho no seu Chrome. Design responsivo é repensar a Web com flexibilidade e adaptabilidade em mente. No workshop, quero ir além das media queries básicas e mostrar como entregar uma experiência fantástica para o usuário.

Criei esse workshop depois de muito programar sites responsivos, de palestrar bastante sobre o tema, de lançar o livro A Web Mobile e dar muitas aulas. Percebi como existem muitos desafios e dúvidas, e muita gente fazendo coisas não tão recomendadas.

Um diferencial do workshop é poder tirar dúvidas comigo pessoalmente, levantar tópicos para discussão e ver o que outras pessoas também estão fazendo.

Os tópicos detalhados do workshop:

Design Responsivo
- Porque o design responsivo é o único caminho viável para a Web do futuro;
- Layout fluídos e a mágica por trás das medidas flexíveis da Web;
- Media queries para adaptação condicional;
- Uso do viewport e os conceitos por trás dele;
Técnicas de responsividade
- Boas práticas para media queries;
- Imagens e mídias flexíveis;
- Adaptação com código JavaScript;
Mobile-first
- Mobile-first, touch-first e web-first!
- Progressive enhancemente an Web moderna;
- Feature detection com Modernizr e JS;
- Umas palavrinhas sobre RESS;
Técnicas avançadas
- Como entender telas de alta resolução e retina
- Uso de imagens retina
- Como usar SVG, imagens vetoriais, CSS3 e icon fonts
- Conditional loading para conteúdo
- Algumas palavras sobre performance focado em mobile
- Debug e workflow de desenvolvimento de sites mobiles
Discussão de tópicos levantados pela turma.

Interessado? Veja o workshop de design responsivo no site da Caelum e faça sua reserva.

Conteúdo original do blog sergiolopes.org.

O que muda nas práticas de otimizações de performance na Web com o HTTP 2.0 e o SPDY

2014-06-18T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

As fantásticas novidades do HTTP 2.0 e do SPDY

2014-06-02T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Lançamento do livro “Coletânea Front-end: uma antologia da comunidade front-end brasileira.”

2014-04-01T00:00:00.000Z

Acabo de lançar pela editora Casa do Código mais um projeto: um livro que junta 10 autores de renome da comunidade front-end brasileira. É um projeto ambicioso que reuniu bastante trabalho nos últimos meses e acaba de sair. É a Coletânea Front-end.

Inspirado em iniciativas lá de fora (como o famoso Smashing Book), nossa coletânea conta com 10 capítulos de diversos assuntos. Eu fui o editor e organizador da coletânea.

O livro custa R$ 29 em ebook, R$ 59 na versão impressa e R$ 69 ebook + impresso. Você pode comprar direto no site da editora Casa do Código.

A lista de autores é simplesmente fantástica:

Almir Filho - Globo / Loopinfinito
Bernard De Luna - Videolog / Freteiros
Caio Gondim - Booking / Loopinfinito
Deivid Marques - Locaweb
Diego Eis - Tableless / Locaweb
Eduardo Shiota - Booking
Giovanni Keppelen - Planedia
Jaydson Gomes - Terra
Luiz Real - Caelum
Reinaldo Ferraz - W3C
Sérgio Lopes - Caelum

O resultado é um livro plural com assuntos bacanas escritos por pessoas de destaque na comunidade. Os capítulos da coletânea:

Progressive Enhancement: construindo um site melhor para todos?
Responsive, Adaptive e Fault Tolerance
Tudo que você precisa saber para criar um framework de sucesso
Tornando a web mais dinâmica com AngularJS
As diretrizes de acessibilidade para conteúdo na Web – WCAG
Aplicações web super acessíveis com WAI-ARIA
APIs geniais da Web moderna
As APIs de acesso a dispositivos do HTML5
Debugando sua Web App — ou, Como se estressar menos
Testando códigos JavaScript

O livro foi pensado para ser um marco para o mercado de front-end brasileiro. Há muito conteúdo e muito conhecimento nesses 10 capítulos. Compre o seu e nos mande o feedback.

Conteúdo original do blog sergiolopes.org.

Palestra: Repensando o front-end para telas de alta resolução

2013-11-19T00:00:00.000Z

Essa palestra é completamente interativa, o que não é suportado nos feeds RSS. Recomendo que visite o site e leia por lá. (é otimizado também para mobile)

Telas de alta resolução? Imagens responsivas? Retina? Gráficos vetoriais? SVG, icon fonts? Veja nessa palestra como suportar telas de resoluções diferentes.

Media queries também ajudam na acessibilidade

2013-08-28T00:00:00.000Z

Esse post foi atualizado recentemente com mais informações (data de publicação original: 29 Jan 2013).

Sempre que alguém fala em medias queries, a primeira coisa que vem à cabeça é design responsivo e mobile. Mas elas ajudam também em outro cenário: acessibilidade.

Aliás, é sempre bom lembrar que acessibilidade não é só sobre usuários cegos. Há várias categorias, incluindo os que enxergam mas com dificuldade de ler texto pequeno. Pode ser uma doença, pode ser uma pessoa mais idosa, ou até um usuário "comum" desconfortável com um texto pequeno.

Pra isso, os navegadores têm a capacidade de zoom nas páginas. Eu mesmo, apesar de não ter nenhum problema na vista, uso direto: gosto de ler textos com pelo menos 18px de tamanho, então dou zoom em todas as páginas menores que isso.

E, só pra ficar claro, estou falando do que chamamos de page zoom, que aumenta tudo na página, usado geralmente no Desktop; não estou falando do gesto de page scale, comum no celular, que não afeta a renderização da página, só a visualização do usuário.

Mas dar zoom na página tem um problema: se você aumentar muito, o design do site pode quebrar, principalmente medidas flexíveis como porcentagens e em, tão comuns em design responsivo.

Um zoom de 200% deixa o artigo do blog bem estranho. O texto fica grande mas apertado, e a foto fica grande demais sem necessidade.

A parte mais curiosa é que o inimigo desse layout estranho é justo o design flexível. Se tivesse feito o layout todo fixo em px, o zoom iria aumentá-lo proporcionalmente e nada quebraria. O ruim só é que o usuário teria que dar scroll horizontal pra ver o site todo.

Media queries ajudam no zoom

Mas a grande sacada é que as media queries são aplicadas quando o usuário dá 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. (aliás, há muita semelhança disso com meu post sobre resoluções, pixel ratio e telas retina.)

E a vantagem do viewport mudar de tamanho de acordo com o zoom é que as media queries são aplicadas de acordo com o viewport. Com isso, as suas media queries criadas originalmente para celulares e tablets começam a ser aplicadas para o usuário com zoom. Seu layout passa a se adaptar corretamente sem problema algum.

Media queries ajustam o layout no Desktop com zoom de 200% como se estivesse num tablet pequeno. O design fica grande mas bem mais harmônico e proporcional.

Todos os navegadores suportam esse tipo de recurso: Firefox, Chrome, Android, Opera, Internet Explorer e Safari. Só há um bug no WebKit -- 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 (incluindo Chrome com Blink), a media query é aplicada imediatamente de acordo com o zoom.

Então, se você por acaso não gosta de design responsivo e ainda faz site Desktop e mobile separado, tá aí um motivo pra usar media queries mesmo assim: garantir acesso de pessoas com visão reduzida.

Use media queries com 'em' por causa do WebKit

Aliás, falando em WebKit, há outra questão importante. Quando o zoom aumenta, o cálculo dos pixels não afeta as media queries. Isso quer dizer que, se você usou (max-width: 960px) no CSS, o WebKit não irá considerar metade desse valor quando o zoom estiver em 200%. Ele deveria fazer isso -- como todo os outros browsers fazem --, já que a media query é sobre o tamanho do viewport e não o tamanho da janela.

Mas o WebKit consegue reaplicar as media queries no zoom corretamente sim, apenas precisamos declará-las com em:

@media (max-width: 44em) { ... } /* equivalente a 704px */
@media (max-width: 37em) { ... } /* equivalente a 592px */

A conta é simples: é só usar como base o font-size em 16px e você chega no valor em em. Os browsers WebKit consideram que o font-size base muda conforme o zoom o que faz sua media query ser aplicada (depois de um refresh, por causa do bug que falei antes). Importante: o Chrome não sofre mais desse problema desde que mudou para o Blink.

E não se engane: isso é um bug do Safari/Android e cia. Usar media queries em em não deveria ser necessário para ganharmos acessibilidade no zoom. Até o IE funciona direito! Mas, com o WebKit dominando completamente o mundo mobile, é bom fazer sempre suas media queries em em pra evitar problemas. Pelo menos até corrigirem esse bug.

Media queries de resolução aplicadas no zoom

Uma desvantagem pra quem usa o zoom do browser é que as imagens costumam ficar pixeladas. Ela fica menos definida, o que deixa a página feia e até com imagens piores pro deficiente visual entender.

Mas, você lembra que temos media queries para lidar com resoluções diferentes? Elas foram pensadas para serem aplicadas em aparelhos com pixel ratio diferentes (como celulares Retina), mas também servem pra acessibilidade.

Após um longo debate no W3C, todos os navegadores concordaram que alterar o zoom do navegador altera o devicePixelRatio e, portanto, altera a forma como as media querie resolution são avaliadas.

Em outras palavras: se você serve uma imagem de alta resolução (2x) para telas retina, por exemplo, ela será usada quando o usuário der 200% de zoom na página. Excelente.

Por enquanto, em Agosto/2013, apenas o Firefox e o Chrome implementaram isso corretamente. Mas é questão de tempo até os outros navegadores implementarem.

Uma nota sobre a falta de acessibilidade do iOS

O Safari Mobile no iOS não permite mudar o zoom padrão do navegador e ter uma página ajustável como mostrei nesse post. A única opção do usuário é usar o gesto de page scale com dois dedos no navegador (pinch to zoom) e ficar arrastando a tela de um lado pro outro pra conseguir ver a página toda.

E, claro, isso se o desenvolvedor do site não desabilitou o zoom -- coisa que você jamais deveria fazer. Nesse caso, a solução pro usuário é usar o recurso de zoom nativo do sistema, que envolve uma série de gestos estranhos e difíceis com 2 e 3 dedos.

Outra nota, sobre zoom vs aumentar a fonte

Nesse post, falo do zoom dos navegadores modernos, que 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.

* Imagem que ilustra o post por @m4tik no Flickr.

Atualização Ago/2013: informações sobre correções dos bugs no Chrome e WebKit.

Conteúdo original do blog sergiolopes.org.

Script para debugar o Mobile Safari do iOS no Desktop

2013-08-26T00:00:00.000Z

Esse post foi atualizado recentemente com mais informações (data de publicação original: 20 Mar 2012).

A partir do iOS 5, é possível fazer remote debug de qualquer aba aberta no Mobile Safari, através do famoso Inspector do WebKit no Desktop enquanto se navega no celular/emulador.

Se você tiver iOS 6 em diante, o processo é extremamente simples, bastando ter o Safari mais recente instalado no Mac. Antes, você precisa habilitar essa função no seu aparelho (ou no emulador). Vá em Ajustes > Safari > Avançado e marque a opção Inspetor Web:

Como habilitar o debug remoto no iOS 6

Agora abra o Safari no Mac e vá nas Preferências > Avançado e marque a opção para mostrar o menu Develop no menu. Por fim, basta conectar o cabo USB no aparelho e no computador (ou só abrir o emulador). Para abrir o inspetor, vá no Safari do Desktop em Develop e deve aparecer seu aparelho/emulador listado, dando acesso a todas as abas abertas.

Debugando meu blog no emulador do iOS pelo Safari do Mac

(tenho também um post sobre debug remoto no Chrome Mobile do Android)

iOS 5

No iOS 5, o debug já existe mas é um pouco mais complicado, exigindo comandos mais complexos.

Criei então um script bash que abre o emulador do iOS 5 e conecta o debugger nele via Safari. É bastante útil pra desenvolvimento Web mobile. Basta rodar o script no Mac após ter instalado o XCode mais novo que inclui o emulador do iOS 5.

Após rodar no terminal, abra o Mobile Safari dentro do emulador e navegue até a página que quer debugar. Depois, volte ao terminal e dê enter para o script continuar e capturar o debug. Ele vai abrir o Safari no seu Desktop com o Web Inspector.

#!/bin/bash

# Open iPhone Simulator on default location for XCode 4.3
open /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/Applications/iPhone\ Simulator.app

# Open mobile safari
echo Open mobile safari on emulator and press return
read

# Plug debug to MobileSafari.app
echo Debugging
MobileSafari_PID=$(ps x | grep "MobileSafari" | grep -v grep | awk '{ print $1 }')

if [ "$MobileSafari_PID" == "" ]; then
  echo "Mobile Safari.app must be running in the Simulator to enable the remote inspector."
  exit
else

  cat <<EOM | gdb -quiet > /dev/null
  attach $MobileSafari_PID
  p (void *)[WebView _enableRemoteInspector]
  detach
EOM
fi

# Open debugger in Safari.app
open -a /Applications/Safari.app http://localhost:9999

Debugando o sergiolopes.org no Mobile Safari do emulador

Há também um gist disponível com esse código. O código do gdb eu peguei nesse post aqui -- lá você também vê como conectar o debug a um aparelho real com iOS, além do emulador.

Se você precisa debugar uma versão mais antiga do iOS ou não tem um Mac a disposição, recomendo testar as ferramentas Adobe Edge Inspect e Weinre.

Atualização Ago/2013: Adicionei informações sobre iOS 6.

Conteúdo original do blog sergiolopes.org.

CSS: Você deveria usar box-sizing: border-box em todas as suas páginas

2013-08-23T00:00:00.000Z

Se você estiver num leitor RSS, é possível que os exemplos não funcionem adequadamente por causa do CSS. Recomendo ver o <a href="http://sergiolopes.org/css-box-sizing-border-box/">artigo original</a> no site. (é otimizado pra mobile também)

Esse post foi atualizado recentemente com mais informações (data de publicação original: 24 Jun 2012).

O box model padrão do CSS é uma das coisas mais contra-intuitivas que existem. Mas você pode trocá-lo com o box-sizing do CSS3. E, melhor, funciona em todos os navegadores -- até no IE8!

Todo elemento no HTML é uma caixa. Controlamos seu tamanho com width, sua borda com border e ainda temos as margens externas e internas com margin e padding. Box model é como todas essas propriedades se relacionam pra determinar o tamanho final do elemento.

E o box model tradicional da especificação tem uma regra bastante confusa: diz que a propriedade width trata do tamanho do conteúdo do elemento, não considerando seu padding e border (e a mesma coisa com a altura).

Isso quer dizer que, se você quiser que um elemento ocupe metade da página mas com uma borda de 10px, não funciona fazer border: 10px solid #555; width:50%. O tamanho final do elemento terá 20px mais metade do tamanho do pai.

Queria que ele ocupasse metade da tela com uma borda.


    border-width: 10px;
    width: 50%;

Ele também tem width 50%, mas sem borda.


    width: 50%;

É assim que as coisas funcionam mas certamente não é assim que nós pensamos. Se você pensa no tamanho de uma caixa, você não pensa só no conteúdo dela. Uma caixa termina em sua borda e isso deveria ser considerado seu tamanho.

Um viva ao IE6!

O curioso é que os primeiros a perceberem que o box model do CSS era esquisito foi a Microsoft. Já no IE6 em quirks mode eles trocaram o box model pra que o width significasse o tamanho total até a borda. A ideia era boa mas o problema foi eles atropelarem a especificação da época, o que acabou criando boa parte dos problemas de incompatibilidade entre navegadores. O IE em standards mode usa o box model oficial e esse é o padrão a partir do IE8.

Mas como a ideia, no fim, era boa, isso acabou se transformando no box-sizing do CSS3, que nos permite trocar o box model que queremos usar.

Por padrão, todos os elementos têm o valor box-sizing: content-box o que indica que o tamanho dele é definido pelo seu conteúdo apenas -- em outras palavras, é o tal box model padrão que vimos antes. Mas podemos trocar por box-sizing: border-box que indica que o tamanho agora levará em conta até a borda -- ou seja, o width será a soma do conteúdo com a borda e o padding.

Queria que ele ocupasse metade da tela com uma borda.


    box-sizing: border-box;
    border-width: 10px;
    width: 50%;

Ele também tem width 50%, mas sem borda.


    box-sizing: border-box;
    width: 50%;

Usando o novo box-sizing

O suporte nos navegadores é excelente, indo até o IE8 -- e há um polyfill pra IE6 e IE7 se você precisar. O Firefox ainda precisa do prefixo -moz- e versões mais antigas do Chrome, Safari e Android, do -webkit-.

Eu uso essa regra em todos os elementos de todas as minhas páginas -- inclusive aqui no blog. Então aplico o seletor universal:

* {
    -webkit-box-sizing: border-box;
       -moz-box-sizing: border-box;
            box-sizing: border-box;
}

Existe uma preocupação quanto à performance do seletor universal * mas ela certamente não será um problema para algo tão simples e pontual como essa regra. O ruim é abusar e ter diversas regras com seletor universal e descendentes. E você nem devia estar se preocupando com performance de CSS se ainda não tem uma nota maior que 95 no PageSpeed; gzip, minificação, sprites, etc são bem mais importantes pra performance.

Outro ponto importante é que o seletor * não pega pseudo-elementos. Na prática, acabo usando:

*, *:before, *:after {
    -webkit-box-sizing: border-box;
       -moz-box-sizing: border-box;
            box-sizing: border-box;
}

Atualização Ago/2013: acrescentei os pseudo-elementos na regra e removi informações sobre bug antigo do Firefox.

Conteúdo original do blog sergiolopes.org.

Bate-papo responsivo - Entrevista na RevistaW

2013-07-31T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Automação de build de front-end com Grunt.js

2013-06-25T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Imagens SVG com CSS animations

2013-05-15T00:00:00.000Z

Esse post possui exemplos não suportados nos feeds RSS. Recomendo que visite a página e leia por lá. (é otimizado também para mobile)

No HTML5, imagens em SVG podem ser embutidas direto no documento HTML com a tag <svg>. A vantagem é que você tem elementos no DOM e pode manipulá-los com CSS e JavaScript normalmente.

Quando escrevi meu livro "A Web Mobile", o amigo e designer Thiago Vilaça desenhou a capa e criou um desenho que gostei muito. Aí quando fui montar o hotsite do livro, claro que eu quis colocar o desenho por lá.

Mas, estamos na Web! Interatividade é a regra e eu achei que o desenho tinha tudo pra receber um toque de animação. Solução? Usar SVG com CSS Animations.

SVG inline no HTML5

Colocar um desenho SVG na página é só sair escrevendo a tag <svg> e pronto. Por exemplo, se quisermos desenhar um círculo em SVG no meio da página:

<!doctype html>
<html>
<body>
    <h1>Meu teste de SVG</h1>

    <svg>
        <circle cx="50" cy="50" r="40" fill="#F90">
    </svg>
</body>
</html>

Segundo o Can I use, SVGs inline no HTML5 funcionam em todos os navegadores modernos. As maiores exceções são Internet Explorer 8, Android 2.x e Opera Mini.

Podemos detectar suporte a SVG com Modernizr e oferecer um fallback se for o caso. No caso da página do livro, eu decidi não oferecer fallback já que é uma imagem meramente decorativa. Os navegadores sem suporte a SVG simplesmente não vêem a imagem:

.no-inlinesvg svg {
    display: none;
}

PS. há um problema de performance nisso, claro. Os navegadores velhos vão baixar o SVG mesmo sem poderem exibi-lo. Decidi ignorar isso já que o SVG é relativamente pequeno e quase não tenho visitantes desses navegadores velhos por aqui.

CSS modificando o SVG

O legal do SVG também ser um formato de marcação é que você pode colocar classes e IDs nos elementos e depois referenciá-los no CSS. No desenho, por exemplo, eu queria mudar a cor das setas do desenho via CSS. Bastou dar uma classe e mudar a cor no CSS.

Algo assim:

<!doctype html>
<html>
<body>
    <style>
    .seta {
        fill: #fcb870;
    }
    </style>

    <svg>
        ...
        <path class="seta" d="...">
        ...
    </svg>
</body>
</html>

O importante aqui é perceber como coloquei uma classe no elemento <path> do SVG e depois referenciei no CSS normal da página. Repare também que estou usando propriedades CSS específicas de SVG, como a fill, que serve pra pintar um elemento de certa cor (quase como um background-color).

CSS3 Animations no SVG

Sabendo modificar o SVG com CSS, o céu é o limite! No caso da seta que falei antes, queria ainda fazê-la mudar de cor ciclicamente, como se estivesse piscando entre duas cores possíveis. Fácil de fazer com CSS animations:

@keyframes muda-cor {
    0%,49% {
        fill: #fcb870
    }
    50%,100% {
        fill: #f89c33
    }
}

.seta {
    animation: muda-cor 3s linear infinite;
}

O que estamos fazendo é alternar entre essas duas cores a cada 5 segundos sem parar. A sintaxe dos keyframes indica que a primeira cor fica fixa na metade do tempo e depois vem a outra cor na outra metade. Não coloquei os prefixos necessários para alguns browsers.

Animações mais complicadas

Dá pra animar de tudo com CSS Animations. Dá pra combinar com CSS transforms e criar uns efeitos legais. Um que eu queria na página era fazer as engrenagens girarem. A princípio, girar algo com CSS é simples:

@keyframes gira {
    to {
        transform: rotate(360deg);
    }
}

.engrenagem {
    animation: gira 2s linear infinite;
}

Mas o resultado não é o esperado. O elemento vai girar mas repare que o eixo de rotação não é o próprio elemento, mas o ponto (0,0) do desenho SVG. Pra resolver, é preciso configurar a propriedade transform-origin apontando a coordenada da origem da rotação — que deve ser o centro da engrenagem. Essa coordenada tem que ser calculada com relação à origem do desenho.

Por exemplo:

.engrenagem {
    animation: gira 8s linear infinite;
    transform-origin: 43px 40px;
}

Esse número não é a coisa mais fácil de calcular mas também não é um bicho de sete cabeças.

Muitas animações

O efeito final que eu criei nessa página gira duas engrenagens em sentidos opostos, altera as cores de 4 setas e ainda desloca suavemente duas nuvens de fundo de maneira alternada.

Veja o efeito completo abaixo ou no site do livro:

O legal de usar CSS animations para detalhes assim é que elas degradam sem problemas em navegadores sem suporte. O IE9, por exemplo, suporta SVG mas não animações. Lá, o desenho vai aparecer estático sem problemas.

Outro detalhe importante é que a especificação SVG tem uma parte própria de animações que poderíamos ter usado também. Nesse caso, preferi CSS Animations que já são mais conhecidas dos desenvolvedores Web e bem simples de usar.

Conteúdo original do blog sergiolopes.org.

Palestra: Truques de Web mobile

2013-04-30T00:00:00.000Z

Essa palestra é completamente interativa, o que não é suportado nos feeds RSS. Recomendo que visite o site e leia por lá. (é otimizado também para mobile)

Muitas dicas de performance, otimizações, UX, HTML5 e CSS3 pra deixar seu site mobile tinindo. Slides comentados, cheios de referências e exemplos práticos. Veja demos no smartphone/tablet.

Lançamento do meu livro “A Web Mobile — Programe para um mundo de muitos dispositivos.”

2013-04-22T00:00:00.000Z

Acabo de lançar pela editora Casa do Código meu livro “A Web Mobile”. Falo sobre design responsivo, media queries, telas retina, touch screens, mobile-first, RESS e muito mais.

Se você me acompanha aqui no blog, certamente vai gostar do livro. Alguns tópicos inclusive saíram aqui do blog e aproveitei pra incrementá-los bastante. Mas, claro, a maioria dos tópicos são inéditos e recheados de conteúdo de mobile e Web — veja a lista completa de tópicos.

O livro custa R$ 29 em ebook, R$ 59 na versão impressa e R$ 69 ebook + impresso. Você pode comprar direto no site da editora Casa do Código.

Indico o livro pra todo mundo que trabalha com Web mobile ou quer entrar nessa área. Não é um livro introdutório de Web — você precisa saber HTML, CSS e JS. Também não é um livro com projetinho de começo ao fim — indico o livro do amigo Tárcio pra isso. Meu livro tem 26 tópicos diversos sobre Web e mobile, discutindo até aspectos avançados como RESS ou conditional loading.

Se estiver com dúvidas, temos uma lista de discussão do livro onde você pode me encontrar.

Conteúdo original do blog sergiolopes.org.

Aniversário de 1 ano do blog

2013-03-26T00:00:00.000Z

Parece que foi ontem. Mas hoje, 26 de março de 2013, faz 1 ano que lancei esse blog. Já tive outros blogs pessoais antes mas nunca tinha me dedicado tanto quanto agora. Esse novo blog, focado em desenvolvimento front-end, foi um grande feito pessoal pra mim.

Esse é um post comemorativo. Se você acompanha aqui com frequência, vai gostar de ler. Tem números e estatísticas. E também um pouco da minha estratégia pra fazê-lo crescer. Podem ser informações interessantes pra mais gente.

1 ano de vida

Lancei o blog em Março de 2012 já com 4 posts simples pra começar--odeio aqueles blogs que começam com um hello world inútil apenas. Nesse 1 ano, publiquei 48 posts, o que dá quase 1 por semana. Uma média, na minha opinião bem boa pra um blog pessoal.

Desses posts:

Maioria sobre Web Mobile. 13 posts.
8 outros posts foram sobre Web em geral.
Mais 2 posts sobre otimizações web.
Outros 6 posts foram de reviews de livros de front-end.
12 posts foram cobrindo palestras de amigos em eventos que assisti. Um formato que resolvi testar por aqui.
E 7 posts eu escrevi no blog da Caelum e só linkei aqui. Acabei linkando também pra mais 6 posts meus antigos no blog da Caelum mas que acho importantes.

Eu uso os comentários do Facebook aqui já que uso o DocPad--aliás, sabia que o código do blog todo tá aberto? Foram 160 comentários esse ano e mais alguns milhares de Likes e compartilhamentos. Aliás, optei pelos comentários via Facebook pois eles são postados automaticamente na timeline do usuário, me ajudando na divulgação.

Nesse 1 ano, já fiz o primeiro redesign do blog também, na virada do ano. Sou programador e não muito bom pra isso, mas estou bem satisfeito com o design que montei agora. O design antigo, se estiver curioso, você pode ver aqui, aqui e aqui. Sou adepto de Flat Design e coisas mais minimalistas, mas vira e mexe experimento com outras ideias também.

Na implementação do blog, uso DocPad pra gerar meu HTML. Uso Stylus pro CSS. O JavaScript é normal, sem framework. E otimizo tudo com o mod_pagespeed direto no servidor. Tudo aqui, claro, é absolutamente responsivo e compatível com mobile. Como falei, você pode acompanhar o código de tudo isso no Github.

Estatísticas

Uma parte divertida de ter um blog pessoal sem muito compromisso é poder abrir os números sem problemas. Pode ser interessante pra você comparar com suas próprias experiências.

Visitas de Março de 2012 a Março de 2013.

As visitas têm crescido bastante conforme mais conteúdo é postado. Isso é bem legal. Mas o blog ainda é pequeno em tamanho. O melhor pra mim não e o número de visitas mas a qualidade delas. E devo dizer que meu público--você!--é excelente!

Comportamento dos visitantes.

Eu acho impressionante o tempo médio da visita ser de 8 minutos e meio. O recorde, pra mim quase inacreditável, é na minha palestra sobre mobile web com tempo médio de meia hora. Isso quer dizer que as pessoas realmente vêm aqui e lêem o que eu escrevo. Fantástico isso.

Navegadores usados.

Não ter nem 3% de usuários de IE é fantástico. Aliás, nem testo nesses browsers velhos. Posso usar códigos mais modernos já que vocês são uma audiência de navegadores modernos.

8% dos visitantes em mobile.

O número de usuários mobile porém não é tão alto quanto eu gostaria. Mas já um número bem mais alto que a média por aí (média brasileira é menor que 3% e outros sites que cuido não chegam nem a 5%). O site é todo responsivo e tem atraído uma certa audiência. Acho que essa proporção deve crescer mais ainda em 2013.

Porcentagem de cada site que linka aqui (referral sources).

Maioria das visitas vem de buscas no Google e de navegação direta. Mas boa parte é de links em outros sites. Desses, mais da metade graças a redes sociais--Twitter e Facebook. Agradeço a todos que compartilham meus posts e ajudam o blog a crescer. E também vários blogs e portais linkam pra artigos aqui--obrigado também!

Estratégias

Não tenho grandes ambições para o blog crescer horrores, então não me cobro muito. Algumas poucas estratégias que uso:

Postar sempre no meu Facebook e no meu Twitter, plataformas fantásticas pra divulgação.
Botões pra compartilhar no Facebook e no Twitter em todos os posts, além dos comentários via Facebook.
Tirei botões de Like nos posts. O número de likes não é muito importante e não traz visitas. Compartilhar é bem mais forte e importante.
Posto bastante no blog da Caelum que tem mais visibilidade e acaba trazendo visitas aqui.

Do conteúdo em si, busco artigos mais focados em um tema específico. Escrevo eles com linguagem simples e clara, quase uma conversa. Odeio aqueles posts com escrita pomposa!

Tenho tentado também associar um estilo visual aos conteúdos que público. Uso o laranja (#F90) em tudo e tenho feito essa minha foto feia (e laranja!) quase como um logo. Uso isso consistentemente aqui no blog, nas palestras que dou, nos meus perfis no Twitter e no Facebook.

Mas, no fundo, minha estratégia maior é escrever artigos--acredito eu--de qualidade e deixar rolar. Acredito muito que, se é interessante, as pessoas vão vir ler.

Futuro

O futuro é continuar esse blog e colocar cada vez mais artigos aqui. Espero que você goste de acompanhar. Aliás, pra não perder um post, assine o RSS ou me siga no Facebook e no Twitter.

E, se você aguentou ler tudo isso até aqui, uma novidade em primeira mão: acabo de lançar um livro sobre Web Mobile. É fruto direto do trabalho nesse blog e do resultado positivo desse ano todo. Ele tem artigos que publiquei aqui mas estendidos com mais conteúdo; e vários artigos novos e inéditos, claro. Confere lá!

Atualização Abril/2013: Migrei o blog recentemente do Jekyll pro DocPad, então atualizei as informações aqui no post.

Conteúdo original do blog sergiolopes.org.

Palestra: Dominando HTML5 offline com AppCache

2013-03-09T00:00:00.000Z

Essa palestra é completamente interativa, o que não é suportado nos feeds RSS. Recomendo que visite o site e leia por lá. (é otimizado também para mobile)

Como criar sites e webapps offline com Application Cache. Palestra completa com dicas avançadas, exemplos e explicações.

Internet Explorer, testes cross browsers e a política de compatibilidade

2013-02-18T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Use sempre media queries baseadas no conteúdo da sua página

2013-02-15T00:00:00.000Z

Ao escrever medias queries, você precisa escolher algum valor pra colocar lá. É o que chamamos dos breakpoints, os pontos onde seu layout vai ser ajustado por causa de uma resolução diferente. E escrever bons breakpoints é essencial para um design responsivo de qualidade.

E o que mais aparece de pergunta de quem tá começando com design responsivo é: quais os valores padrões de se colocar nas media queries? E logo surge uma lista parecida com essa:

@media only screen and (min-width: 480px) { ... }
@media only screen and (min-width: 600px) { ... }
@media only screen and (min-width: 768px) { ... }
@media only screen and (min-width: 992px) { ... }
@media only screen and (min-width: 1382px) { ... }

Péssima prática! Essa lista eu copiei do famoso projeto 320andup mas você acha outras parecidas, com esse valores supostamente "comuns". 480px é por causa de um iPhone em landscape, 600px é comum em tablets de 7'', 768px pega um iPad em portrait, 992px é um Desktop de 1024 menos as barras de rolagem e 1382px pra Desktops grandes.

O pessoal chama essa prática de device-driven breakpoints, pois são valores gerados a partir de tamanhos de dispositivos.

Não use device-driven breakpoints

Primeiro problema: essa lista pensa em meia dúzia de tipos de dispositivos. Mas e os 360px de um Galaxy SIII? Ou os 533px do Galaxy SII em landscape? Ou o iPhone 5 com 568px em landscape? Qualquer lista de media queries padrão é muito pobre quando pensamos na situação atual -- e futura -- dos diferentes dispositivos.

Segundo problema: quem disse que seu design realmente precisa de todos esses breakpoints? Ou pior, que ele não vai ficar ruim bem entre as paradas de 480px e 600px? Usar esses valores de media queries não garante que seu design funcionará em todos os dispositivos, mas apenas nos dispositivos "padrões" -- seja lá o que for isso.

Use content-driven breakpoints

Dá uma olhada em algumas das medias queries que uso aqui no blog: (PS. aliás, o código do blog tá disponível no github e já uso tudo com em por causa de acessibilidade)

@media (min-width: 37em) { ... } /* 592px */
@media (min-width: 41em) { ... } /* 656px */
@media (min-width: 47em) { ... } /* 752px */
@media (min-width: 68em) { ... } /* 1088px */
@media (min-width: 82em) { ... } /* 1312px */
@media (min-width: 100em) { ... } /* 1600px */

Da última vez que chequei, não consegui encontrar nenhum dispositivo com 656px ou 752px. De onde saíram então esses valores? Do design do meu blog.

A ideia é simples: fiz meu design responsivo com unidades flexíveis -- porcentagens e em -- e pra pequenos dispositivos primeiro -- mobile first. Aí fui testando as diversas resoluções pra ver onde o design não ficava tão bom e coloquei um breakpoint lá.

É o que o pessoal chama de content-driven breakpoints. Ou seja, achar suas media queries a partir do seu conteúdo e do seu design. Fica bem mais fácil garantir que sua página funciona em todos os dispositivos.

Como achar meus breakpoints?

Abra sua página original no navegador;
Vá redimensionando a janela devagar até o design parecer ruim -- se fez mobile-first, abra pequeno e vá aumentando a janela; senão, abra grande e vá diminuindo a janela;
Quando achar um ponto em que o design quebra, copie o tamanho da janela e crie uma media query com esse valor lá no seu CSS;
Recarregue a página, veja se as mudanças melhoraram o design, e continue redimensionando pra achar o próximo breakpoint.

Algumas ferramentas que podem te ajudar nisso:

O responsive mode do Firefox;
FitWeird, um excelente bookmarklet que te dá o tamanho da tela, inclusive em em;
Meu responsive play.

Conteúdo original do blog sergiolopes.org.

Review do livro "The Tangled Web: A Guide to Securing Modern Web Applications" do Michal Zalewski

2013-02-07T00:00:00.000Z

Um dos livros mais divertidos que já li. Foi escrito por Michal Zalewski, especialista em segurança na Web e que trabalha no Google. Trata dos desafios de segurança que os navegadores a desenvolvedores Web enfretam hoje em dia.

O assunto é até um pouco pesado, mas o livro é muito bem escrito, didático e leve de digerir. "The Tangled Web: A Guide to Securing Modern Web Applications" não é, porém, um livro pra todo mundo. É um livro mais avançado, voltado pra uma audiência que já sujou a mão com as coisas por trás do HTTP, ou que sabe a diferença que encodings podem fazer na aplicação, e que já toparam com siglas como XSS e CSRF.

É um excelente livro. Mostra com riqueza de detalhes o que acontece por trás dos navegadores -- veja no site dele um overview dos capítulos pra ter uma ideia da quantidade de informação que ele tem. O livro expõe uma quantidade inimaginável de brechas de segurança na Web. E a conclusão dele -- e minha, após lê-lo -- é que a Web funciona meio que por sorte. É impressionante o que é possível fazer de ruim!

Eu gosto de estudar a segurança na Web meio que por hobby. Já estava familiarizado com ataques como XSS, CSRF, injeção de parâmetros, clickjacking; já conhecia algumas das novidades como CORS e CSP. Mesmo assim, aprendi muito.

O autor tem uma visão muito clara do que é eficaz e o que não é com relação a segurança. Mostra os princípios por trás do ataques e as limitações nos navegadores, sendo bem realista. Uma citação que mostra o tipo de comentário que você vai encontrar no livro:

Antimalware features do not make individual attacks any more difficult; they are simply meant to stop the large-scale distribution of unsophisticated malware, based on the assumption that most users are not interesting enough to be specifically targeted or attacked with something clever.

E, uma frase ótima que está lá no final, na conclusão, quando ele reflete sobre segurança de um modo geral, e como a segurança na Web está relacionada:

Why is it that we get upset at developers who use cryptography incorrectly, but we don’t mind that the locks on our doors can be opened with a safety pin? Why do we scorn web developers who can’t get input validation right, but we don’t test our breakfast for laxatives or LSD?

Gostei muito desse livro, mas não é pra qualquer um. Ele também é um pouco mais caro (paguei quase $30 no ebook) e, como foi lançado em no fim de 2011, pode não ter as últimas novidades.

Mas, se você se interessa pela área, definitivamente recomendo a leitura.

Conteúdo original do blog sergiolopes.org.

Web Design Responsivo: as melhores referências em português pra você aprender do básico ao avançado

2013-02-04T00:00:00.000Z

Web Design Responsivo: as melhores referências em português pra você aprender do básico ao avançado

Então você quer aprender design responsivo? Ou já sabe o conceito e quer se aprofundar na técnica? Compilei uma lista de referências sobre o tema exclusivamente em português. Artigos, palestras, livros, cursos e exemplos de sites responsivos brasileiros. Bons estudos!

1. Artigos

Introdutórios

Design Responsivo por uma Web única, artigo meu aqui no Blog.
Design Responsivo: Entenda o que é a técnica e como ela funciona, por Dennis Altermann.
Série no Blog da Popup: parte 1, parte 2 e parte 3, por Dani Guerrato.
Introdução ao Responsive Web Design, do Diego Eis, Tableless.
Flexibilidade em páginas para dispositivos móveis com media queries, artigo meu no Blog da Caelum.
10 dicas para fazer um email responsivo, artigo meu aqui no Blog.
Pixels, pixels ou pixels? Dicas de Web Mobile com viewport, artigo meu no Blog da Caelum.
Responsive Web Design – Adaptação vs Otimização, do Diego Eis, Tableless.
E você jura que ainda não sabe o que é Responsive Webdesign? Vamos mudar isso já!, do Bernard de Luna no iMasters.

Mais avançados

Media queries para resoluções diferentes e retina, artigo meu aqui no Blog.
Media queries também ajudam na acessibilidade, artigo meu aqui no Blog.
Responsive Web Design – focando a coisa certa, do Diego Eis, Tableless.
Tudo que você precisa saber sobre resoluções, telas retina, devicePixelRatio, DPI, CSS pixels e etc, artigo meu aqui no Blog.
Design Responsivo & Retina Display: desenvolvimento web em alta resolução, por Dani Guerrato.
DevCast sobre Design Responsivo com Leandro Lima.
Media queries verticais, por Ofelquis Gimenes.
As muitas faces do Mobile First, artigo de Brad Frost, traduzido pelo Will Sales no Tableless.

2. Palestras

Introdutórias

Responsive Web Design: conteúdo em todos os dispositivos, do Eduardo Shiota, gravada no QCon SP 2012.
Layouts Responsivos, do Zeno Rocha e do Bernard de Luna, na Campus Party 2013.

Mais avançadas

Uma tonela de truques de Web Mobile, palestra minha no QCon SP 2012 - vídeo oficial
Slides: Os Caminhos do Design Mobile e vídeo, por Horácio Soares, na Campus Party 2013.
Slides: Mobile First, por Horácio Soares, na web.br 2012.

3. Livros e cursos

Meu novo livro A Web Mobile: programe para um mundo de muitos dispositivos.
Web Design Responsivo, do Tárcio Zemel, pela editora Casa do Código - meu review.
Curso Web Design da Caelum - HTML, CSS e JavaScript. Design responsivo é um dos tópicos do curso.

4. Fóruns, listas, grupos

Grupo Design Responsivo no Facebook
Lista HTML5 CSS 3 Brasil
Grupo Desenvolvimento Mobile no Facebook
Fórum GUJ

5. Sites Responsivos Brasileiros

Esse blog :)
Vários subsites da Globo.com, como Globo TV e ETC.
Tableless
Livro Arquitetura Java
Plataformatec
Umobi

6. Evento

Mobile Conf 2013

Certamente estão faltando vários bons links nessa lista. Tem mais algum bom para compartilhar sobre design responsivo? Comente e atualizo aqui!

Conteúdo original do blog sergiolopes.org.

Media queries para resoluções diferentes e retina

2013-01-28T00:00:00.000Z

Muitas vezes, você vai querer carregar imagens e estilos diferentes em telas de resolução diferentes ou retina. Pra isso, você precisa de media queries de resolução.

Nesse artigo, discuto a forma correta de se atacar telas de alta resolução com CSS, as diferenças dos navegadores, que valores usar e algumas boas práticas. O resumo do artigo é que você deve usar uma media query parecida com essa:

@media (-webkit-min-device-pixel-ratio: 1.5),
       (min-resolution: 144dpi) {

}

Sim, eu sei que você provavelmente já viu ou usou uma versão bem maior dessa media query, cheia de prefixos de navegadores e valores estranhos. Pois bem, não use mais, o correto para os browsers de hoje e do futuro é essa aí de cima.

Porque essa media query pra telas retina?

Antes de analisar a media query em si, é bom entender direito o que significam DPIs, devicePixelRatio, retina e outros termos.

Muito tempo atrás, quando surgiram as primeiras telas com pixel ratio diferente de 1, o pessoal do WebKit criou uma media querie pra isso, a famosa -webkit-device-pixel-ratio (e suas versões com min e max). Alguns browsers chegaram a experimentar com isso, surgindo até a famosa aberração da Mozilla com min--moz-device-pixel-ratio.

Mas aí veio a especificação oficial e revisaram essa media query, criando uma equivalente com um nome mais simples: resolution. Você pode escrever min-resolution e max-resolution e ela aceita várias medidas, sendo dpi e dppx as mais importantes.

Cuidado, porém, com os valores das medidas. Você já leu meu artigo sobre resoluções, DPI e cia então lembra que os browsers fixam a resolução lógica em 96dpi, independente da resolução física. Então, quando escrevi 144dpi na media query lá em cima, o que estava dizendo é que queria 1.5x o DPI padrão de 96, pegando então telas com pixel ratio 1.5, como vários aparelhos Android.

A medida dppx é nova no CSS e significa o mesmo que o device pixel ratio. Então, poderíamos escrever 1.5dppx e seria equivalente a 144dpi.

Qual valor usar? Realmente preciso de imagens diferentes pra cada resolução?

No meu artigo sobre device pixel ratio, citei os valores que encontramos no mercado hoje:

0.75dppx (= 72dpi) - Android low-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.

Você pode escrever uma media query resolution pra cada um desses valores, servindo imagens adaptadas pra cada resolução. Pode até ser uma ideia se você for gerar tudo isso automaticamente (imagens e media queries), mas, na mão, fica inviável.

O que vejo muito comum de se fazer é servir uma imagem em alta resolução para qualquer tela acima de 1dppx. Você pode fazer algo como o pessoal do WordPress que escolheu 120dpi (= 1.25dppx) como valor inicial pra servir imagens retina.

Mas, veja se realmente vale a pena servir imagens diferentes só por causa do DPI. Isso vai ficar bastante complicado nos próximos anos. Pra suportar bem todo tipo de tela, prefira usar texto, fontes, SVG e CSS. Pra fotos, uma técnica que tem ficado popular são as compressive images.

E os browsers?

Todos os browsers modernos suportam a media query resolution, exceto o WebKit. Existem ainda alguns outros problemas, principalmente em dispositivos móveis. Alguns testes feitos em Janeiro/2013:

Firefox e Opera no Desktop já suportam resolution.
No Webkit, já existe suporte desde Outubro/2012 mas isso ainda não chegou no browsers finais. Por isso, usamos ainda a antiga -webkit-device-pixel-ratio, pensando no Chrome, Safari, Android e iOS.
Opera Mobile suporta resolution nativamente no Android. Único defeito é que ele reporta pixel ratio 1 no meu Galaxy 5 de pixel ratio 0.75. Mas nos celulares com 1.5 e 2, tudo funciona perfeito.
Firefox no Android só aceita a velha -moz-device-pixel-ratio, mas ele devolve sempre pixel ratio 1 e não suporta telas retina ainda. Isso é um bug e, quando for consertado, fará a resolution funcionar, como no Firefox 18 pra Mac que já suporta o MacBook Retina.
Opera Mini reporta sempre pixel ratio 1, tanto no Android quando no iOS, mesmo em telas retina. O problema é que ele suporta a media query resolution cheia de bugs: se usar dppx ele aceita qualquer valor, e o min-resolution acha que o pixel ratio é 2. Conclusão: o suporte nele ainda é bem bugado, mas acrescentar -o-device-pixel-ratio não vai melhorar isso.
Internet Explorer suporta resolution desde a versão 9 e nunca suportou device-pixel-ratio.
Outros browsers que testei: Dolphin Android Beta e UC Browser. Em ambos, funciona -webkit-device-pixel-ratio mas eles sempre reportam 1, mesmo em telas retina.

A conclusão de tudo isso é que precisamos ainda da -webkit-device-pixel-ratio mas já podemos usar a resolution pros outros browsers, sem prefixos. O ideal também é usar a unidade dpi e não dppx, já que o suporte nos browsers ainda é precário.

A media query final

Ta aí então a media query final pra suportarmos telas de alta resolução hoje e no futuro, sem problemas:

@media (-webkit-min-device-pixel-ratio: 1.25),
       (min-resolution: 120dpi) { 

}

* Imagem que ilustra o post por @bcnbits no Flickr.

Conteúdo original do blog sergiolopes.org.

Review do livro "The Mobile Book" da Smashing Magazine

2013-01-21T00:00:00.000Z

Um livro épico, reunindo diversos autores famosos para falar sobre mobile. Muitos tópicos e diversos insights. Leitura obrigatória pra qualquer desenvolvedor mobile (web e nativo).

Lançado pela Smashing Magazine, o The Mobile Book é uma coletânea de 7 capítulos sobre mobile de autores importantes. Nomes como Brad Frost, Trent Walton, Peter-Paul Koch e outros.

O livro tem um viés um pouco mais de design que de código -- normal, pra quem acompanha a Smashing Magazine. Há conteúdo técnico, mas boa parte é de UX, patterns visuais, mercado, análises, estratégias e futuro. E, apesar de falar de mobile como um todo, há uma preferência clara por web e design responsivo (o que eu gostei, claro).

Tirando alguns poucos pontos que não gostei, recomendo o livro pra todo desenvolvedor Web, front-end, designer e quem mais estiver envolvido com mobile.

"The Mobile Book, pela Smashing Magazine"

O livro está dispoível no site oficial por $18 na versão ebook -- que inclui PDF, epub e mobi -- e $50 impresso+ebook. Tem 330 páginas no total. Ele tem um design muito bonito. Mas a versão Kindle deixa muito a desejar, e acabei lendo no PDF mesmo, o que me irritou um pouco. Não tenho, por exemplo, minhas anotações sincronizadas. Mesmo assim, separei algumas.

São 7 artigos na versão final do livro. Há a promessa de um ebook extra com mais artigos a ser liberado em breve aos compradores. Meus comentários:

1) What’s Going on in Mobile?, por Peter-Paul Koch

Mais conhecido como ppk, é o autor do conhecidíssimo QuirksMode.org e trabalha com mobile antes de isso ser moda. Nesse capítulo, ele traça um panorama do mercado mobile atual com muitas informações baseadas em sua análise do mundo todo.

Gostei muito de ler sobre a mecânica por trás das forças no mundo mobile: fabricantes, operadoras e produtoras de SO. Há muitas sutilezas aí que acabam determinando como o mercado se move. Outro ponto forte é a análise dos browsers mobile, a imensa variedade, suas diferenças e números, incluindo dicas pra trabalhar com proxy browsers como o Opera Mini.

Das dicas gerais, ele fala pra evitar bibliotecas JS, usar detecção de user-agent, e montar um device lab. Há muito mais, claro. Separei umas poucas frases de efeito:

Never assume anything on mobile. Never. Anything.

Operators and device vendors are afraid of commoditization and irrelevance and will defend themselves by influencing the overall user experience. Sometimes this is not a good idea.

The Web will become an OS, but currently it’s a weapon in the hands of the losers.

2) The Future of Mobile, por Stephanie Rieger

A Stephanie teve a impossível tarefa de prever o futuro, o que tornou o artigo meio irrelevante pra mim. Ninguém sabe o futuro e, pra mim, o artigo é pura especulação sob a ótica de uma única pessoa que nem trabalha em fabricantes de aparelhos ou outro grande player da indústria.

Há pontos interessates, como ideias de como o NFC pode melhorar a interação dos usuários num futuro próximo. Mas sempre que alguém fica insistindo na ideia idiota de que geladeiras com Internet são o futuro, fico irritado. (e espero estar certo nessa minha previsão também individualista de que geladeiras com Internet não são o futuro)

Ela fala muito de dispositivos bizarros, como uma caixa de remédios conectada na Internet e outras da Internet das Coisas. Até divertido como histórias futurísticas, mas de pouca utilidade prática. A melhor citação dela é a que fecha o capítulo, transformando tudo que veio antes em irrelevante:

My final advice is this: don’t try to predict the future. Carefully observe what’s happening today, and learn about what is coming next. Think of ways to build flexibility into each and every product you develop.

3) Responsive Design Strategies, por Trent Walton

O Trent Walton escreve muito sobre Web responsiva e esteve por trás do redesign da homepage da Microsoft. Esse artigo é um básico de responsive design, revendo conceitos importantes mas não tão importante pra quem já trabalha com isso.

Ele começa revendo os conceitos do Ethan Marcotte de grids fluídos, mídias flexíveis e media queries. Comenta boas práticas importantes como escrever valores das media queries em em e baseado no design, e ideias pra media queries verticais.

Aí entra uma parte mais profunda onde ele fala de diversos assuntos. Como devemos fazer o design baseado no browser e não no Photoshop. Técnicas para priorizar contéudo quando começamos a mover tudo na tela com media queries -- que ele chama de content coreography. Ou ainda, dicas para tipografia fluída em responsive design.

4) Responsive Design Patterns, por Brad Frost

Eu gosto muito do trabalho do Brad Frost e acompanho o blog dele sempre. Por isso, devo dizer que o capítulo não foi muita novidade pra mim. Mas é um conteúdo fantástico, e foi bom reler suas opiniões condensadas de uma vez.

O capítulo analisa diversas formas de organizar o layout quando a tela começa a mudar de tamanho. Colocar navegação no topo, embaixo, offcanvas? São muitas questões a considerar para organizar o layout e conteúdo da página. Outro ponto é o uso de conditional loading pra quebrar páginas grandes do desktop em diversas páginas no mobile.

Além disso, ele fala como outros aspectos da página são afetados pelo design responsivo, como imagens, mapas, widgets, tipografia, tabelas, formulários e mais. É o capítulo mais completo do livro.

Ensure that content flows logically. Users don’t want to sift through a bunch of disparate content to find what they’re looking for.

Treat layout as an enhancement. Bryan Rieger eloquently stated that, “The absence of support for @media queries is in fact the first @media query.”

Find the balance between navigation accessibility and unobtrusiveness. Like a good friend, it should be there when you need it, but not always in your face, demanding attention.

Giving users different experiences is alright. However, the full functionality should remain accessible to everybody in some way, shape or form.

Make sure you actually need one. Many carousels are used to sweep content under the rug. A carousel should not be a lazy substitute for making important content strategy decisions.

5) Optimization For Mobile, por Dave Olsen

Dado meu aprofundamento nessas duas áreas -- mobile e otimizações --, esse era certamente o artigo que eu mais esperava ler. E ele é muito bom, apesar de não entrar em algumas técnicas muito avançadas e bizarras que eu tenho lido ultimamente.

Ele fala de números concretos que mostram o tamanho das páginas crescendo, em como a latência das redes móveis afeta a performance e outros. Aí cita que responsive design pode esconder problemas de performance tornando a página visualmente menor, mas com mesmo peso de performance que no Desktop. Isso não é necessáriamente ruim se sua página for pequena, mas com a média em torno de 1 MB, só colocar media queries não vai fazer mágicas.

A parte das técnicas de otimização é bem próxima do que já sabemos -- gzip, minificação, cache etc. Mas há algumas dicas a mais pra mobile, como não usar display:none pra esconder conteúdo no celular, ou usar localStorage pra cache, ou ainda como simular conexões ruins com um proxy. E, claro, ele também prega o abandono do jQuery e outras libs pesadas.

Por fim, ele ainda fala de RESS, que é o responsive design com detecção de browser pra rodar algumas coisas server-side. Mas confesso que ainda não tenho uma opinião muito certa sobre isso.

While mobile network speeds are slower than desktop speeds, they aren’t on the whole that bad. The real Web performance difference between the two is latency.

For me, the most disappointing feature of HTML5 so far has to be AppCache. [...] My advice regarding AppCache for now is simple: stay away from it.

6) Hands On Design for Mobile (UX Perspective), por Dennis Kardys

Pior artigo do livro. Extremamente longo e confuso. Fala de um monte de assuntos e ao mesmo tempo não fala de nada. É um artigo mais de UX e não técnico, mas, mesmo assim, é pouco prático e cheio de bla bla bla.

Ele fala da mudança de paradigma do mobile, do workflow de criação ser mais ágil, um monte de besteiras sobre rascunhos, wireframes e prototipação. Tem várias palavras bonitas que não querem dizer nada. Além de ruim, me irritou muito o fato dele ter 65 páginas, mais que qualquer outro capítulo.

7) Designing With Gestures and Touch, por Josh Clark

Fechando o livro veio o Josh Clark com um artigo sobre UX mas bem melhor que o anterior. O ponto principal é que touch e gestos são a base da interação com computadores agora.

As novas máquinas com Windows 8 misturam tudo -- touch, mouse, teclado, trackpad -- o que torna impossível otimizar para um cenário específico. Não há mais cenários específicos e detectar tablets como diferentes de PCs é besteira. Devemos desenvolver agora tudo sempre pensando em touch; se o usuário usar mouse, será tranquilo. O contrário não é verdade.

Boa parte do capítulo é mostrando as diferenças visuais entre as plataformas móveis e as diferenças de interação do usuário entre celulares, tablets e PCs. É bem interessante ver como pequenos detalhes afetam a experiência do usuário. Ele mostra muitos exemplos de Apps e Sites e como o touch e os gestos ajudam ou atrapalham a interação. É um excelente capítulo.

On iPhone, put app controls at screen bottom. On Android, put app controls at screen top. For the Web, favor navigation at page bottom (not screen bottom).

When controls display or affect content, place them below or to the side of that content, never above.

Assume that every screen your website serves is a touch- screen.

Gestures are the keyboard shortcuts of touch.

Conteúdo original do blog sergiolopes.org.

Seu código CSS pode ser mais limpo, flexível e reaproveitável

2013-01-16T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Sempre libere o zoom do usuário em suas páginas mobile

2012-12-30T00:00:00.000Z

Esse post foi atualizado recentemente com mais informações (data de publicação original: 19 Jul 2012).

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.

Se você trabalha com web mobile, conhece a meta tag viewport e sua importância. Com ela, você consegue bloquear o zoom do usuário de algumas formas:

<meta name="viewport" content="width=device-width, user-scalable=no">

<meta name="viewport" content="width=device-width, minimum-scale=1, maximum-scale=1">

Mas, na esmagadora maioria dos casos, você não deveria fazer isso. Exceções talvez sejam webapps com uma ideia de canvas fullscreen onde os gestos são tratados pela aplicação (mapas e jogos talvez). Em sites web normais? Jamais.

Há um mito que circula por aí de que limitar o zoom faz com que nossa página fique mais parecida com uma App. Primeiro: site não é App, então não tente parecer uma. Segundo: se algumas Apps têm essa limitação de não deixar dar zoom, porque copiar essa deficiência pra sua página?

Mas meu iPhone dádava zoom quando deito o aparelho!

Eu acho que o grande culpado da proliferação de páginas com zoom desabilitado é um famoso bug no iOS até a versão 5.x que faz com que a página dê um zoom quando você gira o aparelho em modo paisagem. Se você desabilita o zoom, o bug não acontece. Mas é um jeito covarde de resolver o problema.

O iOS 6 resolve esse bug do Mobile Safari. E como a maioria dos usuários Apple atualiza rapidamente, isso quer dizer que esse bug deve ser coisa do passado em breve.

Mas mesmo que o bug do iOS seja um problema pra você e seus usuários com iOS antes do 6, pense em alguma opção:

Não faça nada. Sim, uma opção é deixar o bug acontecer. Lembre que um usuário de iOS está acostumado a isso, afinal todos os sites do mundo são afetados! E a maioria dos usuários com iOS 6+ está ok.
Se incomodar muito e você quiser tirar o zoom do usuário por causa do bug, pelo menos faça isso apenas no iOS e não limite todos os outros dispositivos do mundo que funcionam direito. Lembre que, principalmente no Brasil, o Android é muito mais usado que o iOS (às vezes, até em audiências mais nerds como nós).
Há hacks em JavaScript que solucionam o problema em 99% dos cenários. O mais famoso é o do Scott Jehl mas há outros - até eu tenho uma solução, baseada em CSS. Veja um comparativo de hacks que resolvem o bug.

Controle na mão do usuário!

Desabilitar o zoom das páginas é tão irritante, mas tão irritante, que os browsers mobile modernos estão deixando esse controle na mão do usuário! O browser do Android 4 e o Chrome Mobile, por exemplo, têm essa opção nas configurações:

O Mobile Safari do iOS infelizmente ainda não tem uma opcão dessas. Também não consegui achar no Opera e no Firefox uma opção semelhante. Uma gambiarra útil pra usuários dessas plataformas, é usar um bookmarklet que reescreva a tag viewport dos sites pra habilitar o zoom sempre:

javascript:document.querySelector('meta[name=viewport]').setAttribute('content','width=device-width,initial-scale=1,maximum-scale=10,user-zoom=yes');

Atualização Dez/2012: coloquei informações sobre o iOS 6 e o bug que não existe mais.

Conteúdo original do blog sergiolopes.org.

Retrospectiva 2012

2012-12-28T00:00:00.000Z

2012 foi o ano de lançamento desse blog e de uma guinada no foco da minha carreira de desenvolvedor. Veja os assuntos que bombaram aqui esse ano, estatísticas e planos pra 2013!

Novo foco em 2012

Escrevi minha primeira linha de código em 1999 e ela foi em HTML. Mas, com o tempo, como boa parte dos programadores, acabei caindo mais em backend. Trabalhar com frontend não era "ser um programador", não era glamuroso.

Mas o HTML5 mudou isso. Web é sexy. Frontend é um cargo de respeito hoje. E, eu que sempre gostei de Web, resolvi que 2012 seria uma mudança na carreira em direção ao frontend.

Lancei esse blog em Março. Dei várias palestras -- e a maior parte sobre frontend. Postei centenas de links sobre frontend no meu twitter e no meu facebook. Fiz opensource e li vários livros de front.

Eu gosto muito de backend e Java -- até lancei um livro. Programo o dia todo, dou aulas, escrevo e palestro sobre isso. Mas em 2012 tive a chance de focar mais em frontend que é o que mais gosto. E o mais legal é o apoio que tive e tenho da Caelum pra essas mudanças.

2012 foi o ano do mobile

No imenso leque da Web, resolvi que 2012 seria o ano de focar em mobile. Falei de design responsivo, outras coisas de mobile web e até emails responsivos.

Codei vários sites responsivos -- como esse blog, o site do livro de arquitetura Java e o novo site da Caelum. Montei meu device lab: comprei 2 iPod Touch, 3 celulares Android; ganhei um Kindle Fire.

Estatísticas do blog em 2012

9 meses de vida
31 mil visitas e 58 mil pageviews
8.8% de visitantes em dispositivos móveis
Orgulhosamente só 3% de visitantes usando IE :-)

2013

Quero continuar meu foco em frontend, em especial nas áreas de mobile web e otimizações.

Quero escrever mais, palestrar mais e ensinar mais sobre Web.

Quero programar mais, experimentar mais, opensourcear mais.

Obrigado por me acompanhar aqui em 2012. Nos vemos em 2013!

Conteúdo original do blog sergiolopes.org.

Tudo que você precisa saber sobre resoluções, telas retina, devicePixelRatio, DPI, CSS pixels e etc

2012-12-06T00:00:00.000Z

Há muita confusão rondando as discussões sobre resoluções de tela, densidade de pixels, usabilidade das telas, áreas útil e coisas relacionadas. Confusão inclusive na mídia especializada.

Um artigo que me despertou para escrever esse post saiu no Gizmodo americano no lançamento do iPad Mini, comparando-o aos concorrentes. O argumento era que a tela de 1024x768 do iPad Mini era pior que a de um Nexus 7 de 1280x800 pois tinha menor área útil disponível para o usuário. Errado!

O Nexus 7 tem resolução tvdpi com devicePixelRatio de ~1.3, o que dá um viewport de 966x603 pixels, equanto o iPad mini tem devicePixelRatio 1, com viewport igual sua resolução, em 1024x768.

Pixel ratio, viewport, CSS pixels, dpi - parece grego? Leia mais.

iPad Mini vs. Nexus 7 vs. Kindle Fire HD

Resoluções e DPIs

Duas medidas são importantes numa tela: o tamanho físico da tela em centímetros -- ou polegadas, como é mais comum -- e sua resolução em pixels. Da divisão desses dois números, temos o DPI -- dots per inch -- que diz quantos pixels existem por polegada de tela.

Conseguimos saber a resolução em pixels da tela em JavaScript com as propriedades window.screen.width e window.screen.height. Mas, com JavaScript, não é possível saber o tamanho físico da tela e nem seu DPI.

O curioso é que o CSS tem algumas unidades para tamanho físico -- você pode criar um div com width 1cm ou 1in. Mas isso não faz o que realmente queremos (um elemento de 1 centímetro ou 1 polegada física). Os navegadores em geral concordaram em um dpi base de 96 e todas as contas são relativas a esse número. Então, se fizer um div de 1 polegada, na verdade você leva um de 96px, não interessando o tamanho físico real da tela ou seu dpi verdadeiro.

Pixel ratio, CSS pixels e telas retina

Telas retina são telas de alta resolução com tantos pixels que eles acabam sendo pequenos fisicamente, tornando difícil o olho identificar um individualmente. Com isso, o conteúdo mostrado ficaria muito pequeno na tela, então a grande novidade é que um pixel de conteúdo é renderizado com mais de um pixel físico. Ãhn?

A ideia é simples: se você desenhar uma linha de 1px na tela (com CSS ou mesmo uma app nativa), ela será renderizada como uma linha de 2px físicos. Isso melhora, e muito, a definição dos elementos na tela. Existe, então, uma razão de multiplicação entre pixels lógicos e pixels físicos. Essa razão é o device pixel ratio, acessível em JS pela propriedade devicePixelRatio e nas media queries CSS de alta resolução.

No mundo Apple, as telas retina têm device pixel ratio 2, o que facilita as contas. No mundo Android, essas mesmas telas são chamadas de xhdpi -- como num Galaxy S3 ou num Nexus 4. Mas, no Android, temos mais possibilidades:

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, Nexus One.
tvdpi - pixel ratio 1.33 - usado só no tablet Nexus 7.
mdpi (medium dpi) - pixel ratio 1 - telas normais, comuns em smartphones simples.
ldpi (low dpi) - 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.

(Curioso notar o ldpi com pixel ratio menor que 1. Nesse caso, o conteúdo é desenhado com menos pixels na tela. Uma linha de 4px no CSS vai ser desenhada com 3 pixels físicos. Esse downscale deixa a renderização visualmente pior, claro.)

É muito comum também falar em CSS pixels ou device independent pixels pra significar as medidas que usamos no código e device pixels pra indicar quantos pixels físicos serão usados na tela. E, claro, número de css pixels × devicePixelRatio = número de device pixels.

O que importa é o tamanho do viewport

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.

Por isso o artigo do Gizmodo que citei antes sobre o iPad mini vs. Nexus 7 estava errado. Embora com resolução física mais alta, o Nexus 7 tem um viewport menor (966x603px contra 1024x768px do iPad Mini). Um usuário que queira ver mais conteúdo na tela, vai preferir o iPad Mini.

Não quer dizer claro, que ter uma tela com alta resolução e com alto pixel ratio seja ruim. Embora o conteúdo fique igual de tamanho nos dois tipos de iPhone, ele fica mais bem definido no retina, claro. Textos e gráficos ficam ótimos. Conteúdos grandes e com zoom out ficam mais definidos -- como uma foto grande ou um vídeo HD ou mesmo um site Desktop visto no celular.

Diferença de viewport em tablets do mesmo tamanho físico (A List Apart)

Devíamos falar de 'DPI de conteúdo'

A confusão maior nisso é que as especificações dos aparelhos e matérias nos sites de tecnologia costumam falar apenas da resolução física do aparelho e não de viewports e pixel ratios. Claro, esses conceitos confundem muita gente, principalmente o usuário final. Mas a contradição é que o viewport é justamente o número mais útil pro usuário, muito mais que saber a resolução física.

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 320px
iPhone retina tem 326 dpi com largura de 640px
Galaxy S tem 233 dpi com largura de 480px
Galaxy Y tem só 133 dpi com largura de 240px

Só vendo esses poucos exemplos, a ideia é que temos telas com resoluções bem diferentes e DPIs diversos.

Mas isso não é verdade se levarmos em conta o viewport, a área real pro conteúdo. Por isso, acho que deveria existir uma métrica de dpi de conteúdo, que mostra a densidade da tela com base na quantidade de conteúdo que ela mostra, em CSS pixels.

Olhando 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 largura
iPhone retina tem 163 dpi de conteúdo com viewport de 320px de largura
Galaxy S tem 155 dpi de conteúdo com viewport de 320px de largura
Galaxy Y tem 177 dpi de conteúdo com viewport de 320px de largura

Pro usuário final, essa medidade de dpi de conteúdo é mais importante que o dpi físico.

Porque um iPad mini tem o mesmo viewport que um iPad normal?

O lançamento do iPad mini trouxe muita discussão sobre sua usabilidade. O Jakob Nielsen declarou que a tela é pequena demais e com problemas de UX. Outros reviews chegaram na mesma conclusão, e até nomes como Luke Wroblewski e Brad Frost entraram nessa discussão.

O problema do iPad Mini é que ele tem a mesma resolução de 1024x768 do iPad normal mas em uma tela 27% menor fisicamente. Pior, seu device pixel ratio é 1, o que faz com que o viewport final seja também de 1024x768. Na prática, todas as coisas do iPad abrem 27% menores em tamanho, tornando os botões mais difíceis de clicar, os textos menores pra ler e etc.

Muita gente se pergunta em como a Apple chegou no tamanho de 7.9 polegadas do iPad Mini. Esse número não é aleatório. Com 7.9, o iPad mini tem o mesmo dpi de conteúdo dos iPhones. Ou seja, vai renderizar tudo do mesmo tamanho físico que um iPhone faz. Veja as contas:

iPhone não-retina (320x480) tem 162.98)%2F2) dpi de conteúdo numa tela de 3.5'' com pixel ratio 1
iPhone retina (640x960) tem 162.98)%2F2) dpi de conteúdo numa tela de 3.5'' com pixel ratio 2
iPad mini (1024x768) tem 162.02)) dpi de conteúdo numa tela de 7.9'' com pixel ratio 1
iPad 4 retina (2048x1536) tem 132 dpi de conteúdo numa tela de 9.7'' com pixel ratio 2

Olhando essa lista, percebemos que o estranho é o iPad normal, com um dpi bem mais baixo. As coisas ficam maiores fisicamente no iPad normal, o que é bom já que um tablet grande costuma ser usado a uma distância maior do usuário (apoiado na mesa, no colo etc).

Na prática, o que a Apple está dizendo é que o iPad mini foi feito para ser usado na mesma distância que você usa o iPhone, e não como você usa o iPad normal.

iPad Mini vs. iPad

Quantos pixels minha tela deveria ter?

A questão aqui é de usabilidade. Pixels pequenos demais tornam a leitura do usuário mais difícil, que é grande crítica dos analistas ao iPad mini. Você precisa usar o aparelho mais perto do rosto, o que pode não ser muito natural.

O W3C tem uma medida oficial pra determinar o tamanho de um pixel de conteúdo na tela, o que eles chama de pixel de referência. Ele é medido em ângulos, claro. Um pixel num celular que usamos perto do olho tem comprimento menor que um pixel numa televisão que vemos a metros de distância. Para analisar se um pixel está do "tamanho certo", é preciso saber a distância do usuário em relação à tela.

Tamanho de um pixel de referência (W3C)

O tamanho oficial do pixel de referência é de 0.0213 graus. Deixando a matemática um pouco de lado, isso quer dizer que:

Um iPhone foi projetado para ser visto a uma distância de 41.9cm)+inches) do olho.
O iPad, é melhor visto a uma distância de 51.7cm)+inches).
Já o iPad Mini, é pra ser usado como um iPhone, a 42.1cm)+inches) de distância.

Celulares Android são os que trazem a maior variação nos DPIs. Muitos trazem telas grandes fisicamente mas com dpis de conteúdo dos mais variados.

Um Galaxy S3 tem 360x640 de viewport numa tela de 4.8''. É melhor usado a 44.6cm)+inches) de distância.
Já um Galaxy Note 2 tem uma tela de 5.5'' com a mesma resolução física e mesmo viewport -- 360x640 -- do S3. Ou seja, é um aparelho pensado para ser usado a uma distância maior, de 51.17cm)+inches), como um iPad, apoiado na mesa por exemplo.

E, claro, toda essa usabilidade depende de usuário para usuário. Depende de como você pretende usar aparelho e da qualidade da sua visão. O tamanho do pixel de referência é calculado pensando na resolução média do olho humano. E existe toda uma matemática interessantíssima sobre a ótica do olho humano pra se calcular isso.

Por exemplo: a 30cm de distância, a percepção máxima do nosso olho é, em média, de 286dpi. Qualquer coisa acima disso, e a maioria das pessoas não conseguirá distinguir os pixels individualmente. Por isso, a tela de 326dpi do iPhone retina é bastante definida pra gente. Mas o olho humano consegue atingir resolução máxima de 477dpi em quem tem visão perfeita; nesse caso, um celular FullHD de 441dpi como Droid DNA pode ser melhor.

Mais sobre pixels, DPIs e cia

Pixels, pixels ou pixels? Dicas de Web Mobile com viewport, artigo meu no Blog da Caelum.
The CSS physical unit problem, do QuirksMode.
Seven, sobre a diferença nos viewports nos tablets de 7 polegadas, do Andy Clarke.
Apple "Retina Display" in iPhone 4: a Vision Scientist Perspective
A pixel is not a pixel is not a pixel, do QuirksMode.
A Pixel Identity Crisis, A List Apart.

Conteúdo original do blog sergiolopes.org.

Front in Sampa 2012: Design Responsivo, testes A/B, Web Mobile, WebGL, Acessibilidade, SEO e carreira

2012-11-06T00:00:00.000Z

Em 3 de Novembro, tivemos o Front in Sampa 2012. Um excelente evento da comunidade front-end de São Paulo onde tive o prazer de participar como palestrante e espectador. Nesse post, minhas impressões do evento, slides, palestras e links pros tópicos discutidos por todos os palestrantes.

O evento

Foi no Hotel Intercontinental, na Alameda Santos, um super espaço. A sala era bem confortável, com cadeiras e mesas para todos, réguas de tomada por todo lado e excelente infraestrutura. Faltou o Wi-Fi, mas todo mundo hoje em dia tem 3G, então nem fez falta. O coffee break foi um pouco fraco.

A organização foi impecável. Impressionante o que os organizadores conseguiram fazer em um primeiro evento. Registro aqui meus parabéns!

Foram 7 palestras e uma mesa redonda no final. Ficam aqui as minhas impressões de cada uma.

Responsive Design: Por quê e para quê utilizar um framework? Por Fernando Monteiro

O Fernando fez uns slides bem bacanas sobre design responsivo. Eles têm bastante informação, tornando fácil acompanhar de casa. Pra hora da palestra, os slides muito densos acabaram atrapalhando e o tempo ficou curto.

Se você quiser saber mais sobre o tema, recomendo meu artigo sobre design responsivo aqui no blog. Com relação a usar frameworks, sou da opinião contrária: acho que frameworks CSS com breakpoints fixos e grids responsivos só atrapalham.

Auditório cheio no hotel Intercontinental

Como manter um Front-End produtivo e eficiente em testes AB e Personalização. Por Mauricio Wolff

Umas das melhores palestras do evento. O Mauricio trabalha na Dell no time de testes A/B e targeting, e contou a experiência deles nessa área. O site da Dell é visto em 176 versões diferentes, de países e línguas, com mais de 200 mil visitantes por hora. E eles rodam diversos testes A/B ao mesmo tempo, criados pela equipe de marketing.

Ele falou bastante na palestra sobre o processo da Dell, sobre Agile e como manter código limpo e organizado. Dos testes A/B em si, ele falou da importância de se obter um resultado com significância estatística e citou que, na Dell, isso exige geralmente 2 semanas de tráfego. Por lá, os testes costumam rodar de 4 a 6 semanas. Outro truque que ele falou que também gosto é de rodar o teste com dois controles, pra ver se os resultados convergem.

Eu ando meio frustrado com testes A/B ultimamente por não trabalhar em um site com volume de acessos grande como o da Dell. Meus testes dificilmente obtém a significância estatística necessária. Essa palestra me deixou ainda mais relutante com relação a meus testes pequenos.

Truques de Web Mobile. Por Sérgio Lopes

Na sequência, veio minha palestra sobre Web Mobile. Aliás, foi uma oportunidade pra eu atualizar os slides aqui no blog com correções e atualizações - em especial, sobre o novo Internet Explorer 10.

O pessoal foi bastante receptivo no twitter e em conversas depois do evento, então acho que foi boa. Foi muito bom participar do Front in Sampa e agradeço o convite da organização do evento.

Você pode seguir minha palestra de web mobile aqui no blog com slides, textos explicativos e demos dos slides pra acompanhar no celular/tablet.

Palestrantes do Front in Sampa 2012

WebGL, Three.js e tQuery. Por Kaique da Silva

Pra fechar a manhã do evento, o Kaique apresentou o Web GL de maneira bastante produtiva com o Three.js e o tQuery - que eu não conhecia.

Embora essa área de 3D no browser não seja minha praia, achei bem interessante o tQuery, pareceu bem fácil de usar. O Kaique fez um post depois do evento com mais informações sobre o tQuery e WebGL.

Acessibilidade Web, por Horácio Soares e Clécio Bachini

Sem dúvidas, a melhor palestra do evento. O Horácio e o Clécio falaram de acessibilidade, leis e acordos internacionais que eu nem conhecia, tipos de usabilidade e mais. Depois, fizeram uma análise completa no novo site do Itaú que tem sérios problemas de usabilidade. Alguns destaques de melhorias possíveis:

Sempre usar ALT nas imagens.
Usar headings semânticos pro usuário navegar. Criae h1, h2, h3 etc, pensando nos filhos com relação à conteudo.
Performance ruim com imagens gigantes e dezenas de arquivos JS;
Permitir navegação pelo teclado.
Usar landmarks ARIA.
Não fazer links com "saiba mais" ou "clique aqui". Ruim pra SEO e ruim pra navegar via TABs.
Não recriar elementos, como um combobox, que deveria ser um select sempre, ou botão feito com div.
Usar labels nos campos, e não fazer placeholder com value.
Na home, não colocar link de volta pra home (como no logo no topo).
Aumentar o contraste de cor entre elementos. Usar fontes maiores.
Elementos de navegação, como menu, não podem parecer um banner.
Nunca usar TITLE nas imagens, só ALT. (nem pra SEO serve)
Não abrir janelas externas nos links.
Colocar uma boa descrição nos links que fazem coisas inesperadas (download de arquivo, sair do site etc).

Você pode ver também os slides da palestra de front-end com acessibilidade.

Palestra de Usabilidade com Horácio Soares e Clécio Bachini

SEO para front-end. Por Fábio Ricotta

O Fábio é um excelente palestrante, bastante famoso por causa da MestreSEO. A palestra foi muito boa e dinâmica mas, pra mim pelo menos, sem muitas novidades.

Ele falou de 10 tópicos básicos de SEO que um programador front-end precisa se preocupar: colocar title na página; colocar alt nas imagens; usar URLs amigáveis; otimizar o tempo de carregamento; usar rich snippets; usar rel=author com perfil do Google+; submeter um sitemap; evitar Flash e Ajax.

Achei interessante ele falar sobre performance web como fator de SEO. O Googe fala disso há 3 anos, mas eu não imaginava que já fosse um fator tão significativo. Os slides da palestra de SEO para front-end estão disponíveis.

Palestra de SEO com Fábio Ricotta

Biografia do Zeno Rocha e do Bernard de Luna

O Zeno e o Bernard fizeram uma palestra-show sem tema definido, mas que tratou de contar a história da carreira dos dois. Eles mostraram projetos que fizeram, principalmente open source, e mostrarm o impacto que isso teve no sucesso profissional deles.

Advogaram contra o pessoal que faz freelas, o que foi bastante polêmico e gerou muita controvérsia. Falaram bastante de você reservar um tempo para brincar com novas tecnologias, fazer projetos, se divertir. No fim, fizeram um demo com música usando a Audio API.

7 Masters: debate sobre front-end, Mercado, Desenvolvimento e Tendências

Fotos oficiais do evento que você encontra no Facebook deles.

Conteúdo original do blog sergiolopes.org.

Review do livro "Web Design Responsivo" do Tárcio Zemel

2012-10-22T00:00:00.000Z

Primeiro livro em português sobre Web Design Responsivo é uma excelente forma de começar nessa área que só cresce.

Acompanho o mercado de design responsivo há algum tempo, e escrevo bastante sobre ele. Mas sabemos que a maior parte do conteúdo e do conhecimento ainda está em inglês. Por isso que, quando ouvi que o Tárcio Zemel estava pensando em um livro em português sobre o assunto, me interessei logo de cara.

O livro acabou de sair, editado pela Casa do Código, nova editora nacional com foco em livros de TI, ebooks, preços competitivos e grandes nomes do mercado brasileiro. Tive o prazer de participar do projeto com o Tárcio, ajudando na revisão do livro ainda em beta, e com o prefácio.

"Livro 'Web Design Responsivo: Páginas adaptáveis para todos os dispositivos' de Tárcio Zemel."

Recomendo o livro para todos os Web Designers brasileiros que querem começar nessa área de design responsivo e web móvel -- e, aliás, recomendo que todos entrem nesse área o quanto antes, pois é o futuro. O livro é bastante inspirado nas ideias do Ethan Marcotte mas traz uma abordagem mais atualizada, além, claro, de ser em português.

Um bom complemento a esse livro do Tárcio é meu novo livro A Web Mobile: programe para um mundo de muitos dispositivos, também da editora Casa do Código.

O livro Web Design Responsivo: Páginas adaptáveis para todos os dispositivos está disponível diretamente na editora Casa do Código em ebook -- PDF, mobi, epub -- por R$ 30, em versão impressa por R$ 60, ou o combo por R$ 70.

A seguir o prefácio que escrevi para o livro:

Prefácio

A era pós-PC da computação pessoal chegou com tudo. Nos tablets e smartphones, a Web, finalmente, tem a chance de se tornar verdadeiramente ubíqua e onipresente. Ainda estamos no começo dessa nova fase da tecnologia, mas o futuro é inegavelmente da Web móvel e dos mais diversos aparelhos de navegação.

Essa nova perspectiva traz desafios importantes. Até ontem, Web significava um navegador instalado num Desktop controlado por mouse e teclado numa tela de tamanho confortável. Nossos sites foram construídos pensando nesse cenário. Mas, agora, temos telas pequenas, touch screen, redes móveis e muitas outras diferenças. Precisamos de uma nova Web. Uma Web que suporte essa explosão de dispositivos e, mais ainda, esteja preparada para o futuro de dispositivos que ainda nem conseguimos antever.

O Web Design Responsivo é a chave para essa nova Web. É pensar em páginas que se adaptem a todo tipo de dispositivo e contexto de uso. É sair das limitações de um browser Desktop e seu tamanho previsível, e pensar em páginas com flexibilidade que suportem todo tamanho de tela, qualquer tipo de resolução, interfaces com touch ou mouse. Pensar responsivamente é repensar a Web para o futuro.

Este livro é a ferramenta que você precisa pra entender os desafios do Web Design Responsivo. O Tárcio mostra os pilares de uma interface responsiva, explora os aspectos técnicos do HTML e CSS, e mostra ideias para uma interface móvel usável. É um livro que recomendo para todo desenvolvedor Web que queira participar ativamente da nova Web. Espero que você aproveite a leitura como eu aproveitei.

E, quando terminar a leitura, não deixe de conferir também meu livro A Web Mobile, onde aprofundo em vários outros temas relacionados a dispositivos móveis e sites responsivos.

-- Sérgio Lopes - Instrutor e desenvolvedor na Caelum

Conteúdo original do blog sergiolopes.org.

Review do livro "Retinafy your web sites & apps" do Thomas Fuchs

2012-10-10T00:00:00.000Z

É capaz de você estar fazendo a mesma pergunta que me fiz antes de ler esse livro: sério, um livro só sobre como lidar com telas retina na Web? Sim, e o livro é fantástico.

O Retinafy.me é um ebook curto, um PDF -- sem DRM -- de apenas 60 páginas. É publicado diretamente pelo autor, o Thomas Fuchs, e tem um preço meio salgado -- 29 dólares. Mas tem dicas fenomenais sobre como lidar com telas de alta resolução, tão comuns em tablets e celulares, e que agora começam a chegar aos notebooks e desktops. Valeu cada centavo (ok, comprei no beta ainda, por 19 dólares, mas ainda é um valor alto).

O livro é bastante direto e prático, curto e grosso com as dicas de imagens, CSS, HTML e JS pra você suportar telas retina. É fruto do muito estudo feito pelo Thomas e apresenta as conclusões dele pra que você não precise pesquisar tudo de novo por conta própria. E o Thomas não é um cara qualquer; é o autor do Zepto.js, do script.aculo.us, commiter do Rails e de mais um monte de coisa importante.

"Livro Retinafy Web Sites and Apps de Thomas Fuchs."

JPEG gigante com qualidade baixa

Pra mim, o maior insight desse livro é a ideia de usar um JPEG gigante com qualidade mais baixa. Como os pixels em telas retina são muito pequenos, a qualidade visual fica boa. E, nas telas normais, o downscale do browser faz a diferença de qualidade ficar imperceptível. É uma sacada genial. No fim, em muitos casos, o arquivo JPEG fica até com tamanho menor -- um JPEG com o dobro de largura mas qualidade 30 em geral é menor que um JPEG com metade da largura e qualidade 80.

No livro, ele mostra vários exemplos. E, depois do livro, mais gente está falando dessa técnica com ainda mais exemplos comprovando a eficiência da técnica.

Retina first e sem malabarismos

No livro, o autor defende a ideia de criarmos sites retina desde já. No futuro, só teremos displays retina, e é bom estar preparado. Isso significa criar as imagens @2x pra tudo no site que não for vetorizável -- texto, CSS3, icon fonts e SVG. E, para o autor, na maioria das vezes, você não precisa do trabalho de criar uma versão @1x e do monte de CSS e gambiarras de JavaScript para trocá-las.

Eu concordo completamente com essa técnica. Meu fluxo hoje de desenvolvimento pensando em mobile e telas retina é de migrar o máximo possível pra CSS3 e icon fonts, depois usar SVG, e por último um JPG, PNG ou GIF já exportado com dobro de resolução. Aí uso o background-size pra adaptar a imagem no CSS e pronto. Não crio várias versões do mesmo arquivo.

A principal preocupação costuma ser performance, já que o arquivo vai ter o quádruplo de pixels -- e quem me segue sabe que sou bem preocupado com performance. Para fotos JPG, a técnica anterior de diminuir a qualidade é fantástica e eficiente. Para PNGs e gráficos, em geral, a diferença de tamanho não é significativa. E, mesmo que tenha uns KBs a mais, sou da opinião de que o maior gargalo de rede hoje quando falamos de Web é a latência de rede, e não tanto a banda.

Meu único receio de performance é com relação ao uso de memória do browser, que aumenta. De qualquer forma, tudo isso é melhor, mesmo, que usar bibliotecas JavaScript pra ficar trocando imagens. Essa bibliotecas são péssimas pra performance e grandes gambiarras.

Citações do livro

Na minha leitura, separei algumas citações de pontos que me marcaram. Mas, lembre, há muito mais no livro, com códigos, exemplos práticos, dicas etc.

Always target high-density displays by default, don’t make it an afterthought.

For many types of graphics you can just provide a single image—the "retina" version, and rely on the browser to scale down a larger image.

Some images might require special casing, for example an icon or small text rendered on a user interface element might get blurry at smaller sizes.

[To support two image variants] don’t use tags directly, but instead just use
elements with a background image and "background-size" property of "100%".

For [JPEG] content images, double the resolution but lower the quality. Don’t bother with two versions.

It’s better to think "retina-first", and assume you’re running on a retina screen and make exceptions or adaptions for "normal" screens, as high-density displays will soon be the norm rather than a special thing (and they are the norm on mobile devices already!).

Don’t use JavaScript "retina" helper libraries.

Conteúdo original do blog sergiolopes.org.

WebSockets HTML5 em Java com Jetty: Web em tempo real

2012-08-23T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

QCon SP 2012: anotações da palestra 'HTML5 Offline & Storage' do Gabriel Oliveira

2012-08-20T00:00:00.000Z

Gabriel Oliveira (twitter), da Caelum, palestrou na track de Front End do evento QCon SP 2012 sobre técnicas de offline storage com o título HTML5 Offline & Storage: soluções para um mundo sem conexão permanente (slides).

"Palestra do Gabriel Oliveira no QCon SP 2012"

Minhas anotações

Web é plataforma pra aplicações distribuídas
Normal: fazer cache de componentes com Expires no HTTP cache
Mas sem HTTP, sem cache HTTP. Não da pra fazer verificação sem ter rede.
Offline Storage
- Armazenar no cliente mas permite obter os dados sem conexão ativa
- Caso util em mobile webapps, ou hibridas
- evita full http roundtrips
- menor consumo de banda
HTML5 AppCache (Offline)
- quais recursos devem ser armazenados
- quais não devem ser armazenados. coisas que so funcionam com conexao
- ou recursos alternativos caso esteja offline
Um arquivo manifest texto plano com CACHE MANIFEST
posso fazer cache de coisas relativas e outros dominios
cuidado com param da URL que o cache considera recursos diferentes
cuidado com mime type correto senão ele ignora o cache
Algum recurso devolveu 404? Nada vai para o cache!
O offline cache traz todos os recursos de uma vez, mesmo que não use no momento
Mudar o manifest indica pro navegador que um novo cache precisa ser construído
- Faça isso com JavaScript: applicationCache.onupdateready
- Mostre uma mensagem pro usuário recarregar a página
Não deixe o navegador fazer HTTP cache do Manifest, senão não consigo fazer mais updates
Eventos de online e offline
- evento que dispara quando muda o status da conexão window.ononline ou onoffline
- faz sincronizacao no online por exemplo
localStorage
- dados no cliente, como cookies, mas sem limitações
- nao sao enviados pro server, como cookies
- key value, dados nao estruturados
- same origin restrito
usuário pode descartar dados indo nas configs do browser
sessionStorage é igual o local mas só na sessão atual (fechar browser; em alguns, so fechar aba)
IndexedDB
- dados estruturados
- assincrono e transacional
- schemaless nosql
criamos um object store (tipo tabela)
insere objetos JS
posso juntar com offline. usar indexeddb pra salvar coisas locais e depois sincronizar.
- cuidado so com monte de coisa assincrona junta (indexeddb, ajax)
No mobile, pessoal prefere WebSQL que é mais leve.
Limitações de espaço:
- appcache: indeterminado mas se recomenda no maximo 10% do espaco em disco
- localStorage e session: 5MB minimo
- IndexedDB: Indeterminado

Meus comentários

As soluções para offline melhoraram muito com o HTML5. E isso é essencial para o mundo mobile dos smartphones e tablets que nem sempre têm conexão disponível. Eu mesmo, na minha palestra do QCon fiz os participantes abrirem umas demonstrações no celular, e usei HTML5 offline pra evitar problemas com intermitência de rede durante a palestra.

Ainda acho o o AppCache um tanto obscuro e complicado. Ele é muito voltado pra WebApps single-page cheias de JS. Infelizmente não é uma solução fácil de se aplicar na Web em geral. E me incomoda o fato de não ter uma forma de habilitar ou desabilitar o offline de acordo com desejo do usuário - imagine o usuário lendo uma notícia e apertando um botão "salvar offline".

A palestra em si foi muito boa e preencheu alguns buracos no meu conhecimento sobre essas tecnologias. Recomendo ver os slides pra acompanhar os códigos mostrados.

Outras palestras da track de Front End do QCon SP 2012

Tem a minha palestra sobre mobile web, incluindo slides, anotações, referências e demos. O evento teve muitas palestras de vários temas. Anotei aqui apenas as da trilha de Front End que assisti:

Reponsive Design e a Ubiquidade da Web, com Eduardo Shiota
Modular CSS: projetando CSS para aplicativos, com Bernard De Luna
Mitos do Front end, com Zeno Rocha

Conteúdo original do blog sergiolopes.org.

QCon SP 2012: anotações da palestra 'Responsive Web Design: conteúdo em todos devices' do Eduardo Shiota

2012-08-20T00:00:00.000Z

Eduardo Shiota (blog, twitter) palestrou na track de Front End do evento QCon SP 2012 sobre Responsive Design (slides).

"Palestra do Eduardo Shiota no QCon SP 2012"

Minhas anotações

A Web em 1996 (ex. home do UOL na época) era sem muitas práticas de design.
Mas design existe há centenas de anos, com grids, espaçamento, harmonia etc em impressos.
Designer grafico sabe fazer design. Mas e na Web?
A web começou a evoluir nas práticas de design a partir de 2000/2002. Mas o código ainda era ruim (table, font)
Assim surgiu o CSS, com a separação semântica das tags e apresentação (ex. css zen garden)
Passamos na Web e Frontend com diversos ciclos de melhoria, a próxima leva é o Mobile.
- HTML > Print > Table > Tableless > Standards > Mobile

Mobile aumenta o range de idades e tipos de pessoas acessando web e tecnologia
Gama de dispositivos é gigantesca. Até Kindle e-ink acessa web.
Fala-se muito de Apps, Appstore, mas isso limita o alcance. Muitas combinacoes de telas, dispositvos, hardware etc.
O proximo passo do futuro da Web é Responsive Web Design
Solução agnóstica à plataforma. Todo dispositivo acessa a web.
Exemplo: entrada do UOL hoje.
- No Desktop fica bom
- Num iPad começa a ficar meio complicado
- Num iPhone, abre a página mobile.
- Problema: mandar links da versão mobile e amigo abrir no Desktop, ele vai ver versão mobile
- Temos aqui 2 aplicações com o mesmo propósito. Retrabalho
Exemplo: Boston Globe
- Responsável foi o Ethan Marcotte, pai do Responsive Design
- Mesma página, adaptada pra todo tipo de resolução desde Desktop até smartphones pequenos.

Com CSS, JS, técnica e planejamento conseguimos uma versão que funcione em todas as páginas.
Como fazer responsivo? 3 partes
- Design flexivel
- Media Queries
- Ajusts e plugins
Design flexivel
- Tipografia, grid e conteudo
- Golden rule: target/contexto=dimensão
- usar em sempre
Coloque font-size:100% sempre no body. 16px na maioria dos browsers
- Se o usuário mudou, todo o layout se adapta.
- Seta line-height unitless pra ser proporcional ao font-size.
Fazer as contas da golden rule e vai dar uns numeros bizarros. Mas muita gente tem partido pra design no browser ao inves do Photoshop. Ai usa valores mais redondos.
Coloque num comentario a conta que foi feita pra chegar no valor em.

Grids: mesma coisa, fazer tudo proporcionalmente, com porcentagens.
Coloque max-width:100% nos componentes: img, embed, object, video
Shiota recomenda box-sizing:border-box também.
Plugin FitVids pra videos e iframes redimensionarem e plugin FitText pra ajustar texto responsivo de título.
Media queries: começou com @media print lá atrás e hoje tem muitos outros
2 jeitos de usar:
- ou direto no CSS: @media (max-width: 320px) { }
Device pixel ratio: razão de pixels virtuais com relação a pixels físicos
Numa tela retina, cada 1x1 pixel virtual é 2x2 pixel fisico
A imagem pro retina vai ser o dobro de tamanho em cada dimensão
- colocamos numa media querie min-device-pixel-ratio:2
- Usa background-size: 50% 50% pra escalar os pixels virtuais em 0.5
Responsive Images
- carregas imagens diferentes pra cada breakpoint
- Shiota recomenda o polyfill de feita pelo Scott Jehl: picturefill
- há outros plugins JavaScript, outros com servidor, outros misturados
Mas nada disso funciona antes do IE9
- há plugins como Respond.js. mas só tem max/min-width/height
- há o css3-mediaqueries.js

Meus comentários

Quem acompanha o blog sabe que sou praticante do design responsivo então essa palestra do Shiota me interessou bastante. Foi uma boa apresentação para introduzir o tema pra quem ainda não conhecia.

Em particular, gostei bastante de ver como pensamos parecido em temas polêmicos, como usar box-sizing:border-box, preferir ems sempre e fazer breakpoints nas media queries de acordo com o design e não com dispositivos específicos.

Pra mim, um ponto interessante foi a timeline da história do design na web que ele apresentou no início. Em especial, a conclusão sobre como as coisas evoluíram nos últimos tempos: HTML > Print > Table > Tableless > Standards > Mobile.

Outras palestras da track de Front End do QCon SP 2012

Tem a minha palestra sobre mobile web, incluindo slides, anotações, referências e demos. O evento teve muitas palestras de vários temas. Anotei aqui apenas as da trilha de Front End que assisti:

Modular CSS: projetando CSS para aplicativos, com Bernard De Luna
HTML5 Offline & Storage: Soluções para um mundo sem conexão permanente, com Gabriel Oliveira
Mitos do Front end, com Zeno Rocha

Conteúdo original do blog sergiolopes.org.

QCon SP 2012: anotações da palestra 'Modular CSS: projetando CSS para aplicativos' do Bernard De Luna

2012-08-20T00:00:00.000Z

Bernard De Luna (blog, twitter), da MeltDSP, palestrou palestrou na track de Front End do evento QCon SP 2012 sobre boas práticas de CSS e modularidade com o título Modular CSS: projetando CSS para aplicativos (slides).

Minhas anotações

Muitos projetos são focados no visual, e produção linear, página a página. Mas é ruim. Refazemos muitas coisas.
Designer projeta a interface. Se ele fizer de forma modular, já facilitaria tudo.
Mas precisamos entender que Site é diferente de App.
Site tem foco em: estilo, diagração, primeiro impacto.
App tem foco em: estilo, funcionalidades, condução do usuário (tour ou wizard)
Frameworks de grids fixos são feios.
- Misturam HTML e CSS. (tipo class .grid-4-12)
- Manutenção dolorosa
- Orienta o design e não o contrário.
Primeiro pensamento modular é pensar em centralização, pra mudanças afetarem um lugar só
Facilitamos com o Semantic.gs ou SASS, LESS, Stylus. Mas gera dependência.
Mas cuidado com buscar velocidade ao extremo, senão voltamos a um Fireworks da vida.
Crie seu proprio framework: faça seus padrões, com seus ajustes.
Evite utilizar herança
- Prefira '.widget-tt' a '.widget h2'
- Use classes independentes.
- Evite dependência do pai.
- Facilita reutilização.
Evite usar IDs pra estilização: class ainda é performatica mas ajuda a reutilizar.
Foque na função e não no estilo ou conteúdo: pense em mudanças futuras.
Dicas de reutilizacao:
- Classes globais
- Testar em outro local, outro contexto
- Testar variações
- Documentação.
Fazer um guia de estilo. Uma documentacao com os componentes/widgets exibidos num lugar só.
Exemplo: botão com class .b e um botao especial com .b-pri ou .b-small.
- Usa o prefixo igual pra ficar claro
Num sistema, gastamos bastante tempo na formatacao de form e table: crie ou use um mini framework reaproveitável.
DRY CSS: modularizado, facilmente integrado, mas é vinculado ao estilo, vinculado ao ID, id em letra maiúscula!
OOCSS:
- separação de estrutura e estilo, container e conteudo
- criacao de elementos globais
- mas é muito dificil de aprender
- existe um framework (ruim) com mesmo nome da técnica.
SMACSS:
- robusto
- categorização em módulos: base, layout, modules, states e theme.
- modulos independentes
- mas é muito engessado
- projeto não está aberto (precisa comprar o livro ou workshop).
BEM (block element modifier)
- modulos independentes completamente (nao so css, todo html, )
- muito complexo, nomenclatura falha (menu__item_state)
LESS / SASS
- uso de variaveis pra cores, espaçamentos, estilos.
- mas usar preprocessador foge dos padrões, gera dependência e não é CSS.
Crie um arquivo externo
- 'Standards' sempre atualizado com elementos que se repetem
Modularizacao em mini classes: .pao.maionese.tomate.hamburguer
Envolva sua equipe no processo de padronização senao não ha comprometimento da equipe
Prototipe
Crie caixas e containers pra deixar o conteudo mais alteravel

Meus comentários

Excelente palestra do Bernard. É uma das poucas pessoas que conheço que consegue falar com propriedade de arquitetura de CSS e apontas aspectos positivos e negativos não triviais. As dicas de modularização de se trabalhar com várias classes pequenas e independentes são muito boas.

Apenas discordei do pé atrás que ele tem com pré-processadores. Pra mim pelo menos, tem sido ótimo usá-los. Claro que é uma dependência a mais no projeto, mas já temos tantas outras com tantos outros frameworks que não vejo tanto problema assim. Uma estratégia que uso é incluir o pré-processamento já no script de build do projeto, assim tudo fica fácil de usar por todos os desenvolvedores envolvidos. Evito envolver dependência de ferramentas gráficas pra fazer essa compilação.

Por último, achei interessantíssima a comparação das técnicas de CSS que se fala tanto - como DRY, SMACSS, OOCSS e BEM. Conheço várias delas, mas confesso que nunca me aprofundei em nenhuma. Sempre achei um tanto overkill. E depois da metralhada que o Bernard deu na palestra, duvido que vá me interessar por alguma dessas técnicas. O legal é que ele criticou apontando exatamente o problema de cada uma.

Outras palestras da track de Front End do QCon SP 2012

Tem a minha palestra sobre mobile web, incluindo slides, anotações, referências e demos. O evento teve muitas palestras de vários temas. Anotei aqui apenas as da trilha de Front End que assisti:

Reponsive Design e a Ubiquidade da Web, com Eduardo Shiota
HTML5 Offline & Storage: Soluções para um mundo sem conexão permanente, com Gabriel Oliveira
Mitos do Front end, com Zeno Rocha

Conteúdo original do blog sergiolopes.org.

QCon SP 2012: anotações da palestra 'Mitos do Front end' do Zeno Rocha

2012-08-20T00:00:00.000Z

Zeno Rocha (blog, twitter), da Liferay, palestrou na track de Front End do evento QCon SP 2012 sobre vários Mitos do front end (slides).

Minhas anotações

Backend costuma ver frontend como fácil, mas não é verdade
- Mas CSS3 permite muita coisa avançada e complexa
"CSS é muito repetitivo"
- Use pre processadores
- E ainda tem o CSS4 com variáveis, por exemplo
"CSS Sprites são difíceis de manter"
- Compass generator
"Java == JavaScript"
"JS é ruim e cheio de bugs"
- [] + [] = ""
- {} + {}
- [] + {}
- ha explicacoes pras inconsistencias
Mas ha novidades no EcmaScript 6
- "use strict"
"JavaScript não é bem documentado"
- Acesse a MDN e não w3schools
"JS nao eh nada modular"
- require.js, head.js, backbone.js, YUI
- facilitam organizacao do codigo
"Código não é consistente"
- por exemplo, sem padronizacao de codigo CSS e JS
"Sem comunidade"
- linguagem mais usada no github
- muitos eventos
"Código de qualquer jeito"
- use CSS Lint, JS Lint se quiser regras
"Codigo nao eh testado"
- da pra fazer TDD com jasmin
- QUnit
"Preciso do browser pra rodar testes"
- zombie.js
- phantom.js é um browser webkit headless
"preciso de linguagens nativas pra apps"
- appceletator, phonegap, webapp
- ou nem empacota, faz só css e html: Firefox OS
"HTML5 é o futuro"
- html é hoje, browsers ja suportam
- e html5 ~ HTML + CSS3 + APIS JS
- old radio, wormz = HTML5
- WebGL
"HTML5 nao funciona no IE"
- semantica ha polyfill com shiv
- CSS3 tem CSS3 Pie
- ha muitos polyfill no site do Modernizr
- mas realmente precisamos que tudo rode igual em todo browser?
- a guerra dos browser ainda nao acabou
- "Salve a Web"
Design sem conteudo é só decoracao. Principal é o conteudo.
- navegador antigo é tipo TV preto e branco
- e a TV ja resolveu isso, melhorando o sinal pra TVs mais modernas
"HTML5 vai matar o Flash"
- Occupy Flash é babaquice
- sucesso da aplicacao nao é a tecnologia

Meus comentários

Palestra divertida do Zeno com ótimos slides. É um tema que pra gente que está há mais tempo no frontend não tem muita novidade. Mas foi uma palestra essencial pro público-alvo do QCon, que tem muitos arquitetos e pessoal de infra.

O Zeno mostrou vários preconceitos e mitos que envolvem o crescente mundo do frontend e esclareceu vários pontos. Foi uma palestra muito bem avaliada no evento, o que mostra que aquele público precisava mesmo ouvir o recado do que significa desenvolver frontend hoje em dia.

Outras palestras da track de Front End do QCon SP 2012

Tem a minha palestra sobre mobile web, incluindo slides, anotações, referências e demos. O evento teve muitas palestras de vários temas. Anotei aqui apenas as da trilha de Front End que assisti:

Reponsive Design e a Ubiquidade da Web, com Eduardo Shiota
Modular CSS: projetando CSS para aplicativos, com Bernard De Luna
HTML5 Offline & Storage: Soluções para um mundo sem conexão permanente, com Gabriel Oliveira

Conteúdo original do blog sergiolopes.org.

Não use jQuery no seu site mobile: conheça o Zepto.JS

2012-07-31T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Screencast com análise de performance web do datafilme.com.br

2012-07-27T00:00:00.000Z

Na palestra que dei no Front in BH 2012 sobre otimizações web lancei um desafio: quem quisesse se aprofundar no assunto podia me mandar seu site que eu ia escolher um pra analisar publicamente aqui no blog. Esse post é uma análise de aspectos de performance do site DataFilme.com.br.

O site foi desenvolvido pelo pessoal da Bind Solution e o pedido para analisá-lo veio do Riderman Barbosa. Escolhi o site deles porque já está muito bem feito. Muitas das otimizações já foram implementadas -- gzip, minificação, css no topo, js embaixo, sprites, juntar arquivos etc. Isso deu abertura pra observar e discutir otimizações menos triviais, como carregamento assíncrono e quantização de PNGs.

E este é também o primeiro screencast aqui no Blog. Pensei que um vídeo iria me ajudar a mostrar melhor o processo de análise e as dicas, ao invés de só escrever um texto. Mas como é o primeiro vídeo que gravo, vou botar um selo de beta aqui pra você não esperar um super vídeo profissional.

O que achou? Acesse o site do DataFilme.com.br também e veja o que mais melhoraria. E estou pensando em fazer mais análises como essas aqui no Blog, com sites indicados por leitores. Acha uma boa? Gosta do formato screencast? Deixe um comentário.

Conteúdo original do blog sergiolopes.org.

Front In BH 2012: anotações da palestra 'Wordpress aliado do Front End' do Leandro Vieira

2012-07-17T00:00:00.000Z

Leandro Vieira (blog, twitter), da Apiki WP, palestrou no evento Front In BH 2012 sobre Wordpress com o título O WordPress como aliado do Desenvolvedor FrontEnd.

"Palestra do Leandro Vieira no Front In BH 2012"

Minhas anotações

Wordpress cresce absurdamente em adoção. 22% em 2012, perspectiva de 50% pra 2017.
1a fase: blog. 2a fase: CMS. 3a fase: plataforma de aplicação.
iMasters tá sendo todo migrado pra Wordpress hoje. 10 anos de conteúdo.
Diversas funções PHP pra você integrar seu tema à plataforma e plugins.
Marcação gerada é semântica e cheia de classes pra estilização.
Dev font-end que for criar pra WP deve conhecer essas classes e marcação pra evitar retrabalho.
Novidade da próxima versão 3.5:
- Tema padrão novo, já sem muita cara de blog. Mais cara de site.
- Recurso de personalização em cima de um tema minimalista.
- Galerias de fotos com lightbox.
Wordpress traz funções pra facilitar a integração de JavaScript entre plugins. Ajuda a isolar JS.
Declaro via PHP os arquivos JS, suas dependências etc. Depois, o WP gera as tag script satisfazendo as dependências, evitando duplicidade de frameworks etc.
Otimizações: tem opção de inserir o JS no fim do body ao invés do head.
O WP não inclue o jQuery com $, mas usa sempre o noConflict() e expõe só o jQuery.
Já o CSS é totalmente aberto pro dev. Há muitas classes e IDs pro desenvolvedor usar.
WP faz fingerprint de arquivos CSS/JS via param na URL.
WP cospe HTML semântico, temas novos em HTML5. Usa microformats, tem preocupações com SEO.

Meus comentários

Confesso que não sou o maior fã do Wordpress. Acho ele um tanto inflado demais, com muitos recursos e muita complicação pra se fazer coisas até simples. E curioso que, pra mim, o grande ponto onde o Wordpress é mais fraco é justo no front end. Acho ele legal como plataforma CMS pra controlar os conteúdos, mas o HTML gerado costuma ser péssimo e os plugins só pioram isso.

Aqui no blog eu uso o DocPad e fujo do Wordpress. Mas vejo seu uso sim para coisas maiores, que exijam mais controle de permissão e publicação. Curioso que, na palestra, o Leandro focou bastante no uso do Wordpress como plataforma de aplicações quaisquer, não só blog e CMS. E eu nunca tinha pensado nisso. Mas certamente o Wordpress seria a última plataforma do mundo que eu escolheria pra um site qualquer (falou até de ecommerce em Wordpress) - blog e CMS até vai, mas usar o Wordpress pra outras coisas me parece crime grave.

Esse meu ponto de vista deve ser por causa da minha origem de programador. Pra mim, prefiro uma plataforma simples e focada no backend do que uma ferramenta genérica. Talvez valha mais a pena usar o Wordpress quem não tem muita noção de backend e prefere algo pronto; mas aí pode ser que estejamos só tapando o sol com a peneira e escondendo o verdadeiro problema que é a falta de um backend mais robusto e focado no projeto.

Tirando meus problemas pessoais com Wordpress de lado, aprendi muitas coisas na palestra sobre como estender o Wordpress. O Leandro mostrou como eles têm uma preocupação de expor um HTML semântico com classes bem definidas. E aprendi que dá pra otimizar os JavaScripts pra ficar no fim da página ao invés do head, um problema que vejo em muitos blog e eu achava que era culpa do Wordpress.

Outras palestras do Front in BH 2012

Tem a minha palestra sobre otimizações web, incluindo slides, vídeo e post complementar. E as outras:

Rest Client Side, com Alexandre Gaigalas
Amazon AWS e CDN no Peixe Urbano, com Alexandre Tabor
Novo Cinto de Utilidades do Desenvolvedor JavaScript, com Leo Balter
Desafios do Design Mobile, com Horácio Soares
CSS Sucks, com Zeno Rocha
Estilizando folhas de estilo com estilo, com Bernard de Luna

Conteúdo original do blog sergiolopes.org.

Front In BH 2012: anotações da palestra 'REST client side' do Alexandre Gaigalas

2012-07-17T00:00:00.000Z

Alexandre Gaigalas (twitter), do Yahoo, palestrou no evento Front In BH 2012 sobre REST e HTTP com o título REST Client Side - Uma visão geral sobre projeto e consumo de APIs em REST no navegador e vantagens de utilizar recursos do protocolo HTTP (slideshare).

"Palestra do Alexandre Gaigalas no Front In BH 2012"

Minhas anotações

Links são as coisas mais legais na Internet.
Antigamente usávamos referências estáticas, bibliografia, apontando livro, página etc.
URIs apontam pra conceitos, mas não são o conceito. Trafegamos representações desses conceitos.
Formatos de URIs: http:, ftp:, mailto:
Como expressar links: link, a, img, script
JSON não tem links, não serve pra substituir o XML
Se você coloca um endereço numa propriedade do JSON, é só um texto. Não é um link.
Cabeçalhos HTTP pra negociar com o servidor: Accept-Language passa língua
Accept para content negotiation.
Mesmo conceito, mesma URL, mas representações diferentes.
XML é extensível.
Você pode usar dentro do XML pra indicar mais recursos. Ex: no twitter, devolvo links pros seguidores, pra quem eu sigo, pra listas etc.
XML pode ter a mesma tag repetida, JSON não. Facilita extensibilidade.
O Alexandre ama XML :)
Podemos usar o jQuery pra navegar e manipular XML devolvido via Ajax, JSON não.
HTTP suporta erros via status code. Muitas APIs devolvem 200 com erro dentro proprietário. Ruim.
2xx: sucesso, 3xx: redirects, 4xx: client error, 5xx: server error
Posso mandar texto do status code que eu quiser. E o código de acordo com o HTTP.
Negociação de conteúdo: Formato, Idioma, Charset, Encoding, Range, X-...
Ctrl F5 manda cabeçalhos de revalidação de caches.
HTTP auth: suporte básico a autenticação
HTTP digest é mais seguro que cookies, oauth

Meus comentários

O protocolo HTTP é realmente muito rico e extremanente interessante para basear APIs Web. Concordo com o uso do protocolo mais a fundo, ao invés de criar mini protocolos proprietários. E achei bem interessante a ideia do Alexandre de se usar os status code HTTP com mensagem customizada - sempre pensei em mandar a mensagem no body, além do status code.

E ele discutiu um ponto bem interessante sobre como JSON é um formato de texto sem suporte a hipermídia ou outros conteúdos semânticos. Nesse sentido, o XML é muito mais robusto por oferecer hipermídia e um modelo extensível. Mas confesso que eu ando meio desiludido com a ideia de semântica global no REST; acho que, na prática, não ajuda tanto assim.

Outras palestras do Front in BH 2012

Tem a minha palestra sobre otimizações web, incluindo slides, vídeo e post complementar. E as outras:

Wordpress aliado do Front End, com Leandro Vieira
Amazon AWS e CDN no Peixe Urbano, com Alexandre Tabor
Novo Cinto de Utilidades do Desenvolvedor JavaScript, com Leo Balter
Desafios do Design Mobile, com Horácio Soares
CSS Sucks, com Zeno Rocha
Estilizando folhas de estilo com estilo, com Bernard de Luna

Conteúdo original do blog sergiolopes.org.

Front In BH 2012: anotações da palestra 'Desafios do Design Mobile' do Horácio Soares

2012-07-17T00:00:00.000Z

Horácio Pastor Soares (blog, twitter), da Digital Acesso, palestrou no evento Front In BH 2012 sobre os Desafios do Design Mobile (slides).

"Palestra do Horácio Soares no Front In BH 2012"

Minhas anotações

"Design for mobile people not mobile devices"
Ambiente, Tempo, Cultura, Dispositivos diversos.
Experiência mobile.
A experiência perfeita: acho o que eu quero rapidamente.
Projetamos para a experiência de alguém
Acessibilidade
Usabilidade
Simplicidade (o simples é poderoso)
Numa interface perfeita, ninguém deveria errar
Interatividade
Velocidade
Encontrabilidade
Atratividade
Agrade aos olhos sem distrair a mente.
Utilidade
Facilidade
Portabilidade
Qualidade é o diferencial
Modelagem participativa.
Planejamento é essencial.
Projetar baseado nos fluxos do usuário.
Prototipação é importante. É barato errar.
Capacidades de hardware do mobile: gps, acelerometro, camera, bluetooth, nfc, multitoque.
Bom suporte a HTML5
One eyeball and one thumb.
Contexto mobile é diferente, cheio de limitações.
Te força a priorizar, a ter foco.
Restrições são boas pro design.
Mobile tá trazendo chance de repensarmos as coisas que fazemos no Desktop.
Há muitos mitos em mobile
- "Nunca vão ler isso em mobile"
- "As pessoas nao vao se registrar"
- "Nao vao comprar via mobile"
- "Nao vao produzir conteúdo"
Coloque labels no topo
Não pedir repetição de senha/email
Mostrar senhas sem máscara
Evite cadastro obrigatório
Diminuir os passos necessários
Content First, nav depois
Se for fazer site mobile diferente, fazer redirects das páginas e dar botao pra ver versao Desktop
Não colocar botao de Voltar no site pq ja tem no navegador
Difícil teste real de mobile, no contexto real em movimento.
Devemos manter o mesmo conteúdo sempre, no mobile e desktop.

Meus comentários

Eu acredito muito na web mobile. Falo nesse blog bastante sobre o assunto e acho que 2012 é o ano do grande boom mobile no Brasil. Essa excelente palestra do Horácio trouxe novos dados e mais argumentos pra nos convencermos de que o futuro é realmente mobile.

E esse mundo móvel traz novos desafios de UX impressionantes. Concordo com os pontos levantados e recomendo o livro Mobile First do Luke Wroblewski pra quem quiser se aprofundar. Da palestra, achei particularmente interessante a parte dos mitos do mobile. Usuários móveis querem fazer tudo que os os outros usuários fazem, e temos que nos lembrar sempre disso.

Outras palestras do Front in BH 2012

Tem a minha palestra sobre otimizações web, incluindo slides, vídeo e post complementar. E as outras:

Rest Client Side, com Alexandre Gaigalas
Wordpress aliado do Front End, com Leandro Vieira
Amazon AWS e CDN no Peixe Urbano, com Alexandre Tabor
Novo Cinto de Utilidades do Desenvolvedor JavaScript, com Leo Balter
CSS Sucks, com Zeno Rocha
Estilizando folhas de estilo com estilo, com Bernard de Luna

Conteúdo original do blog sergiolopes.org.

Front In BH 2012: anotações da palestra 'CSS sucks' do Zeno Rocha

2012-07-17T00:00:00.000Z

Zeno Rocha (blog, twitter), da Liferay, palestrou no evento Front In BH 2012 sobre pré-processadores CSS com o título CSS Sucks (slides).

"Palestra do Zeno Rocha no Front In BH 2012"

Minhas anotações

CSS3 faz muitas coisas ferradas
Mas é CSS é desorganizado (não tem padrão de código)
CSS é repetitivo (mesma cor copiada em vários lugares)
Precisa de muitos prefixos
Nada intuitivo (exemplo é um gradiente grande e detalhado)
Legal é usar pré-processadores pra gerar CSS
Stylus: tira chaves e ponto e vírgula
Prefix-free é ruim de performance. Isso não deveria ser feito em client-side.
Prefixr é melhor. Tem plugin pro sublime.
Mixins pra reaproveitar código.
NIB são mixins prontos pro stylus
SASS
- variáveis pra evitar repetição de valores
- partials com @import pra fazer include direto
- possível escolher SASS ou SCSS
Compass é uma extensão pro SASS com facilidades
Compilador pra dev que fica observando modificações e compila
Geração fácil de sprites com compass.
LESS
- comentários de linha com //
- aninhamento de regras
- operações matemáticas
- funções de cor
LESS elements são mixins prontos
Há programas Desktop pra compilar essas coisas - tipo CodeKit, WinLess etc
Porque o Twitter Bootstrap usa less e nao sass? Segundo eles:
- 6x mais rápido
- Less é mais simples
- é em JavaScript

Meus comentários

Sou bastante fã de pré processadores, e usuário assíduo do LESS - tenho até um post sobre LESS no blog da Caelum. Gostei de ver na palestra um pouco dos outros, em especial o Stylus que eu só conhecia de nome e não tinha visto código ainda.

Só não gostei do título e da motivação; pra mim, CSS não é tão ruim assim. Uso pré-processadores pra ajudarem em alguma tarefa a mais, mas não vejo tão negativamente o CSS. Foram levantados uns pontos nos primeiros slides como ruins: desorganizado, repetitivo, cheio de prefixos e nada intuitivo. Pra mim, nenhum deles é culpa do CSS. A desorganização é culpa do programador (e vai acontecer usando LESS ou sass), a repetição no CSS é resolvida com classes (e variáveis no CSS4), os prefixos são culpa dos browsers que abusaram desse recurso que era pra ser uma exceção, e intuitivo ou não vai depender da qualidade do código independente se é CSS ou não.

Recomendo pré-processadores de CSS. Mas os vejo mais como um complemento bacana do que como um um recurso antagônico ao CSS.

Outras palestras do Front in BH 2012

Tem a minha palestra sobre otimizações web, incluindo slides, vídeo e post complementar. E as outras:

Rest Client Side, com Alexandre Gaigalas
Wordpress aliado do Front End, com Leandro Vieira
Amazon AWS e CDN no Peixe Urbano, com Alexandre Tabor
Novo Cinto de Utilidades do Desenvolvedor JavaScript, com Leo Balter
Desafios do Design Mobile, com Horácio Soares
Estilizando folhas de estilo com estilo, com Bernard de Luna

Conteúdo original do blog sergiolopes.org.

Front In BH 2012: anotações da palestra 'Estilizando Folhas de Estilo com Estilo' do Bernard De Luna

2012-07-17T00:00:00.000Z

Bernard De Luna (blog, twitter), da MeltDSP, palestrou no evento Front In BH 2012 sobre boas práticas de CSS com o título Estilizando Folhas de Estilo com Estilo (slides).

Minhas anotações

Ninguém sabe CSS.
CSS é muito fácil e aí vc vai testando na tentativa e erro.
Styleshit. A gente não sabe direito o que tá fazendo.
Performance
- Key selector é o último seletor
- Browser seleciona da direita pra esquerda.
- class vs. id não faz muita diferença na prática
- não use tag.classe, só .classe
- Devíamos usar mais classes no HTML pra qualificar melhor no CSS.
- Não usar * como filho
- Ou implícito: body [type=text] é na verdade `body [type=text]`
- Não use @import
- Evite seletores CSS3: first-child, nth-child etc
- border-radius é bastante custoso. Mais que gradientes e shadows.
- Reflow e Repaint
- Definir tamanho das imagens no CSS ou IMG evita reflows.
Modularização
- OOCSS: Reuse, Reduce, Recycle
- Classes mais reusáveis.
- Use OCSS + LESS
- Usar variáveis é uma boa.
- Documente o código sempre.
- Crie objetos padrões e reaproveitáveis pro projeto.
- Crie classes baseadas na função e não no conteúdo.
- Smacss é uma alternativa.
Mágica
- Surpreenda, reinvente, brinque, explore.
- Muitos potenciais hoje em dia.
- old radio em css3 puro - impressionante!

Meus comentários

O Bernard focou bastante nas questões de performance de código CSS, evitar reflows, usar seletores otimizados etc. Concordo que são pontos válidos e realmente eficazes. Só deixo uma ressalva que essas micro otimizações de código CSS só devem ser feitas depois que otimizações maiores já foram feitas - como habilitar gzip ou jogar o JS pra baixo. A não ser que você tenha uma página gigantesca, o impacto prático de usar seletores mais rápidos é bem menor do que a gente imagina.

Sobre CSS modularizável e boas práticas, concordo completamente. Ultimamente tenho me deparado com muito CSS ruim e acoplado em projetos - inclusive meus de anos atrás que hoje preciso dar manutenção. Criar CSS mais flexível e reaproveitável é algo que tenho buscado ultimamente e digo: é muito mais difícil do que parece.

E um comentário especial pro demo impressionante do old radio que ele mostrou no final da palestra. Desenho inteiramente em CSS3 e com Web Audio API por trás. É fantástico.

Outras palestras do Front in BH 2012

Tem a minha palestra sobre otimizações web, incluindo slides, vídeo e post complementar. E as outras:

Rest Client Side, com Alexandre Gaigalas
Wordpress aliado do Front End, com Leandro Vieira
Amazon AWS e CDN no Peixe Urbano, com Alexandre Tabor
Novo Cinto de Utilidades do Desenvolvedor JavaScript, com Leo Balter
Desafios do Design Mobile, com Horácio Soares
CSS Sucks, com Zeno Rocha

Conteúdo original do blog sergiolopes.org.

Front In BH 2012: anotações da palestra 'Amazon EC2 e CDN no Peixe Urbano' do Alexandre Tabor

2012-07-17T00:00:00.000Z

Alexandre Tabor, CTO do Peixe Urbano, palestrou no evento Front In BH 2012 sobre o uso da Amazon EC2, cloud e truques de CDN no Peixe Urbano.

"Palestra do Alexandre Tabor no Front In BH 2012"

Minhas anotações

Pioneiro em compras coletivas, 20 milhões de usuários hoje, 1.5 bilhão de reais economizados em promoções.
Peixe Urbano não foi o primeiro serviço deles. Lançaram outro e não deu certo, foram pra compras coletivas.
Começo era lean, MVP. Testa ideias e tira do ar as que não dão certo. Hoje já tem mais sites.
Primeiro site era um teste, não foi codado muito robustamente.
E foi essencial algo barato pra testar. Usaram Amazon EC2 como plataforma.
Modelo de negócios gera picos (promoções chamativas tem maiores usuários). Usar cloud traz custos elásticos.
Tinham problema grande de latência por usar data center da Amazon na Virgínia.
Mediram tempo de 180ms de latência da Amazon pro Rio de Janeiro.
Começaram a usar CDNs pra distribuição geográfica. Mas tinham problemas de que cada provedor de acesso ia pra um lugar. Alguns usavam servidor americano mesmo tendo no Brasil.
Quando Amazon abriu em SP, decidiram não migrar pra cá pra economizar e por causa dos outros países do peixe urbano.
Montaram então um cache na Amazon São Paulo com Squid.
Usaram domínio secundário pra evitar cookies. A aplicação reescreve as URLs pro CDN.
Montaram serviço de redimensionar as imagens dinamicamente e cachear no squid.
Próximos passos:
- Mudar site pra estático e usar Ajax pra coisas dinâmicas.
- Implementar outras otimizações: gzip no squid, fingerprint nas URLs, minificação de JS e CSS
- Configurar proxies nos outros países do peixe urbano.

Meus comentários

Foram muitas histórias sobre o Peixe Urbano, como abriram a empresa, como ela cresceu e seus desafios. Já tinha ouvido alguns no QCon SP 2011 mas ouvi novas histórias agora. O Peixe Urbano é um excelente case da Amazon AWS e seus gráficos mostram como a elasticidade do cloud é fundamental pro modelo de negócios deles. Não sou muito fã de IaaS - sou mais PaaS e SaaS -, mas é certamente bom ver casos de uso tão bacanas de cloud.

Na palestra, foi abordada ainda a questão da latência de rede, e porquê servidores fora do Brasil podem não ser uma boa ideia. Foi discutida a ideia de se usar CDNs, até que o Tabor mostrou a solução deles de um proxy local no Brasil com Squid. Achei interessante, algo simples de se fazer, e eficaz se seu problema é latência. Mas curioso que ele mesmo levantou o ponto de que eles não têm gzip nem minificação ainda; eu teria feito essas otimizações antes de me preocupar com a latência de rede.

Um ponto interessantíssimo pra mim da palestra foi quando o Tabor citou que a próxima versão do Peixe Urbano será estática, um HTMLzãon gerado pelo servidor. Eu cada vez mais tenho gostado dessa estratégia - esse blog é assim - e tenho visto que pode ser a solução pra muita gente.

Outras palestras do Front in BH 2012

Tem a minha palestra sobre otimizações web, incluindo slides, vídeo e post complementar. E as outras:

Rest Client Side, com Alexandre Gaigalas
Wordpress aliado do Front End, com Leandro Vieira
Novo Cinto de Utilidades do Desenvolvedor JavaScript, com Leo Balter
Desafios do Design Mobile, com Horácio Soares
CSS Sucks, com Zeno Rocha
Estilizando folhas de estilo com estilo, com Bernard de Luna

Conteúdo original do blog sergiolopes.org.

Front In BH 2012: anotações da palestra 'Novo Cinto de Utilidades do Desenvolvedor JavaScript' do Leo Balter

2012-07-17T00:00:00.000Z

Leo Balter (blog, twitter), da Estante Virtual, palestrou no evento Front In BH 2012 sobre as novidades da Mozilla e do Firefox OS (slides).

"Palestra do Leo Balter no Front In BH 2012"

Minhas anotações

Representante Mozilla no Brasil.
Missão da Mozilla é dar opções pros usuários, mesmo perdendo market share pro Chrome.
Developer Tools nativo agora no Firefox, com inspetor HTML e CSS.
Novo Firefox Tilt pra inspeção 3D.
Scratchpad: escreve um JS e testa na hora, bom pra testes.
No futuro, vai vir um novo debugger JS no Firefox.
WebApps: offline, fora do browser, lançados via SO.
Arquivo manifest.webapp pra descrever dados de instalação da app. (mime type application/x-web-app-manifest+json)
Diferenças pra extensões/addons: webapp é independente do browser, e roda em qualquer browser.
Mozilla Marketplace: lojinha de webapps.
WebAPIs: geolocation, webworkers, websockets, indexeddb, video, audio
Novas APIs: camera, mouse lock, power management, screen orientation, vibration, sms, telephony, fullscreen.
WebApps nativos pra celular.
Boot to gecko da Mozilla. Firefox OS. Lançamento no Brasil.
Mozilla aposta que o mercado mobile tem espaço pra eles. No Desktop era a mesma coisa e eles conseguiram uma boa fatia.
100% open source.

Meus comentários

Acompanho com bastante esperança o desenrolar do Firefox OS e as investidas do pessoal da Mozilla no mundo mobile. Em especial, porque acho que eles são os únicos a tentar levar a ideia de webapps pro próximo nível. A Apple tentou quando lançou o iPhone 1 mas parou aí; o Google não fez nada no Android pelas webapps, embora as promessas sejam muitas. Já a Mozilla tá investindo na criação de muitas APIs novas (telefonia, SMS etc) e, principalmente, na integração da webapp com o SO e um processo de "instalação".

Agora, minha esperança é que essas APIs sejam padronizadas e as outras plataformas adotem o mesmo padrão. Porque com relação ao Firefox OS em si, eu acho perda de tempo. O mundo mobile com os fabricantes e operadoras é muito mais complicado que o Desktop. Acho praticamente impossível o Firefox OS ser relevante pro mundo mobile. (nem a MS e seu excelente Windows Phone estão conseguindo)

Espero estar errado no futuro. Porque a Mozilla realmente está com umas ideias bem bacanas. E eles têm um foco no usuário e em sua liberdade que ninguém mais tem - nem mesmo o Android. Eu gostaria que só isso fosse suficiente pra irem pra frente, mas infelizmente o mundo mobile mexe com poderes muito mais ocultos e a coisa não é tão simples.

Outras palestras do Front in BH 2012

Tem a minha palestra sobre otimizações web, incluindo slides, vídeo e post complementar. E as outras:

Rest Client Side, com Alexandre Gaigalas
Wordpress aliado do Front End, com Leandro Vieira
Amazon AWS e CDN no Peixe Urbano, com Alexandre Tabor
Desafios do Design Mobile, com Horácio Soares
CSS Sucks, com Zeno Rocha
Estilizando folhas de estilo com estilo, com Bernard de Luna

Conteúdo original do blog sergiolopes.org.

Front In BH 2012: palestra sobre performance e otimizações web

2012-07-14T00:00:00.000Z

Dia 14 de Julho, tive o prazer de palestrar no FontInBH 2012, excelente evento de front-end na capital mineira, sobre otimizações web. Seguem os slides, anotações e links complementares.

Por uma Web mais rápida: técnicas de otimização de sites

Tive a oportunidade de palestrar sobre esse tema que gosto bastante e considero de máxima importância para os desenvolvedores. Os slides da palestra estão no slideshare pra você ver ou baixar.

UPDATE: coloquei também um vídeo com o áudio da palestra e os slides. Um tanto amador mas dá pra acompanhar sem problemas:

A palestra tratou de diversos tópicos de otimização, mas, claro, pelo tempo curto, não focou em detalhes de implementação. Se você gostou e quer se aprofundar no tema, sugiro alguns links:

Sobre estudos de caso e impactos

Tenho um post com 14 fatos tweetáveis sobre performance web. Lá há links pra muitos estudos de caso de empresas famosas.
Um link recente do SEOmoz sobre os impactos de performance em SEO.
Considerações sobre latência e o mito da banda larga.

Pra se aprofundar nas técnicas de otimização

Tenho um post bem completo no blog da Caelum com 26 práticas de otimizações. Recomendo.
Os guias de boas práticas do Google e do Yahoo são excelentes.
Livros nós temos: High Performance Web Sites, 2007, O'Reilly e Even Faster Web Sites, 2009, O'Reilly, do Steve Souders.
Curso Online de Otimizações Web da Caelum que estou fazendo (lançamento em breve)

Ferramentas pra implementar as técnicas vistas

Minificação de CSS, JS e HTML: YUI Compressor, Google Closure Compiler, uglifyjs, htmlcompressor.
Compressão de imagens: Smushit, Kraken.io, JPEGmini, ImageOptim.
Diagnóstico: PageSpeed, YSlow, WebPageTest.
Sprites: SpriteMe, ou na mão com ImageMagick
Conversor de data URI
Frameworks de carregamento assíncrono de JS: LABjs, HeadJS, ControlJS. Ou (prefiro) o simples async do HTML5.

Outras palestras do evento

Aproveitei que estava lá no evento e fiz umas anotações sobre as outras excelentes palestras, junto com comentários meus:

Rest Client Side, com Alexandre Gaigalas
Wordpress aliado do Front End, com Leandro Vieira
Amazon AWS e CDN no Peixe Urbano, com Alexandre Tabor
Novo Cinto de Utilidades do Desenvolvedor JavaScript, com Leo Balter
Desafios do Design Mobile, com Horácio Soares
CSS Sucks, com Zeno Rocha
Estilizando folhas de estilo com estilo, com Bernard de Luna

Você estava no evento? Deixe sua opinião sobre a palestra e não esqueça de participar da promoção aqui no blog!

Conteúdo original do blog sergiolopes.org.

CSS fácil, flexível e dinâmico com LESS

2012-06-21T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Como debugar remotamente uma página no Chrome Mobile do Android

2012-06-18T00:00:00.000Z

O desenvolvimento de página web mobile é difícil de testar por envolver outros aparelhos. Mas os browsers mais novos já possuem recurso de debug remoto. Além do iOS, o Chrome Mobile também traz esse recurso.

Embora ainda não haja suporte nativo para debug do browser padrão do Android, o suporte no Chrome é muito bom. Ele apenas para Android 4 e já foi anunciado como futuro substituto do browser padrão do Android.

(eu já escrevi aqui no blog também como debugar páginas no Mobile Safari do iOS 5+)

Pré-requisitos

Instale o Chrome Mobile no seu Android 4.
Baixe o Android SDK pra sua máquina.
Instale o Google Chrome no seu Desktop.
Tenha um cabo USB à mão pra conectar o dispositivo no computador.

Configurações no celular

Vá nas Configurações de sistema do Android e entre em Opções do Desenvolvedor.
Lá, habilite a opção Depuração USB:
Abra o Chrome Mobile no celular e vá em suas Configurações.
Entre no menu Ferramentas para desenvolvedores lá no final.
Lá, habilite a opção Ativar a depuração da web via USB

Debug do celular via Desktop

Plugue o celular no computador usando o cabo USB.
No terminal, entre na pasta que você instalou o Android SDK e em platform-tools.
(opcional) Rode o ADB pra listar os dispositivos e ver se seu celular foi reconhecido:

  ./adb devices

Se não for reconhecido, verifique se a depuração USB está habilitada e tente plugá-lo novamente.
Ainda usando o ADB, rode o comando que habilita o debug remoto no Chrome:

./adb forward tcp:9222 localabstract:chrome_devtools_remote

Por fim, basta ir no seu Chrome Desktop e abrir o endereço http://localhost:9222.
Todas as abas abertas no celular serão listadas. Selecione uma para debugar:
O Web Inspector será aberto no seu Chrome no Desktop mas linkado com o Chrome no celular. Você pode debugar normalmente e fazer alterações e vê-las em tempo real no aparelho:

Debugando uma página do celular no Desktop

Conteúdo original do blog sergiolopes.org.

A funcionalidade mobile mais importante

2012-06-11T00:00:00.000Z

Talvez você ainda esteja decidindo se vai de site mobile específico ou de página única responsiva. Ou até já começou a implementar sua estratégia mobile, mas as coisas levam tempo e você está incomodado com usuários mobile abrindo seu site Desktop atual.

Ou talvez você não tenha tempo pra um design responsivo agora. Mas quer ter um site mobile friendly enquanto aprende os truques das media queries e viewport.

Se você tiver tempo para apenas uma coisa agora, foque em deixar seu site mais rápido. Responsivo, site mobile exclusivo e até seu velho site Desktop num celular. Não interessa.

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

O site Desktop menos mobile do mundo se torna acessível num celular se for rápido e otimizado. E um site cuidadosamente construído pra mobile é lixo se for lento e pesado.

É verdade que performance é importante pra todo mundo. Mas 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 (fonte). Um site mobile não otimizado simplesmente não será usado.

Sempre lembre da funcionalidade mais importante quando pensar na sua estratégia mobile e otimize seu site. E além de todas as práticas normais de otimização, o mundo mobile traz alguns desafios que tratei na minha palestra de web mobile.

Conteúdo original do blog sergiolopes.org.

Review do livro "Mobile First" do Luke Wroblewski

2012-05-21T00:00:00.000Z

Ok, você já se convenceu que a Web é mobile (Desktop será a exceção :), já acorda pensando em mobile, e acha design responsivo a última bolacha do pacote. Mas falta ver boas práticas e dicas de como atacar a nova Web. Conheça o excelente livro "Mobile First".

Comprei o livro no combo junto com o "Responsive Web Design" do Ethan Marcotte -- aliás, excelente preço, $15 os dois ebooks. Assim como os outros livros da A Book Apart, Mobile First é focado, curto e rápido de ler -- veja também meu review do livro "Responsive Web Design".

É um livro de boas práticas de usabilidade, design e conteúdo para mobile. Não há código -- o que achei bom --, apenas dicas e análises do autor sobre vários aspectos do desenvolvimento Web mobile e Desktop. A premissa básica que você já vê pelo título é que deveríamos começar nossos sites por mobile primeiro. As restrições e limitações do mundo móvel são uma boa coisa para nos ajudar a priorizar conteúdo, otimizar o site, e focar no que realmente é importante.

Eu gostei bastante desse livro, mais até que do "Responsive Web Design" do Ethan Marcotte. É um livro básico mas não óbvio, com várias sacadas que te fazem pensar melhor seus designs mobile. Um desenvolvedor iniciante consegue acompanhá-lo, e um mais experiente certamente irá aproveitar vários pontos.

"Livro Mobile First de Luke Wroblewski. Editora A Book Apart."

Luke Wroblewski começa destacando as vantagens de ir mobile first com excelentes argumentos. Trata das restrições comuns dos smartphones e tablets, e também das suas capacidades únicas -- como geolocalização, sensores e câmeras. Depois, parte para aspectos práticos de mobile sobre organização de conteúdo, como lidar com ações e input de usuário, e como organizar o layout da página.

Separei algumas excelentes passagens detacadas durante minha leitura no Kindle, começando pela minha favorita:

If your start to hear customers asking for your desktop web experience to be more like the simple, easy-to-use mobile one -- you're doing it right.

Mobile first é bom pra todo mundo

If you design for mobile first, you can create agreement up front on what matters most. You can then apply the same rationale to the desktop [...]. If you can agree on the most important set of features and content for your customers and business, why should that priorization change with mode screen space?

Anything that can be done to increase performance on mobile should be done. At the highest level that means sending less stuff and using whichever browser and server technologies are available to you to speed things up.

If you focus on mobile first and make things fast enough for spotty mobile networks, your websites and applications will be blazingly fast on the desktop and your customers will love you for it -- just another advantage to embracing mobile constraints up front.

Any actions that rely on mouse hovers in our desktop web experiences need to be rethought--and that's a good thing. Many uses of hover actions on the web assume too much. Just because someone places their mouse cursor over something doesn't mean they are asking for a pop-up menu of actions and options.

Não corte conteúdo

Customers will expect to do just about everything (whitin reason) on mobile. Especially those who primarily (or only) use their mobiles to get online. So don't dumb things down on mobile -- focus on what really matters most anywhere people can access your website.

When reflecting on a lot of mobile usage patterns, I like to imagine people as "one eyeball and one thumb". One thumb because they are likely to be holding their mobile in one hand and using a single thumb to control it; one eyeball because in many locations where mobile devices are used we only have people's partial attention.

While the time and place people interact with mobile may be different, the core value of your website stays the same. So once again, don't deny people content and features just because they're on a mobile device.

Dicas de UX

As a general rule, content takes precedence over navigation on mobile. [People] want immediate answers to their needs and not your site map.

On mobile, your options for on-hover menus are: on screen, on tap/swipe, on a separate screen, or (my favorite) gone for good.

While navigation menus fixed to the bottom of the screen might be a good idea in some native mobile applications, the variable presence of web browsers menus and physical controls below the screen on mobile device means they are often a poor idea in mobile web experiences. If you need a fixed menu better to fix it to the top.

Human fingers are imprecise pointing instruments: they lack the pixel-level accuracy of a mouse pointer; they come in different sizes; and it's not uncommon for them to slip or move around as we interact with our devices. Bigger actions mean bigger touch targets

Since the majority of people are right-handed [...] primary actions can be placed in the middle or bottom of the screen and arranged from left to right.

[The core gestures for mobile experiences are] tap, drag and swipe.

Device experiences

Consider the differences between connected TVs, desktop/laptops, tablets, smartphones and feature phones. Each of these devices experiences has a unique common user posture, primary input method and average display size.

Device experiences can also be useful for thinking through how each break point in a responsive web design solution should not only look but act as well. Layout and media assets can be adjusted to make the best use of available screen space and to optimize for specific input capabilities.

The right combination of device experience-specific designs, responsive web design, and fluid interfaces can ensure your mobile web experiences work on today's mobile devices and beyond.

Priorização de conteúdo

Reduction is the best layout approach available to you on mobile. [...] Across all your mobile layouts, aim for the minimum amount necessary to help people meet their needs.

Embracing constraints (rather than fighting them) will ultimately get you to better designs.

Não deixe de ver também meu review do livro Responsive Web Design do Ethan Marcotte, uma excelente companhia para esse livro.

Conteúdo original do blog sergiolopes.org.

Review do livro "Responsive Web Design" do Ethan Marcotte

2012-05-14T00:00:00.000Z

Design responsivo é o futuro da Web. Ethan Marcotte criou o termo em 2010 em um famoso artigo do A List Apart, que depois deu origem a seu livro "Responsive Web Design", editado pela A Book Apart.

Há pouco tempo, li a versão em ebook do livro em meu Kindle Fire -- recomendo um leitor colorido como o Fire pelas imagens. Minha experiência começou no excelente processo de compra, extremamente descomplicado, da A Book Apart. Dois cliques, nenhum campo preenchido e compra feita pelo PayPal -- e eu não tinha comprado nunca com eles, não tinha cadastro anterior nem nada. (aliás, se você for comprar, recomendo o combo com o "Mobile First" do Luke Wroblewski)

"Livro Responsive Web Design de Ethan Marcotte. Editora A Book Apart."

Sobre o livro em si. Leitura bastante agradável, um livro direto ao ponto e curto, o que eu acho uma grande vantagem. Ethan Marcotte é o pai do design responsivo, então ler o que ele tem a dizer traz uma certa autoridade, além de ser interessante pra ver como surgiram as ideias desse movimento.

São cinco capítulos, que giram em torno dos três ingredientes principais dos designs responsivos -- grids fluídos, media queries e imagens flexíveis. Ele fala bastantes também sobre porque design responsivo é a única solução viável pra Web do futuro, cada vez mais fragmentada em dispositivos, telas e navegadores diferentes. É desenvolvido um exemplo no livro de ponta a ponta, que pode até ser visto online.

Mas o livro é bastante básico. Não me entenda mal, livros básicos são ótimos e precisamos deles. Porém, se você já leu e estudou um pouco de responsive design, não vai achar nenhuma grande revelação no livro. A parte de media queries, por exemplo, aborda poucas opções em comparação ao que temos hoje nos navegadores; o capítulo de imagens flexíveis então, é bastante superficial dado o estado das discussões atuais sobre o tema. Eu, que acompanho bastante a comunidade de design responsivo, leio muitos blogs e artigos sobre o assunto, não aprendi nada de muito novo. Mas gostei do livro pelo formato e objetividade, e vou recomendá-lo pra quem estiver começando na área.

Alguns destaques das anotações que fiz no Kindle durante a leitura (e se você quiser saber mais sobre design responsivo, recomendo esse meu artigo aqui no blog ou esse meu post com links de artigos, palestras, livros e cursos em português):

We need to break our habit of translating pixels from Photoshop directly into our CSS, and focus our attention on the proportions behind our designs. It's about becoming context-aware: better understanding the ratio-based relationships between element and container.

We assume mobile users need less content in part because desktop users can tolerate more. [...] But just because desktop users can sift through more content, does that mean they need to? In other words, why is easy access to key tasks only the domain of mobile users? Why can't all users of our sites enjoy the same level of focused, curated content?

If you design mobile first, you create agreement on what matters most. You can then apply the same rationale to the desktop/laptop version of the web site. We agreed that this was the most important set of features and content for our customers and business -- why should that change with more screen space?

When working with media queries, fixed-width layouts often need to be re-coded at every resolution breakpoint, whereas a design built with percentages, not pixels, maintains its proportions from one resolution to the next.

[...] the kinds of decisions we constantly make as designers, choosing between flexibility and control. What responsive design show us, however, is that it doesn't need to be a binary proposition; we can have designs founded upon a flexible layout, while still including fixed-width elements.

Responsive web design isn't inteded to serve as a replacement for mobile web sites. Responsive design is, believe, one part design philosophy, one parte front-end development strategy. And as a development strategy, it's meant to ve evaluated to see if it meets the needs of the project you're working on.

Rather than simply siloing our content into different, device-specific sites, we can use progressive enhancement to ensure quality access for all, with an enhanced experience for those devices that are capable of it.

In the age of portable 3G hotspots and wi-fi enabled phones, it can be dangerous to automatically equate screen's dimensions with the bandwidth available to it.

Se você prefere um conteúdo em português, confira o meu novo livro A Web Mobile: programe para um mundo de muitos dispositivos..

Conteúdo original do blog sergiolopes.org.

A Newsletter Responsiva do QCon 2012

2012-05-07T00:00:00.000Z

O QCon, maior evento de arquitetos e desenvolvedores do mundo, está com preço promocional de inscrição só até dia 9 de maio. Pra divulgar, montamos uma newsletter. E aproveitei pra fazer uma newsletter responsiva.

O pessoal do InfoQ já tinha um modelo de newsletter que eles usam. Já seguem várias das boas práticas para emails que coloquei no meu artigo sobre newsletters. Uso de textos, layout simples, HTML com tabelas, pouco CSS, imagens pequenas, layout não dependente de imagens etc. Só não é responsiva, mas tá quase lá.

Na newsletter do evento, deveríamos seguir as mesmas boas práticas já seguindas pela newsletter normal. Aí aproveite e fiz ela ser responsiva. E, na verdade, se você já está com layout simples, poucas imagens e foco no texto, adicionar a responsividade é bem mais fácil.

Veja o resultado final. Redimensione o navegador e veja a responsividade.

Foto da newsletter responsiva do QCon 2012 (veja a real)

Suporte a Desktop e Mobile

Com emails, porém, o mais importante é saber como eles funcionam de verdade, nos programas de emails, webmails e dispositivos móveis reais. Veja:

Gmail via web no Chrome: é o cenário ideal, tudo funciona.
iPhone 3GS: ela se adapta à tela menor, sem media queries.
iPad 2: funcionando perfeito, tamanho máximo.
Hotmail via web no IE: repare como as bordas redondas e a textura do background somem. Mas a experiência para o usuário é muito boa.

Testando em outros lugares, teremos resultados muito parecidos com os cenários acima. A excessão, claro, é o Outlook, cujas últimas versões usam um motor de renderização pior que o IE6, baseado no Word! Mas desista de combatê-lo. As pessoas usam Outlook e só podemos tentar deixar o email aceitável. Veja:

Outlook 2010: bordas e fundo somem. Tudo fica alinhado no centro (!?) e aparecem quadrados brancos no topo dos blocos de conteúdo. Mas é tudo legível e a renderização é aceitável.
Outlook 2003: curioso reparar que o Outlook bem mais velho renderiza melhor que a última versão! Isso porque o tal motor de Word só foi introduzido a partir da versão 2007, antes era baseado no IE.

Dicas de como foi feito e projeto no Github

Principalmente, segui todas as práticas sobre newsletters resposivas do artigo aqui do blog.

Boa parte da responsividade se deve ao layout simples baseado em uma coluna. Basta uma tabela com 100% de largura (com um max-width de 550px) e os elementos vão se ajustar lá dentro sem problemas.

A exceção é onde mostramos as fotos dos participantes em duas colunas. Usei imagens de tamanhos pequenos, sabendo que caberiam 2 imagens lado a lado mesmo na tela pequena do mobile. O nome do palestrante eu fiz num bloco de tamanho fixo com display:inline-block que segue à direita da foto se houver espaço ou escorrega pra linha de baixo se não couber. Responsividade sem media queries!

E o melhor: se quiser ver todos os truques, liberei o código da newsletter num projeto no Github.

Outros truques incluíram a imagem elástica do rodapé, uso do premailer e htmlcompressor pra gerar o HTML final e até uso de conditional comments pra Outlook. (sim, isso existe!)

Uma prática útil pra ter em mente ao montar newsletters é progressive enhancement. Repare como a base do layout não são as bordas redondas e a textura de fundo. A base é sólida em HTML e CSS básicos e compatíveis, e os recursos de CSS3 vão a mais, pra quem abrir o email num cliente que suporte. Mas não são recursos necessários pro usuário visualizar tudo satisfatoriamente.

O que achou dessa newsletter responsiva na prática? Não deixe de ver o código no projeto e comente aqui!

Conteúdo original do blog sergiolopes.org.

10 dicas para fazer um email responsivo

2012-04-24T00:00:00.000Z

Muita gente abre emails no celular. Falamos que a web mobile tem crescido, mas abrir emails fora do Desktop já é uma tendência ainda maior. Há pesquisas que apontam mais de 20% de taxa de abertura de emails em mobile. E é bom estar preparado, se você manda emails para seus usuários -- newsletters, informativos, emails de confirmação, notificações. O papa da usabilidade, Jacok Nielsen, também apoia o design responsivo como solução para emails.

Recentemente, trabalhei na reestruturação da newsletter da Caelum e um dos focos foi a criação de um email responsivo. Reparamos que a taxa de visitantes mobile no site da Caelum vindas da newsletter é o dobro dos visitantes normais. E nossa newsletter não era responsiva ainda.

Conheça a nova newsletter responsiva da Caelum (redimensione o navegador pra vê-la em ação).

Trabalhei também em uma newsletter para o evento QCon 2012 e publiquei um post especificamente sobre ela, incluindo um projeto no Github com o código fonte.

One email

Falamos muito que a web é única e de web design responsivo. Mas, se você quiser muito, pode fazer vários sites diferentes -- um mobile, um Desktop, um pra tablets etc. Na web, é sua escolha abraçar ou não a ideia de web única.

Quando falamos em email, não há escolha. Só existe um email, entregue para o usuário e lido em todo tipo de dispositivo. E você não sabe se será no Desktop ou em mobile. E você não pode redirecioná-lo para um lugar específico. Um email, zilhões de dispositivos.

Mobile first

Esse é a dica que se dá normalmente para sites responsivos. Mas pensar em mobile primeiro, vai ajudar muito o desenvolvimento do seu email responsivo.

Na web, podemos escolher entre mobile first ou desktop first. Prefiro o primeiro, mas sei que às vezes é bom ter a segunda opção. E, com as media queries, sempre conseguimos ajustar o layout para todo tipo de dispositivo. Bem, isso me leva ao próximo ponto:

Entenda as diferenças

Esqueça tudo que você sabe sobre web design responsivo, ou quase tudo. Media queries? Esqueça. Viewport? Não. Grids flexíveis? Só se for com tabelas, esqueça tableless.

E não estou falando isso por causa do mané que ainda usa Lotus Notes pra ver emails. Um Gmail aberto num Chrome de última geração ainda não suporta media queries. Isso sem falar no suporte básico de HTML e CSS1!

Se você xinga quando tem que suportar o IE6, é bom tomar uns calmantes antes de entrar no mundo dos emails HTML. Suportar IE6 é fichinha perto de suportar o Outlook. E estou comparando um browser de 11 anos de idade à última versão do Outlook -- o Outlook 2010 não suporta a propriedade height no CSS, entre milhares de outras coisas.

Tá achando que tudo melhora com os webmails modernos? O Hotmail não te deixa usar background-image do CSS. Yahoo e Gmail arrancam fora todas as suas propriedades de position, top, left. O Gmail não te deixa usar nem display!

As limitações são tão grandes que muita gente simplesmente desiste. E mandam aquelas newsletters com uma imagem só, grandona. Mais fácil de desenhar, de controlar e não tem bugs. Mas não é acessível, não é responsiva, é menos usável e muita gente não clica pra ver as imagens.

Faça HTML e CSS porcos

Esqueça um HTML semântico. Esqueça usar float (não funciona no Outlook). Esqueça position (não funciona no Outlook, Gmail, Yahoo, Android). Até margin e padding têm seus truques.

Escreva um HTML cheio de tabelas nojentas. Muitas delas, todas não semânticas, só pra design. Use height e width no HTML, direto na tabela. Abuse dos tr e td o quanto quiser.

E, graças ao Gmail, você não pode nem usar <style> ou <link> pra separar seu CSS. O Gmail arranca tudo fora, só suporta algumas poucas propriedades inline lambuzando seu HTML com style=.

Uma opção, recomendadíssima, é criar seu CSS separado higienicamente e usar o premailer, uma ferramenta sagaz que consegue, entre outras coisas, fazer o inline do seu CSS automaticamente. E, claro, isso significa que não dá pra ir além do básico nos seletores; pseudo-classes jamais, incluindo a básica hover.

Pra saber o que você pode ou não usar no CSS, a referência absoluta é essa tabela completíssima do pessoal da CampaignMonitor.

Email responsivo

Você quer um email responsivo, certo? Adaptar à largura do dispositivo, desde um celular de 240px até um Desktop gigante. Parece um cenário impossível dada a falta de suporte a media queries, mas não é.

Temos que focar no básico de responsividade, e isso significa trabalhar com porcentagens, ems e layouts fluídos. Sua tabela principal -- sim, tabela, esqueça div -- não pode ter largura fixa em 600px como muita gente recomenda para emails. Coloque 100% de largura. E use porcentagens para todo o resto do posicionamento e tamanhos.

Lembre que você não tem como ajustar o layout para diferentes breakpoints como fazemos com media queries. Então se atenha ao básico. Em nome da sua sanidade, faça um layout de uma coluna só, mais fácil de adaptar em pequenas e grandes resoluções. Até dá pra arriscar uns truques de duas colunas fazendo uma escorregar pra baixo da outra usando tamanhos fixos, mas teste bem antes de ir por esse caminho.

Veja a nova newsletter da Caelum responsiva abrindo em diversas resoluções sem truques de media queries:

Repare como, comparado a um site, a resposividade é menos... glamurosa. Mas completamente funcional.

Use imagens pequenas

Imagens grandes são grandes limitadoras de um email mobile responsivo. Não adiantar fazer um layout em porcentagens e colocar uma imagem de 500px dentro.

Você pode fazer imagens flexíveis com porcentagens. Mas, sem media queries, você não vai conseguir entregar a imagem no tamanho certo pra cada dispositivo.

Por isso, recomendo que você use apenas imagens pequenas. No máximo, 240px, largura inicial dos celulares que queremos suportar. E faça seu design em torno dessa restrição. A mesma imagem vai servir o usuário mobile e o Desktop. Reveja a newsletter da Caelum e observe como as imagens não são limitantes para o design responsivo.

E, claro, isso não quer dizer apenas fotinhos pequenas como no nosso layout. Seja criativo. Se quiser um banner de 500px na sua newsletter, quebre em duas imagens menores lado a lado no Desktop e uma em cima da outra no mobile.

Faça funcionar com imagens desabilitadas

A maior parte dos clientes de email e webmails, por padrão, bloqueia todas as imagens nos emails para preservar a privacidade do usuário. O usuário precisa clicar explicitamente pra ver as imagens, o que é um passo a mais.

Isso significa que muitos usuários verão seu email com imagens desabilitadas, e é bom suportar esse cenário. Faça um design não dependente das imagens para conteúdo. Use imagens apenas decorativamente. Forneça alt= em todas as imagens de conteúdo e até estilize o texto alternativo.

Veja a newsletter da Caelum com as imagens desabilitadas.

PS. Tem quem me chame de exceção, mas eu, como usuário, não clico em "ver imagens" jamais, a não ser que eu confie demais em quem mandou. E simplesmente jogo fora emails que não consiga ler sem imagens.

Use Progressive Enhancement

O artigo não é todo sobre limitações e hacks. Embora os clientes de email mais usados no mundo sejam o Outlook e o Gmail -- os dois com mais limitações técnicas -- há vários bons programas de email.

O Mail no iOS, por exemplo, suporta media queries e outros truques de CSS3. E você pode usar :hover em todo lugar, exceto no Gmail e no Outlook. Até bordas redondas e sombras funcionam em algumas combinações de navegadores e webmails.

Use recursos avançados de CSS para incrementar o design. Mas tenha o pensamento do progressive enhancement: tenha uma base sólida no HTML e CSS básicos e vá acrescentando funcionalidades para clientes mais avançados.

Teste, teste, teste

Os bugs e limitações dos clientes de email são diversos e surpreendentes. Teste extensivamente seu email. Achava que testar sites Web em meia dúzia de navegadores era trabalhoso? Bem vindo ao mundo dos emails!

Teste em clientes de email Desktop como Outlook, Windows Mail, Apple Mail, Thunderbird. Teste em dispositivos móveis como iOS, Android (tanto Gmail quanto o programa de Email), Blackberry, Nokia. Teste nos webmails pelo menos do Gmail, Yahoo e Hotmail, e abra em vários navegadores diferentes. Aqui no Brasil, é bom também ter contas no UOL, Terra e iG.

Se não quiser perder a cabeça, use algum serviço de testes de emails como o excelente Litmus -- que, aliás, vem incluído em todos os planos do MailChimp.

De volta às origens

Óbvio, mas não custa lembrar: O email mais acessível, portável, usável, prático e direto é o... texto puro. Funciona em qualquer cliente de email, é responsivo e seu usuário está acostumado.

Aliás, lembre disso: usuários estão acostumados a emails em texto puro. Você não pode fazer um site todo em txt em pleno 2012 sem parecer louco, mas, no email, é diferente. Um email texto puro passa a ideia de objetividade.

Recomendo mensagens texto para emails de confirmação, notificações e alertas. Até para certas newsletters ele fica bom. Ou você pode mandar um email em HTML mas fortemente baseado em texto, quase sem formatação visual -- só uns estilos nos títulos e cores. Mega acessível, compatível e responsivo.

Dica Bônus: Faça sua landing page responsiva

Não adianta ter uma super newsletter responsiva e, quando o usuário clica no celular, cai no seu velho site Desktop.

Email é o ponto de partida para uma experiência online com seu usuário. Faça seu site também mobile/responsivo e ofereça uma experiência completa e satisfatória pra quem não está no Desktop.

Dica bônus 2: HTML email boilerplate

O HTMLemailboilerplate.com tem muitas dicas práticas de HTML e CSS pra se criar emails ricos, inclusive com dicas de mobile. Vale bastante a pena acompanhar.

Conteúdo original do blog sergiolopes.org.

2012 é o ano do mercado mobile no Brasil

2012-04-17T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Design Responsivo Por Uma Web Única

2012-04-16T00:00:00.000Z

Esse post possui design e interatividade não suportados nos feeds RSS. Recomendo que visite a página e leia por lá. (é otimizado também para mobile)

Design Responsivo por uma Web Única

Mobile cresce como nunca. Vende-se mais smartphones e tablets que computadores. A banda larga móvel cresce assustadoramente. Web não é mais sinônimo de desktops e notebooks. Novos meios de acesso, novos usuários, novos hábitos... como oferecer uma boa experiência na nova Web?

A Web mobile surgiu em 2007. Sim, dava pra navegar no celular antes disso, mas o iPhone mudou o jogo. Desde então, temos um browser completo e usável sempre à mão. Mas abrir aquele site Desktop clássico no smartphone não é lá a melhor experiência. Abrir até abre, mas costuma ser lento, com informações demais e difícil de navegar.

E assim nasceram os sites mobile. Criar uma página otimizada pra iPhone é bastante fácil: basta um design de 320px e um truque com viewport.

Mas o mundo mudou desde então. Bastante.

Veio o Android com seus tamanhos e formatos variáveis. Vieram o iPad e os tablets, com resolução de computador e mobilidade de smartphone. Levaram o Android e o iOS pra TV e, agora, até pra óculos. Navegamos em todo tipo de aparelho, a todo momento, em qualquer lugar.

Smartphones, tablets, televisões, celulares, ereaders, video games, netbooks, óculos, relógios... até desktops e notebooks!

Como, então, atacar o mundo móvel de hoje e de amanhã?

Criar um site para smartphones, outro pra tablets, outro pra Desktop, mais um pra TVs, outro pra [insira tecnologia do futuro]...? Impraticável.

Responsive Web Design

Um site. Um design. Um conteúdo. Incontáveis dispositivos.

Design responsivo é oferecer um único site pra todo mundo e, usando técnicas avançadas de CSS3, adaptar a experiência de acordo com o dispositivo.

Há vários bons exemplos. Recentemente, desenvolvi a página do nosso Livro Arquitetura Java com design responsivo. Observe:

Diferente de muitos sites mobile atuais que só pensam nos 320px do iPhone, um site responsivo se adapta a todo tipo de resolução, aproveitando o melhor que cada dispositivo tem a oferecer.

Queremos um site responsivo porque é a melhor experiência para o usuário, não porque seja fácil — não é! — e nem porque está na moda.

Como fazer um design responsivo?

São três ingredientes principais:

Media Queries
Com as media queries do CSS3, é possível criar regras no CSS que só se aplicam em determinadas situações, como em resoluções de tela específicas e até de acordo com a orientação do dispositivo ou sua densidade de pixels.
```
@media (max-width: 500px) {
  body { font-size: 87.5%; }
}
@media (max-width: 390px) {
  body { font-size: 80%; }
}
```
(se você não conhece media queries, leia esse meu post e depois volte aqui)
E que valores usar nas media queries? Há vários frameworks CSS que trazem valores pré-definidos para os breakpoints do layout, como os comuns 320px, 480px, 600px, 768px e 992px. Não à toa, são valores derivados de tamanhos do iPhone, do iPad e tablets de 7".

Mas um layout responsivo é aquele que se adapta a todo tipo de resolução. Usar valores pensados em dispositivos comuns (device driven breakpoints) pode levar nosso layout a quebrar em certas resoluções intermediárias se não formos cuidadosos.

Já que queremos suportar todas as resoluções possíveis, porque não criar as media queries a partir das necessidades do nosso layout? (content driven breakpoints). Faça a página e vá redimensionando; no pontos que o layout quebrar, coloque uma media querie pra ajustar.
Layout fluído

Só media queries não bastam. Seria impraticável criar uma media querie para cada resolução existente — seriam milhares! Devemos usar poucas media queries e fazer o layout fluir entre os breakpoints.

O segredo é não usar pixels nas medidas, mas priorizar um layout mais fluído e flexível baseado em porcentagens e ems.

Seria até possível criar um site mobile apenas com essa ideia, sem usar media queries. Se tudo for porcentual, o design se adaptaria a todas as resoluções. Mas, na prática, não seria um design capaz de aproveitar o potencial de cada dispositivo. As media queries permitem ajustar o design pensando em adaptar e melhorar a experiência do usuário.
Imagens flexíveis

Um layout verdadeiramente fluído precisa de imagens que se adaptem à todo tipo de resolução. E isso merece uma atenção especial, já que imagens são baseadas em pixels e, portanto, não muito fáceis de flexibilizar.

Podemos usar porcentagens para dimensionar imagens, mas é preciso cuidado. Aumentá-la além do seu tamanho original deixará o layout pixelizado. E carregar uma imagem de alta resolução para depois diminuí-la via código vai deixar a página muito carregada.

Precisamos de várias imagens em resoluções diferentes, uma para cada contexto. Mas ainda há o problema de como servir a imagem certa pra cada dispositivo. Com media queries, conseguimos ajustar as imagens vindas de CSS via background-image.

Mas para as <img>, não há solução muito elegante. Há alguns projetos e produtos com soluções razoáveis, geralmente envolvendo algum tipo de código no servidor, mas todas com algum "porém". O W3C também está discutindo o assunto no responsive images workgroup já pensando em incluir algo na especificação pra facilitar.

Além disso, é importante lembrar que muitas imagens decorativas podem (e devem!) ser substituídas por efeitos CSS3 — sombras, bordas redondas, gradientes etc. E ainda podemos usar SVG para gráficos vetoriais que escalam em todo tipo de resolução.

Responsivo, mas...

Só jogar umas media queries e trocar tudo pra porcentagem no CSS não vai fazer do seu site responsivo o com a melhor experiência para o usuário.

Desenvolver para mobile têm vários outros desafios, ainda mais se queremos que o mesmo site sirva todo mundo.

O conteúdo que importa

Há quem diga que é impraticável oferecer o mesmo site para todo mundo porque, quando navegamos em telas pequenas, queremos conteúdo mais focado e páginas mais simples e diretas. É absolutamente verdade que usuários mobile têm menos paciência pra páginas grandes e carregadas, mas isso não inviabiliza um design responsivo.

A chave é a priorização de conteúdo. É preciso repensar todo o conteúdo para descobrir o que realmente importa, e remover todo o excesso. Uma página mobile não deve ser apenas um design menor, mas uma completa reestruturação de conteúdo. Por isso que só adaptar o design de um site Desktop já existente dificilmente funciona.

E, se você já gastou um bom tempo cortando coisas secundárias e priorizando o importante, porque oferecer essa versão mais simples e funcional apenas para usuários mobile? Porque temos mania de pensar que usuários Desktop devem receber páginas cheias de informações inúteis?

Responsive design é entregar a mesma informação — útil e priorizada — para todo mundo!

Mais: mesmo que, após a priorização, você perceba que o conteúdo está grande, jamais corte conteúdo dos usuários mobile. Se faz parte do conteúdo principal, deixe lá para todos. Usuários mobile não gostam de experiência capada. Otimizar para mobile não significa diminuir funcionalidades, significa focar.

Otimizar é essencial

Sou grande militante de otimizações web. Acredito que cada segundo importa, e que otimizar o carregamento traz resultados fantásticos de satisfação do usuário e conversões. E isso é mais verdade ainda no mundo mobile.

Mesmo smartphones modernos são dispositivos bastante limitados. Baixo poder de processamento, pouca memória, imensa latência da redes 3G etc. Otimizar o carregamento do seu site é imprescindível.

E, repito a pergunta de antes: se você gastar um tempo otimizando seu site para mobile, porquê não servi-lo também aos usuários Desktop? Porque a versão Desktop tem que ser mais lenta que a versão mobile? Responsive design é entregar um site otimizado para todo mundo!

Aliás, se você só tiver tempo para seguir uma dica mobile desse artigo, esqueça media queries, responsividade e etc. Otimize o carregamento do seu site, é a funcionalidade mobile mais importante. O melhor que você pode fazer pelos usuários mobile é deixar seu site mais rápido.

Mobile first

Antes de criar um site responsivo você precisa escolher: começa pelo Desktop e vai ajustando até chegar no mobile ou o contrário? No site do Livro de Arquitetura Java, eu escrevi o CSS todo 2x, uma em cada abordagem. E digo, começar pelo mobile é muito melhor.

Essa estratégia, chamada de Mobile First, tem muitas vantagens. Como o mobile vai te forçar a priorizar o conteúdo, quando chegar a parte do Desktop você não precisará mexer em conteúdo. No caso contrário, é fácil o site Desktop ter conteúdo demais e, quando chega a parte mobile, você descobre que precisava ter focado mais e priorizado melhor.

No layout é a mesma coisa. Comece pelo layout mobile simples e incremente e ajuste as coisas para resoluções maiores. Começar com um layout complexo, cheio de colunas, e simplificar para mobile é bem mais complicado.

Programar mobile first é seguir o princípio do progressive enhancement — melhoria progressiva. Você cria uma base de conteúdo e marcação semântica ultra portável e vai incrementando-a conforme o dispositivo permitir. Com media queries, você vai ajustando o layout e, com JavaScript, pode ir adicionando capacidades novas avançadas. Mas sua base é simples e sólida, conteúdo puro e simples, que abre até nos dumbphones de 5 anos atrás.

Por fim

Criar um site responsivo não é fácil. Trabalhar com flexibilidade e adaptação é bem mais complicado que um site fixo em pixels. As ferramentas de desenho ainda não estão preparadas e os designer gráficos costumam ter dificuldades para criar com responsividade em mente.

O código fica mais complexo também. Há dificuldades para se trabalhar com imagens e vídeos responsivos. É bastante complicado adaptar um site Desktop já existente para ser responsivo.

Apesar de tudo isso, designs resposivos são o futuro. Pelo simples motivo de que a Web é única e criar sites separados para cada categoria de dispositivos é impossível.

Mas, claro que nenhuma solução é bala de prata. Aplicações web complexas que exijam experiências diferentes em mobile e Desktop podem ser fortes candidatas a terem páginas completamente diferentes. Se você têm recursos e tempo, criar diversos sites separados e otimizados certamente é o que trará a melhor experiência pro usuário. Mas não faça um site Desktop e outro para iPhones e ache que acabou.

Faça um site responsivo sempre disponível para qualquer dispositivo de hoje e do futuro. E, se for o caso, crie mais versões separadas otimizadas para dispositivos específicos.

Quer aprender mais sobre design reponsivo? Conheça meu novo livro A Web Mobile: programe para um mundo de muitos dispositivos.Veja também um post com um zilhão de links para posts, palestras, livros, cursos e exemplos de sites responsivos; tudo brasilieiro, em português.

E você, o que acha? Gosta de acessar sites em mobile com a experiência completa? Tem adotado qual prática em seus projetos móveis? Comente! Tem exemplos de designs responsivos brasileiros? Comente também!

Conteúdo original do blog sergiolopes.org.

Meu blogroll: o que eu leio sobre Web, Mobile, Design, Otimizações e afins

2012-04-10T00:00:00.000Z

Tenho mais de 150 feeds assinados no meu Google Reader que acompanho diariamente. Vários desses sobre assuntos pertinentes a esse blog e seus visitantes.

Então aí vai uma lista de feeds pra você assinar. A maioria dos links é em inglês, mas há alguns em português também. E aguardo sugestões de novos blogs nos comentários!

Obrigatórios sobre Web em geral

A List Apart -- comunidade super influente, artigos que costumam mudar o rumo da Web na mundo.
HTML5 Rocks -- excelentes artigos com o que há de mais novo em Web.
Smashing Magazine
Net Magazine
Categoria Web no Blog da Caelum (português).

Web

Chromium -- novidades da equipe do Google Chrome.
Dev Opera -- excelentes artigos do pessoal do Opera com novidades de HTML5 etc.
CSS Tricks -- muitas dicas de CSS e HTML.
Facebook HTML5 Blog -- dos desenvolvedores Web do Facebook.
Blog do Mathias Bynens -- desenvolvedor famoso, autor do HTML5 Boilerplate.
Blog do Nicholas Gallagher -- famoso, autor do HTML5 Boilerplate e do Normalize.css.
Blog do Paul Irish -- desenvolvedor do Google e autor de diversos projetos importantes.
Tableless -- mais famoso site de Web do Brasil (português).
CSS no Lanche (português).

Mobile

Blog do Brad Frost -- bastante material de Web Mobile, excelentes artigos.
Blog do Luke Wroblewski -- famosíssimo em mobile, ótimos artigos, autor de vários livros.
Android Developers
Cloud Four
Google Mobile Blog
QuirksMode Blog -- blog do Peter-Paul Koch sobre Web e Mobile, com muitos artigos e dados de pesquisas.
The Mobile Web Design Blog

Otimizações Web (WPO)

High Performance Websites -- blog do Steve Souders, engenheiro do Google, papa de otimizações.
Blog do Stoyan Stefanov -- ex-engenheiro do Yahoo, agora no Facebook.
Perf Planet -- dezenas de blogs sobre otimizações num feed só (inclui todos os anteriores). Recomendadíssimo.

Web Marketing

Conversion Rate Experts -- excelentes posts sobre conversões, landing pages, design, web maketing.
Blog do Google Analytics
Google Webmasters Central Blog

Empreendedorismo e Startups

Blog do Derek Sivers
Blog do Joel Spolsky
Blog do Patrick Mackenzie
OnStartups
Software By Rob
Startup Lessons Learned -- do Eric Ries, autor do Lean Startup.

Mais alguns

Blog do Brendan Eich -- engenheiro da Mozilla.
Blog do Paul Kinlan -- engenheiro do Google Chrome.
Blog do Eric Meyer
Blog da CampaignMonitor -- dicas sobre como fazer newsletters HTML, compatibilidade, mobile.
Google Blog -- blog oficial do Google, sempre com notícias interessantes da Web.
Google Developers Blog -- blog de desenvolvimento do Google, com diversos assuntos técnicos, incluindo Web e Mobile.
Blog do jQuery
Blog do John Resig -- criador do jQuery.
Blog do Thomas Fuchs -- autor do Scriptaculous e do ZeptoJS, commiter do prototype e do rails.
DesevolvimentoParaWeb.com (português).
Blog do Kyle Simpson -- autor do HTML5 Cookbook e do LabJS.
iMasters (português).

Conteúdo original do blog sergiolopes.org.

Flexibilidade em páginas para dispositivos móveis com media queries

2012-04-03T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Tweetables: 14 fatos sobre performance Web e otimizações

2012-04-02T00:00:00.000Z

Por que otimizar seu site? Quais impactos de uma página lerda? E o que outras pessoas e empresas já descobriram quando melhoraram sua velocidade? Se você precisava de fatos para se convencer -- ou convencer alguém -- a otimizar, aproveite os 14 fatos tweetáveis desse post.

Pra Amazon, 1s a mais no carregamento da página custa 1.6 bilhão de dólares por ano Tweet this

A maior varejista americana descobriu uma relação direta entre faturamento e a performance de seu site (fonte).

O tráfego do Yahoo! aumenta 9% a cada 400ms de melhora na velocidade Tweet this

Segundo estudos do próprio Yahoo em 2008. (fonte)

Usuários expressam mais agitação e stress em sites lentos, e precisam de 50% mais concentração Tweet this

Além disso, já foi constatado até aumento de pressão arterial quando o usuário tem uma navegação lenta! (fonte).

NYTimes: você perderá clientes para seu concorrente se sua página for mais de 250ms mais lenta Tweet this

Essa matéria do New York Times de Março/2012 fala que 250ms é o número mágico da vantagem competitiva na Web. (fonte)

71% dos usuários esperam que um site abra em seu celular tão rápido quanto no desktop. Tweet this

Segundo a pesquisa What Mobile Users Want da Gomez/Compuware em julho de 2011.

Ao cortar 2,2s da landing page do Firefox, a Mozilla aumentou o número de downloads em 15% Tweet this

No total, foram mais 60 milhões de cópias do navegador baixadas por ano. (fonte)

Um experimento do Google aumentou o carregamento de 0.4s para 0.9s. O tráfego de buscas caiu 20% Tweet this

Nesse experimento, o Google aumentou o número de resultados de busca de 10 para 30, impactando em apenas meio segundo a performance. (fonte)

A Microsoft mostrou que 2s a mais de latência no Bing diminuíam o faturamento em 4,3% Tweet this

O experimento ainda mostrou queda no número de buscas, nos cliques e na satisfação final dos usuários (fonte)

A expectativa de um comprador online em 2006 era de 4s para carregamento da página. Em 2010, 2s. Tweet this

Segundo estudos da Forrester Consulting, com muitos outros dados. (fonte)

Um experimento da Caelum piorou o carregamento da página de 2s para 4s. Os pageviews caíram 28%. Tweet this

Esse experimento fez o tamanho da página subir de 100kb para 300kb, aumentando o número de requests de 12 para 42, o que resultou em um crescimento no tempo de carregamento de 2s para 6s. Os impactos foram queda de 21% no tempo que os usuários ficam no Site, menos 28% pageviews e uma queda de 18% no conversion rate. (fonte)

Uma diminuição de 6s para 1.2s na página do Shopzilla aumentou as vendas em 12%. Tweet this

Além disso, o número de pageviews cresceu 25% e a quantidade de servidores necessários pra rodar o site caiu pela metade. (fonte)

50% dos usuários mobile abandonam um site se ele não abre em até 10s. E 3 em cada 5 não voltam mais. Tweet this

O crescimento do mercado mobile traz novos desafios. E os usuários são exigentes! (fonte)

Desde 2010, o Google considera a velocidade de carregamento dos sites no ranking de buscas. Tweet this

Entre as diversas variáveis usadas no page rank, o Google incluiu também a velocidade das páginas. SEO é um outro excelente motivo para se otimizar! (fonte)

O Walmart descobriu que compradores viam seu site carregar 2x mais rápido que não compradores. Tweet this

Ao analisar os visitantes que compraram algo e os que não compraram, eles descobriram que quem compra em geral viu um site mais rápido. A performance no Walmart.com está diretamente ligada ao bounce rate do site. (fonte)

Falo de performance e otimizações de Sites há algum tempo já. Tenho alguns artigos no blog da Caelum e palestras em diversos eventos, como esse meu keynote no QCon SP 2011. Divulgue esses fatos e, principalmente, faça algo por seu site e otimize-o já.

Tem mais bons links de otimizações web? Compartilhe nos comentários!

Conteúdo original do blog sergiolopes.org.

Lançamento do blog

2012-03-26T00:00:00.000Z

Aos leitores, sedentos por conteúdo, eis aqui meu novo Blog. Web, mobile, otimizações web, cloud computing e o que mais eu achar interessante. Bem vindos!

Pra estrear, escrevi três artigos, já disponíveis:

Mais estão por vir!

O blog

Roda Wordpress? Não, graças a Deus. O blog é baseado no DocPad. Por isso, ele é mais simples, mais rápido e otimizado, responsivo, funciona bem em mobile. E é um blog opensource -- você pode ver o código, customizações e até posts e drafts no repositório. Pull requests com correções são muito bem vindos!

Atualização Abril/2013: Migrei o blog recentemente do Jekyll pro DocPad, então atualizei as informações aqui no post.

Conteúdo original do blog sergiolopes.org.

Responsive Play: Vídeo do seu site responsivo em centenas de resoluções

2012-03-24T00:00:00.000Z

Um site responsivo deve abrir direito em quais tamanhos? 320px, 480px, 600px, 768px e 960px? Errado! Responsividade de verdade é abrir em todo tipo de resolução, até as incomuns -- como os 533px do meu Android.

Ferramentas de testes para mobile e responsive design costumam focar nas resoluções dos dispositivos mais famosos -- iPhones e iPads. Faltava uma ferramenta que permitisse testar um design verdadeiramente responsivo em todas as resoluções possíveis.

Assim nasceu meu pet project chamado Responsive Play -- disponível no Github. Com ele, você pode gerar um vídeo mostrando seu design responsivo em centenas de resoluções. Como o vídeo abaixo do ArquiteturaJava.com.br, um site responsivo em que trabalhei:

ArquiteturaJava.com.br no Responsive Play

Rodar o projeto é bem fácil:

play http://www.arquiteturajava.com.br

Você pode ainda passar opções como o o intervalo das resoluções a ser usado e até o tempo do vídeo:

play http://www.arquiteturajava.com.br 320 960

Mais um demo: um vídeo do Boston Globe, um famoso caso de design responsivo que funciona em todo tipo de resolução:

BostonGlobe.com no Responsive Play

Browser edition

Além disso, o Responsive Play tem uma versão web pra você rodar no navegador e visualizar seu site em diversas resoluções, sem gerar o vídeo. É só acessar a página e colocar o endereço de teste.

ArquiteturaJava.com.br no Responsive Play, Browser Edition

Mais

E o que você acha de testar sites responsivos em centenas de resoluções ao invés de algumas poucas de dispositivos famosos? Saiu um artigo na Smashing Magazine essa semana que trata justo do porquê sites responsivos deveriam funcionar em todo tipo de resolução.

Conteúdo original do blog sergiolopes.org.

Visualize em 3D a complexidade da sua página no Firefox Tilt

2012-03-19T00:00:00.000Z

Você já está acostumado a inspecionar suas páginas no Firebug ou no Web Inspector, mas aposto que não em 3D! O Firefox 11 traz o novo inspector 3D chamado Tilt que mostra os elementos da sua página hierarquicamente numa bela visualização em três dimensões.

A ferramenta já existia antes na forma de uma extensão beta. Mas agora está incorporada ao Firefox 11. Para acessá-la, basta abrir o inspector e clicar no botão 3D -- o inspector no Firefox fica em Tools > Web Developer > Inspect.

Google.com no Tilt

Ainda estou tentando achar cenários realmente úteis pra ferramenta, mas pelo menos ela é divertida. Ela serve como indicativo, por exemplo, de um markup complexo demais. Ao rodar na página da Caelum não fiquei surpreso ao ver dois picos de complexidade exatamente onde ficam os widgets do Facebook:

Caelum.com.br no Tilt

Com um markup estranho desses, não é de se estranhar que esses widgets sejam extremamente lentos -- vilões famosos do pessoal de web performance.

E dá pra fazer mais brincadeiras no Tilt. Como ele roda num canvas infinito de WebGL, ele não tem as mesmas restrições de tamanho do viewport tradicional do navegador. O que isso quer dizer? Dá pra ver todos aqueles hacks de posicionar elementos fora da tela, como esse pedaço do menu no site da Mozilla sobrando no topo da página:

Rabicó do menu da Mozilla saindo pra fora da página: visível no Tilt!

Ou ainda observar sua página em ângulos inusitados:

Toda a verdade por trás do UOL

Baixa lá então o Firefox mais novo e testa o Tilt. E se conseguir pensar em cenários úteis pra usá-lo, me conta aí nos comentários.

Conteúdo original do blog sergiolopes.org.

Pixels, pixels ou pixels? Dicas de Web Mobile com viewport

2012-02-27T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Por uma Web mais rápida: 26 técnicas de otimização de Sites

2011-09-12T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Otimizações na Web e o carregamento assíncrono

2011-04-28T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

CSS3 e o futuro da Web

2010-02-17T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Segurança em aplicações Web: Injeção de novos parâmetros

2009-04-07T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.

Segurança em aplicações Web: XSS

2008-11-25T00:00:00.000Z

Escrevi esse post em um outro blog. Acesse aqui para ler.