<?xml version="1.0" standalone="yes"?>
<Paper uid="W06-3706">
  <Title>Converser(TM): Highly Interactive Speech-to-Speech Translation for Healthcare</Title>
  <Section position="3" start_page="0" end_page="0" type="metho">
    <SectionTitle>
2 Translation Shortcuts
</SectionTitle>
    <Paragraph position="0"> In order to accumulate translations that have been verified by hand and to simplify interaction with the system, we have developed additional functionality called Translation Shortcuts(TM).</Paragraph>
    <Paragraph position="1"> Shortcuts are designed to provide two main advantages: null First, re-verification of a given utterance is unnecessary. That is, once the translation of an utterance has been verified interactively, it can be saved for later reuse, simply by activating a Save as Shortcut button on the translation verification screen. The button gives access to a dialogue in which a convenient Shortcut Category for the Shortcut can be selected or created. At reuse time, no further verification will be required. (In addition to such dynamically created Personal Shortcuts, any number of prepackaged Shared Shortcuts can be included in the system.) Second, access to stored Shortcuts is very quick, with little or no need for text entry. Several facilities contribute to meeting this design crite- null rion.</Paragraph>
    <Paragraph position="2"> * A Shortcut Search facility can retrieve a set of relevant Shortcuts given only keywords or the first few characters or words of a string. The desired Shortcut can then be executed with a single gesture (mouse click or stylus tap) or voice command. null NOTE: If no Shortcut is found, the system automatically gives access to the full power of broad-coverage, interactive speech translation. Thus, a seamless transition is provided between Shortcuts and full translation.</Paragraph>
    <Paragraph position="3"> * A Translation Shortcuts Browser is provided, so that users can find needed Shortcuts by  traversing a tree of Shortcut categories. Using this interface, users can execute Shortcuts even if their ability to input text is quite limited, e.g. by tapping or clicking alone.</Paragraph>
    <Paragraph position="4"> The demonstration will show the Shortcut  the current selected category, for example Conversation, which contains everyday expressions. This category has a Staff subcategory, containing expressions most likely to be used by healthcare staff members. There is also a Patients subcategory, used for patient responses. Such categories as Administrative topics and Patient's Current Condition are also available; and new ones can be freely created.</Paragraph>
    <Paragraph position="5"> * Below the Categories section is the Short-cuts List section, containing a scrollable list of alphabetized Shortcuts. (Various other sorting criteria will be available in the future, e.g. sorting by frequency of use, recency, etc.) * Double clicking on any visible Shortcut in the List will execute it. Clicking once will select and highlight a Shortcut. Typing Enter will execute the currently highlighted Shortcut, if any. * It is possible to automatically relate options for a patient's response to the previous staff member's utterance, e.g. by automatically going to the sibling Patient subcategory if the prompt was given from the Staff subcategory.</Paragraph>
    <Paragraph position="6"> Because the Shortcuts Browser can be used without text entry, simply by pointing and clicking, it enables responses by minimally literate users. In the future, we plan to enable use even by completely illiterate users, through two devices: we will enable automatic pronunciation of Shortcuts and categories in the Shortcuts Browser via text-tospeech, so that these elements can in effect be read aloud to illiterate users; and we will augment Shared Shortcuts with pictorial symbols, as clues to their meaning.</Paragraph>
    <Paragraph position="7"> A final point concerning the Shortcuts Browser: it can be operated entirely by voice commands, although this mode is more likely to be useful to staff members than to patients.</Paragraph>
    <Paragraph position="8"> We turn our attention now to the Input Window, which does double duty for Shortcut Search and arbitrary text entry for full translation. We will consider the search facility first.</Paragraph>
    <Paragraph position="9"> * Shortcuts Search begins automatically as soon as text is entered by any means - voice, handwriting, touch screen, or standard keyboard into the Input Window.</Paragraph>
  </Section>
  <Section position="4" start_page="0" end_page="0" type="metho">
    <SectionTitle>
* The Shortcuts Drop-down Menu appears
</SectionTitle>
    <Paragraph position="0"> just below the Input Window, as soon as there are results to be shown. The user can enter a few words at a time, and the drop-down menu will perform keyword-based searches and present the changing results dynamically.</Paragraph>
    <Paragraph position="1">  show that this is in fact a Shortcut, so that verification will not be necessary. However, final text not matching a Shortcut, e.g. &amp;quot;Good job,&amp;quot; will be passed to the routines for full translation with verification. null</Paragraph>
  </Section>
  <Section position="5" start_page="0" end_page="0" type="metho">
    <SectionTitle>
3 Future developments
</SectionTitle>
    <Paragraph position="0"> We have already mentioned plans to augment the Translation Shortcuts facility with text-to-speech and iconic pictures, thus moving closer to a system suitable for communication with completely illiterate or incapacitated patients.</Paragraph>
    <Paragraph position="1"> Additional future directions follow.</Paragraph>
    <Paragraph position="2"> * Server-based architectures: We plan to move toward completely or partially server-based arrangements, in which only a very thin client software application - for example, a web interface - will run on the client device. Such architectures will permit delivery of our system on smart phones in the Blackberry or Treo class. Delivery on handhelds will considerably diminish the issues of physical awkwardness discussed above, and anytime/anywhere/any-device access to the system will considerably enlarge its range of uses.</Paragraph>
    <Paragraph position="3"> * Pooling Translation Shortcuts: As explained above, the current system now supports both Personal (do-it-yourself) and Shared (prepackaged) Translation Shortcuts. As yet, however, there are no facilities to facilitate pooling of Personal Shortcuts among users, e.g. those in a working group. In the future, we will add facilities for exporting and importing shortcuts.</Paragraph>
    <Paragraph position="4"> * Translation memory: Translation Short-cuts can be seen as a variant of Translation Memory, a facility that remembers past successful translations so as to circumvent error-prone reprocessing. However, at present, we save Shortcuts only when explicitly ordered. If all other successful translations were saved, there would soon be far too many to navigate effectively in the Translation Shortcuts Browser. In the future, however, we could in fact record these translations in the background, so that there would be no need to re-verify new input that matched against them. Messages would advise the user that verification was being bypassed in case of a match.</Paragraph>
    <Paragraph position="5"> * Additional languages: The full SLT system described here is presently operational only for bidirectional translation between English and Spanish. We expect to expand the system to Mandarin Chinese next. Limited working prototypes now exist for Japanese and German, though we expect these languages to be most useful in application fields other than healthcare.</Paragraph>
  </Section>
class="xml-element"></Paper>