De nouveaux moyens pour aborder la programmation : l'apport des interfaces graphiques

L'utilisation des langages de programmation classiques est réservée à des spécialistes informaticiens. Avec l'introduction des interfaces graphiques et l'amélioration des interfaces Homme-Machine, l'univers informatique est devenu plus abordable par le grand public.

1°) Du concept de manipulation directe aux interfaces démonstratives

Le concept de manipulation directe permet à tout utilisateur de manipuler directement les données avec lesquels il travaille.

[Baulac 84] (p.100) "La manipulation directe des objets de l'application est le fait de pouvoir appeler directement un objet sans le recours à la description de cet objet dans un langage quelconque. Les objets de l'application sont soit des objets de contrôle (fenêtres, procédures, boutons, ...), soit des objets propres au domaine de l'application (des objets géométriques dans le cas de Cabri-géomètre)".

[Nanard 90] (p.42), [Bellemain 92] (p.100-103), [Carbonneaux 98] (p.6)" Les principes de la manipulation directe ont été jusqu'à présent plutôt mis en œuvre dans la conception d'interfaces graphiques permettant la manipulation, souvent nécessaire, d'objets informatiques à l'intérieur d'environnements informatiques. Ces objets ne sont pas représentés mais plutôt symbolisés par des images, et la manipulation du symbole représente pour l'utilisateur la manipulation de l'objet lui-même. Ces manipulations sont destinées plutôt à simplifier la mise en œuvre de notions informatiques intervenant dans l'utilisation d'un système qu'à permettre la construction de connaissances relatives à ces notions. Dans le cas d'environnements destinés à l'apprentissage, la manipulation directe s'applique à des représentations d'objets mathématiques et non pas aux objets eux-mêmes. "

Concrètement, une interface est dite de manipulation directe si elle possède les propriétés suivantes :

1. "Les objets concernés ont une représentation permanente,

2. Des actions physiques directes ou l'appui sur des boutons étiquetés sont utilisés au lieu de commandes textuelles de syntaxe compliquée,

3. Le résultat des actions sur les objets est immédiatement visible,

4. Les opérations sont rapides, incrémentales et réversibles." [Shneiderman 82] (p. 239 ) 5. "Les transformations sont contrôlables en temps réel". [Laborde 95] (p. 36)

6. Le déplacement des objets concernés doit être continu. 7. Tous les objets représentés doivent être manipulables.

8. La création des objets s'effectue naturellement et directement.

9. Aucun ordre sur les éléments des procédures." [Carbonneaux 98] (p.23)

Avec des interfaces respectant ce mode de manipulation, l'utilisateur est plus à même de définir les comportements attendus de ces données, ou plutôt leur réactions en fonction de ses manipulations.

L'idée est apparue de donner à tous les utilisateurs, quels que soient leurs profils, les moyens de définir eux-mêmes les tâches qu'ils désirent ordonner aux ordinateurs, en leur donnant les moyens de communiquer directement avec l'ordinateur. [Myers 90] définit les interfaces démonstrationnelles comme des interfaces capables de générer de nouveaux outils utilisables dans l'interface elle-même et définis par démonstration, où le terme "démonstration" ayant ici le sens de « présentation ».

2°) Une diversification des intervenants et une évolution des tâches

Auparavant, dans toutes les activités informatiques, l'utilisateur était différencié du programmeur. L'évolution de l'usage de l'informatique conduit à modifier cette différenciation des types d'utilisateur de l'ordinateur [Myers 95].

Considérant les moyens informatiques non plus comme un magasin (un serveur) d'applications mais comme un environnement permettant d'en fabriquer, le programmeur devient tout autant client de services informatiques que l'utilisateur final, celui pour lequel sont prévues ces applications, et qui est éventuellement non informaticien.

De même que le programmeur devient client des logiciels qui constituent les environnements de programmation, l'utilisateur final commence à être à même d'utiliser des outils de fabrication ou d'ajustement de ces environnements. Apparaît une évolution du statut de l'utilisateur, mais tout aussi bien du programmeur, et même une nouvelle catégorie de protagonistes : ceux dont le travail est la mise au point et la conception d'activités propres au domaine d'application du logiciel.

Ainsi, autour d'un environnement donné (en plus de l'ergonome) "collaborent" trois types de personnes : celles qui fabriquent l'environnement, celles qui utilisent l'environnement pour mettre au point des activités du domaine (les experts du domaine) et les utilisateurs finals.

Considérons un tableur comme Excel. On différencie les concepteurs du logiciel lui- même, des concepteurs de fiches, des utilisateurs des fiches conçues.

Les besoins de l'utilisateur final sont des besoins de "client" par rapport aux fiches : il ne peut qu'y entrer des données. L'utilisateur concepteur de fiches est par exemple un expert en comptabilité. Il prépare des tableaux dans lesquels seules certaines cellules sont modifiables. Les autres cellules s'ajustent automatiquement par les calculs qu'il a prévus, ou restent identiques. Les concepteurs du logiciel sont ceux qui ont prévu le fonctionnement global du logiciel. Ils ont su trouver les solutions permettant à l'ordinateur de supporter les fonctionnalités intéressantes pour la fabrication de telles fiches, différencier les niveaux de fonctionnements adaptés aux différents types d'utilisateurs aval du logiciel.

La chaîne de vie du logiciel se trouve modifiée : au lieu de boucler entre le programmeur et l'utilisateur, le logiciel est ajusté entre le programmeur et l'expert du domaine. C'est l'expert qui est à même de sonder l'adaptation du logiciel et de ces "fiches" aux attentes de l'utilisateur final.

Dans les EIAH (Environnements Informatisés pour les Apprentissages Humains), le même type de différenciation apparaît : les concepteurs de l'environnement (programmeurs et ergonomes), les concepteurs des activités (professeurs) et les utilisateurs (exécuteurs de ces activités : les élèves) interviennent dans le cycle de vie du logiciel avec des fonctions distinctes.

Dans les environnements graphiques de programmation, les concepteurs de l'environnement sont des programmeurs aidés d'ergonomes, les concepteurs des applications sont des utilisateurs de l'environnement de programmation, éventuellement non informaticiens, et les utilisateurs des applications sont a priori non informaticiens. Ces derniers sont appelés les utilisateurs finals (end users en anglais).

La différence principale avec les environnements de programmation classique comme CodeWarrior, est la qualité (profil) des utilisateurs supposée par l'environnement : dans le cas classique, ce sont des informaticiens, alors que dans le cas graphique, tous les niveaux de familiarité sont attendus.

L'informaticien voit une évolution de sa tâche : ce n'est plus l'utilisateur des ressources informatiques qui doit s'adapter au seul moyen de communication possible avec l'ordinateur, mais c'est ce moyen de communication qui doit être adapté à tous les types d'utilisateurs et qui doit être capable de s'adapter aux besoins de l'utilisateur. La tâche du programmeur, souvent aidé d'un ergonome, est alors de mettre en place les environnements. Elle n'est cependant pas déconnectée du domaine d'application, puisque les choix d'environnement doivent être liés aux besoins des activités, et des conceptions de ces activités.

Les nouvelles tâches du programmeur prennent essentiellement deux directions :

• Définir la structure de l'interface et son comportement,

• Construire des outils pour la réalisation d'interfaces (cf. paragraphe précédent).

Pour ouvrir la possibilité à des non-informaticiens de fabriquer leurs propres applications, les environnements doivent remédier aux principales difficultés inhérentes à la programmation textuelle par langage informatique pour les non informaticiens.

"Spreadsheets and visual programming languages raise a challenge for existing schema- based models of programming knowledge, which have been scarcely been applied outside Pascal- like languages." [Green 95].

Ces difficultés proviennent essentiellement de trois sources :

• la nécessité de raisonner de façon abstraite pour programmer des abstractions d'actions (noms de fonctions ou d'actions) agissant sur des abstractions de valeurs (variables),

• l'obligation de suivre une structure rigide qui contraint l'expression textuelle naturelle selon le seul carcan formel compréhensible par l'ordinateur,

• l'obligation d'utiliser la forme langagière comme média de communication alors qu'elle ne constitue pas nécessairement toujours ni pour tous le support adéquat des mécanismes de raisonnement humain engagés dans la tâche.

Le premier point concerne les difficultés liées à la programmation en aveugle, c'est-à-dire sans aucun moyen pour identifier les actions avec leurs effets sur les variables et ces dernières avec les valeurs en jeu. Il est atténué par l'utilisation de la manipulation directe.

Le second point ne remet pas en cause la forme textuelle du support. Il est lié à l'utilisation d'un langage formel et non pas naturel.

Par contre, le dernier point met en doute le choix de la forme textuelle du support si la volonté d'aider l'utilisateur à formaliser ses raisonnements est pris en considération.

3°) La place des diagrammes comme aide au raisonnement

L'intérêt de l'utilisation de diagrammes pour le raisonnement humain est un sujet récurrent de l'histoire des sciences. Avec l'informatique et les interfaces graphiques, il réapparaît tant pour les domaines d'application comme les mathématiques, que pour l'activité informatique elle-même.

Dans les domaines d'application comme les mathématiques, la question du support du raisonnement humain est abordée régulièrement. Par exemple [Barwise & Etchemendy 91] étudient l'intérêt de l'utilisation de diagrammes pour des activités de démonstration en mathématique, et plus particulièrement en géométrie, théorie des ensembles et logique. Ils argumentent sur la légitimité d'inférences hétérogènes (visuelles et textuelles) en prenant comme arguments l'universalité de la représentation linguistique et les dangers de la représentation visuelle :

"despite the obvious importance of visual images in human cognitive activities, visual representaiton remains a second-class citizen in both the theory and practice of mathematics.[...] The main reason for the low repute of diagrams and other forms of visual representation in logic is the awareness of a variety of ill-understood mistakes one can make using them : witness the fallacies that have arisen from the misuse of diagram in geometry. By contrast, it is felt that we have a fairly sophisticated semantic analysis based on reasoning."

Ils établissent ainsi la raison d'être de leur logiciel "Hyperproof" : permettre à des étudiants de résoudre des tâches de raisonnement déductif à l'aide d'une combinaison intégrée d'énoncés et de diagrammes.

Pour l'activité informatique, le sujet réapparaît avec les interfaces graphiques. D'abord dans le cas d'applications graphiques à des domaines particuliers où le raisonnement est important, de nouvelles possibilités sont explorées pour visualiser les phénomènes. Dans le cadre de la géométrie et du logiciel Cabri-géomètre, [Laborde C. 93] fait état du double rôle de la visualisation en géométrie : ce logiciel permet d'explorer des constructions et de valider des conjectures. Une figure peut-être considérée comme une expérience graphique destinée à vérifier visuellement une propriété géométrique ou à supporter le raisonnement. En fait, le retour d'information procuré par le programme n'est pas seulement de nature perceptive, mais aussi de nature conceptuelle : c'est parce que les étudiants ont une idée a priori de quelques invariants de la figure qu'ils seront convaincus de l'inexactitude de leur solution. Dans le cas de Cabri-géomètre, ce n'est pas seulement la composante graphique qui agit pour apporter de l'aide au raisonnement, mais son animation et sa réponse aux manipulations, donc sa composante dynamique.

Ensuite, apparait la question du support graphique et de ce qu’il apporte à l'activité informatique elle-même : au travers de ces interfaces, les technologies de manipulations maîtrisées aujourd'hui apportent la possibilité de définir graphiquement les programmes soit à l'aide de la souris, soit plus récemment par interprétation de tracés effectués à main "levée".

Les publications regroupées dans [Addis & al. 98], le recueil d'articles qui a servi de base à "Thinking with diagram" en 1998, témoignent des différents aspects de ce sujet. Par exemple y sont discutées :

• l'apport des diagrammes aux raisonnements humains liés en particuliers à l'utilisation de machines [Olivier 97],

• l'usage fait des diagrammes selon le niveau d'expertise de l'utilisateur [Scaife & al. 98]

• L'influence des places respectives des diagrammes et des programmes dans la

communication avec l'ordinateur : programmer par le biais de diagrammes ou voir des programmes au travers de diagrammes [Blackwell & al. 98],

[Botshernitsan & Downes 97] rappelle ainsi les premières motivations des langages de programmation visuelle :

« From cave printings to hieroglyphics to paintings of Campbell's soup cans, human have long communicated with each other using images. The field of visual programming languages asks: why, then, do we persist in trying to communicate with our computer using textual programming languages? Would we not be more productive and would the power of modern computers not be accessible to awider range of people if we were able to instruct a computer by simply drawing for it the images we see in our mind's eye when we consider the solutions to particular problems? Obviously, proponents of Visual Programming Languages (VPLs) argue that the answer to both these questions is yes. »

L'apport de la composante visuelle produit principalement deux palliatifs pour atténuer les difficultés inhérentes à l'usage exclusif de langages formels pour toute activité de programmation. La programmation à l'aide d'un langage visuel propose la spécification de la structure logique du programme par l'intermédiaire de graphes, un peu comme les organigrammes. La programmation par démonstration s'appuie sur l'apprentissage automatique des processus utilisés par l'utilisateur lors d'activités de conception sur ordinateur.