Aux sources d'Ubiquity

Ubiquity est un de mes projets favoris des laboratoires Mozilla. Il marque une étape du retour de la ligne de commande, qui a toujours été mon interface de communication préférée avec mes compagnons digitaux. Ubiquity est entre autres l'œuvre de Aza Raskin, spécialiste en interfaces homme-machine et responsable de ces questions aux laboratoires. Il a cofondé Humanized, une société qui a produit des logiciels à l'interface innovante comme le moteur de recherche de musique Songza ou Enso, un lanceur (hélas uniquement pour windows) dont la parenté avec Ubiquity est évidente. En fait, avec Humanized Aza poursuivait les recherche de son père, Jef Raskin, un des créateurs du Mac et de son interface[1].

Après son départ d'Apple, Jef Raskin a continué ses recherches et créé un nouvel ordinateur, pour Canon, le Canon Cat. Le Cat comportait une interface d'un nouveau genre, et était essentiellement destiné au traitement de texte. Canon a malheureusement rapidement abandonné le projet. Jef a publié en 2000 un livre, The Humane Interface, fruit de son expérience des IHM et considéré comme une référence en la matière. Il l'a ensuite décliné en un projet, The Humane Environment (THE), reprenant les concepts d'interface du Cat. THE a été renommé en 2005 Archy. Jef est malheureusement décédé en février 2005, et la dernière version de développement d'Archy est sortie en décembre. Le projet semble à présent abandonné, mais Enso et aujourd'hui Ubiquity en sont le prolongement direct.

L'interface humaine

Ajout du 9 février 2009 : je tombe avec un peu de retard sur un bien meilleur résumé du livre de Jef Raskin sur Gobz, un blog des étudiants de l'école des Gobelins. Allez le lire, il vous en apprendra plus que mon article.

En m'intéressant aux travaux de Jef Raskin, j'ai retrouvé quelques uns des concepts derrière Ubiquity, mais aussi bien d'autres choses passionantes. Raskin insiste sur la nécessité de bâtir des interfaces basées sur le fonctionnement humain et non sur des contraintes techniques. Par exemple abandonner les fichiers et les arborescences de répertoires pour ne plus manipuler que des documents, une notion plus familière aux humains. Il se base pour cela entre autres sur des recherches en sciences cognitives et ergonomie, et insiste sur la nécessité de tester en permanence les nouvelles idées en conditions réelles, pour voir si elles répondent aux besoin des utilisateurs.

Voici quelques uns des concepts qu'il a développés dans The humane Interface et essayé de mettre en œuvre dans Archy (simple compilation de mes rapides recherches sur le net, n'hésitez pas à creuser et me corriger) :

  • modelessness : la réponse à une action donnée de l'utilisateur doit toujours être la même, sans tenir compte de l'état du système (donc par exemple éviter d'avoir plusieurs "modes", un pour se déplacer dans le document, un autre pour l'éditer, etc) Cela permet d'effectuer des actions sans avoir à réfléchir pour connaître l'état de l'application, donc en étant le moins distrait possible;
  • monotonie : il ne doit y avoir qu'un moyen d'effectuer une action (ce qui exclut par exemple de pouvoir exécuter la même action via une entrée de menu ou une icône ou un raccourcis clavier). Encore une fois, s'il n'a pas à choisir la méthode pour effectuer une opération le cerveau est moins distrait;
  • persistance : tous les documents sont persistants, il n'y a pas besoin de les enregistrer, chaque modification est automatiquement sauvegardée. Un des avantages est que même en cas de plantage, on ne perd jamais son travail;
  • annulabilité : toute action doit pouvoir être annulée, sans limite. Accessoirement, cela entraîne que les demandes de confirmation lors d'actions "dangereuses" sont inutiles (de toute façon personne ne les lit), puisqu'on peut toujours revenir en arrière;
  • il faut inverser la perspective actuelle pour mettre les documents au centre du processus: ne plus avoir des applications dans lesquelles on ouvre des documents, mais des documents sur lesquels on travaille au moyen de divers outils. On supprime également les notions de fichiers, de dossiers, etc, ne reste que des documents que l'on n'est pas obligé de nommer. Un puissant mécanisme de recherche textuelle permet de retrouver facilement ces documents;
  • les outils se présentent sous la forme de commandes saisies dans un langage le plus naturel possible depuis une ligne de commande accessible de partout. Une touche déclenche l'apparition de la ligne de commande, et la saisie est assistée (exactement ce que propose Ubiquity). Toutes les applications sont remplacées par des commandes que l'on installe en fonction des besoins. L'API des commandes est publique, afin de leur permettre d'interagir, de créer des "macros" composées d'un enchaînement de commandes, etc;
  • Raskin conseille une interface de navigation entre documents basée sur un mécanisme de zoom : tous les documents sont disposés sur un plan, et on augmente ou diminue le zoom pour naviguer ou consulter un document spécifique;

Certains de ces principes me heurtent un peu. J'aime bien par exemple avoir le choix de la manière dont j'effectue une action, disposer de raccourcis pour une utilisation avancée, etc. Mais globalement je trouve la plupart de ces idées plutôt intéressantes.

Archy

On peut essayer l'implémentation de certaines de ces notions dans Archy en téléchargeant la dernière alpha disponible. C'est du Python et ça s'exécute sans problème sur Sid[2], seul soucis, mon clavier français est mal reconnu, mais il suffirait sans doute de tripoter quelques fichiers. Cette version, inspirée du Canon Cat, se focalise essentiellement sur l'édition de texte. Elle permet de saisir du texte, s'y déplacer et de lui appliquer quelques commandes. A terme, le but d'Archy était de remplacer à la fois le système d'exploitation et les applications. D'être une application unique manipulant des documents et leur contenu au moyen de commandes. Tout le reste, environnement de bureau, fenêtres, fichiers et répertoires, programmes, etc, devait être amené à disparaître.

Application immédiate du principe de modeless, la touche "verrouillage majuscule" n'a plus d'utilité, elle est donc réaffectée et sert à faire apparaître l'invite de commande.

Archy implémente de nouveaux mécanismes de gestion du curseur, le leaping, qui permettent d'éviter d'avoir à utiliser la souris. Tout peut donc se faire en gardant les mains sur le clavier, ce qui apporte un gain de temps appréciable. Le leaping est en fait un mécanisme de recherche incrémentale, associé à deux touches, l'une permettant de rechercher en amont et l'autre en aval. Des caractères spéciaux permettent de se déplacer par paragraphe, page, etc.

Les commandes ressemblent à celles d'Ubiquity. Par exemple, on peut sélectionner un texte, ouvrir l'invite de commande en pressant Caps Lock et taper NEW EMAIL (pas besoin de taper en entier, l'auto-completion fonctionne) pour voir s'ouvrir une nouvelle zone de commande permettant de saisir les destinataires du message. Pas besoin de lancer une application spécifique, c'est la commande qui se charge de tout.

Vous pouvez voir quelques copies d'écran d'Archy ici.

Alors ?

Pour un projet de laboratoire, Ubiquity m'avait surpris par la maturité de son interface. Je comprend mieux à présent, et me réjouis que Firefox marche dans les pas d'un des hommes qui ont contribué à révolutionner les communications entre humains et ordinateurs, et à rendre les ordinateurs plus accessibles. Si Ubiquity est très prometteur, les écrits de Jef Raskin contiennent bien d'autres pistes, et j'ai hâte de voir les prochaines qu'Aza et ses camarades exploreront. La communauté autour de certains projets des Mozilla Labs, dont Ubiquity, semble solide et enthousiaste, il y a bon espoir de voir rapidement arriver des trucs qui pourraient profondément changer notre façon de dialoguer avec le navigateur (qui est, d'après certains, le système d'exploitation de demain...) Il me tarde d'être à demain :)

Notes

[1] je viens de tomber grâce à Tristan sur cet excellent billet du Capitaine racontant en détail la naissance du Mac. Jobs en prend sérieusement pour son grade.

[2] j'ai juste dû installer le paquet python-pygame et créer un fichier build.dat contenant 0,0