Sei sulla pagina 1di 20

BOAS PRÁTICAS PARA DESENVOLVIMENTO WEB MOBILE

Relatório Técnico

Número do relatório – pegar com o gerente!

Este documento apresenta uma seleção de regras e sugestões de projeto de interfaces de aplicações para celulares.

Mauricio Cirelli

Fevereiro de 2009

Grupo de Estudos em interação do LTS Escola Politécnica da Universidade de São Paulo

Cirelli Fevereiro de 2009 Grupo de Estudos em i nteração do LTS Escola Politécnica da Universidade

CONTROLE DE REVISÕES

Fevereiro de 2009

No.

Data

Revisão

00

   

01

   

02

   

03

   

04

   

05

   

Proj.RT.NNN.vv

1

Proj.RT.NNN.vv 1
 

Fevereiro de 2009

Sumário

RESUMO

3

INTRODUÇÃO

3

DIFICULDADES

4

O COMEÇO

5

BOAS PRÁTICAS

5

Interface

6

Conteúdo

6

Navegação e Links

8

Layout

10

Formulários

13

Tecnologia

15

CONCLUSÃO

18

REFERÊNCIAS

19

Proj.RT.NNN.vv

2

Layout 10 Formulários 13 Tecnologia 15 CONCLUSÃO 18 REFERÊNCIAS 19 Proj.RT.NNN.vv 2

RESUMO

Fevereiro de 2009

Este trabalho propõe recomendações para os principais problemas de usabilidade encontrados em páginas web exibidas por dispositivos móveis, fornecendo um guia de boas práticas e princípios a ser seguido por desenvolvedores do framework x-gov.

O conteúdo será inicialmente apresentado a partir das dificuldades existentes para

desenvolvedores e web designers nos quesitos de usabilidade e restrições tecnológicas e, a seguir, serão propostas diversas técnicas e práticas de desenvolvimento que podem solucionar ou, ao menos, minimizar estes problemas.

Palavras-chave: web mobile, boas práticas, x-gov, usabilidade

INTRODUÇÃO

Estimativas mostram que aproximadamente 730 milhões de pessoas acessam a Internet via dispositivo móvel. Cada vez mais as empresas e corporações estão fazendo uso de soluções web mobile, seja para integrar grandes equipes de funcionários ou para fornecer seus serviços a uma gama maior de usuários [1].

Entretanto, desenvolver uma página web mobile não é simplesmente migrar uma solução desktop para uma versão para celulares. Segundo a Little Springs Design [2], uma aplicação móvel deve possuir objetivos muito diferentes de uma aplicação convencional, pois os recursos disponíveis são outros. Uma aplicação mobile pode ser acessada a qualquer momento de qualquer lugar e esta característica deve ser explorada ao máximo pelos desenvolvedores.

Por exemplo, a página web de uma pizzaria pode possuir um catálogo de pizzas, com fotos, ingredientes utilizados, receitas e, até mesmo, vídeos do local. Todo este conteúdo é bem visível e explora muito bem as capacidades de um computador. Porém, não seria agradável se um usuário acessasse este site por um celular e enfrentasse uma longa demora para carregar a página devido às imagens e vídeos, sendo que, ao final, não obteria boa resolução do conteúdo que foi exibido.

Considere uma situação em que o usuário deseja encomendar uma pizza de um local próximo de sua casa.Ao acessar a página pelo celular, o cliente provavelmente:

1. Já conhece a pizzaria, pois sabia seu endereço eletrônico ou a encontrou rapidamente

em um site de buscas como o Apontador (http://www.apontador.com.br)

2. Está em movimento ou em um local que não possui um computador disponível

3. Deseja apenas encomendar uma pizza, normalmente, que ele já conhece

A navegação se tornaria muito confusa, se a página exibida fosse apenas uma miniaturização

do site convencional. Os objetivos são muito diferentes, pois as intenções dos usuários são diferentes.

Proj.RT.NNN.vv

3

convencional. Os objetivos são muito diferentes, pois as intenções dos usuários são diferentes. Proj.RT.NNN.vv 3

Fevereiro de 2009

Além dos objetivos, a estilização e a apresentação do conteúdo em ambiente mobile devem ser muito bem estudadas e estruturadas. Não é possível, por questões físicas dos aparelhos, exibir todo o conteúdo que se deseja em uma página.

Apontaremos e discutiremos, de agora em diante, uma relação de soluções e princípios a serem seguidos pelos desenvolvedores mobile a fim de criarem páginas bem definidas e apresentáveis em dispositivos móveis.

DIFICULDADES

Alguns dos problemas foram apontados a partir de um estudo de usabilidade com muitos usuários, realizados de 2004 a 2007 por Y. Cui e V. Roto em “How people use the web on mobile devices”, publicado em 2008 [8] e por S. Shrestha em “Mobile web browsing: usability study”, publicado em 2007 [10].

A portabilidade e mobilidade de aparelhos como celulares, Palms, SmartPhones, PDAs, entre

outros, se deve, essencialmente, ao tamanho físico do dispositivo. A redução deste tamanho favorece a mobilidade em sacrifício da usabilidade e dos recursos tecnológicos da web [1].

Ao trabalhar com um espaço reduzido, o desenvolvedor não poderá utilizar muitas formas diferentes para exibição de conteúdo. Como veremos mais adiante, o conteúdo fica restrito a, basicamente, texto curtos e diretos [3]. Isto pode tornar o conteúdo impreciso, gerar problemas com rolamento de página e má organização dos tópicos do site [8].

A velocidade de conexão aparece como um segundo grande empecilho encontrado pelos

programadores. Apesar do advento da tecnologia 3G, a maioria dos aparelhos com acesso a Internet o faz a partir de conexões WAP [1].

A conexão wireless WAP está restrita a uma baixa velocidade, o que impede a exibição de

grandes conteúdos ou páginas web com muitos recursos visuais ou de interação, além de apresentar um alto custo de utilização.

A digitação em ambiente mobile é muito complexa [9]. A maioria dos dispositivos utiliza

teclados reduzidos, normalmente baseados no teclado numérico convencional. A digitação é feita com apenas dois dedos pela maioria das pessoas, o que a torna lenta e muito suscetível a erros. Formulários, campos de busca e caixas de texto se tornam grandes vilões da usabilidade de uma página mobile.

Uma última dificuldade reside nos navegadores mobile, ou mini-browsers, e nos sistemas operacionais dos aparelhos. Atualmente, muitos navegadores já oferecem suporte às tradicionais linguagens de programação para Web Convencional, como XHTML, JavaScript e Cascade StyleSheets. Apesar disto, não são todos os sistemas operacionais mobile que aceitam estes navegadores e ainda existem muitas diferenças de interpretação por parte dos browsers [1].

Isto é incômodo e gera dificuldades de desenvolvimento no aspecto tecnológico. Até então,

as dificuldades apresentadas eram apenas de conotação física. Ou seja, relacionadas ao

tamanho das telas dos aparelhos ou à quantidade de teclas disponíveis, afetando diretamente apenas a interface com o usuário e a usabilidade.

Proj.RT.NNN.vv

4

de teclas disponíveis, afetando diretamente apenas a interface com o usuário e a usabilidade . Proj.RT.NNN.vv

O COMEÇO

Fevereiro de 2009

Antes de iniciar o desenvolvimento de qualquer projeto, uma das etapas é a Especificação do Sistema, a qual deve definir metas de usabilidade e metas de experiência do usuário [6]. Nesta etapa, algumas reflexões devem ser feitas:

Entender o que o usuário espera ao utilizar o sistema

Quais tarefas o usuário poderá executar?

Analisar se estas tarefas atendem às expectativas do usuário

Definir como o usuário realizará estas tarefas

Especificamente no ambiente web mobile, é fundamental entender que os objetivos do usuário são diferentes daqueles definidos no ambiente desktop.

Podemos comparar as atividades dos usuários da Internet Mobile com relação aos da Internet Desktop da seguinte maneira:

Normalmente, ele não buscou o site através de um serviço buscador, como o Google

[4]

Ele tem uma meta bem definida e deseja realizá-la o mais rápido possível

Ele tem um problema para resolver e precisa de uma solução ou resposta eficiente e rápida

Ele abandonará seu site caso demore em atingir seu objetivo ou se perca na hierarquia do conteúdo [5]

Em função disto, é um bom começo definir bem as metas do usuário e a hierarquia do conteúdo de sua página. Ao acessar seu web site, o usuário deverá saber exatamente o que ele poderá encontrar ou realizar – quais os objetivos que seu site atende – e entender rapidamente de que forma o conteúdo do site está estruturado.

A maneira com a qual o usuário irá realizar as tarefas em uma página varia muito e depende, essencialmente, da criatividade do desenvolvedor. Entretanto, um sistema criativo não é necessariamente eficiente, fácil de usar ou que respeita as limitações da plataforma.

BOAS PRÁTICAS

Conforme discutido na sessão Dificuldades, no ambiente mobile, os problemas podem ser subdivididos em duas categorias: Recursos Tecnológicos e Interface com o Usuário.

As limitações tecnológicas são aquelas padrões da plataforma, definidas pelo fabricante do dispositivo, e pelo navegador utilizado pelo usuário. São problemas como portabilidade de softwares, incompatibilidade de plataformas de desenvolvimento, linguagens de programação suportadas, além de padrões de codificação de caracteres, entre muitos outros.

No plano de Interface com o Usuário, os problemas estão relacionados à usabilidade e estão intimamente ligados às dificuldades descritas na sessão Dificuldades. A interface abrange características de layout, conteúdo das páginas, recursos visuais e de multimídia, organização e estrutura do site, formulários e mecanismos de navegação.

Proj.RT.NNN.vv

5

visuais e de multimídia, organização e estrutura do site, formulários e mecanismos de navegação. Proj.RT.NNN.vv 5

Fevereiro de 2009

Para cada um dos tipos de problema apresentados, existe um conjunto de recomendações especificadas, a fim de minimizar as dificuldades do usuário – melhorar a usabilidade e a interface – e aumentar as chances de que seu projeto seja bem exibido pelos diferentes dispositivos.

A equipe de desenvolvedor deve balancear as recomendações. Usualmente, uma pode conflitar com outra, de forma que a equipe deve ponderar cada uma delas, baseado no público-alvo, tecnologia disponível e testes de usabilidade.

Em função disto, os princípios propostos serão discutidos em duas grandes categorias:

Interface e Tecnologia.

Interface

Conteúdo

O conteúdo a ser exibido é, tão somente, aquele que o usuário procura.

Segundo J. Nielsen [5], a interface deve fornecer apenas o conteúdo que o usuário deseja ver e no local que ele espera que o conteúdo seja exibido. Embora seja muito criativo exibir o conteúdo de um site sobre aquários, por exemplo, em posições randômicas da tela tendo um oceano de fundo e em caixas de texto com formato de peixes, o usuário se sentirá perdido e desamparado, pois não saberá o que fazer ou o que está acontecendo. Tudo que ele queria era saber o preço de um peixe Beta e se deparou com um mar de informações que não lhe servia, dispostas de forma ilógica, dificultando sua acessibilidade.

O conteúdo principal deve sobrepor o conteúdo extra.

Este tipo de problema é normalmente encontrado quando nos deparamos com aplicações que foram migradas do ambiente web convencional para o ambiente mobile. É comum encontrarmos aplicações que foram apenas miniaturizadas ou apenas adaptadas para dispositivos móveis. Desta forma, o conteúdo original passa por um processo de redução de tamanho de exibição e a página web fica extremamente poluída por informações que não são relevantes para o usuário.

Mesmo em aplicações criadas sem baseamento em páginas convencionais, é comum se encontrar textos que descrevem alguma informação ou não pertencem ao assunto principal da página.

Devido às dificuldades de navegação e restrição de espaço para exibição de conteúdo, sempre que possível deve-se exibir somente a informação procurada. Quando esta informação for muito vaga ou dependente de um aparato extra, deve-se ter o cuidado de que estes textos complementares sejam curtos e não sobreponham o assunto principal [5].

O conteúdo deve ser bem apresentado em qualquer dispositivo que o usuário utilize.

Proj.RT.NNN.vv

6

principal [5]. O conteúdo deve ser bem apresentado em qualquer dispositivo que o usuário utilize. Proj.RT.NNN.vv

Fevereiro de 2009

A maioria dos dispositivos móveis consegue exibir claramente, em uma página sem scrolling,

de 3 a 10 linhas de texto [7]. Esta grande variação é devida à grande variedade de dispositivos, os quais não seguem um padrão de tamanho e resolução de tela.

Analisar quais são os possíveis usuários de uma aplicação e quais tipos de dispositivos eles utilizarão para acessar o conteúdo desta página são procedimentos já descritos na sessão anterior. Uma vez conhecidas as restrições de dispositivos existentes no público-alvo, deve-

se

testar a exibição do conteúdo em todos estes aparelhos.

A

W3C [4] recomenda que o conteúdo seja hierarquizado em subpáginas, a fim de respeitar

as

limitações de tamanho, tráfego de dados e velocidade de conexão dos dispositivos.

Este aninhamento de conteúdo deve manter a legibilidade e navegabilidade da página. O usuário não pode ser obrigado a executar muitos passos para realizar uma tarefa simples, devido ao fato de sua página estar hierarquizada em um número excessivo de subpáginas. Lembre-se de que o conteúdo a ser exibido é, tão somente, o necessário.

O conteúdo deve estar hierarquizado, através de um índice ou menu com lista de opções [4]

Como já mencionado em outros tópicos, é fundamental entender que o usuário acessará o conteúdo pressupondo que um determinado link o levará ao seu objetivo.

Dar ao usuário uma lista de opções possíveis, como uma listagem dos tópicos abordados e funções disponíveis no site – índice ou menu – fará com que ele elimine as opções que não se relacionam com o que ele deseja e vá direto ao tópico que lhe interessa.

São inúmeras as situações em que o usuário se depara com uma lista de opções e nenhuma delas parece atender ao que ele procura. Quando isto acontece, ele imediatamente pensa que a informação não existe neste local e se sente perdido. Muitas vezes isto o leva a sair da página e buscar as informações em outro site.

Existem, ainda, os casos em que em uma lista de opções, existam três ou mais alternativas que parecem resolver o problema. Nestas situações, pode-se perder muito tempo verificando cada uma delas até encontrar o que se buscava. Tanto pior será se, ao se escolher todas as opções existentes, descobrir-se que o conteúdo que buscamos não existia naquele site.

Em uma boa hierarquia, ao eliminar as opções que não lhe interessa, o usuário terá apenas uma alternativa disponível, e esta opção deve levá-lo à informação procurada.

Utilize navegação “drill-down” ao exibir conteúdos muito extensos e com subdivisões em uma mesma página.

Segundo a W3C [4], a navegação “drill-down” é aquela que lista os principais tópicos relacionados ao conteúdo a ser exibido na forma de um índice e utiliza âncoras HTML para a navegação na mesma página.

Desta forma, sem recarregar a página o usuário pode ler todos os tópicos sobre determinado assunto, navegando dentro de um índice – algo que ele já está familiarizado. Este tipo de

Proj.RT.NNN.vv

7

assunto, navegando dentro de um índice – algo que ele já está familiarizado. Este tipo de

Fevereiro de 2009

exibição de conteúdo fornece, sempre, uma forma de o usuário voltar ao índice – ao topo da página – através de um botão ou link “Voltar”, por exemplo.

A apresentação do conteúdo deve ser feita de forma vertical.

O guia de melhores práticas para web mobile da W3C [4] sugere que a barra de rolagem –

scrolling – da página seja feita em uma única direção. As pessoas estão acostumadas a lidar

com conteúdo disposto verticalmente. Planilhas são escritas de forma vertical, tabelas, livros

e elementos visuais crescem na direção vertical. O acompanhamento de um texto em uma

página deve ser feito desta maneira, pois o usuário já está familiarizado com isto.

Embora respeite a sugestão da W3C, utilizar scrolling lateral não é recomendável, pois deixa

o usuário confuso quanto à seqüência lógica das informações exibidas e quanto à estrutura do site.

Scrolling em duas direções não deve ser utilizado de forma alguma, pois a experiência do usuário se torna demasiado confusa, e o problema se agrava ainda mais se a informação relevante não estiver localizada em uma posição óbvia da página.

Navegação e Links

Não utilizar endereços eletrônicos longos e com muita pontuação.

Digitar utilizando teclados mobile, como já foi discutido anteriormente, pode se tornar uma tarefa muito árdua. Se o usuário for obrigado a digitar o endereço de um site, é interessante minimizar o trabalho que ele terá [4].

Isto pode ser feito adicionando os caracteres “http://”, previamente, ao conteúdo do campo que está sendo preenchido, por exemplo.

Uma boa prática é manter as URIs (Uniform Resource Identifier) pequenas e entender simplificações via código, como interpretar “exemplo.com” da mesma maneira que “http://www.exemplo.com/”.

Destaque e identifique claramente os links, assim como o que eles fazem.

O texto de um link é muito importante para que o usuário entenda o que acontecerá caso ele

clique. Imagine-se clicando em um link que diz “Home” e não ser levado à página inicial do

site. Você terá de voltar à página anterior, esperar que ela seja recarregada e procurar onde é

o local correto para executar determinada tarefa.

Segundo a W3C [4], ao clicar em um link o usuário deve saber exatamente para onde este

link o levará, quais ações serão executadas e qual tipo de arquivo ele receberá como retorno –

se for o caso.

Se o usuário desejar exibir um vídeo ao clicar em um link e o mesmo não especifica qual formato de arquivo tal vídeo está gravado, há uma possibilidade de o usuário se frustrar por

Proj.RT.NNN.vv

8

qual formato de arquivo tal vídeo está gravado, há uma possibilidade de o usuário se frustrar

Fevereiro de 2009

não possuir o plug-in necessário para execução do arquivo. Além da perda de tempo, o usuário teve uma perda financeira considerável, pois utilizou tráfego de internet mobile e não pôde utilizar o conteúdo que recebeu.

Certifique-se também, de que o link possui um alvo válido. A consistência da página depende de o usuário não receber um erro do tipo: “404 – Not Found”.

Links em ambiente mobile devem estar destacados, sob algum tipo de efeito de estilo ou formatados de forma diferente do restante da página. É muito comum e eficiente, links receberem realce ao terem o mouse por cima. Este realce pode ser uma mudança de cor de fundo do link, sublinhados ou mudança de tamanho ou estilo de fonte.

Além disto, os botões devem estar bem dispostos, de maneira que o uso do tabulador do teclado seja eficiente e leve o usuário ao longo da página seguindo uma seqüência lógica.

A barra de navegação deve estar disposta no rodapé da página e um link para a sessão anterior ou home Page deve ser exibido no topo.

Devido ao espaço disponível e à recomendação de exibir o conteúdo principal de forma clara

e visível, a navegação deve ser feita ao final da página [4].

Ao entrar na página, o usuário visualizará o conteúdo principal. Se for o que lhe interessa, ele

o lerá até o fim, chegando ao rodapé e continuando sua navegação a partir de lá, sem precisar

voltar ao topo da página para ver os links disponíveis. Mesmo que se usem âncoras para voltar ao topo, neste caso é preferível que o espaço primário da página seja utilizado pelo conteúdo principal e não pelas opções de navegação.

Caso o conteúdo exibido não seja o que o usuário procurava, imediatamente ele recorrerá ao link de “home” ou “voltar” existente na parte superior da tela.

É importante fornecer mecanismos de desfazer ou exigir confirmação à ação do usuário, de

forma que erros de clique – missclicks – sejam contornados.

Utilize teclas de atalho para as tarefas e ações mais comuns.

O estudo prévio dos objetivos do usuário lhe fornecerá quais tipos de ações serão mais comuns por parte dos visitantes.

Estas ações devem possuir teclas de atalho – a W3C [4] as chama de Access Keys – a fim de poupar tempo e tornar a navegação mais eficiente. Um exemplo clássico e padrão do HTML

é o uso da tecla ENTER para submeter informações de formulários. Na verdade, ao clicar na tecla ENTER, disparamos um evento Submit.

Explicite nos botões e locais utilizados para iniciar determinadas tarefas que eles possuem uma tecla de atalho e qual tecla é.

Proj.RT.NNN.vv

9

locais utilizados para iniciar determinadas tarefas que eles possuem uma tecla de atalho e qual tecla

Fevereiro de 2009

Não recarregue a página, não utilize pop-up’s e não redirecione o usuário sem seu consentimento.

Sempre que uma destas ações for necessária, peça permissão ao usuário para executá-las. Qualquer uma delas gera tráfego extra, utiliza a conexão e faz com que o custo de navegação aumente.

Tarefas como recarregar a página e redirecionar o usuário são agravadas pelo fato de que o usuário pode se sentir perdido, caso isto seja feito sem que ele seja notificado. Todas as ações que a página necessite fazer devem estar claras ao visitante, a fim de que ele tenha controle sobre o que irá acontecer.

A W3C [4] recomenda que estes tipos de ações sejam feitas do lado do servidor, utilizando

conexões http sob configuração do código 3xx.

De forma alguma se recomenda o uso de pop-up’s. Todo conteúdo que seria exibido por ele pode ser exibido pela própria página, sem sacrificar ainda mais o espaço destinado à visualização do conteúdo.

Layout

Não se deve utilizar frames ou tabelas como recursos de layout.

Utilizar frames como forma de organizar e estruturar o layout de uma página web é, hoje em dia, uma prática muito antiquada. Com o grande crescimento e aprimoramento dos Cascade Style Sheets (CSS), é possível posicionar, dimensionar e estilizar as páginas web da maneira que o designer preferir.

No ambiente mobile, a utilização de frames possui três agravantes:

Não é versátil. Um frame terá sempre a mesma aparência, não podendo ser reposicionado ou estilizado

Exige o carregamento de páginas (documentos xhtml) extras

Aumenta o custo de navegação do site

O uso de tabelas deve se restringir à função semântica de uma tabela: relacionar dados. A

W3C [4] recomenda que seja seguida a filosofia tableless, a qual define que o layout deve ser

definido exclusivamente por tags <div> e <span> do XHTML e formatadas de acordo com

as folhas de estilo – CSS – em um arquivo separado.

Os problemas da utilização de tabelas como estrutura de layout em ambiente mobile são:

Distorcem o conteúdo na medida em que o texto torna-se maior

Tornam o código confuso e não reutilizável

Estão restritas a poucas colunas, devido ao tamanho da tela

De fato, uma tabela em ambiente mobile não deve possuir mais do que 4 colunas. Este número pode variar dependendo do tamanho das palavras que estão sendo colocadas nas células. Em geral, 4 colunas é o limite recomendável para que o conteúdo não perca a

Proj.RT.NNN.vv

10

colocadas nas células. Em geral, 4 colunas é o limite recomendável para que o conteúdo não

Fevereiro de 2009

disposição nos diferentes aparelhos. Não se deve, desta forma, utilizar mais do que 2 palavras em cada célula.

forma, utilizar mais do que 2 palavras em cada célula. Figura 1: Headings Utilize headings e

Figura 1: Headings

Utilize headings e subheadings para exibição de textos longos.

As tags <h1>, <h2>, <h3>,<h4>,<h5> e <h6> do XHTML permitem a hierarquização do conteúdo de uma forma semanticamente mais clara e correta. São tags criadas com a intenção de hierarquizar o texto de forma que o leitor sinta-se familiarizado com a estrutura do conteúdo.

É comum se encontrar livros e apostilas cujos tópicos do índice estão dispostos como na figura ao lado. Este tipo de estrutura facilita a compreensão do texto e permite a utilização da navegação “drill-down” de forma mais clara – tanto para o programador, quanto para o

visitante.

O título da página deve ser curto e objetivo, com o propósito único de identificação.

Devido ao tamanho reduzido de tela, alguns navegadores não exibem a barra de título da página. Geralmente, em páginas desktop, encontramos o mapa completo do site, indicando toda a trajetória do usuário, no título da mesma, como:

“Site X :: Busca por ID :: Resultados da Busca :: Tópicos Relacionados :: Tópico XYZ”

Isto não deve ser feito em ambiente mobile. O tamanho da tela não permite que toda esta informação seja exibida.

Adicionar um site com esta formatação aos favoritos pode ser extremamente difícil. Ao pedir para o navegador realizar esta tarefa, o usuário terá que editar o título que está sendo armazenado para que o mesmo torne-se legível. Como já foi discutido anteriormente, a digitação é complicada e muito sujeita a erros nesta plataforma.

Uma boa apresentação para o título do exemplo acima seria: “X : XYZ”, apenas.

O tamanho total da página a ser carregada não deve exceder os 10kb.

Esta é uma recomendação da W3C [4]. Devido a fatores já discutidos, como velocidade, custo e desempenho de conexão, exigir que o usuário faça download de uma página grande exigirá que ele seja paciente e esteja disposto a pagar mais caro pelo conteúdo que será exibido.

Geralmente, os usuários se mantêm atentos ao que está acontecendo em carregamentos de até 1s [5]. Em casos de demoras maiores, eles procurarão algo para se distrair – no caso do ambiente desktop – ou desistirão e procurarão a solução em outro site – caso do ambiente mobile.

Proj.RT.NNN.vv

11

ambiente desktop – ou desistirão e procurarão a solução em outro site – caso do ambiente

Fevereiro de 2009

Este tamanho de 10kb inclui o arquivo da página (.html, .xhtml, .asp, .php, entre outros), as imagens e quaisquer conteúdos multimídia, como arquivos Flash®, MPEG, AVI ou MP3.

Utilize medidas relativas ao especificar tamanho de elementos da página.

Medidas relativas são valores acompanhados por unidades que dependem de outras medições. No caso do XHTML, isto pode ser feito utilizando porcentagem.

A W3C [4] especifica que, para melhorar a visibilidade do site em diversos tamanhos e

resoluções de tela, devem-se substituir as medições em pixels, polegadas ou centímetros para medidas em porcentagem.

Se isto for feito corretamente, o conteúdo se adaptará automaticamente ao tamanho da tela que está o exibindo, sem grandes distorções. A prática é tão eficiente que, na maioria dos casos, nenhuma distorção ocorre e o conteúdo é exibido da mesma forma nos diversos dispositivos.

Não utilize imagens “spacers” para alinhar verticalmente o conteúdo.

Spacers” são arquivos de imagem com comprimento pequeno e altura de 1 pixel. São muito utilizados em páginas desktop para alinhar verticalmente o conteúdo interno a uma tag <div>.

Isto é feito devido à inexistência de um atributo com esta característica na especificação do

XHTML ou do CSS.

Podemos listar alguns problemas na utilização desta técnica:

Estes arquivos, em geral, possuem tamanho de 1kb, podendo comprometer o tamanho total de uma página a ser carregada

Não são eficientes, pois o tamanho da tela pode variar e o alinhamento pode deixar de existir

Não caracterizam uma boa prática de programação, pois exige o carregamento de conteúdo que não será exibido – inútil para o usuário – e foge às especificações e recomendações da W3C [4] sobre CSS e XHTML.

O

alinhamento vertical da tag <div> deve ser feito a partir do conhecimento do tamanho

vertical da célula. Uma vez conhecido, utilize as propriedades padding-top e padding-bottom para centralizar o conteúdo. Este procedimento é eficiente em muitos casos, falhando apenas quando não se conhece o tamanho do conteúdo que será exibido.

Utilize textos alternativos para a exibição de conteúdo multimídia.

A maioria dos navegadores possui suporte para imagens, porém, é possível que o usuário desabilite esta opção a fim de economizar tempo e custo em sua navegação.

Proj.RT.NNN.vv

12

possível que o usuário desabilite esta opção a fim de economizar tempo e custo em sua

Fevereiro de 2009

Por este motivo, sempre que se desejar fazer uso de imagem, som, vídeo ou arquivo flash, deve-se utilizar a propriedade “alt” do XHTML para exibir um texto descritivo a este conteúdo, o qual será exibido caso o arquivo multimídia não possa ser carregado.

Não utilize imagens no plano de fundo da página.

O uso de imagens como plano de fundo acarreta alguns problemas:

Maior latência – demora – ao carregar a página

Estão sujeitas a não serem exibidas pelos browsers

Tornam a estilização de cores do site dependente da visualização da imagem

Se a imagem não for exibida, o conteúdo pode se tornar ilegível dependendo das escolhas de cores.

Geram custos extras para serem exibidas

Caso seja necessário utilizar imagens para esta finalidade, garanta que o usuário possa escolher entre uma visualização com ou sem este recurso, de forma que ele não se frustre caso algo aconteça de forma inesperada.

Formulários

Forneça formas alternativas para o preenchimento de caixas de texto sempre que possível.

o preenchimento de caixas de texto sempre que possível. Figura 2: Google Home – http://www.google.com Em

Figura 2: Google Home – http://www.google.com

Em diversos casos é possível substituir uma caixa de texto por uma caixa de seleção múltipla – dropdown list. Esta substituição resolve o problema de digitação e elimina possíveis erros na entrada de dados.

Em casos onde esta substituição não é possível, outra alternativa é o uso de tecnologia AutoComplete. Esta tecnologia é a mesma utilizada

pelo Google Suggest® na imagem ao lado.

O recurso baseia-se em fornecer opções para o usuário conforme ele digita em um campo. No exemplo da figura, ao digitarmos a letra “a”, automaticamente temos a opção de escolher uma entre dez possibilidades. Conforme digitamos mais caracteres, as opções se tornam mais específicas, até que, em dado momento, o texto que digitávamos aparece na lista e podemos escolhê-lo sem ter de terminar de digitá- lo.

Uma desvantagem é o uso de linguagens client-sided, as quais podem não ser interpretadas por todos os navegadores.

Estas alternativas têm por objetivo reduzir a quantidade de texto digitada pelo usuário em formulários de qualquer natureza.

Proj.RT.NNN.vv

13

por objetivo reduzir a quantidade de texto digitada pelo usuário em formulários de qualquer natureza. Proj.RT.NNN.vv

Fevereiro de 2009

Utilize máscaras de entrada em campos de preenchimento padrão.

Entende-se por campos de preenchimento padrão as caixas de texto que devem ser preenchidas seguindo uma estrutura pré-determinada, chamada máscara de entrada. Por exemplo, um campo CPF em determinado sistema deve seguir a estrutura XXX.XXX.XXX-XX. Neste caso, exige-se que o usuário digite quatorze caracteres, sendo três deles especiais, ou seja, de digitação ainda menos direta.

Uma solução para este caso pode ser o uso de linguagem client-sided, a qual preenche automaticamente o campo conforme o usuário digita. Um bom script para isto colocaria os caracteres especiais automaticamente após a digitação das tríades de números e não permitiria que o campo aceitasse qualquer valor fora desta regra – ou máscara.

O uso deste recurso deve ser estendido, de forma que o usuário não possa preencher um

campo – ou posição de campo – numérico com caracteres alfabéticos ou especiais, por exemplo.

As máscaras de entrada têm por objetivo reduzir as chances de erro de digitação do usuário, para que não perca tempo tendo que corrigir os dados fornecidos.

Sinalize de forma clara e direta o que o deve ser preenchido em determinado campo de formulário.

A descrição do campo seja ele uma caixa de texto, de seleção múltipla ou um simples

checkbox” deve ser limitada a uma ou duas palavras, porém deve descrever exatamente o que deve ser preenchido.

Caso o campo utilize alguma máscara de entrada, indique ao lado, abaixo ou com um lembrete que apareça quando ele receber o foco, qual é a máscara e como o seu preenchimento deve ser feito. Assim, se o script de mascaramento automático não funcionar, o usuário ainda saberá como preencher o campo.

Indique quais são os campos obrigatórios. Normalmente isto é feito adicionando uma estrela (*) vermelha ao lado do campo ou da descrição do campo.

Utilize uma seleção hierárquica se as buscas possam ser realizadas por assuntos ou tópicos específicos.

Imagine uma situação em que o usuário deseja realizar um agendamento médico em determinado hospital da rede pública de sua cidade. Ele terá de escolher um hospital de sua preferência, a especialidade médica desejada e um dos médicos que possuem horário disponível.

Em um formulário tradicional, o usuário teria que buscar o hospital a partir do nome digitado, escolher a especialidade entre uma lista disponível e escolher um dos médicos em uma lista.

Proj.RT.NNN.vv

14

digitado, escolher a especialidade entre uma lista disponível e escolher um dos médicos em uma lista.

Fevereiro de 2009

Se o preenchimento for feito de forma assíncrona, ainda é possível evitar que o usuário escolha um médico que não pertence ao hospital. Mas isto exige que o sistema suporte linguagens client-sided, ou diversos “reloads” da página – um para cada opção selecionada. Ainda assim a busca é pouco interativa e exige o uso de controles de formulários.

Uma solução mais eficiente é fazer esta busca de forma hierárquica utilizando hyperlinks. Em uma primeira tela, o usuário receberia a lista de hospitais da região. Após a escolha do hospital, uma nova página é recarregada exibindo a lista de especialidades disponíveis e, em seguida, a lista dos médicos.

Esta solução ainda exige que a página seja recarregada algumas vezes, porém exibe os resultados de uma forma mais clara para o usuário e mais fácil de ser utilizada, pois exige apenas uma tabulação em uma única página, em um rolamento unidimensional.

A diferença fundamental é que o usuário sabe o que esperar ao clicar em um hyperlink. Ao

mudar a opção selecionada em uma dropdown list o usuário não espera que a página seja recarregada ou que uma nova lista de opções apareça assincronamente – o que não acontece quando se clica em um hyperlink.

Desta forma, a interação com o usuário é favorecida pela transparência com que o site executa as solicitações do usuário, por poupá-lo de preencher um formulário e por eliminar quaisquer erros de digitação.

Determine a tabulação do site de modo a seguir a orientação do rolamento da página.

A tabulação é a ordem com que os campos do formulário devem ser preenchidos.

Geralmente, dentro de um formulário, ao apertar a tecla TAB – ou equivalente em um dispositivo móvel – o usuário é direcionados ao próximo campo.

Esta tecla é muito utilizada dentro do ambiente mobile em função de fornecer uma navegação mais rápida e direta dentro de um site. Porém, a navegação se tornaria muito desgastante e confusa caso a tabulação ocorresse de maneira aleatória ou incoerente com a estrutura do conteúdo.

A melhor maneira de manter a orientação da página e não tornar a navegação confusa é

ordenar os campos seguindo o sentido de rolamento da página – normalmente o vertical.

Tecnologia

Forneça alternativas para exibição de conteúdo ou realização de funções que possam não ser exibidas corretamente.

Esta recomendação envolve recursos multimídia no âmbito de tecnologia, cookies e o uso de scripts client-sided.

Proj.RT.NNN.vv

15

envolve recursos multimídia no âmbito de tecnologia, cookies e o uso de scripts client-sided . Proj.RT.NNN.vv

Fevereiro de 2009

Entenda-se por recursos multimídias quaisquer animações, vídeos, sons ou arquivos de streaming. Nem todos os navegadores suportam estas tecnologias, apesar de todas estarem presentes no XHTML tradicional.

Estes recursos fornecem boas interações e favorecem a exibição de grandes quantidades de conteúdo de forma mais limpa e assimilável para o visitante, por isto devem ser utilizados. Entretanto, deve-se ressaltar que estes recursos não devem ferir outras limitações, como tamanho da página e latência de carregamento. Portanto, devem ser utilizados ponderadamente e em situações muito específicas, como pequenas demonstrações.

Como exigem que o usuário carregue um conteúdo de tamanho maior, sempre devem estar inicialmente escondidos, sendo carregados somente se o usuário desejar.

Linguagens client-sided como Javascript já foram mencionadas e, até mesmo, utilizadas por algumas recomendações. No entanto, devemos salientar que nem sempre esta tecnologia é devidamente interpretada pelos navegadores, existindo casos em que os mesmos sequer oferecem suporte a elas.

Embora promovam um grande avanço na questão da interatividade, estas ferramentas devem ser utilizadas com a ressalva de que o sistema não dependa exclusivamente do funcionamento delas. É sempre possível substituí-las por técnicas tradicionais, sem perder o objetivo, como no caso da máscara de entrada, em que se o método automatizado falhar, ainda existe uma explicação da máscara ao lado ou abaixo do campo.

A W3C [4] recomenda que recursos multimídia e elementos client-sided não devam ser

utilizados. Esta é uma postura radical, pois é possível contornar o problema conforme descrito acima e, quando existe portabilidade para tal, estes elementos tornam a navegação e interação do usuário com a página muito melhores.

Cookies são arquivos que o site salva no dispositivo do usuário e que contêm informações utilizadas pela própria página. Normalmente são utilizados para memorizar localmente usuários e senhas, de forma que o usuário não precise fazer sua identificação quando retornar à página em um momento posterior.

A utilização de cookies é análoga às outras mencionadas acima, com o diferencial de que a

W3C não se posiciona deliberadamente contra seu uso em ambiente mobile. Segundo a organização, apenas não se deve confiar que cookies estarão habilitados.

Siga a especificação das linguagens definidas pela W3C.

Embora pareça óbvia, esta recomendação é de suma importância e está presente no documento publicado pela W3C [4]. A maioria dos desenvolvedores não segue a especificação da linguagem definida pela organização. Um bom meio de verificar se determinado site está dentro das normas de programação é utilizar o sistema da própria W3C para validação de código, presente em: http://validator.w3.org/mobile/.

Ao seguir estas normas, o desenvolvedor está, automaticamente, garantindo que os navegadores desenvolvidos a partir delas – a grande maioria – interpretem e exibam o conteúdo da maneira correta.

Proj.RT.NNN.vv

16

a partir delas – a grande maioria – interpretem e exibam o conteúdo da maneira correta.

Fevereiro de 2009

Uma destas normas diz respeito à codificação de caracteres utilizada. A W3C recomenda o uso exclusivo do padrão UTF-8.

Realize testes reais sobre sua aplicação em todos os dispositivos e browsers possíveis.

Devido a todas estas possíveis incompatibilidades ou más interpretações e exibições de conteúdo por parte dos browsers e dispositivos, um teste abrangente pode não ser satisfatório.

Após analisar e descobrir as características do público-alvo, o desenvolvedor deve estudar quais tipos de dispositivos e navegadores estes futuros usuários estarão utilizando ao acessar a página. Isto pode ser feito através de pesquisa, questionários, entrevistas ou testes de campo

[6].

Durante a fase de desenvolvimento, é comum os programadores realizarem testes a partir de emuladores de ambiente mobile. Estes testes são eficientes durante a esta fase, pois fornecem uma visualização prévia, com certo grau de precisão, sobre como seria se o site fosse exibido em determinado dispositivo.

Existem muitos emuladores mobile. A maioria das grandes empresas do ramo, como Nokia, Sony Ericsson e Motorola possuem emuladores para seus aparelhos que estão disponíveis na Web 1 .

Entretanto, a fase de testes não deve ser realizada exclusivamente a partir destas ferramentas. Realizar testes reais é fundamental para ter a garantia de que a aplicação será exibida corretamente em determinado dispositivo sobre determinado navegador.

Após a realização de testes utilizando a própria equipe de desenvolvimento, é necessário realizar testes de campo, a fim de obter a aprovação dos usuários e receber comentários a respeito do que pode mudar para tornar a aplicação mais amigável.

A fase de testes é fundamental para verificar se o site atende aos requisitos de usabilidade, interface de interação e tecnologia dos dispositivos.

Armazene informações e arquivos muito requisitados em cache.

Em qualquer site existe um conjunto de informações ou arquivos, como imagens, que são requisitados com certa freqüência pelos seus visitantes.

Estas informações podem ser logotipos, slogans ou mensagens de alerta, por exemplo. Sempre que o usuário acessa uma página do site, ele fará o download destas informações novamente. Em função disto, é uma boa prática pré-armazenar temporariamente estas informações localmente ou atualizar apenas a área da página que terá o conteúdo afetado.

1 Motorola: http://developer.motorola.com/docstools/sdks/ Nokia/Sony: http://mtld.mobi/emulator.php Emulador Nokia (aplicações não-web): http://www.ramalhoblog.com/simulador-nokia-s60-download/

Proj.RT.NNN.vv

17

Emulador Nokia (aplicações não-web): http://www.ramalhoblog.com/simulador-nokia-s60-download/ Proj.RT.NNN.vv 17

CONCLUSÃO

Fevereiro de 2009

Ao final de toda esta discussão, pode-se dizer que definir metas de usabilidade e de experiência do usuário são fundamentais para que se possam seguir as políticas de boas práticas. Sendo, desta forma, possível construir uma aplicação amigável, eficiente e que explore os bons recursos disponíveis pela plataforma móvel.

As recomendações de desenvolvimento estão listadas abaixo:

O conteúdo a ser exibido é, tão somente, aquele que o usuário procura

O conteúdo principal deve sobrepor o conteúdo extra

O conteúdo deve ser bem apresentado em qualquer dispositivo que o usuário utilize

O conteúdo deve estar hierarquizado, através de um índice ou menu com lista de opções

Utilize navegação “drill-down” ao exibir conteúdos muito extensos e com subdivisões em uma mesma página

A apresentação do conteúdo deve ser feita de forma vertical

Não utilizar endereços eletrônicos longos e com muita pontuação

Destaque e identifique claramente os links, assim como o que eles fazem

A barra de navegação deve estar disposta no rodapé da página e um link para a sessão anterior ou home Page deve ser exibido no topo

Utilize teclas de atalho para as tarefas e ações mais comuns

Não recarregue a página, não utilize pop-up’s e não redirecione o usuário sem seu consentimento

Não se deve utilizar frames ou tabelas como recursos de layout

Utilize headings e subheadings para exibição de textos longos

O título da página deve ser curto e objetivo, com o propósito único de identificação

O tamanho total da página a ser carregada não deve exceder os 10kb

Utilize medidas relativas ao especificar tamanho de elementos da página

Não utilize imagens “spacers” para alinhar verticalmente o conteúdo

Utilize textos alternativos para a exibição de conteúdo multimídia

Não utilize imagens no plano de fundo da página

Utilize máscaras de entrada em campos de preenchimento padrão

Sinalize de forma clara e direta o que o deve ser preenchido em determinado campo de formulário

Utilize uma seleção hierárquica se as buscas possam ser realizadas por assuntos ou tópicos específicos

Determine a tabulação do site de modo a seguir a orientação do rolamento da página

Forneça alternativas para exibição de conteúdo ou realização de funções que possam não ser exibidas corretamente

Siga a especificação das linguagens definidas pela W3C

Realize testes reais sobre sua aplicação em todos os dispositivos e browsers possíveis

Armazene informações e arquivos muito requisitados em cache

Proj.RT.NNN.vv

18

os dispositivos e browsers possíveis • Armazene informações e arquivos muito requisitados em cache Proj.RT.NNN.vv 18

Fevereiro de 2009

Após a conclusão do projeto de desenvolvimento, deve-se fazer uma avaliação interna quanto às questões abordadas pelas recomendações de boas práticas e, a seguir, uma avaliação externa de usabilidade e interação, utilizando possíveis usuários – testes de campo.

Deve-se ressaltar que nem sempre é possível adotar todas as políticas. Por este motivo, a equipe de desenvolvedores deve ponderar as mais relevantes para suas aplicações, levando em consideração os objetivos de usabilidade definidos na fase de inicial do projeto.

REFERÊNCIAS

[1] M. Chae e J. Kim, “What's so different about the mobile Internet?”, Commun. ACM, vol. 46, 2003, pp.

240-247.

[2] Little Springs Design, “Mobilize, Don’t Miniaturize”, http://www.littlespringsdesign.com/ [3] X. Xiao, Q. Luo, D. Hong, H. Fu, X. Xie, e W. Ma, “Browsing on small displays by transforming Web pages into hierarchically structured subpages,” ACM Trans. Web, vol. 3, 2009, pp. 1-36. [4] World Wide Web Consortium, “Mobile Web Best Practices”, http://www.w3.org/TR/mobile-bp/ [5] J. Nielsen, “Usability Engineering”, Morgan Kaufmann, 1993. [6] H. Sharp, Y. Rogers, e J. Preece, “Interaction Design: Beyond Human-Computer Interaction”, Wiley,

2007.

[7] J. Trevor, D.M. Hilbert, B.N. Schilit, e T.K. Koh, “From desktop to phonetop: a UI for web interaction

on very small devices,” Proceedings of the 14th annual ACM symposium on User interface software and technology, Orlando, Florida: ACM, 2001, pp. 121-130. [8] Y. Cui e V. Roto, “How people use the web on mobile devices,” Proceeding of the 17th international conference on World Wide Web, Beijing, China: ACM, 2008, pp. 905-914. [9] S. Trewin, “Physical usability and the mobile web,” Proceedings of the 2006 international cross- disciplinary workshop on Web accessibility (W4A): Building the mobile web: rediscovering accessibility?, Edinburgh, U.K.: ACM, 2006, pp. 109-112. [10] S. Shrestha, “Mobile web browsing: usability study,” Proceedings of the 4th international conference on mobile technology, applications, and systems and the 1st international symposium on Computer human interaction in mobile technology, Singapore: ACM, 2007, pp. 187-194.

Proj.RT.NNN.vv

19

symposium on Computer human interaction in mobile technology , Singapore: ACM, 2007, pp. 187-194. Proj.RT.NNN.vv 19