De la nocivité des interfaces graphiques Je suis de plus en plus inquiet du nombre de nouvelles applications qui sont conçues pour fonctionner uniquement avec une interface graphique. Cela peut paraître censé pour les gens venant des mondes Windows ou Mac, mais une des forces d'Unix a toujours été la possibilité de l'utiliser depuis n'importe où. Ces gens ne semblent pas le comprendre. En fin de compte, quelle est l'utilité de ce nouveau joli tableur, éditeur ou débogeur si je ne peux pas me connecter de l'extérieur et l'utiliser sur mon VT100 ? Trop souvent un outil "avec des fenêtres" n'est rien de plus qu'un truc marketing pour cacher aux utilisateurs facilement impressionnables que l'outil ne propose pas les fonctionnalités dont ils ont besoin. Les programmes conçus avec une interface graphique sont rarement utilisables comme composants d'outils plus importants. En conséquence il ne sont pas adaptés à la philosophie outil-filtre d'Unix. Au lieu que chaque programme soit simple et tente de faire bien une seule chose, ils nous ramènent en arrière aux Anciens Mauvais Jours où chaque programme était un monstre monolithique indépendant qui ne pouvait s'interfacer correctement avec aucun autre. C'est une bonne chose de placer une couche graphique au dessus d'un outil existant, mais concevoir une nouvelle application en prévoyant uniquement une interface graphique est limiter à jamais la flexibilité de l'outil. Par exemple, comment pouvez-vous écrire un script shell qui lance une session xrn automatique ? Il n'existe aucun moyen connu de fournir la programmabilité pour les logiciels graphiques. La meilleure chose à faire dans un environnement Unix est de concevoir le coeur de l'outil comme un "back end" qui peut être commandé manuellement ou automatiquement. La couche graphique devrait être un module séparé. Si elle est remplaçable facilement l'application n'est pas irrémédiablement liée à une technologie graphique spécifique comme SunView, NeWS, ou même X11 ou ses dérivés, comme Open Look ou Motif. Envoyer des commandes standards dans un tube comme le font les paquetages STDWIN ou wafe est aussi une approche raisonnable. Cela signifie que votre outil devrait être utilisable aussi bien avec que sans l'interface graphique, et pouvoir être commandé aussi bien depuis la souris que depuis un programme. Cela signifie de préférence à la fois une interface de niveau shell pour la commodité et une interface de niveau C pour l'efficacité ; les programmeurs Perl pourraient utiliser l'une ou l'autre des deux méthodes. De cette façon, les utilisateurs inexpérimentés peuvent utiliser une interface graphique "presse bouton", les utilisateurs aveugles peuvent utiliser un terminal Braille, et les utilisateurs expérimentés peuvent programmer des solutions à des problèmes complexes. Il a été dit que les interfaces graphiques rendent simples les choses simples, et impossibles les choses complexes. Il est certainement utile de rendre simple les choses simples. Mais trop souvent un logiciel n'est adapté qu'à un niveau d'expertise. Celui qui est adapté au novice est trop souvent hostile à l'expert et vice versa. L'obligation de cliquer dans un menu ralentira l'utilisateur expert qui est plus à l'aise avec une interface clavier. Devoir quitter inutilement le clavier ne fait que ralentir l'utilisateur expérimenté. Un périphérique de pointage précis qui ne nécessiterait pas d'enlever les mains du clavier pourrait être une bonne chose. Il y a des cas où l'absence d'interface graphique n'a pas de sens, comme un système de CAO. La souris est probablement raisonnablement adaptée pour délimiter une région ou dessiner une figure, mais pas pour faire une sélection dans un ensemble de possibilités, en tout cas pas quand l'outil vous est devenu familier. Tom Christiansen 10 août 1992 - tchrist@convex.com traduit par Christophe Deleuze en décembre 1999. Christophe.Deleuze@lip6.fr