Discussion :

[deathness]

Aucune idée, je suis l'utilisateur final.

Je perçois les utilisateurs comme des parasites hélas nécessaires

[Barsy]

pour moi l'utilisateur est un profane pas un idiot donc quand je développe mon application elle doit etre centrée utilisateur en intégrant les contrôles couramment utiliser et intégrant les habitudes des users mais aussi un peu d'évolutivité pour lui faire découvrir d'autres UIs simple mais sophistiquées
donc faut pas croire que c'est des idiots car il savent s'adapter le tout c'est d'associer originalité et simplicité

Et est-ce que tu leur mets de la ponctuation à tes utilisateurs finauds ?

(et non, il n'y a pas de fautes d'orthographe dans mon message )

[MiaowZedong]

Et est-ce que tu leur mets de la ponctuation à tes utilisateurs finauds ?

(et non, il n'y a pas de fautes d'orthographe dans mon message )

Il intégre les habitudes de ses utilisateurs. Ceux-ci sont aussi très friands de SMS

[sybil]

Moi a l'utilisateur final je lui donne le source code et qu'il se demmerde

[JL Fermantel]

Je suis stupéfait de lire ce genre d'ânerie à laquelle je pensais ne pas poster de commentaire. Un peu de modestie ne fait de mal à personne. J'étais un "idiot" et je me suis mis à développer depuis plus de 15 ans pour des besoins professionnels. Je me sens chaque jour un peu moins "idiot". L'intelligence est relative.

[I_believe_in_code]

"L'intelligence, on croit toujours en avoir assez, vu que c'est avec ça qu'on juge".

(Coluche)

[souviron34]

"La culture, c'est comme la confiture : moins on en a plus on l'étale"

Pierre Dac


Certains ont les chevilles enflées...

[gangsoleil]

L'experience m'a montre que l'utilisateur peut etre une catastrophe :

• Celui qui supprime tous les fichiers "*.dll" de son disque, car il n'a plus assez de place
• Celui qui tue le logiciel et t'appelle car il ne tourne plus
• Celui qui supprime les la memoire partagee de ton logiciel et qui t'appelle car le logiciel ne fonctionne plus
• Celui qui, avant meme de tester le logiciel, te demande s'il la couleur rouge n'est pas configurable, "car c'est trop rouge".
• ...

Tout ceci permet de faire de la programmation defensive : des logiciels qui s'auto-surveillent, qui ne plantent pas si tu leur arrache toutes leur dependances, dans lesquels le rouge est configurable (ainsi que les autres couleurs), et qui en plus fait ce qu'on lui demande.

[souviron34]

Tout ceci permet de faire de la programmation defensive : des logiciels qui s'auto-surveillent, qui ne plantent pas si tu leur arrache toutes leur dependances, dans lesquels le rouge est configurable (ainsi que les autres couleurs), et qui en plus fait ce qu'on lui demande.

Ce qui devrait simplement être une démarche parfaitement normale lorsqu'on développe...

Ce pourquoi je ne suis pas du tout d'accord avec ta première phrase :

L'experience m'a montre que l'utilisateur peut etre une catastrophe :

Je dirais :

L'experience m'a montre que le programmeur peut etre une catastrophe :

Car il (très souvent) juge que ses choix sont les bons, que tout le monde devrait savoir ça, et que si tu le sais pas et te comporte pas de manière responsable t'es qu'un pôv c.n...

Or, quand on construit une maison, on s'attend quand même à ce que, nonobstant l'usage d'un bulldozer, la maison reste debout si on plante 1 clou ou que on fasse un trou dans un mur, qu'on puisse changer la couleur des volets, ou ajouter un canapé dans une pièce sans avoir à aller demander à l'architecte ou au maçon...

Je pense donc au contraire que c'est le programmeur (dans son sens général d'informaticien) qui est une plaie pour ne pas penser systématiquement à faire des choses configurabes, robustes, et ne demandant pas à l'utilisateur de savoir comment faire du "béton anti-humidité" ou autre bébelle technologique...

De ce point de vue, les messages d'erreurs (qui se sont un petit peu améliorés) des "Fatal Exception 0x0000" ont été un exemple parfait de ce qui se passait dans la tête des programmeurs et était une aberration...

[gangsoleil]

quand on construit une maison, on s'attend quand même à ce que, nonobstant l'usage d'un bulldozer, la maison reste debout si on plante 1 clou ou que on fasse un trou dans un mur, qu'on puisse changer la couleur des volets, ou ajouter un canapé dans une pièce sans avoir à aller demander à l'architecte ou au maçon...

Tu as construit une belle maison, qui tient bien debout, et ne tombe pas si on fait des trous dans les murs.

Que fais-tu face a l'utilisateur qui te dit que la maison n'a pas resiste a l'ouverture d'une baie-vitree en facade a coup de masse, et que ta maison est vraiment pourrie ?
Nulle part il n'etait ecrit que ce mur etait necessaire a la maison, et pourtant il semblerait que si...

Qui a tort ? Le constructeur qui n'a pas mis des fers partout dans les murs pour qu'on puisse faire des ouvertures comme on veut, ou bien l'occupant qui n'a pas eu un usage "raisonnable" de la maison ??


Pour continuer le parallele, si les logiciels que j'ecris aujourd'hui etaient des maisons, ce seraient de merveilleux bunkers indestructibles, mais configurables, dans lesquels tu peux (presque) tous deplacer, casser, ou modifier, sans que cela ne pose de probleme ni ne supprime de fonctionnalites. Par exemple, ce soir, je deplace la cuisine au 2eme etage pour agrandir le salon. Comment ca il n'y a pas d'arrivee ni d'evacuation d'eau tous les 10cm ? Et je fais comment pour poser mon evier a 28,3 cm de la porte comme je veux le faire ?

C'est bien joli, mais il y a un moment ou l'utilisateur doit etre raisonnable, et ce n'est pas parce qu'il n'y a pas ecrit sur le micro-onde qu'il ne faut pas y faire secher le chat que c'est pour autant une bonne idee.

Lorsque je lance word, je ne m'attends pas a ce qu'il soit capable d'ouvrir des fichiers qui sont sur la clef USB qui est chez le voisin. Pourquoi est-ce que les utilisateurs de mes programmes pensent ca ?? Et surtout, pourquoi est-ce que je dois trouver une solution pour le faire ?

[Barsy]

Je suis d'accord avec gangsoleil. L'utilisateur se comporte parfois comme un bulldozer avec les logiciels mis à sa disposition.

Et puis quand on construit une maison, on part sur des plans et on construit conformément aux plans définis.
Alors qu'avec un logiciel, les plans sont sans cesse remis en cause durant toute la phase de développement.

[Kagukuk]

Je sais plus où su ce forum quelqu'un avais utiliser une métaphore assez parlante je trouve, il comparait la construction d'un logiciel avec celle d'un gratte-ciel.

Une fois que le gratte-ciel est finit on peut bien sur demander de changer la vitesse de l'ascenseur ou bien le réglage de l'interphone, par contre ça serait complètement abérant qu'on demande de rajouter un étage entre le 15ème et le 16 ème parceque vous comprenez mon bon Monsieur les besoins du client ont évolué......
Et si possible dans un délai maximum de 2 jours parce que ca doit pas être bien compliqué a faire quand même.

A bon entendeur

[el_slapper]

La métaphore n'a aucun sens. Bon, mon lien parle d'un Pont, mais c'est une problématique proche du building(les étages en moins). Un logiciel, c'est toujours expérimental.

Mais je suis d'accord avec souviron34 sur le principe(et tant pis pour les -1). C'est à nous de blinder nos codes. Anecdote :

En 2003, un jeune programmeur(moi) faisant de la maitenance sur des transactions des agents bancaires met en production une petite modification. La transaction fait planter 4 fois le serveur central dans la matinée. Après la 4ème relance, l'exploitation revient en arrière sur la livraison, puis passe un savon au programmeur.

Ledit programmeur passe 10 jours à scruter son programme, à lire les logs qui ne disent pas grand chose(et relivrer pour en avoir des plus précises n'est pas une option), puis comprend enfin : les utilisateurs faisaient n'importe quoi. Pour clôturer une carte bleue, il faut un numéro de motif. Il y en a un pour un changement de type de carte, un pour une carte abimée, et deux ou trois autres. La transaction proposait une liste déroulante, avec la liste exhaustive des codes autorisés. Les utilisateurs tapaient un code erroné à la main, négligeaient 2 messages d'insulte, et validaient leur clôture de carte malgré l'insulte encore affichée à l'écran. Et la petite modif faisait planter le serveur à ce moment là.

L'erreur a été corrigée. Comme auparavant, les gens peuvent à nouveau faire n'importe quoi, sans planter le serveur - et sans que leur clôture avec un motif inexistant ne soit prise en compte. Il est certes désagréable de bosser avec des gens qui n'en ont rien à foutre des message qu'on leur met. Mais il existent. Et, dans mon cas, ils mettaient un dawa pas possible. Donc, il faut blinder les applis contre les cons, parceque ce ne sont pas les seuls à être victime de leur propre incurie.

Un utilisateur raisonnable, ça existe, mais ça n'est pas la majorité du genre. Tous, à un moment ou à un autres, nous avons été des PEBKAC. Celà fait partie de notre métier de blinder nos applications pour limiter au maximum l'impact de ces erreurs.

@gangsoleil : la vérité, c'est qu'un utilisateur de maison la casse rarement à coups de masse, pour voir ce que ça fait. Un utilisateur de logiciel fait ça tout le temps. Donc, celà fait partie de nos contraintes. Point. Mal? Bien? Pas mon problème. C'est comme ça. Si il y a la moindre faiblesse, ils vont tout casser. Donc, on ne peut pas se permettre la moindre faiblesse.

[Bluedeep]

:

En 2003, un jeune programmeur(moi) faisant de la maitenance sur des transactions des agents bancaires met en production une petite modification. La transaction fait planter 4 fois le serveur central dans la matinée. Après la 4ème relance, l'exploitation revient en arrière sur la livraison, puis passe un savon au programmeur.

En l'espèce, le savon me semble plus mérité pour la recette qualité que pour le programmeur : en effet, on demande au programmeur de livrer un code "qui marche", et c'est normal; on peut lui demander aussi d'imaginer toutes les conneries potentielles des utilisateurs, pourquoi pas.
Mais le fait qu'un code fonctionnel mais pas totalement blindé passe en prod est clairement un défaut du service qualité , pas une erreur du programmeur.

[Bluedeep]

L'experience m'a montre que l'utilisateur peut etre une catastrophe :

• Celui qui supprime tous les fichiers "*.dll" de son disque, car il n'a plus assez de place
• Celui qui tue le logiciel et t'appelle car il ne tourne plus
• Celui qui supprime les la memoire partagee de ton logiciel et qui t'appelle car le logiciel ne fonctionne plus

.

Dans ces trois cas, ce n'est pas l'utilisateur la catastrophe, mais ceux qui s'occupent de l'administration système qui sont défaillants, pour avoir laissé ce genre de droits pour faire cela sur la station de travail.

[el_slapper]

En l'espèce, le savon me semble plus mérité pour la recette qualité que pour le programmeur : en effet, on demande au programmeur de livrer un code "qui marche", et c'est normal; on peut lui demander aussi d'imaginer toutes les conneries potentielles des utilisateurs, pourquoi pas.
Mais le fait qu'un code fonctionnel mais pas totalement blindé passe en prod est clairement un défaut du service qualité , pas une erreur du programmeur.

Il n'y avait pas de service qualité pour nous, à ce moment-là. Et en tant qu'ancien homologateur, et ayant fait moi-même ma propre homologation, j'aurais du y penser. Donc, je ne me plains pas pour avoir pris un savon(et j'ai mis 10 jours à y penser, en plus, c'est mal).

C'était d'ailleurs mon métier, en tant qu'homologateur : prendre la masse et taper, taper, taper partout en essayant de tout casser. Puis, en cas de rupture, faire un rapport détaillé complet de la masse utilisée, de la prise en main, de l'angle de frappe, etc... afin que les programmeurs sachent quoi blinder(parceque si on est pas précis, l'anomalie, elle revient).

[Logan Mauzaize]

Pas trop d'accord avec toi el_slapper.

Si je décide de tout casser, je le fais en mon âme et conscience, c'est-à-dire que j'en assume les conséquences.

Dans ton expérience, tu as affiché une notification dont l'utilisateur n'a eu que faire, mais tu as accepté (assumé ?) d'enregistrer sa saisie même si elle n'est pas valide. Le système derrière devait donc assumé qu'ils doivent traiter des données non valides. C'est bien ta faute ... Tu es permissif d'un côté mais pas de l'autre.

[gangsoleil]

Dans ces trois cas, ce n'est pas l'utilisateur la catastrophe, mais ceux qui s'occupent de l'administration système qui sont défaillants, pour avoir laissé ce genre de droits pour faire cela sur la station de travail.

Il ne s'agit pas de stations de travail, mais de serveurs en prod. Le client a les droits admin dessus, car c'est difficile de lui supprimer, vu que ce sont ses machines.

C'est à nous de blinder nos codes. [...]

Un utilisateur raisonnable, ça existe, mais ça n'est pas la majorité du genre. Tous, à un moment ou à un autres, nous avons été des PEBKAC. Celà fait partie de notre métier de blinder nos applications pour limiter au maximum l'impact de ces erreurs.

@gangsoleil : la vérité, c'est qu'un utilisateur de maison la casse rarement à coups de masse, pour voir ce que ça fait. Un utilisateur de logiciel fait ça tout le temps. Donc, celà fait partie de nos contraintes. Point. Mal? Bien? Pas mon problème. C'est comme ça. Si il y a la moindre faiblesse, ils vont tout casser. Donc, on ne peut pas se permettre la moindre faiblesse.

Je n'ai jamais dit que je n'avais pas fait d'erreurs debiles, je suis persuade que j'en fais encore. Simplement, lorsque j'ignore un message d'erreur et que ca ne marche pas, je m'insulte moi, pas le programmeur.

Oui, les logiciels corrects doivent aujourd'hui etre des forteresses de stabilite. Bien ou mal, c'est en partie notre probleme, car expliquer a l'utilisateur qu'on ne peut pas bien faire en 3 jours n'est aujourd'hui plus possible pour les commerciaux, qui repondent oui au client avant de dire a la technique de se demerder.

[el_slapper]

Pas trop d'accord avec toi el_slapper.

Si je décide de tout casser, je le fais en mon âme et conscience, c'est-à-dire que j'en assume les conséquences.

Dans ton expérience, tu as affiché une notification dont l'utilisateur n'a eu que faire, mais tu as accepté (assumé ?) d'enregistrer sa saisie même si elle n'est pas valide. Le système derrière devait donc assumé qu'ils doivent traiter des données non valides. C'est bien ta faute ... Tu es permissif d'un côté mais pas de l'autre.

En fait, je crois qu'on est d'accord(mais je n'ai pas tout dit). Le comportement AVANT ma modif était bien de ne pas planter si l'utilisateur validait un code erroné - juste de refuser proprement la validation. J'ai brisé(par un IF mal plaçé) ce comportement, je suis donc fautif.

Oui, les logiciels corrects doivent aujourd'hui etre des forteresses de stabilite. Bien ou mal, c'est en partie notre probleme, car expliquer a l'utilisateur qu'on ne peut pas bien faire en 3 jours n'est aujourd'hui plus possible pour les commerciaux, qui repondent oui au client avant de dire a la technique de se demerder.

Ca, c'est un autre problème. Les attentes déraisonnables(qui ne sont pas limitées aux commerciaux, même si ils sont effectivement coutumiers du fait), c'est, à mon sens, un autre problème. L'appli ne DOIT pas planter. Même si l'utilisateur la veut pour avant-hier sans faute. Si ça plante, pire sont les choses.

[souviron34]

Dans ton expérience, tu as affiché une notification dont l'utilisateur n'a eu que faire, mais tu as accepté (assumé ?) d'enregistrer sa saisie même si elle n'est pas valide.

Acceptes-tu qu'une voiture ne démarre pas si tu n'as pas soufflé dans l'éthylotest, mis ta ceinture, vérifié ue ton gosse est bien arrimé sur le si-ge arrière, que tous tes passagers ont bien mis leur ceinture, sans u'elle soit tournée, et que tu n'as personne à moins d'un mètre de la voiture ????

Et quand elle t'avertit, tu laisses le son branché tout le temps ???