Sensibilité

Parfois il n'y a pas de raison de permettre à l'utilisateur d'interagir avec un contrôle dans un contexte donné, par exemple appuyer sur le bouton Coller lorsque le presse-papier est vide. Dans ces cas-là, rendez le contrôle insensible pour minimiser le risque d'une erreur utilisateur. Lorsque le contrôle est insensible, il apparaît estompé et ne peut pas recevoir le focus, même si certaines technologies d'assistance comme les lecteurs d'écran sont quand même capables de les détecter et de les signaler.

Il est souvent préférable de rendre un contrôle insensible plutôt que de le masquer complètement. De cette façon l'utilisateur peut prendre connaissance de fonctionnalités qu'il utilisera peut-être plus tard même si elle n'est pas encore disponible.

Figure VI.1 Deux cases à cocher : sensible (en haut) et insensible (en bas)

VI.III.I. Contrôles verrouillés

Dans un environnement où le réseau est administré, comme dans un laboratoire d'informatique, les administrateurs système souhaitent habituellement « verrouiller » les valeurs de certains paramètres, voire les supprimer complètement de l'interface utilisateur. Il leur est ainsi plus facile de résoudre tout problème que les utilisateurs pourraient rencontrer. Dans GNOME, la manière correcte de faire cela pour l'administrateur système est de restreindre l'accès en écriture aux clés GConf correspondant à ces réglages.

Lorsque vous concevez une application, prenez en considération les paramètres qu'un administrateur système pourrait vouloir rendre indisponibles aux utilisateurs. Cela comprend habituellement :

  • les paramètres qui, mal configurés, empêcheraient l'application de fonctionner complètement. Par exemple, les paramètres du serveur mandataire pour une application réseau.
  • les paramètres qui pourraient être référencés dans des ressources en réseau. Par exemple, le répertoire des modèles dans une application de bureautique dans lequel les fournitures de bureau partagées, telles que les feuilles d'en-tête de fax, peuvent être enregistrées.
  • les paramètres qui personnalisent l'interface utilisateur, autres que ceux nécessaires pour l'accessibilité. Par exemple, certaines options de personnalisation de menu, clavier ou barre d'outils.

Votre application doit décider, chaque fois que ces contrôles sont affichés, s'ils sont ou ne sont pas disponibles pour modification selon l'état en écriture de la clé GConf qui contient leur valeur. Dans les cas les plus simples, votre code pour chaque contrôle pourrait ressembler à l'exemple ci-dessous.

Exemple VI.1 Exemple de fragment de code montrant comment rendre insensible un contrôle GConf verrouillé
if (!gconf_key_is_writable (http_proxy))
        gtk_widget_set_sensitive (http_proxy_field, FALSE);

Incorporez dans votre guide d'utilisateur, à l'adresse des administrateurs système, un chapitre expliquant quels paramètres peuvent être verrouillés et leurs clés GConf correspondantes.

Expliquez à l'utilisateur pourquoi ces contrôles ne peuvent pas être modifiés en ce moment. Vous pouvez le faire avec du texte statique, des infobulles ou de l'aide en ligne selon les cas. Par exemple :

Figure VI.2 Exemple de boîte de dialogue contenant des contrôles verrouillés

Notez que, bien qu'ils ne puissent pas être modifiés, ces paramètres restent visibles et sélectionnables ; ils peuvent être copiés dans le presse-papier.