|
Usuários |
|
138 Usuários Online
|
|
[Artigos]
[Básico] - Dicas para o desenvolvimento de um software – Parte 6 |
Publicado por rboaro : Quinta, Março 28, 2013 - 08:34 GMT-3 (736 leituras)
 comentar  Enviar para um amigo  Versão para impressão
|
Prezar 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 de artigos. As quatro dicas a seguir envolvem características visuais, mas que não deixam de ser importantes na usabilidade do software. Confira também as outras partes dessa série 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.
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 meia hora esperando o hint aparecer, rsrs. 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?
Cortar informações na Grid é desconfortável para o usuário, que normalmente precisa redimensionar as colunas para visualizar o conteúdo inteiro. Mas quando há várias colunas para serem exibidas, qual é a solução?
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 irá 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, é 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 vai pro oftalmologista, rsrs. Para os desenvolvedores que eventualmente rodam a aplicação pode não parecer tão cansativo, mas imagine para os usuários que irão conviver com o sistema praticamente o dia todo?
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 organização da ordem de tabulação dos campos no tópico sobre facilidade de uso. Aqui eu reforço essa dica: a tabulação deve ocorrer de cima pra baixo sem pular nenhum campo, ao menos que este esteja desabilitado ou seja read-only.
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.
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. 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!
|
|
 Comentários | |
| | Comentários pertencem aos seus respectivos autores. Não somos responsáveis pelo seus conteúdos. |
|
|
Edição 112 |
|
|
50 Programas Fontes |
|
|
Produtos |
|
|
