File Information

File: 05-lr/acl_arc_1_sum/cleansed_text/xml_by_section/metho/98/w98-0213_metho.xml

Size: 8,170 bytes

Last Modified: 2025-10-06 14:15:10

<?xml version="1.0" standalone="yes"?>
<Paper uid="W98-0213">
  <Title>Multimodal Visualization of Geometrical Constructions</Title>
  <Section position="3" start_page="91" end_page="92" type="metho">
    <SectionTitle>
3 What is a macro?
</SectionTitle>
    <Paragraph position="0"> CabriII can store as &amp;quot;macros&amp;quot; construction methods which users try out. This term is commonly used in the domain of programming by demonstration.</Paragraph>
    <Paragraph position="1"> The aim of writing a macro is to define a new tool by using a list of repeatedly invoked constructions (Sugiura, 96). For instance, it is possible to define a macro to construct the symmetric point of a given point with respect to a line.</Paragraph>
    <Paragraph position="2"> As a matter of fact, CabriII does not store the whole construction, but only its &amp;quot;useful&amp;quot; part, determined automatically when the user indicates the &amp;quot;initial&amp;quot; and &amp;quot;final&amp;quot; objects of the construction. This method lets the user decide to construct a macro after embarking on a complex construction, rather than before. It also minimizes the length of the macro (which is strongly related to the number of objects retained). A consequence of this freedom is that a macro definition has to pass a validation test which can fail for various reasons, such as omission of necessary initial objects, dependency loops (in which an initial object depends on a final object), etc.</Paragraph>
    <Paragraph position="3"> Figure 2 shows the dependencies between geometrical objects in the definition of a construction method for drawing the symmetric point of a given point. The method chosen is the same as in figure 1. The object names are written in order of their creation, from left to right. The names written in single quotes are the names displayed in the diagram, and arrows are used to represent object dependencies. The selected initial object names are surrounded by thin rectangles, and the selected final objects by thicker ones. The macro creation process extracts the smallest graph that connects the final objects to the initial ones.</Paragraph>
    <Paragraph position="4">  Notice that the macro obtained may not correspond exactly to the user's expectations if s/he has made mistakes in certain construction choices. In that case, the user must debug the macro. Using the text form is far better for that purpose than redoing the whole construction.</Paragraph>
    <Paragraph position="5"> 4 Why is a textual view used in geometry? In mathematics, graphical visualization is a fundamental support for reasoning (Zimmermann, 91). The appearance of dynamic geometry opens new doors by making the concept of diagraming more accessible: simply drawing, by contrast, is more static and discrete.</Paragraph>
    <Paragraph position="6"> However, in purely graphical interfaces, the choices which guide the construction of various diagram objects can only be tracked down by observing their effect, i.e. by observing the relative behavior of the objects throughout diagram deformations. There is no longer direct access to the causes, only to the consequences.</Paragraph>
    <Paragraph position="7"> The information displayed is not a complete history including the creation, deformations and deletion of all objects, but rather only a record of the construction steps (dependencies) of the stored objects. One way to display all of the constraints for the whole diagram would be to display the program which drew the diagram.</Paragraph>
    <Paragraph position="8"> Similarly, we can observe that macro definition is closely related to classical programming, so that a textual medium becomes an absolute must. We can also add to the software the full range of classical programming environment tools, such as a step-by-step replay tool associated with cursor progression, or a tool aiding visualization of the correspondence between ob- null ject value and graphic rendering. Specific tools associated with the relevant domain (dynamic geometry) are also useful. For instance, the use of color allows visualization of dependencies between objects, and aids debugging if the macro validation fails.</Paragraph>
    <Paragraph position="9"> 5 Constraints, choices, and shape  Given the target audience for this software, the programming langage chosen is as close as possible to the graphic interface. The display is based on the concept of textual and visual equivalence (Lecolinet, 96) - although in this case &amp;quot;graphical&amp;quot; might be a better term than  &amp;quot;visual&amp;quot;.</Paragraph>
    <Section position="1" start_page="92" end_page="92" type="sub_section">
      <SectionTitle>
5.1 Text generation, object ubiquity
</SectionTitle>
      <Paragraph position="0"> Ubiquity is the ability to be in several places at the same time. In the case of a multimodal interface in a geometry program, ubiquity can be applied to geometrical objects such as points, straight lines, circles, conics, and so on as shown below: to construct a new geometrical object, the user selects a tool, then goes to the diagram and specifies the objects to which that tool is to be applied. Only objects whose types are appropriate for the current tool can be selected.</Paragraph>
      <Paragraph position="1"> CabriII produces demonstration strings which help the user to choose which objects to select and to understand how they will be used by the current tool. Alongside the construction, tools names are displayed in the textual area, and strings are simultaneously displayed in the textual area and under the cursor in the graphical area, along with the names which identify objects.</Paragraph>
    </Section>
    <Section position="2" start_page="92" end_page="92" type="sub_section">
      <SectionTitle>
5.2 Moves in construction sequences
</SectionTitle>
      <Paragraph position="0"> The user can revise a di.agram construction by clicking on recorder buttons. The geometrical objects appear in their drawing order with respect to the object dependency constraints (or disappear according to the selected recorder buttons). The corresponding text for that move in the sequence of effective objects is produced in two colors: flat black for the drawn objects and light blue for the object to be drawn. A third color (red) is used to display current program elements: when the user moves through the macro's internal objects, the programming langage commands are displayed in red.</Paragraph>
    </Section>
    <Section position="3" start_page="92" end_page="92" type="sub_section">
      <SectionTitle>
5.3 Value modification
</SectionTitle>
      <Paragraph position="0"> A &amp;quot;program&amp;quot; is a formal description of the active constructions. Actual values of objects and graphical attributes (color, thickness, and so on) may be displayed in help bubbles associated with the object names. Clicking on a name causes every textual occurrence of the relevant object to be highlighted in green. With a double click, all textual occurrences of the objects which depend on the selected object are also displayed in green, and a help bubble appears.</Paragraph>
    </Section>
  </Section>
  <Section position="4" start_page="92" end_page="93" type="metho">
    <SectionTitle>
6 Results Presentation
</SectionTitle>
    <Paragraph position="0"> Figures 3 and 4 show a diagram and its textual view respectively in English (i.e. when the language chosen by the user is English) and in German. In this diagram, the macro &amp;quot;Sym&amp;quot; is called on point E with respect to line D and  The best way to edit macro constructions is  not yet clear. We are investigating whether editing would be most helpful in the diagram program or directly in the macro program.</Paragraph>
    <Paragraph position="1"> The equivalence of the material presented textually and visually enables every user to program comfortably. The user does not have to type a single character, yet appropriate text is generated in the current dialog language of the interface. The text verifies relevant lexical and syntactic rules. Since the syntax and semantics of the programming language are made obvious, the user learns them easily.</Paragraph>
  </Section>
class="xml-element"></Paper>
Download Original XML