Discussion :

[noir_desir]

Bonjour,

Je recherche des informations concernant les IHM, je programme en labview (uniquement).
N'étant pas issu du milieu de l'informatique (plutôt traitement du signal /électrotechnique), je n'ai que de vague de notion de comment rendre une interface logique, agréable, ergonomique. J'ai du temps (ouais fonctionnaire tous ça) pour mener à bien mes projets (vu que ceux ci sont en l'état fonctionnel).
Mais je pense qu'ils sont largement améliorable.
Que me conseillez vous pour apprendre à mieux en créer (livre, documentation etc).
J'ai regardé les tutos sur le site de NI qui donne de bonne info pour les techniques de prog, un peu sur les ihm, mais bon ca reste très sur le visuel plutôt que sur les techniques d'ihm (utilisé des boutons, où plutôt des menus etc).

Cordialement

Ps: le sujet a été mis aussi sur le forum dans l'edi labview, mais comme je recherche quelques choses d'assez générale, je pense que je peux aussi le mettre ici, enfin bref les modos verront ^^'.

[souviron34]

Bonjour

Le fond de ce que tu dois rechercher se trouve dans les règles d'ergonomie.


En gros, il faut que sur ton IHM les emplacements des champs, es botuons, etc, suivent le cheminement de la pensée/de l'action que l'utilisateur fait.

Ce qui veut dire, dans notre langue, aller de gauche à droite et de haut en bas.

Donc avoir les boutons validation/annulation en bas à droite par exemple (ou seuls sur la dernière ligne)

Il y a tout un tas de règles , mais qui sont la plupart du temps un mix entre une logique (par exemple celle plus haut) et un feeling (par exemple ce que pourrait donner un graphiste: forme des champs, des boutons, graphisme des icônes, couleurs)

Si tu as des choix, par exemple, tu as le choix entre plusieurs types : des radio-box (boutons exclusifs) quand le choix est exclusif entre des éléments peu nombreux. des check-box (boutons non-exclusifs) quand le choix est potentiellement multiple ET QUE le nombre est (relativement) limité. (là intervient le "feeling", dans la quantification du "relativement" ). Des combo-box quand le choix est exclusif mais le nombre relativement grand. Des listes quand le choix est soit exclusif soit non mais le nombre grand...

De même, tu peux circonscrire des sous-parties, des sous-ensembles de choses relevant d'un même aspect, en mettant des "frame", c'est à dire des cadres 3D (bords enfoncés par exemple), éventuellement associé avec un sous-titre..

etc etc..

Alors il y a des règles générales, des règles particulières à un contexte/profession, et aussi des "non-règles", des comportements/aspects graphiques difficlement quantifiables mais "plaisants" au regard..

Le tout fournit une IHM de bon niveau.

[Jipété]

Yep !

(... )En gros, il faut que sur ton IHM les emplacements des champs, les boutons, etc, suivent le cheminement de la pensée/de l'action que l'utilisateur fait. (...)

souviron34 ayant bien résumé la chose, j'ajoute mon grain de sel avec un exemple de ce qu'il ne faut pas faire :

Dans une vieille version de Publisher (ça a peut-être évolué depuis), il y a un bouton pour choisir un type d'ombre à ajouter au texte.
Mais le bouton est à droite de la barre d'outils, et la fenêtre des options de l'ombre s'affiche à gauche ! Quand tu es en plein écran sur un grand écran, ben ça fait du trajet

Et ces nazes n'ont même pas prévu, dans cette fenêtre d'option des ombres, un bouton "Appliquer"
Tout ce qu'on a comme choix, c'est OK ou Annuler. Alors si on choisit OK et que tous comptes faits ça ne va pas, faut retourner cliquer à droite sur le bouton et ensuite "courir" à gauche sur la fenêtre !
Au bout de trois essais t'abandonnes les ombres portées...
Jamais vu un truc aussi nul.

Ah si : sous Linux en ce moment, si je recopie des fichiers d'un dossier vers un autre, en cas de collision de fichier ("Ce fichier existe déjà. Voulez-vous le remplacer etc. ?"), la boîte de dialogue s'affiche systématiquement en haut à gauche de l'écran, un endroit qu'on ne regarde jamais
C'est lourdingue...

[noir_desir]

Merci

Je vais voir ça pour l'appliquer à mes interfaces.
C'est juste que moi en tant que programmeur de mon programme, forcement je sais ou tous se trouve (sinon ça serait un peu la loose...).
Mais c'est vrai que l'on se retrouve vite submergé.
Une question subsidiaire me vient à l'esprit, la taille minimal pour une lecture de donnée, c'est laquelle 10pt moins ou plus ?

[souviron34]

C'est juste que moi en tant que programmeur de mon programme, forcement je sais ou tous se trouve (sinon ça serait un peu la loose...).

C'est surtout que il faut absolument éviter les termes qui ne sont pas du métier des gens, ou détourner des termes*.

L'objectif utlime est "zéro apprentissage" : un utilisateur doit se retrouver dans une IHM sans se poser aucune question..

Il faut donc utiliser les termes des utilisateurs, et d'autre part présenter sous leur flot de pensée. Si toi dans ton programme A est avant B alors que pour l'utilisateur c'est B avant A, 2 cas seulement sont possibles : si ce sont juste des champs équivalents, il faut les mettre dans l'ordre des utilisateurs, et si ce sont des champs qui dépendent l'un de l'autre, ben c'est dommage mais c'est une erreur de conception

* Deux exemples de très mauvaises interfaces en ce sens :

• Lors des versions antérieures de M$-Word, un des éléments était "formatter la page", c'est à dire ajuster les marges. Or il existait un menu "Format".. Bien évidemment tous les utilisateurs allaient chercher dans ce menu... MAIS c'était dans le menu "Fichier" sous la rubrique "Mise en page"...
  
  
• Un certain nombre de logiciels internes de grosses boites fonctionnant avec des guichets au public (style EDF, FranceTelecom et autres) ont pendant longtemps fourni, lorsque que quelqu'un téléphonait et laissait un message, l'information sous un menu intitulé "enveloppe" alors qu'il s'agissait de "détails".. Je ne sais pas pourquoi, les architectes et concepteurs des systèmes de gestion au sein de grandes équipes traditionnelles utilisaient ce terme pour regrouper les paramètres (heure, numéro)... En bref, les utilisateurs étaient perdus, ou, pire, après avoir été perdus, assimilaient cette notion, et du coup se dévoyaient complètement quand venait le temps de les consulter pour un autre logiciel..

Une question subsidiaire me vient à l'esprit, la taille minimal pour une lecture de donnée, c'est laquelle 10pt moins ou plus ?

Au minimum 12. Mais là tu ne peux pas t'en sortir seul. Il faut idéalement un graphiste (un vrai), et sinon il te faut tester avec des utilisateurs lambda..

Il faut aussi éviter d'avoir pleins de couleurs.. Sauf si tu reproduis quelque chose qui en a intrinséquement (par exemple une palette de couleurs, ou un juke-box ou un costume de carnaval). Dans le cas général d'un écran de saisie, 3 à 4 couleurs est le maximum. Le vert est pour "OK", le rouge pour "interdit" ou "annuler", l'écriture en général en noir, et le fond doit être le plus "neutre" possible. Suivant les environnements d'utilisation, en général le gris uniforme assez clair ou le bleu pale comme ici quand tu veux poster un message sont les plus corrects..

[noir_desir]

Pour le choix de couleur, j'ai une charte graphique à respecter avec du bleu clair, du bleu plus foncé, du blanc, du jaune.

J'ai mis une capture de ce que trouve l'utilisateur .