Tableless » Tecnologia e Tendências http://tableless.com.br Tableless - Desenvolvimento inteligente com padrões web Fri, 18 May 2012 12:22:56 +0000 pt-br hourly 1 http://wordpress.org/?v=3.3.2 Documentos poliglotas com XHTML5 http://tableless.com.br/documentos-poliglotas-com-xhtml5/ http://tableless.com.br/documentos-poliglotas-com-xhtml5/#comments Wed, 16 May 2012 13:35:51 +0000 Talita Pagani http://tableless.com.br/?p=6057 Quando se começou a falar massivamente a respeito do HTML5, em 2009, muitos desenvolvedores (inclusive eu) torceram o nariz para o fato de poder voltar a utilizar a sintaxe tolerante do HTML, ou seja, tags em uppercase ou sem fechamento, valores de atributos sem aspas, fechar tags em ordem incorreta, entre outros. Inclusive, comentei especificamente sobre isso em um outro artigo.

Grande parte dos desenvolvedores aprenderam  e se habituaram a utilizar a sintaxe do XHTML, que segue as diretrizes do XML para documentos bem formados e que apresentariam erros de renderização caso essas diretrizes são fossem seguidas. Isto nos permitia códigos mais limpos e bem estruturados. Porém, no HTML5, a escolha é sua e você não será punido por não fechar tags.

Com toda essa preocupação, no mesmo ano começou a ideia do XHTML5, uma tentativa de contornar o problema, adicionando as restrições de marcação do XML a documentos escritos em HTML5. Podemos dizer que seria uma tentativa de unir o melhor de cada especificação. O artigo escrito por Bruce Lawson para o HTML5 Doctor (com versão traduzida no Pinceladas da Web) foi um dos primeiros a comentar sobre o tema.

Durante cerca de 1 ano isto era uma forma, digamos, marginalizada de tratar essa questão, por não ser algo reconhecido pelo  WHATWG / HTML WG. Mas em 2010 surgiu o primeiro draft com a proposta de nortear o uso do HTML5 com a sintaxe do XML/XHTML. O W3C denominou essa metodologia de marcação poliglota.

O que é um documento com marcação poliglota?

Um documento com marcação poliglota é um documento escrito em HTML5 que pode ser processado tanto como HTML quanto como XML dentro de um conjunto de restrições definidas, porém, ainda seguindo a especificação do HTML5. Eles são compatíveis com o HTML e XHTML.

Significa que você pode utilizar todo o poder do HTML5 dentro do padrão de marcação bem formada do XML. É importante ressaltar que isto não afeta as tags que você pode utilizar. Por exemplo, elementos que são considerados deprecated em XHTML mas válidos no HTML5 continuam a ser válidos. Uma exceção é com relação a algumas tags que são excluídas de documentos poliglotas por não serem possível de serem replicadas em um parser XML (como é o caso da tag <noscript>).

Mas em linhas gerais, esta “fusão” não altera a especificação, mas sim as regras de sintaxe para processamento e há influência no DOM também (ex.: document.write não é permitido, mas sim innerHTML).

Segundo o W3C, um documento poliglota resulta em:

  • Um documento HTML5 válido;
  • Um documento XML bem formado (mas não significa um documento XML válido);
  • DOM idêntico quando processado tanto como HTML quanto como XML, isto porque os parsers geram diferentes DOMs para determinados atributos relativos ao XML.

Como escrever um documento poliglota

Um dos principais requisitos para escrever um documento em XHTML5 é o MIME-type utilizado. Isto vai definir se o navegador irá interpretar o documento como HTML ou XHTML. Segundo o WHATWG, um documento HTML5 se torna um documento poliglota se for provido o MIME-type application/xhtml+xml.

1
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=utf-8" />

Até algum tempo atrás, o IE não suportava este MIME-type. Para isso, você pode indicar que o MIME-type é o usual text/html. Ele pode ser utilizado junto com o primeiro (separando por vírgula), ou pode ser feita uma validação do navegador para decidir qual o MIME-type a ser utilizado.

O doctype passa a ser opcional, mas ainda é recomendável utilizar para prevenir o quirks mode dos navegadores. Se utilizado, a palavra doctype deve ser escrito adequadamente em uppercase, ex.: <!DOCTYPE html>. A meta-tag que especifica o charset e a declaração <?xml version=”1.0” encoding=”UTF-8”?> (herdada do XHTML 1.1) também passam a ser opcionais se o charset desejado para o documento é UTF-8 (padrão do XML).

Além disso é preciso definir também o namespace do XHTML na tag <html>:

1
<html xmlns="http://www.w3.org/1999/xhtml">

Ao utilizar recursos como SVG e MathML, é preciso especificar também o atributo xml para a tag raiz correspondente de cada um.

Outras recomendações são:

  • Usar tanto o atributo lang quanto xml:lang na tag <html>;
  • Usar tbody / thead / tfoot em <table>s;
  • Quando o elemento <col> é utilizado em tabelas, utilizar também o elemento <colgroup>;
  • Não utilizar o elemento <noscript>;
  • Não iniciar as tags <pre> e <textarea> com linha em branco;
  • Utilizar innerHTML ao invés de documento.write;
  • Para scripts embutidos na página, escreva o código entre uma seção CDATA com os delimitadores comentados. É uma forma de fazer com que o parser do XML (que analisa apenas a marcação) não acuse erros ao utilizar < ou & no script;
  • Os atributos xml:space e xml:base são permitidos apenas nos elementos relativos a SVG e MathML;
  • Elementos que podem ter conteúdo mas estão vazios não devem ser minimizados para o formato de tag órfã. Ex.: <p /> não deve ser utilizado, mas sim <p></p>.

Ao escrever documentos poliglotas, é possível utilizar todas as funcionalidades do HTML5 com uma garantia de código bem formado de acordo com as restrições do XHTML. Com isso, é possível ter um código mais organizado e consistente que seja mais fácil de produzir, manter e reutilizar a longo prazo, principalmente quando este trabalho é realizado em equipe.

Referências

Polyglot Markup: HTML-Compatible XHTML Documents
XHTML5 in a nutshell
Benefits of polyglot XHTML5
HTML 5 + XML = XHTML 5

Posts Relacionados

]]> http://tableless.com.br/documentos-poliglotas-com-xhtml5/feed/ 13 Adobe: The Expressive Web http://tableless.com.br/adobe-the-expressive-web/ http://tableless.com.br/adobe-the-expressive-web/#comments Fri, 11 May 2012 17:13:45 +0000 Diego Eis http://tableless.com.br/?p=6117 Essa é antiga, mas muita gente ainda não viu!

Mais uma iniciativa da Adobe para divulgar as maravilhas do CSS3 e HTML5. O The Expressive Web é um sitezinho maneiro onde a Adobe mostra alguns exemplos das novas features do HTML5 e do CSS3 com exemplos sensacionais.

The Expressive Web, by Adobe.

Cada uma das features tem uma pequena descrição, e o mais importante, eles mostram uma porcentagem de quantos usuários veriam aquela feature. CANVAS, por exemplo, seria visto por 75% dos usuários, obviamente, dos usuários que usarem browsers novos, como IE9, Safari, Chrome e etc…

Não vá ver isso em um Internet Explorer ruim ou um browser antigo. Estamos falando de web de verdade, aqui. ;-)

Posts Relacionados

]]> http://tableless.com.br/adobe-the-expressive-web/feed/ 6 Adobe e os Padrões Web http://tableless.com.br/adobe-e-os-padroes-web/ http://tableless.com.br/adobe-e-os-padroes-web/#comments Thu, 03 May 2012 22:11:44 +0000 Diego Eis http://tableless.com.br/?p=6068 Depois que o Steve Jobs fez o favor de nos livrar do Flash em seus dispositivos, parece que a Adobe acordou e resolveu entender o que realmente ele estava querendo dizer. Em vez de tentar devorar o mercado com uma tecnologia proprietária, por que não ajudar uma comunidade e os padrões que já existem no mercado?

O pessoal da Apple fez isso com o Webkit. Eles tomaram emprestado o motor de renderização criado pelo pessoal do KDE – com o motor chamado KHTML – e fuçaram, mexeram, arrumaram, criaram e devolveram o resultado para a comunidade como um dos melhores motores de renderização que já existiu, o Webkit.

Em vez de criarem um motor novo, eles resolveram começar de uma base que já estava bem feita, pronta e organizada por uma comunidade forte. O KHTML e o KJS (motor de Javascript do KDE) permitiam o desenvolvimento mais fácil que as outras tecnologias do mercado e detalhe, tinha apenas 140.000 linhas de código! Era limpo e principalmente tinha um bom suporte com os padrões web.

A Adobe Macromedia, sem dúvida, revolucionou a web com a criação do Flash. Eu fui um dos doidos eufóricos quando eles mostraram uma linha se transformando em um circulo. Chorei sangue quando aprendi a manipular a timeline e fiz minha primeira animação. Não estou dizendo que o Flash é um lixo. Estou dizendo que o Flash fez o seu papel. Todo mundo achou que a Apple desistiria da decisão, mas não foi o que aconteceu. Eles se mantiveram firmes e isso, felizmente, agitou o mercado. Ajudou na divulgação da importância dos Padrões Web e impulsionou muito o HTML5 e o CSS3, que até então apenas o W3C e a comunidade estavam incentivando a sua utilização.

Depois da atitude da Apple de barrar o Flash de seus aparelhos, o que a Adobe faria? Quando a Adobe percebeu que seu software não teria vez, ela foi obrigada a seguir outro caminho. Graças ao grande senhor das montanhas indígenas extraterrestres, eles tomaram o caminho correto. A Adobe tem tido algumas iniciativas para ajudar os desenvolvedores a criarem websites melhores. Se não pode com eles, junte-se a eles.

Para você entender o que eu quero dizer, a Adobe criou um http://html.adobe.com para divulgar suas iniciativas para com a comunidade de desenvolvedores. As ideias expostas no site são sensacionais e eu, particularmente, quero muito que tudo se torne verdade. Separe um tempo e visite esse site. Você não vai perder nada.

Eles tem um software interessante que te ajuda a testar a responsividade do seu layout em diversos aparelhos e tem algumas sugestões de novos padrões que poderão nos ajudar demais em desenvolvimentos específicos. Leia sobre o CSS Regions e o CSS Shaders. Tem também o PhoneGap.

Parabéns para Adobe.

Posts Relacionados

]]> http://tableless.com.br/adobe-e-os-padroes-web/feed/ 11 Drops 7 – Você está fazendo errado http://tableless.com.br/drops-7-voce-esta-fazendo-errado/ http://tableless.com.br/drops-7-voce-esta-fazendo-errado/#comments Thu, 05 Apr 2012 04:14:02 +0000 Diego Eis http://tableless.com.br/?p=5910 Tem designers trabalhando com web que não entendem HTML/CSS. Tem programadores que ainda insistem em aprender apenas a linguagem server-side e ficam se lixando para HTML. Tem desenvolvedores de interface que não estão nem aí pra semântica, css bem escrito e caem na bobeira de ficar discutindo assuntos superficiais como abordar ou não abordar determinado browser, ou o Flash é melhor que HTML e vice-versa.

Posts Relacionados

]]> http://tableless.com.br/drops-7-voce-esta-fazendo-errado/feed/ 29 Project Glass http://tableless.com.br/project-glass/ http://tableless.com.br/project-glass/#comments Wed, 04 Apr 2012 18:29:36 +0000 Diego Eis http://tableless.com.br/?p=5905 Eu estou separando um tempo frequentemente para ler sobre tecnologias que podem nos influenciar no futuro. Gosto muito de tentar imaginar como a web será daqui um tempo e como nós, desenvolvedores, designers, profissionais de usabilidade e acessibilidade podem se adequar em um lugar onde os browsers, realmente, serão secundários. Comece vendo o vídeo da HP, mostrando a Cooltown, feito há alguns anos.

Hoje surgiu um vídeo no Brain9, sobre uma iniciativa do Google para um óculos que usa a tecnologia ao nosso favor, em tarefas simples e diárias. É uma interação totalmente diferente. Veja abaixo:

Quantos browsers você viu ali? Se não viu nenhum browser, pergunte-se sobre HTML, o CSS e Javascript? Será que escreveremos CSS e HTML em tempos assim? E se escrevermos, como será? E se não escrevermos, o que estaremos fazendo? Designers, como vocês se encaixam nesse cenário? Programadores, como vocês se veem em um ambiente como este? Como vai ser programado?

Em um ambiente como esse não existe responsive web design. Não existe layout para mobiles. não existe ficar brigando se faz ou não faz sites para IE. Eu estou colocando aqui um pensamento muito, mas muito superficial. Algumas respostas são óbvias outras nem tanto. Mas são óbvias para quem?

Estou mudando muito o foco aqui do Tableless. Quero falar mais sobre comportamento e mercado do que tutoriaizinhos e truquezinhos com CSS. Você consegue encontrar isso fácil na web. O problema é que a grande maioria dos desenvolvedores brasileiro não tem base conceitual nenhuma. Muitos não entendem como funciona o negócio. Isso é sério. Para mim é mais importante que assuntos técnicos.
Tem designers trabalhando com web que não entendem HTML/CSS. Tem programadores que ainda insistem em aprender apenas a linguagem server-side e ficam se lixando para HTML. Tem desenvolvedores de interface que não estão nem aí pra semântica, css bem escrito e caem na bobeira de ficar discutindo assuntos superficiais como abordar ou não abordar determinado browser, ou o Flash é melhor que HTML e vice-versa.

Mas esse post não é sobre isso. Aproveite o vídeo e pense nisso! ;-)

Posts Relacionados

]]> http://tableless.com.br/project-glass/feed/ 12 Devs decidem deixar o SVG e adotar o Flash http://tableless.com.br/devs-decidem-deixar-svg-e-adotar-o-flash/ http://tableless.com.br/devs-decidem-deixar-svg-e-adotar-o-flash/#comments Sun, 01 Apr 2012 03:00:48 +0000 Diego Eis http://tableless.com.br/?p=5855 Depois de muita discussão e debate entre a comunidade e alguns grupos, os desenvolvedores de todo o mundo decidem adotar o Flash como padrão em detrimento ao SVG.

Como praticamente 100% dos browsers existentes tem suporte ao Flash – inclusive browsers antigos como o IE6 – nada mais inteligente do que adotar essa tecnologia como um novo padrão. O Flash também já conta com seu IDE feito pela Adobe, possibilitando a criação de animações e games facilmente por uma interface intuitiva e livre de código, enquanto para fazer animações no SVG ou outras tarefas, o desenvolvedor precisa saber Javascript e pasme, HTML também!

A ideia é que os desenvolvedores aproveitem a penetração (ui!) do Flash para criarem mais conteúdo multimidia, rico em experiência para o usuário e sites mais interativos.

Quanto a pergunta sobre a falta de suporte do Flash em aparelhos da Apple, especialistas responderam que se até o IE6 suporta Flash, a Apple deveria abrir mão da bundamolisse e adotar também essa maravilhosa tecnologia.

E você, o que acha disso?

Posts Relacionados

]]> http://tableless.com.br/devs-decidem-deixar-svg-e-adotar-o-flash/feed/ 49 Acessibilidade, como mudar o Brasil? http://tableless.com.br/acessbilidade-como-mudar-o-brasil/ http://tableless.com.br/acessbilidade-como-mudar-o-brasil/#comments Tue, 27 Mar 2012 15:13:33 +0000 Elcio Ferreira http://tableless.com.br/?p=5810 Esse não é apenas um artigo para você se informar. Pelo contrário, é o que eu menos pretendo com ele. É um chamado à ação!

O tema é Acessibilidade na Web. Trata-se de, ao construir um site, fazê-lo para que seja acessível para qualquer pessoa, em qualquer dispositivo, em qualquer conexão. Trata-se de fazer o site acessível para você mesmo quando estiver navegando no celular, ou sem óculos, ou de uma conexão lenta, ou dirigindo. Ou dirigindo ao celular sem óculos numa conexão lenta (cuidado!) Também, é claro, esse trabalho vai tornar o site acessível para portadores de deficiência.

Acessibilidade não deveria ser um extra, mas uma obrigação básica em projetos web. Não simplesmente porque é politicamente correto, mas porque é muito mais barato pensar em acessibilidade desde o princípio. Se você deixa para pensar em acessibilidade depois que o site já foi desenhado, isso é caro e trabalhoso. Mas se a preocupação com acessibilidade está presente desde o início do projeto, conduzindo o desenho, o custo de criar sites acessíveis é muito pequeno.

Apesar disso, vemos o tempo todo agências e produtoras web construindo sites inacessíveis. E aqui eu gostaria de sua ajuda. O que podemos fazer para mudar isso? Como conscientizar os clientes e as agências da importância da acessibilidade? O que podemos fazer para que os novos sites sejam construídos tendo essa preocupação? Que tipo de ações, campanhas, conteúdos, eventos, iniciativas deveríamos nós, a comunidade brasileira de desenvolvedores web, promover para mudar essa realidade?

Por favor, comentários.

Mais comentados

]]> http://tableless.com.br/acessbilidade-como-mudar-o-brasil/feed/ 11 Qualidade de Imagens e densidade de pixels http://tableless.com.br/qualidade-de-imagens-e-densidade-de-pixels/ http://tableless.com.br/qualidade-de-imagens-e-densidade-de-pixels/#comments Mon, 26 Mar 2012 13:13:42 +0000 Diego Eis http://tableless.com.br/?p=5781 Você se lembra quando planejavamos nossos layouts para resoluções acima de 1024? Chega ser engraçado lembrar que um dia fizemos websites para 640×480, pensando que a resolução de 1024×768 eram a minoria dos usuários. Os tempos mudaram e naturalmente diversas outras resoluções apareceram por conta de novos dispositivos, melhores monitores e etc. Acontece que na web nada é tão fácil assim. A gente se livra de um problema, mas aparece outro no lugar.

Este ano eu estou trabalhando a maior parte do tempo em um monitor fullHD. Notei uma diferença gritante ao digitar código pela primeira vez em um monitor desses. E não são apenas os monitores que estão mudando para uma resolução decente. Também, seguindo o ciclo natural, dispositivos menores estão recebendo a dádiva de ter a alta resolução em suas telas. E isso, meu caro, é uma dádiva para o usuário, para você é mais trabalho. ;-)

Pixels não são mais como eram antigamente

Na minha época de escola – nem tanto tempo assim – os professores me ensinaram que o átomo era indivisível. Era incrível por que eu, como criança, me divertia tentando entender como algo poderia ser tão pequeno que não pudesse ser partido ao meio, ficando menor… Mas aí eu descobri que os prótons, os elentrons e outras partículas subatomicas existiam também…

A mesma coisa aconteceu com o pixel. O pixel sempre representou a menor unidade da sua tela. Para os designers, o pixel é a unidade central. É onde tudo se baseia: medidas, tamanhos, alinhamentos etc… Mas o pixel não é mais como era antigamente.

Com o advento das telas HD em aparelhos móveis, o conceito de pixel mudou um pouco muito. Quando a tela retina display do iPhone 4 foi lançada o queixo de todo mundo caiu. A Apple conseguiu apertar quatro pixels onde apenas caberia um. Logo o pixel pode ser definido como a menor unidade na tela, como você já conhece ou pode ser baseada em uma unidade chamada hoje em dia de “pixel referência” ou do inglês reference pixel: que significa que esse novo “pixel” é uma referência ótica de unidade.

Para entrar em detalhes, leia o que é um pixel. Vai te ajudar a entender melhor.

Densidade de pixels

A sigla DPI significa Dots Per Inch, ou seja, é o número de pixels que seu dispositivo pode conter em uma polegada. Quanto mais pixels em uma polegada, mais nítida a imagem é.

Os aparelhos como o iPhone 4 e outros que carregam Android tem uma densidade de pixels muito alta. Ou seja, eles conseguem comprimir um grande número de pixels em suas telas, tornando as imagens melhores. O problema é que as imagens que criamos hoje podem parecer ruins nesses dispositivos. Algo parecido como aumentar uma imagem pequena no Photoshop, entende? Ela fica toda pixelada, sem qualidade nenhuma. Isso por que você está aumentando o tamanho de uma imagem que é pequena e não tem pixels suficientes para dividir pelo tamanho que você definiu.

Entenda fazendo um teste: Vá até o site da Apple utilizando SAFARI. Agora, dê um zoom em alguma imagem. Veja como ela parece pixelada por causa do zoom. Agora abra o Inspector do seu navegador, vá até o console e coloque as duas linhas abaixo:

1
2
AC.ImageReplacer._devicePixelRatio = 2
new AC.ImageReplacer()

A imagem foi trocada para uma imagem com o dobro de tamanho da imagem original para que ela ficasse melhor em telas com alta densidade de pixels… Veja a diferença. Eu vi esse truque aqui.

Ações para otimizar

Existem algumas atitudes que vocês já pode tomar agora para poder chavear estes aparelhos e entregar uma experiência melhor para seus usuários.

Utilize media queries

Media Queries são um chuchuzinho. Você pode utilizar uma regra chamada device-pixel-ratio para detectar qual CSS servir dependendo do pixel-ratio do dispositivo. Não precisa ser maníaco e servir vários CSS para vários pixel-ratios… Você vai ficar doido se fizer isso.

Abaixo veja uma tabela de exemplos de aparelhos com seus valores de pixel-ratios:

Dispositivo Resolução device-pixel-ratio
Android LDPI 320×240 0.75
Iphone 3 & Android MDPI 320×480 1
Android HDPI 480×800 1.5
Iphone 4 960×640 2.0

Agora, como seria o CSS:

1
2
3
4
<link rel="stylesheet" media="screen and (-webkit-device-pixel-ratio: 0.75)" href="low-dpi.css" />
<link rel="stylesheet" media="screen and (-webkit-device-pixel-ratio: 1.0)" href="medium-dpi.css" />
<link rel="stylesheet" media="screen and (-webkit-device-pixel-ratio: 1.5)" href="high-dpi.css" />
<link rel="stylesheet" media="screen and (-webkit-device-pixel-ratio: 2.0)" href="retina.css" />

Eu sugiro que você se limite apenas para o pixel-ratio 2. Do jeito que as coisas estão andando, os aparelhos de pixel-ratio menor do que 2 desaparecerão logo e os aparelhos com pixel-ratio igual a 1 são maioria e você já faz versões para eles, já que não precisam de fallbacks.

Considere chavear versões de imagens

Este é um problema que ainda não existe uma solução inteligente e definitiva.
A ideia é tentar evitar que o usuário baixe duas imagens iguais, mas de tamanhos diferentes para cada tipo de necessidade. Logo, existem vários fallbacks, em Javascript ou linguagens server-side para servir apenas a imagem necessária.

O pessoal da Clound Four escreveu um artigo muito interessante sobre isso.

Há outros artigos bons por aí. Eu estou dando uma lida em vários para tentar escrever um artigo mais simples aqui no Tableless. Mas o assunto é muito vasto e ninguém tem uma opinião definida ainda. Isso não é útil apenas para a situação dos aparelhos hires, mas também para encontrarmos maneiras de servir imagens menores para versões de sites mobiles.

Text rendering

Você consegue melhorar muito a leitura dos usuários utilizando a propriedade text-rendering.

1
h1, h2, h3 { text-rendering: optimizeLegibility; }

Esta propriedade melhora muito a leitura quando o usuário dá o zoom nos aparelhos móveis e também corrige suporte de ligaduras e kerning. Coisa linda.

Text Smoothing

A propriedade font-smoothing é útil agora! A leitura melhora demais em monitores normais e previne serrilhamentos ocasionais quando utilizandos @font-face.

1
2
3
4
5
6
7
body * {
-webkit-font-smoothing: antialiased;
-moz-font-smoothing: antialiased;
-o-font-smoothing: antialiased;
-ms-font-smoothing: antialiased;
font-smoothing: antialiased;
}

Tente usar CSS3

Tente usar e abusar dos efeitos do CSS como sombras, gradientes, bordas arredondadas e etc. Além de facilitarem sua vida evitando a criação de imagens desnecessárias, elas ajudam na velocidade de carregamento do site.

Considere utilizar SVG

Já tem alguns que estão começando a utilizar SVG para facilitar a vida. Para ícones, SVG é ótimo. Você consegue reutilizá-los em diversos tamanhos, aumentando o diminuindo de acordo com a sua necessidade e também do aparelho. Veja um exemplo que a Smashing Magazine escreveu.

Novo elemento HTML

O W3C já criou um grupo chamado Responsive Images Community Group para a criação de elementos do HTML que facilitam a entrega de assets dependendo do contexto. Eles estão propondo um novo elemento que identifica as dimensões do dispositivo, velocidade de rede, densidade de pixels e outros pontos para servir melhor imagens e outros assets dependendo do contexto.

Muitos artigos para ler

Posts Relacionados

]]> http://tableless.com.br/qualidade-de-imagens-e-densidade-de-pixels/feed/ 6 Responsive Web Design – focando a coisa certa http://tableless.com.br/responsive-web-design-voce-esta-fazendo-isso-errado/ http://tableless.com.br/responsive-web-design-voce-esta-fazendo-isso-errado/#comments Tue, 20 Mar 2012 12:58:46 +0000 Diego Eis http://tableless.com.br/?p=5718 Eu andei pensando em um assunto e procurando sobre encontrei um artigo, fresquinho, no Brad Frost que veio de encontro ao que eu estava matutando. Eu escrevi em tempos passados um artigo sobre por que estávamos desenvolvendo apenas para iPhone. Foi aí que começamos a pensar em versões mobiles. Mas fazíamos versões mobiles dos nossos sistemas e websites simplesmente sem entender quando a necessidade de ter um site mobile era real. Muitas empresas gastaram uma boa grana para ter sua versão mobile, mas apenas para se manter na moda.

Agora, a bola da vez é criar designs responsivos como se não houvesse o amanhã. É aí que entra a pergunta: você precisa de um design responsivo?

A maioria dos browsers para dispositivos móveis fazem um bom trabalho em websites que não tem versão específica para mobiles. Desde a vinda do iPhone, todos os browsers para mobiles se adequaram de uma forma que antes apenas o Opera abordava. Hoje, quando navegamos em qualquer website, tendo ou não versão para mobile, temos uma boa experiência. Aí vem o ponto: será que criar um site responsivo é o mais importante para o negócio do seu cliente? Produzir um website mobile friendly não é apenas modificar sua carinha, colocar ícones bonitinhos e pronto. Há outros pontos a serem abordados que são tão ou mais importantes que este.

Veja um comentário do Brad Frost em seu artigo:

Your visitors don’t give a shit if your site is responsive. They don’t care if it’s a separate mobile site. They don’t care if it’s just a plain ol’ desktop site. They do give a shit if they can’t get done what they need to get done. They do give a shit when your site takes 20 seconds to load. They do care when interactions are awkward and broken.

Entende o que eu quero dizer? Um dispositivo móvel já é mais dinâmico por natureza que os desktops. Os aparelhos móveis de hoje em dia nos fazem querer os resultados mais rapidamente. Se você tiver um website desenhado apenas para desktops, mas mesmo assim ele é rápido, os usuários de mobile vão agradecer. Já vi muitos websites mobiles que foram apenas adequados… Isso não é produzir um site mobile. Se seu site é bem desenhado e sua usabilidade impecável, ter um design responsivo passa a ser secundário e você passa a dar atenção coisas mais importantes, por que mesmo sendo uma versão desktop, o usuário conseguirá navegar sem muitos problemas.

Mas você quer dizer que sites mobile não importam?

Não, não quero dizer isso. Pelo contrário, eles importam e muito. A experiência do usuário é muito melhor se houver uma versão mobile, sem sombra de dúvida. Mas do que adianta ter uma versão mobile se o site demora 20 segundos para carregar? O dev cria a versão mobile, mas ele não faz adaptação nenhuma nas imagens (e não estou falando apenas de mudar a dimensão dela), não usa com inteligência o font-face, que embora seja maravilhoso, come muita banda… Acontece que ter carinha bonita não quer dizer que é fácil de usar.

Experiência de usuário é o foco

O foco é buscar a melhor experiência possível que o usuário pode ter em seu dispositivo. Nós usamos responsive web design para levar a experiência do usuário para outro nível. Não apenas por que está todo mundo fazendo. Você não precisa fazer seu site se adequar ao redimensionar a janela. É bonito? Sim, claro, mas só pra impressionar, porque não é muito útil se você parar para pensar.

No front-end, a experiência do usuário vai muito além do design. Responsive web design não é uma modinha é mais uma ferramenta para usarmos em pról da boa experiência do usuário. É por isso que na construção dos nossos projetos, podemos iniciar o trabalho pensando primeiramente nos mobiles e depois nos desktops. Isso nos faz mirar em objetivos mais importantes, não apenas para mobiles, mas para os desktops também, bem como tablets, tvs e todo o resto que vem por aí.

Alguns artigos para você dar uma olhada:

Posts Relacionados

]]> http://tableless.com.br/responsive-web-design-voce-esta-fazendo-isso-errado/feed/ 8 Seu lugar ao sol http://tableless.com.br/seu-lugar-ao-sol/ http://tableless.com.br/seu-lugar-ao-sol/#comments Mon, 12 Mar 2012 11:45:26 +0000 Diego Eis http://tableless.com.br/?p=5682

Você realmente acha que vai escrever CSS e HTML como escreve hoje em um cenário como este?
Você já parou para pensar onde CSS/HTML e Javascript se encaixam em um ambiente onde a web é praticamente camuflada por APPs específicos? Eu não estou me referindo a estes Apps como conhecemos hoje. Podem ser Apps instaladas ou WebApps, neste futuro, dá na mesma. Não há diferença.

Pior do que pensar o lugar que CSS e HTML estarão é pensar em como VOCÊ se colocará em um ambiente tão novo quanto este. O que realmente iremos fazer? Qual será o papel de cada um? Será que a metodologia de trabalho será a mesma?

Você também já deve ter visto o vídeo acima. Veja como os personagens utilizam seus gadgets e como tudo está sincronizado. A discussão aí não é se é melhor criar uma App ou uma aplicação Web, é se o seu produto é realmente relevante e se vai ajudar realmente a vida das pessoas. A forma como isso é oferecido não importa, porque em um cenário como esse tudo é igual. Não faz diferença nenhuma. A Web não é só o seu browser.

É por isso que eu acho que os desenvolvedores precisam acordar. Urgente.
Eu perco as contas de quantos desenvolvedores me castigam quando eu digo para ignorar totalmente os browsers antigos. Você acha que um futuro como mostrado nos vídeos ou qualquer outro tipo de futuro, vai ficar esperando um browser ser adequado aos padrões? Aliás, browsers existirão?

Você precisa repensar o que realmente é vida digital. Qual a real utilidade de se carregar um celular dispositivo móvel. Repense o que será design responsivo. Eu sei que a necessidade de hoje é adaptar websites e aplicações para as diversas telas, mas entende que isso é só uma necessidade que vai passar rápido? Vai passar rápido não porque é uma modinha sem importância, mas porque isso deverá ser padrão daqui pra frente. Assim como o Tableless. Lembra que falavam que isso era uma modinha e que já já passaria? Pois é.

Experimente fazer o exercício de entender o futuro da web. É algo que todo profissional web deveria fazer, principalmente os desenvolvedores. Não importa qual linguagem de programação você vai precisar aprender ou desaprender, o que importa é como ela será aplicada. Isso muda tudo.

Embora a ideia não seja apenas direcionada a Mobile mas para todos os meios de acesso, vale muito a pena ver a apresentação que o Michel Lent fez. Dá uma olhada:

Repensando o marketing a partir do mobile

Posts Relacionados

]]> http://tableless.com.br/seu-lugar-ao-sol/feed/ 15