|
Usuários |
|
74 Usuários Online
|
|
[Artigos]
[Básico] Dicas para o desenvolvimento de um software – Parte 7 |
Publicado por rboaro : Quinta, Agosto 01, 2013 - 10:23 GMT-3 (747 leituras)
 1 Comentário  Enviar para um amigo  Versão para impressão
|
Opa! Estou de volta com a sétima parte sobre dicas de desenvolvimento de software! Nesse artigo, continuo tratando de alguns 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?
Até ele chegar no último submenu já acabou o expediente, rsrs.
Recomenda-se que um menu tenha, no máximo, 2 submenus. Mais do que isso pode atrapalhar o acesso à tela ou funcionalidade, além de 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. No meu ponto de vista, 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. Se essa barra de ferramentas for personalizável é ainda melhor, ou seja, o próprio usuário poderá escolher os botões que ficarão na barra. É muito útil 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.
Assim como comentei na primeira parte dessa série de artigos, 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.
Formato da data e valores
Essa é clássica! Há muitos softwares por aí que exibem datas no formato americano (mês/dia/ano) e confundem a cabeça do pobre cidadão. Quando o usuário encontra a data “12/15/2013″, além de tentar interpretá-la, normalmente ele toma uma atitude: reclama do sistema ou liga para o suporte.
Há um grande risco quando a data se parece comum, como por exemplo, o dia “03/06/2013″ ser exibido 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.
No Delphi, pode-se adicionar as linhas abaixo no arquivo DPROJ (ou DPR, nas versões antigas) para garantir essa padronização em qualquer ambiente Windows em que o software for executado:
Mensagens em excesso
As mensagens acima são irônicas, mas na realidade alguns sistemas 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 sim, mas não em excesso. Há operações que são óbvias, e não precisam ter 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 uma 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ó pra complementar, já trabalhei com sistemas que não mostram nenhuma mensagem 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 prática 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 ele foi gravado com sucesso.
Gravação de imagens no banco de dados
Salvar imagem no banco de dadosNos fóruns de programação é comum encontrar dúvidas relacionadas à gravação de imagens em tabelas no banco de dados. Bom, 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 só por causa das imagens! Além de pesar o banco de dados, 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.
Oras, basta controlar o tamanho da imagem a ser carregada, como por exemplo, somente imagens JPG de tamanho menor que 50KB!
Certo, essa é uma alternativa, mas mesmo assim ainda tenho três argumentos:
1) Não deixa de ser uma imagem, então ela terá que ser gravada em um campo de um tipo especial na tabela, como o BLOB do Firebird;
2) Você terá que implementar um código específico tanto para a gravação quanto para a leitura da imagem;
3) 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 entendiante.
O que você sugere então, infeliz?
Na verdade, eu já me deparei com a necessidade de armazenar imagens no banco de dados e realmente fui infeliz, rsrs. A solução que encontrei (na qual é a solução que muitos desenvolvedores adotam) é 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, você 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!
Mas… e se o arquivo já existir nessa pasta?
Simples! Durante a cópia, você pode renomear o arquivo conforme algum dado que identifique o cliente, como o próprio código. Por exemplo, no cadastro do cliente nº 10, o usuário irá carregar o arquivo “Andre.jpg” na aplicação, mas este arquivo será salvo como “00010.jpg” dentro da pasta de imagens. Bom, então já deu pra perceber que pra fazer a leitura será bem fácil, não é? Basta carregar a imagem que tenha o nome igual ao código do cliente selecionado.
No Delphi, é possível copiar o arquivo da seguinte forma:
E por fim, para carregar:
Pessoal, caso queiram sugerir ideias ou discutir algo, deixe um comentário ou entre em contato.
Obrigado novamente!
Link Original do Artigo:
http://www.subrotina.com.br/dicas-para-o-desenvolvimento-de-um-software-parte-7/
|
|
 Comentários | |
| | Comentários pertencem aos seus respectivos autores. Não somos responsáveis pelo seus conteúdos. |
por: hugosp (hugo-sora@hotmail.com)
: Ago 04, 2013 - 01:01
(Informações sobre o membro | Enviar uma mensagem)
http://
|
|
Mais um excelente artigo da série. Só fiquei meio confuso no final. Não sabia que banco de dados armazenado o próprio arquivo de imagem. Eu sempre usei para armazenar apenas o caminho da imagem.
|
|
|
Edição 112 |
|
|
50 Programas Fontes |
|
|
Produtos |
|
|
