<
Menu

Tableless


idiomas-htm

Declarando idiomas no HTML

modernizr

Utilizando a Biblioteca Modernizr

iStock_000013972132Small

Introdução ao Responsive Web Design

experiencia

Experiência deve ter começo, meio e fim


Bem vindo a Xangri-lá – Parte 1

Progressive Enhancement, Graceful Degradation e um horizonte perdido que precisa ser encontrado no desenvolvimento web

Um dia desses eu estava no meio de muita gente boa em um treinamento em São Paulo – um dos melhores que já fiz – e no meio de uma discussão sobre abordagens de desenvolvimento de aplicações internet crossbrowser e a maravilha que era o HTML5, o Elcio – ele mesmo – da Visie disse que Progressive Enhancement e Graceful Degradation eram a “mesma coisa”. Eu discordava dele porém não continuei o assunto porque essa questão poderia ser abordada de maneira mais abrangente, e porque o momento era de HTML5, não de como temos que escrever código. Deixei em italico a afirmação porque eu tenho certeza do que ele estava querendo dizer. Quando olhamos rapidamente a afirmação ela parece ter um significado, mas analisando mais a fundo, encontramos o Eldorado.

Mas porque trazer essa discussão para o Tableless, de maneira muito mais abrangente? Porque o Elcio já usa PE em seus projetos (conseguir entregar o que a Visie entrega no tempo que entrega só mostra isso). Mas justamente por já desenvolver pensando orientado ao Progressive Enhancement, pra ele tanto faz uma abordagem ou uma metodologia pois as paginas dele ja tem um proposito que PE e Graceful Degradation perseguem: a garantia do maior número possivel de usuários tendo o mesmo tipo de experiência ou funcionalidade, independente do browser, tamanho de tela, dispositivo ou conexão. O novo site da Brastemp, que os caras da Visie entregaram a poucos dias mostra bem isso. Tente acessar esse website do seu browser preferido. A experiência nao é comprometida em nenhum momento. Agora tente acessar do seu mobile. Agora tente acessar do seu PSP. Agora tente acessar do seu PS3. Voce vai perceber que a experiencia é a mesma.

Sem muita delonga, vou direto as diferenças: Graceful Degradation parte da premissa que você vai desenvolver seu site com a melhor tecnologia disponível, plugins e tudo mais. E mesmo que seu cliente possua browsers que não renderizem efeitos/features utilizados, sua navegação vai acontecer “sem problemas”, porque uma vez que a funcionalidade esta OK em um browser, vamos efetuando mudancas no código até garantir que a funcionalidade rode em todos os browsers usados. Partimos da premissa que a experiência que o usuario terá em browsers mais modernos será suavemente degradada para funcionalidades mais simples em browsers mais antigos.

Dito isso, bem vindos ao Eldorado: Progressive Enhancement usa tecnologias web em “camadas” que permitem que todos os usuários, independente de browser e velocidade de conexão, tenham acesso as funcionalidades básicas e conteúdo de uma página. E quanto mais avançado for o browser do usuário e sua conexão, mais rica será sua experiência. Partindo de um baseline que garantidamente funcione em todos os browsers, vamos pouco a pouco adicionando funcionalidades que, após testadas, funcionarão apenas em browsers que a suportam.

Em outras palavras, Graceful Degradation parte do difícil, do bleeding edge. Uma vez que seu jQuery maneirão já esta funcionando bonitinho no Chrome, é hora de voce passar o final de semana namorando seu código e sua garrafa de café, para garantir que o bendito plugin também funcione no amado IE6. Progressive Enhancement vai na direção oposta. Partindo do simples, garantimos que uma funcionalidade roda no IE6 para só depois “perfumá-la” para o Chrome.

Um exemplo?

   

Imprimir

Esse link funciona quando o JavaScript está disponível e habilitado e o browser suporta o comando de impressão. No entanto, se o JavaScript não estiver disponível (por exemplo, em alguns dispositivos móveis), o link não funcionará, criando um problema grande. Você, como o desenvolvedor do site, prometeu a seus visitantes uma funcionalidade que não funciona. Quando clicam no link e ele não funciona eles se sentem confusos, enganados e vão culpá-lo (com razão) por entregar uma experiência ruim ao usuário final.

Para resolver isso os Devs costumam usar Graceful Degradation: dizem ao usuário que o link pode não estar funcionando e qual a razão para isso, e talvez até sugiram uma solução alternativa para conseguir o que o usuário deseja fazer. Um truque comum é usar o elemento noscript.

    

Imprimir**

Para imprimir vc precisa do javascript habilitado. Por favor, habilite-o em seu browser.

Com isso explicamos que algo deu errado e como consertar o problema. Porém partimos da premissa que nosso usuário:

  • Sabe o que é javascript;
  • Sabe como habilitar(e desabilitar) javascript;
  • Tem permissões administrativas para mudar essa configuração;
  • Se sente confortável em habilitar o javascript apenas para imprimir um documento;

Ainda usando Graceful degradation, poderíamos ser mais gentis com o usuario:

    

Imprimir**

Impressão do documento: Selecione o botão imprimir/print no seu browser, ou no menu arquivo/file, selecione a opção imprimir/print. Você também pode tentar o atalho ctrl+p em seu teclado.

Isso resolve vários problemas do dev, mas parte da premissa que a funcionalidade de impressao é a mesma em todos os browsers. E essa afirmacao não é correta.

Se fossemos fazer a funcionalidade acima usando PE, a primeira coisa seria descobrir como imprimir a página sem usar javascripts. Como sabemos que isso non ecziste, chegamos a primeira conclusão: um link não é a melhor escolha de elemento HTML a se usar nesse caso. Mas se mesmo assim você quer usar essa funcionalidade de impressão, você deve usar botões ao invés de scripts. Por definição botões existem para suportar scripts.

“Botões não têm um comportamento padrão. Cada botão pode ter um script client-side associando os atributos do elemento ao evento. Quando ocorre um evento (por exemplo, o usuário pressiona o botão), o script associado é acionado.”


(w3c, 17.2.1 Control types)

A segunda conclusão é não assumir que o javascript estará habilitado, ou que o browser possa imprimir. Ao invés disso, informamos que o usuário precisa imprimir sua página:

	

Obrigado! Por favor imprima essa p´gina para seus registros.

Esse parágrafo com certeza funciona em qualquer browser. O resto é fácil.

	
    (function(){
      if(document.getElementById){
        var pt = document.getElementById('printthis');
        if(pt && typeof window.print === 'function'){
          var but = document.createElement('input');
          but.setAttribute('type','button');
          but.setAttribute('value','Imprimir');
          but.onclick = function(){
            window.print();
          };
          pt.appendChild(but);
        }
      }
    })();
    

Dê uma olhada no script, veja a abordagem usada. Não assumimos nada, tratamos caso a caso cada situação, e oferecemos a mesma funcionalidade a todas elas.

  • Colocando toda funcionalidade em uma função e a executando em seguida, não deixamos variáveis soltas na página.
  • Testamos o suporte a DOM e tentamos chegar no elemento que queremos para adicionar o botão a ele.
  • Após testar a existência do elemento, testamos se o browser suporta o objeto window e o método print
  • Se as duas condições passam, criamos um novo botão e aplicamos o window.print() no evento do clique.
  • Adicionamos o botão ao paragrafo.

Como disse lá em cima, isto irá funcionar para todos os usuários, independentemente do ambiente. Não prometemos ao usuário um elemento de interface que não funciona – em vez disso, apenas mostramos o feature quando ele funciona.

Em tempo: Tecnicamente não há nenhuma necessidade de um botao “imprimir”, mas para entender, mantive o exemplo simples.

Navegando nas águas dos browsers

Grande parte dos desenvolvedores mantém em sua máquina de desenvolvimento um IE8, talvez um IETester, Firefox 2, Firefox 3.6 e Firefox 4. Normalmente os contratos rezam sobre esses browsers, e quando isso representa a maior fatia da internet (73% do mercado), faz sentido. Mas faz sentido apenas até o ponto aonde essa afirmação não atinge consumidores em potencial. E não podemos desconsiderar o poder de 500 milhões de potenciais compradores. Com os browsers mencionados acima voce garante o grosso da internet e isso aí é o minimo que desenvolvedores como nós pode oferecer.

Analizamos os numeros abaixo, a situação fica mais visivel. Em outubro, os numeros* foram:

  1. Firefox: A raposinha tem 44,1% do mercado, ou quase 870 milhões de browsers instalados
  2. IE: Em franca decadência desde a sangrenta batalha com a Netscape, hoje tem 580 milhões de browsers instalados – 29,7%
  3. Chrome: Como tudo do Google, o crescimento espantoso graças a estrategia de marketing que eles usam já garantem quase 380 milhões de usuarios, com 19,2%
  4. Safari / Opera: Juntos, os dois simpáticos browsers tem quase 120 milhões de usuários – 3,9% e 2,2% respectivamente
  5. O resto: temos pouco mais de 17 milhões de pessoas que navegam com outros browsers, a lista é “infinita”

391de7d2-f315-11df-b15d-000255111976
Essa comparação gerou uma visualizacao no manyeyes. Você pode vê-la aqui e aqui.

Considerando que estamos cobrindo 73% do mercado, deixamos fora da festa a considerável quantia de mais de 500 milhões de usuários que fazem uso de outro browser. Voce realmente quer perder ou deixar de lado essa audiência? Você não poderia desenvolver seus websites de uma maneira que uma fatia maior de usuários possa usar sem problemas a sua aplicação? Quer deixar essa equação mais difícil ainda? Estamos falando de números para browsers que hoje estão em sua maioria em desktops. O problema deve aumentar expoencialmente a medida que novos dispositivos comecarem a acessar seus websites.

O cenário caminha para o completo caos se pensarmos que nossos clientes normalmente pedem seus websites em um timeframe muito pequeno. Cobrir todas as áreas do desenvolvimento web em um mês normalmente e ainda garantir que a aplicação vai rodar em 5 diferentes browsers (IE6/7/8/9, FFox 2/3.6/4, Safari4, Opera11, Seamonkey, Chrome) é muita tarefa para o exército-de-um-developer-só. E é ai que entra o PE. Usar uma abordagem diferente para trabalhar é a chave do negocio. Chegou um novo projeto?

  1. Separe conteúdo da forma. Isso facilitará o passo 3
  2. Defina um baseline de funcionalidades básicas da aplicação. Pesquise na documentação se estas funcionalidades rodam OK no browser mais antigo que o seu contrato pede no desenvolvimento. Se não funciona nele, esta não é uma funcionalidade básica. Redefina e pesquise até chegar a um denominador comum. Se o projeto for HTML5, recomendo partir do HTML5 Boilerplate
  3. Escreva um HTML semântico aonde depois você vai encapsular o conteúdo. Nada de javascripts, nada de CSS. Apenas o HTML nesse momento. Valide o template, veja se tudo esta ok antes do próximo passo.
  4. Aplique o CSS para o HTML desenhado, teste nos browsers que você precisa cobrir no desenvolvimento. Garanta a mesma experiência ao usuário em todos eles.
  5. Aplique o javascript. Faça modificações, teste novamente em todos os browsers. Ao implementar, tenha em mãos uma lista de objetos e métodos aceitos pelo browser
  6. Seja feliz e tenha certeza que ao entregar o seu produto, seu celular não vai tocar no final de semana porque o plugin de código de barras não funciona no cliente que tenta deseperadamente imprimir um boleto de compra usando IE7.

Isso significa que Graceful Degradation é o fim do mundo, técnica capenga de desenvolvimento quando comparado ao Progressive Enhancement? Não, de maneira alguma. Graceful Degradation também tem seus benefícios – principalmente em projetos que já estão em produção – mas se você vai escrever um projeto do zero, use Progressive Enhancement. Não complique. Progressive Enhancement é mais sofisticado e mais estável que GD, mas se você não tem uma metodologia de trabalho ja definida, PE pode tomar mais tempo. Se você ainda não tem uma metodologia de trabalho, desenvolva-a. Se você vai trabalhar em um projeto que já está rodando, se vai mudar uma funcionalidade que já está no ar, você pode usar Graceful Degradation, atuando como um “patch” para um produto ja existente, uma vez que o tempo de desenvolvimento sera menor que desenhar uma solução do zero usando Progressive Enhancement. É, pensando bem, dá pra usar os dois pra achar o Eldorado, é só ter cuidado ao criar novos sites, e guardar seu canivete-suiço de soluções ninja para fazer tudo funcionar em todos os browsers para os momentos aonde esse skill sera exaustivamente colocado a prova. Mãos a obra!

Uma vez apresentado, é hora de mergulhar fundo no Progressive Enhancement, mas isso é assunto para o próximo post. Um abraço!

*Os percentuais eu retirei do w3schools, os milhoes de um calculo que so foi possivel gracas ao excelente livro Designing with Progressive Enhancement, do pessoal do Filament group, aos numeros do Internet World stats, e algumas xicaras de cafe. Todavia, recomendo fortemente a leitura do livro.

** Bons olhos James! Obrigado pelo toque, o wordpress remove o javascript: da minha chamada automaticamente, deve ter algo a ver com a tag pre. Assim que resolvido, o código estará corrigido.

Referências:

Por Alysson Franklin

Alysson Franklin é desenvolvedor web por diversão. Lá de BH ele viu a internet nascer no Brasil, o IE vencer a guerra com a Netscape, os CD-ROMs da AOL, os pop-ups tirarem usuários do sério, o maketing "de ponta" dos banners e o nascimento dos heat maps, as newsletters virarem o precursor do spam, o javascript ser declarado como tecnologia para cybercriminosos e depois como Tábua de Salvação. Estudou Eletrônica Industrial e descobriu que pra se formar, tinha que “fazer um projeto de site para a internet”. 13 anos depois, atua como Front-End Engineer na IBM Brasil garantindo a aplicação dos padrões web, usabilidade e acessibilidade em projetos de grande porte.

http://twitter.com/alyssonfranklin

Mais posts do autor

Comentários (33)

  • http://www.profesionalit.com.br Leandro

    Alysson,

    Excelente artigo !, meus sinceros parabéns ! Uma verdadeira aula sobre desenvolvimento web de ponta.
    Estou ansioso para a continuidade dos artigos.

    Um abraço e muito sucesso !
    – Leandro.

  • Pingback: Tweets that mention Progressive Enhancement versus Graceful Degradation | Boas práticas de Desenvolvimento com Padrões Web -- Topsy.com

  • http://jamesclebio.com.br James Clebio

    No caso, seus exemplos não funcionariam nem com o javascript habilitado… ;p

    Ou usa esse mesmo valor no atributo ONCLICK ou usa “javascript:window.print();” no HREF mesmo.

    ;D

  • http://twitter.com/alyssonfranklin Alysson Franklin

    James, obrigado! o wordpress remove o javascript: da chamada automaticamente, deve ser algo a ver com a tag pre. Vou dar uma olhada e assim que corrigido o código estará ok, o que não nos salva de mencionar o fato graças a sua percepção. Bons olhos!

    Abraço!

  • http://www.ecosdaweb.com Tiago B. dos Santos

    Ótimo artigo Alysson!

    Me esclareceu muitas coisas, além de “clarear” as ideias para o desenvolvimento.

    Fico no aguardo dos próximos artigos.

    Abraços.
    Tiago

  • http://twitter.com/alyssonfranklin Alysson Franklin

    Obrigado Tiago, a proxima parte – quase pronta – vai mais a fundo do Progressive Enhancement, e olhando a longo prazo apos as duas partes um lab integrando um plugin de graficos usando PE. Abraço!

  • Júnior

    O site da Brastemp leva minutos pra carregar no navegador do meu Android, e é exatamente igual ao desktop, ou seja, muito difícil de navegar na tela pequena e touch. Não considero isso como “a mesma experiência”.

    Mas o que eu queria dizer é que, francamente, se alguém está desenvolvendo hoje em dia sem testar no Webkit ele não é um profissional. Até porque 99% do que funciona no FF funciona exatamente igual no webkit. A conta dos 500 milhões de usuários está totalmente errada. Normalmente quem acaba de fora é o Opera, mesmo quando o projeto suporta até o IE6.

    Além disso, teus números de uso estão exagerados. O IE ainda tem +- 50% do mercado, aqui no Brasil provavalmente mais. FF em torno de 30%, 10% Chrome. A realidade é bem diferente.

    E por fim, o maior problema do PE é que todo mundo no processo precisa ser “convertido”. Se não, o projeto é vendido pelo PSD, e na hora de desenvolver o gerente fica puto “como assim não ter borda arredondada no IE?” e quer tudo exatamente igual em qualquer lugar, sem entender que isso é um problema. Ninguém quer dizer pro cliente que alguma coisa “não vai funcionar” em algum contexto (que é a maneira errada de por as coisas, mas..).

  • http://twitter.com/alyssonfranklin Alysson Franklin

    Fala Júnior;

    O site da Brastemp, rodando pelo Chrome, aqui na minha máquina, rendeu os seguintes números:

    591ms para Documentos
    379ms para Stylesheets
    1.17ms para imagens
    1.17ms para scripts
    959ms para XMLHttpRequest

    Com menos de 2 segundos a página já estava quase toda carregada. Eu não tenho o ySlow ou parecido para PSP(que pra mim é o dispositivo-quebra-design) , mas nele o site demorou menos de 4 seg pra abrir. E no Android (ipad 1024×768 e mobile 320×480) , a mesma coisa, com renderizacao inferior a 4seg. A acessibilidade também foi pensada, no DaSilva os avisos de severidade 1 foram de ausência de alt em algumas das imagens. Dos 4 cenários de teste, consegui navegar por atalho em 3(menos mobile, não testado) e pelo visual neveguei em todos, e a experiência em uma tela 320×480 foi encarada como a mesma, obviamente com as limitações de tamanho de tela, que nos fazem trabalhar mais o zoom do que a “navegação em si” para melhor visualização.

    Desenvolver para o webkit é sim um bom ponto de partida (confesso que é meu starting point tb), porque você garante uma boa fatia de browsers sem a necessidade de grandes engenharias em hacks e plugins, mas é importante estar atento as limitações do engine (esta é só uma URL de exemplo) para nao cair na armadilha do PSD que você mencionou. Temos que lembrar também que o engine de renderização deve ser algo alinhado as necessidades do cliente (se o cliente quiser garantir o Opera por exemplo, independentemente de IE ou FFox, vc pode usar o Presto ao invés do Webkit. Os percentuais dos navegadores foram retirados do w3schools. A URL esta na referência.

    Por fim, uma empresa de desenvolvimento tem que estar sintonizada. Vender pelo PSD não é a melhor maneira, mas o designer que montou a peça tem que entender que usar bordas arredondadas é algo que não poderia ser usado, justamente pela situação que você mencionou (a não ser que ele ofereça uma alternativa válida para o problema do IE). E não é apenas o design; não adianta vendas prometer o mundo se na hora do desenvolvimento alguem chegar para o cliente e falar “no IE não funciona”. Uma proposta tem que estar bem “azeitada” desde as entrevistas iniciais com o cliente ate o dia da homologação. PE é algo que auxilia muito o desenvolvedor no que diz a garantia da usabilidade, acessibilidade e SEO, mas é algo que com certeza, comeca lá na mesa da criacao, quando o cara esta photoshopando um layout ou criando um wireframe. E com certeza, fazendo uma análise macro, PE ajuda muito mais a empresa como um todo do que salva nossa vida de dev.

    Obrigado pelo comentário!
    Abracos

  • Pingback: Tropeçando 36 | Rafael Bernard Araujo

  • http://raelmax.info Rael Max

    Ótimo artigo, estou aguardando os próximos! :)

    Ah, quanto ao site da brastemp, aqui ele não renderiza corretamente(Firefox 3.6.3/ Ubuntu Linux), todo o conteúdo do centro aparece em um espaço na lateral esquerda. “Resolvi” aqui no firebug desabilitando o overflow no seletor #geral.

    =)

  • Robson Sobral

    Sempre começar pelo mais simples. E colocar VIA JS aquilo que só funcionará via js! Pouca coisa é mais irritante do que links apontando para “#” porque resolveram fazer aquela linda janela modal e se esqueceram de quem abre direto em nova janela. E ainda não nos esqueçamos de preparar o CSS para o layout funcionar com e sem os elementos adicionados via JS.

    Para bater minha exata metodologia de trabalho só falta fazer o layout direto do papel quadriculado para o HTML.

    Parabéns. Excelente artigo.

  • http://twitter.com/alyssonfranklin Alysson Franklin

    Obrigado Robson!

  • http://rodrigofante.com Rodrigo Fante

    Excelente artigo Alysson e concordo com você, essa era uma briga minha quando morava em Londres com os outros devs da agência, é muito mais simples desenvolver dando suporte ao básico e depois incrementando do que o contrário.

    Grande abraço

  • http://rodrigofante.com Rodrigo Fante

    ah, e o site da Brastemp está com layout quebrado aqui, jogado mais a esquerda.

    No Chrome para Mac.

  • http://twitter.com/alyssonfranklin Alysson Franklin

    Obrigado Rodrigo! Abraco!

  • getulio

    Parabéns pelo post! Existe só um erro, “AnaliZando” é com S. Abraço!

  • http://twitter.com/alyssonfranklin Alysson Franklin

    opa, typo a vista! Obrigado Getúlio!

  • http://www.felipesetlik.com.br Felipe

    O HTML5 Boilerplate foi testado em duas máquinas aqui no trabalho. Sempre trava no IE7 e IE8, e o comentário é confuso. Parece que precisa logar no DISQUS primeiro, mas até descobrir isso…

  • http://www.allanmc.com.br Allan

    Olá…
    Eu ainda estou iniciando nesse assunto…

    apenas gostaria de saber se essas técnicas de metodologia Progressive Enhancement e Graceful Degradation são desenvolvidas apenas com HTML5?

  • http://www.allanmc.com.br Allan

    Corrijindo minha dúvida:

    Essas metodologias PE e GD de melhoras de acessibilidade e usabilidade são destinadas especificamente/unicamente/somente para o HTML5 e CSS3? Ou não, não tem nada ver (o objetivo seria acessbilidade e usabilidade idependente da programação e versões de html, xhtml, xml, javascript e etc)?

  • http://twitter.com/alyssonfranklin Alysson Franklin

    Ola Allan, tudo bem?

    Sobre sua pergunta, a resposta é: Não necessariamente. PE e GD são tecnicas usadas para garantir que, independente do navegador, a funcionalidade da tela seja a mesma, e a experiência seja a mais próxima dos navegadores mais novos. Exemplo: existem atributos CSS2.1 que sao renderizados de maneira diferente de navegador a navegador, podemos usar PE(ou GD) para garantir que o a margin-left que esta renderizando legal no chrome tenha o mesmo comportamento no ffox por exemplo:

    p {margin-left:90px;}
    p, x:-moz-any-link, x:default {margin-left:-110px;}

    Isso poderia ser considerada uma “forma primitiva” de GD, e nao envolve HTML5, CSS3 ou novidades do genero ;-)

  • Bruno Ferreira

    Muito bom este artigo! Me ajudou muito.

    Abraço.

  • Pingback: O que são e como os Reflows podem ser otimizados para aplcações ficarem ainda mais rápidas. | Tableless - Desenvolvimento com Padrões Web

  • Pingback: Agora é a vez dos desenvolvedores | Tableless

  • Pingback: Boas práticas para E-mail Marketing | Tableless

  • Pingback: Boas práticas para E-mail Marketing | Velame Cursos

  • Pingback: Como começamos o Locaweb Style

  • Pingback: Locaweb Style – Como iniciamos | Dublado

  • Wanderson Miranda

    Já fazem quase 3 anos que esse post foi publicado e minha dúvida é: Com a constante atualização do mundo web, devo considerar este, um assunto antigo? Ou esses métodos ainda estão valendo?

  • Pingback: Fault Tolerance: a base do Progressive Enhancement | Tableless

  • Diego Yungh

    Os métodos ainda valem Wanderson.
    Trabalho hoje como Frontend Engineer com portais de Alto tráfego e o assunto é constantemente abordado e inconscientemente esperado como resultado de aplicações.

    – Graceful Degradation é um must, pois garantir a operabilidade do sistema em todos os meios (por menos rica que seja) sempre foi o objetivo.

    – Progressive enhancement partindo do pressuposto que GD já está aplicada vai ser agora um passo natural, aonde você vai subir a escada aproveitando o que de melhor os navegadores podem oferecer melhorando e facilitando a experiencia do usuário.

    Lembrando que isso não se aplica somente a versão e suporte de navegador, o termo “mobile-first” também remete grosseiramente a isso, é uma forma de GD.