Monthly Archives: mai 2014

Le Principe de robustesse

16 mai 2014|0 commentaires|Thèmes : ,

Dans le domaine des proto­coles de commu­ni­ca­tion, le Principe de robus­tesse veut qu’un nœud d’un réseau (par exemple un serveur sur Internet) soit tolé­rant quand il décide d’ac­cepter ou non un message plus ou moins bien formé, et qu’il soit plus rigou­reux sur la qualité des messages qu’il envoie. Le prin­cipe voit son origine dans les débats autour de l’im­por­tance qu’il faut donner à une norme de commu­ni­ca­tion : la stra­tégie opti­male pour la robus­tesse du réseau, ce serait de suivre la norme de près en output mais beau­coup moins en input.

Par la suite (RFC 1122, § 1.2.2), il été a inter­prété de manière plus large comme un prin­cipe de prévoyance :

Software should be written to deal with every concei­vable error.

C’est-à-dire : rendez votre programme robuste en le conce­vant de telle sorte à qu’il fonc­tionne avec les plus inputs les plus variés.

La rhéto­rique dispose d’un couple de règles très simi­laire : les prin­cipes d’hon­nê­teté intel­lec­tuelle et de charité. Le premier revient à dire qu’il faut faci­liter le travail de compré­hen­sion de l’in­ter­lo­cu­teur, le second qu’il faut inter­préter ses propos de la manière la plus avan­ta­geuse possible. (Note : c’est une vision à minima. L’honnêteté intel­lec­tuelle ne se limite pas à un souci de clarté. De manière plus dras­tique, ces prin­cipes rappellent qu’il faut veiller à avoir un langage et des valeurs de discus­sion communs.)

Il y a un troi­sième domaine où ce prin­cipe peut s’ap­pli­quer : les IHM. La mani­pu­la­tion d’un programme peut être vue comme un dialogue : l’uti­li­sa­teur demande quelque chose et le système répond qu’il a bien effectué (ou non) la tâche, tout ceci via le language de l’in­ter­face. La méta­phore a notam­ment été déve­loppée par Hutchins dès 1987 (article en lien ici – PDF pour­rave mais réflexion passion­nante), qui en note aussi les limites : elle suppose qu’il y a une média­tion de type symbo­lique entre l’homme et la machine, avec toute la complexité et l’ambiguïté que cela implique.

Pourtant, cette méta­phore de la conver­sion s’ap­plique encore à bien des cas, par exemple la complé­tion d’un formu­laire : j’entre une date et le programme me répond si elle a bien été comprise. Une bonne inter­face est tolé­rante dans les formats possibles qu’elle admet en entrée et rigou­reuse (cohé­rente) à chaque fois qu’elle doit affi­cher une date en sortie.

Le prin­cipe de robus­tesse sur Wikipedia

Plaidoyer pour l’URL

4 mai 2014|0 commentaires|Thèmes :

Résumé : il faut se battre pour l’URL mais il faut aussi améliorer la barre d’adresse et en faire une vraie barre de navi­ga­tion et d’ac­tion.

Google expé­ri­mente en ce moment une nouvelle fonc­tion­na­lité pour Chrome : faire dispa­raitre l’URL de la barre d’adresse. Il ne subsis­te­rait que le nom de domaine dans un cadre, afin de mieux le mettre en avant et lutter contre le phishing (source). Cela permet­trait de mieux distin­guer amazon.com de amazon.siteChelou.com. Pour voir l’URL et l’éditer, il faudrait cliquer sur le nom de domaine.

Animation empruntée à Usability Post

Beaucoup se sont élevés contre cette idée (notam­ment), l’URL étant le concept fonda­teur du web. Grâce à elle, un docu­ment est acces­sible univer­sel­le­ment et sans ambi­guïté. À cela, on peut répondre que bien des appa­reils fonc­tionnent parce que leur tech­no­logie est invi­sible pour l’uti­li­sa­teur. Après tout, on ne lui révèle pas l’adresse IP d’un site ou le header d’une requête HTTP, alors que ce sont des proto­coles fonda­men­taux et porteurs d’in­for­ma­tion. De plus, les URL sont souvent une suite de carac­tères incom­pré­hen­sibles et inuti­li­sables.

Mon avis : cela reste une mauvaise idée et une réponse très dispro­por­tionnée au problème du phishing. Rien n’empêche une URL de suivre une syntaxe claire, il y a même de bonnes raisons tech­niques pour cela. De plus, elle peut comporter des infor­ma­tions direc­te­ment perti­nentes pour l’uti­li­sa­teur. Considérez une URL de ce genre :

boutique.com/fr/vêtements/homme/pantalons?items-par-page=30?classement=prix

Elle permet de situer la page dans l’ar­bo­res­cence du site et de signaler comment elle est para­mé­trée. C’est un excellent repère de navi­ga­tion, toujours présent et toujours au même endroit.

On pour­rait aller plus loin et imaginer que chaque niveau de l’URL soit mani­pu­lable, comme cela se fait dans l’ex­plo­ra­teur de fichiers de Windows ou dans certains éditeurs de code. Par exemple, dans Coda, cliquer sur un dossier du chemin ouvre un menu permet­tant d’ac­céder aux autres dossiers de même niveau. Cliquer sur le fichier ouvert permet égale­ment d’ac­céder aux diffé­rentes fonc­tions que celui-ci inclut, ce qui faci­lite la navi­ga­tion dans le corps du docu­ment. Dans une page web, par exemple, on pour­rait imaginer que changer de langue se fasse depuis l’URL, par un menu dédié, au lieu de cher­cher déses­pé­ré­ment le lien dans la page (cela m’ar­rive souvent dans des bases docu­men­taires).

interactive path for Coda 2

Plus géné­ra­le­ment, je trouve toujours dommage qu’on essaye de cacher un système puis­sant, sous prétexte qu’il est complexe et mal utilisé. Il faudrait plutôt domes­ti­quer cette complexité et la rendre plus acces­sible aux utili­sa­teurs. La barre d’adresse d’un navi­ga­teur est aujourd’hui un des rares endroits où l’on est confronté au concept d’in­ter­face en ligne de commande. C’est aussi une inter­face vers énor­mé­ment de choses : histo­rique, favoris, recherche, etc. Organiser et retrouver du contenu, opérer un service… Il y a là un gros poten­tiel et une bonne occa­sion de faire progresser les inter­faces en ligne de commande et d’y habi­tuer les gens.

Je précise que mon propos n’est pas une posi­tion de prin­cipe ou un un appel à sauver le web. Un proto­cole ne devrait avoir aucune impor­tance, sauf s’il peut avoir du sens pour l’uti­li­sa­teur, comme ici. Je dis bien « peut » : en l’état, la plupart des gens se fichent des URL et vu la gueule de bien d’entre elles, on les comprend. Il y a là un pari : c’est seule­ment en explo­rant leur poten­tiel qu’on fera comprendra leur intérêt au plus grand nombre.

C’était l’idéal d’un projet de Mozilla, Ubiquity. Le concept de départ, très ambi­tieux, était de s’abs­traire des pages et de proposer une inter­face en language naturel qui permette d’exé­cuter des actions de haut niveau et de les lier entre elles. Concrètement, on pour­rait entrer « réserver un vol vers Sidney pour moi et Machin, envoyer l’iti­né­raire à Machin et ajouter la date à mon calen­drier ». La réalité était plus modeste mais tout de même bien cool. Pour en savoir plus, voir ici et ici.

Bref, il y a tant de choses à faire autour de la barre d’adresse.