O que é sempre 'padrão'? Se a especificação não dissesse, deve ser assumida?

Question

Existem alguns padrões que você considera tão óbvio que eles seriam assumidos como em alguma especificação?

Por exemplo, acertar o Escape sempre cancelar um formulário? O clique duas vezes em um separador de cabeçalho da coluna deve redimensionar a coluna?

Quando um cliente diz "isso é óbvio e o" comportamento padrão ", portanto, é um bug não tê -lo" - eles às vezes estão corretos? Se sim, existem alguns recursos que podem ajudar a mediar?

Lembro -me de ter um professor nos pedir para escrever todos os detalhes envolvidos em tarefas simples - e quão ridículo isso poderia ficar. Não quero que nossas especificações sejam ridículas, mas estou cansado de ouvir isso e estou pensando que nossas especificações não são específicas o suficiente.

Answer 1

Você pode conferir as diretrizes de experiência do usuário do Windows para o comportamento "esperado" dos componentes da GUI: http://msdn.microsoft.com/en-us/library/aa511258.aspx

Answer 2

É prática padrão especificar os padrões de interface do usuário, não assumem

por exemplo, clicando duas vezes no cabeçalho da coluna em uma grade para redimensioná-lo não um comportamento padrão da GUI do Windows. Clique duas vezes no separador da coluna para redimensionar a coluna, no entanto.

Vale o esforço para especificar os comportamentos padrão da GUI, para que não haja confusão; Se você pode fazer referência a um padrão existente que esteja bem, mas verifique se o cliente assina nele

"Não consigo ler sua mente, e assim não é um comportamento padrão/padrão" é a resposta lógica ... mas não muito educada. ;-)

Answer 3

Para perguntas da interface do usuário, convém consultar uma diretriz de interface do usuário existente, como Apple's ou Microsoft's. Existem alguns mais, mas esses dois são grandes jogadores o suficiente para que suas diretrizes provavelmente refletem o que seus usuários esperam em maior grau do que a maioria dos outros.

Editar: Fechar uma caixa de diálogo com a chave de fuga é coberta na Microsoft diretriz (role para baixo até "interação"):

Pressionar a tecla ESC sempre fecha uma caixa de diálogo ativa. Isso é verdade para caixas de diálogo com cancelamento ou fechamento, e mesmo que o Cancel tenha sido renomeado para fechar porque os resultados não podem mais ser desfeitos.

Eu não parecia muito difícil, mas não vi nada sobre colunas de resistência automática-e é suficientemente incomum que ficaria bastante surpreso se estivesse lá.

Como tal, se eu estivesse no comando disso, diria que é uma decisão dividida (por assim dizer). É razoável que o cliente espere que a chave de fuga descarte uma caixa de diálogo (sem especificá -la explicitamente), e a falha de fazer deve ser considerada um bug.

Reduzir automaticamente a coluna em resposta ao clicar duas vezes na borda do cabeçalho da coluna não é razoável de esperar sem especificá-la; portanto, implementá-la deve ser considerada um recurso adicional.

Ressalvas:

1. Se você está desenvolvendo algo que possui suas próprias diretrizes de interface do usuário (por exemplo, o Mac ou iPhone), essas são as regras a seguir. A participação de mercado da Microsoft torna a sua opção óbvia para um alvo que não possui sua própria diretriz de interface do usuário.
2. Isso é claramente uma questão de relações com o cliente. Você claramente não quer perder seu melhor cliente por causa de algo que pode implementar com bastante facilidade. Se as colunas de resumo automático fazem uma enorme diferença para elas, e elas são um bom cliente de outra forma, pode fazer sentido fazer isso por eles-mas deixe que eles saibam que você está fazendo um favor a eles por causa de quanto você os valoriza . Você só tem que ter cuidado ao equilibrar o quentes "porque você é especial", parte da leve viagem de culpa de ", então estamos fazendo um favor a você e agora você nos deve ..." (IMO, geralmente é Melhor não para dizer a parte "e agora você nos deve" em voz alta, mas não conheço seu cliente).

Answer 4

Minha citação favorita da faculdade "A grande coisa sobre os padrões é que há tantos para escolher".

Suponho que você esteja fazendo essa pergunta, porque infelizmente se envolveu em uma disputa "mas não pediu essa" ". Isso pode colocá -lo em um lugar difícil. Geralmente, você deseja que a empresa forneça o padrão ou, como outros mencionaram, você pode concordar mutuamente com um padrão de terceiros. Se você estiver executando uma empresa que produz muitos do mesmo tipo de aplicativo, você deve gastar tempo uma vez para gerar seu "padrão".

Se você está sentado no ponto de assinatura e alguém está se recusando a pagar por causa dos recursos "padrão", precisa ter alguns exemplos de lugares onde isso não é padrão. No seu exemplo, por exemplo, feche a forma na tecla Escape é padrão apenas no Windows (não na Web) e, em seguida, apenas para a Microsoft. Acabei de abrir três aplicações no meu computador, onde o ESC não fez nada em um formulário.

Quase nada é padrão. Em qualquer pessoa, a mente "padrão" significará algo um pouco diferente e, se não for especificado para alguma definição mensurável, resultará em argumentos no caminho.

Answer 5

Crie uma especificação da placa de caldeira que você inclua/referência em todos os seus projetos do mesmo design geral. Essa especificação deve crescer e mudar à medida que você aprender mais sobre seus clientes/demandas de clientes. Esta especificação também deve fazer referência às diretrizes apropriadas da UI fornecidas por Maçã ou Microsoft. Mesmo se você estiver em uma plataforma, recomendo ler as outras especificações para obter informações sobre melhores maneiras de fazer as coisas ou identificar possíveis soluços. Também existem vários bons livros sobre o design da interface do usuário do qual você pode pedir emprestado.

Answer 6

Nada é padrão, a menos que esteja escrito e especificado em algum lugar relacionado ao seu projeto (ou vinculado à especificação). Se não estiver escrito, não é padrão, então o cliente deve defini -lo.

Em outra nota:
Se a sua biblioteca da interface do usuário fizer isso de uma maneira e exigiria a codificação para fazer de outra maneira (exemplo estúpido: você deseja que os usuários cliquem em botões com o MouseButton certo), então você deve parar e repensar o que os usuários podem esperar.