Análise de Interfaces

Desenvolvimento

Guia de programação
Padrões Delphi
Filosofias
Interface Commerce
Uso de componentes
Mais sobre Interface
Documentação em Fontes
Estrutura de Pastas

Fonte: Laboratório de Utilizabilidade do Centro de Tecnologia em Automação e Informática de Santa Catarina. www.labiutil.inf.ufsc.br/ergolist.

Construções de Telas

Para construirmos uma tela, devemos primeiro observar que a disposição dos componentes e o tipo de componente usado deve minimizar as ações do usuário. Para isso, o programador terá que contar com o seu conhecimento na ferramenta de programação utilizada, com os seus conhecimentos em sistema operacional e com a sua criatividade. Existem vários componentes diferentes capazes de realizar a mesma tarefa, por exemplo: para disponibilizar certas opções para o usuário podemos criar botões, menus, teclas de atalhos. Dependendo da ocasião um poderá ser mais adequado que o outro. O menu facilita a procura de uma opção entre várias opções; o botão é mais ágil que o menu e mais intuitivo que a tecla de atalho; a tecla de atalho é mais veloz que o menu e os botões, mas exige um pouco de experiência. O analista de interface deve ser capaz de identificar o componente mais adequado para cada situação, tanto para o usuário, quanto para o programador.

Um analista de interface precisa ter domínio na ferramenta de programação, no sistema operacional, ser criativo e ter bom gosto.

As demais qualidades dependerão da experiência e dedicação do programador, mas o bom gosto pode ser adquirido facilmente, apenas observando as recomendações apresentadas mais adiante neste capítulo.

Uma outra observação que devemos considerar ao construirmos uma tela refere-se ao fato de que o usuário não deve precisar lembrar de dados exatos de uma tela para outra, cada tela deve ser independente. Desse modo, sempre que o usuário necessitar escolher uma opção entre uma lista, a lista de opções deve estar visível. Exemplo: em uma nota fiscal, uma lista de clientes cadastrado deve estar disponível para que o usuário possa escolher. Geralmente o componente LookupCombo do Delphi é usado para este fim, mas a necessidade de uma procura mais complexa pode exigir que sejam criado botões de comandos para acessar consultas mais apropriadas ou o próprio cadastro de clientes, caso o cliente ainda não seja cadastrado. A lista de dados deve estar ordenada, geralmente a ordem alfabética crescente é a mais indicada.

Outras observações que podem auxiliar o analista de interface

Quando um software exigir o uso constante do mouse, os editores de imagens por exemplo, as teclas de atalho devem ser constituída de no máximo duas teclas, próximas o suficiente para serem acessados por apenas uma mão. Dessa forma, o usuário poderá acessar um recurso enquanto mantém a outra mão sobre o mouse;

As teclas de funções perigosas devem solicitar confirmação, se forem muito perigosas, devem ser constituídas de três teclas no mínimo;

Quando houver entrada de dados com valores prováveis, o sistema deve adicionar estes valores na inclusão. Exemplo: os sistemas que rodam em Santa Catarina podem sempre sugerir ?SC? na entrada de dados rotulada de ?Estado?. Caso o mesmo sistema seja executado em outros estados, pode-se criar um arquivo de parâmetros contendo o Estado default, que pode ser definido na instalação do sistema, onde o próprio programa solicita a informação ou simplesmente gravar automaticamente no arquivo de parâmetros sempre que na entrada de dados o usuário definir um Estado diferente do default.

Quando um formulário de entrada de dados é apresentado, o sistema deve colocar o cursor automaticamente no começo do primeiro campo de entrada.

Em toda ação destrutiva, o botão default não deve agir sobre a própria ação destrutiva, mas sobre sua anulação. Exemplo: se em um cadastro de clientes o usuário solicitar a opção ?excluir?, o pedido de confirmação ?Confirma exclusão do cliente?? deve posicionar o foco inicial no botão ?Não?, dessa forma, se o usuário não responder a pergunta e apenas pressionar a tecla ?Enter? , a exclusão será cancelada.

O sistema deve informar ao usuário sobre o sucesso ou fracasso de uma ação.

Fornecer resposta sobre as mudanças de atributos dos objetos. Exemplo: em uma janela destinada à modificação de parâmetros, tão logo o usuário faça entrar novos valores para a margem esquerda de um texto, as mudanças são imediatamente refletidas na janela do documento, o texto é reformatado. Ao finalizar o layout desejado, o usuário confirma as mudanças finais e fecha a janela de parâmetros.

O sistema não deve interromper o usuário durante uma transação até que uma ação explícita seja comandada. Exemplo: em um cadastro de clientes onde o número do CGC é testado, antes de se terminar a digitação o usuário não deve ser interrompido por uma mensagem de advertência, ela pode vir após o ?Tab? ou, preferencialmente, quando for solicitada a gravação, neste caso, mensagens sem interrupção podem orientar o usuário.

O sistema deve informar o usuário sempre que ao fechar um formulário ou ao sair de um sistema, uma ação não concluída resultar em perda de dados. Exemplo: para inserir um novo cliente em um cadastro de clientes, o usuário necessita pressionar o botão ?inserir novo cliente?, entrar com os dados e pressionar o botão correspondente a opção gravar. Caso o usuário eventualmente não tenha pressionado o botão ?gravar?, e sim, venha a pressionar o botão ?fechar formulário? ou ?sair do sistema?, deverá ser advertido por uma mensagem orientado a perda de dados conseqüente ao fato do usuário ainda não ter pressionado o botão gravar.

Os sistemas devem possuir, se for conveniente, uma forma de ajuda sensível ao contexto e a transação corrente.

Se uma determinada ação do usuário bloquear o sistema por um certo tempo, ou porque o resultado de uma transação afeta os resultados de ações posteriores ou porque a ação exige o uso exclusivo do processador. O usuário precisa ser avisado desse bloqueio, e se possível, do tempo estimado. Este bloqueio pode ser indicado pelo desaparecimento do cursor do teclado ou pela mudança na forma do cursor do mouse, além de ser acompanhado de um sinal sonoro caso o usuário tente executar uma ação bloqueada. Um digitador pode digitar uma grande quantidade de texto até perceber que o teclado foi bloqueado caso o sistema não emita sons de advertência.

Formulários

Por uma questão de estética o uso do negrito em formulários deve ser evitado ao máximo. O sublinhado deve ser usado somente para destacar palavras, mas o itálico pode ser usado no lugar do sublinhado e é muito mais elegante. As cores podem ser usadas desde que não carreguem o formulário.

Os componentes em um formulário devem estar alinhados o quanto possível uns aos outros e agrupados por coerência. Os componentes de um mesmo grupo devem estar separados de um outro grupo, ou por um espaço maior, ou por um separador qualquer.

Entrada de dados

Mostradores de dados, entrada de dados e convite a interação precisam ter uma forma única de apresentação (uma cor ou um símbolo), para que o usuário possa distinguir bem onde estão as informação somente de leitura, as de leitura e interação e as de leitura, interação e gravação. O Delphi dispõe de diversos componentes para trabalhar com estes três tipos de dados; o componente Label por exemplo, se diferencia do componente Edit pela cor e forma. Um usuário habituado com a forma e a cor do Edit iria estranhar tendo que digitar em um Edit com a cor e forma de um Label. Os componentes de interação do Delphi também se diferenciam, os botões por exemplo, a forma de relevo convida o usuário a pressioná-lo. No entanto, há componentes que fogem um pouco deste padrão, neste caso, o programador precisa ajustar manualmente, é o caso das grids. Elas não tem um forma diferenciada indicando se o usuário pode alterar os seus dados ou somente consultar.

Distinguir em um formulário as entradas de dados que são obrigatórias.

Quando uma entrada de dados for uma senha, os caracteres digitados não devem aparecer na tela, podem ser substituídos por um asterisco.

Rótulos

Nas entrada de dados: um rótulo, um hint ou uma mensagem sem pedido de confirmação deve ser usado quando existir um formato particular, uma faixa de valor, uma unidade financeira ou uma unidade métrica.

Sempre que um documento em papel servir como entrada de dados, o layout da tela deve ser projetado correspondendo a forma do documento. Isso ajuda o usuário a encontrar e manter a localização dos dados no papel e na tela enquanto olha para cima e para baixo.

A primeira letra da primeira palavra de um rótulo é maiúscula as demais são minúscula.

Evitar palavras difíceis e abreviaturas incomum para os usuários.

Textos

Apresentar textos contínuos em colunas largas, contendo no mínimo 50 caracteres por linha. Quando o espaço para a apresentação do texto for limitado, deve-se apresenta-lo preferencialmente em poucas linhas longas, do que em muitas linhas curtas. O texto apresentado em colunas largas será lido com rapidez significativamente maior, do que o texto apresentado em colunas estreitas.

A apresentação de textos em campos rolantes deve prever, ao menos, quatro linhas por vez. Quatro linhas de texto constituem o mínimo que deve ser apresentado, quando o conteúdo é simples. No caso de o conteúdo tornar-se mais complicado, ou se o leitor tiver que voltar atrás em sua leitura freqüentemente, devem ser apresentadas mais linhas.

Os parágrafos de texto devem ser separados por, pelo menos, uma linha em branco.

Os textos devem ser apresentados utilizando mistura de caixa alta e caixa baixa, em vez de somente em caixa alta. As maiúsculas devem ser utilizadas com precaução, sobretudo no corpo de um texto. A leitura e a decifração de texto em maiúsculas é 30% mais lenta do que um texto em minúsculas, em virtude das formas distintas presentes nos traços verticais (por exemplo o traço vertical do h) e as pernas das letras. Além disso, escrever tudo em maiúsculas pode produzir, no ato de leitura, a sobreposição parcial de duas linhas, tornando a leitura mais difícil.

Apresentação de dados

Listas de dados alfabéticos devem ser justificadas à esquerda.

Listas contendo decimais devem ser alinhadas pelo ponto decimal.

Listas de números sem decimais devem ser justificadas à direita.

Os códigos que o usuário deve memorizar devem ser os mais curtos possíveis, não ultrapassando 4 ou 5 caracteres. A digitação de códigos que são significativos e que ultrapassam 7 caracteres devem ser divididas em unidades menores de três ou quatro caracteres. Exemplo: número de um telefone 999 999 9999.

Os dados devem ser apresentados diretamente aos usuários na forma usual, sem necessidade de conversão.

Mensagens

Usar frases afirmativas e na voz ativa. As frases na afirmativa são mais facilmente compreendidas do que as negativas. Deve-se dizer o que deve ser feito em vez de o que deve ser evitado. Exemplo: escreve-se ?Limpe a tela antes de inserir dados? é não ?não insira dados antes de limpar a tela?.

A informação principal de uma mensagem de erro deve se encontrar no início da mensagem.

A informação que necessite permanecer na memória do usuário para poder ser relembrada imediatamente deve se encontrar no final da mensagem de erro.

Salvo em situações especiais, as mensagens de erro devem ser escritas em tipos mistos (maiúsculas e minúsculas) e não somente em maiúsculas.

Se uma frase descreve uma sequência de eventos, a ordem das palavras na frase deve corresponder à sequência temporal dos eventos. A ordem temporal deve ser clara, de modo a não causar confusão na mente do usuário, como o que ocorreria com uma ordem cronológica invertida. Exemplo "Entre com sua senha antes de rodar um programa." e não "Antes de rodar um programa entre sua senha."

As mensagens de erro capturadas pela sistema, devem possuir um botão de ajuda indicando a causa detalhada e a solução do problema.

As mensagens de erro devem ser neutras, polidas e educadas, devem evitar qualquer terminologia hostil ou agressiva ao usuário, não devem julgá-lo, embaraçá-lo ou insultá-lo e não devem ser autoritárias ou humorísticas.

As mensagens de erro devem explicar os erros utilizando a linguagem do usuário, com palavras de uso comum, evitando o uso de terminologia vaga.

Os mensagens de erro não devem ser abreviadas ou codificadas.