Un (grand) rêve: introduction
Posté le vendredi 12 juin 2009
Catégorie Ergonomie · billet n° 45 · rss
Je m'amuse ces jours à étudier de près les concepts qui ont mené l'informatique dans la voie actuelle. Depuis les innovations de NLS, ARC, Xerox PARC puis Apple et IBM pour arriver à Windows 3.1, Linux, OS X, la ligne suivie a été une mise en contraste perpétuelle des besoins des utilisateurs et des envies (ou parfois délires) des informaticiens. Dans cette réflexion constante, on a inventé la souris à trois, puis deux, puis un, puis X boutons; on a inventé le double et le triple click; on a inventé le curseur qui occupe des espaces entre les caractères; on a inventé le drag'n drop. Mais ne reste-t-il pas encore beaucoup à faire pour l'utilisateur? Et que penser de l'arborescence des fichiers. C'est à ce propos que je me suis pris, à mon tour, à rêver.
Un de mes amis, un jour, me téléphone: "Ma mère a un gros problème. Elle s'est payé un Mac. Elle ne connaît pas Mac mais le vendeur lui a dit que c'était simple. Pourtant, c'est bizarre, on a cet ordinateur depuis moins d'un mois, et il ne fonctionne déjà plus correctement. Pourrais-tu venir voir et régler ce problème?" Ni une, ni deux, je vais rendre visite à cet ami pour voir son ordinateur asthmatique: un petit iMac à la coque rose trônait fièrement dans leur salon. Je le démarre, et j'attends… Il mit bien 5 minutes à démarrer: le bureau apparaît et, là, le curseur multicolore nous montre que le Mac a de la peine. Dix bonnes minutes plus tard, enfin, le voici opérationnel, avec un petit bémol: sur le bureau sont disposés des centaines de documents. Et vraiment des centaines, superposés les uns aux autres (car "alignés sur la grille"). La mère de mon ami ignorait totalement ce qu'était une arborescence de fichiers. Malgré le cours que je lui donnai alors, mon ami me confessa plus tard que sa mère n'avait jamais réussi, et que c'est donc lui qui classait ses fichiers depuis.
Cette petite anecdote fait surgir deux questions:
- Le système d'arborescence est-il vraiment clair et efficace pour l'utilisateur?
- Comment se fait-il que sa mère puisse retrouver des fichiers classés par son fils, dans une arborescence qu'elle ne comprend pas et qu'elle n'a pas conçue elle-même?
De l'art de la schématisation.
Le système arborescent employé aujourd'hui par l'informatique comme base inéluctable est également employé dans de très nombreux environnements. Pourtant, plus l'environnement est complexe, moins cette schématisation est satisfaisante. C'est là une théorie appliquée par un de mes anciens professeurs de l'Université de Genève, grand linguiste et fin connaisseur des langues rares: le Professeur Alex Leukart, aujourd'hui à la retraite (mais que je salue ici), a en effet participé au déchiffrement du linéaire B; il maîtrise de très nombreuses langues vivantes et mortes (qu'il serait plus que superflu de nommer ici); et, surtout, il a un très grand intérêt pour la physique, la chimie et les mathématiques. Cet estimé professeur, lors de l'un de nos premiers cours d'introduction au hittite, nous dessina au tableau noir une représentation schématique de l'évolution des langues indo-européennes. Il employa "naturellement" un système d'arborescence et commença à nous le commenter comme s'il allait nous donner un cours sur cette évolution.
Il commença donc par la branche germanique des langues indo-européennes. Arrivé au vieux danois, il s'interrompit et nous déclara:
Vous voyez, ici, ça ne marche plus. Ma schématisation n'est pas valable. Je ne peux pas représenter d'une manière crédible la filiation de ce dialecte sur une arborescence classique. Le vieux danois doit provenir des langues dano-suédoises, mais mène au féroïen, qui est une langue issue du germanique occidental commun. Or, elle ne peut pas être associée à deux branches de notre arborescence. Que nous disent les scientifiques à propos de schémas plus efficaces? Et est-il seulement convenable de penser qu'une schématisation sera pleinement correcte et satisfaisante?
Il entreprit donc de dessiner plusieurs types de schémas pour représenter la filiation des langues indo-européennes. A chaque tentative, le constat fut le même: non, cette représentation n'est pas satisfaisante. Les raisons en étaient diverses: mauvaise prise en compte de l'axe temporel, impossibilité de "croiser" des filiations complexes, impossibilité de classer comme il se devait un certain dialecte au sein du schéma, etc. La conclusion de son cours sur la représentation des langues indo-européennes fut déstabilisante mais encourageante: vous ne pourrez pas trouver de schématisation absolument correcte pour représenter des situations aussi complexes, car toutes nos tentatives font abstraction de certaines données: parfois, les migrations géographiques, d'autres fois la ligne temporelle, parfois une filiation complexe. Et là où il fut (encore plus) brillant: "C'est la même chose en physique ou en chimie: plus vous abordez des questions complexes, moins vous trouverez de schéma parfaitement satisfaisant."
Des langues aux données.
Quelles sont les composantes d'une langue qui prennent part à son évolution et devraient pouvoir être représentées sur un schéma? En vrac, et sans approfondir, nous pourront citer: l'espace chronologique qu'elle occupe pour elle-même et par rapport aux autres, son ou ses ancêtres ainsi que ses descendants, sa famille (branche germanique, italo-celtique,etc.), son espace géographique, sa population (et donc son "importance" toute relative). Et, même ainsi, il manque des catégories pour classifier, par exemple, le dialecte parlé dans le Lötschental (vraisemblablement du IXè au XXè siècle). Il faudrait ajouter à toute simple relation "filaire" (comme c'est le cas des schémas arborescents standards) une dimension relevant de la théorie des ensembles. Et encore, nous aurions peut-être quelques soucis.
Je quitte maintenant le domaine des langues, qui m'a permis d'introduire la complexité inhérente à tout système arborescent. Bien qu'il s'agisse à la base d'un système compréhensible, il devient opaque du moment que les éléments qui doivent y prendre place sont complexes, multiples ou changeants. Ainsi, quels sont les éléments constitutifs d'un fichier informatique? Jetons un œil à un petit fichier:
Nous avons, pour tout fichier informatique, de multiples critères de classement: nom, extension, date de création, date de modification, espace physique occupé sur le disque, emplacement, verrouillage, modèle, logiciel pouvant l'ouvrir, permissions, etc. Or, pour les classer une fois pour toutes, que faisons-nous? Nous créons une énième couche dans une arborescence déjà saturée. Il y a parfois quelques soucis pour retrouver ce fichier que nous avons pourtant nous-même classé. Quelle parade trouver à cela? Actuellement, tous les développeurs de systèmes d'exploitation sont en train de travailler sur des moteurs de recherche de plus en plus perfectionnés, sur des sous-classements (ou classements parallèles, comme les "répertoires intelligents" sous Mac OS X), sur des mots-clés: bref, sur des systèmes complémentaires ou parallèles, qui ne prennent pas place dans l'arborescence classique.
Un exemple concret: le répertoire intelligent de Mail d'Apple.
Voici, pour ceux qui ne connaissent pas cette application, un aperçu de ces répertoires suivi d'une courte explication quant à leur fonctionnement.
Les répertoires standards (icône bleue, en bas) sont semblables à tout autre: on prend un e-mail qu'on glisse et dépose à l'intérieur. Le mail n'est alors accessible que par ce répertoire:
Pour les répertoires intelligents, la marche à suivre est radicalement différente. Il s'agit en fait de répertoires répondant à des clés de tri introduites lors de la création du répertoire:
Là où les choses deviennent complexes pour un utilisateur lambda, c'est que les e-mails ne vont pas physiquement être déplacés dans un tel répertoire: il s'agit simplement d'une clé de tri qui va afficher le résultat d'une recherche. Les e-mails restent donc dans leur répertoire d'origine, mais s'affichent lors de la sélection du répertoire en question. Inutile, donc, de glisser-déposer le moindre e-mail dedans, cela ne fonctionnera pas. Pour finir, la seule chose qui distingue un répertoire intelligent (qui n'est donc pas un répertoire…) d'un vrai "en dur, physiquement présent" est son icône: un répertoire simple a une icône bleue, l'intelligent est représenté par un répertoire violet avec une petite roue dentelée (laissant entendre par là que le répertoire effectue une action).
Selon moi, ce système est un pis-aller. Il est certes pensé pour être le plus ergonomique possible (travail sur les icônes, le placement des répertoires, etc.), mais il se fourvoie dans son appellation. Il ne s'agit pas d'un répertoire prenant place dans une arborescence: il s'agit d'un ensemble. Tentons une représentation schématique du classement des e-mails en ne prenant en compte que ces deux facteurs, leur place dans l'arborescence et leur clé de tri:
On voit bien la difficulté de cette représentation. Nous avons deux moyens de trouver un même e-mail: l'un sémantique, l'autre logique. Mais que se passe-t-il si on ajoute d'autres clés de tri, qui toutes permettent de retrouver un répertoire? Ajoutons donc au précédent schéma la dimension temporelle:
La chose commence à devenir fort complexe, et les moyens d'accéder à un mail se multiplient: par l'arborescence classique, par une clé de tri ou par sélection de la date ce réception. Je pense que vous commencez à voir où je veux en venir. Car nous allons encore ajouter une couche: il y a en effet une différence entre date d'envoi et date de réception. Introduisons donc ces deux données dans notre schéma:
Là où la chose devient inconcevable pour l'utilisateur lambda, c'est qu'il a trois moyens majeurs de trouver un e-mail: arborescence, clé de tri ou recherche avec multiples critères (de fait, une telle recherche est équivalente aux clés de tri des répertoires intelligents). De plus, en cas de recherche d'un simple mot, qui n'a pas été dépité de trouver sa propre réponse à un e-mail qu'on a par erreur détruit?
Vers un classement sémantique des fichiers.
La conclusion qui surgit de tout cela est terrible: actuellement, en informatique, nous n'employons que des pis-allers pour classer, archiver et aider l'utilisateur dans son travail. Pourtant, l'informatique devrait être directe, en phase avec l'utilisateur lambda, et devrait se passer de distinctions trop subtiles (comme c'est le cas avec les répertoires intelligents). Il me semble donc que notre approche de l'informatique devrait pouvoir s'affranchir, du côté utilisateur, du système trop restreint de l'arborescence, par l'ajout d'une autre couche naturelle, celle des ensembles.
Je poursuivrai donc cet article par un prochain, qui présentera la théorie naïve des ensembles appliquée à la structure informatique. Cette longue introduction s'arrête donc là: je conserve mes forces pour le prochain article, qui s'avère déjà fort technique. J'espère que l'actuel titille autant vos neurones que les miens!
Trackbacks
Aucun trackback.
Les trackbacks pour ce billet sont fermés.
Ajouter un commentaire