Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

Quelles idées avez-vous de l'utilisateur final lors du développement d'une application


Sujet :

Débats sur le développement - Le Best Of

  1. #81
    Membre éprouvé
    Citation Envoyé par Jon Shannow Voir le message
    Je suppose que, toi-même, tu utilises des logiciels, donc tu te considères comme une bille, c'est ça ?
    Je considère que tout logiciel destiné a des non informaticiens doit être conçu avec comme idée "l'utilisateur est une bille".

    Et j'attend d'un logiciel non technique de ne pas m'imposer de compétence technique relative à son utilisation.

    J'ai remarqué dans l'informatique une certaine tendance des devs à se dire que tout les gens doivent savoir ce qu'est un masque de réseau ou une regex.

    Si j'étais un garagiste, je me ferais un plaisir de te saboter tes freins et de te dire "mouarf, c'est super simple à faire ça, tu dois te débrouiller!"

    PS: Je suis moi même développeur (diplômé et en poste).
    Si vous moinsez, merci de répondre pour argumenter!
    Ma présentation

  2. #82
    Membre chevronné
    Citation Envoyé par Squisqui Voir le message
    L'informatique n'a rien de vital...
    On ne peut pas en vouloir à des gens de préférer utiliser un client mail comme Outlook/Thunderbird, plutôt que de les gérer à coup de "fetchmail" et autres "mail -s" etc...
    Les gens veulent lire/envoyer leurs mails. Ça leur ferait une belle jambe de connaitre un protocole comme SMTP
    Je suis d'accord que l'informatique n'est pas vitale.
    Cependant sans tomber dans l'excès et demander aux utilisateurs d'envoyer leurs mails avec les touches 0 et 1 on peut voir des cas aberrants.
    Pour reprendre ton exemple, 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 !!
    Si tu ne sais pas faire, apprends. Si tu fais, fais bien. Si tu sais bien faire, enseigne.
    Mieux vaut paraître stupide quelques temps que rester stupide toute sa vie.

  3. #83
    Membre chevronné
    Citation Envoyé par YannPeniguel Voir le message

    Si j'étais un garagiste, je me ferais un plaisir de te saboter tes freins et de te dire "mouarf, c'est super simple à faire ça, tu dois te débrouiller!"

    PS: Je suis moi même développeur (diplômé et en poste).
    Du coup je suis très heureux que tu sois développeur
    Si tu ne sais pas faire, apprends. Si tu fais, fais bien. Si tu sais bien faire, enseigne.
    Mieux vaut paraître stupide quelques temps que rester stupide toute sa vie.

  4. #84
    En attente de confirmation mail
    Citation Envoyé par zeyr2mejetrem Voir le message
    Pour reprendre ton exemple, 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 !!
    Maintenant que le soft est simplifié à l'extrême et prend largement la main de l'utilisateur pour le guider, ce n'est plus vraiment un problème lié à l'informatique. Le développeur ne peut plus rien y faire. Il a fait sa part de boulot en masquant toutes les tâches ingrates et surtout en masquant toutes les connaissances nécessaires pour gérer des mails.
    On peut se demander alors quelle est la frontière entre un soft intuitif ou pas... Dans ce cas, si l'utilisateur arrive a trouver le bouton pour se faire du café, je ne vois pas pourquoi il aurait plus de mal à appuyer sur un gros bouton "envoyer". Les emploies "presse-bouton" ne demande pas d'avoir un Bac après tout...
    On peut faire le rapprochement entre un client mail et La Poste. Les étapes sont identiques et même moins nombreuses (on ne met pas le mail dans une enveloppe). La différence est infime entre un client mail et La Poste. Si le bouton "envoyer" est aussi voyant que tu le prétends (je ne te remets pas en cause) et que l'utilisateur veuille réellement envoyer un mail, l'utilisateur n'a pas vraiment besoin d'un cours d'informatique, mais d'un opticien.
    Si le développement nécessite de considérer fictivement 90% des utilisateurs comme des idiots. La réalité contient tout de même un certain pourcentage bien présent

    Ça me rappelle l'éternel débat sur la baisse de difficulté dans les jeux vidéos où les jeux d'aujourd'hui sont bourrés de didacticiel du début à la fin alors qu'ils ne sont ni destinés aux casuals, ni aux enfants. Les joueurs sont devenus idiots ou les jeux sont devenus difficiles à prendre en main ?

  5. #85
    Membre éclairé
    Citation Envoyé par Squisqui Voir le message
    L'informatique n'a rien de vital...
    On ne peut pas en vouloir à des gens de préférer utiliser un client mail comme Outlook/Thunderbird, plutôt que de les gérer à coup de "fetchmail" et autres "mail -s" etc...
    Les gens veulent lire/envoyer leurs mails. Ça leur ferait une belle jambe de connaitre un protocole comme SMTP
    Je ne comprend pas ton message. Utiliser Thunderbird, c'est aussi de l'informatique.

  6. #86
    Membre éprouvé
    Je pense que la phrase

    "90% des utilisateurs sont des idiots" prends pleinement son sens lorsqu'on lit l'article original. Pour résumer, ce n'est pas du mépris de l'utilisateur, mais c'est simplement pour dire :

    Pas la peine de se prendre la tete sur des détails que l'utilisateur ne remarquera pas, et mieux vaux se contenter de garder l'IHM la plus "stupide possible". En gros, un gros bouton vert la ou il faut cliquer.


    Maintenant, les "utilisateurs" en général souffrent d'un manque cruel et flagrant de culture générale en informatique.
    Je ne sais peut etre pas bricoler les freins de ma voiture, mais je sais au moins a quoi ils servent. Et pas mal de gens savent a peu près comment changer une roue.

    Donc il ne faut pas confondre méconnaissance de l'informatique (ne pas tout connaitre, ne pas etre expert) et non-connaissance totale, ou les utilisateurs savent a peine se servir de la souris, cliquent n'importe ou sans rien savoir et sans chercher a savoir :
    Moi: - Vous avez cliqué ou ?
    User: - Euh... aucune idée.
    M: - Mais vous n'avez pas lu ?
    U: - Bin non.
    M: - Et si le bouton disait "Tout supprimer" ?
    U: - Euh...
    M: - ...
    U: - De toute facon, c'est mal fait ! Ca ne marche pas !
    La je ne parle pas de chercher a savoir dans le domaine de l'informatique, bien sur que l'utilisateur n'a pas besoin de connaitre les réels détails de ce qu'il fait. Mais beaucoup ne cherchent jamais a comprendre ce qu'ils font.

    Faites l'experience : Au détour d'une application, mettez ce menu :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    Cliquez ici pour continuer (recommandé)   |   Ne cliquez pas ici, ca va tout supprimer /!\
    Bon, celui la est un peu "obvious", mais il y en a quand meme qui cliquerons sur la 2eme option.

    Donc ce n'est pas tout de faire des IHM évidente, il faut aussi expliquer a l'utilisateur que, quand on utilise une appliation, il faut lire ce qui est marqué (et nous, il faut nous expliquer de pas mettre n'importe quoi dans les messages, et que ca soit compréhensible).

    The magic of Opera, La magie de l'Opera
    The mysteries of Space Opera, Les mystères de l'Opera Spatial
    Mr. Know-it-all, M. Je-Sais-Tout
    Prelude in C sharp minor, the most beautiful piano song and the best C sharp prelude ever, Prélude en do dièse mineur, le plus beau morceau de piano et le meilleur prélude au C#
    The Mesmerizing Saphir Division for Nerds, L'Hypnotisante Division Saphire pour les Nerds (HDSN)

  7. #87
    Membre éclairé
    Il y a aussi ceux à qui on dit d'écrire "/chemin/vers/ton/fichier.txt"... et qui le font vraiment.

  8. #88
    Membre expert
    L'utilisateur final n'est pas idiot car il aura toujours le recul nécessaire sur ton programme pour y trouver la faille qui tue, le truc que son inexpérience va amener là où tu ne pensais pas. Du coup, il vaut mieux anticiper son comportement et le prendre pour un idiot.
    "Ils ne savaient pas que c'était impossible alors ils l'ont fait." Mark Twain

    Mon client Twitter Qt cross-platform Windows et Linux. (en cours de développement).

  9. #89
    Membre actif
    quand je conçois une appli je part du principe que :

    Si un con peut l'utiliser, quelqu'un de formé et compétent le pourra aussi !

    Idem pour les exception, pas pour rien que les tests de fuzzing existent ^^
    Faut se dire que si le programme veut un nombre, il y aura toujours quelqu'un qui mettra une lettre, même sans le faire exprès.
    Je pense qu'il ne faut jamais faire porter le bon déroulement de l'application sur les épaules du end user.
    (C'est un peut la philo de microsoft avec le ruban qui rend certains fonctions assez complexe a la porté du premier venu)
    .Net... What else ?
    Mon blog sur .Net

  10. #90
    Membre éprouvé
    Bonjour,
    90% des utilisateurs sont des idiots vu du coté des utilisateurs 90% des informaticiens sont des idiots car ils ne comprennent rien à leurs besoins.

    en fait d'un coté un informaticien qui aime se faire plaisir en mettant des IHM joli mais pas fonctionnels et de l'autre un utilisateur qui ne retrouve pas ce dont il a besoin et qui devient un spécialiste d'Excel.

    Mais je remercie tout de meme ces informaticiens qui ont réussi à me permettre de créer ma boite avec on logiciel utilisant ACCESS pour l'IHM.

  11. #91
    Rédacteur

    Quelles idées avez-vous de l'utilisateur final lorsque vous concevez vos applications pour l'adapter à ses besoins ?
    Mon idée c'est que c'est lui qui va utiliser mon application.

    Et que si ca ne lui plait pas, pour une raison ou une autre, c'est que je n'ai pas réussi ma mission... Ou alors c'est que mon application n'est pas celle qu'il devrait utiliser.

    Dans les deux cas, c'est un échec de ma part : soit de ma compréhension de son problème, soit dans l'explication des usages de mon application.
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  12. #92
    Expert éminent sénior


    Un très gros +1000



    Quand je lis des trucs dans le style :


    Citation Envoyé par cs_ntd Voir le message

    Pas la peine de se prendre la tete sur des détails que l'utilisateur ne remarquera pas, et mieux vaux se contenter de garder l'IHM la plus "stupide possible".
    ...

    Maintenant, les "utilisateurs" en général souffrent d'un manque cruel et flagrant de culture générale en informatique.
    je pleure !!!

    Et je me dis que, malgré (à cause ?) des cours / formations, y'a encore un sacré bout de chemin à faire ....


    @cs_ntd : ce n'est pas que "l'utilisateur ne remarquera pas", c'est simplement que dans son utilisation, à cet endroit de son utilisation, il n'en a pas besoin.. Point barre...


    Crois-tu qu'un pilote d'avion, sur son écran de contrôle, a autre chose que les indications qui lui servent à piloter, plus un bouton qui dit simplement "ERREUR DANS LOGICIEL" ????

    Pareil pour les trucs médicaux...

    Le but d'un toubib ou d'une infirmière n'est pas de bien utiliser l'outil informatique, mais de soigner des gens.. Si l'outil lui complexifie la tâche au lieu de la simplifiier, il DOIT s'en passer...

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

    (pour mémoire, le pilote qui a posé son avion sur l'Hudson, il l'a fait en mode manuel, en ayant tout débranché... Le pilote automatique lui disait qu'il allait à la catastrophe... )
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  13. #93
    Membre éprouvé
    Citation Envoyé par air-dex
    L'utilisateur final n'est pas idiot car il aura toujours le recul nécessaire sur ton programme pour y trouver la faille qui tue, le truc que son inexpérience va amener là où tu ne pensais pas. Du coup, il vaut mieux anticiper son comportement et le prendre pour un idiot.
    Ah non, pas du tout "il vaut mieux" : il faut absolument, c'est ça, le boulot du programmeur !
    Citation Envoyé par pseudocode
    Et que si ca ne lui plait pas, pour une raison ou une autre, c'est que je n'ai pas réussi ma mission... Ou alors c'est que mon application n'est pas celle qu'il devrait utiliser.
    Ouf, merci ! Si seulement tout le monde pensait la même chose...
    Citation Envoyé par souviron34
    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...
    Ce serait bien si ça ne traduisait que la différence entre un programmeur débutant, sans expérience et qui a encore beaucoup à apprendre dans le monde du travail, et un programmeur expérimenté et qui connait bien son rôle et les réactions habituelles des utilisateurs moyens, normaux et habituels d'une application quelconque. Mais je me dis qu'il existe des anciens qui réagissent comme étant de la première catégorie, c'est bien dommage !
    L'avis publié ci-dessus est mien et ne reflète pas obligatoirement celui de mon entreprise.

  14. #94
    Membre habitué
    Citation Envoyé par ProgVal Voir le message
    Je ne comprend pas ton message. Utiliser Thunderbird, c'est aussi de l'informatique.
    pas d'accord : c'est de la bureautique.

    Sinon, cela revient à dire qu'utiliser un ordinateur c'est faire de l'informatique...


    Citation Envoyé par Thorna Voir le message
    Ah non, pas du tout "il vaut mieux" : il faut absolument, c'est ça, le boulot du programmeur !
    Disons plutôt "autant que faire se peut" car on ne peut jamais absolument tout anticiper (soyons réalistes)

  15. #95
    Membre averti
    Citation Envoyé par DrHelmut Voir le message
    pas d'accord : c'est de la bureautique.
    La bureautique, c'est aussi de l'informatique. Et à la base, thunderbird, c'est un programme, fait par des développeurs...

    Dans tous les cas, il vaut mieux créer son programme en pensant que l'utilisateur final est un parfait crétin, incapable de se débrouiller, que de miser sur son intelligence, et aller au devant de graves déconvenues.

  16. #96
    Membre extrêmement actif
    Citation Envoyé par YannPeniguel Voir le message
    Je considère que tout logiciel destiné a des non informaticiens doit être conçu avec comme idée "l'utilisateur est une bille".
    Ou plutôt "l'utilisateur n'en a rien a pété de l'informatique pour l'informatique, lui il veut un outil qui fasse mieux et plus vite, ce qu'il faisait très bien sans !"

    Surtout, que lui, il se dit "Pffff ! Ces informaticiens, ils ne comprennent rien, ils va encore falloir tout leur expliquer, et c'est même pas sûr que ces c**s arrivent à nous faire un truc correct !"
    Au nom du pèze, du fisc et du St Estephe
    Au nom du fric, on baisse son froc...

  17. #97
    Membre actif
    Les deux bonnes idées qui se cachent derrière le "90% des utilisateurs n'y comprennent rien" c'est qu'on écris des logiciels qui demandent le moins de prérquis possible d'une part d'autre par on ne va pas aller embrouiller l'utilisateur avec des aspects qui ne l'intèresse pas ("Tiens utilisateur je ne fonctionne pas parce que NullPointerException, t'es heureux de le savoir n'est ce pas ?").

    Ce qu'il faut c'est que ça n'empiète pas sur l'utilisabilité des utilisateurs expérimentés (par exemple éviter d'avoir 1500 boites de confirmation).

  18. #98
    Membre éclairé
    Citation Envoyé par barmic Voir le message
    "Tiens utilisateur je ne fonctionne pas parce que NullPointerException, t'es heureux de le savoir n'est ce pas ?"
    Deux solutions pour remédier à ce problème : déboguer, ou remplacer le message par "erreur interne"
    En théorie, on utilise déjà la première solution. Quant à la deuxième, elle est pire que le "mal".

  19. #99
    Membre chevronné
    Citation Envoyé par ProgVal Voir le message
    Deux solutions pour remédier à ce problème : déboguer, ou remplacer le message par "erreur interne"
    En théorie, on utilise déjà la première solution. Quant à la deuxième, elle est pire que le "mal".
    Ou tu remplaces par un joli écran bleu avec un message du type "Erreur 0x0024563553"

    Sérieusement, je fais maintenant partie des réalistes qui pensent qu'il n'est pas toujours possible de débugguer une appli à 100% en condition réelle.
    Du coup j'opte pour une vraie gestion d'exception avec un message en bon francais et une option d'alerte pour récupérer les messages techniques sur serveur central avec remerciement pour l'utilisateur qui nous envoie les infos.

    Cela permet de ne pas (ou moins) faire peur à l'utilisateur, de savoir quels sont les bugs les plus fréquents pour pouvoir les résoudre en priorité et de donner de l'importance à l'utilisateur en lui faisant sentir "qu'il fait partie de l'équipe"

    Après on se rend bien sûr compte que seul 1 utilisateur sur 3 joue le jeu ...
    Si tu ne sais pas faire, apprends. Si tu fais, fais bien. Si tu sais bien faire, enseigne.
    Mieux vaut paraître stupide quelques temps que rester stupide toute sa vie.

  20. #100
    Membre éclairé
    Citation Envoyé par zeyr2mejetrem Voir le message
    Après on se rend bien sûr compte que seul 1 utilisateur sur 3 joue le jeu ...
    C'est déjà un très bon score.

###raw>template_hook.ano_emploi###