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.

[souviron34]

Je n'ai pas dit de faire d'abord l'IHM puis.....

Ce que je dis, c'est que le "first draft" d'une IHM (comme je disais, cahier des charges utilisateur, graphique (même manuel), avec en plus contraintes de temps associées et données nécessaires), IMPOSE une architecture globale de toute la partie primaire.

Quand on arrive aux couches internes, on peut faire comme on veut. On va au plus efficace selon son but (portabilité, maintenance, vitesse, volume, ...).


Je pense (et ça rejoint le thread sur les RAD) , par expérience, que justement une des erreurs de fond est de dire ce que tu dis pseudocode :

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.

Absolument tous les projets que j'ai vus, sans exception, qui ont fait ça, se sont plantés.... Soit (comme c'était le cas pour moi dans l'équipe d"ergonomie), ils nous appellaient à la dernière minute et s'étonnaient qu'on arrive avec une conclusion "faut tout casser et réécrire.... " (dans 1 seul cas il s'agissait juste de changements "cosmétiques"), soit ils ont été abandonnés ou la boîte a coulé.

Qu'on y pense PENDANT, certainement, mais ce n'est pas déterminant, et ce n'est pas encore formailsé et décidé.

Qu'on y pense AVANT, alors là certainement pas... Ou alors l'IHM ne fait rien que présenter quelques petits résultats.

D'ailleurs, ici-même tu peux trouver le topo d'Emmanuel Delahaye http://emmanuel-delahaye.developpez.com/dev_proj.htm
qui va dans ce sens.

Une seconde erreur extrêmement fréquente, c'est de penser qu'un cahier des charges ou une spec. écrite est valable parce qu'elle est signée par un utilisateur/client . Pourquoi est-ce une erreur ??? Parce qu'on demande à un utilisateur d'approuver un document écrit sur son métier, mais dans des termes et avec une logique qui lui sont inconnues.

C'est pourquoi l'approbation et signature d'un cahier des charges/spec présentant l'IHM sur papier, animation, ou coquille vide, est beaucoup plus sûre.

Enfin je ne vois pas dans ton contexte ce que tu appelles une appli. Si elle a une IHM, l'IHM fait partie de l'appli, et donc ta distinction entre

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

Pour moi c'est impossible.

Il n'y a que 3 cas de figures :

• Ou c'est une appli sans IHM (serveur de données par exemple) : design uniquement centré sur ce qu'on souhaite en faire, pefomances, etc..
• Ou c'est une appli avec une IHM ne servant qu'à vérifier que ça tourne ("Starting Linux....."), et dans ce cas l'IHM est inimportante (un "print" suffit)
• Dans tous les autres cas, l'IHM donne l'architecture de la fonctionalité telle que spécifiée dans une spec système, pour les parties directement touchées. (premier niveau et arborescence fonctionnelle).
  (il est évident que si, pour faire du traitement d'images, tu passes par un array processor, c'est pas l'IHM qui détermine l'architecture de la communication avec l'array processor)
  Il peut donc y avoir des spec fonctionnelles identifiées pour faire le job, mais elles se placeront alors SOUS l'arborescence .

En gros ce que je dis, c'est que dès qu'il y a une IHM, la spec fonctionnelle de premier niveau (voire plus) est déterminée par l'IHM.

Enfin, pour en revenir à ce que disait le P.O, par exemple, en France, EDF utilise un groupe d'ergonomes pour déterminer leurs applis réseaux et services à la clientèle. De même, Philips utilise un tel groupe (avec par exemple des couturiers aussi) pour déterminer l'apparence et la fonctionalité des portables. ça c'est ceux que je connais personnellement. Mais par exemple je sais que les softs des contrôleurs aériens sont aussi basés là dessus. Egalement toutes les banques pour les DAB.

Aux USA, Bell et AT&T utilisent aussi ça pour leurs softs, et la boîte qui fabrique les centraux d'appels d'urgence 911, ainsi que certaines compagnies
d'électricité. Le regroupement des assurances de Californie , celui de Floride, et celui de Géorgie aussi pour les logiciels des médecins et infirmières dans les hopitaux, et pour la télémedecine.

Mais c'est vrai que dans certains milieux, et en particulier les SSII, ce n'est pas bien vu.... En France et ailleurs d'ailleurs. Considéré comme une perte de temps. Mais leur souci principal n'est pas forcément la satisfaction des utilisateurs, mais le paiement par le client (surtout si c'est l'Etat d'ailleurs).

Je ne parlerais pas de l'Extreme Programming, mais je pense que la meilleure solution que j'ai vue (et que j'ai toujours appliquée) est plutôt les "méthodes agiles", sauf que j'étais comme Mr. Jourdain, je savais pas que ça s'appelait comme ça

A+

Note : je pense aussi qu'en info on confond beaucoup ce qu'on veut dire par "fonctionalité".

En fait, dans mon expérience, la production d'un cadre agréé d'IHM DONNE le cahier des charges/spéc. côté utilisateur.

A nous de la re-traduire..

[pseudocode]

Je n'ai pas dit de faire d'abord l'IHM puis.....
Ce que je dis, c'est que le "first draft" d'une IHM (...), IMPOSE une architecture globale de toute la partie primaire.

Etant donné que les IHM ont pratiquement toutes les memes contraintes (rapides, puissantes, configurables, ...) ca voudrait dire que toutes les Appli ont la meme "architecture globale de la partie primaire". C'est cool ca. Plus besoin de reflechir. One Size Fits All.

Quand on arrive aux couches internes, on peut faire comme on veut. On va au plus efficace selon son but (portabilité, maintenance, vitesse, volume, ...).

A priori, si tu as fixé l'architecture globale, tu n'as plus trop le choix pour les couches internes. Quand bien meme, puisque c'est l'IHM qui commande, les interfaces de tes couches internes (= les jobs en background) sont imposées !

Dans ce cas, je ne vois pas trop comment tu vas pouvoir garantir la performance ou le volume. Si l'IHM envoie un million de valeurs, une par une, et demande pour chaque valeurs une sauvegarde en base, comment tu fais pour que cela soit rapide ?

Absolument tous les projets que j'ai vus, sans exception, qui ont fait ça, se sont plantés....

Bah moi c'est l'inverse. Tous les projets qui ont architecturés l'appli autour de l'IHM ont fini par avoir:

- du code "metier" dupliqué un peu partout (car les ecrans IHM ne sont pas toujours exactement les memes, donc les "jobs en background" n'ont pas les memes parametres E/S)

- du code "ihm" dupliqué un peu partout (du genre "griser" les boutons pour eviter que 2 operations s'executent en meme temps)

- un code non réutilisable (car lié a une IHM particuliere, et non pas a une problematique recurente)

D'ailleurs, ici-même tu peux trouver le topo d'Emmanuel Delahaye http://emmanuel-delahaye.developpez.com/dev_proj.htm qui va dans ce sens.

Je ne vois pas en quoi le cycle de developpement impose que l'architecture soit centrée sur l'IHM. Les SDLC décrivent un processus de développement, mais n'imposent rien sur l'architecture.

Une seconde erreur extrêmement fréquente, c'est de penser qu'un cahier des charges ou une spec. écrite est valable parce qu'elle est signée par un utilisateur/client . (...) C'est pourquoi l'approbation et signature d'un cahier des charges/spec présentant l'IHM sur papier, animation, ou coquille vide, est beaucoup plus sûre.

Oui, totalement d'accord. C'est pour cela qu'on fait signer un "Cahier Des Charges" (pas une spec) et que l'on fait valider periodiquement le logicel par les clients (prototypes, iterations, ...)

Enfin je ne vois pas dans ton contexte ce que tu appelles une appli. Si elle a une IHM, l'IHM fait partie de l'appli, et donc ta distinction entre "....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," Pour moi c'est impossible.

Et bien prends par exemple l'ordi que tu as devant toi.

Je suppose que c'est un PC sous windows. Windows est un Operating system, donc une application (un peu particuliere, certe). A ce titre, elle a une IHM et du fonctionnel. Penses tu vraiment que Microsoft a architecturé le noyau, les driver et les services réseaux, disques, mémoires, ... autour de l'IHM ? Dans ce cas comment expliquer que le noyau n'a pratiquement pas evolué depuis NT4 alors que l'IHM a changée avec chaque version ?

Idem pour MacOS, reconnu pour son IHM hyper ergonomique. Ont-ils commencés l'architecture par l'IHM, puis ecrits la partie "background" ? Dans ce cas c'est un sacré hasard de conception, car le "background" en question ressemble bcp a un noyau unix (qui lui n'a pas d'IHM).

Et je ne parle meme pas des applications web (ca m'étonnerait que MySQL ait été créé dans le seul objectif de s'interfacer avec une IHM en HTML)

En gros ce que je dis, c'est que dès qu'il y a une IHM, la spec fonctionnelle de premier niveau (voire plus) est déterminée par l'IHM.

Non, je ne suis pas d'accord. Dès qu'il y a une IHM, les scénarii décrits par le client sont tous (ou presque) axés autour de l'IHM. Pour autant, les fonctions principales effectuées par le logiciel ne sont pas graphiques.

Meme dans un logiciel type "PhotoShop" qui a enormement d'interaction Homme/Machine, les fonctions principales sont dans le domaine du traitement du signal 2D.

Personnellement, je pense que les applications doivent d'abord "rendre un service" a l'utilisateur. Ce service n'a (generalement) rien de graphique. L'IHM n'est pas une fin en soi, mais:
- un moyen pour un utilisateur d'expliquer au logiciel ce qu'il veut faire
- un moyen pour le logiciel de montrer a l'utilisateur ce qu'il a fait

L'ergonomie intervient pour améliorer le confort ou l'efficacité de ce moyen de communication. Mais l'ergonomie n'est pas l'objectif primaire du logiciel. Son premier objectif est de "rendre le service" pour lequel il a été concu.

Je ne parlerais pas de l'Extreme Programming, mais je pense que la meilleure solution que j'ai vue (et que j'ai toujours appliquée) est plutôt les "méthodes agiles", sauf que j'étais comme Mr. Jourdain, je savais pas que ça s'appelait comme ça

L'Extreme Programming EST une methode agile. Les methodes agiles sont des processus de développement adaptatifs (activités variables), peu formels (bonnes pratiques) et avec des iterations courtes.

[Rakken]

Avant de commencer, je vous previent, je viens plutot du monde web, donc j'ai probablement une conception un peu "biaisé" de la notion ihm.

Cependant, apres avoir lu vos post (souviron34 et pseudocode) j'ai globalement l'impression que vous avez tous les deux raisons, sans pourtant vraiment vous comprendre.

En gros, ce que j'ai retenu de souviron34, c'est que quand on fait une appli, il faut "partir" de l'ihm ou, plus raisonnablement inclure la conception de l'ihm au tout début du projet. A mon petit niveau pour une appli web ca veut dire qu'il faut inclure une maquette du site avec le déroulé des écrans dans le cahier des charges que le client va signer. C'est une idée qui ne me semble pas absurde, loin de là.

Ce que j'ai retenu de pseudocode, c'est que l'ihm ne dois pas présumer des choix technique que l'on va faire. En gros, pour ma bonne vieille appli web, décider de facon unilatérale que j'aurai tel et tel écran qui ne pourront être fait qu'en flash par exemple, ca n'est pas judicieux, avec d'autres mots, ca n'est pas le rôle d'une ihm. Ca me semble la aussi plutot pertinent.

Les deux notions ne sont par contre pas incompatible. L'ihm doit être concue dès le départ, parce que c'est "ca" qui est généralement vendu au client (garlg, la c'est le concepteur de site web qui parle ici). Par contre, l'ihm ne doit jamais présumer des techniques à utiliser. Un designer n'a pas a décider si le site sera fait en php, java, asp ou autre chose. Il propose quelque chose de "brut", pour caricaturer, un gars qui fait de l'ihm envoie des jpg.
En parallèle, les gens du coté technique doivent proposer leurs solutions aux problèmes fonctionnels (Le client veut un forum ? faire du datamining sur ses données clients ? ... ?). Et, le plus régulièrement possible, il faut confronter les deux pour ne pas avoir d'incoherence (Genre la technique dit "php" et le designer propose des trucs uniquement réalisable en flash) et faire des choix, soit pour réorienter l'ihm, soit pour réorienter la technique, et le plus souvent, un peu des deux.

Pour reprendre l'idée de windows, évidement que les choix technique n'ont pas été fait en "fonction" de l'ihm, mais tout coder et mettre l'ihm après est tout aussi idiot.

Pour détendre un peu le débat et illustrer ce que souviron34 craint lorsqu'on ne prend pas l'ihm en compte dès le départ : http://www.codinghorror.com/blog/archives/000734.html

[souviron34]

Bon.....


Reprenons les choses dans l'ordre....

@pseudocode : on doit pas franchement avoir la même définition de l'IHM, quand je lis :

Etant donné que les IHM ont pratiquement toutes les memes contraintes (rapides, puissantes, configurables, ...) ca voudrait dire que toutes les Appli ont la meme "architecture globale de la partie primaire". C'est cool ca. Plus besoin de reflechir. One Size Fits All.

Je ne vois pas comment un ensemble commun de contraintes peut définir un ensemble d'IHM...., et comme je l'ai dit, ce ne sont pas les contraintes, mais le design (au sens de dessin) de l'IHM qui définit l "architecture globale de la partie primaire".

A priori, si tu as fixé l'architecture globale, tu n'as plus trop le choix pour les couches internes. Quand bien meme, puisque c'est l'IHM qui commande, les interfaces de tes couches internes (= les jobs en background) sont imposées !

Dans ce cas, je ne vois pas trop comment tu vas pouvoir garantir la performance ou le volume. Si l'IHM envoie un million de valeurs, une par une, et demande

Je me demande bien d'où tu peux tirer ça.... Ce n'est pas parce que le 2ième sous-menu du 3ième menu de la fenêtre principale indique "sauvegarder la base de données" que ça va m'indiquer comment faire cette sauvegarde... Tout ce que ça m'indique, c'est que dans ma spécification, la sauvegarde de la base de données est une fonctionalité à part entière, et que dans l'arbre des fonctionalités elle se situe au 2ième sous-niveau ...

En ce qui concerne les OS, je ne les considère pas comme des applications, en tous cas pas dans celles rentrant dans le cadre de la question du PO.

Ensuite, dans ton exemple, pour Photoshop, tu as tout faux.... :

Adobe a agit avec un groupe d'ergonomes et un groupe d'utilisateurs, pour voir comment un graphiste travaillait. Au fur et à mesure des étapes de son travail, ils ont identifié les outils dont il se servait, dans quel ordre. En particulier, quand ils en sont arrivés aux effets spéciaux, ils ont discuté, creusé, et finalement listé les traitements les plus fréquemment utilisés, et l'ordre de ces traitements (et contrairement à ce que tu crois, ce ne sont pas les traitements d'images qui sont le plus fréquemment utilisé par un graphiste, mais le retouchage, et les effets de pinceau et de bombe à peinture, et la palette de couleur) . Et ils en ont déduit une architecture fonctionelle, reproduite dans l'IHM.

Et quand tu dis :

L'IHM n'est pas une fin en soi, mais:
- un moyen pour un utilisateur d'expliquer au logiciel ce qu'il veut faire
- un moyen pour le logiciel de montrer a l'utilisateur ce qu'il a fait

....

L'ergonomie intervient pour améliorer le confort ou l'efficacité de ce moyen de communication. Mais l'ergonomie n'est pas l'objectif primaire du logiciel. Son premier objectif est de "rendre le service" pour lequel il a été concu

je réitère le fait que nous n'avons pas la même notion d'IHM, de logiciel, et d'ergonomie. Globalement, (bien entendu des cas existent ne rentrant pas dans ces catégories), on a :

• Un logiciel est une AIDE dans le travail d'une personne (en général).
• L'interaction que l'utilisateur a donc avec le logiciel est CENTRALE dans le TRAVAIL de cette personne.
• L'ergonomie d'une IHM n'est PAS le fait que les couleurs soient jolies, mais c'est le fait que 1) il n'y a pas (ou très peu) d'apprentissage (notions instinctives pour la personne dans son travail), et 2) que le logiciel permet à l'utilisateur de faire son travail plus vite, éventuellement en se préparant des utilisations futures.

L'ergonomie permet de GARANTIR que le logiciel "rendra le service" pour lequel il a été concu. Un très bon logiciel avec une mauvais ergonomie ne rendra pas le service rendu.

Je ne citerais que 2 exemples (contre-exemples plutôt) :

1) j'ai eu à redresser une situation chez un grand producteur d'électricité (étranger), où le logiciel de saisie des documents remplis par les représentants à la clientèle était soi-disant basé sur l'analogie du bureau. Il y avait donc des tiroirs, des poubelles, des formulaires.. Sauf que pour jeter un formulaire à la poubelle, il falait commençer par sélectionner "poubelle", puis "type du formulaire", puis dans la liste des formulaires de ce type le formulaire en question. Et j'ai simplement posé la question à l'architecte : chez toi, dans ta maison, c'est ce que tu fais ? Tu vas t'asseoir devant la poubelle, et dire : "qu'est-ce que je vais bien pouvoir mettre à la poubelle aujourdhui" ????

Le logiciel faisait bien la fonctionalité demandée, mais pas dans le bon ordre.

2) j'ai été appelé à l'aide sur un logiciel de DMP (Dossier Médical Personnalisé (ou Informatisé)). Entre divers trucs qui foiraient complètement (650 fenêtres dans le logiciel en particulier), une série d'écrans étaient réservés à la prescription du médecin. Une mesure chronométrée du remplissage d'une prescription compliquée par un spécialiste donnait 12 minutes à la main sur du papier, et ........ 45 minutes par le système informatique.

Là encore, la fonctionalité était effectuée, mais ni découpée ni enveloppée telle qu'elle devait l'être. Résultat : logiciel à la poubelle.

Et j'en ai des dizaines comme ça...


@Rakken :

Ce que j'ai retenu de pseudocode, c'est que l'ihm ne dois pas présumer des choix technique que l'on va faire. En gros, pour ma bonne vieille appli web, décider de facon unilatérale que j'aurai tel et tel écran qui ne pourront être fait qu'en flash par exemple, ca n'est pas judicieux, avec d'autres mots, ca n'est pas le rôle d'une ihm. Ca me semble la aussi plutot pertinent.

Pour le Web le cas est un peu particulier, l'interface globale étant en général une page à l'intérieur d'un navigateur.

Pour les autres, c'est évident, et je ne sais pas où tu peux trouver le contraire dans ce que je dis. Non seulement l'IHM (enfin son design) ne doit pas présumer des choix techniques, mais elle ne SAIT PAS et ne DOIT PAS SAVOIR ce que seront les choix techniques. (durant l'étape initiale)

Pour la détente :

excellent


J'en ai une bonne, mais faut que je scanne.. Demain peut-être...

[pseudocode]

on doit pas franchement avoir la même définition de l'IHM.
(...)
ce ne sont pas les contraintes, mais le design (au sens de dessin) de l'IHM qui définit l "architecture globale de la partie primaire".
(...)
Adobe a agit avec un groupe d'ergonomes et un groupe d'utilisateurs, pour voir comment un graphiste travaillait. (...) contrairement à ce que tu crois, ce ne sont pas les traitements d'images qui sont le plus fréquemment utilisé par un graphiste, mais le retouchage, et les effets de pinceau et de bombe à peinture, et la palette de couleur[/I]) . Et ils en ont déduit une architecture fonctionelle, reproduite dans l'IHM.
(...)
Un logiciel est une AIDE dans le travail d'une personne (en général).
L'interaction que l'utilisateur a donc avec le logiciel est CENTRALE dans le TRAVAIL de cette personne.
(...)

Effectivement, on n'a pas la meme notion de ce qu'est la "conception" (ou "design" en anglais) d'une IHM, et a mon avis, on n'a pas lu le P.O de la meme facon.

Nous sommes ici dans le Forum "Conception" et si je reprend les posts de Tijee ce qui l'interesse c'est:

une "approche IHM" où tout le processus de conception découlerait de l'IHM qui a été conçue

Ce qui l'interesse ce n'est pas les techniques permettant de créer des IHM conviviales (avec des groupe d'ergonomes et des groupes d'utilisateurs). C'est interessant en soi, mais ce n'est pas l'objet du P.O

Ce qui l'interesse c'est de savoir si on peut concevoir une application "entiere" par propagation des "objets" IHM au reste de l'application. Bref, est-ce qu'il existe un processus de développement qui permet de concevoir d'abord l'IHM, puis ensuite de concevoir le reste de l'application ?

Et ma réponse est NON. On ne peut pas faire cela pendant la "phase de conception". La conception doit etre globale, elle doit tout prendre en compte: IHM, workflow, calculs, stockage, connectivité, ... afin de garantir des exigences non fonctionnelles telles que: Performance, sécurité, fiabilité, evolutivité, ...

Par contre, on peut avoir ce genre d'approche pendant la "phase d'analyse du besoin". On demande aux utilisateurs ce qu'ils veulent comme IHM, on observe comment ils travaillent, ... Cela permet d'obtenir une (grosse) partie des exigences fonctionnelles.

Mais ce n'est généralement pas suffisant. Il y a des exigences qui sont "invisibles" pour l'utilisateur du logiciel: le respect des normes/formats (HTTP, HTML) , l'utilisation de brevets/licenses (BSD, GPL, ...), des contraintes techniques (OS, Toolkit) et materielles (processeur, mémoire), l'intégration avec des logiciels tiers (base de données, ), ...

Toutes ces exigences doivent etre recensées AVANT de faire la conception, car les solutions choisies vont en dépendre.

[souviron34]

Ce qui l'interesse c'est de savoir si on peut concevoir une application "entiere" par propagation des "objets" IHM au reste de l'application. Bref, est-ce qu'il existe un processus de développement qui permet de concevoir d'abord l'IHM, puis ensuite de concevoir le reste de l'application ?

Et ma réponse est NON. On ne peut pas faire cela pendant la "phase de conception". La conception doit etre globale, elle doit tout prendre en compte: IHM, workflow, calculs, stockage, connectivité, ... afin de garantir des exigences non fonctionnelles telles que: Performance, sécurité, fiabilité, evolutivité, ...

Là on est d'accord (je pense, quoique...). Je suis d'accord sur le point que la conception est globale, par contre concevoir d'abord l'IHM (sur le papier) et en déduire une bonne partie de la conception est la voie à suivre cependant .. (voir paragraphe suivant ;-) )
Ce que je veux dire, c'est que il n'y a pas de processus permettant de passer DIRECTEMENT de l'IHM à la conception, car effectivement un certain nombre de choses ne sont pas prises en compte dans l'IHM, là dessus on est d'accord.
Par contre, l'IHM intervient de manière directive sur la conception fonctionelle des premiers niveaux.

Par contre, on peut avoir ce genre d'approche pendant la "phase d'analyse du besoin". On demande aux utilisateurs ce qu'ils veulent comme IHM, on observe comment ils travaillent, ... Cela permet d'obtenir une (grosse) partie des exigences fonctionnelles.

Pas seulement des exigences, mais de l'architecture fonctionnelle.

Mais ce n'est généralement pas suffisant. Il y a des exigences qui sont "invisibles" pour l'utilisateur du logiciel: le respect des normes/formats (HTTP, HTML) , l'utilisation de brevets/licenses (BSD, GPL, ...), des contraintes techniques (OS, Toolkit) et materielles (processeur, mémoire), l'intégration avec des logiciels tiers (base de données, ), ...

Toutes ces exigences doivent etre recensées AVANT de faire la conception, car les solutions choisies vont en dépendre.

Encore une fois là on est d'accord bien que par exemple l'intégration avec des logiciels tiers (base de données) ne devrait être décidée (et programmée comme telle) qu'en dernier ressort, car elle devrait être "ouverte" (pouvoir remplacer une base par une autre par exemple).

Ce qui l'interesse ce n'est pas les techniques permettant de créer des IHM conviviales (avec des groupe d'ergonomes et des groupes d'utilisateurs). C'est interessant en soi, mais ce n'est pas l'objet du P.O

Au risque de me répéter ce n'est pas de la convivialité. C'est ce que tu disais plus haut : le fait que le logiciel fasse ce pour quoi il a été conçu....
Car même si la fonctionalité est là, si il n'est pas utilisé, il ne fait pas ce pour quoi il a été conçu....

Je reprendrais juste l'exemple du logiciel DMP cité précedemment. Pourquoi en étaient-ils arrivés à 650 fenêtres ??
On parle d'un projet de 16 ans, 60 personnes d'une SSII très grande (8000 consultants), 80 millions de dollars, avec méthodologies de développement, de gestion, etc...
Outre des choix technologiques initiaux qui se sont avérés faux, ils avaient suivi les méthodologies "normales", et remplissaient bien toutes les fonctionalités demandées. MAIS ni avec l'arborescence ni dans l'ordre utilisés. Pour info, ils faisaient face à une grève des médecins et infirmières des 5 hopitaux où c'était en test qui ne voulaient même plus tester .
A l'inverse, avec une approche centrée sur l'IHM (qui impliquait par exemple la création de widgets spécifiques d'IHM), la même chose était faite en 8 mois à 6 personnes avec 24 fenêtres, et les médecins voulaient acheter le "prototype" ...

A+

[pseudocode]

Cool, on est d'accord sur (presque) tout.

Je reprendrais juste l'exemple du logiciel DMP cité précedemment. Pourquoi en étaient-ils arrivés à 650 fenêtres ?? (...)

Dans ton exemple, c'est clairement le processus de développement qui n'etait pas bon. Ca devait etre un bon vieux WaterFall, non ? Une fois que les exigences ont été recensées (a priori sans prendre en compte le coté ergonomie) le developpement commence, sans feedback des utilisateurs, jusqu'a ce que mort s'en suive.

Dans ce cas, c'est clair que les methodes genre X.P. (avec des scenarios, des iterations avec protoypes et des tests d'acceptation) sont beaucoup plus efficaces.

[souviron34]

je ne sais pas ce qu'est le WaterFall.. Je n'ai jamais suivi de cours d'infos dans ma vie (sauf 1 semaine de XWindow),donc côté théorie et appellations c'est pas mon fort

Par contre, ce que je sais, c'est que par exemple dans ce cas-là, ils avaint pris en compte les contraintes (style loi Informatique et Liberté, directives du Ministère de la santé, etc.. , y compris le fait que ce pourrait être utilisé en bout de chaîne par des chercheurs...

Seul inconvénient : ils avaient oubliés que pour qu'il y ait des données pour les chercheurs, il fallait que les praticiens au jour le jour les rentrent.....

D'ailleurs, pour eux, même avec tous les problèmes de grève etc.., au départ, leur seule demande ergonomique était qu'on leur fasse gagner 10 pixels en largeur et en hauteur par écran.......

2 millions de lignes de code refusées, contre 150 000 acceptées pour nous, et le Directeur Technique venait me dire "vous, vous êtes des chercheurs, vous avez fait un prototype, nous, c'est l'industrie..".... Trouvez l'erreur....


En gros (ce que je disais un peu au départ), l'architecte général n'était capable que de me montrer l'ensemble des relations dans la BD (un mur complet)... Mais l'arborescence de la fonctionalité, ..... en une ou 2 pages, .. inconnue au bataillon..

Et d'ailleurs, après qu'ils aient repris notre "prototype", ils ont remis leur structure d'analyse conceptuelle (avec une barre de menus spéciale pour gérer la loi Informatique et Liberté), et leur manière de faire (gestion d'équipe, de projets, etc..) et ...... ils ont fermé 6 mois plus tard....



Bon enfin on est OK

[pseudocode]

je ne sais pas ce qu'est le WaterFall.. Je n'ai jamais suivi de cours d'infos dans ma vie (sauf 1 semaine de XWindow),donc côté théorie et appellations c'est pas mon fort

Une petite présentation des SDLC, un peu vieillotte (avant que le terme "agile" soit inventé).

Et sinon, pour le fun: chef du projet «Waterfall»

[souviron34]

très bon le truc du chef...

Mais réel malheureusement....

Quant à l'autre, oui, ok , mais en gros ça ressemble au V.

Sur l'appli DMP, c'était du V.

Mais de toutes façons (et sans partir en troll), comme on dit dans le thread sur les bonnes manières de développer, je pense qu'aucune méthode (et il suffit de voir sur ce forum .... avec toutes les méthodes utilisées..) n'est la panacée...

Mais voilà un petit exemple (réjouissant ?? attristant ??) de ce qu'on peut faire en suivant une méthode... (par la même SSII que le DMP, avec leurs méthodes adaptées du V)... Le genre de choses que l'architecte général avait sur son mur après 15 ans de projet :

[pseudocode]

Bah ce diagramme ne me semble pas hyper compliqué...

On peut faire bien pire en UML

[souviron34]

Comme quoi c'est bien ce que je soutiens ailleurs.... Les outils et les modèlisations aussi sophistiquées soient-elles, ne garantissent en rien quelque chose de correct....

[pseudocode]

Réciproquement, il y a aussi des modèles tres complexes qui marchent bien...

- Windows Server running IIS