Discussion :

[Tijee]

Bonjour à tous...

Je vous pose une question sur laquelle je réfléchis depuis quelques jours : quelle est la place pour la conception de l'IHM dans la conception d'une appli ?

Personnellement je la "case" dans la spécification des besoins, après la recherche des classes métier et des cas d'utilisation :

Spécification des besoins (à discuter avec le client) :
1- Identification des classes métier
2- Identification des cas d'utilisation
3- Conception de l'IHM (SNI, SEF,...)
4- Spécification des cas d'utilisation : diagrammes de séquence système en tenant compte de l'IHM

Conception détaillée :
5- Détail des cas d'utilisation : diagrammes de séquence détaillés toujours en tenant compte de l'IHM pour les classes Boundary
6- Détail des classes participantes
7- Architecture

Ce que je veux dire par cet enchaînement, c'est que l'interface du logiciel est pour moi importante puisque c'est un peu ce qui détermine comment se dérouleront les scénarios, et qu'il faut donc la concevoir pour permettre de faire des diagrammes de séquence qui correspondront à l'utilisation de l'application.
Et non de se contenter du cas simpliste, à savoir de faire une classe boundary par relation utilisateur -> cas d'utilisation, ou de le réfléchir à la va-vite, ce qui aboutit le plus souvent à des interfaces peu ergonomiques !

Ce post est un condensé du fruit des réflexions de mon cerveau malade mais j'aimerais savoir ce que vous en pensez et comment vous integrez vos IHM dans la conception de vos logiciels...

[pseudocode]

Apres mures reflexions (et exeperiences) sur ce sujet, j'en suis arrivé aux conclusions suivantes.

Les uses cases d'une appli sont "rangés" dans (au moins) 2 catégories:

- Les "Process Driven", dans lesquels les "décisions" ne dépendent pas des acteurs "humains". Les acteurs "humains" peuvent apparaitrent dans ces use-case, mais ils ont plutot un role passif (notification, confirmation, ...). Exemple typique, le distributeur de billet.

- Les "User Driven", dans lesquels les "décisions" sont prises pas les acteurs "humains". Le système est alors passif et execute les ordres demandés (calcul, affichage,...). Exemple typique, un traitement de texte (word).

Dans le cas "Process Driven", la notion d'IHM apparait dans le diagramme d'activité sous forme d'activités d'interaction Systeme/Humain. J'attache alors des exigences fonctionnelles sur ces activités (afficher/récuperer des informations)

Dans le cas "User Driven", la notion d'IHM apparait au niveau du use-case. Les décisions de l'utilisateur sont des "extend" a un cas d'utilisation plus général ( "ecrire un document" <--extend-- "changer de fonte" )

Les problemes commencent lorsqu'un cas d'utilisation est hybride: Le déclancheur est un acteur non humain, le traitement est "généralement" automatique mais "dans certains cas" necessite qu'une partie du traitement soit manuelle (décision humaine). Exemple typique, un filtre antispam.

Généralement je m'en sort par une pirouette, en découpant ces cas d'utilisations hybrides en 2 parties. La partie "process-driven" contiendra une activité "attendre intervention humaine". La partie "user-driven" sera déclanchée par le système.

[souviron34]

Pour moi (mais je suis un peu biaisé puisque ça fait plus de 17 ans que je fait des IHM, et que j'ai fait + 4 ans d'ergonomie des IHM), sans rentrer dans les catégorisations subtiles énoncées plus haut (qui m'échappent), je dirais :

Toute application nécessitant une IHM (y compris un mode "console") doit être attaquée PRIORITAIREMENT par l'IHM.

Si on est fortuné il y a des outils pour ça (palm-pilots avec design manuel de boutons et de fenêtres et simulation de comportement). Mais sinon, papier et crayon, et éventuellement une démo sans rien derrière suffit.

l'IHM est la SEULE partie que verra l'usager et avec laquelle il interagira. C'est donc ELLE qui DETERMINE les fonctionalités et leur arborescence.

Une fois l'IHM déterminée, on peut s'attaquer, côté informatique, à concevoir une architecture et le détail des fonctionalités requises pour la faire fonctionner.

L'IHM est déterminée par un groupe de personnes (chef de projet, un représentant expert des utilisateurs, éventuellement un ergonome).

Cette spécification de l'IHM détermine 1) ce que souhaite l'utilisateur 2) dans quel ordre il le souhaite, 3) les aides que peut lui procurer l'informatique au fur et à mesure (par exemple un calcul de taux automatique, une liaison à tel instant, sur CET écran, à TEL endroit, avec un dictionnaire, une base, etc..)
4) les contraintes de temps qu'il est prêt (ou non) à accepter sur telle ou telle fonctionalité.

C'est l'équivalent d'un cahier des charges établi par les utilisateurs.

A partir de là, on peut développer du côté informatique une vraie spec, puis avancer.
Il faudrait cependant à mon avis avoir sinon en permanence du moins une fois par semaine l'avis du représentant des utilsateurs sur ce qui est fait.

Et enfiin, une fois le code fait et testé, faire venir un graphiste pour repasser à travers les écrans et les rendre "jolis".

Encore une fois, c'est la SEULE partie que verra l'utilisateur, qui la plupart du temps n'en a rien à .... que ce soit un ordi... Ce qu'il veut, c'est faire son travail et que l'info. l'aide.

Si on vous présentais une voiture avec la tôle brute, sans peintures, les sièges sans revêtement, et l'intérieur et le tableau de bord à l'état brut, ça m'étonnerais que les gens se battent pour acheter le nouveau modèle....

Même chose si le levier de changement de vitesse était au milieu du siège arrière...

Un logiciel est la même chose qu'un autre objet de la vie courante...

[pseudocode]

Je suis d'accord avec souviron34 pour dire que l'IHM doit etre pensée comme un "tout" (charte graphique + charte ergonomique). Elle doit etre en accord avec ce qu'attend l'utilisateur (user experience).

La ou je ne suis pas d'accord, c'est sur la phrase "Toute application nécessitant une IHM (...) doit être attaquée PRIORITAIREMENT par l'IHM."

C'est vrai pour les appli "user driven", c'est a dire celles ou l'utilisateur est le maitre et le logiciel ne fait qu'obeir aux ordres (traitement de texte, navigateur web, ...)

C'est globalement faux pour les autres appli de type "process driven", "data driven". Le logiciel de controle d'une fusée ou d'une centrale nucléaire n'est pas construit "en partant" de l'IHM et "en descendant" aux algorithmes et a l'aquisition des données. C'est meme l'inverse: le data/process est au coeur de l'architecture du logiciel (entité/controleur) et l'IHM est une extrémité (frontiere). C'est, par exemple, le principe du pattern MVC.

Meme si l'IHM doit etre jolie et pratique, ce n'est pas "tout le temps" elle qui pilote ("drive") les choix architecturaux. L'IHM n'est parfois qu'une interface externe comme les autres du logiciel.

[souviron34]

je parlait du "User Centered Design".

Et pour ton exemple de fusée, je suis désolé, mais que ce soit les pilotes ou le centre de contrôle, ce sont eux qui interagissent, même si une partie non négligeable est faite en dehors d'eux, et l'IHM a intérêt à correspondre à ce qu'ils souhaitent pour travailler vite et en sécurité.

Le P.O. posait la question de la place d'une IHM dans la conception d'une appli.

A quelques cas particuliers près (ou justement l'IHM n'est pas importante car uniquement une "fenêtre" sur ce qui se passe [démarrage d'un OS par exemple]), dans l'écrasante majorité des cas de logiciels necessitant une IHM, c'est elle qui présente à l'utilisateur ce qu'il peut faire.

[EDIT]
Tu parles d'"utilisateur maître et de logiciel qui obéit aux ordres", mais il ya beaucoup de cas où c'est faux, mais où l'interface est essentielle (exemples des salles de contrôles ci-dessous, des systèmes d'alertes, etc..)...
[/EDIT]

Tes exemples de "User Driven" me semblent bien pauvres... Que ce soit le contrôle routier, les affichages des tours de contrôle, les logiciels scientifiques, les logiciels de guichets automatiques, tous les logiciels médicaux, les logiciels des banques et assurances, des bourses, des contrôles d'usines, de production, des standards télephoniques d'urgence, les salles de contrôle des centrales nucléaires, des réseaux d'électricité, de téléphone, les réservations de trains, d'avions, etc..... tous ces logiciels sont PRIORITAIREMENT axés sur l'usager.

C'est une erreur très largement répandue de penser que l'IHM n'est que la "présentation" des logiciels. Si il n'y a pas besoin d'interaction humaine, alors il n'y a pas d'IHM. A partir du moment où il y a une IHM, c'est qu'on juge que l'intervention humaine est nécessaire.

Et dans ce cas, il est absolument nécessaire de satisfaire ce dont l'usager aura besoin, et dans l'ordre dans lequel il en aura besoin, quitte à faire dans la conception après des jobs "en background" pour satisfaire les demandes.

Il est en dehors de ça bien entendu qu'il y a des applications ne nécessitant pas d'IHM en tant que telle. mais d'une part c'est une infîme partie, et d'autre part cela ne correspond pas à la question.

[Tijee]

souviron34 je suis content que tu soulèves le problème car là où je veux en venir avec tout ça serait une conception BASÉE sur l'IHM... autrement dit une "approche IHM" où tout le processus de conception découlerait de l'IHM qui a été conçue...

Je me demandais si c'était beaucoup pratiqué en entreprise ? En tous cas ce n'est pas l'approche qui nous est enseignée... peut-être que ça se rapproche plus de l'Xtrem programming ?

Merci pour vos réponses très instructives !

[pseudocode]

Que ce soit le contrôle routier, les affichages des tours de contrôle, les logiciels scientifiques, les logiciels de guichets automatiques, tous les logiciels médicaux, les logiciels des banques et assurances, des bourses, des contrôles d'usines, de production, des standards télephoniques d'urgence, les salles de contrôle des centrales nucléaires, des réseaux d'électricité, de téléphone, les réservations de trains, d'avions, etc..... tous ces logiciels sont PRIORITAIREMENT axés sur l'usager.

Oui tous ces logiciels sont PRIORITAIREMENT axés sur l'usager. Et alors ? ca implique forcement que l'architecture soit centrée sur l'IHM ? et bien non, je ne suis pas d'accord.

Si c'etait aussi simple, on commencerait pas ecrire toute l'IHM avec une ergonomie maximale, sans aucunes contraintes fonctionnelles. Et puis apres, une fois l'IHM terminée, on ajouterai les "jobs en background" et hop, c'est fini. c'est a la fois ergonomique et fonctionnel. Mais ce n'est pas aussi simple. Les contraintes fonctionnelles (ou meme materielles) sont souvent telles que l'on doit penser aux fonctions PENDANT ou meme AVANT de s'attaquer a l'IHM.

C'est justement le role de l'architecture de séparer les responsabilités, par exemple IHM <-> Process <-> Données (aka 3 tiers). Dans ce cas, tu peux avoir une partie IHM qui est entierement (ou presque) user-driven, et donc qui aura l'ergonomie souhaitée par les utilisateurs. Ca n'empeche pas ton appli d'etre centrée sur le process, car a la fin c'est lui qui decidera de faire ou de ne pas faire les operations.

Les applications modélisent un service/metier. Dans cette modélisation, on peut éventuellement extraire et regrouper toutes les actions faisant intervenir l'utilisateur et appeler ce groupement "IHM". Mais ce n'est pas pour autant que l'IHM est le coeur de la modélisation.




Quand a l'Extreme Programming, c'est typiquement l'exemple de la séparation entre "ce que veut l'utilisateur" (IHM, user driven) et "ce que fait le logiciel" (process, data).

"Ce que veut l'utilisateur" est formalisé sous forme de "user stories" qui seront transformées en "exigences", puis codées afin de produire le logiciel.

L'Extreme Programming consite a confronter les "user stories" et le logiciel au travers de "test d'acceptance" afin d'obtenir un compromis.