Design para Dispositivos Moveis - O primeiro passo para um sistema bem sucedido, é a interação com o usuário

Uma das maiores dificuldades ao se criar sistemas para dispositivos móveis (para Pocket PC especificamente) é o design e o diagrama de navegação dos sistemas.

por Max Mosimann Netto

Nem sempre uma idéia revolucionária para um sistema, ganha fama e faz sucesso por alguns motivos básicos. Esses motivos podem ser baixo desempenho, sistema complexo demais, alto custo e etc. Mas sem dúvida, um dos maiores problemas no lançamento e na aceitação de um software é a interação do mesmo com o usuário, principalmente quando abordamos sistema que serão executados em dispositivos com baixa resolução de vídeo, baixa memória e sem teclado.

Design, um dos pilares do sucesso

Uma das maiores dificuldades ao se criar sistemas para dispositivos móveis (para Pocket PC especificamente) é o design e o diagrama de navegação dos sistemas.

O design consiste na interface (menus, logotipos e etc.) que faz do sistema muito mais que um simples formulário.

O diagrama de navegação consiste no caminho que o usuário do sistema deverá fazer para chegar a um determinado ponto.

Geralmente tais sistemas são projetados levando em consideração os limites impostos pelos paradigmas dos dispositivos, como resolução de tela, teclado pequeno, one-hand (acesso com apenas uma mão) e etc. O trabalho dos projetistas de interface é de criar a melhor forma de interface, buscado sempre a inovação e criando formas de navegação mais cômodas e funcionais para os usuários.

Devemos entender que um layout (entenda design) para tais dispositivos, deve ser equiparável com qualquer outro tipo de layout e sendo assim, devemos obedecer a certos padrões, para que a navegação se torne atrativa, tanto do ponto de vista da interface, quanto da navegação.

A consistência deve ser algo crucial em todo o projeto de design. Consistência é a padronização que deve ser seguida quando um projeto de interface é criado. Por exemplo: Se você cria um menu laranja ao lado direito com os itens do sistema em azul, o mesmo padrão deve ser seguido para todos os módulos do sistema. Não podemos, por exemplo, criar o menu cada hora em um lugar. Podemos ver que essa é uma boa prática a ser seguida, pois livros, revistas e jornais têm seu projeto de interface padronizado.

Não confunda, no entanto, a criação de designs diferentes para diferentes módulos do sistema, com falta de padronização.

Devemos criar formas de acesso direto a módulos existentes para usuários mais avançados. Nada de forçar o usuário a navegar por cinco ou seis módulos diferentes a fim de chegar ao 7º, por exemplo. Usuários mais experientes já têm afinidade com o layouts desenvolvidos, e por esse motivo já sabem onde querem ir e como chegar ao ponto desejado. Nada melhor do que facilitarmos isso!

Outro ponto essencial é o feedback - Sistemas que realizam ações e não devolvem um status ao usuário, tendem a ser cansativos e desacreditados. Imagine a seguinte situação: Você preenche 30 campos relativos a um cadastro. Normalmente esse cadastro já iria demorar consideravelmente, pois como sabemos toda forma de preenchimento de campos é feito usando a stylus (caneta para Pocket) com apenas uma mão. Ao terminar de preencher os campos você clica no botão [Cadastrar] quando subitamente a tela principal do sistema é aberta sem maiores justificativas. O que ocorreu? O cadastro foi gravado? Ocorreram erros? Sendo assim, devemos informar uma resposta para cada ação tomada pelo usuário. Mensagens do tipo MessageBox são bem vindas.

Por falar em mensagens, informar o usuário a cada passo do sistema com mensagens causam sensação de alívio ao executar uma série de instruções. Além de pré-informar quais são as próximas ações que devem ser seguidas. Por exemplo: Depois de passar por três ou quatro módulos preenchendo campos e selecionando opções devemos informar ao usuário: "Cadastro de Nota Fiscal concluído com sucesso. Informe os rendimentos.".

Controle absoluto sobre tudo que o ocorre em um sistema é fundamental para que o usuário se sinta a vontade em utilizá-lo. O usuário deve ser quem dispara ações, e não o sistema. Nada de mensagens dando informações sem que o usuário as solicite. Podemos fazer uma comparação aos Pop-ups; Quem gosta?

Erros também devem ser muito bem codificados e corrigidos. Uma mensagem dizendo: "Não foi possível encontrar uma instância para o objeto" é bem entendida por usuários leigos em programação? O sistema deve ser capaz de tratar erros e mostrar mensagens amigáveis, nada de intimar o usuário com mensagens do tipo "Um Soft-Reset será executado em seu dispositivo. Deseja continuar?". O usuário responde que sim, e logo vem a outra mensagem: "Essa ação poderá danificar sistemas em execução. Deseja realmente continuar?". Essa última será entendida como: "Atenção - Seu Pocket poderá nunca mais funcionar corretamente se você fizer isso! Tem certeza do que você esta fazendo?". Padrões para mensagem também devem ser sempre seguidos. Isso fará com que seu sistema seja bem visto dentre os usuários.

Outro item fundamental é a opção de voltar atrás em uma operação. Existem sistemas que se você entra no módulo de pedidos, só consegue sair se terminar de fazer um pedido ou reiniciar o software. Crie situações onde o usuário possa voltar para a tela onde chamou a outra. Uma forma simples de se fazer isso é criar um sistema de hierarquia de navegação. Por exemplo: Supondo que o usuário clicou em pedidos na tela principal, e logo em seguida clicou em pesquisa de pedidos dentro da tela de pedidos. Na parte superior ou em algum lugar que seja visualmente bom poderíamos colocar assim: "Meu Principal -> Pedidos -> Pesquisa de Pedidos". Se o usuário quisesse voltar para qualquer item anterior, basta que ele clique sobre os "links". Os menus são tão importantes quanto à navegação do sistema. Menus muito cheios de informações prejudicam a memorização e consequentemente a localização de informações. Um menu com 30 tópicos não é memorizado pelo usuário com facilidade. Pesquisas afirmam que pessoas normais memorizam sete coisas por vez, ou seja: Se seu menu tiver 30 tópicos, na hora que o usuário ler o oitavo, ele já se esqueceu do primeiro, e assim consecutivamente.

Crie um sistema de fácil entendimento. Se possível separe o sistema por categorias Macro, e não micro. Não há necessidade de colocar no mesmo menu, a inclusão de pedidos, a pesquisa de pedidos, a exclusão de pedidos e a alteração de pedidos. Coloque um tópico chamado Pedidos, que quando acessado leva o usuário a escolher as opções disponíveis dentro da categoria pedidos.

Uma coisa que devemos sempre lembrar, é que por mais que o usuário deva ter o controle sobre o software, nunca devemos deixar que ele faça o que bem entender do sistema. Imagine um software que é totalmente personalizável, desde cores até fontes. Geralmente usuários "enfeitam" os softwares sem respeitar a harmonia de cores que o designer organizou. Imagine um software que foi desenhado para ser verde e branco, e de repente o usuário mistura mais umas quatro cores. Devemos sim deixar o usuário "pintar e bordar" quando o software é especifico pra isso, em outros casos, mantenha o padrão criado pelo projetista, e acima de tudo mantenha proporções entre os objetos.

Desenvolver sistemas para clientes exige uma análise muito profunda de vários aspectos do software. Devemos analisar o logotipo da empresa (caso o cliente solicite o mesmo no sistema) para que fique harmônico com os demais itens, devemos lembrar sempre que a tela do Pocket é restrita, portanto não podemos gastar o espaço com coisas "inúteis".

Uma das grandes novidades ultimamente é a possibilidade de se trabalhar com o pocket deitado (landscape). Isso será uma grande inovação para designers e projetistas de interfaces para esses dispositivos, pois permite que a largura das telas que antes era tão restrita, não seja mais um grande impedimento para a criação de algo inovador.

Essa nova feature faz parte das funcionalidades oferecidas pelo Windows Mobile 2003 Second Edition, e só funcionam em equipamentos que utilizam tal sistema operacional. Existem DLL no mercado que têm o mesmo efeito, porém são incompatíveis com uma grande variedade de dispositivos.

Abaixo, demonstro como projetar e criar uma interface utilizando a tela em Landscape para Pocket PCs. Irei utilizar o Visual Studio.NET 2003 com o emulador Pocket PC 2003 com as novas imagens de aparelhos já deitados para que a possamos visualizar corretamente os exemplos.

O SDK (Software Development Kit) Pocket PC 2003 pode ser obtido em: http://www.microsoft.com/downloads/details.aspx?FamilyId=9996B314-0364-4623-9EDE-0B5FBB133652&displaylang=en e as imagens para os dispositivos com a tela já deitada podem ser obtidas em: http://www.microsoft.com/downloads/details.aspx?familyid=5C53E3B5-F2A2-47D7-A41D-825FD68EBB6C&displaylang=en.

Depois de instalado o SDK e as Images, quando um projeto do tipo Smart Device Application for executado, teremos as opções de executá-lo com os emuladores Pocket PC 2003 ou com a linha Pocket PC 2003 SE, como visto na Figura 1.

Figura 1. Uma lista de templates para execução nos emuladores.

Ao selecionarmos a opção WWE PPC 2003 SE Landscape - SDK Emulator, o emulador será exibido "deitado", como visto na Figura 2. Agora, ao invés de termos a resolução de 240x268 pixels (Pocket em pé), temos 320x188 (Pocket deitado). É obvio que o aumento da largura da tela não significa que todos os problemas estão resolvidos, pois agora a altura da tela diminuiu consideravelmente.

Figura 2. O emulador é exibido na posição Landscape

Irei construir um protótipo de um sistema de pedidos utilizando o Pocket em Landscape. Esse protótipo será construído de maneira a aproveitar as dimensões oferecidas pelo sistema de "tela deitada" - 320x188.

Notem quem é possível levar para o Pocket os mesmos recursos disponíveis em um sistema WinForms adaptado para as dimensões do dispositivo, como visto na Figura 3.

Figura 3. Um sistema sendo executado em um Pocket PC, muito semelhante a um sistema winforms tradicional.

O design do sistema pode ser construído utilizando os softwares de editoração de imagens mais comuns do mercado. Utilizei o Adobe Photoshop para criar o design do sistema. Pequenos detalhes fazem a grande diferença entre um sistema profissional e algo amador, um deles é o InputPanel (teclado virtual para Pockets). Ao exibir o teclado virtual, perdemos parte da tela do sistema, e em alguns casos perdemos também o campo que disparou a visualização do teclado.

A solução mais viável é deslocar a tela do sistema para cima, de acordo com o tamanho do InputPanel, como visto na Figura 4.

Figura 4. Não perdemos de vista o campo onde o texto é digitado

Devemos, no entanto englobar todos os controles da tela de login dentro de um Panel, apenas para facilitar o deslocamento da tela.

O efeito de deslocamento pode ser obtido com o seguinte código:

Listagem 1. Código referente à visualização do InputPanel
Private Sub ShowInputPanel(ByVal sender As Object, ByVal e As System.EventArgs) Handles tbLogin.GotFocus, 
tbSenha.GotFocus
    InputPanelLogin.Enabled = True
End Sub

Private Sub HideInputPanel(ByVal sender As Object, ByVal e As System.EventArgs) Handles tbLogin.LostFocus, 
tbSenha.LostFocus
    InputPanelLogin.Enabled = False
End Sub

Private Sub InputPanelLogin_EnabledChanged(ByVal sender As System.Object, ByVal e As System.EventArgs) 
Handles InputPanelLogin.EnabledChanged
   If InputPanelLogin.Enabled = True Then
      pnPrincipal.Top = Not ((Me.Bounds.Height - InputPanelLogin.Bounds.Height) - 29)
   Else
      pnPrincipal.Top = 0
   End If
End Sub

Onde ShowInputPanel e HideInputPanel são duas procedures criadas por mim que são associadas aos evento GotFocus e LostFocus dos controles de Login e Senha, para que seja possível ativar e desativar o teclado virtual sempre que um dos controles receber ou perder o foco.

A Sub InputPanelLogin_EnabledChanged é disparada sempre que o InputPanel é ativado ou desativado. Assim, colocamos a formula para que o Panel que engloba todos os controles do módulo de login seja descolado para cima a mesma quantidade de pixels ocupada pelo teclado virtual. Quando o teclado é desativado, o panel volta para a posição 0 (zero) e os controles são exibidos normalmente.

Esse trecho de código deve ser replicado para todas os módulos do sistema que possuírem o InputPanel.

Conclusões

Notamos que design para dispositivos móveis não é algo tão trivial como para web ou para sistemas desktop. Devemos planejar muito bem o que será feito, pois como demonstrado, algumas limitações como resolução e memória afetam de maneira direta o trabalho realizado. O mais indicado é procurar empresas que oferecem esse tipo de serviço e estão ganhando cada vez mais o mercado. Para informações sobre esses serviços, entre em contato comigo pelo e-mail: max@codificando.net.