Discussion :

[Nebulix]

Bonjour
Les bonnes pratiques pour la conception d'un programme ont fait l'objet de nombreux et fructueux débats ici. Et tout le monde a souligné l'importance de nombreux tests de validation. Quant il s'agit de concevoir une Interface Homme-Machine, les tests viennent forcément beaucoup plus tard, avec le retour d'expérience des vrais utilisateurs (s'ils viennent, ce dont - en tant qu'utilisateur- je doute).
Il serait donc utile de disposer de "bonnes pratiques" a priori.
Qu'avez-vous dans vos boîtes à outils ?

[souviron34]

Bon

je m'excuse du retard mis à répondre et participer, mais d'autres affaires m'occupent en ce moment...

Je vais tenter de poser les bases d'une discussion plus élaborée...

Déjà quand je lis :

Quant il s'agit de concevoir une Interface Homme-Machine, les tests viennent forcément beaucoup plus tard,

je bondis

C'est là où , appelez-les comme vous voulez, les méthologies échouent....

Comme je l'ai déjà souligné ailleurs, une approche USER-CENTERED permet de valider réellement les IHM AVANT la moindre ligne de code....

C'est le logiciel qui va copier les mockups et non-pas les utilisateurs qui vont devoir s'adapter....


Si en plus, ce qui est dans la logique, on associe une méthodologie de développement agile à une approche user-centered, les tests ne viennent pas beaucoup plus tard, mais tout au long du développement...



Enfin, comme je l'ai déjà souligné ailleurs également, une IHM est la partie visible d'un logiciel. En tant qe telle, elle a le même besoin d'esthétisme que n'importe lequel des objets courants (voiture, jeu vidéo, mobilier...) pour le consommateur-utilisateur. D'où à mon avis le plus d'un graphiste (un vrai, pas un mec sachant se servir de PhotoShop ou d'illustrator), pour avoir un "beau produit"..



Je résumerais donc, de mon point de vue, les bonnes pratiques en 3 étapes :

• L'analyse / conception : utilisant une approche centrée sur l'utilisateur, avec interviews, enregistrements (audio, voire vidéo) d'utilisateurs, fabrication de mockups, et validation in-fine par un groupe d'utilisateurs des mockups.
  
  
• Le développement : basé sur une tête de projet bicéphale (un "informaticien" plutôt généraliste, un utilisateur expert, reconnu dans sa communauté), une approche de développement Agile, permettant les tests et modifications en cours de développement.
  
  
• La commercialisation : faire intervenir un graphiste, afin de trouver les meilleurs équilibres esthétiques (couleurs, formes, icônes.) pour faire du logiciel un "produit commercial". (y compris avant démos ou congrès ou salons, même si c'est quelques mois avant la commercialisation et que ce n'est pas terminé).
  
  (un graphiste a par métier des "règles" qui ne sont pas des règles à l'informaticienne : j'ai eu le cas d'un logiciel où le graphiste m'a dit "cette liste serait mieux avec le fond blanc et l'écriture bleue, et celle-ci avec le fond gris et l'écriture noire".. Ce qu'on a fait, et tous les utilisateurs adoraient... Mais il a été difficile de faire passer la notion que toutes les listes ne seraient pas visuellement pareilles à la Direction Technique *)
  
  * la fameuse normatite, une maladie technocratique et managèriale qui les laisse sans défense si ils n'ont pas un document intitulé Norme auquel se raccrocher... si possible sous forme Norme Internationale.. Existe aussi en forme Norme Nationale, et éventuellement sous forme individuelle de Norme d'Entreprise...)

Cele serait pour moi les bonnes pratiques en matières d'IHM, et de TOUT logiciel en général.

Car en effet, à part un script, TOUT logiciel dispose d'une IHM, qui est le SEUL moyen par lequel l'utilisateur interagit avec ce logiciel...



Des références diverses sont disponibles un peu partout à propos de l'approche centrée utilisateurs, dont les cours de Christian Bastien..


Enfin, en conclusion, je dirais que ce qui pêche souvent , que ce soit du côté des développeurs ou des Directions, c'est l'oubli de la vision qu'un logiciel est un PRODUIT COMMERCIAL....

Et que, de la même manière que le consommateur moyen serait rebuté par une voiture ayant toutes les qualités d'une voiture, mais dont la peinture n'est pas faite, les enjoliveurs n'existent pas, il y a juste la mousse sur les sièges et pas de revêtement, etc etc, l'utilisateur aura une attitude entièrement différente si le produit est joli, en plus de faire la tâche qu'on lui demande...

[el_slapper]

globalement d'accord avec maître Souviron. J'aimerais quand même ajouter quelques précisions :

1)Nombre de logiciels professionels sont à usage purement interne; par exemple, le logiciel qu'utilise un guichetier(de banque, d'assurance, de magasin...). Il est fréquent de faire appel à des ergonomes dans ce cas-là, mais ce que j'en ai vu n'était pas brillant. Ce ne sont pas des logiciels commerciaux, mais fauire comme si éviterait bien des déboires.

2)dans le même cadre, on peut trouver des "scripts" hyper-poussés; ça s'apelle des batchs. Dans une grande Banque, il y en a des milliers, et ça n'a rien d'anodin.

[souviron34]

globalement d'accord avec maître Souviron.

N'éxagérons pas quand même

1)Nombre de logiciels professionels sont à usage purement interne; par exemple, le logiciel qu'utilise un guichetier(de banque, d'assurance, de magasin...). Il est fréquent de faire appel à des ergonomes dans ce cas-là, mais ce que j'en ai vu n'était pas brillant. Ce ne sont pas des logiciels commerciaux, mais fauire comme si éviterait bien des déboires.

C'est bien ce que j'ai voulu dire ... Tout logiciel, fut-il en interne est un produit "commercial"..

Si il est utilisé par 2 personnes, c'est moins sensible..

Mais dans une grande banque ou assurance, quand il est utilisé par 2000 ou 20000 personnes, c'EST un logiciel commercial.. Le rendement global de l'entreprise en dépend...

2)dans le même cadre, on peut trouver des "scripts" hyper-poussés; ça s'apelle des batchs. Dans une grande Banque, il y en a des milliers, et ça n'a rien d'anodin.

je suis d'accord, mais le débat porte sur les IHM

Et, à moins que tu ne me prouves le contraire, mais batchs ou scripts sont faits pour tourner automatiquement...

Leur intérêt dans un débat sur les IHM st donc plus que limité, à mon humble avis

[el_slapper]

On est globalement d'accord, je pinaille juste, parceque ton premier message laissait entendre que les scripts/batchs/programmes sans interface étaient secondaire. Et que ça a souvent été mon gagne-pain, alors je suis un peu susceptible là-dessus.

En relisant ton message, je m'aperçois aussi que le passage sur la normatite est très important, sur le sujet, et hors-sujet. Je resterait sur le sujet en citant un exemple vécu dans une grande banque. J'homologue une nouvelle application en cours de développement. Les boutons de validation de l'écran sont en bas, au centre. Ca me convient : au vu de ce que je fais, le pointeur de la souris traine souvent dans le coin. Se pointe l'ergonome, qui dit d'un ton docte "Vos boutons doivent être en bas à droite, collés les uns aux autres". "Pourquoi?", demande le développeur surpris. "C'est la norme".

Et le chemin du pointeur est devenu bien plus long.

Là, maintenant, je tape un message sur DVP. J'utilise la souris dans la zone de teste pour corriger d'éventuelles fautes de frappe. Les boutons "envoi" et "prévisualisation" sont juste en dessous. C'est parfait. Pas aux normes? On s'en fout.

[clenoir]

Là, maintenant, je tape un message sur DVP. J'utilise la souris dans la zone de teste pour corriger d'éventuelles fautes de frappe. Les boutons "envoi" et "prévisualisation" sont juste en dessous. C'est parfait. Pas aux normes? On s'en fout.

Je pense que l'important c'est de conserver une cohérence dans l'ensemble de l'application (en suivant des guidelines par exemple), et de prendre en compte le sens de lecture naturel pour l'utilisateur (généralement du style gauche > droite, haut > bas). Après, chercher à minimiser le chemin parcouru à la souris je trouve que ça va plutôt dans le bon sens si ça ne crée pas de confusion.
Car effectivement le système qu'a voulu conseiller ton ergonome est très répandu, mais tout comme toi, lorsque je vois 2 boutons en-dessous de ce que j'écris ("Envoyer la réponse" et "Prévisualisation du message" en l'occurrence) je ne suis absolument pas choqué qu'ils soient centrés vu qu'il n'y a pas d'ambiguïté sur ce à quoi ils servent .

[Nebulix]

Je suis tout à fait d'accord avec Souviron, mais ce n'est pas le sujet que j'avais en tête. Je vais préciser, mais d'abord quelques remarques :
- En tant qu'utilisateur, je rêve souvent qu'il existe un enfer pour les programmeurs où ceux-ci devraient utiliser leurs propres programmes. Pas vous ?
J'aurais peut-être dû commencer par la question "Qu'est-ce qui vous horripile dans les IHM"
- Il est difficile de définir un utilisateur moyen, un testeur n'est pas un vrai utilisateur débutant, qui n'est pas un utilisateur rôdé, etc.
-Même si le produit ne peut pas être considéré comme achevé avant tous les tests décrits par Souviron, il n'en reste pas moins que c'est un processus très long, qu'il faut bien commencer en espérant le faire durer le moins possible.

Le sujet auquel je pensais était donc les "bonnes pratiques" pour le premier jet, pour essayer d'obtenir très vite ( du premier coup, idéalement ) une IHM satisfaisante. ( un peu dans l'esprit des "guidelines" citées ci-dessus)

[el_slapper]

(.../...)- En tant qu'utilisateur, je rêve souvent qu'il existe un enfer pour les programmeurs où ceux-ci devraient utiliser leurs propres programmes. Pas vous ?

Bof. Le programmeur connait tellement son truc qu'il n'y fait plus attention du tout, et seules les énormes erreurs lui sont visibles. C'est pour ça que les gens sérieux font appel à des testeurs.

J'aurais peut-être dû commencer par la question "Qu'est-ce qui vous horripile dans les IHM"

1)Tout comportement contre-intuitif.
2)Toute complexité du traitement(alors je clique sur le dossier, ça m'ouvre une fenêtre, je scrolle en bas, j'appuie sur clôturer, je confirme, ça me jette parceque je n'ai pas mis de motif, arrrrrrrgh).

- Il est difficile de définir un utilisateur moyen, un testeur n'est pas un vrai utilisateur débutant, qui n'est pas un utilisateur rôdé, etc.

+1 ; voire, un testeur tout nouveau n'aura pas le même regard que le testeur qui connait l'appli par coeur(et finit, lui aussi, par ne plus voir les défauts).

-Même si le produit ne peut pas être considéré comme achevé avant tous les tests décrits par Souviron, il n'en reste pas moins que c'est un processus très long, qu'il faut bien commencer en espérant le faire durer le moins possible.

Le sujet auquel je pensais était donc les "bonnes pratiques" pour le premier jet, pour essayer d'obtenir très vite ( du premier coup, idéalement ) une IHM satisfaisante. ( un peu dans l'esprit des "guidelines" citées ci-dessus)

Lire dans les pensées des utilisateurs finaux. Blague à part, c'est presque ça : un truc standard et qui parait bien adapté peut être totalement décalé par rapport au VRAI besoin des utilisateurs, qui peinent à l'exprimer tant qu'ils n'ont pas le joujou sous la main.

[Nebulix]

1)Tout comportement contre-intuitif.
...
Lire dans les pensées des utilisateurs finaux.

En fait tout celà repose sur ton expérience, comme programmeur et comme utilisateur.
Que te dictera-t-elle quand tu proposeras la première interface en test, pour une appli destinée au grand public ( ou une appli destinée à des ingénieurs, ou ...)

[souviron34]

- En tant qu'utilisateur, je rêve souvent qu'il existe un enfer pour les programmeurs où ceux-ci devraient utiliser leurs propres programmes. Pas vous ?

Si, mais ceci est dû au fait que pour la plupart des programmeurs (et des équipes et méthodologies) l'utilisateur n'a qu'à faire ce qu'on lui dit de faire...

Le fameux syndrome de "l'autorité technique"..

"Je vous dis que la machine fait ça, et que voilà ce qu'il faut faire"..
"Ah ? Vous ne connaissez pa ce mot ? Bah, c'est utilisé tous les jours"..

etc etc...

J'aurais peut-être dû commencer par la question "Qu'est-ce qui vous horripile dans les IHM"

Comme le dit el_slapper :

1)Tout comportement contre-intuitif.
2)Toute complexité du traitement(alors je clique sur le dossier, ça m'ouvre une fenêtre, je scrolle en bas, j'appuie sur clôturer, je confirme, ça me jette parceque je n'ai pas mis de motif, arrrrrrrgh).

Mais surtout le fait d'avoir à apprendre quelque chose pour faire quelque chose que je fais tous les jours sans le soft (le "dictionnaire", où chacun met sa définition à lui...), ou bien à l'envers de ce qui se fait dans la vie courante.

Je me souviens d'un soft (et j'ai eu vent d'un certain nombre de cas identiques, y compris dans des messageries téléphoniques (le TOP de France Télécom jusqu'il y a peu par exemple) où le terme utilisé pour avoir le détail d'un appel téléphonique était "enveloppe"..

Ce qui, il est bien entendu de la part du commun des mortels, signifie : "date, heure, et numéro d'un appel téléphonique"

Pour le cas des choses "à l'envers", je me souviens (tiens c'était le même soft ), que pour jeter quelque chose à la poubelle, il fallait commencer par sélectionner la poubelle, puis sélectionner le formulaire, et enfin sélectionner "détruire".. Et je me souviens avoir dit au Chef de Projet : "c'est ça que vous faites chez vous le matin ? Vous vous asseyez devant la poubelle et vous vous dites "qu'est-ce que je pourrais bien jeter aujourd'hui ?" ? Et là vous allez dans la pièce à l'étage, allez fouiller la corbeille, y prenez une feuille, puis descendez la jeter, puis vous y remontez, aller chercher la feuille suivante, redescendez, la mettez à la poubelle, etc etc etc ???"

Et, de plus, ce qui m'horripile c'est soit un truc hypersophistiqué, qui prend une plombe à charger et/ou de mémoire, tout ça pour faire un truc idiot, ou au contraire un truc moche, sans saveur ni odeur, dont on doit se servir tous les jours et où tout est gris et noir...(sauf si il y a beaucoup d'informations autres en couleur).

-Même si le produit ne peut pas être considéré comme achevé avant tous les tests décrits par Souviron, il n'en reste pas moins que c'est un processus très long, qu'il faut bien commencer en espérant le faire durer le moins possible.

euh...

Dans ce que j'écris c'est au contraire dès le départ....

Dès la première ébauche, on a un "produit" correct.. Même si l'esthétisme final n'y est pas, il est nécessaire d'en avoir un minimum à ce stade...

Le sujet auquel je pensais était donc les "bonnes pratiques" pour le premier jet, pour essayer d'obtenir très vite ( du premier coup, idéalement ) une IHM satisfaisante. ( un peu dans l'esprit des "guidelines" citées ci-dessus)

re-euh... voir plus bas..

Lire dans les pensées des utilisateurs finaux. Blague à part, c'est presque ça : un truc standard et qui parait bien adapté peut être totalement décalé par rapport au VRAI besoin des utilisateurs, qui peinent à l'exprimer tant qu'ils n'ont pas le joujou sous la main.

En fait tout celà repose sur ton expérience, comme programmeur et comme utilisateur.
Que te dictera-t-elle quand tu proposeras la première interface en test, pour une appli destinée au grand public ( ou une appli destinée à des ingénieurs, ou ...)

Je l'ai dit au dessus :

Commencer par un "survol", "étude", appelez-le comme vous voulez, en filmant ou enregistrant et en interviewant des utilisateurs...

Par définition (et il en va de même de chacun) le "métier" ou l'usage est une somme de choses faites d'habitudes, de connaissances, d'automatismes, et de tout un tas de choses : expériences (en nombre d'années), et aussi bonnes ou mauvaises (avoir vécu tel cas, vu telle configuration qui "aurait dû marcher" et n'a pas marché, ou l'inverse, etc etc)..


Il faut donc, dès le départ, interviewer et pousser dans leurs retranchements les utilisateurs qu'on a sous la main.. Voire comme je disais les filmer, pour mettre à jour les automatismes, ou les incohérences entre la pratique et ce qu'ils disent qu'ils font...


Aucun de nous n'est capable de décrire avec exactitude la manière dont il procède pour faire telle ou telle opération. Et même dans les métiers ayant des "règles" rigoureuses (opérateurs de saisie, opérateurs de logiciels ou d'instruments sensibles, voire vitaux, ...) il y a toujours des automatismes, des "raccourcis", des choses implicites, qui sont utilisées...

Et donc, pour un premier jet comme pour le total, il est vital de passer une phase comme celle-ci...

C'est ce que je mettrais en avant comme première et unique "guideline" et bonne pratique...

[souviron34]

Je pense que l'important c'est de conserver une cohérence dans l'ensemble de l'application (en suivant des guidelines par exemple), et de prendre en compte le sens de lecture naturel pour l'utilisateur (généralement du style gauche > droite, haut > bas).

( un peu dans l'esprit des "guidelines" citées ci-dessus)

Je tiens à préciser que ces "guidelines" sont également à prendre avec des pincettes...


Autant il est incontestable que dans les cultures occidentales on lit de haut en bas et de gauche à droite, autant il est incontestable que vouloir uniformiser ("maintenir une cohérence") sur des choses qui, dans la vie sans inforrmatique, ne le sont pas, est une absurdité d'informaticiens atteints de "normatite"...


Un exemple parmi d'autres : dans le médical...


Que ce soit pour les infirmières dans un hôpital, ou pour un médecin dans son cabinet, tout un tas de choses ne sont pas "dans le sens normal"...


Prenons un médecin... Admettons qu'il doive écrire une prescription. Il prend en général une feuille de papier et un crayon. Puis fouille sa mémoire, et associe diagnostic et médicament.

MAIS..... comme on ne peut pas être omniscient, il peut également aller fouiller le Dictionnaire des Médicaments .. qui, par souci de clarté, ne figure pas sur son bureau, mais sur une étagère plus loin...

ET LA, ensuite, parlant avec le patient, il s'aperçoit que ce patient a telle ou telle condition, ou tel ou tel médicament, et qu'il lui faut vérifier si il y a de possibles interactions néfastes ou contre-indications.

Il va alors fouiller le Dictionnaire des contre-indications, ou les fiches techniques précises, et/ou téléphoner à la pharmacie pour savoir si telle ou telle forme (cachets, ampoules, etc) serait plus adaptée...

Du point de vue d'une IHM, vouloir présenter d'une manière "cohérente" de gauche à droite et de haut en bas une telle séquence est stupide.. Dans la majeure partie des cas, cela fera perdre du temps au médecin. Alors que quand il a un problème du type mentionné ci-dessus, il a déjà des "chemins" non directs lui permettant d'aller dénicher l'information nécessaire...




Prenons maintenant le cas d'une infirmière... à l'hôpital.. Autant pour la plupart des opérations son travail est "relativement" linéaire, autant lorsqu'elle fait sa tournée (par exemple de médicaments) dans un étage elle a d'une part des informations pouvant arriver en temps réel ("les analyses de tel patient sont arrivées" par exemple) d'autre part des informations éparses (ce patient-là a sauté son repas la dernière fois car il était en radio, celui-ci s'est engueulé avec sa femme, etc etc)...

Elles disposent (sans informatique) d'un tableau récapitulatif qui , bien que se lisant de gauche à droite et de haut en bas, est, suivant les services, regroupé de manière différente.. Mais c'est à peu près la seule tâche qu'elles effectuent qui nécessite cette "vision d'ensemble"..

Du point de vue d'une IHM, négliger la particularité de cette tâche en aliggnant la fabrication de l'écran sur la "cohérence" avec les autres écrans est donc une erreur fondamentale...



Il en va de même pour les contrôleurs aériens, qui disposent sur leurs écrans des petits post-it décrivant l'avion qu'ils suivent avec 1 ou 2 paramètres (fréquence radio, etc)

Cette manière de faire, totalement optimisée et adaptée, est antinomique de l'ensemble du reste de leurs actions... Elle doit donc être respectée ... (ce qu'on d'ailleurs bien compris les fabricants des logiciels qui leur sont destinés, mais seulement après avoir subit des échecs cuisants (plus de 10 ans de développement pour rien pour certains...))




Je réitère donc mon propos :

des "guidelines" oui, MAIS attention à ne pas les appliquer aveuglément partout.... MEME à l'intérieur d'un même logiciel, il PEUT être parfaitement correct de NE PAS les respecter....


Mis à part pour quelques trucs "bateau", la plupart des métiers ont optimisé leur manière de faire sur des générations, voire des siècles (les hôpitaux ont 6 à 8 siècles d'existence). Penser qu'on va faire mieux est au mieux de la bêtise, au pire de l'arrogance absolue... Nous, en tant que développeurs de logiciels, sommes là pour les aider... Pas pour les re-formater...




Pour terminer, un exemple de l'absurdité de la "normatite" et des "guidelines" dans certains cas..

Reprenons l'exemple médical, que je connais bien. Un technocrate en manque a un jour, par souci "d'égalité des utilisateurs", stipulé que, pour que daltoniens et non-daltoniens soient à égalité dans les hôpitaux, les logiciels devaient tous être en noir et blanc.....

C'est d'une stupidité incommensurable...

Outre le fait que que les daltoniens ne voient pas plus le noir noir ou le blanc blanc, et qu'il existe tout un tas de différentes sortes de daltonisme, les daltoniens apprennent dès qu'ils sont bébés, et tout au long de leur vie, que ce que tout le monde appelle "jaune", eux ils le voient gris-bleu, que ce que tout le monde appelle "rouge", eux ils le voient verdâtre (par exemple)... L'association "nom usuel - couleur perçue" est intimement liée à l'apprentissage du daltonien depuis qu'il est nourrisson (comme tout un chacun, d'ailleurs.. Le mot "rouge" est une convention...). En conséquence, un médecin ou une infirmière daltonien saura prendre une feuille dite "jaune" dans une pile de feuilles (il saura la bonne nuance de gris-bleu par exemple)...

Penser que parce que c'est un logiciel c'est différent ne fera que le perturber en lui faisant perdre ses repères...




Voilà...

[moldavi]

Bonjour.

Sur les bonnes pratiques, beaucoup de choses ont été dites. J'adhère complètement.

Je voudrais juste appuyer un peu plus sur l'aspect graphique, et je pense aussi qu'un infographiste est nécessaire à la conception de l'IHM. Je trouve que cela donne une âme supplémentaire au logiciel et une personnalité nécessaire, tellement tant de logiciel se ressemblent graphiquement.

[el_slapper]

J'aimerais, après reflexion, reprendre le dernier post de Souviron à ma sauce :

Il n'existe pas de système bête et méchant qu'il suffit d'appliquer pour avoir toujours un résultat correct. Mon expérience ne me donne pas d'écran-type applicable partout. Mon expérience me pousse au contraire à aller voir ce que font réellement les gens, et pas simplement ce qu'ils en disent. Souvent, en effet, ils ne disent pas tout, car ils n'ont pas conscience de la compléxité de leur propre travail.

Un exemple hors informatique. Un ergonome est chargé d'améliorer les conditions de travail sur un établi de montage industriel. Avant sa venue, le patron charge un travailleur de filmer son collègue. L'ergonome arrive, visualise le film, ne voit que des séquences "normales", et remarque des coupures. Sans même y penser, le collègue cameraman avait "filtré" tous les incidents : marteau qui tombe, pièce non conforme, souci sur la machine.....

Mais en fait, tout ça faisait partie de leur travail. Et c'est justement sur ces points là que l'ergonome(celui-là était bon) est intervenu. Ce qui cassait le dos du travailleur, c'était 5 fois par heure de ramasser son marteau, pas 120 fois par heure de l'utiliser.

Ce que me dit mon expérience, c'est "je ne sais pas". Je ne sais pas ce que le professionel sait. Je ne sais pas quels sont ses besoins exacts. Je ne sais pas si il a besoin d'une corde pour empêcher son marteau de tomber ou d'un tabouret pour être à bonne hauteur. Je ne sais pas si son travail est linéaire(ouvrir client, ouvrir carte, modifier carte, valider) ou modulaire(alors, depuis le client, il peut indifférement sauter à l'écran carte, l'écran compte ou l'écran package). Je ne sais pas quelles sont ses actions favorites(10 fois plus de comptes que de cartes? L'inverse?). Mais je sais que je dois le cuisiner pour avoir ces informations, car lui-même ne les lachera pas spontanément : "_mais ramasser le marteau ne fait pas partie de mon travail! _5 fois par heure, c'est suffisemment souvent pour faire partie intégrante de votre travail".

Et c'est la seule chose que je sais. Tout le reste, je dois l'oublier, car si c'était vrai pour la gestion des cartes, ça sera souvent faux pour la gestion des saisies.

[Nebulix]

Bon si j'ai bien compris, ce qui se dégage des messages des contributeurs ( peu nombreux, hélas, mais de qualité) c'est :
la bonne pratique, c'est de ne pas avoir de bonne pratique
mais de se couler dans la pratique de l'utilisateur.
Et j'approuve tout à fait
Alors tout est dit ?
Je ne crois pas, heureusement, mais ce débat a peut-être été posé de façon un peu trop abstraite. Je vais en ouvrir un plus concret comme je l'ai déjà évoqué : Qu'est-ce qui vous horripile dans les IHM et j'espère que celui là alimentera celui ci

[souviron34]

la bonne pratique, c'est de ne pas avoir de bonne pratique
mais de se couler dans la pratique de l'utilisateur.

ne me fait pas dire ce que je n'ai pas dit...

J'ai cité des cas de bonnes pratiques, et des "guides"..

Je dirais que surtout la conclusion est :

la bonne pratique c'est d'être souple et pas dogmatique...

• Des guides ? oui, mais pas forcément tout le temps.
• De la cohérence ? Oui, mais pas forcément sur tout
• Des tests ? Absolument
• Des choses à ne pas faire ? certainement

Il y a donc une distinction entre ce que je dis et ton résumé :

1. Je dis qu'il y a une bonne pratique, qui est d'être à l'écoute, et de moduler suivant les logiciels/ types d'utilisateurs, voire à l'intérieur du même logiciel...
   
   
2. Et je dis qu'il y a une mauvaise pratique, qui est de vouloir appliquer le même filtre de manière systématique partout..

Ceci ne veut surtout pas dire qu'il n'y a pas de bonne pratique..

Il n'y a juste pas de "moule pour toute IHM".

Maintenant, comme je l'ai déjà dit à plusieurs reprises, et comme le confirme moldavi, on devrait donner autant d'attention au graphisme d'une interface qu'à celui d'une plaquette publicitaire.

Et par conséquent, outre l'intervention d'un vrai graphiste, il faut quand même prendre conscience (et/ou faire prendre conscience) que il faut (faudrait) que chacun des "programmeurs" de cette IHM soit quand même un peu artiste, esthète, sur les bords, même si il n'y a pas qu'un seul sens de l'esthétisme... Le final sera corrigé par le graphiste, mais même pour lui faciliter le travail (et avoir de bons retours sur les test et/ou conception) il est bon d'avoir quand même une ébauche "relativement esthétiquement correcte", et pas juste une série d'écrans gris...

[taha1]

je ne suis pas experte et je n'ai pas fait beaucoup d'IHM mais je dirais que le pattern MVC permet d'éclaircir et de bien organisé pas mal de code