Monthly Archives: mai 2014

Le Principe de robustesse

Dans le domaine des pro­to­coles de com­mu­ni­ca­tion, le Principe de robus­tesse veut qu’un nœud d’un réseau (par exemple un ser­veur sur Internet) soit tolé­rant quand il décide d’accepter ou non un mes­sage plus ou moins bien for­mé, et qu’il soit plus rigou­reux sur la qua­li­té des mes­sages qu’il envoie. Le prin­cipe voit son ori­gine dans les débats autour de l’importance qu’il faut don­ner à une norme de com­mu­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 out­put 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 writ­ten to deal with eve­ry concei­vable error.

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

La rhé­to­rique dis­pose d’un couple de règles très simi­laire : les prin­cipes d’honnêteté intel­lec­tuelle et de cha­ri­té. Le pre­mier revient à dire qu’il faut faci­li­ter le tra­vail de com­pré­hen­sion de l’interlocuteur, le second qu’il faut inter­pré­ter ses pro­pos de la manière la plus avan­ta­geuse pos­sible. (Note : c’est une vision à mini­ma. L’honnêteté intel­lec­tuelle ne se limite pas à un sou­ci de clar­té. De manière plus dras­tique, ces prin­cipes rap­pellent qu’il faut veiller à avoir un lan­gage et des valeurs de dis­cus­sion com­muns.)

Il y a un troi­sième domaine où ce prin­cipe peut s’appliquer : les IHM. La mani­pu­la­tion d’un pro­gramme peut être vue comme un dia­logue : l’utilisateur demande quelque chose et le sys­tème répond qu’il a bien effec­tué (ou non) la tâche, tout ceci via le lan­guage de l’interface. La méta­phore a notam­ment été déve­lop­pée par Hutchins dès 1987 (article en lien ici – PDF pour­rave mais réflexion pas­sion­nante), qui en note aus­si les limites : elle sup­pose qu’il y a une média­tion de type sym­bo­lique entre l’homme et la machine, avec toute la com­plexi­té et l’ambiguïté que cela implique.

Pourtant, cette méta­phore de la conver­sion s’applique encore à bien des cas, par exemple la com­plé­tion d’un for­mu­laire : j’entre une date et le pro­gramme me répond si elle a bien été com­prise. Une bonne inter­face est tolé­rante dans les for­mats pos­sibles qu’elle admet en entrée et rigou­reuse (cohé­rente) à chaque fois qu’elle doit affi­cher une date en sor­tie.

Le prin­cipe de robus­tesse sur Wikipedia

Plaidoyer pour l’URL

Résumé : il faut se battre pour l’URL mais il faut aus­si amé­lio­rer la barre d’adresse et en faire une vraie barre de navi­ga­tion et d’action.

Google expé­ri­mente en ce moment une nou­velle fonc­tion­na­li­té pour Chrome : faire dis­pa­raitre l’URL de la barre d’adresse. Il ne sub­sis­te­rait que le nom de domaine dans un cadre, afin de mieux le mettre en avant et lut­ter contre le phi­shing (source). Cela per­met­trait de mieux dis­tin­guer amazon.com de amazon.siteChelou.com. Pour voir l’URL et l’éditer, il fau­drait cli­quer sur le nom de domaine.

Animation emprun­tée à Usability Post

Beaucoup se sont éle­vés contre cette idée (notam­ment), l’URL étant le concept fon­da­teur du web. Grâce à elle, un docu­ment est acces­sible uni­ver­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­lo­gie est invi­sible pour l’utilisateur. Après tout, on ne lui révèle pas l’adresse IP d’un site ou le hea­der d’une requête HTTP, alors que ce sont des pro­to­coles fon­da­men­taux et por­teurs d’information. De plus, les URL sont sou­vent une suite de carac­tères incom­pré­hen­sibles et inuti­li­sables.

Mon avis : cela reste une mau­vaise idée et une réponse très dis­pro­por­tion­née au pro­blème du phi­shing. Rien n’empêche une URL de suivre une syn­taxe claire, il y a même de bonnes rai­sons tech­niques pour cela. De plus, elle peut com­por­ter des infor­ma­tions direc­te­ment per­ti­nentes pour l’utilisateur. Considérez une URL de ce genre :

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

Elle per­met de situer la page dans l’arborescence du site et de signa­ler com­ment elle est para­mé­trée. C’est un excellent repère de navi­ga­tion, tou­jours pré­sent et tou­jours au même endroit.

On pour­rait aller plus loin et ima­gi­ner que chaque niveau de l’URL soit mani­pu­lable, comme cela se fait dans l’explorateur de fichiers de Windows ou dans cer­tains édi­teurs de code. Par exemple, dans Coda, cli­quer sur un dos­sier du che­min ouvre un menu per­met­tant d’accéder aux autres dos­siers de même niveau. Cliquer sur le fichier ouvert per­met éga­le­ment d’accéder aux dif­fé­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 ima­gi­ner que chan­ger 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’arrive sou­vent dans des bases docu­men­taires).

interactive path for Coda 2

Plus géné­ra­le­ment, je trouve tou­jours dom­mage qu’on essaye de cacher un sys­tème puis­sant, sous pré­texte qu’il est com­plexe et mal uti­li­sé. Il fau­drait plu­tôt domes­ti­quer cette com­plexi­té et la rendre plus acces­sible aux uti­li­sa­teurs. La barre d’adresse d’un navi­ga­teur est aujourd’hui un des rares endroits où l’on est confron­té au concept d’interface en ligne de com­mande. C’est aus­si une inter­face vers énor­mé­ment de choses : his­to­rique, favo­ris, recherche, etc. Organiser et retrou­ver du conte­nu, opé­rer un ser­vice… Il y a là un gros poten­tiel et une bonne occa­sion de faire pro­gres­ser les inter­faces en ligne de com­mande et d’y habi­tuer les gens.

Je pré­cise que mon pro­pos n’est pas une posi­tion de prin­cipe ou un un appel à sau­ver le web. Un pro­to­cole ne devrait avoir aucune impor­tance, sauf s’il peut avoir du sens pour l’utilisateur, comme ici. Je dis bien « peut » : en l’état, la plu­part des gens se fichent des URL et vu la gueule de bien d’entre elles, on les com­prend. Il y a là un pari : c’est seule­ment en explo­rant leur poten­tiel qu’on fera com­pren­dra leur inté­rêt au plus grand nombre.

C’était l’idéal d’un pro­jet de Mozilla, Ubiquity. Le concept de départ, très ambi­tieux, était de s’abstraire des pages et de pro­po­ser une inter­face en lan­guage natu­rel qui per­mette d’exécuter des actions de haut niveau et de les lier entre elles. Concrètement, on pour­rait entrer « réser­ver un vol vers Sidney pour moi et Machin, envoyer l’itinéraire à Machin et ajou­ter la date à mon calen­drier ». La réa­li­té é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.