 |
           |
 |
Por
Bill shadish-- |
| ---Dez mandamentos para a criação de interfaces para dispositivos móveis | |
|
|
Este artigo é dedicado àqueles em contato com o desenvolvimento de aplicações para PDAs, handhelds e dispositivos móveis. Ao longo dele, encontraremos guidelines que irão ajudá-lo a definir a aparência e o funcionamento de seus aplicativos para esse tipo de equipamento. No desenvolvimento de uma aplicação desse tipo, vários fatores acabam por influenciar as decisões tomadas. Por exemplo, o dono da sua companhia (provavelmente da época do MS-DOS) deve ter uma opinião muito convicta sobre o que deve estar onde e como. Assim como o dono da empresa, os programadores, provavelmente, também devem ter sua própria opinião sobre o assunto. Finalmente, os usuários finais aqueles a quem a aplicação se destina devem, por sua vez, ter uma opinião totalmente diferente de como as coisas devem parecer e funcionar. Parte do seu trabalho é criar e definir padrões com os quais todos concordem. Tendo em vista que os campos necessários e regras de dados já foram definidos, agora é hora de trabalhar no layout das telas finais. Por onde começar? |
|
Há muito tempo, a IBM criou os guidelines do CUA (Common User Access), para ajudar na definição de um padrão a ser seguido por quem desenvolve telas. Muitas dessas definições da CUA podem nos ser muito úteis até os dias de hoje. Por exemplo, uma das sugestões contidas nessas premissas trata de convencer os programadores a incluir uma janela de aviso sempre que o usuário tentar apagar algum arquivo. Muitos de nós somos gratos por essa regra ter sido criada e estar presente em praticamente tudo, hoje em dia afinal, qualquer de nós pode mudar de idéia na última hora. Abaixo, estão os meus dez mandamentos, a serem considerados na hora de criar UIs (user interfaces) para Pocket PCs.
Independentemente de você estar comprando ou desenvolvendo sua aplicação, uma das mais importantes perguntas relacionadas com a interface é: qual o modelo de navegação desejado? Com o scrolling, o formulário e seus campos são exibidos como uma longa página de Internet, onde a barra de rolagem é usada para navegar para cima ou para baixo. Este método funciona bem para a web, no Word ou em documentos do tipo Adobe Acrobat, mas pode ser incômodo para usuários forçados a mover (e ver) uma tela para cima e para baixo na hora de usar o aplicativo. O problema é que os usuários costumam esquecer o que não conseguem enxergar. Campos de entrada enterrados fora da área visível da tela, provavelmente, serão deixados de lado, a menos que sua página remeta o usuário de volta aos campos de preenchimento necessário. A alternativa a tudo isso é adotar o modo de navegação paginada, onde os campos (ou conteúdo) estão divididos em páginas separadas, sempre do tamanho da tela. Quando o número de páginas é pequeno, você pode permitir que o usuário as acesse, clicando em abas (tabs). Mas, se há muitas páginas, você pode optar por botões de anterior/próximo no rodapé do formulário, que vão direcionar o usuário até as páginas escolhidas. Usando esse método, o valor das informações de uma tela nunca serão mais longos que a área exibida pelo equipamento. Esse tipo de controle ocupa muito pouco espaço útil de tela. Além disso, será extremamente útil, se mostrar que os campos de preenchimento obrigatório da página ainda não foram todos preenchidos, ficando desabilitados até que isso aconteça. Isto fornece um sinal claro para o usuário, informando-o de que preencheu corretamente a página, antes de clicar em prosseguir. Um fator a ser considerado na implementação de botões anterior/próximo é o fato de as telas variarem de tamanho, de dispositivo para dispositivo o que resultará em algum trabalho extra para o desenvolvedor.
Ah, esse é o primeiro lugar que os desenvolvedores visitam para brincar com o novo ambiente. Você vai encontrar fontes em itálico, três, ou mais, tamanhos, fontes em negrito e até wingdings engraçadinhas, geralmente, mais variações do que você consegue apontar chacoalhando uma caneta stylus. Uma boa regra é não usar mais que dois tamanhos de fonte diferentes na sua aplicação (de preferência, apenas uma) e usar o negrito para diferenciar campos de títulos ou texto. Não há nenhum problema em usar adicionalmente um tamanho bem menor de fonte para itens como avisos de copyright.
Essa é a segunda coisa que os desenvolvedores fazem, ao melhorar suas habilidades numa plataforma nova. Não se assuste ao ver cores, muitas cores, durante as primeiras interações nesses tipos de aplicativos. Mais do que duas ou três cores (incluindo o preto), em qualquer tipo de tela, costumam, porém, confundir, mais do que ajudar. Essas duas ou três cores devem ser respeitadas e usadas em todo o aplicativo, e se possível, em toda linha de produtos e aplicativos. Uma dica: Lembre-se sempre de que há pessoas com dificuldades visuais no mundo real. Essas pessoas também gostariam de poder usar (leia: comprar) suas aplicações. Depender apenas de cores para diferenciar seções na tela é excluir todo esse universo de usuários.
Todo mundo sabe que canetas stylus são usadas para operar um PDA. Com elas, é possível tocar uma área muito pequena na interface com o propósito de selecionar algo. Isto fez com que desenvolvedores conseguissem colocar o maior número de coisas possível dentro de um tela (veja exemplo abaixo). Além de criar uma tela confusa que pode levar o usuário a um esforço visual desnecessário, isso também dificulta o uso dos dedos para selecionar coisas na interface. Humanos às vezes preferem tocar na tela com os dedos, no lugar de brigar para pegar a stylus. Ou, pior, às vezes eles a perdem! Desenhe o seu programa com isso em mente e teste-o usando apenas os dedos. Como resultado, seu programa conterá menos telas "abarrotadas" e permitirá o uso com apenas uma mão, permitindo que o usuário segure outras coisas, como um telefone, por exemplo.
Uma coisa que costuma gerar muita ligação pedindo suporte é quando uma aplicação decide esconder (remover) um controle ou funcionalidade da área de visão do usuário, ao invés de, simplesmente, desabilitá-lo. Desenvolvedores preferem esconder menus, controles e, até mesmo, telas inteiras, quando isto não é relevante para os usuários. Este procedimento costuma frustrar o usuário, especialmente quando ele usou um desses itens no passado e, agora, não consegue mais encontrá-lo na interface. Ao invés de esconder, prefira desabilitar essas funcionalidades caso estejam fora de contexto. Assim, o usuário saberá onde a funcionalidade está, sem perder tempo em procurá-la; e também saberá que a funcionalidade em questão não é apropriada ao contexto. Tudo isso tornará as coisas mais simples para todos, resultando em maior conforto para quem vai usar seu aplicativo.
Quando houver um número de escolhas suficiente para ocupar boa parte da tela, uma lista do tipo drop-down deverá ser empregada. E, finalmente, quando o número de escolhas for tão grande ao ponto de não caber na tela, use um list-box assim, o usuário poderá rolar a lista de opções, até fazer a escolha. Ao usar um list-box, tenha o cuidado de ativar o recurso de localizar o registro mais próximo com a entrada do primeiro caractere, especialmente quando houver um número muito grande de escolhas. Uma dica: considere a possibilidade de usar listas MRU (Most Recently Used) na sua aplicação. Elas marcam as opções mais escolhidas por usuários individuais e as exibem junto com a lista. Também permita que o usuário limpe a lista MRU sempre que desejado.
Faça com que sua aplicação peça ao usuário, sempre, que confirme a decisão de apagar alguma coisa. Um aviso do tipo "você deseja realmente excluir [nome do que será excluído]", permitindo escolher entre sim e não, dará ao usuário uma segunda chance. Desta forma, você descobrirá que o número de ligações desesperadas na sua linha de suporte, perguntando como recuperar o que foi apagado, se reduzirá drasticamente. Uma dica: crie alguns níveis de undo em telas que aceitam entradas de texto em blocos.
Especialistas definem "ícone" como um símbolo gráfico que denota um programa, comando, arquivo ou conceito na interface gráfica de usuário. A principal finalidade de representar graficamente um programa (ou operações dentro de um programa) é tornar a vida do usuário mais fácil, quando ele quer executar ou procurar alguma coisa. Quando o desenvolvedor insiste em ficar mudando o formato, a cor ou a figura do ícone nas diferentes versões do aplicativo (ou, contextualmente, dentro da mesma aplicação), ele acaba negando a principal finalidade do ícone, que é simplificar a vida do usuário. Escolha um ícone e permaneça com ele.
Admita: você odeia quando, depois de preencher um formulário ou tela e clicar o botão de enviar, é jogado de volta para a mesma tela, para preencher campos de preenchimento obrigatório, que foram esquecidos. Você odeia mais ainda, quando esses campos não estavam assinalados como obrigatórios. Certifique-se de que o usuário saiba o que é obrigatório, numa tela. Você pode colocar uma pequena seta ou um asterisco, ao lado de cada um dos campos de preenchimento obrigatório. E, pelo amor de Deus, não faça com que o usuário tenha que receber janelas de erro, uma atrás da outra, por cada item esquecido. Mostre a ele tudo que foi esquecido numa única e longa janela de mensagem. Após isso, coloque-o imediatamente no primeiro campo obrigatório que foi esquecido. Isso poupa o usuário do trabalho de ter que localizar o campo novamente.
Existem dispositivos Mobile 2003, Smartphone, Pocket PC 2002 e Pocket PC 2003, entre outros. Cada qual tem o seu próprio tamanho de tela, método de entrada, e até mesmo, aplicações originalmente diferentes sem falar de versões anteriores do Windows CE ou de aplicações que você queira desenvolver em várias plataformas. Nosso mundo já é complexo e está ficando ainda mais. Dedique um pouco de tempo a pensar em como sua aplicação aparecerá e será exibida nessas diferentes plataformas, e como ela vai se comportar. Por exemplo, o Smartphone não tem touch screen. Como isto afeta a sua aplicação pode não ser importante hoje mas não custa nada considerar essa limitação , antes de construir ou reconstruir, assim, ao menos, ter uma explicação pronta para usuários que tentem rodar sua aplicação em dispositivos incompatíveis. Uma dica: o uso de alertas com som ou voz é bastante positivo, mas certifique-se de que todos os dispositivos rodando sua aplicação suportam tais recursos.
Envie sua dica! A presente lista de user interface design do´s and don´ts nesse artigo não é exaustiva. Para enriquecê-la, mande o seu próprio mandamento por Email para info@fo.com. Suas sugestões serão incluídas na versão online deste artigo (veja http://www.fo.com/articles). Junto com o seu mandamento, não esqueça de enviar seu nome e endereço de Email.
U.S.
Department of Health and Human Services Usability E-mail
lists that you can subscribe to for more information or to ask questions Wide
selection of User Interface (UI) thoughts Common
User Access; A consistent and usable human-computer interface for the SAA environments
(History) ProContext
User Interface Style Guides O
texto original em inglês pode ser acessado no seguinte endereço:
Bill Shadish é o presidente da Fundamental Objects, Inc. www.fo.com, onde trabalha com tecnologia de handhelds e em parcerias com clientes. Bill escreve para um número considerável de jornais do segmento. Ele pode ser contactado via bills@fo.com. Permission
to reproduce article from Pocket
PC magazine.(c) 2004 Thaddeus Computing INC. |
