Dicas para o desenvolvimento de um software – Parte 6

Dicas para o desenvolvimento de um software - Parte 6Prezar pela usabilidade e funcionalidade do software sempre foi um aspecto importante a ser considerado. A sexta parte sobre dicas de desenvolvimento traz alguns conceitos mais básicos em comparação com as outras partes dessa série. As quatro dicas a seguir envolvem características visuais, mas que não deixam de ser importantes para a usabilidade. Confira também as outras partes no final deste artigo!

 

Dicas de tela
As dicas de tela, também conhecidas como Hints, são textos que aparecem quando você posiciona o cursor do mouse em um componente da tela, como um campo ou botão. Esses textos trazem uma breve definição da função do componente, extremamente útil para barras de ferramentas que possuem apenas imagens nos botões.

Exemplo de Hint

O problema é que às vezes esses hints não estão disponíveis. Eu já fui vítima de colocar o cursor em um botão e ficar um bom tempo esperando o hint aparecer, rsrs. Por isso, procure adicionar hints bem explicativos na maioria dos componentes visuais da tela. Uma dica dessas pode evitar que o usuário execute uma operação incorreta ou entre em contato com o suporte para questionar sobre a funcionalidade.


Exibição dos dados na Grid

Quem já não visualizou uma Grid dessa forma?

Exemplo de Grid

Cortar informações na Grid é desconfortável para o usuário, que normalmente precisa redimensionar as colunas para visualizar todo o conteúdo. Porém, qual é a melhor solução quando há várias colunas para serem exibidas?
Na verdade, há 3 soluções. A primeira é fixar o tamanho das colunas em tempo de projeto, de modo que todos os valores possíveis da tabela sejam exibidos na íntegra. Em contrapartida, isso pode gerar a necessidade de uma barra de rolagem horizontal para visualizar todas as colunas.
A segunda solução é criar uma função que redimensione automaticamente as colunas em tempo de execução com base no maior valor de cada campo. Portanto, os tamanhos serão variáveis conforme os valores que forem exibidos na Grid. Assim como a solução anterior, provavelmente será necessário ativar a barra de rolagem horizontal também.
Enfim, a terceira solução, que em minha opinião é bem interessante, consiste em dividir o formulário em duas abas: uma que exiba a Grid somente com as colunas que identifiquem o registro (como código e nome, por exemplo) e ao clicar no registro, todos os dados são carregados em campos de texto na outra aba. Em outras palavras, em uma aba o usuário navega entre os registros e na outra aba ele visualiza os dados do registro selecionado.


Imagem de fundo da aplicação

Só para fazer um teste, crie um papel de parede verde fluorescente e coloque como imagem de fundo na sua aplicação. Eu aposto que em dois dias a maioria dos usuários irão marcar uma consulta com o oftalmologista, rsrs. Para os desenvolvedores que eventualmente rodam a aplicação pode não parecer tão cansativo, mas, para os usuários que convivem com o sistema praticamente o dia todo, é desagradável.
A dica é utilizar cores leves dispensando gráficos avançados, talvez apenas com o nome do sistema bem pequeno no canto da imagem.
Outra dica é manter a imagem de fundo dinâmica, ou seja, permitir que o próprio usuário selecione um arquivo no computador, assim como acontece com o papel de parede do Windows.


Ordem de tabulação
No primeiro artigo, mencionei a importância da ordem de tabulação dos campos no tópico sobre facilidade de uso. Imagine que o usuário está no primeiro campo de uma tela e ao pressionar TAB o foco vai para o último? Ruim, não é? Neste caso, nem é possível “adivinhar” a ordem – infelizmente a solução é utilizar o mouse. Bom, eu mesmo devo assumir que muitas vezes já esqueci de ajustar a ordem de tabulação dos campos, rsrs. Portanto, aqui eu reforço essa dica: a tabulação deve ocorrer de cima para baixo sem pular campos, ao menos que estejam desabilitados ou sejam read-only.

E sobre a questão de utilizar o ENTER ao invés do TAB?
Bem, eis que chegamos a mais um dilema entre programadores…

Em minha opinião, o ENTER é uma tecla de confirmação, e não de entrada de dados. Partindo deste raciocínio, eu sempre configuro o ENTER para simular o clique de um botão, confirmar uma mensagem ou selecionar um registro, enquanto o TAB avança entre os campos. Observe que a tecla TAB já possui essa funcionalidade de modo tradicional, utilizada em vários outros sistemas, como o próprio Windows. Inclusive, para retroceder um campo, basta pressionar SHIFT + TAB, o que não é possível com o ENTER. Além disso, reflita: no campo de observações em uma tela de cadastro, o ENTER deverá pular a linha ou avançar para o próximo campo?
Bom, essa é apenas minha opinião, ok?

 

Pessoal, obrigado pela atenção!
Grande abraço a todos!


Confira também as outras partes dessa série de artigos:

Dicas para o desenvolvimento de um software – Parte 1
Dicas para o desenvolvimento de um software – Parte 2
Dicas para o desenvolvimento de um software – Parte 3
Dicas para o desenvolvimento de um software – Parte 4
Dicas para o desenvolvimento de um software – Parte 5
Dicas para o desenvolvimento de um software – Parte 6
Dicas para o desenvolvimento de um software – Parte 7
Dicas para o desenvolvimento de um software – Parte 8
Dicas para o desenvolvimento de um software – Parte 9
Dicas para o desenvolvimento de um software – Parte 10
Dicas para o desenvolvimento de um software – Parte 11


 

Compartilhe!
Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Pin on PinterestEmail this to someone

2 comentários

  1. Realmente o uso dos hints é bom. Fico insatisfeito quando espero por uma dica (hint) e não aparece, mas não aplico sempre. Dá trabalho colocar em todas as possibilidades em um form. Tem um modo de facilitar isso?
    No grid, apesar de redimensionar os campos conforme conforme a resolução e apresentar só os parametrizados (cód. barras/uso, nome/apelido, endereço/cidade,…), sua terceira sugestão é realmente a melhor, ao usar um novo form, aba, tab ou mid. Uso quase todas essas opções, depende da pesquisa, mas não consegui definir um padrão. Aí esta a falta de um gerente de projeto ou Design. Decidir um padrão sozinho não é fácil, melhor trabalhar em equipe.
    Eu tomo cuidado com a ordem de tabulação (usando Tab), mas com o uso do enter valido a digitação e avanço para o próximo campo útil, tipo: no cadastro de produtos, nem todos os campos são necessários (meu caso), com tab é sequencial, com enter próximo campo obrigatório – descrição, tipo de imposto, ncm, und, preço de venda. Diminui de 20 pra 5 e facilita bastante a entrada inicial. Com o tempo o cliente preenche os outros – fornecedor, grupo, custo, mark-up. Estes detalhes fazem a diferença entre um software e outro, e é grande às vezes.

    Mais uma vez, obrigado pelos artigos.

    1. Olá, Gerson!
      Também concordo que a terceira sugestão da exibição de dados na Grid é a melhor, tanto é que venho utilizando essa opção na maioria dos meus projetos. Dividir as telas em cadastro e consulta certamente facilita a busca e inserção de dados.
      Uma ação que tomei em um dos meus projetos antigos foi padronizar as telas. Criei um modelo para as telas de cadastro, consulta e cadastro/consulta (sugestão do artigo). Dessa forma, faço uso de herança para criar novas telas, favorecendo a manutenção e evitando a duplicação de código. Esse é um dos pilares da Programação Orientada a Objetos!

      A respeito do Hint, ainda não testei, mas acredito ser possível percorrer os componentes de uma tela e atribuir Hints automaticamente para cada um deles.

      Obrigado pelo comentário! Abraço!

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Preencha o campo abaixo * Time limit is exhausted. Please reload CAPTCHA.