Na sétima parte sobre dicas de desenvolvimento de software, continuo tratando de pequenos “ajustes” no software, mas que fazem diferença para o usuário. Afinal, é ele quem convive diariamente com o produto do nosso trabalho. Lembre-se de que um bom desenvolvimento certamente garante uma boa satisfação.
Submenus infinitos
Imagine que o usuário tenha que acessar 5 submenus para emitir um relatório? Além de complexo, exige que o usuário tenha uma boa memória para guardar a localização de cada menu. Recomenda-se que um menu tenha, no máximo, 2 submenus. Mais do que isso pode tanto atrapalhar o acesso à tela ou funcionalidade quanto confundir as opções em meio a tantos itens. É comum encontrar também submenus desnecessários, como a seleção da impressora para imprimir um relatório. Para prezar pela simplicidade, essa opção pode ser adequadamente incluída na própria tela de visualização do relatório ou no diálogo de impressão.
Uma alternativa é criar uma barra de ferramentas com botões de acesso para as telas mais utilizadas, evitando que o usuário tenha que percorrer vários submenus para abri-las. Essa alternativa torna-se ainda melhor se a barra de ferramentas for personalizável, ou seja, permitir que o próprio usuário escolha os botões que ficarão disponíveis na barra. Estes atalhos são muito úteis para sistemas que integram dois ou mais departamentos de uma empresa, já que em cada departamento as telas acessadas com mais frequência são diferentes.
Alguns softwares mais modernos apresentam menus do tipo Ribbon, parecidos com as versões mais recentes do Microsoft Office. Esse tipo de menu, por possuir abas e botões de opção, podem facilmente substituir os menus tradicionais de um sistema e apresentar uma navegação mais intuitiva.
Formato da data e valores
Essa é clássica! Há muitos softwares em uso que exibem datas no formato americano (mês/dia/ano) e confundem a cabeça do pobre usuário. Há um grande risco quando a data se parece comum, como, por exemplo, a data “03/06/2013” ser exibida como “06/03/2013”. Embora esteja errada, o usuário pode interpretá-la como o dia 06 de março. Se o sistema trabalhar com históricos, movimentações ou agendamentos, essas datas podem trazer sérios problemas!
Isso também vale para formatos de valores monetários. Procure sempre manter o ponto como separador de milhares e a vírgula como separador decimal. Caso o banco de dados exija que o armazenamento seja no formato americano, cabe ao software realizar a conversão necessária para gravar e exibir corretamente os valores.
Mensagens em excesso
Eventualmente é possível encontrar alguns softwares que parecem fazer uma entrevista com o usuário: para qualquer operação existe uma tela de confirmação, até para as operações mais rotineiras. Mensagens são necessárias, mas não em excesso. Algumas operações são óbvias e não precisam de uma mensagem de informação ou confirmação para serem realizadas. É claro que isso não irá afetar o desempenho do software, mas já me deparei com muitos usuários que solicitaram a remoção de algumas mensagens pelo motivo de atrapalhar a usabilidade.
Se a intenção é exibir uma mensagem informativa, considere exibi-la no formulário de forma estática, utilizando um rótulo (label), por exemplo. Mensagens de validação também podem ser substituídas por balões com hints (hint balloons) que, além de não exigir interação do usuário (para pressionar o OK), também são bem modernos.
Só para complementar, já trabalhei com sistemas que não exibem mensagem alguma ao gravar um registro, apenas limpam os campos para a inserção de novos dados. Se for uma tela que permite inserções sucessivas, essa modalidade pode ser bem adequada. Basta orientar o usuário de que, se o sistema “limpar” o conteúdo dos campos ao gravar o registro, significa que foi gravado com sucesso.
Gravação de imagens no banco de dados
Nos fóruns de programação é comum encontrar dúvidas relacionadas à gravação de imagens em tabelas no banco de dados. Porém, antes de implementar essa função no seu sistema, lembre-se de que os dados binários das imagens são extensos e podem sobrecarregar o banco de dados. Para compreender melhor, acompanhe a prática: imagine que você tenha um cadastro de clientes que permita associar uma foto do cliente ao registro. Em um dos cadastros, o usuário carrega uma imagem no formato BMP de 2MB. Imagem grande, não é? Pois bem, ao gravá-la no banco de dados, significa que estes 2MB serão inseridos na tabela. Portanto, se o usuário repetir essa operação para os próximos 100 clientes, o banco de dados armazenará 200MB somente com as imagens! Além do tamanho, isso pode afetar o tempo de retorno dos dados ao consultar o registro, já que o banco de dados irá selecionar todo o conjunto binário referente à imagem e trazer para a aplicação. Considere também que no caso de uma aplicação cliente/servidor, essa consulta pode ainda congestionar o tráfego na rede.
Por esse motivo, alguns desenvolvedores implementam rotinas para controlar o tamanho da imagem a ser carregada, como permitir somente imagens JPG com tamanho menor que 50KB. É uma alternativa viável, mas há o que se argumentar:
- Não deixa de ser uma imagem, então ela terá que ser gravada em um campo de um tipo especial na tabela;
- O desenvolvedor terá que implementar um código específico tanto para a gravação quanto para a leitura da imagem;
- E o mais impactante: o usuário terá que utilizar um aplicativo externo para redimensionar e converter a imagem para que atenda os requisitos da sua aplicação. Para muitos, isso pode se tornar entediante.
Uma das soluções (adotada por muitos desenvolvedores) é copiar a imagem para uma subpasta dentro do diretório da aplicação. Por exemplo, pode-se criar uma pasta chamada “Imagens” e, ao carregar uma foto do cliente na aplicação, o software simplesmente copia o arquivo para dentro dessa pasta ao invés de gravar a imagem no banco de dados. Para ler a imagem é ainda mais simples: basta carregar o arquivo que está na pasta.
Na prática, durante a cópia, o arquivo pode ser renomeado conforme algum dado que identifique o registro, como o ID. Por exemplo, no cadastro do cliente nº 10, o arquivo seria salvo com o nome “00010.jpg” dentro da pasta de imagens, independente do nome de origem. Dessa forma, para realizar a leitura, basta carregar a imagem que tenha o nome igual ao ID do registro selecionado.
Obrigado novamente pela leitura, leitores!
Abraço!
Leia também: Parte 1, Parte 2, Parte 3, Parte 4, Parte 5, Parte 6, Parte 8, Parte 9, Parte 10, Parte 11
Publicado originalmente no blog SubRotina
