To: Arquitetura da Informação (em Português) <aifia-pt AT lists.ibiblio.org>
Subject: [AI] Res: Telas de cadastro - Disposição dos campos
Date: Sun, 19 Apr 2009 03:56:26 -0700 (PDT)
Flávio,
O que vou falar não tem nenhum estudo de usabilidade envolvido é um sentimento de quem trabalha com sistemas há 15 anos e é uma pesquisadora de usabilidade.
1) Só disponho lado a lado campos relacionados, ex.: RG e CPF, pois ocupam individualmente pouco espaço e tem o mesmo objetivo: documentação;
2) No caso de endereço, costumo fazer uma moldura com os campos dentro (logradouro, numero, complemento, bairro, cep, cidade, estado);
3) Para alguns usuários o que facilita é o <tab> funcionar na ordem de preenchimento dos campos;
4) Quando tenho muitas informações, uso o modelo de abas.
De: Flávio Araújo <flaviowd AT gmail.com> Para: Arquitetura da Informação (em Português) <aifia-pt AT lists.ibiblio.org> Enviadas: Sábado, 18 de Abril de 2009 18:12:36 Assunto: [AI] Telas de cadastro - Disposição dos campos
Pessoal, boa noite.
Não sei se alguém ja pesquisou sobre isso.
Estou desenvolvendo um sisteminha na faculdade para fins didáticos para as disciplinas de Análise de Sistemas e Linguagens de Programação.
Neste momento, estou desenvolvendo as telas do sistema e minha dúvida é com relação a qual modelo é melhor para a disposição dos campos de uma tela de cadastro.
Exemplo:
Nome de usuário:
________________
RG: ________________
CPF: ________________
Ou
Nome de usuário: ____________________________ RG: _____________ CPF: ____________
Eu fico um pouco incomodado com elementos dispostos um ao lado do outro, porém, desta forma, economizamos um espaço considerável com relação ao tamanho da tela.
Outra coisa chata é que quando temos campos para dados de poucos caracteres como por exemplo CEP, e eles misturados com os campos que possuem um dado maior como nome de rua, nome completo, etc esta mistureba de tamanhos também acho incomodo, e deixar todos os campos com tamanho padrão também não acho legal rsrs
Enfim, quando pensamos num problema
encontramos outro.