Discussion :

[lod101]

...j'avais un utilisateur qui me demandait sans cesse sur quel bouton il fallait appuyer pour envoyer un mail alors que le bouton Envoyer/Recevoir prenait la moitié de l'écran !!

La remarque de ton utilisateur ne me choque pas plus que ça.
Pourquoi appuyer sur un bouton "Envoyer/Recevoir" lorsqu'on veut seulement envoyer un mail ? Ca veut dire quoi "Envoyer/Recevoir" ?
Ce genre de bouton me semble manquer cruellement d'ergonomie

Je trouve certaines remarques ici d'une arrogance extrême que ce soit par rapport aux utilisateurs ou par rapport à l'importance d'un logiciel...

En effet...

Oui, dur de dialoguer avec les utilisateurs.. surtout quand ils pensent tout savoir mieux que toi en terme d'ergonomie des interfaces...

Je pense qu'il n'y a aucune raison pour que tu en saches d'avantage qu'eux.
L'ergonomie est un métier. A moins d'y avoir été formé, le développeur n' a aucune raison de maîtriser cette compétence. Il peut éventuellement y être sensibilisé, mais l'ergonomie ne s'arrête pas à la couleur des boutons

Je me suis permis les remarques précédentes car je suis développeur et que j'ai de la chance de travailler aujourd'hui sur des projets qui intégrent sociologues et ergonomes.
En travaillant avec ce type de métiers, on comprend rapidement que le développeur est loin d'être la seule pièce maîtresse pour la réussite d'un projet et la satisfaction du client.

L'analyse du besoin passe bien sûr par la communication mais également par l'observation des utilisateurs, c'est là que le sociologue va pouvoir intervenir (entre autre) et augmenter les chances d'avoir de bonnes spec.
L'ergonome lui va concevoir les IHM ou aider le developpeur. Il va définir par exemple la navigation dans les pages webs, le niveau de profondeur des menus, la prise en compte de l'accessibilité,...

En travaillant systématiquement avec ces métiers, on augmenterait grandement le taux de réussite de nos projets informatiques et on arriverait même à améliorer le travail de nos utilisateurs

Quelles idées avez-vous de l'utilisateur final lorsque vous concevez vos applications pour l'adapter à ses besoins ?

L'idée que j'ai de mon utilisateur, c'est que si en tant que developpeur je travaille tout seul, y'a peu de chance qu'il soit entierement satisfait. Parce qu'en plus des bugs, il aura un soft qui répond pas à ses besoins avec des messages d'erreur incompréhensibles

[souviron34]

Absolument..

C'est d'ailleurs pour ça que je prône, partout où je peux , et quelle que soit la méthodologie employée, d'avoir des Têtes de projet (notez bien le non-usage du mot chef) bicéphales : un informaticien généraliste et un utilisateur/expert.

Et que je recommande d'utiliser un graphiste (un vrai, pas quelqu'un qui utilise Photoshop) pour finaliser une IHM..

Si en plus on peut avoir un egonome avec, surtout en phase de conception/analyse des besoins, et/ou faire des études vidéos d'utilisateurs, c'est encore mieux...

[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"

[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.....

[Le_Bret]

Je ne sais pas quel est le pourcentage d’utilisateurs idiots, mais le pourcentage de programmeur qui se foutent de savoir comment l’utilisateur va faire pour utiliser leur bousin n’est pas mal non plus.

[lod101]

Je ne sais pas quel est le pourcentage d’utilisateurs idiots, mais le pourcentage de programmeur qui se foutent de savoir comment l’utilisateur va faire pour utiliser leur bousin n’est pas mal non plus.

Ouais...mais bon, le développeur évolue non ? Il est de plus en plus sensibilisé ? J'ose le croire quand même...

Enfin chez moi, on l'est. On parle de plus en plus de ... USER EXPERIENCE...
Oui, je sais, je vois d'ici certains dire que c'est un terme à la mode qui ne fait que reprendre de bonnes pratiques existantes. Mais bon, ça fait pas de mal de mettre des mots derrière ces bonnes pratiques et d'embarquer avec de nouveaux métiers...
Les sciences humaines ont leur rôle à jouer dans le dev. logiciel...

[el_slapper]

chuis content de faire du batch, moi...

Sauf quand le batch en question comprend une partie "échantillons", liste papier de données extraites du fichier. Et on retrouve les mêmes horreurs.

"_Bon, elle est gentille, votre spec, mais j'ai que 132 caractères de large, et je ne peux pas tout mettre sur une seule ligne
_Alors mets tout sur deux lignes. C'est pas important
(3 semaines plus tard)
_Aaaaaah! Mais il est illisible, ton truc
_C'est exactement ce que tu as demandé...."

(Le fight continue, sans moi, je suis en vacances. Je suis sur que ça continue à cartonner)

Et +1 sur les infographistes pas graphistes.

[NEfanda]

Bonjour,
Je ne comprends pas comment on peut considérer les utilisateurs comme des idiots. Avant d'affirmer ce genre de remarques, il faut réfléchir à nos réactions face à un outil totalement inconnu. Ne nous comportons-nous pas comme un vulgaire "idiot" pour reprendre le terme?
Les personnes qui affirment ce genre de remarques doivent aussi se considérer comme telles, face à des outils inconnus.
A mon avis, en tant que développeur, l'utilisateur doit être pris en considération avec respect. Nous devons nous mettre à son niveau en matière d'explications. Nous devons étudier et si possible prendre en compte ses remarques, car c'est lui qui sera pendant des heures sur le futur logiciel.
Il faut le respecter et lui aider à donner son avis, pour mieux y répondre.
C'est d'ailleurs à cause de personnes qui traitent les utlisateurs d'idiots que les développeurs ont mauvaise réputation: des geeks au fond de leur bureau
Cordialement
Nicole

EIRL EFANDA Nicole
Azélie Informatique
131 Bd du Général Vanier
14000 CAEN

[chico200987]

Et je pense que c'est ce qu'il manque dans nos formations, des cours de communication, mais pas au sens marketing. Apprendre à être plus pédagogue avec les utilisateurs, et sortir de ce rôle de "gros geek" d'informaticien.

Peut-être qu'il serait temps également de proposer à l’école des cours d'informatique...

Je suis d'accord, la communication est difficile, et c'est souvent qu'on remarque des développeurs qui ont du mal a s'exprimer clairement simplement, sans être trop technique pour ne pas perdre l'utilisateur alors que ca semble une evidence pour nous..

Les cours d'informatique a l'ecole oui pourquoi pas, il y en a de plus en plus aujourd'hui (ou du moins, ils utilisent de plus en plus l'outil informatique) mais a condition que ce soit bien encadre, pour ne pas que des élèves de CM2 tombent sur des videos.. Un peu bizarre quand leur instit' par en réunion..

Je me suis permis les remarques précédentes car je suis développeur et que j'ai de la chance de travailler aujourd'hui sur des projets qui intègrent sociologues et ergonomes.
En travaillant avec ce type de métiers, on comprend rapidement que le développeur est loin d'être la seule pièce maîtresse pour la réussite d'un projet et la satisfaction du client.
...

Certes, mais le prix du logiciel final augmente exponentiellement.. Tout dépend du projet, coller un graphiste, ergonome, sociologue et développeur pour chaque projet c'est pas dans l'porte-monnaie (ou dans l'envie même..) de toutes les entreprises..
Effectivement tu en as de la chance, je suis dans une boite qui fait des contrats avec des banques, assurances et qui vend ses logiciels pour quelques dizaines de milliers d'euros la licence d'installation, et bah aucun graphiste a l'horizon, encore moins de sociologue ou autre.. 5 développeurs (meme pas sur les mêmes projets) et c'est tout !



@NEfanda : Si, nous l'avons dit et revendique, nous (a 90%) faisons parti des idiots qui ne lisent pas la doc d'un programme avant de l'utiliser..
Se mettre a son niveau en matière d'explications, d'accord, mais comme dit plus haut ce n'est pas donne a tout le monde.. Communiquer avec des mots simples quand tout semble au plus simple pour nous semble difficile quand on est pas entraine (pour ca que je plussoie les cours de com' dans les formations d'informatique)

[Doksuri]

NEfanda => je te mets au defi de faire un formulaire web d'incription (le truc banale hein) en considerant les utilisateurs comme "intelligents"...

tu verras que t'auras bien des surprises dans ta BDD...

donc, on prend les utilisateurs pour des idiots, on ne leur laisse pas le choix quand ils doivent entrer des informations a la main et comme ca, tout le monde est content.

l'exemple qui me vient a l'esprit c'est pour la date de naissance : t’imagine un champ texte "entrez votre date de naissance"
tu vas te retrouver avec 50 000 syntaxes d'ecriture de date differentes...intraitable derriere et qui ferait planter ton script : donc... 2 solutions
1) tu considere l'utilisateur comme intelligent, tu parse ce qu'il a rentre, tu fais 10 000 tests pour verifier qu'il a bien rentre une date complete, tu reformate comme tu veux, et apres tu fais tes traitements
2) tu le prend pour un abruti et tu lui impose 3 listes pour jour, mois, annee... (1 ligne pour verifier l'annee bissextile) et hop..

il faut réfléchir à nos réactions face à un outil totalement inconnu

c'est tout a fait ce qu'on fait en le prenant pour un abruti...
l'exemple le plus parlant sont les personnes agees : elles ne savent jamais ou cliquer, quoi rentrer dans les champs qu'on lui demande

=> plus t'auras anticipe de cas improbables, plus ton resultat final sera complet (car il y aura toujours quelqu'un.. un jour... qui fera la manipe que t'avais pas prevue...)

[Génoce]

il y aura toujours quelqu'un.. un jour... qui fera la manipe que t'avais pas prevue...

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.

[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.

[lod101]

...
l'exemple qui me vient a l'esprit c'est pour la date de naissance : t’imagine un champ texte "entrez votre date de naissance"
tu vas te retrouver avec 50 000 syntaxes d'ecriture de date differentes...intraitable derriere et qui ferait planter ton script

C'est sûr que si tu ne guides pas l'utilisateur tout les formats sont possibles pour lui.
Pourquoi ne pas mettre un p'tit exemple à coté de ton champ du style "JJ/MM/AAAA". C'est pas dur à contrôler ça ?

...
2) tu le prend pour un abruti et tu lui impose 3 listes pour jour, mois, annee... (1 ligne pour verifier l'annee bissextile) et hop..

Et hop... j'ai une ihm bien pourrie mais je suis content, j'ai plus de pb techniques....
Typique du dev. logiciel. On fait pâtir l'utilisateur de nos difficultés techniques sans se poser plus de questions que ça...

...
l'exemple le plus parlant sont les personnes agees : elles ne savent jamais ou cliquer, quoi rentrer dans les champs qu'on lui demande

Je ne sais pas si tu développes beaucoup de services pour les personnes agées, mais moi c'est un peu mon fond de commerce. Je suis dans le maintien à domicile, je connais un peu la problématique.
Et c'est sûr que si tu fais des pages web avec du texte "patte de mouche" et des boutons 10x10 comme pour tout le monde, ton p'tit vieux y va pas s'en sortir et vaut mieux que tu changes de cible comme utilisateur final.
Dans ce genre de service il y des domaines comme l'Accessibilé à prendre en compte et des fois faudra même penser à oublier la souris

Alors, je comprend bien tes pb techniques, j'ai les mêmes, mais il faut arrêter de penser que les utilisateurs sont des boulets parcequ'ils sont la source de tes pb.
Aujourd'hui tout developpeur devrait savoir qu'on ne peut pas fournir à l'utilisateur uniquement un soft qui ne plante pas.
L'utilisabilité et l'ergonomie, entre autres, sont primordiales

[atb]

Pour tester les développements nous avons trouvé un bon début:
lancer l'interface et s' asseoir sur le clavier. Ceci pour essayer de reproduire les conneries que peuvent taper les utilisateurs finaux

[Doksuri]

Pourquoi ne pas mettre un p'tit exemple à coté de ton champ du style "JJ/MM/AAAA". C'est pas dur à contrôler ça ?

parcequ'il y aura toujours quelqu'un pour mettre aa-jj-mm (ou autre)
et donc ca revient au point 1) => faire 10 000 verif

Et c'est sûr que si tu fais des pages web avec du texte "patte de mouche" et des boutons 10x10 comme pour tout le monde, ton p'tit vieux y va pas s'en sortir

c'est pour ca qu'on fait la difference entre codeur et graphiste...et c'est aussi pour ca qu'on peut faire plusieurs feuilles de styles css

[behe]

C'est sûr que si tu ne guides pas l'utilisateur tout les formats sont possibles pour lui.
Pourquoi ne pas mettre un p'tit exemple à coté de ton champ du style "JJ/MM/AAAA". C'est pas dur à contrôler ça ?

Et tu controles comment que l'utilisateur n'a pas rentré MM/JJ/AAAA (03/05 et non 05/03)? Au moins avec les combobox tu mets les mois en toutes lettres et ça t'évites d'avoir des données foireuses

[lod101]

Certes, mais le prix du logiciel final augmente exponentiellement.. Tout dépend du projet, coller un graphiste, ergonome, sociologue et développeur pour chaque projet c'est pas dans l'porte-monnaie (ou dans l'envie même..) de toutes les entreprises..

Ben faut savoir ce qu'on veut (ou ce que le client veut)...
Un soft pourri qui va faire chier les utilisateurs ou un soft qui améliore leur condition de travail et qui les rend plus productifs (je caricature, mais l'idée est là). C'est ça qu'on doit leur vendre à nos clients et qui justifie éventuellement une hausse du service.
Argument qui nous permettrer peut être également de concurrencer certains dev. délocalisés.

Ensuite t'es pas obliger de sortir l'équipe de choc sur tous les projets. Mais déjà juste un ergonome qui intervient en transverse sur les projets et tu augmentes sérieusement les chances d'acceptation de ton produit.

Effectivement tu en as de la chance, je suis dans une boite qui fait des contrats avec des banques, assurances et qui vend ses logiciels pour quelques dizaines de milliers d'euros la licence d'installation, et bah aucun graphiste a l'horizon, encore moins de sociologue ou autre.. 5 développeurs (meme pas sur les mêmes projets) et c'est tout !

Je travaille dans un environnement particulier en effet.
Ensuite il faudrait peut être revoir l'organisation des équipes et arrêter de penser que le développeur est capable de faire l'analyse des besoins, l'analyse technique, la conception, les dev. (de belles ihm intuitives, de beaux algos. performants,...), les tests, les install., la maintenance, tout ça en étant expert dans chaque phase.
Chacune de ces activités demande des compétences spécifiques et je doute qu'un seul métier puissent les regrouper...

[rock_4_ever]

Et pourquoi il aurait rentré le mois en 1er ???
On demande "Date de naissance" !!! "Je suis né en mars le 7 en 1978" c'est vrai que je répond ça généralement...

Même le pire des idots sait qu'il n'y a pas 31 mois et 12 jours par année...

[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.