Présenter un sujet à l’oral IFT820 - Séminaire Présenter un sujet à l’oral

Pourquoi se jeter dans la gueule du loup? Échelle des moyens de communication plus Science-fiction « What happens in Vegas… » Présentation orale Vidéoconférence Téléphone Courrier écrit Courriel Messages texte Clavardage moins Information transmise ambiguïté moins plus

Avantages d’une présentation orale Qualité du média Plus rapide et direct que la publication Pas limitée au contenu de l’article Expert disponible pour les questions Dynamique

Avantages d’une présentation orale Plus de moyens de mettre l’emphase sur l’important Matériel audio / vidéo Démonstrations La rétroaction peut être stimulante pour votre recherche

Inconvénients d’une présentation orale Vous n’avez qu’une seule chance L’auditoire ne peut pas s’informer en cours de route Dépend de l’habileté du présentateur et de la qualité du matériel de présentation Coûteux

Le message parlé: ajoutez de la saveur Analogies Exemples Histoires Connexion avec l’audience Humour

10 erreurs critiques à éviter Dire la mauvaise chose Puiser l’information au mauvais endroit Décoller sans l’auditoire Perdre l’auditoire dans l’espace Présenter un diaporama que personne ne lit

Puiser l’information au mauvais endroit Source Avantages Inconvénients Élaborer sur des points Gain de crédibilité Ajustable Rythme naturel Contact visuel Inexact Long à préparer Mémoriser Précis Fluide Potentiellement désastreux Rythme pas naturel Difficile à ajuster Très long à préparer Lire Perte de crédibilité Pas de contact visuel Improviser Aucune préparation Difficile d’être organisé Pas d’assistance visuelle

10 erreurs critiques à éviter Dire la mauvaise chose Puiser l’information au mauvais endroit Décoller sans l’auditoire Perdre l’auditoire dans l’espace Présenter un diaporama que personne ne lit

10 erreurs critiques à éviter Présenter un diaporama dont personne ne se souvient Ignorer la loi de Murphy Ne pas se préparer assez Ne pas être attentif Perdre votre contenance

Ce qu’on attend de vous

IFT820 - Séminaire Outils visuels

Ce qui distingue un diaporama scientifique Spécifique et complexe Difficile à comprendre Utilisation d’images essentielle.

Anatomie d’un diaporama scientifique Police (typographie, taille) Couleurs (choix et contrastes) Disposition pour une diapositive Style de la présentation

Phrase complète en en-tête décrivant l’objectif de la diapositive (28 points) Tout bloc de texte a un maximum de 2 lignes Les listes doivent avoir entre 2 et 4 éléments. Évitez les sous-listes Elles surchargent le lecteur Ne lésinez pas sur l’espacement (24 points). Figure 1: au moins une image (18p).

Utilisez une police grasse au lieu d’agrandir les caractères. Tout bloc de texte a un maximum de 2 lignes Les listes doivent avoir entre 2 et 4 éléments. Évitez les sous-listes Elles surchargent le lecteur Ne lésinez pas sur l’espacement. FAIL Figure 1: au moins une image.

Exemples d’application de style Images pour complémenter une explication Images en tant qu’icônes réutilisables Association d’images au plan Peu d’éléments par diapositive Un seul objectif clair par diapositive

Key elements: Scripts Knowledge Representation Model Tracing User Interface Interactions The views were used as a first layer, to establish a semantic link between the interface and the knowledge representation. CLICK The scripts, will in turn be used to define interactivity on the interface and what it MEANS. Their main role is to define how problem solving steps Are achieved on the interface.

Key elements: Scripts Model tracing Primitive procedures Parameter specification We’ve already seen that signals from the interface’s controls are managed by handlers, which produce interactions. CLICK Some interactions or groups of interactions mean that a primitive procedure has occured. However, there are many cases where interactions are only meant to specify the PARAMETERS of a procedure. Once the parameters are specified and the right interactions were done, we might consider the procedure has been completed. Every time a sequence of interactions may specify that a more complex action was done by the user, a script has to be defined to match on that sequence. So, what can happen on the interface? Aside from basic interactions, a user might do a primitive procedure, thus, we can define procedure scripts. There are also two ways to specify a parameter. CLICK Either you do a sequence of interactions that aim to SELECT an instance that is already available in the knowledge base, Or you create something new, by doing a sequence of interactions that aim to INPUT a new instance in the knowledge base. So, in short, handlers produce basic interactions. Input and selection script produce trap basic interactions and produce input and selection events. Procedure scripts may trap any combination of events, and send a message to the model tracing that a procedure has been done. Interactions

Key elements: Scripts EnterSimplifiedFraction (FractionOperand, Fraction) Context -Interaction (« SimplifyButton », FractionOperand) -Input (Fraction,FractionOperand) -Interaction (« OkButton », FractionOperand) Input (Fraction , FractionOperand) -Input (Numerator,FractionOperand) Fraction Operand -Input (Denominator,FractionOperand) So, here is what happens when you want to simplify a fraction in our simple fractions lab. As you can see, there are a few scripts involved. Each script specifies what should be done in order for it to match. The script at the top is a procedure script, and describes a problem solving step. The other scripts specify how some of the parameters are input. As you can see, inputting a whole fraction involves inputting The numerator, then the denominator. These instances will be put in the knowledge base BEFORE we can create the fraction, which will REFER to them as its PARTS. CLICK So, when the user wants to simplyfy the fraction, he clicks on the simplify button, which pops up the dialog. CLICK He then enters the numerator, and this interaction matches the script here at the botton. The numerator instance is created and put in the knowledge base, then, an input event is sent. CLICK This event happens to match one step of the other script in the middle. CLICK Something very similar happens when the user enters the denominator. CLICK Another input event is created and the script that specifies how to input hte whole fraction matches, sending another input event. CLICK This event matches the second condition in our procedure script here. Finally, the user clicks the ok button, an action which completes the script for our step. All that is left to do before the model tracing can be informed is to convert the information from all those events into parameters for the procedure. Input (Numerator , FractionOperand) Input (Denominator , FractionOperand) -Interaction (« DenomField », FractionOperand) -Interaction (« NumField », FractionOperand)

Scripts bridge the semantic gap by giving meaning to the interactions. Knowledge Representation Model Tracing User Interface Interactions The views were used as a first layer, to establish a semantic link between the interface and the knowledge representation. CLICK The scripts, will in turn be used to define interactivity on the interface and what it MEANS. Their main role is to define how problem solving steps Are achieved on the interface.

Scripts can describe procedures or specify their parameters Model tracing Primitive procedures Parameter specification We’ve already seen that signals from the interface’s controls are managed by handlers, which produce interactions. CLICK Some interactions or groups of interactions mean that a primitive procedure has occured. However, there are many cases where interactions are only meant to specify the PARAMETERS of a procedure. Once the parameters are specified and the right interactions were done, we might consider the procedure has been completed. Every time a sequence of interactions may specify that a more complex action was done by the user, a script has to be defined to match on that sequence. So, what can happen on the interface? Aside from basic interactions, a user might do a primitive procedure, thus, we can define procedure scripts. There are also two ways to specify a parameter. CLICK Either you do a sequence of interactions that aim to SELECT an instance that is already available in the knowledge base, Or you create something new, by doing a sequence of interactions that aim to INPUT a new instance in the knowledge base. So, in short, handlers produce basic interactions. Input and selection script produce trap basic interactions and produce input and selection events. Procedure scripts may trap any combination of events, and send a message to the model tracing that a procedure has been done. Interactions

Scripts in action: multiple interactions translated to one problem solving step EnterSimplifiedFraction (FractionOperand, Fraction) Context -Interaction (« SimplifyButton », FractionOperand) -Input (Fraction,FractionOperand) -Interaction (« OkButton », FractionOperand) Input (Fraction , FractionOperand) -Input (Numerator,FractionOperand) Fraction Operand -Input (Denominator,FractionOperand) So, here is what happens when you want to simplify a fraction in our simple fractions lab. As you can see, there are a few scripts involved. Each script specifies what should be done in order for it to match. The script at the top is a procedure script, and describes a problem solving step. The other scripts specify how some of the parameters are input. As you can see, inputting a whole fraction involves inputting The numerator, then the denominator. These instances will be put in the knowledge base BEFORE we can create the fraction, which will REFER to them as its PARTS. CLICK So, when the user wants to simplyfy the fraction, he clicks on the simplify button, which pops up the dialog. CLICK He then enters the numerator, and this interaction matches the script here at the botton. The numerator instance is created and put in the knowledge base, then, an input event is sent. CLICK This event happens to match one step of the other script in the middle. CLICK Something very similar happens when the user enters the denominator. CLICK Another input event is created and the script that specifies how to input hte whole fraction matches, sending another input event. CLICK This event matches the second condition in our procedure script here. Finally, the user clicks the ok button, an action which completes the script for our step. All that is left to do before the model tracing can be informed is to convert the information from all those events into parameters for the procedure. Input (Numerator , FractionOperand) Input (Denominator , FractionOperand) -Interaction (« DenomField », FractionOperand) -Interaction (« NumField », FractionOperand)

Intro: Astus Framework Knowledge representation Procedural knowledge Goals Complex procedures Primitive procedures Semantic knowledge Ontology Instances as parameters Episodic knowledge Path in the procedural graph An original part of Astus is its approach to knowledge representation. First, procedural knowledge for a given problem is represented as a hierarchical graph of goals and precedures, like this one. (CLICK) In red, you can see the goals, and in blue, the procedures. The root of the graph is the initial goal, or intention to solve the problem. Each goal may then be satisfied by one of many procedures, some of which might be erroneous. These procedures are either complex, where they are a script of sub-goals, or primitive, where they are atomic actions, basic problem solving steps.(CLICK) Astus also uses an ontology composed of concepts and relationships between them. This semantic knowledge plays an important role in the coupling of the tutor with the interface, as I will elaborate later. Finally, astus logs problem solving episodes as paths in the procedural knowledge graph (CLICK), with instances of concepts from the ontology as parameters. The model tracing is thus the current episode being built.

Key elements of interface design Mapping semantic knowledge to the interface with views 2. Defining steps on the interface with scripts A standard method of developping user interfaces applied to the ASTUS framework relies on three key elements. CLICK First, we have to give some MEANING to the interface. We achieve this be defining a mapping of the semantic knowledge to the interface with constructs called VIEWS. Second, we have to describe how each basic step or primitive procedure in the model of the solution will be carried out on the interface. We achieve this by defining interaction SCRIPTS. Finally, a more subtle problem arises when a step is identified as done, we have to get its parameters. This will be done by collecting information from the interface with EXTRACTORS. 3. Collecting information from the interface with extractors

User Interfaces and ITS Knowledge Representation User Interface Domain specific ITS Rich feedback and usability Very few constraints on UI design No constraints on KR design Non-reusable code for step recognition Now, let’s see how this coupling is usually achieved. The first type of ITS you would encounter with regards to this design problem, are domain-specific ITS. They usually have a pretty RIGID coupling between the UI and the KR. This gives them a few advantages: Rich feedback and usability, Very few constraints on UI design No constrants on KR design But, the big problem is that step recognition is not generalisable.

User Interfaces and ITS Knowledge Representation User Interface Q. What should determine the contents of semantic knowledge and step grain size? Generic ITS Mapping between KR and UI elements 1 interaction equals 1 step Very little domain-specific code Small steps or hidden interactions Cannot exchange any form of data The concepts and procedures that we want to teach. The second type of ITS would be the generic ones. With those ITS, you will get a looser coupling, if you can make a few sacrifices. You won’t have to build code specific to a domain to integrate it. However, one signal from the user interface must equal one problem solving step. Also, there needs to be a convention on what data can come from the interface and in what form. That means, not all the information scattered on the interface can be retrieved by the tutor. Finally, the one signal for every step constraint has a consequence. Either you do not send a signal to the tutor for EVERY user interaction that occurs, or you add a lot of small, insignificant steps into your knowledge representation. On which side of the compromise should we go? CLICK Well, the answer lies in the fact that we want teach somthing specific, and that is what determines what should be in the knowledge representation. Thus, a good method to bridge that gap should allow us to choose what we will put in our knowledge representation with little regard to how the interface will be designed in the end.

Key elements: Views Which concepts should be viewed? Knowledge Representation User Interface Which concepts should be viewed? -The problem’s data -The tools used to solve the problem Now let’s define the role each of these elements will play in bridging the gap between the user interface and the knowledge representation.(CLICK) Views are the groundwork, defining what the interface means. Every instance from the knowledge base that is shown on the interface should have a view, Associating it to the parts of the interface that represent it on screen. We use the instances from the knowledge representation as the underlying data, or « model » in a « model-view-controller » sense. This means that we usually define a problem-sloving environment’s interface as a set of tools and information, that the learner will use to solve the problem. These tools are represented on screen by parts of the interface, and have their counterparts in the knowledge base as instances. By associating the conceptual tools to the parts of the interface, we effectively give it some MEANING.

Key elements: Scripts Knowledge Representation Model Tracing User Interface Interactions The views were used as a first layer, to establish a semantic link between the interface and the knowledge representation. CLICK The scripts, will in turn be used to define interactivity on the interface and what it MEANS. Their main role is to define how problem solving steps Are achieved on the interface.

Key elements: Extractors Knowledge Representation User Interface What is the place of extractors in all of this? They are the final glue that will make this bridge hold. They bind scripts views and events together. Here’s how they work.

Définition d’un « lolcat » Un Lolcat ou LOLCAT est une image combinant une photographie, généralement un chat, avec une légende humoristique et idiosyncratique dans un anglais écorché - un dialecte qui est appelé « Kitty Pidgin », « lolspeak », ou Lolcat. Le terme « lolcat » est un mot composé des lemmes « LOL » et « cat ». Un autre nom pour ce genre d'image est cat macro, étant donné qu'il s'agit d'une image macro. Référence: http://fr.wikipedia.org/wiki/Lolcat FAIL

Définition d’un « lolcat » Combinaison de rire (lol) et chat (cat) Photo de chat amusante Anglais écorché (lolspeak) Figure 1: un lolcat.

Overview Introduction Key Elements of Interface Design in Astus The Astus Framework Goals of this work User Interfaces and ITS Key Elements of Interface Design in Astus Views Scripts Extractors Conclusion Features Future work Let’s get a glimpse of what I’ll be talking about! I’ll start by introducing the ASTUS framework and the place my work takes in it. Then, I’ll explain the goals we wish to achieve with the implementation of this standard method. Since this work is about user interface integration into ITS, I’ll also briefly explain how this is usually done on existing systems. Then, I’ll present an overview of our method and the key elements that make it work: views, scripts and extractors. Finally, I’ll discuss the features that are currently implemented in our prototype and some others that we wish to develop in the near future.

Overview Introduction Key Elements of Interface Design in Astus The Astus Framework Goals of this work User Interfaces and ITS Key Elements of Interface Design in Astus Views Scripts Extractors Conclusion Features Future work Now that I’ve talked about the problem, let’s talk about a solution, that was designed to follow the previous guidelines AND achieve the goals I mentionned earlier.

Overview Introduction Key Elements of Interface Design in Astus The Astus Framework Goals of this work User Interfaces and ITS Key Elements of Interface Design in Astus Views Scripts Extractors Conclusion Features Future work Now, let’s talk about the second important element of interface design, scripts.

Overview FAIL Introduction Key Elements of Interface Design in Astus The Astus Framework Goals of this work User Interfaces and ITS Key Elements of Interface Design in Astus Views Scripts Extractors Conclusion Features Future work FAIL The last element I will tell you about is the use of EXTRACTORS to gather the information from the interface and convert it into usable parameters for our procedures.

Overview Introduction Key Elements of Interface Design in Astus The Astus Framework Goals of this work User Interfaces and ITS Key Elements of Interface Design in Astus Views Scripts Extractors Conclusion Features Future work Finally, let’s move on to a short conclusion.

Overview Introduction Key Elements of Interface Design in Astus Conclusion Let’s get a glimpse of what I’ll be talking about! I’ll start by introducing the ASTUS framework and the place my work takes in it. Then, I’ll explain the goals we wish to achieve with the implementation of this standard method. Since this work is about user interface integration into ITS, I’ll also briefly explain how this is usually done on existing systems. Then, I’ll present an overview of our method and the key elements that make it work: views, scripts and extractors. Finally, I’ll discuss the features that are currently implemented in our prototype and some others that we wish to develop in the near future.

Overview Introduction Key Elements of Interface Design in Astus The Astus Framework Goals of this work User Interfaces and ITS Key Elements of Interface Design in Astus Conclusion Let’s get a glimpse of what I’ll be talking about! I’ll start by introducing the ASTUS framework and the place my work takes in it. Then, I’ll explain the goals we wish to achieve with the implementation of this standard method. Since this work is about user interface integration into ITS, I’ll also briefly explain how this is usually done on existing systems. Then, I’ll present an overview of our method and the key elements that make it work: views, scripts and extractors. Finally, I’ll discuss the features that are currently implemented in our prototype and some others that we wish to develop in the near future.

Overview Introduction Key Elements of Interface Design in Astus Views Scripts Extractors Conclusion Now that I’ve talked about the problem, let’s talk about a solution, that was designed to follow the previous guidelines AND achieve the goals I mentionned earlier.

Overview Introduction Key Elements of Interface Design in Astus Views Scripts Extractors Conclusion Now, let’s talk about the second important element of interface design, scripts.

Overview Introduction Key Elements of Interface Design in Astus Views Scripts Extractors Conclusion The last element I will tell you about is the use of EXTRACTORS to gather the information from the interface and convert it into usable parameters for our procedures.

Overview Introduction Key Elements of Interface Design in Astus Conclusion Features Future work Finally, let’s move on to a short conclusion.

La disposition en résumé… Police: 28, 24, 18 points, sans empattement, gras. Limitez le nombre d’éléments à 7 par diapo Séparez les éléments avec du vide au lieu d’utiliser les puces et leur espacement. Pour ajouter des éléments, évitez les animations complexes et les sons

La disposition en résumé… Arrière-plan simple, contraste de couleur élevé Limitez tout bloc de texte à 2 lignes Recherchez l’équilibre entre ce qui est dit et ce qui est montré Les diapos doivent être lues rapidement par les auditeurs.

Aidez l’auditoire à se souvenir de la présentation Plan de la présentation clair avec images Le plan doit mettre l’emphase sur le matériel important Introduction et conclusion communs à toutes les présentations Période de questions déjà déterminée par le format

Overview FAIL Introduction Key Elements of Interface Design in Astus The Astus Framework Goals of this work User Interfaces and ITS Key Elements of Interface Design in Astus Views Scripts Extractors Conclusion Features Future work Questions FAIL Let’s get a glimpse of what I’ll be talking about! I’ll start by introducing the ASTUS framework and the place my work takes in it. Then, I’ll explain the goals we wish to achieve with the implementation of this standard method. Since this work is about user interface integration into ITS, I’ll also briefly explain how this is usually done on existing systems. Then, I’ll present an overview of our method and the key elements that make it work: views, scripts and extractors. Finally, I’ll discuss the features that are currently implemented in our prototype and some others that we wish to develop in the near future.

Key elements of interface design Mapping semantic knowledge to the interface with views 2. Defining steps on the interface with scripts A standard method of developping user interfaces applied to the ASTUS framework relies on three key elements. CLICK First, we have to give some MEANING to the interface. We achieve this be defining a mapping of the semantic knowledge to the interface with constructs called VIEWS. Second, we have to describe how each basic step or primitive procedure in the model of the solution will be carried out on the interface. We achieve this by defining interaction SCRIPTS. Finally, a more subtle problem arises when a step is identified as done, we have to get its parameters. This will be done by collecting information from the interface with EXTRACTORS. 3. Collecting information from the interface with extractors

Page-titre: aidez l’auditoire à se souvenir de vous Nom de la personne qui présente Affiliation (écrite et logo) Image qui représente la présentation

A Standard method of Developing User Interfaces for a Generic ITS Framework FAIL 9th International Conference on Intelligent Tutoring Systems Montréal, Canada, June 23-27, 2008 Mikaël Fortin, Jean-François Lebeau, Amir Abdessemed, François Courtemanche and André Mayers Hi, welcome to this talk about « A standard method of developping user interfaces for a generic ITS framework » I’m Mikaël Fortin, I work with Pr. André Mayers on an ITS framework called ASTUS.

A Standard method of Developing User Interfaces for a Generic ITS Framework Hi, welcome to this talk about « A standard method of developping user interfaces for a generic ITS framework » I’m Mikaël Fortin, I work with Pr. André Mayers on an ITS framework called ASTUS. Mikaël Fortin Computer Science Department University of Sherbrooke

Conclusion Synthétisez et illustrez vos résultats Conservez de l’information utile durant les questions L’information présente peut faire naître les bonnes questions

Conclusion Features Multiple interactions per step Extract any form of data Undo and edit steps can be defined too Support for demonstration feedback

Conclusion Future work Flag feedback and red lining More powerful matching algorithm Optional, state-check events

FAIL Questions?

Conclusion Questions? Gains Difficulties Loose, yet thorough coupling Powerful scripts Extract anything Automatic demonstrations Difficulties No flag feedback Difficult to learn Matching algorithm is lacking

Référence Alley, Michael. The Craft of Scientific Presentations. Springer-Verlag, 2003. (Disponible dans Internet à partir du catalogue Crésus).