Les ancêtres d’Excel et de Powerpoint

Excel

Ce pho­to­gramme est tiré du film La Garçonnière de Billy Wilder. On y voit le héros, comp­table parmi des cen­taines d’autres dans une com­pa­gnie d’assurance. Ben Evans a avancé l’idée qu’on peut com­parer ce bureau à un fichier Excel et chacun de ces employés à une cel­lule effec­tuant un calcul précis. Evans sur­es­time sans doute le degré de tay­lo­ri­sa­tion des employés de bureau, mais il est vrai qu’il est ten­tant de com­parer à un énorme tableau tous les dépar­te­ments d’une orga­ni­sa­tion s’occupant de chiffres et que le déve­lop­pe­ment de l’informatique a lar­ge­ment auto­ma­tisé les cal­culs et permis d’étendre les méthodes de tra­vail et de rai­son­ne­ment, comme l’a très bien perçu Steven Levy dès 1984.

Il existe un cas encore plus par­lant : les cal­culs mathé­ma­tiques com­plexes requis par des domaines tels que l’astronomie, la balis­tique ou la cryp­ta­na­lyse. Chaque calcul était décom­posé en opé­ra­tions simples et suc­ces­sives, effec­tuées par des per­sonnes armées de cal­cu­lettes et autres tables de loga­rithme. En anglais, ces per­sonnes étaient appe­lées des... com­pu­ters, Cf. cet article et ce livre. Bletchley Park était ainsi un centre mili­taire tout entier dédié au but de casser les codes secret uti­lisé par l’Axe, ce qui se reflé­tait dans son orga­ni­sa­tion.

Powerpoint

Powerpoint est autre exemple d’organisation entière se retrou­vant réduite à un simple logi­ciel. Dans les années 1980, la concep­tion d’une pré­sen­ta­tion se fai­sait par ordi­na­teur, mais il fal­lait tou­jours pro­duire les sup­ports, que ce soit sur dia­po­si­tive argen­tique ou sur trans­pa­rent. Powerpoint 2.0 avait ainsi un bouton Envoyer à Genigraphics, qui per­met­tait de trans­mettre un fichier direc­te­ment à une entre­prise spé­cia­lisée dans l’impression de dia­po­si­tives.

Si on remonte jusqu’au début du 20e siècle, on trouve l’entreprise de chimie DuPont, qui pos­sé­dait une salle dédiée. Ses diri­geants pou­vaient assister à des pré­sen­ta­tions étayées par des tableaux et gra­phiques, les­quels étaients affi­chés sur de grands pan­neaux, d’abord montés sur des char­nières puis sur tout un sys­tème de mono­rail. C’est fas­ci­nant, car le dis­po­sitif a inventé ou popu­la­risé à la fois :

  • L’usage des gra­phiques, pas très répandu à l’époque
  • L’idée de la dia­po­si­tive comme docu­ment syn­thé­tique et sup­port d’un dis­cours
  • L’idée d’une pré­sen­ta­tion comme suite de dia­po­si­tives
  • L’idée d’un réper­toire de dia­po­si­tives dans lequel on puisse pio­cher, puisque la salle ser­vait autant de lieu de réunion que d’archive.

Et DuPont a fait ça de la manière la plus lit­té­rale et steam­punk qui soit : avec des rails.

1919 : pre­mière ver­sion
1950 : ver­sion plus évo­luée

Pour aller plus loin

  • Un article très com­plet sur l’histoire du format de la dia­po­si­tive
  • Un livre sur l’histoire du tra­vail intel­lec­tuel au prisme des bureaux et envi­ron­ne­ments de tra­vail.

Un bidule optimisé pour la main mais codé avec les pieds

S’il y a bien un moment où je n’ai pas envie d’utiliser mes faibles capa­cités de calcul mental, mais plutôt un arte­fact cog­nitif adapté (en fran­çais : dégainer une cal­cu­lette), c’est quand il s’agit de payer en tickets res­tau­rant. Étant tou­jours à la recherche d’occasions concrètes d’apprendre à pro­grammer, j’ai donc bri­colé un petit outil qui affiche le nombre de tickets à donner et le reste en liquide.

Le bidule est pensé pour une uti­li­sa­tion sur petit écran et une saisie au pouce. J’ai essayé de rendre le for­mu­laire dyna­mique, pour empê­cher la saisie de lettres ou des mon­tants mal for­matés. C’est un parti pris ergo­no­mique (blo­cage versus mes­sage d’erreur), mais c’est éga­le­ment ins­tructif de voir à quel point le déve­lop­pe­ment de web app peut être CHIANT si on tombe sur la mau­vais com­bi­naison de cas – en l’occurrence, com­biner un contrôle à la saisie et un cla­vier adapté à la saisie numé­rique sur mobile. Par exemple, l’outil bloque la saisie d’une seconde vir­gule après « 1,01 », mais après « 1, » ou « 1,00 ».

Avertissement : on parle d’un truc opti­misé pour la main mais codé avec les pieds. Donc pas de sup­port de Safari <9 ni d’Internet Explorer (et tem­po­rai­re­ment de Firefox sur Android, grrr). et un code d’une qua­lité très rela­tive.

C’est ici.

Screenshot_2016-01-03-00-05-00

Meta Axure : un outil de maquettage créé avec un outil de maquettage

Vous voyez les gens qui recréent un ordi­na­teur dans Minecraft (une intro ici, un résultat en vidéo ici) ?

J’ai fait un truc du même genre, en beau­coup plus modeste : un outil de maquet­tage réa­lisé grâce à un outil de maquet­tage. Pour être hon­nête, il s’agit plutôt d’un outil de zoning très pri­mitif. Il permet de placer des rec­tangles, de les redi­men­sionner, de les effacer, de les renommer et de les mettre à l’avant-plan ou à l’arrière-plan.

Il est tes­table en ligne à cette adresse et le fichier source est ici (il n’est pas du tout docu­menté et néces­site Axure 8).

Meta Axure

Axure : Créer un menu et un fil d’ariane sans dupliquer aucun contenu

Menu

Dans un pro­to­type, on veut sou­vent qu’un menu soit pré­sent dans toutes les vues auquel il permet d’accéder, et qu’un item du menu soit visuel­le­ment dis­tinct des autres pour mon­trer qu’elle cor­res­pond à la vue en cours. (Par vue j’entends une page ou une sec­tion au sein d’une page.)

Solution bour­rine : dupli­quer le menu autant de fois qu’il y a de vues. oui, mais si on danse si quelque chose change ? Par exemple si je dois inter­caler un nouvel item ou changer un lien, il faudra le répéter par­tout. Comme d’habitude, évi­tons de nous répéter.

Meilleure solu­tion : uti­liser un master. Comme ça, toute modi­fi­ca­tion ulté­rieure du menu sera réper­cutée dans chaque vue. Axure offre même une fonc­tion pour insérer à votre place un master dans les pages et à l’emplacement de votre choix (clic droit sur un master dans le pan­neau dédié, puis « Add to pages ». Sauf cas par­ti­cu­lier (par exemple si vous voulez changer la hau­teur du menu), vous n’avez plus à tou­cher à chaque écran. Oui mais, com­ment signi­fier qu’une vue est sélec­tionnée ?

Solution ultime : un mélange de ce qu’Axure appelle les styles d’interaction et de l’évènement onPa­ge­Load.

Premier ingrédient : les styles d’interaction

Les styles d’interactions sont des varia­tions visuelles qui s’activent lorsqu’un widget est dans un état donné. Il y a le clic, le survol, l’inactivité et la sélec­tion.1 C’est cette der­nière qui nous inté­resse. Il faut spé­ci­fier :

  • Le style lui-même. Ici, ça peut être que le libellé passe en gras. Une fois ajouté, il appa­rait dans le pan­neau « Widget pro­per­ties ».
  • L’action qui le déclenche.

Axure tuto 1
Axure tuto 2

Second ingrédient : onPageLoad

Axure permet d’exécuter des actions au char­ge­ment d’une page, dans l’onglet « Page inter­ac­tions » du pan­neau « Page pro­per­ties ». Ici, cela permet d’activer un item du menu dif­fé­rent à chaque page, même s’il est dans un master.

sans titre 5

Un tuto­riel sur Axure.com avec un fichier source pour essayer.

Et au sein d’une page ?

Notez que le truc marche entre pages, mais aussi au sein d’une page. Dans ce cas, le menu n’est plus un master mais une simple suite de wid­gets, et chaque vue est un état d’un pan­neau dyna­mique. Au clic sur l’item 1 du menu, on le passe en « Sélectionné »et on passe le pan­neau à l’état 1.

Un tuto­riel plus com­plet.

Fil d’Ariane

Un fil d’Ariane, c’est encore un objet constant à tra­vers les pages mais dont un aspect change. Pour que la page sélec­tionnée soit en gras, il suffit de suivre les expli­ca­tions plus haut. Mais com­ment faire pour le nom de la page qui change à chaque fois. La solu­tion, c’est d’utiliser un master pour le fil d’ariane et d’ajouter à chaque char­ge­ment de page une action « Set text », avec la valeur [[PageName]]. Cette variable pré­dé­finie par Axure cor­res­pond au titre de la page tel que défini dans votre arbo­res­cence, donc si elle s’appelle « 04-b », le fil d’Ariane com­por­tera « 04-b ».

Axure tuto 4


  1. Attention : Axure, aimant la sim­pli­cité, dis­tingue ces styles de la liste d’évènements, laquelle com­porte des termes très proches (mou­seOver vs onMou­se­Hover vs Selected). Because 

De quelques similitudes entre utilisabilité et sécurité

Créer un sys­tème, c’est s’assurer qu’il rem­plit un ensemble de fonc­tions don­nées, mais aussi qu’il pos­sède des qua­lités glo­bales comme la main­te­na­bi­lité, la fia­bi­lité, la rapi­dité… On les appelle par­fois des exi­gences non-fonctionnelles. Parmi elles, l’utilisabilité et la sécu­rité sont des qua­lités cru­ciales et moins anta­go­nistes que l’on ne pour­rait le croire.

Ne pas raisonner dans l’absolu

On se demande sou­vent « est-ce que cette inter­face est ergo­no­mique ? » Ce n’est pas la bonne ques­tion à se poser car elle n’a pas grand sens dans l’absolu. Il faut plutôt cher­cher à savoir dans quelle mesure elle est uti­li­sable, selon cer­tains cri­tères, pour cer­tains usages et avec cer­taines contraintes.

Le même enjeu existe en sécu­rité : on oscille entre fan­tasmes de pro­tec­tion totale et sen­ti­ment résigné que, de toute façon, Google et la NSA savent tout de nous. Pourtant, non seule­ment la sécu­rité n’est pas une pro­priété binaire, mais grosso modo elle dépend de trois fac­teurs.

  1. Les enjeux : à quel point les don­nées à pro­téger sont cri­tiques ? Cette éva­lua­tion se fait clas­si­que­ment selon trois cri­tères : la dis­po­ni­bi­lité (les per­sonnes auto­ri­sées ont accès aux don­nées), la confi­den­tia­lité (uni­que­ment ces per­sonnes y ont accès) et l’intégrité (les don­nées n’ont pas été modi­fiées dans leurs dos). Selon le contexte, cer­tains cri­tères vont être pri­vi­lé­giés : par exemple je consi­dère que déver­rouiller mon télé­phone faci­le­ment est plus impor­tant que de le rendre indé­chif­frable, donc je ne lui donne pas de mot de passe inter­mi­nable.
  2. Le modèle de menace : qui en a après mes don­nées, quelles res­sources a-t-il et à quel point est-il déter­miné.
  3. La réponse : quelles mesures mettre en place ?

Elaborer une poli­tique de sécu­rité n’est pas for­cé­ment très com­pliqué. Par exemple, selon James Mickens dans cet article très drôle, le modèle de menaces d’un par­ti­cu­lier peut se limiter à « Mossad ou pas Mossad ». Si le Mossad (ou une ins­ti­tu­tion com­pa­rable) en a après vous, vous êtes foutus. Si non, prenez des mesures rai­son­nables et tout ira bien.

Même si elle n’est pas très com­pli­quée, la sécu­rité n’est jamais une pro­priété binaire. Il en va de même en ergo­nomie : on peut favo­riser la poly­va­lence ou la spé­cia­li­sa­tion, une appre­na­bi­lité rapide ou longue, etc.

Ne pas se croire tout puissant

En sécu­rité, un aspect inté­res­sant est que les mesures prises ont pour objec­tifs de rendre accep­table le niveau de risque — et pas plus. Pour chaque risque iden­tifié, on évalue sa vrai­sem­blance et sa gra­vité, avant de prendre une mesure pour dimi­nuer son impact. A la fin, il reste des vul­né­ra­bi­lités rési­duelles, qu’il suffit d’expliciter et de jus­ti­fier : certes, quelqu’un avec un accès phy­sique au sys­tème, une porte dérobée déjà en place et un super­cal­cu­la­teur de poche pour­rait opérer une brèche. Mais c’est un risque accep­table.

Ce n’est pas très dif­fé­rent d’une démarche ergo, dans laquelle on iden­tifie cer­tains déter­mi­nants de l’activité (par exemple, l’utilisateur est forcé d’utiliser sa tablette avec des moufles), aux­quels on répond par des solu­tions (dou­bler la taille des bou­tons) ou des recom­man­da­tions (ne pas uti­liser la tablette dans un contexte néces­si­tant ces moufles).

La dif­fé­rence, dans mon expé­rience, c’est que la démarche ergo est :

  • Moins for­ma­lisée : Les obser­va­tions et solu­tions sont moins décom­po­sées, les points faibles sont affi­chés de manière moins trans­pa­rente. (Mais j’ai peut-être une vision idéa­liste des audits de sécu­rité.)
  • Moins cadrée : au nom d’une uti­li­sa­bi­lité par­faite et absolue, on nous demande sou­vent l’impossible. Une bonne part du boulot d’un expert en ergo­nomie est d’expliquer que l’on n’est pas omni­po­tents.

Faire avec l’utilisateur

Une der­nière simi­li­tude, c’est qu’on ne peut pas conce­voir un sys­tème isolé : il faut anti­ciper son uti­li­sa­tion et sup­poser que l’utilisateur peut être étourdi, bri­co­leur, ou mal­veillant (voire les trois en même temp). Par exemple, il faut anti­ciper ce qui se passe si l’utilisateur oublie son mot de passe ou s’il est laxiste dans une pro­cé­dure de véri­fi­ca­tion quel­conque.

Dans les deux cas, il y a une ten­sion entre les uti­li­sa­teurs réels (pressés et tous dif­fé­rents) et idéaux (conscien­cieux et atten­tifs). Il existe même un concept juri­dique de « per­sonne pru­dente et rai­son­nable », consa­crant le fait que mani­puler des infor­ma­tions sen­sibles entraine cer­taines res­pon­sa­bi­lités et exige un cer­tain com­por­te­ment. Evidemment, c’est plutôt rare d’aller en prison parce que vous n’avez pas uti­lisé un logi­ciel comme un concep­teur l’espérait. Malgré tout, la concep­tion doit faire cer­tains pos­tu­lats et com­promis.

Similaires, voire complémentaires

La sécu­rité nuit sou­vent tel­le­ment à l’utilisabilité qu’elle se tire une balle dans le pied. Les exemples ne manquent pas, des cri­tères absurdes de choix de mot de passe à la com­plexité (PDF) des outils de chif­fre­ment. Les deux approches sont suf­fi­sam­ment simi­laires pour pou­voir être com­plé­men­taires. Il suffit d’en revenir à l’utilisateur. Voici deux articles clas­siques pour creuser le sujet : « Users are not the enemy  » (PDF) et « When secu­rity gets in the way ».

Pocket et la cohérence c’est pas trop ça

Pocket est un ser­vice de lec­ture dif­férée plutôt chouette et dis­po­nible offi­ciel­le­ment sur cinq pla­te­formes. Hélas, les inter­faces de ces dif­fé­rentes pla­te­formes souffrent d’un cer­tain manque d’homogénéité. C’est même car­ré­ment le bordel. J’ai fait un tableau de ces inco­hé­rences.

Dans l'ordre, la barre de navigation des versions Web, Android, Windows et Mac
Dans l’ordre, la barre de navi­ga­tion des ver­sions Web, Android, Windows et Mac

Notez bien que :

  • Je me suis concentré sur l’accès aux fonc­tions concer­nées. Il y a d’autres inco­hé­rences : dans le reste de la pro­cé­dure (ex : ajout d’items sur Mac, modi­fi­ca­tion groupée sur iPad), dans le choix des pic­to­grammes (mode d’affichage sur Windows), dans le concept de base (prin­cipe de double pan­neau avec l’article à droite sur Mac)...
  • Un « non » dans le tableau signifie que la fonc­tion est pure­ment absente.
  • Le site web est res­pon­sive mais je n’ai inclus que la ver­sion « grand format ».
  • J’ai regroupé Paramètres et Aide par com­mo­dité car ils sont tou­jours placés à côté.

Le tableau, je trouve, montre bien l’étendue des diver­gences :

  • une moitié des fonc­tions est indis­po­nible sur au moins une pla­te­forme.
  • Aucune fonc­tion étu­diée n’est par­fai­te­ment homo­gène (c’est-à-dire offrant un accès iden­tique sur toutes les ver­sions).
  • Sur les cinq pla­te­formes, on dénombre quatre accès dif­fé­rents pour trois fonc­tions

Certaines diver­gences sont faci­le­ment expli­cables :

  • Pocket suit par­fois les conven­tions propres à chaque pla­te­forme. Par exemple, sur Android, les para­mètres se trouvent habi­tuel­le­ment dans le menu en haut à droite (celui acces­sible par les trois points) et ce menu n’a pas d’équivalent sur iOS.
  • Certaines fonc­tions ont moins d’intérêt sur cer­taines pla­te­formes, par exemple un affi­chage en grille sur un petit smart­phone.
  • Il y a tou­jours une cer­taine inertie dans le déve­lop­pe­ment multi-plateformes et il n’est pas facile d’avoir une feuille de route uni­fiée dans le moindre détail.

Mais ça n’explique pas l’ampleur du pro­blème. J’y vois sur­tout un manque de volonté des créa­teurs. Par exemple, la ver­sion Windows / Chrome OS uti­lise les même tech­no­lo­gies que la ver­sion web (en gros c’est une web app lancée en local). Les deux devraient donc être rela­ti­ve­ment faciles à faire converger, pour­tant la ver­sion Windows est l’une des plus diver­gentes.

Un fac­teur sup­plé­men­taire d’incohérence est tem­porel : des mises à jour modi­fient fré­quem­ment les inter­faces et ajoutent à la confu­sion. Je ne sau­rais dire si l’homogénéité est ten­dan­ciel­le­ment crois­sante.

Foin de blabla, voici le tableau.

Fonction iPad Android Web Windows Mac # de diver­gences
Nav prin­ci­pale Menu ham­burger Menu ham­burger À gauche Menu dérou­lant cen­tral Non 3 + 1 non
Filtrer par labels Menu ham­burger Menu ham­burger À gauche 1e ligne, droite En bas 4
Filtrer par type d’articles Menu ham­burger Menu ham­burger À gauche Gauche, 1e ligne Première ligne 4
Paramètres et aide Menu ham­burger Menu, droite Menu, droite Menu dérou­lant cen­tral Barre de menus native 4
Premium Menu ham­burger Menu ham­burger Menu, droite Menu dérou­lant cen­tral Non 3 + 1 non
Messagerie Menu ham­burger Menu ham­burger 1e ligne, droite Non Non 2 + 1 non
Modification groupée Menu, droite ou tap long sur item Menu, droite 2e ligne, droite Non Non 2 + 1 non
Ajout d’items Gauche, 1e ligne Non 1e ligne, droite Gauche, 1e ligne Barre de menus native 3
Recherche 1e ligne, droite 1e ligne, droite 1e ligne, droite 1e ligne, droite En bas 2
Mode d’affichage 1e ligne, droite Non 2e ligne, droite Gauche, 1e ligne Non 2 + 2 non