Cada um destes personagens tem papéis importantes para que a evolução da web possa se tornar forte, traçando novos caminhos, cobrindo as necessidades atuais dos usuários e prevendo necessidades e soluções futuras. Há um ciclo para que estes personagens possam cumprir com seus objetivos.

O W3C cuida dos padrões. Ele tem ideias, ele prevê problemas e tenta solucioná-los. O W3C não aplica, ele apenas planeja. É um trabalho difícil, por que é necessário uma visão muito apurada do cenário da web para saber quais caminhos ela deverá tomar. Uma decisão errada, pode acarretar problemas que levarão anos para serem solucionados por completo. Vide o desenvolvimento com tabelas. Por isso esse trabalho de planejamento deve ser meticuloso. Devo confessar que em muitos casos o W3C não supera as expectativas e faz com que iniciativas paralelas surjam e direcionem a Web para um caminha mais correto. Foi o que aconteceu com o HTML5.

Os browsers, por sua vez, precisam entender e adotar as idéias do W3C, absorvendo as soluções e criando suporte nos seus softwares. Esse trabalho também tem seus perigos. Os browsers precisam pesquisar quais das necessidades dos desenvolvedores é mais importante e assim implementá-la para que a utilização de projetos seja executada. Obviamente que alguns decidem suportar aquelas soluções que darão mais pontos estratégicos contra o concorrente.

Finalizando o ciclo, os desenvolvedores aplicam tudo o W3C define, mas apenas aquilo que os browsers “querem” ou podem suportar. E isso, claro, faz com que o desenvolvedor se depare com problemas na ponta produção. Vide o IE6/7/8 e nossos problemas de cada dia.

Durante muito tempo, esse ciclo não era afinado. Havia uma certa confusão e um jogo de interesses próprios envolvendo principalmente os browsers. O W3C estava apenas pensando em como resolver problemas que talvez existiriam daqui longos anos. Os browsers estavam apenas interessados em criar uma massa de usuários suficiente para ser o primeiro no ranking. Os desenvolvedores, por sua vez, queriam ganhar seu dinheirinho, fazer o trabalho, entregar pro cliente e acabar com o problema.
Ninguém deu atenção quando começamos a desenvolver com tabelas, fazendo com que os sites ficassem mais pesados, aumentando o tempo de desenvolvimento e o custo do projeto.

Este ciclo defeituoso foi praticado durante muito tempo. Por incrível que pareça, foram os Desenvolvedores que começaram a fazer o ciclo funcionar novamente como deveria. Eles acordaram os fabricantes de browsers e também o W3C.

O W3C passou a pensar mais em problemas presentes. Solucionou problemas iminentes e que entregavam valor para os projetos.

Os browsers suportaram o mais rápido possível essas mudanças, atualizando seus engines, e fortalecendo as bases para novas soluções e flexibilizações posteriores.

Já os desenvolvedores estagnaram. Desculpe-me, serei um pouco revoltado daqui para frente. Os desenvolvedores dormiram. Quando o W3C e os browsers apresentaram soluções para problemas como transparência, bordas arredondadas, backgrounds inteligentes, utilização de fonts remotas e etc, os desenvolvedores resolveram que não era a hora dessas soluções por causa da retrocompatibilidade com browsers antigos, como o IE6. Na verdade estou sendo meio injusto aqui. Não foram todos os desenvolvedores que criaram caso com a retrocompatibilidade, foram somente os idiotas.

Nós reclamávamos que precisávamos de recursos mais inteligentes para trabalhar. Que precisávamos de idéias realmente inovadoras, que transformassem os projetos e facilitassem o desenvolvimento. Protestamos, escrevemos manifestos, postamos em nossos blogs revoltados com a falta de visão do W3C e com a pobreza do suporte dos browsers. E quando conseguimos o que queríamos, demos para trás. Amarelamos. Pedimos arrego.

Infelizmente, via-se muito disso aqui no Brasil do que no resto do mundo. Ouvi muitas desculpas como: – “Mas meu cliente usa IE6.” ou “Mas isso não funciona em IE6.” Você é desenvolvedor. Você trata com seu cliente todos os dias. Você tem o poder de educar e convencer. E se você acha que não tem poder nenhum, por que ainda trabalha com web?

Talvez isso seja trauma do passado. Talvez não. O fato é que não podemos mais nivelar por baixo. Isso é atrasar uma “evolução” inteira.

Tenho incansavelmente falado sobre Graceful Degradation, Enhanced Progressive, HTML 5, as maravilhas do CSS 3 e etc, pois esse é o assunto que rola lá fora. Há desenvolvedores e empresas, que acham que devemos ter uma autorização especial dos gringos para utilizarmos novas tecnologias e principalmente para deixar os browsers antigos no passado.

Esse assunto me faz pensar em outra pergunta: Estamos (você está?) preparados para o ritmo alucinante do W3C e dos browsers?
Até a Microsoft está cumprindo com a palavra de ter um browser atualizado. Eles já anunciaram o novíssimo Internet Explorer 10, com uma série de atualizações que promete trazer o IE para o patamar de browsers atuais.

O mercado de client-side se transformará rapidamente nos próximos anos. Muitas mudanças no HTML e no CSS serão publicadas com o intuito de tornar a web mais homogênea, flexível, portável. O HTML 5 não é só uma coleção de novas tags e APIs. O CSS 3 não ganhou só bordas arredondadas. E nem só de iPhone vive o homem. Existem milhares de Nokias, Blackberrys, Windows Phones e Androids por aí.

Os desenvolvedores precisam acordar.

Artigo originalmente publicado em Nov/2009 na revista TI Digital.

Posts Relacionados

• Introdução aos padrões de codificação
• ePub: Aprenda a criar um livro digital
• CSS1K
• Um pensamento sobre design para web
• Introdução das premissas dos controles de versão

Posts Relacionados

• ePub: Aprenda a criar um livro digital
• Sobre Internet Explorer para Mobile – Breve impressão
• Agora é a vez dos desenvolvedores
• Introdução aos padrões de codificação
• Um pensamento sobre design para web

Definir padrões é normal para que a equipe inteira escreva o código da mesma maneira. Esse assunto é longo e muito importante para todas as equipes de desenvolvimento. Programadores já quiseram me matar várias vezes porque eu uso TABS em vez de ESPAÇOS em arquivos Python/PHP. Programadores gostam de espaços. Eu não. Mas não é o nosso gosto que vai definir quais os padrões de código que devemos seguir.

Quando definimos padrões e boas práticas, garantimos que todos da equipe conseguirão ter o mínimo de entendimento do código daquele projeto que está na empresa a tempos. Se alguém da equipe adoecer ou precisar ir para o Canadá, outro integrante pode assumir o seu lugar sem precisar se preocupar em aprender novas regras, porque elas devem ser as mesmas do projeto anterior.

É importante que os integrantes da equipe sejam sempre fiéis aos acordos firmados no momento em que combinam esses padrões. É importante também que, caso eles encontrem um integrante fora da lei, que eles forcem o meliante a seguir as regras. Já vi gente perdendo o trabalho de uma semana por que estava trabalhando diretamente pelo FTP e o projeto não estava no GIT. O programador simplesmente APAGOU o projeto da pessoa. Nunca mais ela resolveu editar os arquivos fora do controle de versão. Esse tipo de atitude é perigosa mas muito necessárias às vezes. Devemos forçar as regras num ambiente onde todos devem quem, quando e como as linhas de código do projeto foram escritas.

Alguns pontos para se pensar e combinar:

Identação

Como devemos identar o código? Com espaços ou tabs? Se for com espaços quantos?

Espaços em brancos (Whitespaces)

Espaços devem ser incluídos depois de uma operação condicional? Espaços devem ser colocados entre o seletor e as chaves? E no final de cada linha, precisa?

Nomenclatura

Como as classes, ids e variáveis devem ser nomeadas? E as funções? Vamos usar CamelCase?

Comentários

Como faremos com os comentários? Como serão os delimitadores do comentário? O comentário deve ser completo ou precisa ser algo mais resumido?

Arquivos

Como os arquivos, que não fazem parte da estrutura padrão do CMS, Framework e etc deverão ser chamados? E o nome das pastas? Como as páginas serão chamadas?

Chaves e ponto/vírgula

As chaves deverão ser abertas na mesma linha ou devemos quebrar linhas? Vamos sempre usar ponto/vírgula? Vamos usar o padrão K&R ou Allman?

Quando definimos estas pequenas coisas, diminuímos muitos percalços no meio do caminho. Já vi projetos atrasarem meses por que um palerma abriu e salvou arquivos com o charset diferente do que já tinha sido combinado no início.

“It’s more important for people on a team to agree to a single coding style than it is to find the perfect style.” Building Scalable Web Sites: Building, Scaling, and Optimizing the Next Generation of Web Applications
Indico este livro sobre esse e outros assuntos sobre a construção, desenvolvimento e manutenção de websites

Posts Relacionados

• Agora é a vez dos desenvolvedores
• ePub: Aprenda a criar um livro digital
• Introdução das premissas dos controles de versão
• Boas práticas de Acessibilidade
• CSS1K

O que você tem que fazer é simples:
- Você só pode enviar CSS.
- O seu código CSS deve ter 1K (1024 bytes), minificado.
- Não precisa utilizar prefixos de browsers, eles colocarão lá para você, logo, você pode usar as coisas bacanas de CSS que só funcionam em browsers (não o IE).
- O Design não precisa ficar igualzinho em todos os browsers, mas gracefull degradation é uma boa pedida.
- Seu código é submetido sob a licensa MIT.

Eles dão o código HTML que você não pode modificar em hipótese alguma, se não acaba a graça da brincadeira.

E aí, consegue?

Posts Relacionados

• Agora é a vez dos desenvolvedores
• Um pensamento sobre design para web
• ePub: Aprenda a criar um livro digital
• Introdução aos padrões de codificação
• Experiência cross-device

A boa experiência no design de impresso depende muito da arte inspiradora do designer, qual o papel usado, que tipo de impressão, da gráfica… em web dependemos muito do tamanho da tela, do dispositivo utilizado, do browser, da configuração do texto, velocidade da internet e do computador. São muitas variações para tentarmos manter o controle de cada detalhe.

Quando um designer faz peças para uma campanha ou algum projeto offline, dependendo do caso é necessário criar peças para diversos formatos de veiculação em outdoors, revistas, posters etc. Em relação a web, nós temos todos os formatos de telas que envolvem tablets, notebooks, monitores, TVs e celulares… Com um diferencial: cada uma dessas telas tem um tipo de comportamento diferente dependendo da manipulação do dispositivo e também do usuário. Em alguns dispositivos como tablets e mobiles em uma tela temos dois formatos: retrato e paisagem. Já no impresso não há manipulação pelo usuário. A estimulo é totalmente visual e muitas vezes tátil. Mesmo assim, a experiência que a web entrega é totalmente outra.

No design impresso, quanto mais proporcional, harmoniosa e equilibrada for a peça, melhor será recebida. No design para web também, mas os layouts precisam ser harmoniosos em cada um dos dispositivos, precisa ser proporcional em cada navegador, além da acessibilidade para alcançar usuário distantes.

Mas em ambas a personalidade é a plataforma para a emoção do usuário. Seja online ou offline, o layout, a forma com que o usuário o consome deve leva-lo para uma experiência diferente do normal. E não estou falando de hotsites feitos em flashs ordinários puramente comerciais.

Eu queria ser designer para entender melhor os conceitos que envolvem esse assunto e talvez explicar tudo isso com mais propriedade.

Assim como não é possível escrever uma linha de código sem saber os porquês da importância do código semântico e acessível, não é possível desenhar um website sem ter a plena certeza de que qualquer usuário terá uma experiência envolvente e agradável.

O design para web está mudando de novo outra vez por causa da explosão de novos dispositivos. Se você ainda não parou para pensar, pense: faça as contas das telas: notebooks, monitores, tablets e smartphones. Sendo que cada uma destes tipos de telas tem diversas variações de tamanho e principalmente de resoluções. Já disse que a experiência do usuário precisa ser cross-device, caso contrário, algo se perde.

Eu queria mesmo era fazer um carro.

Posts Relacionados

• Experiência cross-device
• Agora é a vez dos desenvolvedores
• CSS1K
• Utilizando APPs em vez de browsers
• ePub: Aprenda a criar um livro digital

O artigo do Scott Jenson começa dizendo que a popularização dos smartphones são apenas o começo. Juntando o barateamento das peças para a produção destes aparelhos com a criação sistemas de baixo custo e acessíveis como o Android, não só estão surgindo dispositivos baratos capazes de fazer tarefas que antes eram possíveis apenas em computadores, mas dispositivos baratos baseados na web, trazendo uma experiência cross-device nunca antes experimentada. Um exemplo disso é quando utilizamos estes dispositivos integrados com aplicações como o sistema de som Sonos. O Scott Jenson chamada de Zombie Apocalypse dos eletrônicos.

O paradigma dos computadores desktops estão nos impedindo de enxergar novos caminhos não tão longes assim. Isso é totalmente evidente quando falamos sobre smartphones, no qual nós sabemos que não são computadores desktops e tão somente por isso nós temos outras experiências e outras abordargens quando estamos usando aparelhos deste tipo. Perceba que diversos serviços e aplicações estão sendo portados para os dispositivos móveis porque fazem mais sentido nesse meio. O Twitter mesmo foi criado inicialmente para publicações vindas apenas pelos smartphones. Foi um processo reverso.

Me lembro que aqui no Brasil o recebimento de SMS internacional era um problema em algumas operadoras. Muitos queriam utilizar o Twitter, mas não podiam atualizar suas timelines ou receber as atualizações dos seus colegas porque o Twitter, naquela época, era baseado em SMS. Foi aí que a plataforma se popularizou mais lá fora e então a possibilidade de atualizar sua timeline por outros meios surgiu.

Há uma frase interessantíssima no artigo de Scott Jenson onde ele diz assim:

This problem is simple, but pernicious: designers think of new technologies in terms of yesterday’s tasks, failing to clearly see the real potential of the new technologies.

Minha tradução livre: “O problema é simples mas pernicioso: os designers pensam nas novas tecnologias baseando-se nas tarefas de ontem, falhando em ver claramente o real potencial das novas tecnologias.”

Muito óbvio. É por isso que o Windows Mobile falhou! A Microsoft durante muito tempo liderou o mercado de sistemas para mobiles com um sistema ruim, bugado e muito, mas muito inútil, simplesmente porque eles eram praticamente os únicos. O problema com o sistema deles foi a tentiva de portar os conceitos, experiências, comportamentos e tarefas do sistema dos desktops para os mobiles. Claramente um grande erro. Com o Windows Phone eles mudaram (tarde) o cenário. Eles criaram o Windows Phone levando em consideração os atos e comportamentos do usuário em aparelhos deste tipo. Não há nenhuma analogia aos desktops. E mais uma vez, algo que foi criado primeiramente para aparelhos móveis será portado para os desktops, que é o caso da interface Metro levada para o Windows 8.

Os PCs de hoje serão apenas hubs num futuro próximo. No cenário de hoje você escolhe entre Mac ou PC e baixa aplicativos que muito provavelmente funcionarão apenas para um destes sistemas. O modelo ideal, que já é mais real do que imaginamos, é que cada pessoa possa usar múltiplos dispositivos acessando um mesmo dado, uma mesma informação, normalmente pela núvem.

O exemplo do serviço de música via streaming Pandora é perfeito. Ele permite que nós possamos utilizar seus serviços em uma variedade gigante de dispositivos. Sempre sincronizando suas músicas via internet. Tudo sempre integrado. Aqui no Brasil, como o Pandora não funciona, talvez não seja a sua realidade… Entretanto estamos vivendo em um mundo onde o software, a aplicação, o serviço, define qual aparelho você vai comprar.

O Sonos é um aparelho de som Wi-Fi. Além do Pandora você pode sincronizar sua biblioteca de músicas de diversos outros serviços como iTunes ou o Spotify. Quando o conheci eu o quis sem pensar. Nada de iPod ou iPhone plugado no aparelho de som. Nada de fio p2-p2 para ligar meu celular ao aparelho de som… Eu quero ouvir minhas músicas livremente pelo serviço que eu mais gosto no sistema de som da minha casa. Mas quando eu for pra rua e quero continuar ouvindo a mesma biblioteca de música, só que agora no meu fone de ouvido. Essa integração entre dispositivos e softwares é incrível. Perceba que não estamos falando sobre um ecosistema fechado como o da Apple. Estamos falando de hardware e software de fabricantes diferentes, que prestam diferentes serviços, mas que se integram.

Entende o que é a experiência do usuário nesse cenário?

Posts Relacionados

• Um pensamento sobre design para web
• Vote no Especialista em Usabilidade para Presidente
• Sites para Dispositivos Móveis – MediaType
• Sobre Internet Explorer para Mobile – Breve impressão
• ePub: Aprenda a criar um livro digital

Afinal, o que é usabilidade?

A Usabilidade é “filha” da Interação Humano-Computador (IHC) e “neta” da Engenharia de Software, carregando esse legado ao longo de sua evolução, podendo ser definida como o grau de facilidade com que o usuário consegue interagir com determinada interface.

Partindo da IHC, a usabilidade aborda a forma como o usuário se comunica com a máquina e como a tecnologia responde à interação do usuário, considerando as seguintes habilidades, de acordo com a norma ISO 9241:

• Facilidade de aprendizado: a utilização do sistema requer pouco treinamento;
• Fácil de memorizar: o usuário deve lembrar como utilizar a interface depois de algum tempo;
• Maximizar a produtividade: a interface deve permitir que o usuário realize a tarefa de forma rápida e eficiente;
• Minimizar a taxa de erros: caso aconteçam erros, a interface deve avisar o usuário e permitir a correção de modo fácil;
• Maximizar a satisfação do usuário: a interface deve dar-lhe confiança e segurança.

Partindo da Engenharia de Software, a usabilidade é englobada dentro da qualidade e visa garantir uma parte da eficiência e eficácia do sistema. A eficiência refere-se a uma interação produtiva entre o usuário e o sistema, permitindo a realização de tarefas com menor esforço sob uma experiência agradável. A eficácia pode ser entendida como a capacidade do sistema e da interface possibilitarem ao usuário a completude da tarefa e o alcance de seus objetivos no sistema.

A importância da usabilidade no desenvolvimento de projetos

A usabilidade se encaixa em qualquer tipo de projeto de interface, tendo amplitude diferente de acordo com a criticidade do projeto, ou seja, quanto mais crítico for o sistema, maiores serão as perdas caso ele não seja de fácil utilização e proporcione satisfação. Ela deve ser pensada desde o planejamento do projeto, até a etapa de desenvolvimento e teste.

As empresas têm consciência da importância da usabilidade. Porém, muitas ainda a veem como um fator que só deve ser levado em conta durante o desenvolvimento se houver tempo e recurso, como se ela representasse um custo adicional, fora do que é essencial. Mas as empresas têm muito mais a perder ao minimizar a usabilidade dessa forma. De acordo com Cybis, Betiol e Faust (2007):

“Dependendo da frequência com que o software é empregado, os prejuízos para as empresas podem também ser expressivos, não só em decorrência do absenteísmo e da rotatividade do pessoal, mas também pela baixa produtividade, competitividade e menor retorno de investimento. Sistemas difíceis de usar implicam em erros e perda de tempo, fatores que se multiplicam com a frequência das tarefas e o número de usuários. A perda de dados e informações pode implicar na perda de clientes e de oportunidades. Acontecimentos deste tipo causam desde uma resistência ao uso do sistema até a sua subutilização e abandono completo, com o devido consentimento da empresa. O barato terá custado caro.”

A usabilidade pode ser abordada de diferentes formas ao longo do projeto:

Técnicas utilizadas para garantir e verificar a usabilidade em diferentes etapas

Lacunas a serem preenchidas

Apesar de a usabilidade ser responsável por assegurar grande parte dos quesitos de experiência do usuário, ela possui duas grandes limitações:

1. Embora considere a satisfação do usuário, trata apenas dessa satisfação perante a realização de uma determinada tarefa, concentrando-se na função, sem considerar fatores físicos, ambientais e emocionais inerentes ao contexto de utilização do sistema. Mais do que ser de fácil utilização, aprendizagem e permitir completude da tarefa, uma boa experiência de uso está baseada em uma interação agradável, considerando a forma como as pessoas percebem a interação com o sistema;
2. O contexto usualmente analisado pela usabilidade é mais restrito: abrange apenas a visão do usuário. Para garantir uma boa experiência de uso, é necessário abranger a visão de diferentes stakeholders: do usuário, da organização e da equipe de desenvolvimento, cada qual com requisitos e necessidades diferentes frente ao sistema.

Adaptando um gráfico apresentado durante a nnGroup Conference de 2008, podemos ver a usabilidade enquadrada da seguinte forma:

O escopo da usabilidade

Referências e Leitura Complementar

ABRAS, C.; MALONEY-KRICHMAR, D.; PREECE, J. User-Centered Design. In: Bainbridge, W. Encyclopedia of Human-Computer Interaction. Thousand Oaks: Sage Publications, 2004.

CYBIS, W.; BETIOL, A. H.; FAUST, R. Ergonomia e Usabilidade: Conhecimentos, Métodos e Aplicações. São Paulo: Novatec Editora, 2007. 344p.

SUMATHI, B. Chapter Three: User Centered Design Approach. Disponível em: http://dspace.fsktm.um.edu.my/bitstream/1812/214/8/Chapter%20Three.pdf.

NIELSEN, J.; LORANGER, H. Usabilidade na Web: Projetando Websites com qualidade. Rio de Janeiro: Elsevier, 2007. 406p.

OLIVEIRA NETTO, A. A. IHC – Interação Humano Computador: Modelagem e Gerência de Interfaces com o Usuário. Florianópolis: VisualBooks, 2004. 120p.

PREECE, J.; ROGERS; Y.; SHARP, H. Interaction Design: Beyond Human-Computer Interaction. New York: John Wiley & Sons, Inc., 2002. 551p.

ROCHA, H. R.; BARANAUSKAS, M. C. C. Design e Avaliação de Interfaces Humano-Computador. Campinas: Universidade Estadual de Campinas, 2007.

UX Revisions. The Difference Between Usability and User Experience. Disponível em: http://www.uxrevisions.com/user-experience-design/the-difference-between-usability-and-user-experience/18/

UX Revisions. User Experience vs User Interaction. Disponível em: http://www.uxrevisions.com/user-experience-design/user-experience-vs-user-interaction/16/

Usability Geek. The Difference (And Relationship) Between Usability And User Experience. Disponível em: http://usabilitygeek.com/the-difference-between-usability-and-user-experience/

NeoSpot. Usability vs. User Experience (UX). Disponível em: http://neospot.se/usability-vs-user-experience/

Interaction by Design. Usability vs. user experience. Disponível em: http://www.interactionbydesign.com/thoughts/thumbnails/00000050.html

Posts Relacionados

• Experiência deve ter começo, meio e fim
• Responsabilidade de um dev client-side
• Agora é a vez dos desenvolvedores
• Introdução aos padrões de codificação
• CSS1K

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.

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.

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

• Mobile First – A arte de pensar com foco
• Introdução ao Responsive Web Design
• Porque é a web que comanda
• Experiência cross-device
• Command & Conquer: Tiberium Alliances

Graciosamente retroceder ou progressivamente evoluir?

A melhor análise antes de decidir qual caminho tomar e a qual evolução recorrer vem do planejamento de seu projeto. Estudo de estatísticas de navegadores, perfil do usuário, resolução de tela, dispositivos, etc; são alguns dos pontos a serem levados em consideração, criando material suficiente para você decidir qual caminho seguir: considerar o retrocesso [ por exemplo: desenvolver seu website para IE6 ] ou expor a evolução de forma progressiva [ por exemplo: utilizar bordas arredondadas e novas características via CSS3 ].
Determinar os fins do projeto vão estabelecer o melhor caminho a seguir durante toda a sua execução pois, em época de transição, os riscos de utilizar algo que não dê certo e a presença de retrabalho são quase inevitáveis. Assim, considere todas as possibilidades.

Graciosamente retroceder

Quando pensamos em retrocesso, no caso do desenvolvimento web, o utilizamos para conceituar uma codificação baseada em X-HTML/CSS 2 e Crossbrowser [ com browsers de mercado incluindo o IE6 ], de qualquer forma, a ideia não é pensar que esteja errado ou que seja um método fora de uso, mas sim uma segurança em utilizar o que já está regulamentado, validado pela W3C e igualmente embutido na renderização padrão dos browsers mais utilizados.
Inúmeras são as dicas aqui no Tableles relacionadas à esta frente de desenvolvimento, mas o que podemos levar em consideração quando pensamos em desenvolver um website dentro dessas diretrizes é que: IE 6 e IE7 ainda devem fazer parte dos browsers em testes e que ainda utilizaremos imagens para criação de bordas arredondadas e sombras. Além claro, de nos encontrar em momentos que utilizaremos diversos elementos em nosso código html apenas para assegurar que algum efeito visual seja renderizado na tela [ as vezes dependente do uso de Javascript para tanto ]. Considerando estes pontos e pensando nos fins do projeto, basta iniciar o desenvolvimento.
Algumas dicas que podem ajudar nesta escolha estão em: http://tableless.com.br/categoria/client-side/html-css/page/2

Progressivamente evoluir

Como falamos acima, estamos num momento de transição que significa acima de tudo – escolha. Utilizar novas possibilidades na criação de websites é uma escolha que deve ser igualmente planejada pois, o risco não vem do que já conhecemos e do que já sabemos que vai exigir maior cuidado, mas sim do que desconhecemos – a renderização de novos parâmetros em folhas de estilo e a interpretação de uma nova tag html, por exemplo.
Pouco ainda consegue-se definir a respeito das novas possibilidades, mas é fato que muitos desenvolvedores estão aprendendo como utilizar o novo, testando e reportando erros e acertos e este comportamento deve estender-se por anos, até que as diretrizes sejam regulamentadas pela W3C e os browsers tenham o mesmo número de usuários que suas versões de mercado tem hoje.
Com isso, os testes geralmente giram em torno dos novos browsers, mas eventualmente necessitamos também direcionar o desenvolvimento à navegadores mais antigos, encontrando assim, a dificuldade em visualizar a mesma coisa em todos eles. Para ajudar, pensando em HTML 5 e CSS3, abaixo uma lista de algumas ferramentas que podem ajudar na implementação das novas técnicas em browsers e possibilidades atuais:

• Modernizr: http://www.modernizr.com/ – uma ferramenta JavaScript que suporta propriedades CSS3 em diferentes navegadores.
• CSS3 Pie: http://css3pie.com/ – já comentada em outro artigo, o CSS3 Pie é uma ferramenta JavaScript que permite renderizar bordas arredondadas, background-gradient e box-shadow nas versões anteriores de IE.
• Selectivizr: http://selectivizr.com/ – ferramenta JavaScript que emula seletores CSS3 e pseudo-classes, como por exemplo :focus em diferentes browsers.

Além das ferramentas, conheça no link ao lado também, algumas das melhorias trazidas para as folhas de estilo em sua nova versão e para a evolução da linguagem de marcação – o HTML5: http://tableless.com.br/categoria/client-side/html-css

Testar o novo ou trabalhar com o conhecido? Esta pergunta não podemos responder, mas analisadas as características do seu projeto, você mesmo poderá tomar esta decisão consciente de um trabalho profissional e determinado ao sucesso.

Boas escolhas e até a próxima.

Posts Relacionados

• Experiência cross-device
• Agora é a vez dos desenvolvedores
• Introdução ao CSS 3D – Flip Card
• Command & Conquer: Tiberium Alliances
• Experiência deve ter começo, meio e fim

Se preferir faça o download do arquivo em Mp3 ou OGA. Ou inscreva no iTunes. Feed direto dos Podcasts.

Posts Relacionados

• Agora é a vez dos desenvolvedores
• Introdução aos padrões de codificação
• Podcast Tableless #22 – Primeira impressão sobre Padrões Web
• Podcast #19 – WYSIWYG, WiMax e a onda móvel
• ePub: Aprenda a criar um livro digital