<
Menu

Tableless


thumb

Google Chrome para Android

ie10

O browser que você amou odiar

mobile

Utilizando APPs em vez de browsers

firefox

Firefox 17: um firefox mais social


Imagem post: Especificação para touch screens

Especificação para touch screens

Interações em interfaces touch são diferentes das interfaces baseadas com mouse. Hoje temos pleno controle das ações baseadas com mouse, mas este controle não pode ser expandido para as interfaces touch. As ações e as forma de comportamento do usuário são diferentes.

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

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

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.

Por Diego Eis

Diego Eis criou o Tableless para disseminar os padrões web no Brasil. Como consultor já treinou equipes de empresas como Nokia, Globo.com, Yahoo! e iG. É palestrante e empreendedor.

http://about.me/diegoeis/

Mais posts do autor

Comentários (11)

  • http://twitter.com/oieduardorabelo Eduardo Rabelo

    Isso tudo é fantástico!

    Mas não nego que fico com aquela sombra “E agora?” hahahaha

    Who knows ahn? :D

    E quero saber sua opinião Diego! Expresse-se!

  • http://www.lucassandoval.com.br Lucas Sandoval

    Interessante, Diego. E a CSS aural, como vai? Costumo chamar a css de Jack Bauer, pois ela sempre salva o mundo.

  • http://www.silvestrin.com.br Silvestrin

    Grande artigo Diego!
    parabéns!

  • http://www.fellipeeduardo.com Fellipe Brito

    Pois é Diego, concordo com o Eduardo… ficamos todos querendo saber sua opinião para debater masi sobre isso =)

  • http://leocarpo.blogspot.com Leocarpo

    Realmente as linguagens de marcação ficarão ainda mais dificeis..

  • Dorian

    Bastante interessante essa matéria que você fez.O jeito é esperar e vê no que da.Minha opnião é que novas linguagens serão criadas e vai complicar é tudo hahahahahah

  • http://www.sastudio.com.br Sergio Almeida

    Ótimo post Diego. Procuro desenvolver meus sites com botões grandes para justamente as pessoas navegar com poucas dificuldades.

    Agora, olhando um pouco para os smartphones, veja a seguinte situação:

    Quando um browser mobile navega um site que exibe um número telefônico em seu conteúdo, o browser mobile trata de criar um hyperlink automaticamente (parse) que, ao clique do usuário, o dispositivo tenta realizar uma chamada telefonica, certo? Isso acontece com o iPhone, pelo menos. Se o número telefonico conter um telefone sem operadora e sem código de estado, ou seja, um numero hipotético 1234-5678, ao clicar, a chamada acontece sem problemas. :)

    Porém, se estou no Acre e acesso um site de uma empresa em São Paulo e vejo que tem um número telefonico 011 1234-5678 com hyperlink; clico nesse hyperlink mas meu dispositivo mobile não completa a chamada, pois a operadora avisa que é necessário digitar o código da operadora. E isso não é user-friendly, ou seja, o cara tem que copiar o numero telefonico, editar o numero e depois colocar a operadora desejada.

    Além disso, sites usam padrões diferentes para telefones, ex: 11-1234-5678 ou 011-1234-5678. A pergunta é: existe alguma recomendação HTML para especificar telefones com DDD para facilitar a vida do usuário mobile? O que vc acha sobre isso? Acha que podemos usar um microformat chamado DDD? Ou acha que o responsável é dispositivo mobile que precisa fazer o parse correto e oferecer uma forma amigável ao usuário para fazer chamadas locais e para outros estados?

  • Gabriel Magalhães dos Santos

    Existe algum emulador desses eventos para poder testalos?

  • Felipe

    Utilize o “callto”, ex: 12345678

  • Beto Chazan

    Sinceramente, acho melhor desabilitar esse hyperlink dos telefones e exibir assim como é num site “comum”. Se a pessoa tiver interesse, faz a ligação com a operadora que quiser.

  • Lucas

    Ótimo Post Diego!!!