Tableless » Internet Móvel

Graceful degradation é tudo sobre Acessibilidade

Diego Eis — Sun, 12 Apr 2009 16:13:41 +0000

Não há uma tradução literal para Graceful Degradation. O mais próximo seria Degradação Harmoniosa. Não é um termo muito bonito de ficar dizendo por aí. Por isso, vamos utilizar o termo original inglês durante todo o artigo.

Graceful Degradation é algo que vemos todos os dias. Trata-se de um método comum em dias onde a Internet é muito mais que um simples computador ligado no telefone. Acho que resumidamente, podemos dizer o que exatamente é Graceful Degradation com a frase:

Graceful degradation means that your Web site continues to operate even when viewed with less-than-optimal software in which advanced effects don’t work.

Peter-Paul Koch em Fluid Thinking

Esse assunto é bastante velho, mas que volta à tona nestes dias de campanhas contra o IE6 e outros browsers antigos. Eu mesmo já falei para ignorar totalmente o Internet Explorer 6, mas não é tão fácil assim. Eu posso ignorar aqui no Tableless, onde os usuários são de um nicho específico, mas eu não posso ignorar esse público quando se trata de um produto que é feito para o meu cliente. O cliente do meu cliente utiliza IE6. E ignorá-los significa fazer meu cliente perder dinheiro. Isso está fora de questão.
Então, se seguirmos este raciocínio, pense bem: podemos cometer este erro com outros tipos de usuários. Por exemplo, se seu site não pode ser bem visto em dispositivos móveis ou se não é bem acessado por leitores de tela.

É tudo sobre acessibilidade

Engana-se aquele que acha que acessibilidade é apenas sobre cegos e outras pessoas com alguma necessidade fisica. É claro que esse público merece uma atenção especial, que muitas vezes é tristemente ignorada. Mas quando falamos sobre acessibilidade, temos que entender que há outros grupos que se encaixam nesse assunto.
Quando um visitante não consegue acessar seu site por causa da resolução, ou por meio de algum dispositvo, ou por algum sistema de voz etc, estamos falando de acessibilidade.

Temos que prever visitantes com necessidades diversas. Há pessoas que passam a maior parte do tempo viajando. Por isso é muito difícil ler emails ou trabalhar conectado por notebook ou computador decente. Por isso ela passa a maior parte do tempo utilizando aparelhos móveis. Não por que ela queira, mas por causa da sua necessidade.
Se negligenciarmos o acesso desse tipo de público, cometemos um erro grave de acessibilidade. O mesmo para um simples visitante que não consegue acessar seu website por causa da sua resolução. Ele usa 800×600 porque precisa e não porque quer. Embora haja alguns que nem sabem o que é resolução.
Necessidade. Acessibilidade é tudo sobre a necessidade das pessoas.

Meios de acesso a Internet

Se as pessoas acessam a Internet, elas acessam por meio de um dispositivo especifico. Se ela é cega ou tem algum ou outro problema de visão, ela acessa o site por um leitor de tela. Se ela viaja muito ou fica muito tempo presa no trânsito, utililza dispositivos móveis.
Hoje em dia não existem muitos meios de acesso a Web. Se não acessamos por um computador ou um dispositivo móvel, acessamos com o que?
Outros meios de acesso a Internet estão nascendo. Na verdade novos usos para o acesso a Internet estamos surgindo e com estes novos usos, surgem novos meios de acesso. Vide o Surface da Microsof. É um meio totalmente diferente de interagir com a Web. Mas é um novo meio.

Mas e o Graceful Degradation?

Problemas com compatibilidades sempre existiram e creio que nunca deixarão de existir. Pelo contrário. Esses problemas serão mais comuns embora fiquem mais fáceis de resolver. Não serão apenas probleminhas entre browsers (os browsers existirão em tempos futuros?), mas também entre dispositivos.

Acontece muito hoje: tentamos acessar um serviço por um determinado browser, e somos aconselhados a utilizar outro browser porque o serviço não é compativel ou não funciona bem no nosso browser predileto.
Isso tira qualquer um do sério. O site deveria funcionar em qualquer browser. Para exemplificar: se em um meio de acesso eu não consigo utilizar bordas arredondadas nos elementos, os elementos apareceriam sem as bordas arredondadas. Isso não deveria prejudicar minha experiência de uso. Eu perderia um pouco no Design, mas conseguiria utilizar o serviço sem problemas.

A idéia do Graceful Degradation é exatamente essa: dar a melhor experiência possível ao dispositivo/meio que o usuário estiver utilizando sem prejudicar a acessibilidade.

Os usuários do IE6 por exemplo podem ficar sem bordas arredondas, position fixed, sombras e pngs semi-transparentes, mas eles precisam acessar e utilizar perfeitamente o site, com a melhor experiência que é possivel dar a este browser.

Mesma coisa é aplicada aos dispositivos móveis. Estes dispositivos normalmente não tem os mesmos recursos de um desktop. É tudo diferente, desde o poder de processamente até o tamanho das coisas. Então imaginar que o uso do sistema/site será parecido como se fosse acessado por PC, é um erro.

É um erro também se fizermos um site pensando em dispositivos menos capazes mas não nós lembrarmos do grupo de usuarios que acessam seu site com dispositivos mais completos e modernos. É engraçado porque pensamos sempre no usuário que está no pior cenário. Mas aquele usuário que não seria um problema pra nós, pode se tornar o pior deles.

Um exemplo disso é quando usuários de iphone acessam sites inteiros feitos em Flash. Sabemos que é uma limitação do aparelho. Mas estes usuários estão crescendo e seu cliente pode estar ali. Normalmente ninuem coloca uma versão diferente da do Flash. Logo, estes usuários simplesmente são ignorados. Imagine a frustação.

Resumidamente, Graceful Degradation é dar a melhor experiência que você conseguir para o usuário.
Se ele utiliza o último lançamento da Apple ou se ele utiliza um Nokia 6111 com Opera Mini. Ele precisa ter a melhor experiência que é possível dar dentro dos limites de cada dispositivo.
Obviamente que vice não vai prever todos os tipos de usuário. Mesmo porque seria impossível fazer isso. Novamente eu digo o óbvio: faça um estudo de público-alvo é importante.

Para complementar seu estudo:

Posts Relacionados

O Safari para iPhone – Desenvolvimento web para iPhone

Diego Eis — Mon, 13 Oct 2008 09:00:05 +0000

Esse texto e muitos outros fazem parte do Campus Online. Visite e cadastre-se grátis!
Sessão exclusiva sobre Desenvolvimento web para iPhone.

Um pouco de História

Por volta de 1997, os computadores da Apple traziam por padrão o Netscape. Naquele tempo o mercado de browsers não era tão acirrado como hoje e os concorrentes eram poucos. O Internet Explorer estava em sua versão 2/3. Mesmo assim, o Internet Explorer para Mac era também distribuído com o MacOS durante os 5 anos de acordo entre Apple e Microsoft. A Microsoft laçou 3 versões principais do seu navegador para o Mac, parando na versão 5 em março de 2000.

Em 2003, a Apple anunciou que eles estavam desenvolvendo seu próprio browser baseado no motor de renderização KHTML. A versão 1.0 foi lançado como browser padrão do MacOS por volta de Junho de 2003. O Internet Explorer ainda era distribuido no sistema, mas agora como um navegador alternativo, até Abril de 2005.

Motor de Renderização WebKit

O Safari utiliza um motor de renderização chamado WebKit. O WebKit tem dois motores de renderização: o WebCore, que é o motor de renderização baseado no KTHML do Konqueror. E o JavaScriptCore, baseado no motor de javascript KDE chamado KJS. Esses motores estão sob Licensa GNU.

A Apple, ao fazer o Safari fez muitas atualizações e modificações no motor KHTML, deixando-o mais maduro e robusto. Essas modificações foram devolvidas para a comunidade e incorporadas no Konqueror.

MobileSafari e Safari para Desktop

A idéia é que o usuário tenha uma experiência muito próxima a experiência que ele tem no desktop. Por isso o Safari para iPhone (MobileSafari) foi feito sob o mesmo motor de renderização WebKit do Safari para Windows e Mac. Diferenças: 1) Se o site não foi feito para iPhone, ele renderiza a página da mesma forma como renderiza em um Safari para desktop, mas miniaturizada. 2) A interação do usuário.

Padrões Suportados

Para que a renderização do MobileSafari seja fiel ao Safari para desktop, ele tem grande suporte aos Padrões Web.

HMTML 4.01
HTML 5
XHTML 1.0
CSS 2.1
Parte do CSS 3
Javascript 1.4
Ajax
DOM

É interessante notar que temos uma certa liberdade de desenvolvimento web no iPhone. Há facilidades como cantos arredondados que não podemos contar no desenvolvimento focado para desktops. Isso tráz vantagens pra você, desenvolvedor, porque facilitará seu trabalho, e para o usuário porque ele terá uma experiência mais rica.

Limites dos recursos

Embora o iPhone suporte as tecnologias mais atuais de desenvolvimento web, não podemos esquecer de que ele é um dispositivo móvel, com capacidade de processamento muito menor que a de um desktop. Por isso, há algumas limitações de recursos que devemos nos atentar.

Para códigos:

10Mb para arquivos Javascripts e XML
O tempo de execução de um Javascript é limitado a 10 segundos. Se passar de 10 segundos, o Safari pára a execução em algum lugar aleatório do seu código.
Javascripts alocados limitados a 10Mb
Máximo de 8 documentos abertos de uma vez

Para imagens:

Limite máximo do tamanho de GIF, PNG e TIFF são 2 Megapixels
A decodificação máxima dos tamanhos de JPGs são 32 Megapixels. Utilizando SubSampling
O tamanho máximo de GIFs animados deve ser menor que 2MB. Para arquivos animados maiores, só é mostrado o primeiro frame.

Verifique sempre o tamanho final de sua página. Normalmente o sites com 30Mb para menos funcionam muito bem no iPhone.

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.

Posts Relacionados

Podcast Tableless #23 – .mobi

Diego Eis — Thu, 28 Sep 2006 01:32:51 +0000

Pois é… parece que lá fora, a moda (ou quase) é registrar domínios .mobi para sites destinados a dispositivos móveis.

Isso está gerando uma polêmica muito produtiva: Uns acham que isso não é certo, porque defendem uma única versão do site para vários dispositivos. Outros, acham que é uma saída fazer uma versão específica para esses dispositivos.

Este assunto na verdade não é tão novo quanto parece, mas agora que foi tudo aprovado, discussões serão travadas e ainda não há como saber qual caminho o mercado irá tomar.

Fizemos este podcast expondo nossa primeira impressão. Nenhum dos dois ainda tem uma opinião totalmente formada, mas ambos acham que foi a pior droga que pode acontecer. E você, o que acha? Ouça o podcast e exponha sua opinião.
Agora você pode interagir melhor com o nosso podcast. Se você quiser mostrar sua opinião, dar um comentário ou sugestão, pode fazer isso deixando um recado de voz no skype. O usuário é tablelessbr. Adicione no seu skype e manda bala.

Podcast Tableless #23 – .mobi
Tempo: ~30min
Formato: Mp3
Tamanho: ~10Mb

Posts Relacionados

Podcast #15

Diego Eis — Wed, 28 Dec 2005 03:02:14 +0000

Estava ouvindo um podcast (ótimo por sinal) por aí, que me fez pensar um pouco sobre os anos vindouros.
Comecei a pensar então sobre a entrada triunfal dos celulares e outros aparelhos móveis. É melhor começarmos a ficar espertos com eles.

Você pode baixar o Mp3 direto, ou se quiser receber automagicamente nossas atualizações, cadastre nosso Feed.

Tamanho: ~14.32Mb
Tempo: ~15 Min

Você está gostando do podcast? O cara tá falando bem? Precisa de uma consulta com a fonoaudiologa? Comente.