2010-11-30 28 views
1

J'ai toujours eu un biais contre l'apparition/la disparition des commandes au moment de l'exécution. Je pense que j'ai lu quelque part mais Google n'est pas disponible et je n'ai pas réussi à trouver quelque chose pour soutenir mon parti pris dans l'une des copies papier que j'ai. Nous avons un débat interne sur la validité de cette approche et je me demande si quelqu'un peut me diriger vers une référence qui traite du sujet.pratique de conception: est-il bon de cacher/afficher les contrôles à l'exécution

Merci!

Bo

+0

Voulez-vous dire cacher plutôt que désactiver? –

+0

Contrôles masquage est souvent assez similaire au comportement existant, comme Tab, ou boîte de dialogue ("Se souvenir de votre mot de passe" dans le navigateur), ou ... Donc, IMO, cela dépend beaucoup de la situation, et je ne donnerais pas de règles strictes À propos de ces. –

+0

Oui, Visible = true/false, contrairement à Enable = true/false. Je suis sur Activer/Désactiver, moins sur Visible/Invisible. –

Répondre

1

Cela dépend probablement de la situation. En général, les contrôles qui apparaissent et disparaissent comme par magie sont probablement mauvais. S'ils sont toujours présents mais désactivés, l'utilisation leur permettra de les activer d'une façon ou d'une autre, et ils le rechercheront dans le manuel. Si les contrôles sont cachés, l'utilisateur ne saura même pas qu'ils sont là pour les rechercher. D'un autre côté, si l'interface utilisateur est déjà assez compliquée et encombrée, et que ces contrôles ne sont utilisés que dans un contexte très spécifique, alors il est probablement bon de faire apparaître si nécessaire, car l'utilisateur a déjà commencé une action qui les exiger.

L'autre option à cacher pourrait être d'avoir les contrôles dans les palettes d'outils flottantes/fenêtres qui apparaissent si nécessaire.

Je ne me souviens pas d'une référence à citer, désolé.

+0

Je pense que si l'interface utilisateur est compliquée que cacher/démasquer les contrôles est une considération, peut-être que l'interface utilisateur devrait être reconsidérée elle-même. Un écran géant plein de contrôles semble être un mauvais flux de travail pour moi. Juste mon avis cependant. – Jay

+0

@Cyrena: En général, je suis d'accord. La plupart des interfaces ne peuvent probablement pas le justifier. Rebirth/Reason pourrait peut-être, et peut-être quelques applications de CAO dans certaines situations ... – FrustratedWithFormsDesigner

+0

@Cyrena: Pas d'écran géant - l'application fonctionne réellement sur un périphérique winmo et est donc nécessairement simpliste - pas trop d'écran à encombrer, et seulement une demi-douzaine de contrôles dans tous les cas. le champ en question est un champ "clock out" pour lequel une valeur est parfois requise, parfois non. Si non requis, je dis désactiver. Le patron dit invisible. Devinez qui gagne? (sauf si je viens avec un argument convaincant! :) –

0

Si l'utilisation d'un contrôle génère une erreur, vous devez probablement au moins désactiver ce contrôle.

La fonction de masquage ou de désactivation dépend du contrôle. Dans un menu déroulant standard, il est probablement logique de désactiver, car alors tous les éléments sont toujours au même endroit.

0

En général, je pense que votre processus de conception devrait dicter cette question. Je crois en gardant l'interface simple et facile à utiliser. Seules les informations essentielles pour la décision suivante doivent être visibles. La désactivation des contrôles peut être justifiée de temps en temps, mais certainement pas quand elle complique ce qui devrait être l'étape d'action/de décision.

En créant des cas d'utilisation précis et en parcourant le processus de décision, vous devriez pouvoir décider de cacher un contrôle ou simplement de le désactiver.