Journal L'ergonomie en voilà un sacré mot...

Posté par  .
Étiquettes :
0
17
jan.
2005
Bonjour,

j'ai eu quelques cours l'an dernier sur l'ergonomie l'an dernier ainsi que quelques remarques cette année. N'ayant pas comprit dans certains cas pourquoi certains choix étaient plus ergonomiques je me suis tout naturellement tourné vers le journal pour trouver une solution :)

Par exemple, lors de la réalisation d'une application web , nous avions plusieurs liens sur une page, ainsi qu'un bouton pour envoyer un formulaire. La remarque suivante a été formulée : "il serait préférable de n'avoir que des liens ou que des boutons mais pas les deux". Pour ma part, il me parait logique d'utiliser un bouton pour soumettre un formulaire et si la balise input de type submit existe c'est qu'il y'a bien une raison ou bien ?

Sinon, nous avions réalisé une interface avec des onglets un peu comme à la Yahoo, avec des couleurs différentes lorsque l'on clique sur ceux-ci. "Il serait préférable d'avoir une seule couleur" nous
a t'on dit... Alors là je ne voit pas du tout, peut-être que les
utilisateurs sont considérés comme des personnes stupides se perdant quand la couleur change, personnellement je ne vois pas.

Une autre fois (c'est le dernier exemple c'est promis), nous avions réalisé un site, la taille de la police était à peu près la même que sur linuxfr et on a eu comme remarques que celle-ci pourrait être plus
grande car cela rendra bien plus lisible... Faites voir deux fois CTRL+ dans votre Mozilla/Firefox et dites moi si c'est plus lisible... en tout cas c'est sérieusement moche.

Je sais que je n'ai pas la science infuse et que l'on défend en général ce que l'on apprécie, mais j'aimerais quand même des explications :)

  • # Source?

    Posté par  . Évalué à 8.

    Ca serait super intéressant de savoir dans quel genre de formation tu as ces cours-là.

    Sinon, c'est vrai que ça fait un peu magie noire, mais il existe des études sérieuses (et assez scientifiques) sur le sujet, à base d'optimisation des mouvements des mains, par exemple.

    En revanche, ceux pour qui l'ergonomie représente la facilité avec laquelle un néophyte appréhendera la plateforme... comment dire...

    • [^] # Re: Source?

      Posté par  . Évalué à 4.

      La formation dans laquelle j'ai ces cours est un DUT Informatique.
      Et sinon on deux trois profs vraiment calé là-dedans à l'IUT (ceux qui nous on fait les cours), mais je préfèrerait avoir un avis externe :p

      • [^] # Re: Source?

        Posté par  . Évalué à 10.

        En soi, je n'ai qu'une seule chose à dire : C'est excellent. Tu ne le sais peut-être pas encore, mais très rares sont les formations d'informatique dans lesquelles on met l'accent sur ce genre de choses, et pourtant Dieu sait si c'est important car les outils que l'élève sera amené à développer dans sa carrière seront utilisés par beaucoup de gens pendant beaucoup de temps, et souvent contre leur gré. Il est donc primordial de faire quelque chose de propre, intuitif et agréable à utiliser.

        Si tes profs t'ennuient avec leur boutons ou leur liens, mappe une image sur tes boutons ou bien applique-leur une feuille de style pour les faire apparaître comme des boîtes plutôt que comme les boutons de ton système d'exploitation. Personnellement, je trouve que le seul avantage à cela est la conservation d'une certaine harmonie avec le reste du document, mais cela brise les principes sémantiques du Web. Si c'est un bouton, cela doit ressembler à un bouton, point.

        Par contre, un document qui eût beaucoup de succès en son temps est le « Interface Hall of Shame ». Il a déjà cinq ans, il n'est accessible que par la Wayback Machine, mais décrit assez bien les pièges que l'on peut rencontrer lorsque l'on construit une interface.

        C'est par ici :
        http://web.archive.org/web/20001005062147/www.iarchitect.com/mshame(...)

  • # Le bon goût...

    Posté par  . Évalué à 2.

    Je crois que c'est ça la solution pour l'ergonomie!
    J'aime arriver sur un site et avoir une impression d'homogénéité, c'est à dire ne pas voir toutes sortes de composants, aucune logique dans les occurrences de ces composants, etc...
    Pire, un site avec du texte de toutes les couleurs, ca fait carnaval, non, non, c'est pas sérieux ça!
    Finalement, ne pas oublier de "remplir" le site, d'une manière ou d'une autre, soit du contenu, soit par la forme.

    Je pense que tu as compris que je suis totalement avec les remarques qu'on t'a fait. C'est sur qu'après, faut voir à quelle occasion on t'a fait ces remarques, tu as certainement fait du très bon boulot de ton côté ;) .

    • [^] # Re: Le bon goût...

      Posté par  . Évalué à 4.

      Personnellement je suis tout à fait d'accord qu'il ne faille pas mélanger les composants, ça Ok, cependant un formulaire ca s'envoit par un bouton et pas en faisant un lien hypertexte qui oblige en plus à utiliser du javascript... je trouve pas ça top comme solution du top et pas ergonomique non plus enfin bon c'ets mon avis :)

      • [^] # Re: Le bon goût...

        Posté par  . Évalué à 5.

        et puis surtout ce n'est pas la même chose : un formulaire envoie des données, pas un lien. C'est donc normal de différencier visuellement les deux composants. C'est vouloir berner l'utilisateur que de déguiser un bouton de soumission de formulaire en lien hypertexte, c'est irrespectueux, fatiguant à l'utilisation et perturbant (un même type d'action donnant deux types de résultats différents).

    • [^] # Re: Le bon goût...

      Posté par  . Évalué à 5.

      En fait, le bon goût ne fait pas tout. Avoir du goût (s'il est bon, c'est encore mieux) est essentiel pour produire quelque-chose de beau. L'ergonomie, elle mesure "combien" quelque-chose est pratique, adapté.

      Il y a réellement des choses qui peuvent se mesurer, quant à l'ergonomie d'une application ou d'une interface: la distance moyenne à parcourir à la souris pour une utilisation normale, l'accessibilité de tel ou tel composant (il est plus facile de viser un bord d'écran qu'un truc en plein milieu, et il est plus facile de viser un coin qu'un bord), le temps passé par l'utilisateur à attendre que sa machine lui rendre la main, etc.

      On peut également rajouter une composante psychologique à la réflexion (il paraît - et on l'a beaucoup dit à une époque - que l'utilisateur n'aime pas avoir une fenêtre qui se bloque pendant un traitement, et qu'une simple progressbar l'aide à patienter).

      La cohérence d'un ensemble de rêgles d'interface utilisateur (les fameuses "UI guidelines" chères au projet Gnome) d'une application à l'autre peut aussi entrer en ligne de compte, si l'on considère que le système sera fait pour utiliser de nombreuses applications. Ça sera moins primordial, assez logiquement, dans le cas d'une application quasi-unique (exemple type: l'ordinateur du guichetier, à la banque).

      En fait, la seule partie qui est - éventuellement - subjective, c'est le poids à apporter à chaque critère objectif. Comme souvent.

  • # Commentaire supprimé

    Posté par  . Évalué à 0.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 7.

      Ce commentaire a été supprimé par l’équipe de modération.

  • # mouais

    Posté par  (site web personnel) . Évalué à 4.

    Note que j'ai effectivement des pbs de lecture sur les sites comme linuxfr (oh, je lis très bien mais ça n'aide pas à me concentrer ni à lire longtemps). Ca ne fait pas joli ? faut savoir si le texte est fait pour être joli ou être lu.
    Certes on peut zoomer, mais on voit bien que ceux qui disent ça n'en ont que rarement besoin. Zoomer et dézoomer dès qu'on clique quelque part c'est *très* vite lourd.
    Perso je suis geek donc je modifie les CSS, mais ce n'est pas le cas de tout le monde. Puis il y a ceux qui ne s'en rendent pas compte mais qui vont sur le site du concurrent parce qu'il est "plus agréable" sans savoir dire en quoi exactement, ou ceux qui ne reviennent pas souvent parce que ça leur a été désagrable ou peu confortable, sans savoir pourquoi non plus.

    Pour les couleurs il faut voir, là sans les fichiers c'est dur de te dire si il a abusé ou pas. Mais globalement c'est vrai qu'on évite de mettre trop de couleurs dans les objets d'interface, ça complexifie l'interface et ça se sent à l'utilisation courante (le fait que les menus et ce genre de choses soient grises ou d'une couleur neutre dans la plupart des interface n'est pas un hasard)

  • # Un site qui pourrait intéresser

    Posté par  . Évalué à 10.

    En parcourant le site de Joël Spolsky, je suis tombé sur une véritable mine d'or d'articles sur une grande variété de sujets touchant à l'ingénerie logicielle:

    http://www.joelonsoftware.com/navLinks/fog0000000247.html(...)

    Entre autres, il met à disposition en ligne une version condensée d'un livre qu'il a écrit sur la conception d'interfaces utilisateur (premiers liens des archives), ou il expose des problèmes classiques d'ergonomie d'interface et donne des solutions.

    Entre autres et de tête, on y retrouve le principe "Si c'est un bouton, ca doit ressembler à un bouton" évoqué par Robin des Bulles, l'histoire de la "mile high bar" d'Apple et de l'application ratée qu'en a fait Microsoft dans windows 95. L'auteur travaille beaucoup à partir d'exemples de ses expériences professionelles, et je trouve que ca rend la lecture beaucoup plus agréable qu'une liste de concepts abstraits.

    Je ne sais pas si c'est exactement ce que tu cherches, mais en tout cas il y a de bonnes indications générales sur la conception d'interfaces qui ne donnent pas des furoncles aux gens qui essayent de s'en servir, c'est un bon départ ;)

    Et pour les autres, tous les articles de Joël sont un vrai plaisir à parcourir, autant du point de vue du style littéraire que du contenu d'information. Je vous les recommande vivement!

    - David

  • # ergonomie et code

    Posté par  (site web personnel) . Évalué à 6.

    l'ergonomie est à l'accessibilité ( au sens humain ) ce que les coding rules sont à la programmation : un truc astreignant au départ, mais assez utile rapidement.

    la notion sous jacente à l'ergonomie et aux coding rules est la notion de sémantique du langage.

    quand tu concois une interface, tu souhaite communiquer une information de maniere spaciale ( dans notre cas notre espace est plutot planplan ;) ).

    ton interface va donc développer une sémantique propre pour signifier le sens d'une zone. par exemple :
    - deux fleches hemicirculaire formant un cercle
    - un panneau avec une croix au milieu
    - un bouton vert et un bouton rouge
    - un ensemble de 4 barre verticale de plus en plus grande qui s'allume de la plus petite à la plus grande
    - une bouée

    ces "mots" graphiques ont un sens et je les comprend juste en ayant joué avec.

    l'accessibilité d'un langage que ce soit une interface graphique ou un code source repose sur la cohérence de la sémantique employé et de la manière dont elle s'auto-coordonne donc de sa grammaire.

    google me semble etre un tres bon exemple au niveau ergonomie :
    - une interface sobre, claire et toujours cohérente quelque soit le service

    la sémantique colorimetrique de google est à mon sens :
    - rouge : "ici & maintenant/conseil"
    - bleu : "alternatives/liens"
    - vert : "communication/blabla/promo"
    - orange : "a la suite/ailleurs"

    mes noms ne sont pas clair, mais c l'idee que je retiens de google. par contre, comme toute règle, elle a ses exceptions aussi chez google ;)

    il n'y a pas de regle en ergonomie, il n'y a que des sentiments de confort simple à apporter à l'utilisateur pour le garder, cela passe par une maquette et son travail pour qu'elle devienne "user-friendly" :)

    pour conclure, "python suxor car on doit indenter le code" ;)

    • [^] # Re: ergonomie et code

      Posté par  . Évalué à 7.

      Je répond à ton message, mais j'aurais pu répondre à n'importe quel message au dessus. Pour moi le gros problème c'est que la notion d'ergonomie dépend de la "culture" de chaque personne.

      Par exemple, c'est évident que les développeurs sont surement les personnes les moins aptes à réaliser une interface ergonomique pour le commun des mortels :). Je m'explique, on nous a appris à toujours développer par métaphore, à chercher de rapprocher nos problèmes de conception naturelle (ou du moins quotidienne). Le problème c'est qu'on finit par dénaturer le sens premier de nos métaphores, et ça ne devient compréhensible que pour des gens étant déjà immergé dans notre monde.

      Pour vous en convaincre, rappelez vous de votre dernière discussion sur l'informatique (et surtout de développement) avec un ami ni connaissant pas grand chose pour lui expliquer ce qu'est exactement votre boulot. Je suis presque sûr que vous avez eu du mal à expliquer facilement ce que vous faisiez, votre interlocuteur n'avait surement pas le même vocabulaire et avait du mal à cerner votre monde. Maintenant, le problème pour votre ami, c'est que les gars qui développent les outils qu'il va utiliser c'est justement des gens comme vous :). Bref, il va venir à l'informatique avec ses connaissances et va être surement pommé le temps d'assimiler notre façon de penser (qui est peut être la meilleure en fin de compte).

      De plus, ce qui me fait assez rigolé avec les cours d'IHM/Ergonomie, à part quelques éléments scientifiquements prouvés/prouvables (par exemple le choix des couleurs de contraste pour du texte entre le fond et la police, le nombre d'infos importantes par page =~ 7 ...) le reste est très subjectif et est totalement lié à la "religion" de tes professeurs : tout comme pour le choix des langages de programmation il n'y a pas de solution miracle.

      J'ai souvenir de cours d'IHM avec un prof qui défendait mordicus qu'il n'existait pas de bonne IHM sous Unix et que la seule bonne voie était celle de Max Os où de Windows. Je passe ses trolls sur la ligne de commande, Emacs, Vi (qui pour moi ne sont que des outils d'informaticiens) pour juste lui demander ce qu'il connaissait comme WM sous Unix ? sa réponse : CDE (Common Desktop Environment de Sun Solaris) ou les équivalents proprio des anciens grands constructeurs d'Unix, bref la dessus je lui parle de GNUStep, Window Maker, Gnome, KDE, Blackbox (je ne connaissais pas Fluxbox à l'époque), Enlightement ... La dessus je lui dit que pour moi l'avantage de environnement graphique sous Unix c'était qu'on avait le choix ... pour des gens habitués à Windows, il faut mieux utiliser KDE/Gnome mais ensuite chaque personne peut choisir d'utiliser un environnement personnel. La dessus, il prend assez mal ma remarque (j'avais pourtant éviter de la faire devant d'autres éléves) me dit que le choix c'est mauvais ! qu'au moins sous Windows il n'y avait pas a se poser de question, le menu démarrer était toujours au même endroit.. Je lui réplique que je ne vois pas pourquoi il n'y aurait qu'une seule solution alors qu'il existe des milliers de façon d'utiliser un ordinateur tout en lui concédant que le problème sous Unix/Linux était le problème de cohérence qu'on pouvait avoir une application KDE sous Gnome (et inversement) mais que ça s'arrangeait en utilisant des thèmes spécifiques (genre comme fait MDK). La conversation a tourné assez court, on voyait bien qu'on arriverait pas à un consensus, qu'on avait chacun nos opinions et qu'elles auraient du mal à converger.

      Tout ça pour dire que c'est aussi dur de discuter d'ergonomie que de langage de programmation, chacun à son vécu et ses croyances (le tout objet est meilleur :).

      Pour finir, je pense qu'une bonne ergonomie est surtout quelque chose de cohérent. Après qu'on ai le choix entre plusieurs façon de faire ce n'est pas génant tant que chacune de ces façons forme un tout compréhensible et cohérent.

      • [^] # Ergonomie vs Convivialité

        Posté par  . Évalué à 5.

        Et est-ce qu'on aurait pas aussi (surtout ?) tendance à confondre ergonomie et convivialité ? Ce sont deux concepts très différents qu'il est en géneral assez difficile a concilier. Il me semble que l'ergonomie recouvre l'"utilisabilité" d'un outil sur le long terme, alors que la convivialité concernera l'utilisabilité d'un outil dès sa première urilisation.

        Je conçoit que pour un site web, les deux concepts doivent facilement se recouvrir (un site c'est dynamique, et on ne l'utilise pas 24h/24), mais ont tendance à s'opposer de manière générale. Exemple typique: word est convivial et LaTeX ergonomique.

        • [^] # Re: Ergonomie vs Convivialité

          Posté par  . Évalué à 4.

          J'appuie violemment, la confusion est très (trop?) courante. Convivialité/intuitivité sont des choses éminement subjectives et liées au vécu de la personne qui juge. L'ergonomie est mesurable. Un soft qui m'oblige à passer sans cesse du clavier à la souris, un soft qui m'oblige à deux cents clicks de souris alors que deux touches au clavier auraient suffit, ce sont autant d'exemples d'ergonomie déficiente.

  • # Il a raison

    Posté par  . Évalué à 5.

    Les remarques de ton prof me paraissent justifiées.
    "il serait préférable de n'avoir que des liens ou que des boutons mais pas les deux"

    Ca découle d'un principe simple : Des informations de même nature doivent être présentées de la même façon. Il faut tenir compte du fait que les non informaticiens se posent souvent beaucoup trop de questions (souvent injustifiées). Ca leur paraît compliqué donc ils imaginent souvent que c'est plus tordu que ça ne l'est réellement. Au boulot j'ai dajà vu des utilisateurs se poser des questions parce que sur certaines pages il y avait un bouton sauvegarder on avait un coup un bouton un coup un lien. Et donc ils se demandaient s'il y avait une nuance. Il faut faire attention aussi à toujours utiliser les mêmes termes. Pour nous "sauvegarder" et "enregistrer" c'est pareil. Pour la secrétaire de plus de 50 ans c'est une source d'interrogations.

    "Il serait préférable d'avoir une seule couleur"

    La question à se poser c'est : Qu'est ce que ça apporte? La différence de couleur c'est juste pour faire joli (et faire comme Yahoo) ou est-ce qu'il y a une différence de nature entre les différentes informations? Pour te donner une idée dans une appli sur laquelle j'ai bossé, les utilisateurs peuvent avoir plusieurs rôles à divers moments et agir de différente façon sur un même document suivant le rôle qu'il a. La couleur du thème indique le contexte dans lequel on est. Lorsqu'un utilisateur rédige une demande, le thème est bleu, lorqu'il valide/refuse une demande le thème est vert. Un même utilisateur peut être tantot superviseur tantot supervisé par ses supérieur. Au premier coup d'oeil il sait dans quel contexte il est.

    J'aujouterais que changer de couleur sans raison perturbe réellement les utilisateur. Dans cette même appli, on a un code couleur pour indiquer sur les demandes si elles sont conformes/non conformes à la politique paramétrée. Un jour un gars s'est dit que ça ferait joli d'utiliser le fond orange du "non conforme" pour une info qui n'avait rien à voir. Du coup les utilisateurs se posaient pas mal de questions du genre : "Mais qu'est ce que j'ai fait, il me dit que c'est pas conforme!" (ie. c'est orange).

    Bref l'ergonomie peut paraitre un truc fumeux pour les non initiés mais il suffit de regarder à l'oeuvre des non techos pour se rendre compte que chaque détail compte. Passé la première réaction de "mékisonkon" on réalise qu'ils n'ont pas toujours tord. Etre un peu cohérent ne fait pas de mal. Il faut savoir réfreiner ses envies de couleurs bariolées et de clickodrome avec des trucs qui se déplient dans tous les sens, qui clignotent et qui font super hype et se poser à chaque fois les questions de base : Qu'est ce que ça apporte pour l'utilisateur? Est-ce que c'est utile? Faire simple et clair.

    • [^] # Re: Il a raison

      Posté par  . Évalué à 1.

      Pour la remarque sur les oculeurs, en fait les onglets ramenaient sur des parties bien différentes du site ayant chacune sa propre fonctionnalité, c'ets pour ça que le choix des couleurs me parraissait vraiment justifié, on ne changeait pas de couleurs sans raison.

  • # La force de KDE et Gnome

    Posté par  . Évalué à 3.

    Je crois qu'un gros avantage à développer un logiciel pour KDE ou Gnome, c'est qu'on peut se tourner vers leur groupe de travail dédié à ce genre de questions, respectivement le KDE Usability Project (http://usability.kde.org/(...)) et le GNOME Usability Project (http://developer.gnome.org/projects/gup/(...))

    Je n'ai pas l'impression que ce soit un réflexe systématique de la part des développeurs, mais ils ont la possibilité de recourir à ces experts, soit en suivant leurs recommandations, soit en leur demandant un audit de leur application ; en tout cas, ce serait dommage de ne pas en profiter

  • # Apple Software Design Guidelines

    Posté par  . Évalué à 2.

    Puisqu'on parle souvent d'Apple ces temps, vous connaissez le bouquin d'Apple (essayez de l'imprimer pour voir :D) Apple Software Design Guidelines ? http://developer.apple.com/documentation/MacOSX/Conceptual/AppleSWD(...)

    C'est très intéressant, et même si c'est souvent orienté "OS X" (dans un seul chapitre particulièrement, sinon rarement), ça offre une vision intéressante de l'accessibilité dans les programmes. Je sais, on parle de site web, mais j'ai pensé que ça vallait la peine de le mentionner. Ca pourra être utile à certains sûrement, dans le processus de création d'un soft et de son ergonomie !

    • [^] # Re: Apple Software Design Guidelines

      Posté par  . Évalué à 1.

      J'oubliais aussi le http://developer.apple.com/documentation/UserExperience/Conceptual/(...)

      Apple Human Interface Guidelines. Plus orienté création d'interfaces "KISS". Et encore plus gros comme bouquin :) Bonnes lectures...

    • [^] # Re: Apple Software Design Guidelines

      Posté par  . Évalué à 3.

      tu as eu raison de poster ces informations. Et même si le journal parlait de sites web, il ne faut tout de même oublier que toute application (quelque soit son type) est concerné par ce genre de problématique (sauf si on n'est qu'un pisseur de code qui s'extasie sur le fait de coder une fonction en 30 lignes au lieu de 29).

      • [^] # Re: Pisseur de code

        Posté par  (site web personnel) . Évalué à 1.

        (sauf si on n'est qu'un pisseur de code qui s'extasie sur le fait de coder une fonction en 30 lignes au lieu de 29).

        Tu voulais pas dire l'inverse plutôt ? ;-)
        J'aurai plutôt tendance à m'extasier devant une fonction codée en 29 lignes au lieu de 30 que l'inverse :-) Quoique pour une ligne de gagnée.. ;o)

  • # Et les tests

    Posté par  (site web personnel) . Évalué à 1.

    Tout les ergonomes que j'ai croisé m'ont toujours dit que le plus importants, c'est les tests.
    Tu prends quelques personnes néophytes, et tu regarde comment elles se débrouillent face à tes deux maquettes.

    La, ça va déja faire partir une bonne part des problémes.

    • [^] # Re: Et les tests

      Posté par  (site web personnel) . Évalué à 3.

      Ah non !
      Tu ne prend des personnes néophytes que si ta cible ce sont des personnes néophytes qui ne seront pas "habitués" au site.
      Marre de voir que le néophyte est la cible de toutes les réflexions sur l'ergnomie. Et les autres alors ?

  • # Les bonnes pratiques pour l'internet

    Posté par  . Évalué à 3.

    Je sais pas si ça va t'aider mais c'est un petit site indiquant ce qu'il faut ou ne faut pas faire lors du developpement d'un site web :
    http://opquast.com/(...)

    • [^] # Re: Les bonnes pratiques pour l'internet

      Posté par  . Évalué à 1.

      Je connais ce site mais je ne vois pas le rapport avec l'ergonomie, ce sont des pratiques aidant effectivement à rendre un site le plus accessible à tous en suivant les recommandations du W3C ainsi que d'autres certainement.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.