Discussion :

[RegBas]

Sinon hormis les réactions qui me rappellent la cour de récré du type c'est pas moi c'est toi, c'est pas les utilisateurs c'est les développeurs qu'ils sont méchants, est ce que certains ont lu l'article ? Le mot "idiot" est mis là pour faire réagir mais de là à prendre ça au premier degré c'est d'un niveau ...

Je m'attendais à un débat plus intéressant du type
faut il mieux proposer des IHM très voire trop simplistes pour éviter les "erreurs de saisie ou autre" (ce que prônerait plutôt le blogueur) ?
des IHM doublées (mode simple / mode avancé) ?
des IHM qui satisfont le plus grand nombre mais qui peuvent amener un nombre certains de faux incidents (exemple de saisie de date cité plus haut par exemple, - mais attention ça n'est qu'un exemple aussi maladroit soit il -)
les fonctions "avancées" cachés dans le fin fond des menus ?

En somme, êtes vous plutôt pour les applicatifs très user-friendly (ce qui amène à des situations du type j'ai Photoshop 2042 => je suis infographiste) ou pas ?

[java2me2010]

à votre avis, quelles sont les types d'interfaces sont compréhensible par les utilisateurs finaux ?
Quelles sont les bibs les plus adéquates qu'on peut utiliser avec eclipse ?

[CapJack]

N'étant pas professionnel, je vais jouer le rôle du Candide. Utilisateur final avant tout, mais qui connaît un peu la programmation.

Selon moi, une interface idéale devrait être à deux niveaux : un premier niveau où toutes les tâches réalisées quotidiennement seraient immédiatement et clairement accessibles, sans que l'utilisateur doive se "prendre la tête", et un autre niveau accessible par ce qu'on voudra (bouton, menu, etc.) présentant les fonctionnalités plus rarement utilisées, ainsi que les options de personnalisation.

C'est un lieu commun, ce que j'écris là, mais pourtant, même dans les logiciels grand public, ce n'est pas toujours appliqué.

Maintenant, c'est un peu la philosophie des "Blue Ribbons" de Microsoft Office, et moi, les Blue Ribbons, je n'ai jamais pu m'y faire. Question de vieilles habitudes prises, aussi.

[DrHelmut]

CP: Si on prend l'option A on en a pour 2 semaines de boulot mais au premier bug on est coincé et y en a pour 5 semaines de réparation.
Si on prend l'option B on en a pour 4 semaines de dev mais on est tranquille derrière

Boss: J'ai pas de budget (Ce qui était faux car on avait vendu 8 semaines mais c'est trop tentant d'"empocher le differentiel"). On prend l'option A et on vendra une prestation de maintenance derrière

Mais si le CP est malin, la prochaine fois il ne proposera même pas l'option A... en SSII, en avant-vente, c'est pareil : y'a toujours un commercial prêt à couper le budget en deux pour gagner un projet et face à ça les CP doivent rester fermes, même si ce n'est pas toujours évident. (et gonfler leurs chiffrages futurs en conséquence :p)

Après, le problème final sera toujours le client : je n'ai jamais eu vent d'un appel d'offre ou la solution la moins chère n'a pas été retenue... après, si les commerciaux faisaient mieux leur boulot, on pourrait vendre des projets qui mettent en avant la qualité (et qui sont donc plus chers) en projetant que le coût d'exploitation et de maintenance à long terme est moindre...

On ouvre là la porte à un autre débat : comment faire de la qualité dans un environnement essentiellement porté sur le rendement à court terme ?

[popo]

J'ai passé pas mal de temps à lire les posts de chacun et ce que j'en ressors c'est que ceux qui s'offusquent de lire "considérer 90% des utilisateurs comme idiots" n'ont pas vraiment compris le message qui se cache derrière cette phrase.

Il ne s'agit pas de réellement dire que l'utilisateur est un crétin fini.
Il s'agit de dire qu'il faut prévoir qu'un utilisateur (avec des connaissance en informatique ou pas du tout), risque de faire quelque chose de stupide (sans forcément le faire exprès).

C'est le rôle d'un développeur d'essayer de limiter au maximum les erreurs de saisie ou les clics intempestifs. Pour cela, il n'a d'autre choix que d'avoir ce genre de raisonnement :

Bon alors, cette zone de texte, c'est la quantité. Cela signifie que l'utilisateur doit saisir des chiffres et uniquement des chiffres. Je ne suis pas à l'abri du mec qui va tabuler jusqu'à cette fameuse zone de saisie et manque de bol son doigt rippe et il appuie aussi sur le A. Pour éviter ça je vais mettre un composant qui n'accepte que des chiffre ou alors programmer ce comportement.

Même problème pour une date. Je ne vais pas m'amuser à demander à l'utilisateur de saisir une date, je vais placer un calendrier et mettre en forme la date par programme avant de l'insérer dans la DB (un calendrier ou bien trois combo suivant ce qui est le plus adapté). Remarque : en général, j'évite de mettre un calendrier dans une fenêtre et les combo dans une autre. Je trouve ça un peu perturbant.

Bref, je suis entièrement d'accord avec ce bloggeur : si je peux éviter au maximum les erreurs "que risquent de faire l'utilisateur", je le fait même si je dois passer plus de temps que prévu sur un projet. Cela évite par la suite d'avoir à faire une correction et toute la phase de test et de redistribution.

[kdmbella]

c'est pourquoi on parle aujourd'hui d'UI centré Utilisateur car au final c'est pour lui qu'on fait tout ce travail et ce que tu dis c'est ce qui est appliqué aujourdh'ui dans laplus par des Framework qui intègre la conception d'interface : tout est fait pour limiter au maximum les erreurs de saisie de l'utilisateur : date, contrôle d'email, grille, cliquer déposer ... voir par exemple cette bibliothèque Js : http://www.dhtmlx.com ou bien YUI (Yahoo User Interface).
Mais une autre chose: l'interface conçu doit certe être facile à prendre en main pour l'utilisateur final mais si elle peut améliorer ses connaissances le rendant "moins idiots" je pense que la oui on aura atteint l'objectif visé !

[philnext]

J'ai pris l'habitude de gérer des projets avec 3 principes :
1/ L'utilisateur est stupide
2/ Le client a toujours raison
3/ Le développeur est une grosse feignasse sans mémoire.
Bien évidemment aucun principe n'est vrai mais en fait ils servent de moyen mnémotechniques pour :
1/ Faire une interface simple, ergonomique et un soft fiable et robuste.
2/ Rappeler que pour les définitions fonctionnelles le 'métier' est connu par le client et pas par le CP ni par le développeur.
3/ Commencer par la doc puis les tests (+code coverage) & les commentaires ensuite le code.

[Phoquounet]

Je trouve que le plus idiot est de dire que les utilisateurs le sont.

Je ne suis pas d'accord avec ça. C'est comme si le boulanger se dit "je la fait cuire 10 ou 11 minute la baguette ?... Toute façon je m'en fout tout mes client sont des idiots et il ne verront pas la différence !"

Et je peut faire de cet exemple une généralité pour tout les métiers d'aujourd'hui.

Donc moi je dirait tout simplement que l'utilisateur lambda n'est pas plus idiot que n'importe qui d'autre, ni même que moi, et qu'il ne vois juste pas les chose comme nous et que ce qui parait évident pour certain ne l'est pas pour d'autre !

Donc je répondrais a l'homme (et tout ceux) qui pensent cela, que si ils voient leur clients comme des idiots, qu'ils n'ont qu'a faire un métier ou la satisfaction client ne compte pas, voir même un métier sans client. Bonne chance pour trouver ! Parce qu'aujourd'hui il y a, à mon avis, peu(ou pas) de travail qui ne sont pas fait pour servir un client qui ne sais pas faire ce dont il a besoin et qui donc, fait appel a vous !

Merci de votre attention.

[lepotager]

Certes se dire que l'utilisateur est un idiot et qu'on va donc faire son petit programme comme on le sent et qu'il n'y verra aucune différence est stupide, et l'est de plus en plus dans un monde ou l'informatique sera de plus en plus comprise (du moins en substance) par un nombre important d'utilisateurs.

Même si on a affaire à des "idiots", il peut être bon de se demander si on va créer un programme tournant pour un maximum d'idiots ayant tous un navigateur internet dont ils savent se servir ou s'il vaut mieux le réserver à un petit nombre d'idiots" possédant l'OS "Fenetres 7.0". Et bien entendu savoir si notre programme répondra mieux aux attentes des ces "idiots" dans un cas ou dans l'autre en fonction des fonctionnalités pouvant être proposées.

Dès lors, on se doit de consulter les idiots pour savoir ce qu'ils attendent de ce fabuleux programme que vous allez créer, avant de passer vous-même pour un idiot qui n'a rien compris à leurs attentes !

Mais... il y a un domaine où il faut les prendre IMPERATIVEMENT pour des idiots : partez du principe que l'utilisateur final sera toujours assez idiot pour rentrer une donnée non prévue (tu veux une nombre, voilà une lettre), cliquer partout où il ne faut pas et mettre sans dessus-dessous votre beau programme qui tournait si bien entre vos mains un peu trop expertes.

C'est la base d'un programme bien réalisé : prévoir le comportement irrationnel des ces "idiots", avoir la peur bleue de ce que leur esprit maléfique est capable d'engendrer au sein de votre beau code

Mais nous sommes tous l'idiot d'un autre

[fucce]

Les utilisateurs finaux ne sont pas des idiots mais pensent et agissent différemment des développeurs. Tout ce qui est différent est d'ailleurs enrichissant. Si je le pouvais (j'essaie un maximum...), j'exercerais la tâche de la personne pour m’imprègner du rôle de celui-ci. Je développe de petites IHM dans une entreprise agro et je peux vous dire que les remarques des utilisateurs sont en générale très constructives. J'ai d'ailleurs mis en place un cahier d'amélioration et de bugs sur chaque poste que je consulte régulièrement. Cela instaure un climat de confiance entre le service informatique et les ouvriers sur ligne.
Ce sont, de plus, des testeurs "hors normes". Je passe moins de temps à tester dans mon bureau mais mets plus rapidement une version bêta entre leurs mains.

[Abdellah2010]

lors du développement des applications, toutes les exceptions sont prises en compte, il faut bien tester son application (les champs textes, les types de données, les valeurs nulles..) ,car une petite erreur (qui n'est pas testée auparavant ) peut conduire aux mauvaises conséquences (incohérences de données par exemple) parfois irréversibles.Alors le développeur sent plus de responsabilité.

[fucce]

Je teste bien sûr le déroulement normal du programme. Ce que je veux dire c'est que je ne teste pas le déroulement anormal auquel je ne pense jamais (en tant que concepteur du programme). Je sensibilise bien les opérateurs pour leur dire qu'ils ont une version "bêta" et que celle-ci ne pourra que s'améliorer. De ce fait, ils s'intéressent à leur futur outil de travail en s'impliquant.

[NBBIZOU]

NON,
L' utilisateur n' est PAS un informaticien!!!
C' est à vous d' apprendre son travail.
J' ai une voiture et je ne comprends rien à la mécanique!J' explique le problème et il le résoud, c' est pas à moi de prendre la clef de huit!
Vous êtes là pour l' AIDER, pas pour vous faire plaisir.
30 ans de programmation avec des utilisateurs divers ça vous rends un peu humble.

[NBBIZOU]

Bon , j' en rajoute un peu...
Certains de mes utilisateurs un peu "IDIOTS", ont vu qu'ils devaient cliquer sur TROIS boutons( SCANNER, VERIFIER, VALIDER )
Ils m'ont demandé DEUX boutons : SCANNER, VALIDER oui mais c'est desCOTOREP
Je fais quoi? Je leur demande dans quel registre revient le code retour?
Nous avons tous ( les vieux ) étés confrontés à ce problème....
BIZ a tous les VIEUX

[yan]

Bon , j' en rajoute un peu...
Certains de mes utilisateurs un peu "IDIOTS", ont vu qu'ils devaient cliquer sur TROIS boutons( SCANNER, VERIFIER, VALIDER )
Ils m'ont demandé DEUX boutons : SCANNER, VALIDER oui mais c'est desCOTOREP
Je fais quoi? Je leur demande dans quel registre revient le code retour?
Nous avons tous ( les vieux ) étés confrontés à ce problème....
BIZ a tous les VIEUX

EN quoi regrouper scanner/Verifier est problématique??

[Pelote2012]

Perso, ici j'ai de tout.
- Un boss avec un super calculateur à la place du cerveau
- Des commerciaux qui veulent que l'informatique fassent tout leur boulot
- des secrétaire super sympa et super mignone mais aucune connaissance en informatique (normal c'est pas leur travail)
- des tech qui voudrait tous en ligne de commande
...
Développeur c'est un boulot entre tout le monde
Je vais toujours voir l'utilisateur final, je demande ses besoins
Je fais un premier jet, pour qu'il critique
Je fait valider par les supérieur
je finalise
Et SURTOUT j'essaie de tracer correctement les erreurs.
Je suis plutôt du type développeur en mode itératif : fonctions de bases, puis option 1 ....
Mais les utilisateurs finaux sont toujours plus malin, il y a toujours le Hic que personne n'a pensée.

Pour moi ce sont les joies du développeurs un peu le jeu du chat et de la souris

[atc666]

moi je dirai juste ceci :
j ai un mal de chien à créer un programme sans avoir de client . j ai des idées de soft a créer parfois , mais si je n ai pas un client qui connait bien son métier et qui m' explique ce qu'il attend de mon soft et ben je rame comme un con devant mon interface car je ne sais pas comment créer mes ihm ni les les fonctionnalités qui seront vraiment importante pour lui.
je suis indépendant , et je fait tout en solo.
et mon principe de base est :
seul l utilisateur sait vraiment ce dont il a besoin .
et mes utilisateurs ne seront pas toujours des super pro de leur métier .
donc je doit avant tout comprendre ce qu'il a dans sa tête . à partir de la je lui propose des petites choses qui vont souvent être plébiscitée par lui car j arrive a bien comprendre ce qu'il voulait. mais ce n'est possible que parce que je me dit que je suis le plus grand nul qui soit dans son métier
quand a tout vérifier et fermer des "options d erreur" ben c est bien le minimum a faire pour éviter toute erreur accidentelle.

[berceker united]

moi je dirai juste ceci :
j ai un mal de chien à créer un programme sans avoir de client . j ai des idées de soft a créer parfois , mais si je n ai pas un client qui connait bien son métier et qui m' explique ce qu'il attend de mon soft et ben je rame comme un con devant mon interface car je ne sais pas comment créer mes ihm ni les les fonctionnalités qui seront vraiment importante pour lui.
je suis indépendant , et je fait tout en solo.
et mon principe de base est :
seul l utilisateur sait vraiment ce dont il a besoin .
et mes utilisateurs ne seront pas toujours des super pro de leur métier .
donc je doit avant tout comprendre ce qu'il a dans sa tête . à partir de la je lui propose des petites choses qui vont souvent être plébiscitée par lui car j arrive a bien comprendre ce qu'il voulait. mais ce n'est possible que parce que je me dit que je suis le plus grand nul qui soit dans son métier
quand a tout vérifier et fermer des "options d erreur" ben c est bien le minimum a faire pour éviter toute erreur accidentelle.

Désolé, mais c'est pas souvent exacte . Il est parfois préférable de connaitre le domaine dans laquelle il travaille. Cela permet de bien comprendre ses besoin avec ses mots. Parce qu'entre ce qu'il dit et ce qu'il pense il peut y avoir une très grande différence et mener dans une direction opposée. Le client ne voit pas forcément très loin parce qu'il ne peut se projeter au de la d'une certaine limite. Il faut souvent faire une première démonstration de l'IHM proche de son métier ou besoin. De là, il sera ou aller.
C'est compliqué mais il faut souvent anticiper/comprendre le besoin.

[Pelote2012]

Tout à fait berceker united

Avoir des idées de soft, cool, mais il serait sage d'aller voir avant le lancement le client final visé. Au mieux, tu peux faire une ébauche pour discuter avec le client, mais sas aller trop loin.
Si le produit ne lui plaît pas, tu risque de fermer une porte et toi tu seras démoralisé d'avoir bien bossé tout se temps (où tu n'as pas été payé) pour rien car tu ne vendras pas ton appli.
Le raisonnement vaux aussi pour les développeur internes à une entreprise.

Faire un mini projet pour base de discussion ok, mais il ne faut pas trop s'emballer (ça c'est très dur quand on est perfectionniste comme moi)
Puis Voir l'utilisateur final, voir ses besoins pour coller au plus proche de ce qu'il veut (là il faut arriver à le comprendre, généralement c'est son chef qui fait l'interprète )

[curt]

L'utilisateur est au centre de l'application.
Il appartient au développeur de connaître le métier de l'utilisateur final s'il veut réaliser une IHM au plus juste.

L'Interface Homme Machine sert réellement de passerelle entre les besoins (et les attentes) de l'utilisateur et les impératifs/contrainte du développeur.

Pour tester : laisser seul pendant 15mn un utilisateur face à votre application. Si d'instinct il parvient à se débrouiller, vous aurez gagné (il faudra compléter par une [in]formatin).

Si vous avez fait une usine à gaz, vous le saurez en 15mn chrono !!!

Curt