Discussion :

[niocco]

Ca me fait penser a mes cours d'ergonomie :

Comment définir l'ergonomie d'un logiciel ?

la réponse tient en 3 aspects :

1 - Son auto documentation ( c'est pas le terme exact mais en gros ca veut dire est ce que visuellement il a l'air de faire ce qu'il est fait pour faire )
exemple un logiciel de gestion des absences avec des logos férrari partout, ca peut dérouter.
2 - Son efficience : est ce qu'il me permet d'arriver a mes fins et en combien d'opérations ? ( exemple : nombre de clic de souris nécéssaires pour obtenir une vue simple de mon travail )
3 - (le plus important ici) : la connaissance d'un logiciel dépends étroitement de la connaissance et la représentation qu'on les utilisateurs d'un tel logiciel.
C'est à dire que si vous mettez un homme de néandertal devant la meilleure des interfaces, il ne pigera pas plus parce qu'il lui manque toute la représentation mentale de ce qu'est un l'informatique.
Nous informaticiens on en a une représentation trés développée parce qu'on évolue dedans. On sait même comment marche tout ce qu'on ne voit pas d'un logiciel. Exemple : Quand j'achete un nouveau jeu, je l'installe et je vais directement voir dans options->configuration juste pour voir a quoi j'ai à faire.
Pour la plupart des utilisateurs faire ca reviendrait a ouvrir le capot de leur voiture pour regler un poil le delco et ajuster le ralenti avant de démarrer.

[ALT]

* ... a la main qui démange ... *

Vous préféreriez quel vocabulaire ?

La communication Dev / utilisateur "au travers des interactions de l'utilisateur avec le logiciel" ? (IHM c'est plus court quand même ... )

IHM, je connais.

C'est IHMSque je ne connais pas.


Bon, d'accord, je réagis un peu tard, mais j'ai reçu aujourd'hui (17 h 34) la première notification depuis mon dernier message !

[souviron34]

C'est IHMSque je ne connais pas.

C'était pour "machines"

[Excellion]

Un autre exemple me vient en tête.

Pour bien comprendre, il faut savoir que "Madame", "Mademoiselle" et "Monsieur", en français sont des "titres", et non des civilités qui en français signifient des politesses.

Bref, un de mes prédécesseurs, misa sur l'intelligence des utilisateurs et mit un champ texte sans contraintes dans un formulaire d'enregistrement.

Résultat : "Je suis le comte de ...", "Docteur ès droit & ...".

Bref, des titres.
Mais qui en l'occurrence n'avaient rien à voir avec le formulaire en question.

Là dessus faites une extraction sur le sexe de l'utilisateur... Pour ma part, je m'en suis référé au prénom, en classant à part les prénoms asexués.

Voilà le genre de chose qu'un développeur doit prendre en compte s'il veut que son programme fonctionne correctement et que les données récupérées servent à quelque chose.

Bref, penser l'utilisateur comme un idiot, n'est pas une insulte, mais une absolue nécessité pour tout développeur suffisamment expérimenté un tant soit peu professionnel et souhaitant s'éviter des nuits blanches...

[goomazio]

Non seulement il ne s'agit que de faire comme si les utilisateurs étaient idiots, mais surtout, il s'agit de faire comme si les utilisateurs n'étaient pas informés/formés. À confondre idiotie et non connaissance, ne nous étonnons pas d'être pris pour des idiots (pour rebondir sur les messages postés visiblement par des utilisateurs ).

Dommage que ce débat parte d'une phrase qui a surtout comme conséquence pour les développeurs de se mettre les utilisateurs à dos.

Mais comme tout le monde semble arriver à la même conclusion, j'aurais peut-être pu m'abstenir de poster cette réponse...

[Lady]

IHM, je connais.

C'est IHMSque je ne connais pas.


Bon, d'accord, je réagis un peu tard, mais j'ai reçu aujourd'hui (17 h 34) la première notification depuis mon dernier message !

Bah j'oublie tellement de s au pluriel que j'en rajoute là où y en a pas besoin ... une question d'équilibre.....

[willom]

J'ai pas eu le courage de lire toutes les pages, mais je vais réagir quand même au risque de paraphraser...

L'utilisateur n'est pas forcément con, nous sommes "informaticiens", nous connaissons le fonctionnement de tous ces trucs, machins, bidules qui apparaissent sur l'écran.
L'utilisateur veut que ça marche, sans avoir à réfléchir plus que ça. Ils ne sont donc pas con, mais n'ont pas les connaissances nécessaires.
Je pense que c'est très difficile d'être objectif quand on baigne dans un milieu, quelqu'un qui ne connait pas le "alt+F4" n'est pas con, il ne le connait pas, mais ça nous parait bizarre parce que notre vision des choses est biaisé...

Pour reprendre un exemple donné plus haut, un champs avec "votre/fichier/ici.txt" ne parle forcément, même si ça nous paraît évident, il est déjà plus facile de parcourir un explorateur puis de cliquer sur le fichier de son choix, parce que les gens y sont habitués et connaissent ce fonctionnement. Il est très difficile de se mettre à la place du client.

Ensuite, concernant les tests, ça n'est pas toujours facile de faire des tests exhaustifs, mais on peut essayer de s'en approcher en utilisant des techniques (RIGHT BICEPs), qui permettent de s'assurer un minimum d'avoir fait des tests complet, prévenant ainsi certains bug que le client aurait pu lever.

Pour conclure, je dirai qu'Apple a bien compris la nuance (et je ne suis pas un fan de mac, je précise ), il fait juste en sorte que le fonctionnement soit le plus "naturel" possible...

[Gluups]

Il est regrettable de se lancer dans une longue discussion sur "l'utilisateur est-il un idiot ?" sans se mettre d'accord sur ce qu'est un idiot, à supposer qu'on soit d'accord sur ce qu'est l'utilisateur.

Si le programmeur a besoin qu'on lui dise que lorsqu'il demande un changement de disquette à l'utilisateur, l'opération suivante qu'il doit introduire dans le traitement est un contrôle de changement de disquette (ce qui suppose de savoir comment identifier la disquette introduite dans le lecteur), avec une sortie propre du traitement si l'utilisateur s'aperçoit qu'il a oublié la disquette à la maison, ça ne signifie pas que l'utilisateur est un idiot.

Pas davantage si le programmeur en est à ne pas connaître la distinction entre un champ texte et un champ date, ou si le plombier confond un pied à coulisse avec une clef à molette.

[cboudy]

Conclusion à laquelle je suis arrivé au fur et à mesure du retour des utilisateurs : "Il ne faut pas prendre les utilisateurs pour des cons mais il ne faut pas oublier qu'ils le sont"

[Gluups]

Quand on appelait le prof de prog pour valider nos dernières avancées sur des programmes simples, il commençait par taper littéralement () sur le clavier puis appuyait sur entrée.

Tu te fais avoir une fois, pas 2 mais même après blindage des inputs il trouvait des trucs improbables.

Le test du singe, qu'on appelle ça.
Pour ma part je l'ai juste entendu raconter, comme un bon truc à faire, mais de mon côté j'en suis resté à juste essayer de penser à tous les cas. (Pour faire une intrusion dans le concret, si quelqu'un a un outil à proposer ...)

C'est vrai aussi que tant que c'est possible j'aime autant confier le programme pour test à quelqu'un de la future équipe utilisatrice, car il a toutes chances d'être plus représentatif que moi des utilisateurs finaux. Pas forcément complètement, car ça marche mieux avec une personne capable d'exprimer les difficultés rencontrées, éventuellement de les reproduire quand c'est possible, ce qui n'est pas toujours le cas de tous les utilisateurs.

[Gluups]

Je viens de parler de l'utilisateur à qui confier les tests, voilà qui m'inspire une sortie de sujet, si vous voulez bien me le pardonner, après tout j'imagine que nous ne sommes pas sur le point de résoudre en deux réponses un problème épineux.

Une personne qu'on ne rencontre pas sur tous les projets, mais ça peut arriver, c'est la groupie. Elle aimerait bien faire de la programmation, mais n'a pas franchi le pas. A défaut elle aimerait bien être l'interlocuteur privilégié de l'analyste-programmeur, et fait son maximum pour se faire bien voir.

Sauf qu'avoir une bonne appréhension d'un système demandé pour toute une équipe en acceptant de filtrer les informations en les entrant via une seule personne, ça expose à des déconvenues qui ne feraient pas très pro.

Attention, une fois qu'on va s'adresser aux autres utilisateurs, la groupie risque d'être vexée, et peut même trouver un autre moyen de faire capoter la mission.

La discussion en cours montre qu'on peut très bien lui trouver un rôle privilégié au moment des tests, ce qu'on peut très bien mettre en avant si on y pense au début, ça peut être une façon de maintenir de bonnes relations. Au moment de l'analyse, lui trouver un rôle privilégié demande vraisemblablement plus de subtilité de la part de l'analyste-programmeur. Il y a des moments, comme ça, où on aimerait bien être subtil.

[StefGac]

Quelles idées avez-vous de l'utilisateur final lors du développement d'une application ?
Un développeur choisi comme leitmotiv « 90 % des utilisateurs sont des idiots »

1) Non, déjà c'est profondément méprisant pour les gens. L'auteur du blog se place dans quel catégorie , les 80% ou 20% ( pour suivre Parreto)
2) Les utilisateurs ont autre chose à faire que d'apprendre comment l'appli super génial de la super équipe de dev fonctionne
3) Pour plus de détails, allez voir le site de Joel on Software(http://www.joelonsoftware.com/uibook/fog0000000249.html) avec des bons principes que j'applique( et qui marche) comme :
"A user interface is well-designed when the program behaves exactly how the user thought it would."
"Every time you provide an option, you're asking the user to make a decision."
"Designing for People Who Have Better Things To Do With Their Lives"
"Users Don't Read the Manual."
4) Penser comme l'auteur du blog, c'est aller dans le mur à coup sûr !
5) Pour finir, c'est pas l'utilisateur qui est crétin, c'est à mon avis, celui qui conçoit l'appli qui n'est pas capable de comprendre l'utilisateur et le monde dans lequel il vit. Il parait que c'est une preuve d'intelligence que de savoir s'adapter ?

[ALT]

Je ne sais pas si l'utilisateur a le QI d'une huître ou non, mais il est toujours utile de se demander quelle erreur l'utilisateur peut faire. Exemple (facile) : saisir des lettres dans un champ numérique.
Le bon programmeur doit donc toujours intégrer des "anti-cons" dans son code. Surtout qu'une erreur est possible, même au programmeur (en phase de test, par exemple). Planter un programme (ou lever une exception, ce qui revient au même) pour avoir négligé cette partie du travail est un signe d'incompétence ou de flemme excessive de l'informaticien.

Un autre aspect est la conception de l'interface : elle doit être logique, simple & intuitive. Ça suppose de se demander comment l'utilisateur peut avoir besoin de remplir les champs, comment il peut réagir devant un message d'erreur trop ésotérique ("Une erreur AC576B800 s'est produite à l'adresse 29400FC8A9"). Bon, cet exemple est certes caricatural (bien qu'historique !), mais un truc du style "Erreur inconnue" est tout aussi déroutant. Quoique que peut-être pas toujours évitable.
Effectivement, lui demander de tester, permet de savoir s'il est satisfait de l'ergonomie, si ça fonctionne même en cas d'erreur de sa part, &c.

[Génoce]

Un autre aspect est la conception de l'interface : elle doit être logique, simple & intuitive. Ça suppose de se demander comment l'utilisateur peut avoir besoin de remplir les champs.
Effectivement, lui demander de tester, permet de savoir s'il est satisfait de l'ergonomie, si ça fonctionne même en cas d'erreur de sa part, &c.

Tout à fait d'accord, ceci dit, faire des IHMs intuitives pour l'utilisateur relève parfois de la magie noire surtout que chaque utilisateur a une vision différente.

Bon j'avoue, je suis vraiment pas un visionnaire en manière d'agencement d'une IHM...

[souviron34]

Tout à fait d'accord, ceci dit, faire des IHMs intuitives pour l'utilisateur relève parfois de la magie noire surtout que chaque utilisateur a une vision différente.

Bon j'avoue, je suis vraiment pas un visionnaire en manière d'agencement d'une IHM...

ça se voit

Il y a des User Tests, de User Groups, des User Acceptance Tests, des User-Centered methologies, des approches ergonomiques, etc etc...

Il n'y a pas UN ou DES utilisateurs, mais des groupes d'utilisateurs à créer pour passer au crible une IHM...

[Génoce]

ça se voit

Comment ça?!

[souviron34]

il n'y a JAMAIS de magie noire si on travaille professionnellement et méthodiquement

Et justement le principe d'une méthode est de ne pas se fier à UN utlisateur...


Ce que tu dis correspond à la même chose que faire un soft sans plan...

[zeyr2mejetrem]

Il y a des User Tests, de User Groups, des User Acceptance Tests, des User-Centered methologies, des approches ergonomiques, etc etc...

Une telle méthodologie n'est elle pas compatible qu'avec les sociétés d'une taille certaine ?
Pour avoir bossé dans des TPE/PME d'édition de logiciel je doute que l'environnement rende possible une méthodo si carrée (hélas !)

[RegBas]

1) Non, déjà c'est profondément méprisant pour les gens. L'auteur du blog se place dans quel catégorie , les 80% ou 20% ( pour suivre Parreto)

Faut arrêter de prendre cette expression au pied de la lettre. Tu cites toi même :

"Every time you provide an option, you're asking the user to make a decision."
"Designing for People Who Have Better Things To Do With Their Lives"
"Users Don't Read the Manual."

Restreindre les choix des utilisateurs, considérer qu'ils ne liront pas le manuel, developper pour des gens qui ne s'interesseront pas plus que ça à l'outil informatique parce qu'ils ont mieux à faire, c'est EXACTEMENT ce que veut dire "considérer que 90% des utilisateurs sont des idiots".

Et si tu avais lu le blog, tu saurais que son auteur se met dans les 90 % :

And, in good conscience, don't you want to be an idiot when you're on the other side of the screen? I do! I want to be an idiot!

Please let me be an idiot. I want things to "just work". Don't make me figure my way through all the setup procedures. "Don't make me think"

[souviron34]

Une telle méthodologie n'est elle pas compatible qu'avec les sociétés d'une taille certaine ?
Pour avoir bossé dans des TPE/PME d'édition de logiciel je doute que l'environnement rende possible une méthodo si carrée (hélas !)

oh non.. Une approche centrée utilisateur est indépendante de la taille de l'entreprise ou du projet, et ne dépend réellement que du fait de savoir si le logiciel est une part importante des activités de l'entreprise (en interne ou en externe, c'est à dire pour ses propres employés ou pour des clients extérieurs) ou non..

ça coûte BEAUCOUP moins cher que de faire les choses dans l'autre sens...

Refaire une architecture, ou que son produit ne soit pas acheté, est beaucoup plus coûteux que de payer l'équipe (et éventuellement des utilisateurs) pour 2 à 3 semaines à étudier le comportement et les souhaits des utilisateurs..

Je crois que c'est plus par méconnaissance de ces approches et par suffisance des informaticiens (que ce soit devs ou CP), que cela n'est pas plus utilisé..

Si un CP exigeait cela, il n'y aurait pas un patron de TPE/PME qui y verrait quoi que ce soit à redire... Qu'est-ce que 3 semaines sur la plupart des temps de devs d'applis "centrales" au fonctionnement de la boîte ???