Tableless » mobiles

Google Chrome para Android

Diego Eis — Wed, 08 Feb 2012 13:05:08 +0000

O Google acaba de lançar o Google Chrome para Android. Antes que você fique todo alegre, o Chrome para Android só está disponível para os usuários do Ice Cream Sandwich ou tablets. Ele é baseado na simplicidade do Chrome para desktops, prometendo a experiência de navegação.

Eles reimaginaram o uso de tabs para os mobiles, e nas tablets a utilização as tavs ficaram similares com o Chrome para Desktops. Temos também incluído nessa versão mobile o famoso “Porn mode” ou o Incognito, que é o modo de navegação privativa.

O Google Chrome para Android ainda está em fase beta e você pode baixá-lo no MarketPlace mais próximo.

Uma boa notícia para toda a comunidade de desenvolvimento web mobile. A briga fica acirrada entre os sistemas. O que é bom para nós e para os usuários. Agora oremos para que o IE10 para Windows Phone saia logo, o que eu duvido. Acho que ele somente virá com o Windows Phone 8. Entretanto temos um ótimo cenário quando falamos sobre browsers para mobiles.

Posts Relacionados

Introdução ao Responsive Web Design

Diego Eis — Mon, 15 Aug 2011 13:00:03 +0000

Você já deve ter ouvido falar sobre Responsive Web Design. Você pode ler sobre isso aqui e aqui.
Até pouco tempo atrás tínhamos praticamente apenas um meio de acessar a internet, que era pelo desktop. Podíamos acessar mal e porcamente a internet pelos celulares ou por outros aparelhos ligados a televisão etc, mas nenhum destes meios nos permitia acessar a internet com a facilidade que tínhamos quando utilizávamos um desktop.
Hoje o cenário é totalmente diferente. Os smartphones tomaram conta. Até mesmo os celulares mais simples dispõem de browsers altamente eficazes e se não há algum browser instalado, o usuário pode facilmente baixar o Opera Mobile. Há também as Tablets, que demoraram para aparecer, mas agora trazem flexibilidade para usuários que querem algo mais prático que um notebook e mais confortável que um smartphone. Não vai demorar muito para aparecer outros aparelhos diferentes ou que você acesse sem restrições a internet pela sua TV.

Quando não restringimos os cenários a aparelhos temos um horizonte muito maior e mais frutífero. Entenda que a informação publicada na web pode e é totalmente reutilizada a qualquer momento. O Google faz isso com seu robô todos os dias, a todo momento. O robô do Google ou o de qualquer outro sistema de busca é um meio de acesso. O leitor de tela do usuário deficiente visual também é um meio de acesso. O leitor de RSS utilizado pelo seu celular, por mais simples que seja, é um meio de acesso. Podemos dizer então que qualquer dispositivo que o usuário utilize para consumir informação na web é um meio de acesso. Esse “qualquer coisa” pode ser um robô ou um sistema manipulado pelos visitantes de seu site.

O que é Responsive Web Design

Responsive Web Design é acima de tudo um conceito. Nós nos responsabilizamos a apresentar a informação de forma acessível e confortável para diversos meios de acesso. Muitos websites restringem o conceito a aparelhos com telas de diversos tamanhos, mas o conceito é muito mais abrangente.

Mesmo assim irei restringir os primeiros exemplos a dispositivos que tenham telas e que estão mais presentes atualmente. Não irei me estender muito a meios de acesso como leitores de tela, robôs de busca ou outros dispositivos.

O problema de entregar conteúdo em diversos formatos

Para fazer um website que seja acessível por qualquer dispositivo você geralmente tenta detectar o aparelho que o usuário está utilizando. Se for um desktop ou um notebook, você redireciona o acesso para um código CSS que formata seu site para o design mais confortável em grandes monitores. Se você detectar que o usuário está utilizando um dispositivo móvel, você o redireciona para uma versão que formatará o site para um formato compatível para este dispositivo.
Essa ideia é simples e foi efetiva por algum tempo quando utilizávamos Media Types do CSS.
Com o advento dos novos aparelhos como tablets, smartphones e até mesmo as televisões LED e LCD, essa técnica se tornou muito obsoleta.
Entenda porque: os media types detectavam algumas características dos meios de acesso, por exemplo o valor handheld filtrava aparelhos com telas de tamanho pequeno e conexão com a internet limitada. O valor screen, filtrava aparelhos com telas coloridas, normalmente terminais com monitores.
Entende porque estas características estão obsoletas ou se confundem com a quantidade de aparelhos existentes? Hoje 100% dos smartphones suportam resoluções de tela maiores e com acesso a um número ilimitado de cores que os monitores antigos. Quase nenhum celular tem telas pequenas e conexão limitada com a internet. Logo, estes parâmetros ficaram totalmente inúteis.

Para termos uma ideia melhor, a tela do iPhone e do iPad suportam resoluções muito maiores do que os monitores antigos. Lembro que utilizava em meu antigo monitor de 13” resolução de 800×600. A resolução do iPad é de 1024×768 com 132ppp. Meu monitor de 13” até chegava nessa resolução, mas daquele jeito porco. Até o iPhone tem uma resolução melhor: 960×640.

Agora entenda a regra primordial, que deve guiar todo o planejamento de design para diversos dispositivos: O que importa é a resolução e não o tamanho da tela.

Sabendo dessa regra, entenda que você não faz um layout para um determinado tipo de dispositivo, mas para aparelhos que tem uma determinada resolução. Um exemplo clássico é o site do Itaú. Eles tem uma equipe sensacional e muito pioneira. Eu consigo acessar perfeitamente o bankline por disversos dispositivos. Mas há um problema. Troquei meu smartphone Android recentemente por um Windows Phone. Eles tem as mesmas características. Mas quando entrei no bankline do Itaú, curiosamente fui redirecionado para a versão WAP do bankline. Com um bom desenvolvedor que sou, não me conformei e peguei emprestado o iPhone da minha mulher, copiei o endereço que o site redireciona os usuários do iPhone e o utilizei no meu Windows Phone. Voilá! Mesma interface, mesma usabilidade, mesmo design.
Eles detectaram o tipo de aparelho e não as características do aparelho.

Para nos ajudar a detectar as características dos aparelhos, bem como a resolução, utilizamos as Media Queries em detrimento aos Media Types.

Media Queries

Media Queries é a utilização de Media Types com uma ou mais expressões envolvendo características de uma media para definir formatações para diversos dispositivos.

Em Media Types há um valor chamado SCREEN, como já vimos anteriormente. Este valor é utilizado quando queremos direcionar uma determinada formatação para aparelhos que tem telas coloridas. Bom, telas coloridas é algo muito genérico, qualquer coisa hoje em dia tem telas coloridas. É aí que as Media Queries nos ajudam: além de identificar aparelhos com telas coloridas, você consegue definir um range de tamanho de tela para que aquele CSS possa ser ativado.
Veja um código de exemplo abaixo:

1	<link rel="stylesheet" href="estilo.css" media="screen and (color)" />

Você já deve ter percebido o porque do QUERIES no nome. Você cria queries no valor do atributo media o elemento LINK.
Neste exemplo, estamos capturando terminais com montiores e coloridos. Você pode capturar outros terminais com alguma saída visual, mas pode ser que o usuário esteja utilizando algum aparelho com saída de monitor monocromático, por isso temos que especificar o COLOR no valor.

Outro exemplo, onde restringimos a largura máxima da tela:

1	<link rel="stylesheet" href="smartphones.css" media="screen and (max-width:480px)" />

Aqui estamos direcionando o código CSS para aparelhos que tenham uma largura máxima de tela de 480px. Ou seja, qualquer aparelho que tenha essa largura de tela, deverá utilizar o código CSS que está no arquivo especificado.

É aqui que a diversão começa: com essas queries você define uma série de ranges de larguras de tela, separando uma versão de CSS para cada grupo de aparelhos que se enquadradam nestas descrições. Você faz um formato para grandes telas, outro para telas de tablets e outro para telas de smartphones.

E lá vem uma pergunta para você: as telas dos Tablets hoje em dia utilizando uma resolução de 1024×768. Muitos usuários utilizam esta mesma resolução de tela em seus computadores, com monitores maiores que as tablets. Como faz?

Entenda: se você criou uma versão adaptável, confortável para resoluções de 1024×768, pensando em tablets, será que essa mesma versão não seria confortável para monitores com essa resolução? E vice-versa. Se você definiu que a versão desktop será carregada a partir de uma largura de tela de 1000px. As tablets também verão essa versão. Lembre-se o que realmente importa é o tamanho da tela dos aparelhos, não o aparelho em si. Quando você especifica o aparelho, você limita os usuários, quando você específica a resolução, você amplia o número possíveis de visitantes.

Além do mais, vendo estatísticas por aí, a resolução de 1024×768 está decaindo muito rápido. Com as novas TVs e novos monitores, as resoluções de tela tem aumentado bastante, levando todos a um novo patamar.
O que nos leva ao próximo assunto.

Outras decisões de interface

O primeiro passo foi identificar os aparelhos e usuários que utilizam determinadas resoluções para conseguirmos entregar um CSS específico.
O segundo passo é fazer com que o layout seja amigável. Para isso você precisa entender os dilemas dos seus layouts e resolvê-los sem que o design mude da água para o vinho, mantendo as mesmas características e histórias de uso. Para tanto você precisa estudar e aplicar algumas premissas em seu website. Vou mostrar alguns pontos aqui, mas cada projeto terá uma abordagem diferente.

Layout fluido

Layouts fluidos estão sendo utilizados desde os primórdios, mesmo assim de uma forma muito restrita porque dependendo do tamanho do site são bem difíceis de planejar. Veja o site da Amazon, ele ocupa todo o espaço do navegador e seu tamanho é adequado até uma determinada largura de tela.

O A List a Part tem um exemplo ótimo, por isso não vou fazê-lo perder tempo vendo outro exemplo. Veja este layout com a tela maximizada e vá diminuindo a janela do seu browser e veja os efeitos.

Perceba ele se encaixa em qualquer tipo de tela. Dessa forma você entregou uma boa experiência de design para todos os públicos. Este é um ótimo exemplo para entender exatamente o que é Responsive Web Design.
Quer outro ótimo exemplo? Neste caso o designer mostra uma mensagem para o usuário, o alertando de que o site é melhor visualizado em grandes resoluções.

Adaptando menus

Menus de websites são indispensáveis. É por lá que o usuário descobre todos os segredos do seu website, por onde ele se apaixona ou se perde. O menu é um dos principais elementos do seu website. É muito comum que usemos menus na horizontal. E como você sabe, menus na horizontal não são quase impossíveis em telas pequenas como as dos smarphones. Ainda mais se você tiver uma grande quantidade de opções. Logo, você precisa adaptar se menu para que ele continue usável e ao mesmo tempo não ocupe tanto espaço na tela.

Há diversos caminhos que você pode tomar: você pode transformar o menu em um selectbox (ou combobox, como preferir), sumir com alguns ítens que podem não ser interessantes para usuários de mobiles ou reformatar seu design para que ele caixa de forma funcional em telas pequenas.

Veja alguns exemplos abaixo. Entre no site e diminua a janela do browser para ver os efeitos. Se preferir ver na vida real, visite o site pelo seu smartphone:

Diminuindo ou trocando imagens

Não se preocupe se seu website trabalha utilizando grandes imagens, você trocar ou diminuir as imagens para que caibam em telas menores. Veja os exemplos abaixo:

Media Queries – A Collection of sites using media queries

Todos os exemplos de website que mostrei acima, retirei deste website. A ideia é genial!
O http://mediaqueri.es/ tem uma coleção impressionante de websites que utilizam de forma responsável as Media Queries. Veja os exemplos e entenda como você pode fazer um website adaptável para diversos cenários de uso.

Cada meio de acesso tem sua característica

Conversamos bastante sobre o problema das resoluções e larguras de tela. Mas no começo deste post eu disse que o Responsive Web Design pode ir muito além das telas e Media Queries. Há usuários podem visitar seu site e não utilizar uma tela, tablet ou smartphone. Em vez de ler as informações ele pode ouvi-las, como é o caso dos usuários de leitores de tela.

CSS Aural

Quero que você abra sua mente e entenda que mesmo você não tenho deficiencia visual, você pode ser um grande candidato a utilizar leitores de tela. Enganam-se aqueles que acham que programas que leem a tela só podem ser usados por pessoas com problemas de visão. E se você estiver dirigindo ou em qualquer outra situação em que não pode ficar o tempo inteiro com o celular na mão, mas mesmo assim quer ler um determinado artigo, site etc, como você faz? Nunca pensou em ouvir o artigo? Pois é.

Eu sei que os sistemas de leitura de tela hoje em dia precisam de uma repaginada total. Mas empresas como Apple e Microsoft já estão fazendo isso para que seus sistemas mobiles e para desktops tenham a habilidade de ler bem as telas dos dispositivos. Isso é impressionante.

Se a informação vai ser consumida dessa forma ela precisa ser formatada também. Isso mesmo, formataremos o áudio! Como? Com CSS Aural.

O CSS Aural praticamente controla como o audio do leitor de tela irá se comportar. Você pode controlar volume, tipo da voz, qual caixa a voz sairá etc.
Imagine que você tenha um artigo sobre uma entrevista, onde há o entrevistador e o entrevistado. Você pode: especificar que a voz do entrevistador sairá na caixa da esquerda e a do entrevistado na caixa de som da direita. Que a voz do entrevistador será masculina e que voz do entrevistador será feminina.
Sensacional, não é?

Especificação Touchscreen

Já falei sobre a Específicação Touchscreen, abaixo segue um resumo, mas sugiro que você leia o artigo completo.

Estamos acostumados com a experiência de interação com a ajuda do mouse. Isso foi desde os primórdios e provavelmente ainda será por bastante tempo. Nós desenhamos interfaces para ações baseadas no mouse ou qualquer aparelho que controle a setinha da sua tela. Criar interfaces touch é algo relativamente novo. Nós trouxemos ideias da interação com mouse para os dispositivos touch, mas grande parte das interações precisaram ser reinventadas porque o modo, o ato, a forma de interagir com a informação é diferente. Na interface touch você não “coloca o mouse” em cima do elemento. Você não utiliza teclas de atalho para executar ações. Normalmente as ações importantes estão expostas na interface, facilitando o acesso rápido. Isso é muito importante porque nos ensina criar interfaces mais intuitivas, com a curva de aprendizado menor.

Há também o outro lado da moeda, onde detalhes das interfaces touch não podem ser portadas para interfaces baseadas em mouse. Lembre agora na forma de como você gira uma imagem em um dispositivo touch e como você gira essa mesma imagem utilizando um mouse. A interface muda, o seu comportamento muda.

Sabendo dessas limitações você deve entender que não podemos simplesmente portar o visual de um determinado site para um dispositivo touch. Você pode dizer que “hoje fazemos isso e até agora está funcionando muito bem”. Mas pense melhor… a grande maioria dos sites que você visita hoje no iPad ou qualquer outro tablet, por exemplo, são sites onde a sua interação é limitada. O que você faz em um site hoje em dia? Clica nos links e lê. Salvo às vezes quando você visita um site mais “animadinho” com mais ações para entreter o usuário. Mas e se você faz um site onde é preciso rotacionar uma imagem ou fazer um ZOOM? Você precisará manter as mesmas ações nos dois cenários. E como antigamente, para manter o cenário das interfaces touch você precisa da ajuda de muito script.

Concluindo

Responsive Web Design é um assunto muito extenso mas muito interessante. Nos faz pensar no futuro de forma diferente. Até 5 anos atrás não tínhamos preocupações com outro dispositivo a não ser um ou outro smartphone e os desktops. Hoje temos diversos aparelhos, com diversas limitações de tela, tamanhos, comportamentos… E isso não vai parar por aí. Todos os dias aparecerão mais e mais aparelhos e dispositivos que ajudarão os usuários a terem acesso a qualquer informação. É importante que nós possibilitemos que essas informações sejam entregues da melhor maneira possível.

Algumas referências que você pode querer dar uma olhada:

Posts Relacionados

Especificação para touch screens

Diego Eis — Wed, 22 Jun 2011 13:00:48 +0000

Até alguns anos atrás nós acessávamos a internet apenas utilizando computadores e celulares. Hoje existem aparelhos de diversos tipos. Temos até dispositivos como o Surface, ainda que seu uso seja mais restrito e específico. Mas não demora muito que outros dispositivos surjam e preencham alguma lacuna escondida. O importante é entender que cada aparelho tem sua forma de interação.

Hoje, as interfaces touch estão maduras e estáveis, que chegam a inspirar as interfaces dos sistemas desktops. Vide o que aconteceu com o OS X Lion e com o Windows 8. As principais ideias foram retiradas de suas respectivas interfaces mobiles: o Windows do Windows Phone e o Lion do OS X para iPad.
As interfaces mobiles e as interfaces desktop ficarão mais homogêneas com o passar do tempo, se assemelhando cada vez mais, contudo, as interações são totalmente diferentes. As interfaces criadas para cada dispositivo nos ajudam a distinguir os ambientes e também a forma com que o usuário interage.

Ambas as versões tem suas limitações e um legado de compatibilidade com seu sistema base que precisam manter.

A ideia de criar uma especificação destinada para as interfaces touch é que tenhamos controle sobre as ações do usuário, da mesma forma que temos nos desktops. Para isso eles estão mapeando uma série de eventos que específicos das interfaces touch. Assim podemos definir ações baseadas nessas interfaces. Estão participando da escrita desta especificação Doug Schepers do W3C, Sangwhan Moon da Opera Software ASA e Matt Brubeck da Mozilla.

Se você parar para ler a específicação, vai entender que poderemos controlar quando o usuário interage encostando o dedo na tela, movendo o dedo e também ao retirá-lo. Você poderá controlar a área de toque. Se o elemento for pequeno, por exemplo, você poderá aumentar essa área de toque para que o usuário não tenha dificuldades. Poderá acionar eventos no momento que o usuário rotacionar os elementos. Se você está fazendo um WebApp poderá acionar um menu contextual personalizado quando o usuário fizer um “tap” com dois dedos. O usuário vira basicamente um proctologista.

A especificação ainda é um rascunho mas já está mostrando que as possibilidades são imensas. Eu vivo me perguntando até onde irá o HTML, CSS e Javascript com essas novas mudanças. Será que vão continuar fáceis como são hoje ou tudo vai ficar complicado? Será que serão eles que farão todo o trabalho ou novas linguagens serão criadas para lidar com essas novidades? Who knows? Eu tenho um palpite, mas é assunto para outra hora.

Posts Relacionados

Interface Guide para Apps Mobiles

Diego Eis — Thu, 26 May 2011 13:00:24 +0000

Um dos sucessos dos Apps da Apple, tanto para mobiles quanto para desktops é a fidelidade e respeito que os desenvolvedores e designers tem ao seguir os padrões de interface que a Apple dispõe. São guias com informações importantes para que o App tenha um layout mais adequado e homogêneo com o sistema operacional. Dessa maneira o usuário final não se sente em um ambiente hostil e desconhecido.

Separei 3 guias para que você, independente da sua área de atuação, leia e compreenda mais os padrões dos três principais sistemas operacionais para mobiles existentes: Android, iOS e Windows Phone. Entenda que isso não são guias para criação de websites otimizados para estes aparelhos. São guidelines de interface para que você crie aplicativos offline ou online para estes sistemas. Diversas informações só farão sentido para aplicativos offline, instalados no aparelho. Mas toda a essência e diversas dicas podem ser utilizadas no desenvolvimento web.

Baixe abaixo os guias:

Windows Phone: Website com informações.
Download do guia de interface para Windows Phone.
Android: Website com informações.
Download do guia de interface para Android.
iOS: Website com informações.
Download guia de interface iOS.
De brinde: guia de interface para MAC OS X.

Posts Relacionados

Browsers para Mobile – Nova era

Diego Eis — Sun, 29 Jun 2008 05:23:08 +0000

Pense um pouco e tente lembrar de pelo menos uma maneira de acessar a internet que não seja a partir de dispositivos móveis ou computadores (notebooks e desktops). Difícil, não é?
Hoje, conhecemos bem apenas um meio de acessar a internet que é o computador. Estamos começando agora a navegar decentemente com dispositivos móveis, como um PDAs ou Smartphones. Além do óbvio, não conhecemos os futuros reais problemas de usabilidade e arquitetura de informação dos sites destinados à estes aparelhos. Estamos apenas engatinhando.

Naveguei um pouco pelo Safari do iPhone, e enquanto me adaptava, me perguntava várias vezes sobre a real necessidade de haver uma versão para mobiles. O iPhone tem uma maneira diferente de tratar os sites. Ele renderiza como se fosse um browser para desktop: o site aparece em miniatura na tela. Assim você tem uma visão geral do site e com apenas dois toques você aumenta o zoom no local que você gostaria de ler.

O interessante do iPhone, é que a Apple ensina e mostra exatamente como fazer um site que possa ser bem visto em um iPhone. Nunca vi nenhuma outra fabricante de celular fazer algo parecido. Eles te mostram características e formas de fazer um site bem feito com características úteis para o visitante e usuário de iPhone.

iPhone SDK for Web Developers de iphonedevel no Vimeo.

Juntamente com o iPhone, o Opera Mini 4, também utiliza esse tipo de navegação por miniatura e zoom. Esse método de navegação para celulares com tela pequena se mostrou muito mais confortável que o modo convencional.

Na minha opinião, essa maneira de renderizar, dispensa a criação de uma outra folha de estilo para mobiles. Como não existe apenas o iPhone no mundo, e nem todo mundo utiliza o Opera Mini para navegar, ainda precisamos criar uma versão mobile do nosso CSS para que os sites sejam acessados decentemente a partir de mobiles com navegação convencional.

Opera mini 4 – iPhone Killer! Part 1 de Kiran Konathala no Vimeo.

O W3C acabou de lançar um teste parecido com o Acid para testar a compatibilidade dos browsers para mobiles.

A guerra dos browsers para mobiles vai ser diferente. O Internet Explorer ainda não prevalece nesta área, e sistemas realmente bons, utilizam o Opera como navegador padrão. Uma boa notícia é que o Internet Explorer para mobiles não é tão terrível quanto o IE para desktops.

A Visie irá ministrar uma palestra rápida sobre o Internet Móvel no dia 07/07 em São Paulo por R$30.
Enquanto isso, leia algo antes de começar a fazer a versões mobiles por aí:

Posts Relacionados

Navegação em mobiles

Diego Eis — Fri, 31 Aug 2007 18:12:13 +0000

Adquiri faz pouco tempo um MotoQ. Já estou passando da parte de adaptação e me acostumando melhor com as frescuras, limitações e vantagens do aparelho. Agora, consigo dar mais atenção a pontos mais interessantes e claro, que irão me ajudar no trabalho diário. Um deles é a navegação.

Se acostumar a navegar num aparelhinho desses é algo realmente interessante e dependendo dos casos quebra um galho absurdo.
Hoje eu uso o Opera Mobile para navegar. E uma coisa que andei percebendo é que as versões mobiles dos sites (os que tem essa versão) são horríveis. O pessoal ainda não gasta tanto tempo planejando e implementando versões mobiles. Será que essas versões são menos importantes? Será que devemos dar atenção para isso somente se os clientes ou os visitantes pedirem?

Eu mesmo não costumo fazer versões mobiles dos meus sites. O Tableless não tem um (na próxima versão já vai ter) nem o site da Visie (que vergonha! Por enquanto.). Acontece que no meio de tanta a coisa para se pensar no site para desktop, que muitas vezes simplesmente, deixamos de lado. Para depois. O pior é que dependendo do site, fazer uma versão razoável para mobiles não demora tanto.

O que você acha? Você faz sites para versão mobile? Ou só faz por livre e espontânea pressão do chefe ou cliente?

Estou começando a colocar na minha cabeça que todo desenvolvedor devia ter um SmartPhone. Pelo menos os que trabalham com interface e padrões web.