<?xml version="1.0" standalone="yes"?>
<Paper uid="W98-1427">
  <Title>GENERATION AS A SOLUTION TO ITS OWN PROBLEM</Title>
  <Section position="4" start_page="257" end_page="257" type="metho">
    <SectionTitle>
2 WYSIWYM editing
</SectionTitle>
    <Paragraph position="0"> WYSIWYM is a technique for creating and maintaining knowledge models (e.g., knowledge bases, databases, domain models) by direct knowledge editing with the benefit of dynamic natural language feedback. With WYSIWYM, each operation on the model results in a presentation in natural language of the current state of the'model; this textual description also includes explicit information about what parts of the model remain incomplete (and, of those, which must be obligatorily completed). In this way, text generation technology is used as a means to presen t complex data entry tasks in a way which is both easy to understand and practical to work with.</Paragraph>
    <Paragraph position="1"> The basic idea of WYSIWYM editing is that a special kind of natural language text is generated in order to present the current configuration. This text includes generic phrases called 'anchors' which mark attributes that have no value. The anchors serve as the locations where new objects may be added. By opening a pop-up menu on an anchor, you obtain a list of short phrases describing the types of objects that are permissible values of the attribute; if you select one of the options, a new object of the specified type is added to the semantic network. A new text is then generated to present the modified configuration, including the attributes of the new object.</Paragraph>
    <Paragraph position="2"> As more information is added about a new object, it will be represented by longer spans of text, comprising whole sentences, or perhaps even several paragraphs. These spans of text are also mouse,sensitive, so that the associated semantic material can be cut or copied. The cutting operation removes the network fragment that was previously the value of an attribute, and stores it in a buffer, where it remains available for pasting into another suitable location. The text associated with the fragment may or may not remain the same, depending on the context of the new location.</Paragraph>
    <Paragraph position="3"> Although the user appears to be creating text, she is doing this only indirectly by creating knowledge; it is the system which creates the text. Whereas WYSIWYG editors (e.g., Microsoft Word, FRAMEMAKER and INTERLEAF)present the user with text as it will appear on the printed page, WYSIWYM editors present a text that reflects only what the user meant - not necessary what she will get as the final output.</Paragraph>
  </Section>
  <Section position="5" start_page="257" end_page="263" type="metho">
    <SectionTitle>
3 Illustration of WYSIWYM editing
</SectionTitle>
    <Paragraph position="0"> Our first application of WYSIWYM editing was in the context of the DRAFTER project, which developed a system to support the production of software documentation in English and French (e.g., Paris et al, 1995).</Paragraph>
    <Paragraph position="1"> The system includes a knowledge editor, with which a technical author can define the procedures for using common software applications such as word processors .and diary managers; in this way the author builds the domain model from which atext generator produces instructions, in English and French, that describe thesepr0cedures. The eventual aim of such Systems is to support the technical authors who produce tutorial guides and user manuals for software applications, by automatically generating routine procedural passages in many languages.</Paragraph>
    <Paragraph position="2"> In DRAFTER-I, the first version of the system, knowledge editing was performed through a graphical * interface in which objects in the knowledge base were presented through nested boxes with brief linguistic labels. Some authors found these diagrams hard to interpret and modify, so we decided to explore the new idea of presenting the growing domain model through a natural language text, thus exploiting the multilingual generator to support knowledge editing. The result was a completely re-engineered system, DRAFTER-II, in which the generator not only produces the final output texts, but also supports a WYSIWYM knowledge editor.:</Paragraph>
    <Paragraph position="4"> As a detailed example of WYSIWYM editing, we will describe a session in which a technical author uses DRAFTER-II in order to define the knowledge underlying a brief passage of software documentation. We will suppose that the author is producing a tutorial guide to the OpenWindows Calendar Manager, and is currently working on a section that explains how to schedule an appointment.</Paragraph>
    <Paragraph position="5"> The Calendar Manager's procedure for scheduling an appointment requires various data to be entered in a dialogue box called the Appointment Editor window. With some simplifications, it could be expressed by the following text, which we quote here in order to clarify the author's task.</Paragraph>
    <Paragraph position="6"> To schedule an appointment: Before starting, open the Appointment Editor window by choosing the Appointment option from the Edit menu.</Paragraph>
    <Paragraph position="7"> Then proceed as follows:  1. Choose the start time of the appointment.</Paragraph>
    <Paragraph position="8"> 2. Enter the description of the appointment in the What field.</Paragraph>
    <Paragraph position="9"> 3. Click on the Insert button.</Paragraph>
    <Paragraph position="10">  The author's aim is to introduce this information into the domain model. In the conventional setting, the technical author would be using a word processor to construct this information as text. With DRAFTER-II, the author will be operating at the symbolic (conceptual) level by interacting directly with domain model. If this is done successfully, the system will be able to generate the above text -- or an equivalent one -- in English, French, and any other supported language.</Paragraph>
    <Paragraph position="11"> We now follow stage by stage a session in which the procedure for scheduling an appointment was defined. Each stage is illustrated by the corresponding snapshot in Figure 1.1 Stage 1 The process starts when the author selects the menu options Input: modality and New file (not shown). In response, the system constructs a model of an empty procedure, i.e. one in which a goal and the methods of achieving it are undefined. From this model, the generator produces the single-sentence text shown in the figure. This text has special features related to its authoring function. * The phrase &amp;quot;Do this action&amp;quot; is coloured red, indicating that it marks a mandatory choice, a location where information must be added. In this case, the red phrase represents the undefined goal of the procedure.</Paragraph>
    <Paragraph position="12"> * The phrase &amp;quot;using these methods&amp;quot; is coloured green, indicating that it marks an optional choice, a location where information may be added. In this case, the green phrase represents the undefined methods for achieving the goal.</Paragraph>
    <Paragraph position="13"> * Both coloured phrases are mouse-sensitive. By clicking on either phrase, the author opens a pop-up menu from which a concept may be selected.</Paragraph>
    <Paragraph position="14"> We refer to the mouse-sensitive coloured phrases as 'anchors', by analogy with the links in a hypertext. Anchors can be developed in any order: we will assume in this illustration that the author decides to define the goal of the procedure first, and then the methods for achieving it.</Paragraph>
    <Paragraph position="15"> ~For of lack of space, we have had to cut parts of the snapshots and occassionaUy assume intermediate displays. This means that at times we refer to parts of the display not visible in the figure (e.g., the end of a long pop-up menu) or take the reader through a step that is not shown. We ask the reader's indulgence in this.</Paragraph>
    <Paragraph position="17"/>
    <Paragraph position="19"> Stage 2 To begin the process of defining the goal (scheduling an appointmen0, the author clicks on the red anchor and obtains a pop-up menu listing the available action concepts. Near the bottom of this list (not shown) is the concept schedule. When this concept is selected, DRAFTER-II updateS its model by filling the goal slot with a scheduling action, which includes a new slot for the event to be scheduled (as yet undefined).</Paragraph>
    <Paragraph position="20"> Stage 3 From the updated model, a new text is generated and displayed. The green anchor remains the same, but the anchor &amp;quot;Do this action&amp;quot; is replaced by a phrase showing the information already defined (the scheduling action) in black, along with a new red anchor showing that the author must choose which kind of event is to be scheduled. Although the anchors can be developed in any order, it would be most logical for the author to continue defining the goal by clicking on this event and choosing the appropriate concept, in this case appointment.</Paragraph>
    <Paragraph position="21"> Stage 4 The goal is now completely specificed, since it is shown by a phrase with no red anchors. If an error has been made (e.g. choosing meeting instead of appointment), the author can undo the mistaken choice by opening a pop-up menu on the relevant span of text (in this case, &amp;quot;the meeting&amp;quot;) and selecting the option Cut. This will yield the text in snapshot 3, including the anchor &amp;quot;this event&amp;quot;, so that the correct choice can be made. If the goal were completely wrong, the author could cut the span &amp;quot;Schedule the meeting&amp;quot;, undoing both choices and returning to snapshot 1.</Paragraph>
    <Paragraph position="22"> When satisfied that the goal is correctly defined, the author proceeds to specify the method (or methods) by which appointments can be scheduled. Opening the anchor &amp;quot;using these methods&amp;quot; yields a single menu choice, which the author selects.</Paragraph>
    <Paragraph position="23"> Stage 5 The inclusion of methods in the procedure requires a reorganization of the generated text.</Paragraph>
    <Paragraph position="24"> * Since the material will no longer fit into a single sentence, the generator chooses a different pattern in which the methods are presented in bulleted paragraphs, introduced by an infinitival phrase that presents the goal. The rephrasing of the goal is instructive: it shows that the author has been choosing the meaning, not the words. It is the generator, not the author, that decides how the procedure should be worded; as a result, the wording may change (without any intervention from the author) as the editing of the knowledge proceeds.</Paragraph>
    <Paragraph position="25"> * The model provides for more than one method, since sometimes a goal can be achieved in several ways. Since the author has decided that there will be at least one method, the components of the first method (so far undefined) are shown by suitable anchors; the optional anchor &amp;quot;Next method&amp;quot; can be opened if the author wishes to define further methods.</Paragraph>
    <Paragraph position="26"> * A method comprises a precondition (optional), a sequence of steps (obligatory), and an interrupt procedure (optional). Each step is a procedure, because in addition to a goal it may have methods of its own. The precondition is a task that should be performed before the steps; the interrupt procedure provides a way of abandoning the method if you have second thoughts.</Paragraph>
    <Paragraph position="27"> * Since there must be at least one step, the first step is shown by a sentence with anchors for goal and methods. Further steps can be added by opening the optional anchor &amp;quot;Next step&amp;quot;. The same technique is thus used for a sequence of methods and a sequence of steps, except that the former is presented by a buUeted list and the latter by an enumerated list.</Paragraph>
    <Paragraph position="28">  Stage 6 Since the basic mechanism should now be clear, we now jump to a later stage in which most of the information has been defined; the only missing piece is the method for opening the Appointment Editor window. The transition from snapshot-5 to snapshot 6 could have occurred in several ways, since anchors can be developed in any order; one possibility is the following:  author opens the anchor &amp;quot;using these methods&amp;quot; (snapshot 6). This poses a problem for the generator, since as we have seen the material for an expanded method will not fit into a single sentence. The problem is solved by deferring the procedure for opening the Appointment Editor window to a separate paragraph. As a result of this reorganization of the text, the action of opening the window has to be expressed twice: in the first paragraph, it serves as the precondition in the procedure for scheduling an appointment; in the last paragraph, it serves as the goal of a sub-procedure. Of course this does not mean that there are now two actions. The author might decide to cut one of the phrases &amp;quot;the Appointment Editor window&amp;quot; in order to replace window by another concept, e.g. dialogue-box, thus redefining the action as one of opening the Appointment Editor dialogue-box; the effect on the text would be that both the sentences expressing this action would change. This reinforces the point that the author is editing meaning, not text.</Paragraph>
    <Paragraph position="29"> Stage g From snapshot 7, the author completes the model by developing the anchor &amp;quot;Do this action&amp;quot;, which is eventually replaced by the phrase &amp;quot;Choose the Appointment option from the Edit menu&amp;quot;. At this point the model is potentially complete, since it contains no red anchors 2. When a model is potentially complete, the author can switch the modality from Input to Output in order to obtain a text which simply presents the knowledge base, without indicating the locations at which further information may be added.</Paragraph>
    <Paragraph position="30"> Note that the output text in snapshot 8 is completely regenerated; it is not obtained merely by omitting the green anchors from the input text. In particular, since the method for opening the Appointment Editor window can now be expressed by a phrase, there is no need to defer it to a separate paragraph as in snapshot 7.</Paragraph>
    <Paragraph position="31"> This output text is a computer-generated draft of part of the section of a user manual for the OpenWin- null The text is completely regenerated every time the user changes the domain model or switches the modality. So far we have developed two experimental systems with this architecture. In DRAFTER-II, described above, the domain model and the generator are implemented in Prolog, while the interface is implemented in CLIM (CLIM 1994). In the other system, the Prolog generator produces HTML source files which can be read by a web browser. In both applications, texts several paragraphs long can be generated very quickly, so that when the model is changed the text seems to be updated instantaneously 3 .</Paragraph>
    <Paragraph position="32"> DRAFTER-II currently supports English, French and Italian. Switching from one language to another results in the immediate re-generation of the currently viewed text in the new chosen language. This takes no longer than the generation of a new text when the model is expanded during editing (as described in the steps of Figure 1).</Paragraph>
  </Section>
class="xml-element"></Paper>