Mathématice, intégration des Tice dans l'enseignement des mathématiques  
Sommaire > N°35 - mai 2013 > DGPad - Une approche tactile spécifique de (...)

DGPad - Une approche tactile spécifique de géométrie dynamique sur tablettes
Moteur de recherche
Mis en ligne le 16 mai 2013, par Yves Martin

La révolution tactile, toute naissante, en est probablement à ses premiers balbutiements. Et pourtant, déjà, ses premières réalisations contiennent parfois de jolies perles. C’est le cas, pour ce qui est de la géométrie dynamique, de DGPad. Tour d’horizon de cette application qui est encore une webApp au moment de la rédaction de cet article.

Mise à jour Juillet 2013
Désormais, sous Android, le navigateur standard est supporté et est très efficace pour utiliser DGPad.
Qui peut le plus peut le moins : on peut utiliser Chrome ou Firefox, ce dernier reste moins rapide pour le JavaScript.

Mise à jour Novembre 2013
Outre un module d’expression très complet, avec un clavier dédié, désormais, DGPad possède un module 3D intégré qui est présenté à cette page dans MathémaTICE.

Cet article, de mai 2013, ne parle que de la partie géométrique du logiciel. Le logiciel a beaucoup évolué depuis, y compris sa façon de mettre en ligne les figures.

Introduction

Plusieurs logiciels commencent à installer la géométrie dynamique (GD) sur les tablettes tactiles, et, pour certains, explorent dans le même temps les nouvelles potentialités des interfaces tactiles.

Certains partent du connu, comme Dr Geo qui a été le premier logiciel de GD sur la première tablette, l’iPad, en particulier parce que son code était facilement transférable. Mais ce n’est, justement qu’un transfert, pour le moment sans enjeux quand à l’approche tactile, au contraire même, il y a beaucoup de boutons à cliquer. GeoGebraWeb semble être aussi tenté par une voie proche de cette du transfert de code puisque GGW partage le code de l’applet GGB au sens où le code JS est rechargé dans notre cache à chaque nouvelle compilation de GGB. Pour le moment GGW est en cours de développement, même si chacun peut exporter en HTML 5 une figure GGB.

D’autres logiciels partent d’un moteur déjà connu comme solide et efficace, et travaillent leur interface tactile, avec originalité. C’est le cas de Sketchometry, construit sur le moteur de JSXGraph et dont les auteur ont fait un choix de manipulation directe résolument "du coté des gestes" pour la construction des objets mathématiques, en explorant les "gestures" pertinentes pour construire soit une perpendiculaire, soit un angle droit, ou encore un milieu.

D’autres choisissent d’aborder ces nouveaux supports avec un regard neuf et décident de tout réécrire, code et interface, à partir de la page blanche. Cela semble avoir été le cas de Geometry Designer, qui a eu dans ses premières versions une interface assez "minitel" et depuis a bien progressé en se dotant d’une roue d’outils un peu à l’image de la roue des iPod.

DGPad fait partie de cette dernière catégorie. Son auteur, Eric Hakenholz, a choisi de tout reprogrammer, en essayant, justement, de ne pas transposer le connu, mais de réinventer pour ce nouveau support. Bien entendu, l’auteur ne part pas de rien non plus. On sait qu’il a programmé CaRMetal pendant 5 ans, et en particulier ses CaRScripts en 2009, sa première internalisation des relations entre le JavaScript et un logiciel de géométrie dynamique.

Première et seconde internalisation - un parallèle audacieux

Chacun de nous a ses propres représentations des outils et concepts qu’il manipule, construites par nos pratiques et par des analogies issues de notre propre histoire culturelle, collective d’abord, individuelle ensuite.

Pour ce qui est de la culture collective, chacun sait que quelque chose de nouveau est né quand on a su décrire, puis construire, une machine qui savait traiter les informations qu’elle recevait, plus précisément, quand un même langage pouvait recevoir et traiter des données. On parle au sens large, de l’informatique (même si les spécialistes auraient des nuances à apporter sur le terme et le raccourci de cette présentation).

Dans la version individuelle, donc moins partagée, je parlerais de l’approche axiomatique de la géométrie. Klein définissait la géométrie comme la donnée d’un groupe qui laissait invariant un ensemble. Puis dans un travail de généralisation, pour obtenir une axiomatique qui contenait les trois géométries planes fondamentales, Bachmann a su opérer une seconde axiomatisation sur la géométrie euclidienne pour arriver une approche ultime de la problématique de Klein sur la géométrie : avec Bachmann cela devient l’étude d’un sous groupe particulier opérant sur un groupe donné.

Dans le premier exemple, quelque chose est né quand on a su fusionner le traitement et ce qui est traité. Dans le second, on atteint l’aboutissement d’une théorie, à nouveau quand l’action est un élément de ce sur quoi a lieu cette action.

Quel rapport avec DGPad ?

Les CaRScripts de CaRMetal, comme ils ont été conçus, sont des actions sur un support dynamique, qui plus est, riche de son interprétation mathématique des commandes : le logiciel de géométrie lui-même. En ce sens, c’’est une "première internalisation" car le JavaScript s’imbrique en profondeur avec les données de la figure (les fameux x_m, y_m pour ceux qui ont pratiqué). Je ferais le parallèle avec la problématique de Klein : on dispose d’un langage qui agit sur un logiciel. Avec des réalisations spectaculaires sur l’extension que cela permet du micromonde atteignable par la géométrie dynamique comme la panoplie du petit footballeur de Pierre Marc Mazat, ou des contributions plus modestes comme a pu en voir régulièrement sur le site de l’IREM de La Réunion par exemple.

Une seconde internalisation serait une situation à la Bachmann - ou à la Turing - si le traitement pouvait être véritablement de même nature que ce qui est traité. Or c’est précisément ce qu’a fait Eric : DGPad est, entre autre, une seconde internalisation du JavaScript dans la géométrie dynamique, car le traitement et les données traitées sont tous les deux des fichiers JavaScript, et reconnus explicitement comme tels.

On comprendra que cela ouvre des perspectives assez inouïes. Tellement même que certaines fonctionnalités, normalement attendues, n’ont pas encore été implémentées dans la première version que nous étudions ici, pour prendre le temps du recul sur l’interface à proposer.

Au moins conceptuellement - même si ce n’est pas encore toujours mis en oeuvre dans l’implémentation actuelle - DGPad est donc à la fois un aboutissement, et une expression nouvelle, de ce qu’a pu être le projet initial de la géométrie dynamique.

Par essence, étant construit de la même façon, a priori Sketchometry dispose du même potentiel, mais il semble que les auteurs ne soient pas - pas encore pour le moment - concernés par cette option. Par exemple dans les présentations vidéo de Sketchometry, on peut lire, par les auteurs des figures, que la droite d’Euler est déjà une figure relativement complexe pour ce logiciel. Clairement, DGPad est construit pour d’autres horizons : deux semaines après sa mise en ligne, nous avions pu réaliser - avec un logiciel qui n’a pas encore ni nombre ni expression algébrique - un pavage hyperbolique de génération 2, à plus de 3100 objets.

Voir cette figure en copie d’écran et ses objets cachés

La figure est manipulable dans l’article - au doigt sur tablette - dans l’onglet Galerie Hyperbolique.

Structure de l’article

On a choisi de mettre en ligne dans l’article un nombre important de figures, dont certaines sont lourdes. Comme elles sont, en texte, à l’intérieur même de l’article SPIP, il a été nécessaire de découper cet article en deux parties :

Partie 1 : réflexion sur le transfert de support, prise en main du logiciel, et réalisations géométriques.

Partie 2 : consacrée aux scripts, elle est plus réservée aux enseignants de lycée qui peuvent avoir envie d’utiliser ce support soit pour pratiquer quelques TP d’algorithmique, soit encore pour des projets ISN : le JavaScript, par son interaction avec le HTML 5 est désormais non seulement pérenne, mais devenu un langage de script utile à pratiquer.

Les figures en ligne sans dans le texte de l’article mais elles nécessitent un appel à DGPad par un bouton. On verra en détail, dans l’onglet Interface de DGPad pourquoi ce choix de l’appel des figures par bouton a été nécessaire dans le contexte de cet article.

Présentation de la première partie

Dans la barre d’onglets suivante on trouvera successivement

1. Sketchometry et DGPad : présentation générale et analyse des choix des deux logiciels
2. La problématique du "touch" : toucher n’est pas cliquer. Tracé au doigt et palettes contextuelles
3. Interface de DGPad : les autres outils que ceux vus dans l’onglet précédent
4. Les macros de DGPad
5. La notion de micromonde : approche générale. Le cas de DGPad.
6. Galerie 1 (cercles coniques barycentres)
7. Galerie 2 (hyperbolique, dont pavage)

La mise en œuvre de scripts programmés est abordée dans cette seconde partie


Sketchometry et DGPad

Sketchometry et DGPad

Commençons par une comparaison entre ces deux logiciels écrits en JavaScript, Sketchometry et DGPad, du point de vue de l’interface et des choix d’intégration du tactile.

Les deux logiciel ont en commun d’avoir pris en compte la dimension tactile du nouveau support que sont les tablettes tout en choisissant d’être aussi disponibles sur ordinateur.

Les choix d’interface fait par les développeurs sont lourds de conséquence dans le cadre d’une utilisation scolaire. La question essentielle est celle de la géométrie du geste que l’on veut construire. Quelles représentations des propriétés géométriques souhaite-t-on favoriser ? Pour quelle conceptualisation ? Tout est à construire en ce domaine, tout est à inventer.

Pour la construction d’objets géométriques, les deux logiciels font preuve de d’originalité et de créativité dans leur rapport au tactile. Ils proposent néanmoins des approches fondamentalement différentes qui vont influencer les possibilités effectives de réalisation et donc, nécessairement, le public visé pour une utilisation en classe.

Ce qui a précédé au tactile

Reprenons, très rapidement, l’état de l’art en la matière. Deux approches principales existent pour la création d’objets (ou l’application de macro-constructions) :

• celle issue de Cabri-géomètre, reprise par la plupart des logiciels de GD dont GeoGebra : les items de création d’objets de base ont naturellement un "fil à la patte", on entend par là que l’objet est préconstruit par anticipation avant le dernier clic de souris. D’un point de vue didactique, cela s’analyse en terme d’engagement direct (prise en compte de la connaissance de l’utilisateur de ce qu’il est entrain de faire).
Par contre, dans les constructions, les prémisses doivent être toutes désignées avant la construction de l’objet : la médiatrice de deux points ne peux être construite que quand les deux points sont désignés alors que la création d’un cercle de centre O passant par un point A est anticipée et suit le mouvement de la souris avant que l’utilisateur clique pour désigner le point A. Géogebra a néanmoins bien évolué sur ce point dans ses dernières versions, au moins sur quelques items, à cause du projet GGBPrim ... et peut-être de CaRMetal ;-)

• celle issue de CaR (et dont a hérité CaRMetal) : on choisit toujours de définir les constructions en choisissant - quand cela a un sens - un point comme dernière prémisse à désigner, et alors, la construction anticipée des objets existe pour toutes les constructions, même dans le nommage automatique de points ou dans des macro-constructions complexes.

On a déjà analysé ici (page 10 numérotée 174) en quoi le choix de ne pas ordonner les prémisses (*) avait été vécu comme une avancée en tant qu’engagement direct car elle ne contraignait pas les choix des élèves, contrairement aux toutes premières versions de Cabri. Cette "avancée" a fait passer toute une génération de formateurs et d’élèves à côté de la construction anticipée des objets, pourtant source de visualisation de schèmes et donc source de conceptualisation plus grande de ce qui est anticipé.

(*) Pour prendre une perpendiculaire à une droite passant par un point, on peut choisir de montrer le point ou la droite en premier car il n’y a pas, en soi, de hiérarchie mathématique - même si oralement tout le monde dit "la perpendiculaire à la droite d passant par le point A". Ordonner les prémisses avait été perçu comme une contrainte informatique dont il fallait se débarrasser.

On va voir que DGPad va tenter de poursuivre dans la lignée de CaR et CaRMetal en offrant l’anticipation des constructions de ses objets alors que Sketchometry va plutôt s’installer dans l’autre voie, avec cette volonté de dépasser néanmoins cette ambiguïté subtile entre création et construction d’objet.

Quelques gestes communs ou proches

Tout d’abord signalons que DGPad doit être placé en mode trait (2° icone du tableau de bord) pour interpréter le tracé au doigt, tout comme Sketchometry doit être en mode construction.

Le choix des mots a du sens : si DGPad a un mode "trait", on peut penser qu’il ne va pas reconnaitre des courbes (le cercle) alors que Sketchometry propose la reconnaissance de cercle, d’où la désignation plus générale de son mode "construction".

Reconnaissance du tracé de lignes droites

Le tracé des "lignes droites" en général est assez proche et montre, dans les deux cas, une belle finition de l’engagement direct. Voici cinq copies d’écran (en réduction) tout d’abord deux de DGPad, deux de Sketchometry et une de DGPad.

Commentaire sur ces copies d’écran :

• Le retour textuel de Sketchometry, dans une fenêtre dédiée : elle permet à l’utilisateur de savoir comment son geste est actuellement interprété par le logiciel. En définitive c’est la désignation de l’objet qui valide l’action et donc la conceptualise : on a une conceptualisation par désignation. On notera, en opposition à cela, la confirmation visuelle des éléments de construction d’une droite.

• Le choix délibéré de DGPad de ne pas avoir de référence textuelle, mais au contraire une anticipation graphique. Pour DGPad c’est la visualisation de l’objet mathématique qui est à la fois la confirmation de la prise en compte de l’action et de la conceptualisation du geste en cours de réalisation.

Dans les deux cas on notera la subtile anticipation : tant que la droite ne passe pas explicitement par les deux points elle peut changer à tout moment.

Petit clin d’oeil à un grand initiateur de bien des vocations en géométrie dynamique : dans le retour graphique de DGPad, les plus anciens des lecteurs de MathémaTICE peuvent repérer une "culture Cabri" chez l’auteur du logiciel. En effet, Jean Marie Laborde - fondateur du projet Cabri-géomètre - a souvent expliqué dans ses présentations la subtilité ergonomique - et "euclidienne" - qui consiste à ne pas construire la droite sur tout l’écran, mais de reproduire une petite portion du plan euclidien comme quand on travaille dans l’environnement papier crayon : didactiquement, on reste dans le micro espace du geste effectué, c’est donc une attitude qui respecte l’état d’esprit de l’élève au moment de sa manipulation (plutôt que de conceptualiser trop vite en traçant la droite ’entière’ pendant le déplacement à la souris). Même si on ne pratique plus beaucoup Cabri-géomètre, l’enseignement du maître est toujours bien présent ...

Dans les deux logiciels la droite "entière" est construite au lâcher de souris, et dans les deux, l’anticipation d’une droite se transforme immédiatement en demi-droite si on s’arrête à un des points (illustration 5).

Mais en dehors des gestes sur les mouvement primordiaux comme ceux-ci - il y a les intersections "par caresse" - la relation au tactile va rapidement fortement bifurquer entre les deux logiciels.

Sketchometry : le geste conceptualisant ?

Le choix de Sketchometry est, pas uniquement mais principalement, du côté du perceptif au sens où l’utilisateur va devoir reproduire kinestésiquement un geste en rapport avec une définition ou une propriété de l’objet à construire, comme ceux-ci pour l’orthogonalité et le parallélisme :

Pour l’orthogonalité, le premier trait peut passer par un point, ce sera alors la perpendiculaire à la droite issue de ce point. On peut émettre l’hypothèse de travail qu’à l’usage ce geste participe à la conceptualisation de l’orthogonalité.

Le choix du geste pour le parallélisme est probablement moins universel. Il peut être significatif, soit d’un rapport précoce aux angles en Allemagne, soit d’un niveau d’enseignement privilégié.

En effet, le geste produit renvoyant aux angles alternes internes égaux, ne sera conceptualisant, en France qu’au collège (en classe de 5°). Ce geste ne sera porteur d’aucun sens sur des élèves de cycle 3 de l’école primaire alors qu’une double orthogonalité - pas plus difficile à reproduire - aurait été un geste conceptualisant très tôt des relations entre orthogonalité et parallélisme, et même exploitable d’un point de vue argumentatif, dès la classe de 6°.

D’autres gestes sont proposés qui, s’ils veulent rappeler une propriété, ont un rapport assez lointain avec ladite propriété. C’est le cas du milieu et de la bissectrice :

Dans les deux cas la boucle symbolise une symétrie. Elle est centrale quand elle est ronde - et s’applique à des points, elle est axiale quand elle est allongée - et s’applique à des droites. Dans les deux cas, les objets doivent être construits préalablement, il n’y a pas de construction à la volée, comme le milieu d’un point et d’un point construit à la volée, en lâchant l’objet milieu.

Ce choix de gestes pourrait paraître arbitraire, mais il est possible que non, et cela pourrait être lié à une culture allemande : chez Bachmann, en géométrie absolue, Mittlepunkt (centre) signifie à la fois milieu mais aussi "point bissecteur" dans un contexte particulier qu’il serait trop long à rappeler ici. D’où cette proximité des gestes qui peut vouloir rappeler une certaine proximité conceptuelle.

On voit poindre une difficulté dans cette démarche "tout geste" car il faut parfois apprendre à faire, correctement, des gestes qui sont perceptivement loin du concept mathématique initial. La conceptualisation fonctionnera probablement - cela peut être une hypothèse initiale de travail pour concevoir les premières activités en classe - sur les gestes qui sont directement en rapport avec la perception que l’on a des objets en jeu. Il n’est pas sûr du tout qu’elle fonctionne sur d’autres gestes. Il sera intéressant d’étudier les représentations engendrées par ces nouveaux schèmes d’action.

Les limites didactiques de la reconnaissance du geste

Il y a bien entendu d’autres gestes, dont plusieurs pour le cercle même si, en général, il faut surveiller le retour textuel pour savoir si on est entrain de construire un cercle ou un quadrilatère : la différence entre quadrilatère et cercle demande un peu de pratique.

D’un point de vue informatique, ces illustrations de pré-cercle et de pré-quadrilatère illustrent la qualité de la reconnaissance du geste : dans le cercle il n’y a qu’un geste anguleux, dans le quadrilatère le logiciel semble en avoir repéré deux. La reconnaissance peut être présentée comme pertinente car, dans un geste rapide, un enfant ne devrait pas faire plus d’un a-coup avec un geste anguleux. Reste à savoir à partir de quand on fait un geste rapide.

D’un point de vue didactique, ces exemples illustrent tout autre chose. Ils relativisent les capacités de la reconnaissance informatique du gestes comme outil participant à la conceptualisation des objets mathématiques. Le logiciel n’apparaît plus comme une aide à la conceptualisation des objets, il est un outil dont il faut apprendre les interprétations pour pouvoir l’utiliser. Et clairement ce n’est pas ce qu’attend la communauté éducative de l’évolution de la géométrie dynamique.

Car si on fait le choix de reconnaitre les cercles, la programmation de la procédure de reconnaissance est confrontée non seulement au problème de la classification des formes, selon les micro-gestes effectués, mais aussi à la représentation que les élèves ont des objets engagés..

C’est un peu le dilemme d’une enseignante de GS ou CP qui, dans l’apprentissage de l’écriture cursive, doit choisir de valider quelque chose qui est entre un d et un a, ou entre un u et un v : elle, au moins, a l’interaction langagière pour commenter son choix ou son non choix, ce que le logiciel tente - intelligemment d’ailleurs - de faire par la rétroaction textuelle en temps réel.

Il reste que si l’élève veut faire un cercle, en même temps qu’il accomplit un geste, il doit vérifier comment ce geste est interprété en temps réel par le logiciel : on n’est plus vraiment dans une activité mathématique.

C’est pour éviter cela - qui doit demander beaucoup d’énergie de mise en oeuvre - que DGPad s’est limité à la reconnaissance des traits et ne cherche pas à tenter de reconnaitre les cercles.

Sketchometry : les innovations du logiciel

Parmi les autres innovations on mentionnera un vrai multitouch avec deux doigts sur une droite, construite avec ou sans points (illustration de gauche). Au moment où cet article est écrit, Sketchometry semble bien être le seul logiciel ayant un vrai multitouch sur tablette (en dehors du zoom classique s’entend)

Pour certains outils, on peut récupérer des données par un toucher long, on copie ainsi la longueur d’un segment ou le rayon d’un cercle (illustration centrale). Là aussi cela semble être une innovation qui pourrait être rapidement reprise par d’autres logiciels.

L’interface tactile est donc l’occasion de réinventer la manipulation des objets en particulier en dépassant la typologie ancienne sur la distinction entre création et construction. C’est encore le cas avec une variante du geste d’orthogonalité adapté à la tangente à un cercle en un point du cercle (illustration de droite).

Quel cheminement vers la conceptualisation des objets géométriques ?

Avec une interface aussi tactile pour la géométrie dynamique, Sketchometry propose un nouveau regard sur la façon d’accompagner les élèves depuis leurs pratiques perceptives, réinvestie de manière kinesthésique ("au doigt") vers leur conceptualisation des objets (cycle 3 de l’école primaire, début du collège).

Parce que le logiciel reconnaît les formes et les transforme - tracé plus ou moins rectiligne transformé en droite, « rond » transformé en cercle – cette géométrie va accompagner le cheminement du perceptif vers les figures idéales de la géométrie autrement que ce qui a pu se faire jusqu’ici en géométrie dynamique.

Deux premières questions se posent au formateur :

a) la question de la genèse instrumentale. Comment la pratique de l’interface va-t-elle être appréhendée par les élèves ?

En effet, on l’a vu sur le milieu ou le cercle, même pour des figures simples une certaine dextérité est nécessaire pour construire les objets : les élèves, habitués aux écrans, vont-il développer une "dextérité tactile" plus efficace que celle de la "manipulation des instruments" de l’environnement papier crayon ? La manipulation va-t-elle finalement être plus complexe ?

b) la question de la sortie du perceptif. En effet, au doigt, il faut reproduire un dessin qui représente l’orthogonalité ou symbolise le parallélisme. Et même si bien entendu le logiciel répond par une construction de géométrie dynamique, l’interface semble cantonner l’élève, par répétition du geste, dans sa représentation de dessin géométrique, car c’est un dessin sur l’écran qui crée un objet.

Seule l’expérimentation en classe, à différents niveaux, permettra d’aborder plus précisément ces questions.

DGPad : le geste conceptualisé

L’approche de DGPad est très différente. On a vu qu’il y a des gestes primordiaux sur les lignes droites et les polygones, mais pour le reste le logiciel a choisi de s’installer dans un registre plus mathématisé, avec des palettes d’outils contextuelles.

En fait, le mode standard du logiciel ne contient pas le dessin au doigt des figures de base, il faut se placer dans un mode trait spécifique. Pour le concepteur, cela évite des interactions malheureuses entre un travail de construction et des triangles qui se construisent automatiquement parce qu’un petit doigt traine sur la tablette. En fait cette séparation a été faite après plusieurs séances d’utilisation en classe, environ un mois après la sortie officielle du logiciel.

Voici les quatre principales palettes contextuelles attachées, respectivement, à un point, à une droite, à un cercle et à un segment (ici en taille réduite)


Il y a ainsi 14 outils associés à un point (un quinzième apparaîtra à l’occasion). En effet, à la différence de Sketchometry (dans la version disponible au moment de la rédaction de cet article : 0.2.26), tous les points constituants des objets proposés peuvent être construits à la volée : ainsi que ce soit un simple milieu de deux points, le cercle circonscrit à trois points ou encore un polygone quelconque, tous ces objets peuvent être choisis, car ils peuvent être construits à partir d’un premier point à l’écran.

On remarquera que les icônes suivent un code couleur rigoureux - ce qui n’était pas toujours le cas pour CaRMetal : les prémisses des objets en gris clair, l’objet construit en blanc. Pour l’outil "milieu", on dispose d’une icone spécifique car on peut montrer aussi bien les deux points que le segment. Cela évite, comme dans le cas de CaRMetal, que la différence avec l’outil "symétrie centrale" ne diffère que du code couleur.

Les trois autres objets de base peuvent accepter un point sur objet. Le segment a deux outils disponibles de plus que la droite : le milieu et la médiatrice.

Il y a, bien entendu, un geste particulier pour utiliser ces outils à trois ou plusieurs points, et c’est bien d’un seul geste à apprendre qu’il s’agit. Nous reviendrons dans le prochain onglet de présentation de l’interface de DGPad.

À la différence de l’analyse que l’on a proposé pour l’usage de Sketchometry, ce geste n’est pas conceptualisant pour les objets, il est déjà conceptualisé, au sens où l’on choisi un objet mathématique à construire. La conceptualisation du geste est ailleurs.

DGPad : une autre forme de conceptualisation ?

En effet, une des spécificités des outils de DGPad, c’est leur anticipation des constructions, à l’image de ceux de CaRMetal. Dans le cadre d’une utilisation tactile cette anticipation peut être d’abord interprétée comme un contrôle de l’action de l’utilisateur, immédiat et direct, sans passer par le registre textuel.

Mais, on l’a déjà analysé plus haut, cette anticipation, systématique sur tous les outils, participe d’autre chose. Elle accompagne la conceptualisation des propriétés des objets : quand on déplace le doigt, si on a choisi l’outil perpendiculaires, la perpendiculaire pré-construite suit la souris, et donc l’utilisateur voit toutes ces droites perpendiculaires à la première et parallèles entre elles. De même si on choisit ensuite une perpendiculaire à la première droite, cette perpendiculaire au bout le souris paraît être aussi parallèle à l’autre perpendiculaire, les parallèles au bout de la souris semblent également parallèles entre elles etc ... L’anticipation des outils laisse à voir non plus l’objet idéal mathématique en cours de construction, mais bien des propriétés géométriques des objets.

Ici illustré en mode projection : le disque jaune permet de suivre
au vidéo projecteur où est le doigt du manipulateur sur la tablette

• Illustration 1 : prise d’une perpendiculaire à la droite initiale. L’anticipation permet de voir - éventuellement de verbaliser - des propriétés sur "perpendiculaire" ou "paralléle".
• Illustration 2 : la perpendiculaire est tracée, on va choisir un nouvel outil à partir de la droite initiale (les autres icones seront détaillée à l’onglet "Interface DGPad".
• Illustration 3 : on a choisit parallèle, là encore on peut visualiser des propriétés que l’on peut faire verbaliser collectivement.
.

Dans les cas simples (une perpendiculaire à une droite par exemple), cette anticipation peut même participer à la conceptualisation des propriétés des objets (ici les perpendiculaires à une même droite sont parallèles entre elles).

Dans des cas plus complexes comme ci-dessus ce qui est perçu ne débouche pas nécessairement sur une conceptualisation individuelle, mais peut être décrite pendant le mouvement avant la construction finale, et faire émerger ainsi des prises de consciences de la démarche hypothético-déductive.

On retiendra que la conceptualisation que permet l’anticipation des construction ne se fait pas tant sur l’objet mathématique lui-même que sur ses propriétés sous-jacente, en général en relation avec un autre objet géométrique.

Retour à la barre d’onglets (vers DGPad)

Le toucher DGPad

Du clic de la souris au toucher de l’écran

Pour mieux comprendre les choix effectués pour l’interface par l’auteur du logiciel, commençons par une réflexion préliminaire sur la différence entre l’usage de la souris et du toucher de l’écran. Il y a, au moins deux points de vue, celui de l’utilisateur final et celui du concepteur.

Pour l’utilisateur

On a beau en être conscient, savoir intellectuellement que l’expérience utilisateur de la géométrie dynamique sur tablette va être différente que celle sur ordinateur, en fait, avant d’avoir touché une tablette et un logiciel réactif, on ne sait pas exactement comment va être ressentie cette différence. Toujours intellectuellement on imagine la difficulté des élèves dans l’instrumentation, l’idée qu’il faut conserver le doigt sur la tablette pour continuer son segment, des choses comme ça.

Puis viennent les premières constructions de figures. Et sans qu’on s’en aperçoive vraiment, elles prennent d’une certaine façon un côté un peu magique, on se sent comme un oiseau qui va picorer une graine : on choisit des yeux le point sur lequel on souhaite agir, et on pose le doigt dessus, comme un oiseau qui se poserait là où il a repéré une activité intéressante.

Du coup, le pointage par la souris prend tout d’un coup un sacré coup de vieux. C’est comme si avant on était dans Flatland, que pour aller d’un point à un autre il fallait franchir les distances sur l’écran, et que tout d’un coup quelqu’un - comme dans les films sur Flatland nous faisait voir la situation d’un peu plus haut, et qu’il n’y a plus de chemin plan, juste comme une géodésique en 3D pour aller au point voulu.

Bien entendu ceci ne vaut que pour le premier point d’un objet, mais se répète néanmoins à chaque nouvelle construction. Bien sûr qu’avec une souris, on regarde aussi le point sur lequel on va agir, et la souris va, d’une certaine façon quasiment toute seule tellement nous sommes habitué à cette interface, et pourtant, de fait, l’expérience utilisateur est vite subtilement différente, plus intime dans sa relation à la figure car le doigt va au point repéré par l’oeil, nous ne passons plus par un pointeur externe, le pointeur est partie intégrante de nous-même, d’où cette sensation de proximité ...

On voit alors tout de suite la différence avec la démarche de Sketchometry qui privilégie le kinesthésique et donc le chemin à l’écran, car c’est le chemin du doigt qui permet au logiciel de reconnaitre l’action que l’on veut faire : un quadrilatère ? un cercle ? et souvent il faut contrôler l’interprétation du logiciel ! Même prendre des milieux dans une figure déjà commencée est parfois délicat car le passage prés d’un objet est interprété comme une information cognitive par le logiciel alors que nous avions, nous, "extrait une figure simple d’une figure complexe" - selon un objectif scolaire bien connu - pour accomplir notre geste.

Bien entendu tout n’est pas aussi idéal dans le "pure tactile", le doigt peut gêner la vue, qui sert de contrôle de l’action en cours, alors que le pointeur de la souris, fin, ne se superposait à rien. Reste pourtant que l’expérience utilisateur est bien différente.

Pour le concepteur

L’approche est totalement différente. L’interface tactile est d’abord une interface de discontinuité du rapport à l’écran de l’utilisateur alors que la souris est un pointeur continu à l’écran : même si l’utilisateur lâche la souris, le système a toujours les coordonnées du pointeur quand la souris sera reprise en main. Au contraire, l’utilisateur d’une tablette touche l’écran, déplace son doigt, et lâche l’écran (TouchStart, TouchMove, TouchEnd) et à ce moment là, le concepteur n’a aucune possibilité de savoir où l’écran va être touché à nouveau. Dans le rapport homme-machine de l’interface d’un logiciel, le passage de l’ordinateur et son pointeur souris à la tablette et son pointeur doigt relève, d’un certain point de vue, du passage de la continuité à la discontinuité.

Dans CaRMetal, une des premières caractéristiques est probablement l’anticipation de toutes les constructions d’objet, alors pour son auteur, le premier objectif est de reproduire sur tablette cette anticipation des constructions, et en particulier des constructions à la volée de points en objet final des constructions. Dans un logiciel de GD associé à une souris, un point à la volée est créé au lâcher de la souris (dans un "OnMouseUp"). L’équivalent sur tablette est donc de créer un point à la volée à la suppression du contact avec la tablette (par un "TouchEnd").

Le problème se pose alors pour les objets ayant trois prémisses (cercle circonscrit, angle, arc, bissectrice) : il faut maintenir ce "fil à la patte" alors que l’utilisateur va rompre le contact avec la tablette pour signifier la création ou la sélection du deuxième objet. Avec une souris, la situation est continue, on peut poursuivre la construction "avec le fil à la patte" car la position du pointeur est connue. Sur tablette, il n’y a plus d’information venant de l’utilisateur, il y a une rupture, et il faut trouver une interface qui brise cette rupture pour recréer rapidement - naturellement pour ’utilisateur - la continuité de la construction anticipée.

C’est en particulier de cette réflexion qu’est née l’interface de DGPad, et plus spécifiquement le mode de fonctionnement des palettes contextuelles.

Le choix pour DGPad

Pour fixer les idées, prenons le cas d’un cercle circonscrit, avec, par exemple, trois points pré-construits, même si ce n’est pas nécessaire (mais plus parlant pour les copies d’écran plus loin).

L’outil cercle circonscrit étant sélectionné à partir d’un premier point, l’utilisateur glisse son doigt vers un second point, reconnu par rollover, il est donc surligné en gros (pour que l’on voit sous le doigt), il faut que l’utilisateur signale qu’il souhaite bien utiliser ce point comme second point du cercle circonscrit. Et si le point n’était pas créé, de même il faudrait pouvoir signaler que là où est le doigt on souhaite construire un second point. Il faut donc rompre le mode de contact avec la tablette.

A priori, il y avait deux choix possibles à ce moment de la conception de l’interface du logiciel pour rompre ce mode "contact avec un doigt".

Soit favoriser, dans la manipulation directe, un mode élémentaire, facile d’accès pour tous les élèves, même les plus jeunes, c’est-à-dire favoriser le mode "mono doigt" et donc la rupture du contact avec un doigt devient "plus de contact".
Soit être audacieux, et utiliser, dans les gestes les plus simples, les possibilités du multitouch et rompre le contact avec un doigt en ajoutant un second doigt.

Le second point, en tout cas pour des utilisateurs réguliers, aurait eu de l’allure, mais Eric Hakenholz, a choisi de rester sage, et de se contenter de ce que font beaucoup de logiciels pour le moment : réserver le multitouch à des taches très standards d’interface générale.
Techniquement, ce n’est pas une solution de facilité puisque, ce choix retenu, il lui a fallu concevoir une méthode transparente pour l’utilisateur pour conserver l’état de la figure en cours de construction après un touchend.

L’ analyse de son choix - dans un échange de mails - repose sur plusieurs arguments :

• Conserver une certaine simplicité : à part certains jeu, spécialistes d’interfaces conçues pour des joueurs invétérés, les logiciels sur tablette, même les plus importants, sont essentiellement mono-doigt pour leurs usages spécifiques, en dehors d’éléments de translation, homothétie et rotation (dans les logiciels de dessin en particulier).
• Par ailleurs, on notera que dans ces cas, l’utilisation de deux doigts est essentiellement une utilisation synchrone : les doigts vont dans le même sens ou pivotent autour d’un point. Introduire un second doigt comme pour simuler un clic droit par exemple serait une utilisation asynchrone encore peu voir pas répandue.
• L’activité multitouch asynchrone n’est pas vraiment compatible avec une utilisation ultraportable de la tablette, ou l’on tient sa tablette d’une main et manipule de l’autre main, ce qui est une utilisation largement répandue hors environnement scolaire.
• DGPad envisage d’être utilisé par des publics variés et dans des situations les plus diverses, en particulier en dehors de la classe, donc dans des situations d’ultraportabilité : il est préférable que l’interface soit la plus simple possible, en privilégiant les attitudes les plus élémentaires.

Après tout, nous en sommes à la première génération d’utilisateurs de tablettes tactiles : il faut construire et installer une pratique régulière avant de la faire évoluer : les premiers tableurs, même professionnels, n’avaient rien à voir avec ce que l’on connait maintenant, le multitouch asynchrone systématique n’est peut-être que pour la prochaine génération ...

Mais peut-être pas. L’auteur de l’article de désespère pas de motiver un étudiant à tenter d’explorer la réalisation d’une version où la rupture du contact avec un doigt soit effectivement un contact asynchrone avec deux doigts ... qui sait ... à suivre.

Mise en œuvre du choix retenu

La première réalisation est celle de l’anticipation des constructions pour un objet à deux prémisses comme un segment, une symétrie ou une médiatrice. Comme la copie d’écran ne prend pas en considération la position du doigt pointeur, les illustrations de cette partie sont faites avec un point final déjà préconstruit, mais rappelons qu’il peut être aussi construit à la volée par suppression du contact avec la tablette.

L’auteur de DGPad a tenu à ce qu’il n’y ait pas plus de "TouchEnd" pour construire un objet de DGPad que de clics de souris pour obtenir le même objet avec CaRMetal.

C’est donc réalisé pour les objets à deux prémisses. Voyons comment c’est aussi réalisé pour les objets à trois prémisses : il y a bien trois "TouchEnd" :

L’engagement direct au sein des outils

Un point final d’un outil peut non seulement être pris à la volée mais aussi pris à la volée comme intersection d’objets.

Voici deux exemples, avec illustration de la validation de l’intersection par manipulation dans le second exemple :

a - Avec une médiatrice


b - Avec un cercle circonscrit


Même si, d’une certaine façon, on n’en attendait pas moins de Eric Hakenholz, dont on connait la sophistication des interfaces, il n’en reste pas moins que cet engagement direct en cours de construction obtenu sur tablette est particulièrement sophistiqué, et au moment où est écrit cet article (mai 2013), unique sur tablette tactile.

Bilan de la palette contextuelle

L’interface retenue pour DGPad et le fonctionnement de sa palette contextuelle permettent de réaliser les objets de construction :
• avec le même confort visuel et la même implication cognitive
• avec le même nombre de gestes
que le logiciel CaRMetal.

L’engagement direct en cours de construction est remarquablement abouti.

Rien que pour cette première analyse des palettes contextuelles, le logiciel mérite largement attention par la communauté des enseignants.

Retour à la barre d’onglets (vers l’interface de DGPad)

Interface DGPad

Généralités

WebApp : au moment où cet article est écrit, DGPad est une application en ligne qui s’utilise dans un navigateur. On lance l’application depuis le site www.dgpad.net.
Même si nous allons détailler quelques points de l’interface, il est conseillé quand même de regarder les vidéos mises en ligne par l’auteur sur le site de DGPad.

Utiisation sur tablette : sous Androïd (version 4.xx ou plus) on peut utiliser le navigateur par défaut proposé sur la tablette, mais aussi Chrome ou Firefox. Sous iOS, on peut utiliser Chrome ou Safari.

Utilisation sur ordinateur : on peut utiliser au choix les navigateurs Chrome, Firefox, ou Safari, mais pas IE non conforme aux règles du HTML5). Noter que sur ordinateur on peut directement glisser un fichier DGPad (un fichier .txt) sur la fenêtre du navigateur quand l’application en ligne est ouverte.

Format de fichier : les fichiers sont des fichiers .txt. On abordera le format des fichiers dans l’onglet Macro et la manipulation des fichiers d’abord dans l’onglet Micromonde , et ensuite, bien entendu dans la partie 2 sur les scripts.

Présentation du "tableau de bord"

En général les différents outils sont fonctionnels dans un environnement dédié, à savoir quand une des icônes suivantes est sélectionnée. Cependant, certains éléments de l’interface sont génériques et disponibles dans de nombreux (ou tous les) modes du logiciel.

Les cinq premiers items

Pointeur - mode standard : mode de déplacement des objets a priori, c’est surtout le mode standard dans lequel les palettes contextuelles sont actives.
Les objets restent en effet déplaçables, en manipulation directe, dans les modes ou cela conserve du sens, comme Cacher/Montrer, Macro-construction, Inspecteur d’objets.

Mode traits : mode d’utilisation pour des constructions élémentaires au doigt.
Le logiciel interprète le geste pour reconnaitre les formes (segment, droite, demi-droite et polygone. L’intersection et le point sur objet sont disponible dans ce mode (voir la vidéo "Caresse" sur le site de DGPad). Mais il n’est pas si facile que cela de "caresser une intersection".
Le mode trait est particulièrement efficace pour construire des polygones quelconques. On notera que DGPad a fait le choix de ne pas tenter de reconnaitre le tracé d’un cercle.

D’un point de vue didactique, comme on l’a analysé dans le premier onglet, pour nous, ce mode trait est un mode transitoire de l’approche perceptive (kinesthésique sur tablette) vers l’approche plus conceptuelle de la géométrie (géométrie des propriétés descobjets), que DGPad met en oeuvre avec ses palettes contextuelles dans son mode d’utilisation standard.
On verra ce qui en sera fait à l’usage, mais - a priori - le mode trait est plus pour un usage en cycle 3 de l’école primaire, début de collège.

Utiliser la présence de ces deux modes, clairement distingués, dans le même logiciel est peut-être l’occasion de favoriser autrement - par le toucher de l’interface tactile - la transition d’une géométrie perceptive vers une géométrie plus conceptuelle non seulement des objets mais de leurs propriétés. Bien entendu ceci doit s’accompagner d’une instrumentation fine de ces deux modes et d’une ingénierie qui est encore à concevoir. Mais cela peut être une piste de recherche riche et intéressante.

Les palettes contextuelles ne sont pas actives dans le mode traits.

Cacher/Montrer : mode standard pour cacher ou montrer les objets.
Fonctionne comme les outils équivalents de Cabri II+ ou de Geogebra. En particulier ce mode ne correspond pas à la baguette magique de CaRMetal qui permet de poursuivre les constructions dans ce mode ... mais nécessite deux icônes (en lien avec la gomme).

Néanmoins, les objets de base de la figure sont accessibles et manipulables dans ce mode, ce qui peut être utile parfois, même dans des figures complexes.

On a pu voir - si on a regardé le pavage hyperbolique dans un bloc de l’introduction - que les macros construisent les objets intermédiaires avec le statut d’objets cachés. Il n’y a pas - pas encore ? - de mode "super caché" comme dans CaRMetal qui rend les objets intermédiaires des macros cachés même si on fait apparaître les objets cachés de la figure.

Supprimer : permet de supprimer des objets autres que les derniers construits (outils Annuler/Rétablir).

Si on utilise le bouton Efface toute la figure, on supprime en même temps toutes les macros de la figure. Pour les conserver, on supprimera les objets de base de la figure.

Macro-constructions : l’auteur de DGPad a innové dans l’interface de construction des macros comme on le verra dans l’onglet dédié à cet outil. La gestion des macros se fait, pour le moment, "à la main", dans le fichier texte. Voir l’onglet Micromonde plus loin.

Inspecteur d’objets

L’inspecteur d’objet est un outil classique de présentation individualisée des objets.

C’est d’abord l’icone à partir de laquelle on active le mode "projection".

Dans ce mode, un disque jaune symbolise un doigt virtuel pour que, lors d’une vidéo projection, le public ait une trace en temps réel des manipulations de l’utilisateur sur la tablette ... le doigt n’étant pas vidéo projeté ...

Ci dessus on construit une médiatrice entre le premier point et un autre point :
à gauche : le doigt de l’utilisateur va vers le point.
au centre : tout le monde - dont l’utilisateur ! - voit que le point a été atteint. Le doigt est encore en contact avec la tablette.
à droite : le doigt n’est plus en contact, la médiatrice est tracée, le disque est entrain de se résorber (rétroaction dynamique)

Modifications des attributs par lot
L’inspecteur d’objet permet aussi des manipulations par lot, plus précisément par type d’objets, comme dans l’illustration ci-dessous :

À gauche, des points, par défaut en taille 6 et en police 30, sont modifiés par lot ; à droite, en modifiant un seul point ils passent tous en taille 4 et en police 14.

Manipulation des curseurs de l’inspecteur d’objets : une fois un curseur pointé du doigt, on a tout à fait loisir de déplacer le doigt vers le bas en dessous de "Appliquer à tous" pour manipuler le curseur en voyant précisément les valeurs numériques affichées : elles ne sont pas ainsi cachées par la manipulation au doigt comme on pourrait le penser dans les premières manipulations.

Figures du cache

DGPad - comme Sketchometry d’ailleurs - utilise pleinement le cache HTML5 des navigateurs - cache qui fait souvent 5 Mo sur les tablettes, et 10 Mo sur ordinateur - ce qui permet de conserver les dernières figures en mémoire immédiate.

DGPad peut ainsi conserver jusqu’à 20 figures dans la mémoire du navigateur, figure que l’on peut cadenasser pour qu’elles ne soient pas vidées quand le cache est vidé par le système.

L’utilisateur - sauf utilitaires spécifiques peut-être - n’a pas la maitrise de cette partie spécifique du cache du navigateur (qui n’est pas celui accessible par les préférences usuelles) et en particulier pas du moment où le cache est vidé.

Une figure s’enregistre dans ce cache dès qu’on la supprime, en particulier par "Effacer toute la figure".

Les Exportations

Elles sont tournées vers l’utilisation dynamique en ligne. Il y a 4 modes d’exportation :

HTML et JS : le mode standard pour mettre une figure en ligne dans un site. Par exemple dans une page SPIP, si on reste au premier niveau de cette page, il suffit de mettre ce code entre les deux balises HTML.

On peut régler la taille de la fenêtre DGPad en précisant les paramètres width et height à deux endroits, au tout début du fichier et à la fin :

HTML seul : ce mode est à utiliser quand le mode précédent (avec utilisation du onload) ne fonctionne pas.
Dans ce mode, la figure n’est pas immédiatement accessible, il faut cliquer sur un bouton pour forcer l’appel à DGPad.

Le bouton fait 40 pixels de hauteur, donc la fenêtre d’export est plus grande de 40 pixels que la taille de la figure. Si on veut modifier les paramètres il faut respecter cette différence : la première donnée, en début de fichier, tient compte du bouton, le seconde en fin de fichier, non :

Rédaction d’articles SPIP incluant des fichiers DGPad :

La rédaction de cet article, assez long et rédigé en onglet, a mis en évidence que sur tablette - et sur tablette uniquement - l’utilisation des figures DGPad directement dans les onglets du Couteau Cuisse ne fonctionne pas. Il nécessite d’avoir recours à ce mode d’exportation pour que les figures s’affiche dans les onglets SPIP sur tablette.

C’est la raison pour laquelle, dans les prochains onglets, il faudra cliquer sur un bouton pour ouvrir les figures DGPad.

Cette précaution n’est pas nécessaire en général dans une page SPIP sans onglets. De même, sans avoir tout testé, a priori le premier mode fonctionne bien sous les ENT des établissements scolaires.

Page HTML : réalise une page HTML standard.

Ces trois modes codent la figure et appellent directement le moteur d’interprétation de DGPad, qui ne fait actuellement que 200 Ko si le module de texte MathJax n’est pas appelé. Les figures codées peuvent faire une dizaine de Ko à plusieurs dizaines de Ko.

Dans ces trois modes, on peut ajouter la barre d’onglets, l’utilisateur dispose alors du logiciel dans sa page de travail, comme avec les applets de Geogebra ou CaRMetal, mais avec un fichier environ 20 fois plus petit.
C’est en particulier pratique pour faire appliquer une macro en ligne, comme on le fera à l’onglet Micromonde.

Fichier texte : le fichier de DGPad tel qu’il est enregistré en mode texte. On utilisera souvent ce mode, en particulier sur ordinateur, par exemple pour regrouper plusieurs macro-constructions dans un même fichier, ou encore travailler sur le code JavaScript pour faire un fichier de script.

Charger / Déposer dans le nuage

On notera qu’on ne crée pas directement de nouveaux dossiers depuis l’interface. Mais tous les dossiers sont accessibles.

L’enregistrement sur ordinateur est possible mais, à l’usage, l’outil export est plus rapide pour conserver les fichiers sur son disque dur.

Nommage automatique

Fonctionne comme celui de CaRMetal : on indique à partir de quelle lettre on souhaite que les objets soient nommés automatiquement. Et on continue la construction avec ce mode sélectionné. Voici un exemple sur le milieu :

On remarquera que dans CaRMetal, même le nommage est anticipé , ce n’est pas le cas ici.

Axes

Permet de prendre des droites parallèles aux bords de la tablette, soit prototypiquement "horizontales" ou "verticales" dans le repère (ultraportable) lié à la tablette : avec l’outil droite parallèle on prend une parallèle à un axe passant par un point. De même pour droite perpendiculaire.

Encore peu utile d’un point de vue numérique, hors des activités de lecture, vu que l’on ne dispose pas d’outils pour travailler sur les coordonnées.

Les autres aspects de l’interface

Quand on clique sur un objet en mode standard, en plus de la palette contextuelle, on a généralement une liste de deux ou trois icones :
placement du nom de l’objet
ouverture de l’inspecteur d’objets
déplacement d’un objet après levée d’une ambiguité

Dans l’illustration ci-dessous (en mode "présentation" : gros doigt jaune), en bas à droite, les trois icones sous le point sélectionné.

L’illustration montre le fonctionnement de la première icone : le nom de l’objet est à l’opposé du doigt que l’on peut faire tourner autour de l’objet.

L’utilisation de la troisième icone est détaillée avec les ambiguïtés

La gestion des ambiguités

Quand deux objets sont superposés, il est important de pouvoir lever l’ambiguïté. Voyons un premier exemple archétypique au sens où la superposition est aussi topologique :

On a placé un petit polygone (marron) dans un plus grand. L’ambiguité permet de sélectionner le plus petit à l’intérieur du premier, alors l’icone de déplacement permet de saisir ce polygone et le sortir.

Mais cette troisième icone de déplacement a des utilisations plus fines. Dans l’illustration suivante, M est un point sur objet du segment [AB]. On place M en A. Alors si on clique sur les point confondus, par défaut - sans attente - on peut saisir M et le décoller de A. Si on veut déplacer A au lieu de M, on attend un instant, on lève alors l’ambiguité (ie on prend le premier objet créé) et dans ce cas la troisième icone permet de déplacer A :

Placé dans le mode standard, on a toujours aussi la palette contextuelle puisque l’on peut avoir choisi ce point pour une construction. Là il s’agit d’un cas d’école mais clairement ce type de situation se rencontre assez naturellement dans des constructions, en tout cas des constructions non triviales.

La dernière illustration montre bien la capacité d’engagement direct "complet" du logiciel, l’utilisateur pouvant choisir à chaque instant toutes sortes d’actions. Reste que l’instrumentation de cette richesse ne doit pas être un frein à l’utilisation en classe. On peut souhaiter que, dans une prochaine version, pour une utilisation en collège, le concept d’environnement resteint soit mis en oeuvre afin de limiter, pour des usages d’une séance, la foison d’outils à disposition comme ci-dessus.

L’aisance des élèves à manipuler l’outil n’est pas nécessairement en cause, mais plutôt la surcharge cognitive que peut produire cette proximité aussi riche d’outils à disposition.

Dans un logiciel comme Geogebra ou CaRMetal, bien plus d’outils sont à disposition des élèves, mais on n’y est pas confronté de la même façon que dans cette interface. Dans les logiciels, il faut aller les chercher - et les élèves perdent du temps à les chercher dans les menus de Geogebra par exemple - ici, toute la potentialité de ce que l’on va faire est concentrée autour du point sur lequel on travaille : c’est bien entendu un choix spécifique au tactile (et on a vu que "toucher n’est pas cliquer") mais il est souhaitable qu’à moyen terme, l’enseignant puisse maitriser l’environnement dans lequel vont travailler ses élèves comme on peut le faire dans les logiciels sur ordinateur en pouvant faire des choix sur l’apparition des icones de traitement et celles des outils contextuels.

Clairement nous sommes ici dans une première version qui met en place ses propres potentialités et qui affinera, avec le temps, approche didactique de sa propre richesse.

Voyons, pour terminer cette présentation générale de l’interface, que le traitement de l’ambiguïté fonctionne aussi pour plus de deux objets :

A partir de deux points on a construit le segment, une demi droite et la droite. On veut placer un point sur le segment. L’ambiguïté permet de choisir entre les trois objets. Ce choix effectué (on voit le segment sélectionné en rouge, on peut, avec l’icone locale de déplacement, prendre un point sur objet du segment.

Retour à la barre d’onglets (vers les macros DGPad)

Macros

Le fait que DGPad ait des macros-constructions dans sa première version en ligne était un objectif de l’auteur. Pour les utilisateurs avertis, c’est une source de production extraordinaire que nous allons largement illustrer dans les onglets de Galerie. Cet onglet est consacré uniquement à la réalisation des macros-constructions. L’onglet suivant abordera la gestion de ces macros.

Réalisation d’une macro-construction

Considérons une figure déjà terminée, un peu complexe : étant données deux cercles et un point, on a déjà construit les 4 cercles passant par le point et tangents aux deux cercles initiaux.

Figure manipulable


On notera que les cercles sont définis par centre et rayon, c’est-à-dire que l’on peut modifier les rayons directement en agissant sur les deux cercles, en manipulation directe.

On se propose de transformer cette figure en macro-construction qui, à partir des deux cercles et du point construit les 4 cercles. Pour cela on se met en mode macro-construction.

On remarque que la figure contient déjà plusieurs macro-constructions dites personnelles : l’axe radical de deux cercles, les centres d’homothétie de 2 cercles et la macro intitulée 2CT a 1C par 2pts, soit une macro qui construit les deux cercles tangents à un cercle donné et passant par deux points donnés. La figure finale ci-dessus utilise en effet cette macro.

Pour faire une nouvelle macro, il suffit de commencer par cliquer sur un objet initial pour le processus commence. En voici une description visuelle détaillée :

Illustration 1 : Dès que l’on clique sur un cercle l’interface de création de macro s’affiche : une ligne de texte pour le titre, une deuxième ligne, associée au bouton vert, les objets initiaux, une troisième ligne, avec un symbole rouge, les objets finaux potentiels. Au premier clic sur un cercle (l’objet sélectionné devient vert), un objet final est possible, son centre.
Illustration 2 : Sélection du second cercle initial, son centre est ajouté aux objets finaux. On notera que les objets finaux potentiels sont en noir dans la figure.
Illustration 3 : En sélectionnant ensuite le point, les 4 cercles deviennent noirs car ce ont des objets finaux potentiels. On pourrait finir la macro ici mais elle ajouterais deux points inutilement, les centres des cercles intiaux.
Illustration 4 : On peut alors sélectionner sur la figure les objets finaux. Dés que l’on sélectionne un premier objet final, il est sélectionné en rouge, et la liste des objets finaux potentiels est supprimée, la liste se transforme en objets finaux réels.
Illustration 5 : On choisit ainsi les 4 cercles.

Puis (non illustré) on donne un nom à la macro et elle se rajoute aux macro-constructions personnelles.

Les macros sont des macros "de figure".

Dans cette version, en particulier parce que DGPad n’est pas encore une application autonome, on ne peut créer que des macros de figure, on ne peux pas les mettre dans la bibliothèque. Ce qui n’empêche pas de les enregistrer : dès qu’une figure est enregistrée, toutes les macros faite avec elle sont enregistrées comme macro-construction, ce qui permettra de les associer ensuite comme on le verra à l’onglet suivant.

Cela signifie aussi que pour tester l’application de la macro, il faut rester sur la même figure.

Application d’une macro

On se propose maintenant d’appliquer cette macro. Pour la tester, on supprime les centres des cercles, on construit de nouveaux cercles, que l’on prend d’un autre type, cette fois par centre et un point (au lieu de centre et rayon) pour vérifier que la macro s’applique au méta-objet "cercle" et pas à un type particulier de cercle.

On clique sur la nouvelle macro. Un commentaire apparaît dessous qui indique le type d’objet attendu :

Illustration 1 : Avant que l’on clique sur le cercle attendu, la macro attend un premier cercle.
Illustration 2 : Dès que le premier cercle est sélectionné au doigt, le commentaire de la macro demande un second cercle ...
Illustration 3 : ... puis quand le cercle est sélectionné, la macro attend un point. Et c’est le dernier objet initial attendu (se lit sur le 3/3).

C’est ici qu’il y a une grande différence fondamentale entre l’interface tactile et l’interface avec une souris. Dans l’interface tactile, le dernier cercle sélectionné signifie que l’utilisateur a lâché la tablette. On attend donc que l’utilisateur touche à nouveau la tablette, en sélectionnant un point. Alors la macro s’exécutera, la figure sera construite.

Dans une interface avec souris, il y a naturellement le questionnement de la construction anticipée : la position de la souris est connue continument, on peut donc engager la construction anticipée depuis la position de la souris, même si l’utilisateur ne manipule pas encore la souris. On retrouve donc la différence entre la continuité de la souris et la discontinuité du tactile.

Pourtant, même dans une interface tactile, on aurait pu imaginer que l’entrée dans le dernier point de la macro puisse faire basculer la procédure de restitution dans une boucle finale TouchStart - TouchMove - TouchEnd pour une construction anticipée de la macro sur le dernier point. Interrogé sur cette question, l’auteur du logiciel a simplement signalé que comme sont faites les macros, ce n’est pas aussi simple à mettre en oeuvre et que l’anticipation des constructions dans les macros est loin dans la listes des choses à poursuivre et améliorer sur le logiciel.

Illustration 4 : La figure est finie. La macro continue éventuellement à s’appliquer avec un nouveau "prompt" sur un nouveau premier objet initial.
Illustration 5 : Quand on quitte le mode "macro-constructions" on retrouve la figure finale. On remarque aussi que les macros ne conservent pas les couleurs des objets lors de la construction des macros, mais c’est assez général comme comportement, la priorité étant la couleur de l’objet en cours pour la figure.

La question du point sur objet : initial ou final ?

Lors des premières utilisations quand un point M est un point sur objet (par exemple d’un segment ou d’un cercle), on est surpris qu’il soit placé en objet automatiquement en objet final de la macro quand on clique sur l’objet auquel il appartient.

Dans l’application de la macro, il sera juste créé à nouveau et sera crée comme point sur objet bien entendu. Cela peut être très utile dans de nombreux cas.

Il peut y avoir aussi de nombreux cas où, au contraire, ayant à appliquer plusieurs fois cette macro, on voudrait que certaines données soient, en pratique, implicites comme il existe des objets implicites dans les macros de Cabri, et CaRMetal (au moins).

Si c’est le cas d’un point sur objet qui sert plusieurs fois dans les construction, pour qu’il ne soit pas placé en objet final - et que l’on en a besoin comme objet initial, le plus simple est de le montrer en objet initial avant l’objet auquel il appartient. Dans ce cas il ne sera pas reconstruit puisqu’il sera remontré.

Exploration de la position du point sur objet dans la macro

Vous pouvez créer et tester des macros Bezier2pts qui aux objet initiaux O, I, t, A et B donnent le point Bz, avec plusieurs variantes. Donner des indices différents aux macros que vous appliquerez à deux points M et N que vous créez à chaque nouvelle macro (on peut supprimer les points, tous les outils sont disponibles)

Les objets finaux seront au minimum le point Bz.
Les objets initiaux se terminent dans tous les cas par A et B.
Test1 : en initiaux S1,et t en final avant Bz. Un nouveau point t est créé, Bz dépend de ce point
Test 2 : en initiaux t et S1, alors t n’est pas recrée, le point Bz en dépend directement
Test 3 : en initiaux S1 sans t en final.Alors un nouveau t est crée sous le premier, mais il sera caché - car objet intermédiaire - donc déplacer le point t et faire apparaître ce nouveau point en activant Cacher/Montrer.

S’il y a une mauvaise manipulation, on peut toujours supprimer des points, et au pire, relancer la page, mais alors cela effacera les macros déjà construites.



Autres précisions sur fonctionnement des macros

Comme dans CaRMetal, et Cabri (au moins) si les macros peuvent être contenues dans les figures, c’est essentiellement pour être appliquées à nouveau. En particulier, dans l’utilisation standard du logiciel, si une macro a été appliquée, il n’est pas nécessaire de la conserver dans le fichier, on peut l’enlever (à la main comme cela sera détaillé à l’onglet suivant).

Autrement dit, dans DGPad une macro est appliquée, elle n’est pas appelée comme une fonction. Mais elle peut l’être, si on décide d’intervenir manuellement dans les fichiers - et donc faire de la programmation - et c’est très efficace, nous verrons cela dans la seconde partie de cet article, sur les scripts.

Bilan de cet onglet sur les macros

On retiendra les spécificités suivante de l’interface de DGPad :

• Dans la construction d’une macro, le traitement simultanée des objets initiaux et finaux, en fonction des choix de l’utilisateur.
• Ce qui implique une réflexion particulière sur ce que l’on veut faire des points sur objet.
• Dans l’utilisation des macro, la possibilité de construire des points à la volée pendant l’application même d’une macro.
• La non anticipation des objets dans les macros se terminant par un point, comme c’est le cas des constructions.
• Les macros sont appliquées et non pas appelées.

Retour à la barre d’onglets (vers les micromondes)

Micromonde

Le concept de micromonde a été dégagé par Paper en 1980. Mais au sens où il le définissait à l’époque - en informatique 1980 c’est quand même très loin, même pour ceux qui y étaient - tous les logiciels de GD seraient des micromondes. La notion a donc fortement évolué pour les logiciels de GD avec Jean Marie Laborde et son équipe autour de Cabri géomètre. Depuis on dit d’un logiciel de géométrie dynamique qu’il est un micromonde s’il dispose de la possibilité de créer de nouveaux outils (qu’on appelle traditionnellement des macro-constructions) et qu’il permet de les structurer pour permettre, d’une manière générale, de travailler dans un environnement propre à un contexte géométrique particulier. On peut développer un micromonde sur les cercles, un sur les coniques par exemple, mais en général on entendu par micromonde la mise en oeuvre d’une autre géométrie pour peu qu’elle ait un modèle euclidien.

Exemples et illustrations de micro-mondes non euclidiens

Par exemple avec CaRMetal, et ses macros particulièrement soignées - résultat d’années de programmation - on peut non seulement faire des micromondes des géométries non euclidiennes classiques - la géométrie hyperbolique, dont le modèle du disque de Poincaré qui implémenté en standard dans le logiciel, ou encore son modèle sur la pseudosphère comme dans ce classeur de 27 figures ...

... mais aussi des micromondes de géométries bien moins standard comme le plan de Moulton, modèle de géométrie plane non arguésienne.

La mise en oeuvre de tels micromondes permet d’explorer ces géométries - ici non arguésienne - peu connues, et trouver des résultats comme par exemple l’existence de triangles bi-orthocentriques : ayant deux orthocentres.

(fin du bloc dépliable)


Cabri-géométrie, en particulier à partir de Cabri II a poussé très tôt (1996) très loin à la fois la facilité de faire des macros et la façon de structurer et organiser ces macros puisque Cabri II permettait de construire des barres de menu spécifiques de ces nouvelles macros, ce qui n’a jamais été repris depuis semble-t-il.

En prélude, une petite expérience d’adaptabilité

Dés cette première version de DGPad, pour tester les capacités du logiciel et jusqu’où on peut aller en terme de figures avec des macro-constructions, nous avons pu réaliser non seulement des pavages hyperboliques, mais aussi l’essentiel des macros hyperbolique de second niveau sur les faisceaux de Bachmann, y compris - et c’est surprenant - une macro intersection de deux droites hyperboliques alors qu’elle se ramène à celle de deux arcs de cercles. Et on sait qu’il faut gérer soi-même la continuité de cette intersection quand les orientations des arcs changent (en pratique dans ce contexte, quand l’arc traverse le centre du disque de Poincaré).

Modifier ses schèmes d’action

Ce dernier point est un bel exemple, dans le contexte d’un changement de support, sur nos capacités à modifier nos schèmes d’action : avec CaRMetal par exemple (ou Geogebra dans une certaine mesure) nous disposons de divers moyens pour maitriser la continuité des objets, ce qui permet de faire des outils d’un autre micro-monde en toute sérénité. Sans aucun de ces moyens sophistiqués - et qui plus est, sans nombre ni algèbre - il a fallu chercher une méthode de construction purement géométrique pour construire cette intersection de manière continue.

La réussite de ce petit challenge montre au moins deux choses :
• une certaine paresse opérationnelle que peut entrainer la mise à disposition d’outils sophistiqués. En effet la solution trouvée fonctionnerait avec n’importe quel logiciel de géométrie dynamique.
• la capacité à trouver des solutions nouvelles dans un monde contraint : ce qui frappe le plus, et on le verra dans les onglets de scripts, c’est que la contrainte environnementale (rappelons que cette première version DGPad n’a pas de nombres, donc pas de mesure, pas d’expression algébrique sur les grandeurs en jeu) oblige à modifier fortement les points de vue, à bousculer nos propres schèmes personnels, pour, en définitive, trouver des solutions géométriques parfois plus simples que les solutions analytiques, immédiates à l’esprit, mais souvent techniques ou calculatoires.

Bien entendu ceci n’est pas un plaidoyer pour des logiciels pauvres, bien loin de moi cette pensée, mais c’est l’occasion de montrer qu’en attendant l’implémentation des outils classiques, la géométrie a en elle-même des ressources qui ne sont pas toujours pleinement explorées. On en donnera d’autres exemples avec les scripts.

Le format de fichier de DGPad

Avant d’aborder la modification des fichiers de DGPad pour construire des listes de macros, un mot sur l’organisation d’un fichier. Tout d’abord c’est un fichier au format texte : .txt. Même si ce n’est pas essentiel pour le moment, c’est aussi un fichier JavaScript, en particulier les commentaires sont des lignes qui commencent par //.

Voici le fichier d’une droite passant par deux points

Autrement dit (pour ce qui nous intéresse ici)
• une ligne qui situe l’origine de la figure et la taille écran de l’unité,
• des lignes de construction (rubrique Geometry)
• les lignes de STYLE de chaque objet
• une ligne d’état du système de coordonnées (qui est reconstruite si on ne la met pas).

Ajoutons à cette figure la perpendiculaire en un point et faisons une macro perpendiculaire (cela ne sert à rien, c’est juste pour lire le fichier produit).

Note technique SPIP

Dans la balise cadre utilisé pour le code, on remarquera une petite icone en bas à droite du cadre.
Elle permet de régler la taille du cadre utilisé.

Le code commence donc par les macro-constructions. Ce sont des fonctions qui ont un nom (externe et interne, même si c’est souvent le même sauf si on met des accents), une liste de paramètres, et un executable. Il s’agit une fonction Javascript - "fonction" car elle renvoie un ou des objets - qui correspond à la construction que l’on souhaite transformer en macro-construction.

On remarquera que les noms de variables (globales) de la figure qui a servi à faire la macro sont repris tels quels, mais dans la macro, ce sont bien entendu des variables locales de la fonction.

Pour ce qui est du corps de la construction, on voit aussi un réarrangement des objets qui ne correspond pas à l’ordre séquentiel de création : la droite avait été construite avant que l’on place le point M, alors que dans le fichier M est placé avant : il y a clairement un classement interne par type d’objet tant que cela est possible bien entendu.

Appliquons cette macro toute élémentaire à une droite (la perpendiculaire Perp1) et un point U, le fichier devient :

On voit, par la ligne Perp11, que la macro est appliquée, elle n’est pas explicitement appelée (par son nom).

Il en résulte qu’une fois la figure finale achevée, puisque le code final ne fait pas appel explicitement aux macros utilisées, on peut supprimer les macros si on le désire, par exemple pour diminuer la taille du fichier.

On verra dans les onglets de scripts que l’on peut aussi appeler directement une macro-construction dans un fichier, ce qui rend le fichier plus lisible pour de nombreuses applications itératives par exemple.

Applications imbriquées des macro-constructions

Bien entendu, c’est le principe même du micromonde, les macros peuvent s’appeler entre elles, ce qui permet de réaliser des macro-constructions de plus en plus complexes.

Par exemple la macro 4CT a 2C1P qui construit les 4 cercles tangents à deux cercles passant par un point appelle la macro 2CT a 1C par 2 pts qui construit les deux cercles tangents à un cercle passant par deux points donnés. Voici un extrait du code de ces macros :

On voit en particulier l’effet de la réorganisation des objets. Les pointillés de la première macro correspondent à 18 instructions. Or quand on applique deux fois cette macro, une première fois pour trouver les cercles tangents de même type - un cercle deux fois intérieurement et un cercle deux fois extérieurement - puis une seconde fois pour trouver les deux autres cercles, on pourrait s’attendre à trouver les 18 instructions entre les constructions de C4 et C5 (ce que rend la première application de la macro) et les cercles C41 et C51 (la seconde application de la macro).

Comme on le voit il n’en n’est rien, au contraire il n’y a entre les deux couples de que les intersections avec un autre cercle qui va donner les points cherchés pour terminer les troisième et quatrième cercles.

Voir le code entier des deux macros

Organisation des macro-constructions en fichiers de micromondes

On aura compris, avec cette présentations du code des macros que l’organisation en micromondes est à la charge de l’utilisateur.

Construire un micromonde, pour cette version, c’est se donner une liste de macros dans un fichier de figures.

Les macros étant indépendantes les une des autres chacun peut à loisir copier coller des macros dans des fichiers de figures et les agencer à sa guise.

Bien entendu, on imagine bien que la gestion des macro-constructions n’en restera pas là. Mais rappelons que le logiciel a entièrement été écrit à partir de rien, donc pour cette première version, c’est déjà une possibilité importante.

Un exemple d’application ... pour le plaisir de la géométrie

Poursuivons sur ces deux macros de cercle. L’exemple est un peu culturel, au sens où il reste éloigné de tous les programmes, mais il est intéressant quand même. On sait que les intersections d’une conique et d’une droite sont constructibles à la règle et au compas, et qu’en général, les intersections de deux coniques ne sont pas constructible à la règle et au compas. Les logiciels majeurs - ie qui ont atteint leur "majorité logicielle" - intègrent ces intersections. C’est le cas des trois cités ici, Cabri, Geogebra et CaRMetal, mais aussi le cas d’autres comme Cinderella. DGPad est juste naissant la question ne se pose donc pas encore ...

Si les intersections de deux coniques en général ne sontt pas constructibles à la règle et au compas, il y a des situations spécifiques où elles le sont. C’est par exemple le cas quand elles ont un foyer commun.

Soient donc ces deux coniques ci-dessous : une ellipse rose et une hyperbole verte (il y a ses asymptotes en prime, chacun aura compris que c’est un passage par l’infini qui n’est pas encore géré).

Ces deux coniques ont un même foyer F. Pour ce qui nous intéresse ici, on les a considérées comme définies chacune par leur foyer F et un cercle directeur :
• de contre O1 pour l’hyperbole - cette conique est une hyperbole car F n’est pas à l’intérieur de son cercle directeur,
• de centre O2 pour l’ellispe - cette conique est une ellipse car F est à l’intérieur de son cercle directeur.

L’ellipse est le lieu du point E, intersection de la droite (O2N) et de la médiatrice de [FN] quand N décrit son cercle directeur, et de même,
L’hyperbole est le lieu du point H, intersection de la droite (O1M) et de la médiatrice de [FM] quand M décrit son cercle directeur.

Alors un raisonnement simple sur les distances - et la définition bifocale des coniques à centre - permet de voir que les intersections de ces deux coniques sont équidistantes de F et de chacun des deux cercles directeurs.

Autrement dit ce sont les centres des 4 cercles - quand ils existent - tangents aux deux cercle directeurs et passant par F.

Il suffit donc d’appliquer la macro 4CT a 2C1P à ces deux cercles directeurs et au foyer commun des deux coniques pour avoir leurs intersections :

Vous pouvez déplacer les points O1, O2 et F, mais aussi la taille des deux cercles bleus (cercles directeurs des deux coniques)
Les centres des cercles tangents aux cercles directeurs passant par F sont aussi les intersections des deux coniques.



Voici un exemple immédiat - la figure est vite faite - d’une utilisation de macro-constructions plus longues et plus complexes à réaliser que leurs applications.

Les qualités internes d’un micromonde

On a donc vu que, pour le moment (mai 2013) la gestion des macros en micromonde est à la charge de l’utilisateur, en partie parce que l’application est une webApp.

Mais la qualité d’un micromonde n’est pas seulement dans la gestion de ses macros, ce qui peut être considéré comme les qualités externes du micromonde. Donc les qualités externes des micromondes de DGPad sont clairement minimales pour le moment.

Mais les qualités du micromonde peuvent être plus interne au logiciel, au coeur sa conception, en particulier dans la réalisation des macros et dans la qualité d’enchainement de ses macro-constructions.

Manipulation directe de la figure en cours de réalisation d’une macro.

Cette possibilité, si elle permet bien entendu de déplacer des objets pour accéder à d’autres objets qui seraient hors écran, est aussi l’occasion de tester le comportement logique des macros : peut-on enregistrer dans une même macro des objets finaux qui existent exclusivement l’un de l’autre ?

Cette possibilité avait été une avancée importante de Cabri II qui avait ouvert la possibilités à ce qu’on appelait alors des macros logiques. Cette notion a disparu avec les nouveaux logiciels libres (comme Geogebra et CaRMetal entre autres) qui ont largement étendu ces possibilités , par exemple avec des attributs de conditionnalité, et des variables booléennes incorporées soit dans ces attributs, soit dans les coordonnées des points constituants des objets.

Indépendamment de ces possibilités d’utilisation, on s’intéresse ici à la qualité de réalisation des macros. Considérons donc la situation de base suivante, archétypiquement la situation qui permet de gérer la troncature du cube par les sommets à partir d’un point sur une arête.

Deux points A et B, un point M, la perpendiculaire à (AB) passant par M. Puis I le milieu de [AB], les deux segment [AI] et [IB], et les deux points d’intersection U et V de la perpendiculaire avec chacun des segments :

Donc U et V existent exclusivement l’un de l’autre. Voyons le comportement de DGPad pour transformer cela en macro-construction. En voici les étapes détaillées.

• Illustration 1 : les deux points A et B sont montrés, les seules objets finaux possibles sont le milieu et les segments construits à partir du milieu.
• Illustration 2 : on ajoute le point M, tous les objets de la figure sont possibles en objets finaux, y compris les deux points U et V.
• Illustration 3 : on clique sur U, toutes les autres possibilités disparaissent.
• Illustration 4 : on peut déplacer le point M pendant la construction de la macro et cliquer sur V comme second objet final.On termine la macro et on la teste sur de nouveaux points.
• Illustration 5 : la macro fonctionne, elle crée bien les deux points U et V qui existent exlcusivement l’un de l’autre.

Donc la manipulation directe de la figure en cours de réalisation de macro fonctionne dans toute sa potentialité.

Comportement de Geogebra dans cette situation

Geogebra a une gestion différente de ses outils - nom des macro-constructions. La construction des macros est modale, la question de la manipulation directe ne se pose pas.

Mais l’approche étant modale, Geogebra fabrique la macro sans problème : les points U et V étant des points de la figure, ils sont des points finaux possibles, on peut les choisir. Par défaut les trois points initiaux sont A, B, et M. La macro est construite avec succès ...

Mais elle semble ne pas s’appliquer ...

Sur les illustrations 3 et 4 on voit à la fois la figure construite comme ci-dessus, et son application en macro qui donne ’impression de ne pas fonctionner mais en fait ce n’est pas le cas ! Cela fonctionne, mais il faut s’en apercevoir !

En effet ... l’autre point d’intersection n’étant pas défini, par défaut il a le statut écaché". On le voit dans la fenêtre d’algèbre : c’est le point H. Il faut déplacer le point E, alors H existe et on peut le rendre visible :

Autres qualités internes plus fines des micromondes

Ce dernier paragraphe de cet onglet est plus réservé à une culture des micromondes, il n’apporte rien d’opérationnel sur l’utilisation de DGPad.

On a vu les qualités externes de gestion de macros, puis les qualités internes aux macros. On peut aller plus loin dans la qualité de la production d’un micromonde. Celle que nous allons aborder maintenant est encore plus au coeur de la réalisation des macro-constructions, c’est elle qui permet des raffinements sophistiqués qui certes, ne concernent pas les élèves mais interpelle les concepteurs de micromondes : il s’agit de la prise en compte, dans les macros, des relations entre les objets et leurs constituants. Et donc, même sans avoir à construire des micromondes sophistiqués, cette relation là est un questionnement que chacun peut avoir à rencontrer lors d’une utilisation un peu fine d’un logiciel de géométrie dynamique.

La possibilité d’utiliser des points constituants des objets pour faire des macros sur ces objets - ou des macros les utilisant - est un point fondamental dans la réalisation des micromondes. C’est une qualité interne ultime des macros.

Cette capacité est intégrée dans Cabri II (c’est-à-dire existe en géométrie dynamique depuis 1996) mais je ne l’ai retrouvée que dans CaRMetal. Et donc cela ne fonctionne pas - pas encore ? - dans DGPad et non plus dans Geogebra qui n’est pas un logiciel très accès sur la construction de micromondes.

Illustrons ce dont il s’agit sur un exemple élémentaire : la construction du centre d’une conique à centre donnée par 5 points. Tout d’abord signalons qu’il existe des constructions du centre d’une conique à partir de ses seuls 5 points constituants. Mais nous allons faire une figure mixte ici, plus simple, qui illustrera jusqu’où peut aller la qualité d’un micromonde. Pour éviter toutefois de compliquer l’argumentation, on se limitera à une ellipse.

Méthode utilisée : si on se donne trois points d’un cercle, son centre est l’intersection des deux médiatrices. D’un point de vue affine (c’est là que l’argument ne tient pas pour les hyperboles mais la construction reste correcte par des arguments sur le birapport), une médiatrice de deux points d’un cercle est le lieu des milieux des cordes parallèles à une corde donnée. Si on fait cela deux fois on a d’une manière affine le centre d’un cercle et donc celui d’une ellipse comme intersection de deux droites de milieux de cordes parallèles.

Mise en œuvre dans CaRMetal

Une conique est définie par 5 points A, B, C, D, et E. On se propose de faire le lieu des milieux des cordes parallèles à [AB] et à [AE] : ces deux lieux sont des droites, et leur intersection est le centre de la conique.

La parallèle à [AE] passant par B coupe la conique en M. LA parallèle à [AB] passant par E coupe la conique en N. Cette construction utilise donc explicitement à la fois la conique elle-même et trois de ses points constituants.

Le premier lieu de est la droite (UV) - un segment de cette droite - et le second lieu est la droite (PQ) - même remarque. Le centre du lieu est donc l’intersection de ces deux droites.

On voit que la macro a un seul élément initial, la conique, et la macro est acceptée, car les macros acceptent les constructions sur leurs points constituants.

Dans la seconde ligne d’illustrations on voit l’application de la macro sur une conique dont on déplace un seul point : la construction est opérationnelle dans tous les cas (y compris quand l’hyperbole change de branche - par rapports aux points constituants.

Aller plus loin - Mais qu’est-ce qu’un objet constituant ?

La question n’est pas aussi simple que cela. Prenons une droite : elle peut être définie par deux point, par un point et une pente (dans Geogebra au moins). Il faut donc définir des métas objets dont toutes les droites, segments et demi-droites sont dérivés et que les macros, dans la mesure du possible, s’appliquent si possible aux meta-objets.

Pour les cercles, c’est la même chose : il y a l’objet par centre et point, par centre et rayon (à la volée) et centre et rayon (montré à l’extérieur : outil compas), et ceci dans les trois logiciels Cabri, Geogebra et CaRMetal. Et s’il y a un méta-objet : l’arc de cercle défini par trois point en fait-il partie ?

Quels sont les objets constituant d’un arc de cercle ? Les trois points ? En général non ... donc il faut repérer les objets constituants des objets pour pouvoir faire des macros plus fines.

Dans CaRMetal seul un des trois points par lequel passe un arc défini par 3 points est effectivement un objet constituant de l’arc. Dans Geogebra, il semble que ce soient les points mais on ne peut pas utiliser les objets constituants en ne montrant que l’arc comme objet initial. Il en résulte que faire de la géométrie hyperbolique, de manière optimisée, n’est pas aussi simple que cela. On le verra dans l’onglet sur la galerie hyperbolique.

Retour à la barre d’onglets (vers une première Galerie)

Galerie 1

Voici quelques figures manipulables dans l’article, dont certaines avec la barre d’outils pour faire des constructions. Toutes les figures sont disponibles en téléchargement en fin d’article.

Sur les cercles

Cercle de Malffati

Construction de trois cercles à l’intérieur d’un triangle deux à deux tangents et chacun tangent à deux côtés du triangle.



Exemple de micromonde sur les coniques affines

Ces macros sont disponibles dans la figure ConiquesAffines dans le fichier de téléchargement. En voici une première application :

Un cas particulier du théorème de Carnot permet d’affirmer qu’il existe toujours une conique tritangente aux côtés un triangle en les trois points d’intersection avec les côtés de trois céviennes concourantes (une cévienne est juste une droite passant par un sommet du triangle - en hommage à Céva).

Dans la figure ci-dessus, vous pouvez manipuler :
• Les sommets A, B et C du triangle.
• Le point Sp (pour Steiner Parabole) qui est sur l’ellipse de Steiner circonscrit au triangle ABC. Pour les céviennes concourrantes sur l’ellipse de Steiner la conique tritangente aux côtés du triangle est une parabole.
• Le point Sg (pour Steiner général) est déplaçable dans les points. Si Sg est à l’intérieur de l’ellipse circonscrit de Steiner, la conique tritangente est une ellipse, si Sg est à l’extérieur c’est une hyperbole.



Exemple d’utilisation d’une macro directement dans l’article

Exploration sur la nature d’une conique

La figure suivante est composée de 4 points A, B, C, D, et des deux paraboles passant par ces quatre points (réalisée par la macro Paraboles 4P). Elle contient aussi la macro qui construit la conique passant par 5 points.

On se propose d’explorer la nature de la conique passant par les 4 points donnés A, B, C, D et un point M supplémentaire en fonction de la position de M par rapport aux deux paraboles. Plus précisément, on s’intéresse au cas où la conique est une ellipse.

Manipulation possible :
• Se mettre en mode macro.
• Appliquer la macro Cnk 5P (Conique par 5 points) aux point A, B, C, D et un point pris à la volée (qu’on appellera M dans la suite).
• Explorer la partie du plan dans laquelle doit être M pour que cette conique soit une ellipse.


Le lieu cherché est la différence symétrique des intérieurs des deux paraboles, ie la réunion des intérieurs privée de leur intersection

Exemple de figure avec comportement booléen

On peut déplacer le point Ch et le centre du cercle



Exemple de texte dynamique

L’implémentation n’est pas encore complète - c’est pour cela qu’elle n’est pas documentée dans cet article - mais voici un exemple de (futur) texte dynamique dans DGPad (avec MathJax). Comme MathJax est chargé dans un second temps, le texte reste non affiché correctement quelques secondes.

Selon les plateformes et le navigateur, éventuellement il peut être nécessaire de déplacer un curseur ou le point A pour que le texte s’affiche correctement.

Précisions sur la figure :
• On a tracé une fonction polynôme du troisième degré, avec ses coefficients manipulables.
• Puis entre deux points A et B, on montre que cette fonction est obtenue par une courbe de Bézier à 4 points (degré 3) allant de A à B définie par deux points intermédiaires C et D.
• Construction : C et D sont respectivement sur la tangente à la courbe issue de A et B et ils sont d’abscisse le tiers et les deux tiers de [AB].
• On agit sur t pour déplacer le point de Bézier sur la courbe.
• L’unité est modifiable par le point droit du curseur contenant le coefficient a.



(en cours de développement, pour information, le texte peut ne pas s’afficher correctement dans tous les navigateurs ou sur toutes les plateformes)

Retour à la barre d’onglets (vers une galerie hyperbolique)

Galerie Hyperbolique

Les figures suivantes sont en manipulation directe en ligne, dans le navigateur.

Présentation succincte du modèle

On est dans le disque de Poincaré : les points du plan hyperbolique sont les points à l’intérieur du cercle, appelé cercle horizon, ie dans le disque. Les points du cercle horizon sont les points à l’infini. On parle aussi de points idéaux dans la mesure où ce ne sont pas des points hyperboliques, mais des points du modèle - ce qui est pratique.

Les droites sont des arcs de cercles orthogonaux au cercle horizon : par deux points il passe alors une et une seule droite. Il y a tout de même un cas particulier : s les points sont alignés avec le centre l’arc devient un segment.

Les droites peuvent être :
• sécantes : elles ont un point commin
• parallèles : alors elles se "coupent à l’infini". Dans le modèle, elles ont un point idéal commun. Hors modèle, on parle de "bouts communs". Hilbert par exemple, dans son chapitre "Fondements de la géométrie", a développé tout un chapitre sur les propriétés des bouts hyperboliques.
• ou avoir une perpendiculaire commune. Et alors celle-ci est unique.

La différence entre la géométrie euclidienne et la géométrie hyperbolique réside par exemple que par un point, il passe deux droites paralléles à une droite donnée. Dans le modèle ce sont les droites passant par le point et un des deux bouts de la droite initiale.

Le faisceau des droites parallèles est scindé en deux notions : le faisceau des droites parallèles (et que ce soit un faisceau fait partie des propriétés qu’il faut montrer) et le faisceau des droites ayant une perpendiculaire commune.

On parle alors de faisceau
• à centre : les droites sont concourantes
• à axe : les droites ont une perpendiculaire commune
• sans support : les droites ont un bout commun, ie un point idéal commun, elles sont paralléles.

Les propriétés de concours des droites usuelles du triangle s’étendent à des propriétés de "droites en faisceau".

Par exemple les médiatrices soit sont concourantes - et les trois points sont sur cercle circonscrit, soit ont une perpendiculaire commune, soit ont un point idéal commun (difficile à obtenir en manipulation directe sans construction spécifique. Il en est de même pour les hauteurs, et les bissectrices d’un triangle.

Manipulation sur les médiatrices d’un triangle

A l’ouverture, les trois points ne sont pas sur un cercle circonscrit, car les médiatrices ne sont pas concourantes : elles ont une perpendiculaire commune. Dans ce cas le cycle circonscrit s’appelle une équidistante.

On peut déplacer un des sommets du cercle pour voir le cas circonscrit.



Le cas "point idéal" en général ne s’obtient pas vraiment en manipulation direct, mais on peut l’approcher perceptivement. Dans ce cas le cycle circonscrit s’appelle un horicycle (ou horocycle en anglais). C’est un cercle dans le modèle du disque de Poincaré.

Les médianes d’un triangle hyperboliques

Contrairement aux autres droites remarquables du triangle, les médianes d’un triangle hyperbolique sont toujours en faisceau à centre - autrement dit elles sont toujours concourantes - ce qui est un résultat assez difficile à prouver dans un contexte absolu.



Du triangle au trilatère

Comme les droites peuvent être non sécantes sont être parallèles, il y a une extension naturelle au triangle qui est le trilatère : trois droites deux à deux non sécantes (et toutes les trois non en faisceau).

De très nombreuses propriétés générales sur les triangles ne sont pas spécifiquement euclidiennes mais sont absolues. Voici une illustration de cette propriété : les hauteurs d’un trilatère - quand elles existent - sont les bissectrices du triangle podaire (des pieds des hauteurs). C’est une propriété euclidienne qui se démontre facilement avec le produit scalaire, et qui était encore une application significative, mais classique, de 1°S quand il y avait encore de la géométrie au lycée.

Dans la figure suivante :
• On se donne trois droites quelconque : un trilatère.
• Chaque droite est manipulables par deux poignées : a1, a2, b1, b2 et c1 c2 respectivement.
• Les droites couleur cyan sont les hauteurs du trilatère. Une hauteur est une droite qui appartient au faisceau de deux droites et qui est perpendiculaire à la troisième droite. Ici les hauteurs sont concourantes. Certaines pourraient même ne pas exister dans certaines configuration.
• On n’a pas construit les pieds des hauteurs, mais ils sont représentés car on a construit - en rouge - le triangle orthique qui relie ces pieds des hauteurs deux à deux
• Puis on a construit les projections orthogonales U, V et W de l’orthocentre du trilatère initial sur les trois côtés du triangle orthique.
• On voit alors que le cercle de centre l’orthocentre passant par U passe aussi par V et W et qu’il est tangent au triangle orthique en ces points : les hauteurs d’un trilatère sont les bissectrices du triangle orthique.



Manipulation possible : vous pouvez rendre le trilatère TRIANGLE en faisant se couper deux à deux les droites en manipulant leurs poignées : on aura alors la même situation que le contexte euclidien : un triangle, ses hauteurs, et triangle orthique et ses bissectrices.

On remarquera qu’en dehors des six points initiaux poignées des trois droites du trilatère, on n’a construit dans cette figure que 4 autres points : l’essentiel de la construction se fait sans point par des macros sur les faisceaux de droites et leurs propriétés : d’une manière générale ces macros sont plus stables que celles faisant intervenir les points.

Pavage hyperbolique P(5,4) - Génération 2

Le fichier suivant est assez long à ouvrir (environ 20 s sur tablette), mais fluide ensuite : c’est probablement le premier pavage hyperbolique manipulable au doigt sur tablette tactile ... merci à DGPad, et à son auteur !!!

Il s’agit d’un pavage de pentagones orthogonaux (à 5 angles droits). Avec l’orthogonalité, donc de nombreux points alignés, c’est le plus simple à construire car celui qui a le moins d’objets à produire.

C’est la raison pour laquelle on peut construire une génération 2 : il y a tous les pentagones (G2) autour des pentagones (G1) du pentagone initial que l’on peut manipuler par son centre et un point.



Dans l’état actuel de DGPad cette figure fait plus de 3100 objets, elle pourrait être ramenée à environ 800 à 1000 objets quand on pourra utiliser des données numériques pour l’inversion : ici tous les sommets hyperboliques des pentagones sont construits géométriquement.

Les macros du micromonde associé

La difficulté des arcs de cercle est qu’en général leurs points constituants ne sont pas ceux par lesquels on les définit. Il en est de même d’ailleurs, par construction pour les droites hyperboliques : les points constituant des arcs représentant une droite hyperbolique (AB) ne contient ni A ni B, ce qui permet d’utiliser cette macro même pour des points A ou/et B idéaux.

En fait il est naturel, pour des questions d’orientation entre autre, que les points constituants des arcs ne soient pas les points qui les définissent.

Mais pour DGPad, même les points constituants ne sont pas (pas encore) accessibles comme tels (ils seraient alors utilisables en macros). Il en résulte que les macros constructions sont nécessairement plus lourdes en objets intermédiaires.

Pour réaliser ces constructions, on a commencé par faire 8 macro-constructions hyperboliques standard et 3 autres macro-constructions sur les faisceaux de droites.

Les noms des macros parlent d’eux mêmes : si il faut donner trois points pour une perpendiculaire au lieu d’une droite hyperbolique et d’un point, c’est que la qualité du micromonde mis en oeuvre est pauvre. De même pour les 4 points pour une perpendiculaire commune.

Il y a donc un travail interne à faire, conceptuellement, pour que les objets intermédiaires soient accessibles dans les constructions qui permette de montrer l’objet constitué comme objet initial.

Une autre approche, algébrique, est toujours possible.En conséquence, toutes ces macros, et ces figures, seront refaites, et largement optimisées quand les expressions algébriques seront incorporées dans DGPad. Ici elles sont proposées pour montrer que, dés la première version webApp, on peut déjà faire des choses mathématiquement consistantes avec DGPad.

Plus de précision sur les faisceaux de droite en général ici.

L’article se poursuit par des considérations plus techniques dans cette partie 2 : les scripts de DGPad

Rappels d’utilisation

Site : www.dgpad.net

Environnement :
Sous Android, utiliser au choix le navigateur standard ou Chrome ou Firefox
Sous iOS, utiliser Chrome ou Safari
Avec un ordinateur : Firefox, Chrome, Safari (mais pas IE). Avec un ordinateur, on peut glisser les fichiers directement sur la page de DGPad (dans le navigateur). Sur tablette, on passera par un nuage.

Une figure, réalisée par l’auteur de DGPad : les 8 cercles d’Apollonius (2568 objets)
(et si vous avez parcouru cet article, vous saurez télécharger la figure ;-)

Toutes les figures de cet article, et quelques autres sont dans ce fichier à télécharger.


Documents associés à l'article
  Figures_DGPad_mai13   |   (Zip - 148.6 ko)
Réagir à cet article
Vous souhaitez compléter cet article pour un numéro futur, réagir à son contenu, demander des précisions à l'auteur ou au comité de rédaction...
À lire aussi ici
MathémaTICE est un projet
en collaboration avec
Suivre la vie du site Flux RSS 2.0  |  Espace de rédaction  |  Nous contacter  |  Site réalisé avec: SPIP  |  N° ISSN 2109-9197