Generating Remote Control Interfaces forComplex Appliances

(Production d'Interfaces de Télécommande pour Appareils Complexes)

Jeffrey Nichols*, Brad A. Myers*, Michael Higgins†, Joseph Hughes†,Thomas K. Harris*, Roni Rosenfeld*, Mathilde Pignol*

School of Computer ScienceCarnegie Mellon University

Pittsburgh, PA 15213{jeffreyn, bam, tkharris, roni}@cs.cmu.edu,

mpignol@andrew.cmu.eduhttp://www.cs.cmu.edu/~pebbles/puc/

†MAYA Design, Inc.Suite 702

2100 Wharton StreetPittsburgh, PA 15203

{higgins, hughes}@maya.com

ABSTRACT 3

KEYWORDS: 3

INTRODUCTION 3

RELATED WORK 8

ARCHITECTURE 11

SPECIFICATION LANGUAGE 13

APPROACH 13INTERFACE ANALYSIS 16

Language Definition 16State Variables and Commands 16Type Information 17Label Information 18Group Tree 19Dependency Information 20

COMMUNICATION PROTOCOL 21

INTERFACE GENERATION 21

GRAPHICAL INTERFACE GENERATOR 21Inferring Panel Structure From Dependencies 22Making the Interface Concrete 25

SPEECH INTERFACE GENERATOR 27Generation Procedure 27Lessons Learned 28

FUTURE WORK 29

CONCLUSION 30

ACKNOWLEDGMENTS 30

(REMERCIEMENTS) 30

REFERENCES 31

Figure 1. A diagrammatic overview of the personal universal controller system, showing an appliance, asnippet from our specification language, and two graphical interfaces generated from the specification.

Figure1. Une vue d'ensemble schématique du système de contrôleur universel personnel, montrant un appareil, un aperçu de notre langage de spécification et deux interfaces graphiques produites avec ce langage.

ABSTRACTThe personal universal controller (PUC) is an aproach for improving the interfaces to complex appliances by introducing an intermediary graphical or speech interface. A PUC engages in two-way communication with everyday appliances, first downloading a specification of the appliance’s functions, and then automatically creating an interface for controlling that appliance. The specification of each appliance includes a high-level description of every function, a hierarchical grouping of those functions, and dependency information, which relates the availability of each function to the appliance’s state. Dependency information makes it easier for designers to create specifications and helps the automatic interface generators produce a higher quality result. We describe the architecture that supports the PUC, and the interface generators that use our specification language to build high-quality graphical and speech interfaces.

ABSTRACT (Résumé)Le contrôleur universel personnel (PUC) est

une approche pour améliorer les interfaces des appareils complexes en présentant un intermédiaire graphique ou oral. Un PUC établit une communication bilatérale avec des appareils quotidiens, téléchargeant d'abord les des fonctions spécifiques de l'appareil et ensuite créant automatiquement une interface pour contrôler cet appareil. La spécification de chaque appareil inclut une description de haut niveau de chaque fonction, un groupement hiérarchique de ces fonctions et des informations de dépendance, qui rapprochent la disponibilité de chaque fonction de l'état de l'appareil. Les informations de dépendance facilitent le travail des designers créer le cahier des charges (les spécifications) et aident les générateurs d'interface automatiques à produire un résultat de bonne qualité. Nous décrivons l'architecture qu'utilise le PUC et les générateurs d'interface qui utilisent notre langage de spécification pour construire des interfaces graphiques et oral de haute qualité.

Keywords: handheld computers, remote control, appliances, personal digital assistants (PDAs), Pebbles, Universal Speech Interface (USI), personal universal controller (PUC)

INTRODUCTION Increasingly, home and office appliances, including televisions, VCRs, stereo equipment, ovens, thermostats, light switches, telephones, and factory equipment, are designed with many complex functions, and often come with remote controls. However, the trend has been that as appliances get more computerized with more features, their user interfaces become harder to use [2]

INTRODUCTIONDe plus en plus, les appareils domestiques et

de bureautique comme les télévisions, les magnétoscopes, les équipements stéréo, les fours, les thermostats, les interrupteurs de la lumière, les téléphones et les équipements du travail, sont conçus avec beaucoup de fonctions complexes et souvent avec des télécommandes. Cependant, la tendance rend ces appareils de plus en plus informatisés, avec plus de fonctions et leurs interfaces utilisateur devient plus difficile à utiliser [2].

Another trend is that people are increasingly carrying computerized devices, such as mobile phones, pagers, and personal digital assistants (PDAs) such as the Palm Pilot or PocketPC. Many of these devices will soon contain processors powerful enough to support speech applications and hardware for wireless networking. Short-distance radio networks, such as 802.11b and Bluetooth [6], are expected to enable many devices to communicate with other devices that are within close range.

Une autre tendance est que les gens portent de plus en plus des dispositifs informatisés, comme des téléphones portables, des radios messagers (pagers) et des aides numériques personnels (PDAs) comme le Palm Pilot ou PocketPC. Beaucoup de ces dispositifs contiendront bientôt des processeurs assez puissants pour supporter des applications orales et le matériel pour la gestion de réseau sans fil. On s'attend à ce que les réseaux à faible porté, comme le wifi (802.11b) et Bluetooth [6], permettre à beaucoup de dispositifs de communiquer avec d'autres dispositifs à leur porté.

We are investigating how handheld devices and speech can improve the interfaces to home and office appliances, using an approach we call the personal universal controller(PUC). A PUC provides an intermediary interface with which the user interacts as a remote control for any appliance. We envision PUCs running on a variety of platforms, including handheld devices with graphical interfaces or hidden PCs with speech recognition software. The PUC differs from today’s universal remote controls, such as the Philips Pronto [17] or the inVoca speech remote [10], because it is self-programming. This means that the PUC engages in a two-way exchange with the appliance, downloading a description of the appliance’s functions and then automatically creating a high quality interface. The PUC and the appliance exchange messages as the user interacts with the interface. The two-way communication allows the appliance to update the interface and provide feedback to the user.

Nous examinons comment des équipements manuel et la parole (commande vocale) peuvent améliorer les interfaces à la maison et au bureau, en utilisant une approche que nous appelons le contrôleur universel personnel (PUC). Un PUC fournit une interface intermédiaire avec laquelle l'utilisateur agit réciproquement comme une télécommande pour n'importe quel appareil. Nous prévoyons PUCS exécutant(dirigeant) sur une variété de plates-formes, y compris des dispositifs à main avec des interfaces graphiques ou des PC cachés avec le logiciel de reconnaissance de la parole. Le PUC diffère de télécommandes universelles d'aujourd'hui, comme Philips Pronto [17] ou le discours inVoca éloigné [10], parce qu'il s'auto programme. Cela signifie que le PUC s'engage dans un échange bilatéral avec l'appareil, téléchargeant une description des fonctions de l'appareil et ensuite créant automatiquement une interface de haute qualité. Le PUC et les messages d'échange d'appareil comme l'utilisateur agissent réciproquement avec l'interface. La communication bilatérale permet à l'appareil de mettre à jour l'interface et fournir des réactions à l'utilisateur.

Another difference from the Pronto and similar devices is the PUC’s ability to provide an interface to the complete functionality of each appliance. Most universal remotes achieve their “universal” nature by providing an interface to only a subset of the most commonly used functions. In our preliminary studies, we have found that doing tasks on a complete PUC interface was still twice as fast as using the actual manufacturer’s interfaces and users made one-half the errors.

Une autre différence du Pronto et des dispositifs semblables est la capacité du PUC'S a fournir une interface complète des fonctionnalités de chaque appareil. La plupart des télécommandes proposent une interface qui n'utilise que les fonctions les plus utilisées. Dans nos études préliminaires, nous avons constaté qu'utiliser une interface crée sur le PUC est deux fois plus rapide que d'utiliser l'interfaces du fabricant et les utilisateurs font moitié moins d'erreurs.

Using a high-level description to generate interfaces also gives the remote controllers flexibility to choose their interface modality. We have created interface generators that can create graphical and speech interfaces. On a PUC that supports it, this might allow the user to switch freely between multiple interactions modalities, perhaps using a graphical interface to browse a list of songs on an MP3 player and a speech interface to pick a particular one. Multiple PUCs that each supported a different modality could also be used simultaneously to achieve the same effect.

L'utilisation d'une description de haut niveau pour produire des interfaces donne aussi la possibilité aux de contrôleurs distants de choisir leur modalité d'interface. Nous avons créé des générateurs d'interface qui peuvent créer des interfaces graphiques ou des interfaces à commandes vocales. Sur un PUC suffisamment performant cela permettrait à l'utilisateur de commuter librement entre différents modes d'interactions, utilisant peut-être une interface graphique pour examiner une liste de chansons sur un lecteur MP3 et une interface vocale pour choisir un morceau particulier. Plusieurs PUCS utilisants des modes d'interactions différents pourraient aussi être utilisée simultanément pour réaliser la même tâche.

The description of the appliance’s functions must have enough information to allow a PUC to generate a high quality user interface, but not contain specifics about how the interface should look or feel. Those choices should be left up to the interface generator. Our specification language contains, like similar systems [16, 29], a hierarchical grouping of all appliance functions that we call the group tree. This tree is determined by the designers of the appliance specifications based upon their understanding of how the appliance’s functions relate to each other.

La description des fonctions de l'appareil doit avoir assez d'informations pour permettre à un PUC de produire une interface utilisateur de haute qualité, mais ne doit pas contenir de détails concernant le loock ou l'agencement. Ces choix devraient être laissés au générateur d'interface. Notre langage de spécification contient, comme des systèmes semblables [16, 29], un groupement hiérarchique de toutes les fonctions des appareils que nous appelons l'arbre de groupe (group tree). Cet arbre est décidé par les designers des spécifications d'appareil et est basé sur leur compréhension de l'interaction des fonctions de l'appareil.

A novel feature of our specification language is that it also includes dependency information, which describes the availability of each function relative to the appliance’s state. Dependency information is useful for two reasons: 1) it allows the interface to provide feedback to the user about the availability of a function, such as “graying out” a button in a graphical interface, and 2) it helps the interface generators organize functions.

Organization improves because dependency information is objective, rather than subjective like the group tree. For example, a graphical interface generator might place sets of functions on overlapping panels because the dependencies indicate they will never be available at the same time. Using a similar technique, the grammar of a speech interface may be simplified because the generator knows that a certain phrase will only make sense when the appliance is in a particular state.

Une nouvelle caractéristique (fonction) de notre langage de spécification est qu'il inclut aussi des informations de dépendance, qui décrivent la disponibilité de chaque fonction selon l'état de l'appareil. Les informations de dépendance sont utiles pour deux raisons :

1. elles permettent à l'interface de fournir des informations à l'utilisateur relatives à la disponibilité d'une fonction, comme griser (graying) un bouton dans une interface graphique et

2. il aide les générateurs d'interface à organiser des fonctions.

L'organisation s'améliore parce que les informations de dépendance sont objectives, plutôt que subjectif comme l'arbre de groupe. Par exemple, un générateur d'interface graphique pourrait placer les jeux de fonctions sur des écrans se chevauchant parce que les dépendances indiquent qu'ils ne seront jamais disponibles en même temps. En utilisant une technique semblable, la grammaire d'une interface vocale peut être simplifiée parce que le générateur sait qu'une certaine expression signifiera seulement quelque chose quand l'appareil est dans un état particulier

The dependency information also makes it easier for designers to create the group tree because there is no need for the tree to exactly match the structure of the resulting interfaces. The designer can approximately match the structure of the appliance in the group tree and the interface generator can infer the rest from the dependencies. Another benefit of this approach is that it allows the designer to include more structure in the group tree than is necessary for most interfaces, e.g. making the tree deeper with smaller groups. This makes our specification more portable because a PUC generating a graphical interface on a small screen can take advantage of this extra detail, while other devices can safely ignore it by comparing the group tree to the structure inferred from dependencies. We have developed algorithms for generating graphical and speech interfaces by combining dependency information with the group tree.

Les informations de dépendance le rendent aussi plus facile pour des designers créer l'arbre de groupe parce qu'il n'y a aucun besoin de l'arbre pour exactement correspondre à la structure des interfaces résultantes. Le designer peut approximativement correspondre à la structure de l'appareil dans l'arbre de groupe et le générateur d'interface peut déduire le reste des dépendances. Un autre avantage de cette approche est qu'il admet que le designer pour inclure plus de structure dans l'arbre de groupe que soit nécessaire pour la plupart des interfaces, faisant par exemple l'arbre plus profond avec des groupes plus petits. Cela fait notre spécification plus d'ordinateur portatif parce qu'un PUC la production d'une interface graphique sur un petit écran peut profiter de ce détail supplémentaire, tandis que d'autres dispositifs peuvent sans risque l'ignorer en comparant l'arbre de groupe à la structure déduite de dépendances. Nous avons développé des algorithmes pour produire graphique et des interfaces de discours en combinant des informations de dépendance avec l'arbre de groupe.

Our speech interface generator uses Universal Speech Interface (USI) techniques. The USI project [19] at Carnegie Mellon University is creating a standardized interaction style for speech communication between humans and machines. A USI design consists of a few syntactic rules and a handful of application-independent keywords, such as options , status, what_is_the, and more. The rules are designed to create a semi-structured interaction style―mnemonic but not necessarily identical to natural language (NL). Unlike full NL interfaces, data collection and skilled grammar creation are not needed, and the small vocabulary and syntactic space ensures high recognition accuracy. Unlike command-and-control speech interfaces, the user need not master any particular application, and can become immediately productive in any new USI application by leveraging their existing knowledge of the universal keywords and rules. Studies have shown that the interaction style can be learned within five minutes of training [21]. Although USI design is guided by analysis of a variety of application types, so far USI designs have been tested primarily in information access applications. The work reported here is the first exploration of USI for device-control applications.

Notre générateur d'interface de discours utilise l'Interface de Discours Universelle (USI) des techniques. Le projet d'USI [19] à Carnegie Mellon l'Université crée un style d'interaction standardisé pour la communication de discours entre des gens et des machines. Une conception d'USI consiste en quelques règles (autorités) syntactiques et une poignée de mots-clés d'application-indépendants, comme des options, le statut, what_is_the et plus. Les règles (autorités) sont conçues pour créer un style d'interaction semi-structuré ? Mnémonique mais non nécessairement identique à langage naturel (NL). À la différence des pleines interfaces NL, la collecte de données et la création de grammaire habile ne sont pas nécessaires et le petit vocabulaire et l'espace syntactique assure la haute exactitude d'identification. À la différence des interfaces de discours de commande-et-contrôle, l'utilisateur n'a pas besoin de surmonter de demande (d'application) particulière et peut devenir immédiatement productif dans n'importe quelle nouvelle demande (application) USI en démultipliant leur connaissance existante des mots-clés universels et des règles (autorités). Les études ont montré que le style d'interaction peut être appris dans cinq minutes de recevoir une formation [21]. Bien que la conception d'USI soit guidée par l'analyse d'une variété de types d'application, jusqu'ici USI des conceptions ont été évalué principalement dans des demandes (applications) d'accès à l'information. Le travail annoncé est ici la première exploration d'USI pour des demandes (applications) de contrôle de dispositif.

Another important piece of the PUC system is the ability to control actual appliances from the interfaces created by our generators. To enable this, the PUC system provides appliance adaptors: software and hardware that translate from the proprietary communication protocols found on many appliances to our PUC protocol. This architecture has allowed us to use PUCs to control a shelf stereo, camcorders with IEEE 1394 support via the AV/C protocol, the WinAmp media player, a Mitsubishi VCR that supports HAVi [7], and several others. We are working to support emerging industry standards such as UPnP [26] and JINI [24].

Un autre morceau important du système PUC est la capacité de contrôler des appareils réels des interfaces créées par nos générateurs. Pour le permettre, le système PUC fournit des adaptateurs d'appareil : le logiciel et le matériel qui traduit des protocoles de communication de marque déposée trouvés sur beaucoup d'appareils à notre protocole PUC. Cette architecture nous a permis d'utiliser PUCS pour contrôler une planche stéréo, des caméscopes avec IEEE 1394 appui via le protocole AV/C, l'acteur(le joueur) de médias WinAmp, un magnétoscope Mitsubishi qui soutient HAVI [7] et plusieurs d'autres. Nous travaillons pour soutenir des normes(standards) d'industrie naissantes(émergentes) comme UPNP [26] et JINI [24].

The next section of this paper examines related work. In the sections following we describe the architecture in greater detail, and discuss the specification language and our approach to its design. We continue by describing our communication protocol, followed by a detailed section discussing the graphical and speech interface generators and their use of dependency information. We conclude with thoughts on future directions for this project.

La section suivante de ce papier (journal) examine le travail lié. Dans les sections après nous décrivons l'architecture dans le détail plus grand et discutons la langue de spécification et notre approche à sa conception. Nous continuons en décrivant notre protocole de communication, suivi par une section détaillée discutant les graphiques et des générateurs d'interface de discours et leur utilisation d'informations de dépendance. Nous concluons (nous terminons) avec des pensées sur des directions futures pour ce projet.

RELATED WORKA number of research groups are working on controlling appliances from handheld devices. Hodes, et. al. propose a similar idea to our PUC, which they call a “universal interactor” that can adapt itself to control many devices [8]. However, their research focuses on the system and infrastructure issues rather than how to create the user interfaces. An IBM project [5] describes a “Universal Information Appliance” (UIA) that might be implemented on a PDA. The UIA uses an XML-based language called MoDAL from which it creates a user interface panel for accessing information. However, the MoDAL processor apparently only handles simple layouts and its only type of input control is text strings. The Stanford ICrafter [18] is a framework for distributing appliance interfaces to many different controlling devices. While their framework supports the automatic generation of interfaces, their paper focuses on handgenerated interfaces and shows only one simple automatically generated interface. They also mention the difficulty of generating speech interfaces.

Un certain nombre de groupes de recherche travaillent en direction d'appareils de dispositifs à main. Seaux à charbon et. Al-. Proposez une idée semblable à notre PUC, qu'ils appellent "un interacteur universel" qui peut s'adapter pour contrôler beaucoup de dispositifs [8]. Cependant, leur recherche se concentre sur le système et les questions (publications) d'infrastructure plutôt que la façon de créer les interfaces utilisateur. Un projet d'IBM [5] décrit "un Appareil Universel de L'information" (UIA) qui pourrait être mis en oeuvre sur un PDA. L'UIA utilise un langage basé sur XML, appelé Modale dont il crée un panneau (jury) d'interface utilisateur pour avoir accès à l'information. Cependant, le processeur Modal apparemment manipule seulement des dispositions simples et son seul type de contrôle d'entrée est des chaînes de caractères. Stanford ICrafter [18] est une structure pour distribuer des interfaces d'appareil à beaucoup de dispositifs de direction différents. Tandis que leur structure soutient la génération automatique d'interfaces, leur papier (journal) se concentre sur des interfaces handgenerated et montre seulement un simple l'interface automatiquement produite. Ils mentionnent aussi la difficulté de produire des interfaces de discours.

UIML [1] is an XML language that claims to provide a highly-device independent method for user interface design. UIML differs from the PUC in its tight coupling with the interface. UIML specifications can define the types of components to use in an interface and the code to execute when events occur. The PUC specification language leaves these decisions up to each interface generator.

UIML [1] est une langue XML qui revendique fournir la méthode indépendante à un fortement-dispositif pour la conception d'interface utilisateur. UIML diffère du PUC dans son accouplement serré avec l'interface. UIML des spécifications peut définir les types de composants pour utiliser dans une interface et le code pour exécuter quand les événements arrivent. La langue de spécification PUC laisse (quitte) ces décisions jusqu'à chaque générateur d'interface.

The XWeb [16] project is working to separate the functionality of the appliance from the device upon which it is displayed. XWeb defines an XML language from which user interfaces can be created. Unlike the PUC specification language, XWeb’s language uses only a tree for specifying structural information about an appliance. Their approach seems to work well for interfaces that have no modes, but it is unclear how well it would work for remote control interfaces, where modes are commonplace. XWeb also supports the construction of speech interfaces. Their approach to speech interface design, including emphasis on a fixed language and cross-application skill transference, is quite similar to ours, as it is derived from a joint philosophy [20]. XWeb’s language design allows users to directly traverse and manipulate tree structures by speech, however they report that this is a hard concept for users to grasp [16]. Our Universal Speech Interface design differs by trying to stay closer to the way people might talk about the task itself, and is somewhat closer to naturally generated speech.

Le XWEB [16] le projet travaille pour séparer la fonctionnalité de l'appareil du dispositif sur lequel il est montré. XWeb définit une langue XML dont les interfaces utilisateur peuvent être créées. À la différence de la langue de spécification PUC, la langue du XWEB'S utilise seulement un arbre pour spécifier l'information structurelle sur un appareil. Leur approche semble travailler bien pour les interfaces qui n'ont aucun mode, mais il est peu clair comment bien il travaillerait pour des interfaces de télécommande, où les modes sont banals. XWeb soutient aussi la construction d'interfaces de discours. Leur approche à la conception d'interface de discours, y compris l'accent sur une langue fixée et une transmission d'habileté(de compétence) à travers d'application, est tout à fait semblable au nôtre, comme il est tiré d'une philosophie commune [20]. La conception de langue du XWEB'S permet aux utilisateurs de directement traverser et manipuler des structures d'arbre par le discours, cependant ils annoncent que c'est un concept dur pour des utilisateurs pour saisir [16]. Notre conception d'Interface de commande vocale Universelle diffère en essayant de rester tout près de la voie que les gens pourraient parler de la tâche lui-même et sont quelque peu plus proches du langage naturel.

Figure 2. An architectural diagram of the PUC system showing one connection (multiple connections are allowed at both ends).

Figure 2. Un diagramme architectural du système PUC montrant une connexion (des connexions multiples sont permises dans les deux sens).

The INCITS V2 [30] standardization effort is developing the Alternative Interface Access Protocol (AIAP) to help disabled people use everyday appliances with an approach similar to the PUC. AIAP contains a description language for appliances that different interface generators use to create interfaces for both common devices, like the PocketPC, and specialized devices, such as an interactive braille pad. We have begun collaborating with the V2 group and plan to continue this in the future.

L'INCITS V2 [30] l'effort de standardisation développe le Protocole d'Accès d'Interface Alternatif (AIAP) pour aider les gens mis hors de service à utiliser des appareils quotidiens avec une approche semblable au PUC. AIAP contient une langue de description pour des appareils que des générateurs d'interface différents utilisent pour créer des interfaces tant pour des dispositifs communs, comme le PocketPC, que pour des dispositifs spécialisés, comme un clavier (tapis, écran) braille interactif. Nous avons commencé à collaborer avec le groupe V2 et planifions de le continuer dans l'avenir.

A number of research systems have looked at automatic design of user interfaces for conventional computers. These sometimes went under the name of “model-based” techniques [25]. Here, the programmer provides a specification (“model”) of the properties of the application, along with specifications of the user and the display. This approach was moderately successful for creating dialog boxes [11, 27] and creating complete interfaces in a limited range [15, 25]. The ITS system from IBM was used to create all the screens for the information kiosks at the EXPO’92 worlds fair [29]. Of particular note is the layout algorithm in the DON system that achieved a pleasing, compact, and logical placement of the controls [11]. We extend these results to create panels of controls on significantly different handhelds, without requiring designer intervention after the interfaces are generated.

Un certain nombre de systèmes de recherche ont regardé la conception automatique d'interfaces utilisateur pour des ordinateurs conventionnels. Ceux-ci allaient parfois sous le nom de techniques "à base de modèle" [25]. Ici, le programmeur fournit une spécification ("le modèle") des propriétés de la demande(l'application), avec les spécifications de l'utilisateur et l'exposition. Cette approche était modérément couronnée de succès pour créer des boîtes de dialogue [11, 27] et créer des interfaces complètes dans une gamme limitée [15, 25]. Le SON système d'IBM a été utilisé pour créer tous les écrans pour les kiosques de l'information à l'EXPO ' 92 expositions universelles [29]. De note particulière est l'algorithme de disposition dans le système de DON qui a réalisé une complaisance, le placement compact et logique des commandes [11]. Nous prolongeons(étendons) ces résultats pour créer les écrans de commandes sur des ordinateurs de poche significativement différents, sans exiger l'intervention de designer après que les interfaces sont produites.

ARCHITECTUREThe PUC architecture has four parts: appliance adaptors, a specification language, a communication protocol, and interface generators (see Figure 2). There are several benefits to the design we have chosen:

Interfaces can be automatically generated. The peer-to-peer connection model allows

for scalability. The transport layer independence between

PUCs and appliances makes communication easier.

Proprietary appliance control protocols can be separated from the PUC framework.

L'architecture PUC a quatre parties : des adaptateurs d'appareil, une langue de spécification, un protocole de communication et des générateurs d'interface (voir la Figure(le Chiffre) 2). Il y a plusieurs bénéfices à la conception que nous avons choisie :

des Interfaces peuvent être générées automatiquement.

Le modèle peer-to-peer connexion tient compte de l'adaptabilité.

L'indépendance de couche de transport entre PUCS et des appareils fait la communication plus facile.

des protocoles de contrôle d'appareil de Marque déposée peuvent être séparés de la structure PUC.

The PUC architecture is designed to allow for automatic interface generation by a wide range of devices in a wide range of modalities. This is enabled by a two-way communication protocol and a specification language that allows each appliance to describe its functions to an interface generator. The specification language separates the appliance from the type of interface that is being used to control it, such as a graphical interface on a handheld or a speech interface on a mobile phone. A later section in this paper describes interface generators that we have created for the graphical and speech modalities.

L'architecture PUC est conçue pour tenir compte de la génération d'interface automatique par un grand choix de dispositifs dans un grand choix de modalités. Un protocole de communication bilatéral le permet et une langue de spécification qui permet à chaque appareil de décrire ses fonctions à un générateur d'interface. La langue de spécification sépare l'appareil du type d'interface qui est utilisée pour le contrôler, comme une interface graphique sur un ordinateur de poche ou une interface de discours sur un téléphone portable. Plus tard dans nous decrirons les générateurs d'interface que nous avons créés pour le graphique et les commandes vocales.

A key part of the architecture is the network that PUCs and appliances use to communicate. We assume that each appliance has its own facility for accepting connections from a PUC. The peer-to-peer aspect of this choice allows the PUC architecture to be more scaleable than other systems, such as ICrafter [18] and UIA [5], which rely on a central server to manage connections between interfaces and appliances. A PUC could discover appliances by intermittently sending out broadcast requests, as in the service discovery portion of the Bluetooth [6] protocol. However, service discovery has not yet been implemented and is the subject of future work.

Une partie clef de l'architecture est le réseau que les PUCs et les appareils utilisent pour communiquer. Nous supposons que chaque appareil a la possibilité de communiquer avec un PUC. Le choix du "peer-to-peer" permet à l'architecture PUC d'être plus adaptable que d'autres systèmes, comme ICRAFTER [18] et UIA [5], qui compte sur un serveur central pour gérer les connexions entre des interfaces et les appareils. Un PUC pourrait découvrir des appareils en faisant par intermittence sortir des demandes d'émission, comme dans la partie de découverte de service du protocole Bluetooth [6]. Cependant, la découverte de service n'a pas encore été mise en oeuvre et est le sujet de travaux futur.

We have also attempted to make communication easier by making few assumptions about the underlying transport mechanism. It is unreasonable to expect that every controller device will be able to communicate over the 802.11b wireless Ethernet protocol, for example. The communication protocol, described later, has been designed with a small number of messages to operate over a wide variety of transport layers. The protocol is currently only implemented on TCP/IP, but we have plans to implement on a nonreliable protocol such as UDP, and also on Bluetooth if it becomes widespread.

Nous avons aussi essayé de faire la communication plus facile en faisant peu de suppositions du mécanisme sous-jacent de transport. Il est peu raisonnable de s'attendre à ce que chaque dispositif de contrôleur soit capable de communiquer sur le 802.11b à la radio le protocole d'Ethernet, par exemple. Le protocole de communication, décrit plus tard, a été conçu avec un petit numéro(nombre) de messages pour fonctionner sur une large variété de couches de transport. Le protocole est actuellement seulement mis en oeuvre sur le TCP/IP, mais nous avons des plans de mettre en oeuvre sur un protocole nonfiable comme UDP et aussi sur Bluetooth si cela devient répandu.

Although we assume network independence for PUC communication, we cannot make any assumptions about how to communicate with actual appliances. Several standards exist for appliance control, including Microsoft’s UPnP [26], Sun’s JINI [24], and HAVi [7], but so far none of these have been widely accepted. Many consumer electronics manufacturers have their own proprietary methods for communicating with and between their appliances. Often these methods are not available for use by the general public, although there are Internet groups dedicated to reverse engineering these protocols [9]. Most devices in the lowend market have no means of being controlled externally, except for one-way IR-based remote control. These appliances must be altered at the hardware level to achieve twoway communication with a PUC.

Bien que nous assumions l'indépendance de réseau pour la communication PUC, nous ne pouvons pas faire de suppositions de la façon de communiquer avec des appareils réels. Plusieurs standards existent pour le contrôle d'appareil, y compris UPNP de Microsoft [26], JINI de Soleil [24] et HAVI [7], mais jusqu'ici aucun de ceux-ci n'a été largement accepté. Beaucoup de fabricants d'électronique grand public ont leurs méthodes propres de marque déposée pour communiquer avec et entre leurs appareils. Souvent ces méthodes ne sont pas disponibles pour l'utilisation par le grand public, bien qu'il y ait des groupes d'Internet consacrés pour changer complètement l'ingénierie de ces protocoles [9]. La plupart des dispositifs bas de gamme n'ont aucun moyen d'être pilotés extérieurement, à part la télécommande IR-based à sens unique. Ces appareils doivent être changés au niveau de matériel pour réaliser la communication bilatérale avec un PUC.

(a) (b)

Figure 3. a) The Aiwa CX-NMT70 shelf stereo and b) the AT&T 1825 telephone/digital answering machine used in our research.Figure3. a) l'Aiwa CX-NMT70 mini chaine et b) 1825 AT*T répondeur téléphonique téléphonique/digital utilisé dans notre

recherche

To connect the PUC to any real appliance, we must build an appliance adaptor, i.e. a translation layer to its built-in protocol (see Figure 2). We imagine that an adaptor would be built for each proprietary appliance protocol that the PUC communicates with. For example, we have built a software adaptor for the AV/C protocol that can control most camcorders that support IEEE 1394. We have also built adaptors for connecting to specific devices, such as an Audiophase shelf stereo that we modified with custom hardware to enable two-way communication. We have recently begun constructing an adaptor for the HAVi protocol, and plan to pursue UPnP in the future. This architecture allows a PUC to control virtually any appliance, provided the appliance has a built-in control protocol or someone has the hardware expertise to add one.

Pour connecter le PUC à n'importe quel appareil réel, nous devons construire un adaptateur d'appareil, c'est-à-dire une couche de traduction à son protocole incorporé (voir la Figure 2). Nous imaginons qu'un adaptateur serait construit pour chaque protocole d'appareil de marque déposée avec lequel le PUC communique. Par exemple, nous avons construit un adaptateur de logiciel pour le protocole AV/C qui peut contrôler la plupart des caméscopes cet appui IEEE 1394. Nous avons aussi construit des adaptateurs pour unir(connecter) aux dispositifs spécifiques, comme une planche Audiophase stéréo que nous avons modifié avec le matériel douanier(personnalisé) pour permettre à la communication bilatérale. Nous avons récemment commencé à construire un adaptateur pour le protocole HAVI et planifions de poursuivre UPNP dans l'avenir. Cette architecture permet à un PUC de contrôler pratiquement n'importe quel appareil, pourvu que l'appareil ait un protocole de contrôle incorporé ou quelqu'un a l'expertise de matériel d'ajouter celui.

In order to make the construction of new appliance adaptors easy, we have created an adaptor development framework. The framework, implemented entirely in Java, manages all PUC communication for the adaptor, allowing the programmer to concentrate on communicating with the appliance. Using our framework, we implemented adaptors for the X10 protocol and the WinAmp media player in a matter of hours.

Pour faire la construction de nouveaux adaptateurs d'appareil faciles, nous avons créé une structure de développement d'adaptateur. La structure, mise en oeuvre entièrement dans la Java, gère à toute la communication PUC pour l'adaptateur, permettant au programmeur de se concentrer en communication avec l'appareil. En utilisant notre structure, nous avons mis en oeuvre des adaptateurs pour le protocole X10 et le joueur de médias WinAmp dans une question d'heures.

SPECIFICATION LANGUAGE There must be a description of an appliance’s functions so the PUC can automatically generate an interface. This description must contain enough information to generate a good user interface, but it should not contain any information about look or feel. Decisions about look and feel should be left up to each interface generator. Further requirements for our specification language are described elsewhere [13].

Il doit y avoir une description des fonctions d'un appareil donc le PUC peut automatiquement produire une interface. Cette description doit contenir assez d'information pour produire une bonne interface utilisateur, mais il ne devrait pas contenir d'information sur le l'apparence ou le sens. Les décisions du regard(de l'apparence) et le sens devraient être laissées(quittées) jusqu'à chaque générateur d'interface. De nouvelles exigences(conditions) pour notre langue de spécification sont décrites ailleurs [13].

Approach As a first step towards determining what information should be included in the specification language, we hand-designed control panels for two appliances. We evaluated them for quality with users, and then extracted the features of these control panels that contribute most to their usability.

Comme un premier pas vers la détermination quelle information devrait être incluse dans la langue de spécification, nous des panneaux de configuration conçus de main pour deux appareils. Nous les avons évalués pour la qualité avec des utilisateurs et avons ensuite extrait les fonctions(dispositifs) de ces panneaux de configuration qui contribuent le plus à leur rentabilité.

(a) (b)

(c) (d)

Figure 4. Hand-designed interfaces for the phone (a-b) and stereo (c-d) on the Palm and PocketPC. The Palm interfaces are paper prototypes, whereas the PocketPC interfaces were actually implemented in Microsoft’s embedded Visual Basic.

Figure 4. Interfaces Conçues de main pour le téléphone (a-b) et stéréo (c-d) sur la Paume et PocketPC. Les interfaces de Paume sont des prototypes de papier, tandis que les interfaces PocketPC ont été en réalité mises en oeuvre à Microsoft

incorporé Visuel de Base.

We chose two common appliances as the focus of our handdesigns: the Aiwa CX-NMT70 shelf stereo with its remote control, and the AT&T 1825 telephone/digital answering machine (see Figure 3). We chose these two appliances because both are common, readily available, and combine several functions into a single unit. The AT&T telephone is the standard unit installed in many offices at Carnegie Mellon, and Aiwa-brand stereos seem to be common, at least among the user population that participated in our comparison studies. Ten of our twenty-five subjects owned Aiwa systems.

Nous avons choisi deux appareils communs comme le centre de notre handdesigns : l'Aiwa CX-NMT70 la planche stéréo avec sa télécommande et 1825 AT*T le répondeur téléphonique téléphonique/digital (voir la Figure(le Chiffre) 3). Nous avons choisi ces deux appareils parce que tant sommes communs, aisément disponibles, que combinons plusieurs fonctions dans une unité simple. Le téléphone d'AT*T est l'unité standard installée dans beaucoup de bureaux à Carnegie Mellon et l'Aiwa-marque stereos semble être commune, au moins parmi la population d'utilisateur qui a participé à nos études de comparaison. Dix de nos vingt-cinq sujets ont possédé des systèmes Aiwa.

We created our hand-designed interfaces in two phases, initially on paper and later as Visual Basic implementations on a Microsoft PocketPC. Each interface supported the complete set of appliance functions. At each phase, we iteratively improved the interfaces with heuristic analyses and performed a user study. The user study in each phase was dual-purpose: to compare our hand-designed interfaces with the interfaces on the actual appliances and to see what problems users had with the hand-designed interfaces.

Nous avons créé nos interfaces conçues de main dans deux phases, initialement sur le article et plus tard comme des mises en oeuvre Visuelles de Base sur Microsoft PocketPC. Chaque interface a soutenu le jeu complet de fonctions d'appareil. À chaque phase, nous avons itérativement amélioré les interfaces avec des analyses heuristiques et avons exécuté une étude d'utilisateur. L'étude d'utilisateur dans chaque phase était à double usage : comparer nos interfaces conçues de main avec les interfaces sur les appareils réels et voir quels utilisateurs de problèmes avaient avec les interfaces conçues de main.

The comparison study in both phases showed that our handdesigned interfaces were much better than the manufacturer’s interfaces on the actual appliances [14]. In both studies users were asked to perform a variety of simple and complex tasks. Some simple tasks were dialing the phone or changing the volume on the stereo, whereas some complex tasks were programming a list of tracks into the stereo’s CD player or copying a message between two of the four mailboxes on the telephone’s built-in answering machine. We found that for both hand-designed interfaces, Palm paper prototypes and PocketPC implementations, users completed tasks in one-half the time and with one-half the errors as compared to the actual appliances [14].

L'étude de comparaison dans les deux phases a montré que nos interfaces handdesigned étaient beaucoup meilleures que les interfaces du fabricant sur les appareils réels [14]. Dans les deux utilisateurs d'études ont demandé pour d'exécuter une variété de tâches simples et complexes. Quelques tâches simples composaient le téléphone ou changeaient le volume sur le stéréo, tandis que quelques tâches complexes programmaient une liste de traces dans le lecteur de CD du stereo's ou copiaient un message entre deux des quatre boîtes aux lettres sur le répondeur téléphonique incorporé du téléphone. Nous avons constaté que tant pour des interfaces conçues de main, des prototypes de papier(journal) de Paume que des mises en oeuvre PocketPC, les utilisateurs ont achevé des tâches dans la moitié le temps et avec la moitié les erreurs en comparaison des appareils réels [14].

The large differences in this study can be attributed to problems with the appliance interfaces. Most of the problems users had with the built-in appliance interfaces could be traced to poor button labels and inadequate interface feedback. Both appliances had buttons with two functions, one when the button was pressed and released and one when the button was pressed and held. Our subjects rarely discovered the press and hold function. The stereo also had buttons that changed function with the appliance’s mode.

Les grandes différences de cette étude peuvent être attribuées aux problèmes avec les interfaces d'appareil. La plupart des utilisateurs de problèmes avaient avec les interfaces d'appareil incorporées pourrait être tracé aux pauvres étiquettes de bouton et des réactions d'interface inadéquates. Les deux appareils avaient des boutons avec deux fonctions, celui quand le bouton a été appuyé et sorti et celui quand le bouton a été appuyé et tenu. Nos sujets découvraient rarement la Presse et tenir la fonction. Le stéréo avait aussi les boutons qui ont changé la fonction avec le mode de l'appareil.

Interface Analysis Once we were confident that our interfaces were usable, we analyzed them to understand what functional information about the appliance was needed for designing the interfaces. This included questions such as “why are these elements grouped together?” or “why are these widgets never shown at the same time?” These are questions that might suggest what information should be contained in the specification language.

Une fois que nous étions confiants que nos interfaces étaient utilisables, nous les avons analysés pour comprendre quelle information fonctionnelle sur l'appareil a été nécessaire pour concevoir les interfaces. Ces questions incluses comme "pourquoi ces éléments sont-ils groupés ensemble ?" Ou "pourquoi on ne jamais jamais montre ces gadgets(machins) ?" Ceux-ci sont les questions qui pourraient suggérer ce que l'information devrait être contenue dans la langue de spécification

Language Definition The PUC specification language is XML-based and includes all of the information that we found in our analysis of the hand-designed interfaces. The language has been fully documented and a DTD is available for validating specifications. The documentation can be downloaded from our project web site:http://www.cs.cmu.edu/~pebbles/puc/specification.html

La langue de spécification PUC est XML-BASÉE et inclut toute l'information que nous avons trouvée dans notre analyse des interfaces conçues de main. La langue a été entièrement documentée et une DTD est disponible pour valider des spécifications. La documentation peut être téléchargée de notre site Web de projet : http://www.cs.cmu.edu/~pebbles/puc/specification.html

State Variables and Commands Interface designers must know what can be manipulated on an appliance before they can build an interface for it. We discovered from our PocketPC implementations that most of the manipulable elements could be represented as state variables. Each state variable has a given type that tells the interface generator how it can be manipulated. For example, the radio station state variable has a numeric type, and the interface generator can infer the tuning function because it knows how to manipulate a numeric type. Other state variables include the current track of the CD player and the status of the tape player (stop, play, fast-forward, etc.).

Les designers d'interface doivent savoir(connaître) ce qui peut être manipulé sur un appareil avant qu'ils ne puissent construire une interface pour cela. Nous avons découvert de nos mises en oeuvre PocketPC que la plupart des éléments manipulable pourraient être représentés comme des variables d'état. Chaque variable d'état a un type donné qui dit au générateur d'interface comment elle peut être manipulée. Par exemple, la station d'émission déclare que la variable a un type numérique et le générateur d'interface peut déduire la fonction de réglage d'accord parce qu'il sait(connaît) comment manipuler un type numérique. D'autres variables d'état incluent la trace actuelle du lecteur de CD et le statut du lecteur de cassette (l'arrêt, le jeu(la pièce), rapide-en-avant, etc).

After further exploration, we discovered that state variables are not sufficient for describing all of the functions of an appliance. Some elements, such as the seek button on a radio, cannot be represented as state variables. Pressing the seek button causes the radio station state variable to change to some value that is not known in advance. The seek function must be represented as a command, a function whose result cannot be described easily in the specification.

Après une nouvelle recherche, nous avons découvert que des variables d'état ne sont pas suffisantes pour décrire toutes les fonctions d'un appareil. Quelques éléments, comme le bouton se cherchant en radio, ne peuvent pas être représentés comme des variables d'état. L'appuyant du bouton se cherchant cause à la station d'émission exposent la variable pour changer à une certaine valeur que l'on ne connaît pas d'avance. La fonction se cherchant doit être représentée comme une commande, une fonction dont le résultat ne peut pas être décrit facilement dans la spécification.

Commands are also useful when an appliance is unable to provide feedback about state changes back to the controller, either by manufacturer choice or a hardware limitation of the appliance. In fact, the remote control technology of today can be simulated on the PUC by writing a specification that includes only commands. This is exactly like building a remote control that has only buttons. Any feedback is then restricted to the appliance’s front panel.

Les commandes sont aussi utiles quand un appareil est incapable de fournir des réactions de changements d'état en arrière au contrôleur, par le choix de fabricant ou une limitation de matériel de l'appareil. En fait, la technologie de télécommande de peut aujourd'hui être simulée sur le PUC en écrivant une spécification qui inclut seulement des commandes. C'est exactement comme la construction(le bâtiment) d'une télécommande qui a seulement des boutons. N'importe quelles réactions sont alors limitées au écrans de devant de l'appareil.

Type InformationEach state variable must be specified with a type so that the interface generator can understand how it may be manipulated. For example, in Figure 1 the state shown has an integer type. We define seven generic types that may be associated with a state variable:

Boolean integer fixed point floating point enumerated string custom

Chaque variable d'état doit être spécifiée avec un type pour que le générateur d'interface puisse comprendre comment il peut être manipulé. Par exemple, dans la Figure(le Chiffre) 1 l'état montré a un type d'entier. Nous définissons sept types génériques qui peuvent être associés à une variable d'état :

Boolean Integer Fixed point Floating point Enumerated String Custom

The most interesting of these types is the custom type, which is provided to allow for the specification of standard widget arrangements, such as the play-stop-pause button groups seen in Figure 4c-d. Each of these button groups represents one state variable, the status of the CD and tape players respectively. Such a widget arrangement presents two problems: the first is that there is a complex mapping desired between the state of the appliance and the interface elements presented to the user; the second is that this complex mapping can and should be reused. Ideally, interface generators will recognize custom types and present a familiar set of interface elements. This is always what happens in the current implementation. It is unreasonable, however, to expect every interface generator to understand every custom type. Therefore we intend to provide a type interrogation feature in our protocol which will involve breaking down a custom type into simpler component types that can be guaranteed to be understood across all interface generators.

Le plus intéressant de ces types est le type custom, qui est conçu pour permettre la spécification de dispositions de fenètre standard, comme les groupes de boutons play-stop-pause vu dans la Figure 4c-d. Chacun de ces groupes de bouton représente une variable d'état, le statut du CD et des lecteurs de cassette respectivement. Une telle entente de gadget(machin) présente deux problèmes : le premier est qu'il y a un complexe dressant la carte désirable entre l'état de l'appareil et les éléments d'interface ont présenté à l'utilisateur; le deuxième est que cette configuration de complexe peut et devoir être réutilisé. Idéalement, les générateurs d'interface reconnaîtront des types custom et présenteront un jeu familier d'éléments d'interface. C'est toujours ce qui arrive dans la mise en oeuvre actuelle. C'est peu raisonnable, cependant, s'attendre à ce que chaque générateur d'interface comprenne chaque type custom (personnalisé). Donc nous avons l'intention de fournir une fonction(un dispositif) d'interrogation de type dans notre protocole qui impliquera la destruction d'un type custom(personnalisé) dans les types composants plus simples que l'on peut garantir être compris à travers tous les générateurs d'interface. C'est peu raisonnable, cependant, s'attendre à ce que chaque générateur d'interface comprenne chaque type custom (personnalisé). Donc nous avons l'intention de fournir une fonction(un dispositif) d'interrogation de type dans notre protocole qui impliquera la destruction d'un type custom (personnalisé) dans les types composants plus simples que l'on peut garantir être compris à travers tous les générateurs d'interface.

Label Information The interface generator must also have information about how to label the interface components that represent state variables and commands. Providing this information is difficult because different form factors and interface modalities require different kinds of label information. An interface for a mobile web-enabled phone will probably require smaller labels that an interface for a PocketPC with a larger screen. A speech interface may also need phonetic mappings and audio recordings of each label for text-to-speech output. We have chosen to provide this information with a generic structure that we call the label dictionary.

Le générateur d'interface doit aussi avoir des informations sur la façon d'étiqueter les composants d'interface qui représentent des variables d'état et des commandes. Fournissant ces informations est difficile parce que des facteurs de forme(formulaire) différents et des modalités d'interface exigent les sortes différentes d'informations d'étiquette. Une interface pour un portable le téléphone permis de tissu probablement exigera des étiquettes plus petites qu'une interface pour un PocketPC avec un plus grand écran. Une interface de discours peut aussi avoir besoin de configurations phonétiques et les enregistrements audio de chaque étiquette pour la production de texte-to-speech. Nous avons voulu fournir ces informations avec une structure générique que nous appelons le dictionnaire d'étiquette.

Figure 5. A sample group tree for a shelf stereo with both a CD player and radio tuner. The black boxes represents groups and the white boxes with text represent state variables. The mode variable indicates which source is being played through the speakers.

Figure 5. Un arbre de groupe type pour une planche stéréo tant avec un lecteur de CD qu'un tuner de radio. Les boîtes noires représentent des groupes et les boîtes blanches avec le texte représentent des variables d'état. La variable de mode indique quelle source est jouée par les orateurs (speakers).

Each dictionary contains a set of labels, most of which are plain text. The dictionary may also contain phonetic representations using the ARPAbet (the phoneme set used by CMUDICT [3]) and text-to-speech labels that may contain text using SABLE mark-up tags [23] and a URL to an audio recording of the text. The assumption underlying the label dictionary is that every label contained within, whether it is phonetic information or plain text, will have approximately the same meaning. Thus the interface generator can use any label within a label dictionary interchangeably. For example, this allows a graphical interface generator to use a longer, more precise label if there is lots of available screen space, but still have a reasonable label to use if space is tight. Figure 1 shows the label dictionary, represented by the <labels> element, for a CD track state with two textual labels and a text-to-speech label.

Chaque dictionnaire contient un jeu d'étiquettes, dont la plupart sont le texte simple(plat). Le dictionnaire peut aussi contenir des représentations phonétiques utilisant l'ARPABET (le jeu de phonème utilisé par CMUDICT [3]) et les étiquettes de texte-à-discours qui peuvent contenir le texte utilisant des étiquettes de majoration de ZIBELINE [23] et un URL à un enregistrement audio du texte. La supposition étant à la base du dictionnaire d'étiquette est que chaque étiquette contenue dans, si c'est le texte de l'information ou simple(plat) phonétique, aura approximativement la même signification. Ainsi le générateur d'interface peut utiliser n'importe quelle étiquette dans un dictionnaire d'étiquette de façon interchangeable. Par exemple, cela permet à un générateur d'interface graphique d'utiliser une étiquette plus longue, plus précise s'il y a tas de l'espace d'écran disponible, mais avoir toujours une étiquette raisonnable pour utiliser si l'espace est serré. La figure 1 montre le dictionnaire d'étiquette, représenté par l'élément, pour un état de trace de CD avec deux étiquettes textuelles et une étiquette de texte-à-discours.

Group Tree Interfaces are always more intuitive when similar elements are grouped close together and different elements are kept far apart. Without grouping information, the play button for the CD player might be placed next to the stop button for the Tape player, creating an unusable interface. We avoid this by explicitly specifying grouping information using a group tree.

Les interfaces sont toujours plus intuitives quand des éléments semblables sont groupés de près ensemble et des éléments différents sont tenus loin à part. Sans grouper des informations, le bouton de jeu(pièce) pour le lecteur de CD pourrait être placé à côté du bouton d'arrêt pour le Lecteur de cassette, créant une interface inutilisable. Nous l'évitons en spécifiant explicitement le groupement de l'utilisation de l'information d'un arbre de groupe.

We specify the group tree as an n-ary tree that has a state variable or command at every leaf node (see Figure 5). State variables and commands may be present at any level in the tree. Each branching node is a “group,” and each group may contain any number of state variables, commands, and other groups. We encourage designers to make the group tree as deep as possible, in order to help spaceconstrained interface generators. These generators can use the extra detail in the group tree to decide how to split a small number of components across two screens. Interface generators for larger screens can ignore the deeper branches in the group tree and put all of the components onto a single panel.

Nous spécifions l'arbre de groupe comme un arbre aucun qui a une variable d'état ou une commande à chaque noeud de feuille (voir la Figure 5). Des variables d'état et des commandes peuvent assister à n'importe quel niveau dans l'arbre. Chaque noeud s'embranchant est "un groupe" et chaque groupe peut contenir n'importe quel nombre de variables d'état, des commandes et d'autres groupes. Nous encourageons des designers à faire l'arbre de groupe aussi profondément que possible, pour aider l'espace des générateurs d'interface contraints. Ces générateurs peuvent utiliser le détail supplémentaire dans l'arbre de groupe pour décider comment diviser un petit nombre de composants à travers deux écrans. Les générateurs d'interface pour de plus grands écrans peuvent ignorer les branches plus profondes dans l'arbre de groupe et mettre tous les composants sur un écrans simple.

Dependency Information The two-way communication feature of the PUC allows it to know when a particular state variable or command is unavailable. This can make interfaces easier to use, because the components representing those elements can be disabled. The specification contains formulas (see the <active-if> element in Figure 1) that specify when a state or command will be disabled depending on the values of other state variables, currently specified with three types of dependencies: equal-to, greater-than, and less-than. Each state or command may have multiple dependencies associated with it, combined with the logical operations AND and OR. These formulas can be processed by the PUC to determine whether a component should be enabled when the appliance state changes.

La caractéristique(fonction) de communication bilatérale du PUC cela permet de savoir(connaître) quand une variable particulière d'état ou une commande sont indisponibles. Cela peut faire des interfaces plus faciles à utiliser, parce que les composants représentant ces éléments peuvent être mis hors de service. La spécification contient des formules (voir le < actif - si > l'élément dans la Figure(le Chiffre) 1) qui spécifie quand un état ou une commande seront mis hors de service selon les valeurs d'autres variables d'état, indiqués(spécifiés) actuellement avec trois types de dépendances : égal - à, plus grand - qu'et moins - que. Chaque état ou commande peuvent faire associer des dépendances multiples avec cela, combiné avec les opérations logiques ET et OU. Ces formules peuvent être traitées par le PUC pour déterminer si on devrait permettre un composant quand l'appareil expose des changements.

We have discovered that dependency information can also be useful for structuring graphical interfaces and for interpreting ambiguous or abbreviated phrases uttered to a speech interface. For example, dependency information can help the speech interfaces interpret phrases by eliminating all possibilities that are not currently available. The processing of these formulas will be described later in the interface generation section.

Nous avons découvert que les informations de dépendance peuvent aussi être utiles pour structurer des interfaces graphiques et pour interpréter des expressions ambiguës ou abrégées prononcées à une interface de discours. Par exemple, les informations de dépendance peuvent aider les interfaces de discours à interpréter des expressions en éliminant toutes les possibilités qui ne sont pas actuellement disponibles. Le traitement de ces formules sera décrit plus tard dans la section de génération d'interface.

COMMUNICATION PROTOCOL The communication protocol enables appliances and PUCs to exchange information bi-directionally and asynchronously. The protocol is XML-based and defines six messages, two sent by the appliance and four sent by the PUC. The PUC can send messages requesting the specification, the value of every state, a change to a particular state, or the invocation of a command. The appliance can send the specification or the current value of a particular state. When responding to a PUC request for the value of every state, the appliance will send a current value message for each of its states. Full documentation for our communication protocol can be downloaded from our project web site:http://www.cs.cmu.edu/~pebbles/puc/protocol_spec.html

Le protocole de communication permet aux appareils et PUCS d'échanger des informations bi directionnellement et d'une manière asynchrone. Le protocole est XML-BASÉ et définit six messages, deux envoyé par l'appareil et quatre envoyé par le PUC. LE PUC peut envoyer des messages demandant la spécification, la valeur de chaque état, un changement à un état particulier, ou l'invocation d'une commande. L'appareil peut envoyer la spécification ou la valeur actuelle d'un état particulier. En répondant à une demande PUC de la valeur de chaque état, l'appareil enverra un message de valeur actuel pour chacun de ses états. La pleine documentation pour notre protocole de communication peut être téléchargée de notre site Web de projet :http://www.cs.cmu.edu/~pebbles/puc/protocol_spec.html

INTERFACE GENERATION The PUC architecture has been designed to be independent of the type of interface presented to the user. We have developed generators for two different types of interfaces: graphical and speech. This section describes our implementation of these two interface generators, including our algorithms for working with dependency information.

L'architecture PUC a été conçue pour être indépendante du type d'interface a présenté à l'utilisateur. Nous avons développé des générateurs pour deux types différents d'interfaces : graphique et discours. Cette section décrit notre mise en oeuvre de ces deux générateurs d'interface, y compris nos algorithmes pour travailler avec des informations de dépendance.

Graphical Interface Generator We have implemented a graphical interface generator for the Compaq iPAQ handheld computer using the Personal- Java API. This generator takes an arbitrary description written in our specification language and makes use of the group tree and dependency information to create a high quality interface. The actual UI components that represent each state variable and command are chosen using a decision tree [4]. The components are then placed into panels according to the inferred structure, and laid out using the group tree. The final step of the generation process instantiates the components and places them on the screen.

Nous avons mis en oeuvre un générateur d'interface graphique pour Compaq iPAQ l'ordinateur de poche utilisant l'Annonce personnelle - l'API de la Java. Ce générateur prend une description arbitraire écrite dans notre langue de spécification et se sert de l'arbre de groupe et les informations de dépendance pour créer une interface de haute qualité. Les composants UI réels qui représentent chaque variable d'état et commande sont choisis utilisant un arbre de décision [4]. Les composants sont alors placés dans des écrans selon la structure déduite et disposés utilisant l'arbre de groupe. Le pas final de la génération traite instantiates les composants et les places sur l'écran.

A key focus of the graphical interface generator is the structure portion of the interface layout. When we looked back at our hand-designed interfaces, we noticed that they could be broken down into small groups of components that were placed relative to each other. For example, Figure 4c shows an interface for the CD player of a shelf stereo. This interface can be broken down into five structural groups: the global functions in the vertical sidebar, the tabs for controlling stereo mode, the less-used CD controls (e.g. Random), the disc and track indicators, and the play controls. Each of these groups has a small number of controls and each control is aligned with the others in their small group, creating a combined layout that is complex. Focusing on the structure portion makes the layout problem solvable and allows us to create complex layouts.

Un centre clef du générateur d'interface graphique est la partie de structure de la disposition d'interface. Quand nous avons regardé derrière soi à nos interfaces conçues de main, nous avons remarqué qu'ils pourraient être détruits dans les petits groupes de composants qui ont été placés l'un quant à l'autre. Par exemple, la Figure 4c montre une interface pour le lecteur de CD d'une planche stéréo. Cette interface peut être détruite dans cinq groupes structurels : les fonctions globales dans sidebar vertical, les étiquettes pour contrôler le mode stéréo, le moins - des commandes de CD utilisées (par exemple. Aléatoire), le disque et les indicateurs(clignotants) de trace et les commandes de jeu(pièce). Chacun de ces groupes a un petit nombre de commandes et chaque contrôle est aligné sur les autres dans leur petit groupe, créant une disposition combinée qui est complexe. Se concentrant sur la partie de structure faite le problème de disposition soluble et nous permet de créer des dispositions complexes.

Inferring Panel Structure From Dependencies The use of different panels can be beneficial to a graphical interface. Commonly-used or global controls can be made available in a sidebar where they are easily accessible. Controls that are only available in the current appliance mode might be placed on a panel in the middle of the screen that changes with the mode, hiding functions from the other modes that are not available.

L'utilisation de écrans différents peut être avantageuse à une interface graphique. Des commandes Généralement eues l'habitude ou globales(mondiales) peuvent être rendues disponible dans un sidebar où ils sont facilement accessibles. Les commandes qui sont seulement disponibles dans le mode d'appareil actuel pourraient être placées sur un écrans au milieu de l'écran qui change avec le mode, cachant des fonctions des autres modes qui ne sont pas disponibles.

The graphical interface generator uses dependency information to determine how to divide the screen into panels, and to assign branches of the group tree to each panel. We have found it useful to compare the dependencies of different state variables and commands to determine if they are never available at the same time. If two variables are mutually exclusive, then they might be placed on separate panels. Instead of using dependency information to find mutual exclusion, we could instead have required the specification designers to place markers on all group tree nodes that have mutually exclusive branches. Determining how to place markers requires designers to not only determine what the dependencies are, but then discover all mutually exclusive situations themselves. Instead the designers can enumerate the dependency information and choose a group tree structure that seems intuitive. They can rely on the interface generator to discover relationships within the dependency information and infer panel structure, even if no groups have been specified.

Le générateur d'interface graphique utilise des informations de dépendance pour déterminer comment diviser l'écran en écrans et assigner les branches de l'arbre de groupe à chaque panneau(jury). Nous l'avons trouvé utile de comparer les dépendances de variables différentes d'état et des commandes pour déterminer s'ils ne sont jamais disponibles en même temps. Si deux variables sont mutuellement exclusives, donc ils pourraient être placés sur des écrans séparés. Au lieu d'utiliser des informations de dépendance pour trouver l'exclusion mutuelle, nous pourrions au lieu de cela avoir exigé que les designers de spécification aient placé des marqueurs sur tous les noeuds d'arbre de groupe qui ont des branches mutuellement exclusives. La détermination comment placer des marqueurs exige que des designers non seulement déterminent quelles les dépendances sont, mais découvrent alors tout des situations mutuellement exclusives eux-mêmes. Au lieu de cela les designers peuvent énumérer les informations de dépendance et choisir une structure d'arbre de groupe qui semble intuitive. Ils peuvent compter sur le générateur d'interface pour découvrir des rapports dans les informations de dépendance et déduire la structure de panneau(jury), même si aucun groupe n'a été spécifié.

Figure 6. Interfaces produced by the graphical generator for our Audiophase shelf stereo.Figure 6. Interfaces produites par le générateur graphique pour notre planche Audiophase stéréo.

Unfortunately, the task of determining mutual exclusiveness for an arbitrary set of state variables is NP-hard. We reduce the difficulty of the problem by considering mutual exclusion with respect to a single given variable. Our algorithm starts by obtaining a list of all state variables that other commands and states depend upon. Our experience shows that this is a small number of variables for most specifications. We iterate through this list, starting with the state that is most depended upon. Usually the states that are most depended upon represent higher-level modes and we prefer to create high-level structure earlier in the algorithm.

Malheureusement, la tâche de déterminer l'exclusivité mutuelle pour un jeu arbitraire de variables d'état est NP-hard. Nous réduisons la difficulté du problème en considérant l'exclusion mutuelle en ce qui concerne une variable donnée simple. Nos démarrages d'algorithme en obtenant une liste de toutes les variables d'état dont d'autres commandes et des états dépendent. Notre expérience montre que c'est un petit numéro(nombre) de variables pour la plupart de cahier des charges(de spécifications). Nous réitérons par cette liste, commençant avec l'état qui est plus dépendu. D'habitude les états qui sont plus dépendus représentent des modes de niveau plus haut et nous préférons créer la structure de haut niveau plus tôt dans l'algorithme.

For each state, the algorithm finds the state’s location in the group tree and gets a pointer to its parent group. Dependencies on the state are collected from each of the children and are analyzed to find mutual exclusion. If mutual exclusion is found, rules are applied to determine the panel structure to use. We currently have three rules at this level:

1. If the state has an enumerated type and there are mutually exclusive groups of components that are active for each value of the state, create a tabbed panel component with a panel for each value of the enumeration.

2. If the state has a boolean type and all the other states and commands are active for one value of the state, create two full-screen overlapping panels. Each panel has a button for toggling the boolean type. This rule is primarily used for the power button.

3. Create an overlapping panel for every mutually exclusive group and make sure a component exists at a higher level of the tree for changing this state’s value.

We plan to create additional rules in the future that create pop-up dialogs or keep all components in the same panel.

Pour chaque état, l'algorithme trouve l'emplacement de l'état dans l'arbre de groupe et obtient un indicateur sur son groupe parental. Les dépendances à l'état sont rassemblées de chacun des enfants et sont analysées pour trouver l'exclusion mutuelle. Si l'exclusion mutuelle est trouvée, les règles(autorités) sont appliquées pour déterminer la structure de écrans pour utiliser. Nous avons actuellement trois règles(autorités) à ce niveau :

1. Si l'état a un type énuméré et il y a les groupes mutuellement exclusifs de composants qui sont actifs pour chaque valeur de l'état, créent un composant de écrans tabbed avec un écrans pour chaque valeur de l'énumération.

2. Si l'état a un type booléen et tous les états autres et les commandes sont actives pour une valeur de l'état, créent deux écrans en plein écran se chevauchant. Chaque écrans a un bouton pour basculer le type booléen. Cette règle(autorité) est principalement utilisée pour le bouton de pouvoir(puissance).

3. Créez un écrans se chevauchant pour chaque groupe mutuellement exclusif et assurez-vous qu'un composant existe à un niveau plus haut de l'arbre pour changer la valeur de cet état.

Nous planifions de créer des règles(autorités) complémentaires dans l'avenir qui créent des dialogues contextuels ou tiennent tous les composants dans le même panneau(jury).

Making the Interface Concrete Once the initial structure has been defined for the interface, our generator can begin making the interface concrete. The first step is choosing what kind of component to assign to each state variable and command. The generator uses a decision tree to make these choices [4]. The decision tree takes into account the following questions when choosing a component:

Is this a command or a state variable? What it the type of the state variable? Is the state variable read-only? Was a panel structure rule (see above)

applied because of this state variable?

For example, in our current system a command is always represented by a button component. Read-only states are almost always represented by a label component. Boolean states are represented by checkboxes, unless the dependency algorithm applied panel structure rule #2 because of this state. In this situation, a button that toggles the state’s value is used instead.

Une fois que la structure initiale a été définie pour l'interface, notre générateur peut commencer à faire le béton d'interface. Le premier pas choisit quel genre du composant assigner à chaque variable d'état et commande. Le générateur utilise un arbre de décision pour faire ces choix [4]. L'arbre de décision tient compte des questions suivantes en choisissant un composant :

Est-ce que c'est une commande ou une variable d'état ?

que cela le type de la variable d'état ? Est la variable d'état en lecture seule ? Était une règle(autorité) de structure de

écrans (voir ci-dessus) appliqué à cause de cette variable d'état ?

Par exemple, dans notre système actuel une commande est toujours représentée par un composant de bouton. En lecture seule les états sont presque toujours représentés par un composant d'étiquette. Des états booléens sont représentés par des boîtes à cocher, à moins que l'algorithme de dépendance le écrans appliqué ne structure la règle(l'autorité) #2 à cause de cet état. Dans cette situation, un bouton qui bascule la valeur de l'état est utilisée au lieu de cela.

Once the components have been selected, the interface generator recursively traverses the group tree and inserts each component into a structure that we call the interface tree. The interface tree represents the panel structure of the generated interface and is used for translating abstract layout relationships to a concrete interface. Each leaf node in the tree is a panel and each branching node specifies how the child panels are placed relative to each other. Branching nodes may represent a set of panels separated by horizontal or vertical edges, or a set of overlapping panels. The particular branching nodes used are chosen by the rules described in the dependency inference section above.

Une fois que les composants ont été choisis, le générateur d'interface traverse récursivement l'arbre de groupe et insère chaque composant dans une structure que nous appelons l'arbre d'interface. L'arbre d'interface représente la structure de écrans de l'interface produite et est utilisé pour traduire des rapports de disposition abstraits à une interface concrète. Chaque noeud de feuille dans l'arbre est un écrans et chaque noeud s'embranchant spécifie comment les écrans d'enfant sont placés l'un quant à l'autre. L'embranchement de noeuds peut représenter un jeu de écrans séparés par des bords horizontaux ou verticaux, ou un jeu de écrans se chevauchant. Les noeuds s'embranchant particuliers utilisés sont choisis selon les règles(autorités) décrites dans la section d'inférence de dépendance ci-dessus.

Each panel node in the tree also contains a set of row objects, which describe how components should be placed relative to each other. Most components are placed in the panel using a one-column layout with an adjacent label, but other row layouts are also used. The following rules are used to select different layouts:

If a group is found that contains a label and two components that do not need their own labels (such as buttons), then a row will be created using the label with the two components in the space typically reserved for a single component. An example is the seek buttons in Figure 6a.

Some of the components chosen by the decision tree may prefer to occupy the full width of their panel. In this case, a row is created that allows the component to fill the full width of its container, including the space typically reserved for labels.

If a group is found that contains two components that both need their own labels (such as text fields or selection lists), then a row will be created that has two columns. Each component and its label will be placed in a separate column.

Chaque noeud de écrans dans l'arbre contient aussi un jeu d'objets de rangée(dispute), qui décrivent comment les composants devraient être placés l'un quant à l'autre. La plupart des composants sont placés dans le écrans utilisant une disposition à un colonne avec une étiquette adjacente, mais d'autres dispositions de rangée(dispute) sont aussi utilisées. Les règles(autorités) suivantes sont utilisées pour choisir des dispositions différentes :

si un groupe est trouvé que contient une étiquette et deux composants qui n'ont pas besoin de leurs étiquettes propres (comme des boutons), ensuite une rangée(dispute) sera créée utilisant l'étiquette avec les deux composants dans l'espace typiquement réservé pour un composant simple. Un exemple est les boutons se cherchant dans la Figure 6a.

certains des composants choisis par l'arbre de décision peut préférer occuper la pleine largeur de leur panneau(jury). Dans ce cas, une rangée(dispute) est créée qui permet au composant de remplir la pleine largeur de son conteneur, y compris l'espace typiquement réservé pour des étiquettes.

si un groupe est trouvé que contient deux composants que les deux ont besoin de leurs étiquettes propres (comme des champs(domaines) de texte ou des listes de sélection), ensuite une rangée(dispute) sera créée qui a deux colonnes. Chaque composant et son étiquette seront placés dans une colonne séparée.

After the group tree has been traversed, the interface is made concrete by recursively traversing the interface tree twice. The first traversal allocates space for each component and determines the size and location of every panel. The second traversal places and sizes the components within their rows, and then assigns labels by picking the largest label that will fit in the space allocated. When this traversal is complete, an interface is presented to the user. Example interfaces generated for controlling our shelf stereo are shown in Figure 1 and Figure 6.

Après que l'arbre de groupe a été traversé, l'interface est faite le béton en traversant récursivement l'arbre d'interface deux fois. La première traversée alloue(répart) l'espace pour chaque composant et détermine la taille et l'emplacement de chaque panneau(jury). Les deuxièmes places de traversée et les tailles les composants dans leurs rangées(disputes) et assignent ensuite des étiquettes en choisissant la plus grande étiquette qui ira dans l'espace alloué(réparti). Quand cette traversée est complète, une interface est présentée à l'utilisateur. On montre des interfaces d'exemple produites pour contrôler notre planche stéréo dans la Figure 1 et Figure 6.

Speech Interface Generator The speech interface generator creates an interface from a PUC specification, using USI interaction techniques [22].

Le générateur d'interface de discours crée une interface d'une spécification PUC, utilisant USI des techniques d'interaction [22].

Generation Procedure The speech interface generator differs from the graphical interface in that it connects to multiple PUC adaptors (if multiple adaptors can be found on the network), requests the device specifications, and then uses those specifications collectively to configure itself so it can control all devices with the same speech grammar. This includes building a grammar for the parser and a language model and pronunciation dictionary for the recognizer.

Le générateur d'interface de discours diffère de l'interface graphique dans laquelle il unit(connecte) aux adaptateurs PUC multiples (si des adaptateurs multiples peuvent être trouvés sur le réseau), demandent le cahier des charges(les spécifications) de dispositif et utilisent ensuite ce cahier des charges(spécifications) collectivement pour se configurer ainsi il peut contrôler tous les dispositifs avec la même grammaire de discours. Cela inclut la construction(le bâtiment) d'une grammaire pour l'analyseur syntaxique et un modèle de langue et un dictionnaire de prononciation pour le reconnaisseur.

The generated grammar is compatible with the Phoenix parser [28], which is used by the USI library to parse user utterances. A grammar is generated for each device that contains phrases for query and control. Query phrases include determining what groups are available, what states and commands are available, what values the states can take, as well as what values they currently hold. Control phrases allow the user to navigate between groups, issue commands and change states. All of the device-specific grammars, together with a device-independent USI grammar, are compiled into a single combined grammar representing everything that the speech interface will understand. This has been implemented in a test system that is capable of controlling a shelf stereo, a Sony camcorder via the AV/C protocol and multiple X10 devices.

La grammaire produite est compatible avec l'analyseur syntaxique Phoenix [28], qui est utilisé par la bibliothèque USI pour faire l'analyse syntaxique d'énonciations d'utilisateur. Une grammaire est produite pour chaque dispositif qui contient des expressions pour la question et le contrôle. Les expressions de question incluent la détermination quels groupes sont disponibles, quels états et commandes sont disponibles, quelles valeurs les états peuvent prendre, aussi bien que quelles valeurs ils tiennent actuellement . Les expressions de contrôle permettent à l'utilisateur de naviguer entre des groupes, des commandes de question(publication) et des états de changement. Toutes les grammaires spécifiques de dispositif, ensemble avec une grammaire USI indépendante de dispositif, sont compilées dans une grammaire combinée simple représentant tout que l'interface de discours comprendra. Cela a été mis en oeuvre dans un système d'essai qui est capable de contrôler une planche stéréo, un caméscope Sony via le protocole AV/C et les dispositifs X10 multiples.

Lessons Learned We encountered several challenges generating an interface using USI techniques from the PUC specification language. The language makes a distinction between state variables and commands. But what is best described as a variable in a visual interface (e.g. speaker volume) might be better thought of as a command in a spoken interface (e.g. “louder”). Secondly, in a visual environment, groupings of functionalities or widgets need not have a name; such grouping can be implied by adjacency or by a visual cue such as a frame. In speech interfaces, grouping must be assigned a word or phrase if they are to be directly accessed. Occasionally, appropriate names are hard to find, and may not even exist. In the other direction, choosing from a long list of names is easy with speech, yet poses a special challenge to visual interfaces. These challenges are consistent with the observations of others [18] and is a topic of currentresearch.

Nous avons rencontré plusieurs défis produisant une interface utilisant USI des techniques de la langue de spécification PUC. La langue fait une distinction entre des variables d'état et des commandes. Mais qu'est le meilleur décrit comme une variable dans une interface visuelle (par exemple l'orateur(le speaker) le volume) pourrait être la meilleure pensée de comme une commande dans une interface parlée (par exemple "plus fort"). Deuxièmement, dans un environnement visuel, les groupements de fonctionnalités ou des gadgets(machins) n'ont pas besoin d'avoir un nom; un tel groupement peut être impliqué par la contiguïté ou par une réplique visuelle comme un cadre. Dans des interfaces de discours, le groupement doit être assigné un mot ou une expression s'ils doivent être directement eus accès. De temps en temps, des noms appropriés sont durs de trouver et ne peuvent pas même exister. Dans l'autre direction, choisissant d'une longue liste de noms est facile avec le discours, cependant pose un défi spécial aux interfaces visuelles. Ces défis sont compatibles avec les observations d'entre d'autres [18] et est un sujet de recherche actuelle.

We have addressed these interface generation challenges in our USI-PUC implementation. Consistent with the graphical interface’s translation from the group tree to the graphical interface tree, the speech interface translates the group tree into a USI-interaction tree. This tree, like the graphical interface generator’s tree, is a more concrete representation of what interactions can take place between the system and the user. The tree consists of nodes with phrasal representations. Each node is either actionable or incomplete. An actionable node contains a phrase that, when uttered, will cause some device state change. An incomplete node contains a phrase that requires more information before it can be acted upon; uttering the phrase causes the system to prompt the user with completion options, derived from that node’s children. Grouping information is represented in the structure of the tree, and influences exploration, disambiguation, and scope.

Nous avons adressé ces défis de génération d'interface dans notre mise en oeuvre USI-PUC. Compatible avec la traduction de l'interface graphique de l'arbre de groupe à l'arbre d'interface graphique, l'interface de discours traduit l'arbre de groupe dans un arbre d'USI-INTERACTION. Cet arbre, comme l'arbre du générateur d'interface graphique, est une représentation plus concrète de ce que les interactions peuvent avoir lieu entre le système et l'utilisateur. L'arbre consiste en noeuds avec des représentations syntagmatiques. Chaque noeud est passible de poursuites judiciaires ou incomplet. Un noeud passible de poursuites judiciaires contient une expression qui, quand prononcé, causera un certain changement d'état de dispositif. Un noeud incomplet contient une expression qui exige plus d'informations avant qu'il ne puisse être agi; la prononciation de l'expression cause que le système incite l'utilisateur avec des options d'achèvement, tirées des enfants de ce noeud. Le groupement d'informations est représenté dans la structure de l'arbre et influence l'exploration, la désambiguïsation et la portée.

FUTURE WORK There are numerous directions for us to pursue with our work on the personal universal controller in addition to those mentioned previously. There are several outstanding issues with the specification language, and a number of directions in which to take the interface generators.

Il y a de nombreuses directions pour nous pour poursuivre avec notre travail sur le contrôleur universel personnel en plus de ceux mentionnés précédemment. Il y a plusieurs questions(publications) remarquables(en suspens) avec la langue de spécification et un certain nombre de directions dans quel prendre les générateurs d'interface.

One problem with the current specification language is that it does not include a list type. Lists are important for many appliances, such as the messages for an answering machine and the songs on an MP3 player. There are many issues to address before the PUC framework can handle lists adequately. One of the most difficult problem is inferring what functions can be performed on the list. Unlike for an integer or boolean state variable, where inferring the possible manipulations is simple, there are many different ways to operate on lists, and it is rare to find a list that uses every one. Some lists, such as a play list for an MP3 player, support the addition and deletion of elements at arbitrary locations. Others do not, such as the answering machine message list shown in Figure 4b, in which new messages are always appended to the end but can be removed from any location. It does not seem reasonable to enumerate all of the possible list operations that might be supported, and then specify which of those operations are supported for each instance of a list on the appliance. We are currently working on a more general solution for this problem.

Un problème avec la langue de spécification actuelle est qu'il n'inclut pas de type de liste. Les listes sont importantes pour beaucoup d'appareils, comme les messages pour un répondeur téléphonique et les chansons sur un acteur(joueur) MP3. Il y a beaucoup de questions(publications) pour adresser avant que la structure PUC ne puisse manipuler des listes en juste proportion. Un du problème le plus difficile déduit ce que les fonctions peuvent être exécutées dans la liste. À la différence de pour un entier ou une variable booléenne d'état, où la déduction des manipulations possibles est simple, il y a beaucoup de façons différentes de fonctionner(d'opérer) dans des listes et il est rare de trouver une liste qui utilise chaque. Quelques listes, comme une liste de jeu(pièce) pour un acteur(joueur) MP3, soutiennent le complément et l'effacement d'éléments aux emplacements arbitraires. D'autres ne font pas, comme la liste de message de répondeur téléphonique montrée dans la Figure(le Chiffre) 4b, dans laquelle de nouveaux messages sont toujours ajoutés à la fin, mais peuvent être enlevés de n'importe quel emplacement. Il ne semble pas raisonnable d'énumérer toutes les opérations de liste possibles qui pourraient être soutenues et spécifier ensuite lequel de ces opérations sont soutenu pour chaque cas d'une liste sur l'appareil. Nous travaillons actuellement sur une solution plus générale pour ce problème.

Finally, one goal of the personal universal controller is to provide consistent interfaces across appliances with similar functions. This requires an interface generator that is adaptive, based upon interfaces that it has created in the past. It must also support some kind of pattern recognition for determining from a specification that two appliances have similar functions. These are both difficult problems that we will be addressing in our future research.

Finalement, un but du contrôleur universel personnel est de fournir des interfaces cohérentes à travers des appareils avec des fonctions semblables. Cela exige un générateur d'interface qui est adaptatif, basé sur des interfaces qu'il a créées dans le passé. Il doit aussi soutenir quelque reconnaissance de formes pour décider d'une spécification que deux appareils ont des fonctions semblables. Ceux-ci sont les deux problèmes difficiles que nous adresserons dans notre recherche future.

CONCLUSION We have described the design and architecture of the personal universal controller, a system for automatically generating high-quality multi-modal remote control interfaces for complex appliances. The system includes a twoway communication protocol, adaptors for translating from proprietary appliance protocols to the PUC protocol, a specification language for describing the functions of an appliance, and generators that automatically build interfaces from specifications. A novel element of our system is the use of dependency information for helping generators create high quality interfaces. We have presented generators that use our specification language to create both graphical and speech interfaces.

Nous avons décrit la conception et l'architecture du contrôleur universel personnel, un système pour automatiquement produire des interfaces de télécommande multi-modales de haute qualité pour des appareils complexes. Le système inclut un protocole de communication bilatéral, des adaptateurs pour traduire de protocoles d'appareil de marque déposée au protocole PUC, une langue de spécification pour décrire les fonctions d'un appareil et des générateurs qui construisent automatiquement des interfaces au cahier des charges(aux spécifications). Un nouvel élément de notre système est l'utilisation d'informations de dépendance pour aider des générateurs à créer des interfaces de haute qualité. Nous avons présenté les générateurs qui utilisent notre langue de spécification pour créer tant graphique que des interfaces de discours.

ACKNOWLEDGMENTS This work was conducted as a part of the Pebbles [12] project. The speech interface was also conducted as part of the Universal Speech Interfaces project [19]. Marc Khadpe did a portion of the work on the prototype phone interface as a part of a summer independent study project. This work was funded in part by grants from NSF, Microsoft and the Pittsburgh Digital Greenhouse, and equipment grants from Mitsubishi Electric Research Laboratories, VividLogic, Symbol Technologies, Hewlett-Packard, and Lucent. The National Science Foundation funded this work through a Graduate Research Fellowship for the first author, and under Grant No. IIS-0117658. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect those of the National Science Foundation.

(Remerciements)Ce travail a été conduit comme une partie du

projet Pebbles[12]. L'interface de discours a été aussi conduite comme la partie du projet d'Interfaces de Discours Universel [19]. Marc Khadpe une partie du travail sur le prototype téléphone à l'interface comme une partie d'un projet d'étude indépendant d'été. Ce travail a été financé(consolidé) en partie par des subventions(octrois) de NSF, Microsoft et Pittsburgh la Serre Numérique et des subventions(octrois) d'équipement de Laboratoires de recherches Électriques Mitsubishi, VividLogic, des Technologies de Symbole, Hewlett-Packard - et Lucide. La Base(Fondation) de Science nationale a financé(consolidé) ce travail par une Camaraderie de Recherche de Diplômé pour le premier auteur et sous la Subvention(l'Octroi) No IIS-0117658. N'importe quels avis, découvertes et des conclusions ou des recommandations exprimées dans ce matériel(matière) sont ceux des auteurs et ne reflètent pas nécessairement ceux de la Base(Fondation) de Science nationale.

REFERENCES1. Abrams, M., Phanouriou, C., Batongbacal, A.L., Williams,S.M., and Shuster, J.E. “UIML: An Appliance-IndependentXML User Interface Language,” in The Eighth InternationalWorld Wide Web Conference. 1999. Toronto, Canada

2. Brouwer-Janse, M.D., Bennett, R.W., Endo, T., van Nes, F.L.,Strubbe, H.J., and Gentner, D.R. “Interfaces for consumerproducts: "how to camouflage the computer?"” in CHI'1992:Human factors in computing systems. 1992. pp. 287-290.

3. CMU, “Carnegie Mellon Pronuncing Dictionary,” 1998.http://www.speech.cs.cmu.edu/cgi-bin/cmudict.

4. de Baar, D.J.M.J., Foley, J.D., Mullet, K.E. “Coupling ApplicationDesign and User Interface Design,” in Conference onHuman Factors and Computing Systems. 1992. Monterey,California: ACM Press. pp. 259-266.

5. Eustice, K.F., Lehman, T.J., Morales, A., Munson, M.C., Edlund,S., and Guillen, M., “A Universal InformationAppliance.” IBM Systems Journal, 1999. 38(4): pp. 575-601.

6. Haartsen, J., Naghshineh, M., Inouye, J., Joeressen, O.J., andAllen, W., “Bluetooth: Vision, Goals, and Architecture.” ACMMobile Computing and Communications Review, 1998. 2(4):pp. 38-45. Oct. www.bluetooth.com.

7. HAVi, “Home Audio/Video Interoperability,” 2002.http://www.havi.org

8. Hodes, T.D., Katz, R.H., Servan-Schreiber, E., and Rowe, L.“Composable ad-hoc mobile services for universal interaction,”in Proceedings of ACM Mobicom'97. BudapestHungary: pp. 1-12.

9. homeautonz, “Home Automation Webring,” 2002.http://c.webring.com/webring?ring=homeauto;list

10. inVoca, “inVoca Universal Remote,” http://www.invoca.com

11. Kim, W.C. and Foley, J.D. “Providing High-level Control andExpert Assistance in the User Interface Presentation Design,”in Proceedings INTERCHI'93: Human Factors in ComputingSystems. 1993. Amsterdam, The Netherlands: pp. 430-437.

12. Myers, B.A., “Using Hand-Held Devices and PCs Together.”Communications of the ACM, 2001. 44(11): pp. 34-41.

13. Nichols, J., Myers, B.A., Higgins, M., Hughes, J., Harris,T.K., Rosenfeld, R., Shriver, S. “Requirements for AutomaticallyGenerating Multi-Modal Interfaces for ComplexAppliances,” in ICMI. 2002. Pittsburgh, PA:

14. Nichols, J.W. “Using Handhelds as Controls for EverydayAppliances: A Paper Prototype Study,” in ACM CHI'2001Student Posters. 2001. Seattle, WA: pp. 443-444.

15. Olsen Jr., D.R. “A Programming Language Basis for User InterfaceManagement,” in Proceedings SIGCHI'89: HumanFactors in Computing Systems. 1989. pp. 171-176.

16. Olsen Jr., D.R., Jefferies, S., Nielsen, T., Moyes, W., andFredrickson, P. “Cross-modal Interaction using Xweb,” inProceedings UIST'00: ACM SIGGRAPH Symposium on UserInterface Software and Technology. 2000. pp. 191-200.

17. Philips, Pronto Intelligent Remote Control. Philips ConsumerElectronics, 2001. http://www.pronto.philips.com/ .

18. Ponnekanti, S.R., Lee, B., Fox, A., Hanrahan, P., andT.Winograd. “ICrafter: A service framework for ubiquitouscomputing environments,” in UBICOMP 2001. pp. 56-75.

19. Rosenfeld, R., “Universal Speech Interfaces Web Site,” 2002.http://www.cs.cmu.edu/~usi/ .

20. Rosenfeld, R., Olsen, D., Rudnicky, A., “Universal SpeechInterfaces.” interactions: New Visions of Human-ComputerInteraction, 2001. VIII(6): pp. 34-44.

21. Shriver, S., Black, A.W., Rosenfeld, R. “Audio Signals inSpeech Interfaces,” in ICSLP. 2000.

22. Shriver, S., Toth, A., Zhu, X., Rudnikcy, A., Rosenfeld, R. “AUnified Design for Human-Machine Voice Interaction,” inExtended Abstracts of CHI 2001. 2001. pp. 247-248.

23. Sproat, R., Hunt, A., Ostendorf, P., Taylor, P., Black, A.,Lenzo, K., Edgington, M. “SABLE: A Standard for TTSMarkup,” in International Conference on Spoken LanguageProcessing. 1998. Sydney, Australia:

24. Sun, Jini Connection Technology. Sun Microsystems,http://www.sun.com/jini/ , 2000.

25. Szekely, P., Luo, P., and Neches, R. “Beyond Interface Builders:Model-Based Interface Tools,” in ProceedingsINTERCHI'93: Human Factors in Computing Systems. 1993.Amsterdam, The Netherlands: pp. 383-390.

26. UPnP, “Universal Plug and Play Forum,” 2002.http://www.upnp.org

27. Vander Zanden, B. and Myers, B.A. “Automatic, Look-and-Feel Independent Dialog Creation for Graphical User Interfaces,”in Proceedings SIGCHI'90. 1990. pp. 27-34.

28. Ward, W. “The CMU Air Travel Information Service: UnderstandingSpontaneous Speech,” in DARPA Speech andNatural Language Workshop. 1990.

29. Wiecha, C., Bennett, W., Boies, S., Gould, J., Greene, S.,“ITS: A Tool for Rapidly Developing Interactive Applications.”ACM Transactions on Information Systems, 1990.8(3): pp. 204-236

30. Zimmermann, G., Vanderheiden, G., Gilman, A. “PrototypeImplementations for a Universal Remote Console Specification,”in CHI'2002. 2002. Minneapolis, MN: pp. 510-511.