IHM et plasticité Anne-Marie Déry pinna@polytech.unice.fr IHM et Différents supports Différents utilisateurs Différents environnements Problématique - aperçu des solutions industrielles et recherche

Plasticité des interfaces Un peu d’histoire … Introduction du terme à Interact’99 Capacité d’une interface à s’adapter à son contexte d’usage dans le respect de son utilisabilité Contexte d’usage Plate-forme Environnement Utilisateur (2001)

Contenu du module Semaine 1 Introduction au module Semaine 2 4H Cours Flex                 Semaine 3        xul Semaine 4   XUL Semaine 5 Flex sur mobile Semaine 6        HTML 5 Semaine 7        IIHM Semaine 8        ENTRETIENS      

Evaluation Mettre en place un site web avec : TP téléchargeables Rapport de synthèse sur les travaux de recherche de votre choix en reagrd sur le domaine de plasticité traité plateforme / environnement / utilisateur conception / exécution modèle sous jacent illustration du besoin sur un exemple avantages et inconvénients Entretien indivuel Objectif : vérifier vos acquis dans le module Déroulement : démonstrations à la demande et réponse aux questions sur le travail de recherche étudié Durée : 30 minutes

Motivations et exemples d’applications visées

Diversité des supports : intéractions Capacités d’interaction nouvelle : tactile bornes - tables – vitrines – murs interactifs Différence de taille des écrans – multi touch ou non – utilisateur experts ou non Environnement bruyant – sombre …

Besoins de plasticité Entre supports tactiles : de la table au mur, du téléphone au PC ? Entre un support non tactile et un support tactile : quand changer l’interaction ? Pourquoi ? Impact sur la présentation ? Impact sur l’enchaînement des taches Besoin identifié par un changement d’environnement (arrivée dans un lieu public) - Besoin provoqué par l’utilisateur (changement de matériel, mains occupées par une tache ?)

Diversité des supports : supports dédiés Supports dédiés à une activité Niveau d’expertise des utilisateurs experts – Niveau de fiabilité En mobilité

Besoins en plasticité Nouveau matériel Changement de voiture Sortie d’une nouvelle montre de plongée Changement de lieu : sur le site de dépannage ou sur le site professionnel : exemple du fontainier, du réparateur d’électroménager Choix de l’utilisateur ou de son environnement professionnel ou du niveau d’expertise

MÊMES USAGES ? MÊMES SERVICES ? Supports mobiles MÊMES USAGES ? MÊMES SERVICES ?

Besoin en plasticité Passage en mobilité Changement de matériel En déplacement Dans les transports en commun Changement de matériel Nouvelles technologies Nouveaux services Quid de l’usage ? Quid du développeur ?

IHM, utilisateurs et usages Complexification de la conception ergonomique et logicielle Continuité de service et adaptation au lieu et à l’usager

Besoins en plasticité Au domicile A l’extérieur – dans la rue Des utilisateurs différents du même service Des supports différents selon les pièces et l’activité A l’extérieur – dans la rue Un environnement interagissant Les sollicitations commerciales, culturelles, de déplacement Des supports privés (mobiles) ou des supports publics (bornes interactives,….) Des contraintes environnementales (bruit, lumière, mains occupées…) Dans l’univers professionnel Supports privés et supports professionnels : taches fixées D’un lieu à un autre Continuité de services

Espace problème Domaine de plasticité Seuil de plasticité Contexte couvert par l’IHM C2 Contexte non couvert

Plastique pour qui et quand ? 2 cas A la conception – faciliter la vie du développeur Réutiliser un maximum pour chaque nouvelle cible Diminuer le coût de développement A l’exécution – faciliter la vie de l’utilisateur final Faire migrer une application d’un support à un autre Faciliter l’usage – conserver les habitudes tout en profitant des spécificités des supports

Comment identifier le problème ? Démarche Identifier le besoin en plasticité Quand (conception et/ou exécution) ? Dans quel(s) environnent(s) ? Pour quel(s) utilisateur(s) ? Identifier les technologies adaptées Avoir une démarche modèle

Les acteurs Organismes de normalisation Les RIA Les fournisseurs de services sur mobiles Les chercheurs

Au début il y avait …..

Approche à la conception basée sur des Traducteurs XSL HTML XML VoiceML WML Au centre une interface XMLisée

Approche à l’exécution : Migration Problème ? Exemple SI la batterie du PC faiblit ALORS passer sur PDA SI condition ALORS action Action  Réaction

Cadre de référence : phase “exécution” Exécution de la réaction Identification du Identification Reconnaissance de situation changement de Des solutions Calcul d’une réaction contexte candidates Détection de Selection d’une solution candidate changement de contexte Capture du Exécution du contexte prologue Execution de Execution de la Exécution de la réaction L’épilogue reaction

Interventions dans le module Des solutions partielles industrielles Pour des types d’application (Site Web) Pour des types de supports (téléphones mobiles) Des projets – en recherche De la réutilisation pour la composition d’applications existantes De la migration dirigée par l’utilisateur Points communs : niveau de description des interfaces plus ou moins abstraits : Langages à balises et IHM

Bref historique concernant les acteurs

Quand les organismes de normalisation s’y mettent … OASIS et W3C

UIML http://www.uiml.org/ dérivé d'XML permettant de décrire des interfaces graphiques. Il y a des outils (renderers) qui convertissent une représentation d'UIML en représentation pour divers GUI (par exemple Java awt). un langage commun de description d'interface utilisateur, ouvert et libre d'utilisation qui soit indépendants des plateformes, qu'il s'agisse des plateformes actuelles ou futures. définir un métalangage canonique qui peut décrire n'importe quelle interface utilisateur, sans être tributaire du type d'unité ou d'interface graphique utilisée. UIML peut décrire les interfaces utilisateur - interface de bureau, interface web, interface mobile, système embarqué, ou encore applications « voix ». UIML 1.0: Décembre 1997 UIML 3.1: Mars 2004 http://www.oasis-open.org UIML 4

W3C comment trouver l’info Quelles infos et comment zoomer

UIML « User Interface Markup Language » Langage multi-interface (graphique, voix, ...) Une norme : UIML (uiml.org) Des implémentations ou « renderers » Harmonia : Awt/Swing, HTML, WML, VXML, ... Rubico : Visual Basic, GUI builder TV Server, AG : C++ for embedded systems Les 4 parties d'un document UIML: <Head> : metadata (author, date, version, ...) <Template> : réutilisation de fragments <Interface> : interface proprement dite <Structure> : arbre des « widgets » <Style> : styles (propriétés) des widgets <Content> : contenu (texte, image, son) <Behavior> : objet / événement / action <Peers> : mappings et liens vers l'extérieur

Traducteurs XSL HTML XML VoiceML WML XML et XSL pour la présentation, UIML, SUNML, Xforms …. XSL HTML XML VoiceML WML

User Interfaces langages XML dans tout ses états

Recommandations W3C (World Wide Web Consortium) http://www.w3.org/2001/di/Activity CONSTAT : multiplication des terminaux, la distribution des contenus devient plus que jamais problématique. les données doivent être filtrées et leur format modifié. Transformation ? la reconnaissance des caractéristiques de l'équipement client par le serveur. Une solution : Le projet CC/PP (pour Composite Capability/Preference Profiles) 1999. Basé sur le format de meta-données RDF (Resource Description Framework), Application de XML pour décrire : les caractéristisques logicielles et matérielles d'un terminal (Web ou WAP, capacité machine, etc.) + les informations relatives au profil de son utilisateur.

Recommandations W3C CC/PP (dont font parti Ericsson, IBM, Nokia, SAP et Sun), Un panel d'appareils assez large (téléphone portable, PC, assistant personnel,...), Avantage de CC/PP : proposer une méthode de description des configurations - réduire la quantité d'informations échangées entre client et serveur (protocoles de transmission sans fil restent limités en bande passante). - les variables d'un profil CC/PP (capacités du terminal, préférences utilisateur, etc.) peuvent être appliquées au sein d'une feuille de style XSLT afin de créer ou d'adapter un document.

XForms http://www.w3.org/2002/Forms/Activity.html XForms un langage à balises pour les formulaires électroniques « modernes » Basés sur XML et renvoie les valeurs saisies dans le formulaire sous forme de document XML Il prend en compte l’authentification, l’utilisabilité et l’accessibilité, le device independence, l’internationalisation, et l’intégration pour plusieurs langages cibles tout en réduisant la mise en œuvre de traducteurs.

Mobile Web Initiative http://www.w3.org/2005/MWI/Activity.html W3C MWI travaille actuellement à la mise en place des meilleures pratiques pour les sites web et les applications sur mobile Il propose également des tests sur l’interoperabilité entre logiciels webs et l’usage du mobile au niveau social. Ils accueillent des groupes de travail sur la thématique générale de l’utilisation des mobiles 1ere consigne : Design for one web (cf http://www.w3.org/Mobile)

WAI http://www.w3.org/WAI/ Le Web est partout : les services publics sont en ligne (impots, sncf, enseignement, etc…) Il doit donc être accessible à TOUS Comment traiter le handicap : visuel, auditif, physique, cognitif, neurologique, etc. De plus les solutions ne doivent pas handicapées les personnes non handicapées  Web Content Accessibility Initiative (WAI) représente des industriels, des chercheurs et des personnes connaissant bien les handicap Donner des consignes et développer des solutions

WAI http://www.w3.org/WAI/ Principaux résultats Outils automatiques de validation de pages webs (les sites publics ont longtemps été non conformes aux tests) Consignes pour évaluer si une page est accessible (exemple la faire lire par une synthèse vocale) Consignes pour concevoir des pages accessibles (exemple classique du tag image à renseigner correctement)

http://www.w3.org/2005/Incubator/model-based-ui/charter/ Model-based User Interfaces Incubator Group Charter Model-based User Interfaces Incubator Group, a pour mission d’évaluer les travaux en recherche autour des modèles pour la conception des IHMs pour essayer de sortir des standard Par exemple : les concepteurs d’UsiXML font partie de ce groupe de réflexion

Quand les RIA sont inspirés

RIAs RIA = le meilleur du web et du "desktop" RIA & conception des interfaces Séparer présentation - logique – données Briques d'IHM réutilisables Nécessité d'installer un plugin dans le navigateur et forte concurrence sur les technologies Multiplication des technologies sur le poste de travail ! ...

Solutions RIAs disponibles AJAX : un ensemble de techno open source éprouvées Asynchronous Javascript And XML Utilisation combinée nouvelle Autres offres ‏ Adobe Flex (2004) : http://www.adobe.com/support/documentation/en/flex/ Microsoft Silverlight (2006) : http://www.silverlight.net Sun JavaFX (2008) : http://www.javafx.com/ Mozilla XUL (XML User Interface Language) http://www.mozilla.org/projects/xul/ ... Macromedia 2004 -> Adobe 2005 silverlight 2006 javascript 1995 Xmlhttprequest 1999 dans IE5 Source : Google Insights

Exigence des supports mobiles Illustration des besoins en entreprise Pour la téléphonie Exemple d’Open Plug

Elips Open-Plug ELIPS Pourquoi ? Créateur d’ELIPS Créée en 2002, Open-Plug est basée à Sophia-Antipolis. Open-Plug est membre de la Fondation LiMo (Linux Mobile Foundation). Fruit de 5 ans de R&D et a fait l’objet de dépôts de brevets. ELIPS environnement ouvert de développement (Framework) de téléphones portables grand public. CELIPS permet aux éditeurs de logiciels, aux fabricants de téléphones et aux opérateurs de téléphonie mobile de créer et de déployer des applications mobiles, des interfaces utilisateurs riches et des solutions logicielles. Pourquoi ? Pour le développement rapide des nouveaux modèles de téléphones portables et facilite l’implémentation de nouvelles solutions logicielles et la création d’interfaces utilisateurs. Pour réutiliser leurs développements d’une plateforme de téléphone à l’autre et développer des variantes de leurs produits plus rapidement.

Quand les chercheurs s’en mêlent…

Equipes et travaux en présence Equipe IIHM Laboratoire IMAG à Grenoble Gaelle Calvary & Joelle Coutaz Equipe RAINBOW Laboratoire I3S à Sophia Antipolis Michel Riveill & Philippe Renevier & Audrey Occello & Anne Marie Dery Laboratoire HIIS à l’université de Pise Fabio Paterno Equipe IHM au Université de Valencienne Anas Hariri & Sophie Lepreux & Christophe Kolski Laboratoire CHI Université catholique de Louvain Jean Vanderdonckt

Exemples d’articles EMMA pour la Plasticité en Mobilité In Actes de la 20ème Conférence francophone sur l’Interaction Homme-Machine (IHM’2008, Metz, France, Septembre 2008). 2008. Vincent Ganneau, Rachel Demumieux, Gaëlle Calvary http://iihm.imag.fr/publication/GDC08a/ Model-Driven Engineering of Multi-Target Plastic User Interfaces In Proc. of 4th International Conference on Autonomic and Autonomous Systems ICAS 2008. pages 7-14. 2008. Benoit Collignon, Jean Vanderdonckt, Gaëlle Calvary D. Greenwood, M. Grottke, H. Lutfiyya, M. Popescu (eds.), IEEE Computer Society Press, Los Alamitos, Gosier, 16-21 March 2008 http://iihm.imag.fr/publication/CVC08a/ Anne-Marie Pinna-Déry, Cédric Joffroy, Philippe Renevier, Michel Riveill, Christophe Vergoni. "ALIAS: A Set of Abstract Languages for User Interface Assembly" in Proceedings of the 9th IASTED International Conference Software Engineering and Applications (SEA'08), IASTED, pages 77--82, ACTA Press, Orlando, Florida, USA, 16-17 nov 2008 http://rainbow.polytech.unice.fr/publis/pinna-dery-joffroy-etal:2008.pdf Anne-Marie Pinna-Déry, Jérémy Fierstone. "Construction d'Interfaces Utilisateurs Par Fusion de Composants d'IHM : un Atout Pour la Mobilité" in Proceedings of the Premières Journées Francophones: Mobilité et Ubiquité, 2004

Visite de travaux de recherche autour de la plasticité

Un cadre de référence : Cameleon Context Aware Modelling for Enabling and Leveraging Effective interaction (IST R&D 2001-2004).

Cadre de référence : phase “conception” “Spécifier 1 fois -> N Interfaces  approche par modèles ARTStudio D. Thevenin Modèles archétypes Domaine Concepts Tâches Contexte User Plate-forme Environment Adaptation Evolution Transition Modèles ontologiques Config 1 Modèle Tâches et Concepts Modèle Tâches et Concepts Config 2 Concepts Concepts Tâches Tâches IHM abstraite IHM abstraite User User Plate-forme Plate-forme IHM concrète IHM concrète Environment Environment Evolution Evolution IHM finale IHM finale Transition Transition Réification, Factorisation, Traduction, Abstraction / Reconception, Crossing, Intervention Humaine

Cadre de référence : phase “conception” Config 1 Tâches & Concepts IHM abstraite IHM concrète IHM finale

Slides : Cédric Ulmer cedric.ulmer@sap.com 3G Mobile Context Sensitive Adaptability - User Friendly Mobile Work Place for Seamless Enterprise Applications CONSENSUS (PROJET Européen terminé en 2004) www.consensus-online.org Try not to present too much about SAP and our technology but more general on mobile application development and what‘s missing Slides : Cédric Ulmer cedric.ulmer@sap.com

Cost-efficient development of usable device independent Applications Objective Ziel der Folie: Einführung der allgemeinen Zielsetzung für das Projekts kosteneffizient – keine Individuallösungen benutzbar – einheitliche Benutzungsschnittstellen geräteunabhängig – Adaption der Anwendungen in Bezug auf Geräte/Kontext Achtung: Bild aus einem älteren Corporate Profile Cost-efficient development of usable device independent Applications

Challenge is ... ... to bring (potentially) all applications to (potentially) all devices different mobile devices with different device capabilities – voice comes on top of that For a single application to be displayed on 50 devices 50 sets of application UI need to be created! Some enterprises are maintaining hundreds of applications – customer developments & customization comes on top of that Example: For all SAP applications being able to be displayed on all devices 50.000 sets of application UIs need to be created!

State of the Art: Adaptation - Transcoding Usability: Declined! Ziel der Folie: Automatische Adaption erzeugt eine zu komplizierte 1:1 Abbildung der ursprünglichen Anwendung Randbemerkung: Die automatische Umsetzung von HTML Seiten nach WML war unserer Meinung nach der Killer für WAP Application-independent adaptation: A multitude of screens 15 numbers have to be entered

State of the Art: Dilemma - Cost vs. Usability Integrated adaptation Recoding semantic adaptation device & application specific Usability Integrated Adaptation semantic information context information Transcoding syntactic adaptation technology specific Ziel der Folie: Die Verfahren der automatischen und manuellen Adaption sind nicht ausreichend. Gewünscht ist eine hohe Benutzbarkeit bei relativ niedrigen Kosten. Der grüne Punkt ist der „Wunsch“ Ziel ist eine die Flexibilität auf einer Kurve zwischen automatischer Adaption – Integrierter Adaption – Manuelle Adaption zu ermöglichen. Auf dieser Linie kann eine hohe Steigerung der Benutzbarkeit mit geringem Kostenaufwand ermöglicht werden. Weitere Verbesserungen werden relativ teurer. Die Integration Adaption wird ermöglicht durch semantische Informationen – Beschreibung der Bedeutung/Wichtigkeit der einzelnen Komponenten (z.B. Ein-Ausgabefelder) und dem Bezug zu Kontextinformationen Kontext Information – Die Bereitstellung (und Verwendung) von Informationen zur Beschreibung des aktuellen Kontext. Zum Kontext gehören zum Beispiel Geräteklasse, Lokation, Umgebung des Benutzers (laut/leise, hell/dunkel, mobil/stationär) Cost

Renderer Independent Markup Language: RIML Tools: Context-sensitive Annotation Editor Semantic Information: Relevance, splitting hints, context conditions,... Augment applications with metadata for adaptation engines to prepare presentation context- and device-specific Device Classes: UI/Technical aspects Context: User Prefs, bandwith,..

Renderer Independent Markup Language: RIML (contn’d) UI-Info to be expressed with application data In order to define RIML, we needed: Language Research Existing MLs Requirements Extensions Usability Research based on Focus on mobile devices How easy / hard is it to use specific UI Components on different devices (not usability on application / process level) Definition of device classes Usability Analysis leads to a limited number of Device Classes which represent devices behaving similar from a users / usability perspective

Adaptation Concept T1 T2 T1 T2 T1 T2 T1 T2 T1/T2 = UI info Templates Colors indicate importance Mandatory Optional Backend Data Application-specific Adaptation SEMANTIC ADAPTATION Device-specific fine-grained Adaptation SYNTACTIC ADAPTATION Information Pruning Filter other filters... Information Splitting Filter T1 T2 T1 T2 T1 T2 T1 T2 WML Application data outbound processing Template Editor Transcoding Rules

Composition de composants Projet ASPECT Composition de composants et de leurs IHMs 2003 23/05/2002 Jeremy Fierstone / Equipe Rainbow / 58

Applications visées Problématique Applications évolutives et adaptables accessibles via un PDA, un portable ou une station variabilité des fonctionnalités selon le contexte d'utilisation (mode dégradé, connecté ou déconnecté, dépendance des ressources…) Applications construites à base de composants (composants métiers, composants d’IHM, composants services…)  S’appuyer sur les infrastructures systèmes (RMI, EJB, …)  Fournir une plate-forme à composants Exemples : Agenda collaboratif Gestion commerciale (facturations, commandes, client, fournisseur)

Spécificités des applications et contraintes IHMs Changement du contexte d'exécution du composant (d’utilisation de fonctionnalités) d'une station à un PDA, un téléphone portable … "Reconfiguration" du composant Retrait / ajout de composants (demande de fonctionnalités, de services) Composition de composants Comment réutiliser une IHM existante sur un support différent ? Comment composer les IHMs des composants métiers ? Déporter le composant prise de commande sur un PDA pour le consultant sur site Ajouter dynamiquement le service de gestion de stock pour informer du délai…

Composition de composants Composants indépendants, composables Mais interactions possibles Composants Composite Jeremy Fierstone / Equipe Rainbow / 61

Composition de composants Fusion de menus correspondants aux composants (1) Jeremy Fierstone / Equipe Rainbow / 62

Composition de composants Fusion de menus correspondants aux composants (2) Jeremy Fierstone / Equipe Rainbow / 63

Proposition : modèle de composants et abstraction Composer les IHMs des composants métiers Réutiliser des composants métiers Spécification d ’ IHM indépendantes du support Un modèle de composant + ISL + SUNML Un modèle de composants qui découple composant métier et composants d ’IHM. Composition de composants métiers par interactions Règles de composition adaptées aux IHMs Fusion de règles vérifiant la cohérence de la composition Atelier de composition : Amusing La communication entre composants IHM et métier est exprimée par des interactions Un langage abstrait de description structurelle des IHMs : SUNML dans la lignée de XForms, RIML,... (inspiré de UIML)

De l’IHM abstraite vers l’IHM concrète Fichier SUNML (Spécification) IHM abstraite (Exécution) <sunml> <interface id="FicheClient"> <structure> <dialog id="MainDialog" sequence="true"> ... <field id="LabelFieldNom" mode="read"> <element type="String">Nom :</element> </field> <field id="FieldNom" mode="read-write"> <element type="String">Toto</element> </field> ... </dialog> </structure> </interface> </sunml> FicheClient HMI Réification MainDialog Dialog ... LabelFieldNom FieldNom Field Field ? ? Projection IHM concrète (Exécution) JFrame1 JFrame ? JPanel1 JPanel durand ... JLabel1 JField1 Composant métier (Exécution) JLabel JTextField

Exemple de Liste de Clients Composition Représentant – Client (1-n) : Liste de clients Fichier SUNML (spécification) <sunml> <interface id="ListeClients"> <structure> <dialog id="MainDialog" sequence="true"> <list id="ListeClients" reference="FicheClient" select="Field[FieldNom]"/> </list> </structure> </interface> </sunml> Exemple en Swing

De l’IHM abstraite vers l’IHM concrète Séparation du composant d’IHM du composant métier Expression des communications possibles entre ces composants avec ISL Adaptation des composants suivant le contexte d’exécution Instance Légende interaction FicheClient Controleur IHM abstraite durand JFrame1 Composant métier IHM concrète

SERVFACE SERVICE ANNOTATIONS FOR USER INTERFACE COMPOSITION PROJET EUROPÉEN HTTP://141.76.40.158/SERVFACE/

Vue d’ensemble Annotations de services avec des éléments d’interfaces Composition de services Génération de l’interface du service « composite » à partir des annotations 2 approches: 1ière approche : composition visuelle des services 2ième approche : composition dirigée par les tâches 3/15

Annotations de services [Izquierdo et al., 2009] Annotations de services 4/15

1ière approche: Composition Visuelle [Nestler et al., 2009] [Feldmann et al., 2009] End-User Programming 1ière approche: Composition Visuelle 5/15

1ière approche: Composition Visuelle Auto-génération d’annotations + Annotations par un “Expert” [Nestler et al., 2009] [Feldmann et al., 2009] Service Annotator Services (WSDL) Services Annotés Génération de l’interface “abstraite” MARIA Transformations: M2M M2C Interface Finale Service Composer 6/15

2ième approche: Dirigée par les tâches [Feldmann et al., 2009] [Janeiro, 2009] 2ième approche: Dirigée par les tâches 7/15

2ième approche: Dirigée par les tâches Services Génération d’annotations (IHM + tâches) + A partir des opérations du service + Une opération = une “tâche annotée” + Une “tâche annotée” = une tâche système Génération des tâches intéractives MARIA Génération de l’interface “abstraite” Transformations: M2M M2C Raffinement de l’IHM, (op. UNION) Interface Finale [Feldmann et al., 2009] + Chaque tâche d’interaction = une fenêtre (par défaut) + Intervention du développeur : enlever les doublons [Janeiro, 2009] 8/15

Références [Nestler et al., 2009] Service Composition at the Presentation Layer using Web Service Annotations [Feldmann et al., 2009] Improving Task-driven Software Development Approaches for Creating Service-based Interactive Applications by using Annotated Web Services [Izquierdo et al., 2009] An Annotation tool for enhancing the user interface generation for services [Feldmann et al., 2009] An Integrated Approach for Creating Service-Based Interactive Applications [Janeiro, 2009] Retrieval of User Interface Templates Based on Tasks 9/15

Projet RAINBOW :Besoins en informatique ambiante De nombreux services Des services métiers (apparition et disparition de fonctionnalités) Des services pour gérer les supports physiques et les interacteurs Des services contraints Des services sur l’étagère “boites noires” Des devices avec leurs caratéristiques Des usages variés Des utilisateurs nombreux et variés Chaque utilisateur a ses propres intérets et besoins Titre a changé !! Ici, l’importance c’est : On a une multitude d’éléments (services, dispositifs) utilisable par les utilisateurs. Mais son objectif est de choisir ce qu’il a besoin au moment où il en est à besoin donc en fonction de ce qu’il est en train de faire et de où il est (contexte) Propre à chaque utilisateur, difficulté de savoir ce dont il peut utiliser par rapport au fonctionnalité du système mais aussi des devices qui peuvent personnel ou partagé. Eléments tous représentés par des services aussi bien WS que WSD. Services à tous les niveaux => WS - WSD Multiplicité des services Contraintes sur les services Multiple usage : parce que plusieurs utilisateurs, plusieurs lieux, habitudes, … First of all, what is the current context ? During the last 10 years, we saw the emergence of Internet. Everybody can create applications or services and broadcast it. This development can be made by students during projects or by industrials or by the owner of an Information System. So we don't have the control on all services we use. There is also the technological rise. Yesterday, we use informatics only in the office, or in science. Now everybody use informatics. The devices changed too. They are more little, more mobile. So we can use technology everywhere, with our mobile phone or our PDA. And to finish, we use informatics in different contexts. But in this different contexts, we always want to access to our information. When you are in your office, on in a conference, or at home, we would like to obtain information, more or less specialize according to the place we are.

Etude de cas privilégiée : les bâtiments équipés Un bâtiment universitaire équipé : SEDUITE Des services métiers : News, Timetable, Marks, .. Des devices variés : écrans plasma, PDA, téléphone mobile, ordinateur personel, ...)‏ Pour illustrer la mise en œuvre des préférences, on se place dans le cadre d’une application qui existe qui est l’application SEDUITE, et c’est dans cette application que l’on va illustrer la mise en place des préférences utilisateurs. Public visé différent enseignant, étudiants, administratifs, … Donc a bien des besoins différents.

Problématiques liées au domaine de l’utilisateur Adapter l’interface utilisateur à l’évolution du système Comment modifier l’IHM pour intégrer un nouveau service ? Adapter l’interface aux besoins utilisateurs Adaptation aux supports physiques : travaux sur les IHMs plastiques (IHMs abstraites et rendering, expression du modèle de tâches) Adaptation aux utilisateurs : travaux sur les IHMs (introduction de modèles de tâches, de profis) Adapter le système aux besoins utilisateurs Construire des applications personnalisées à partir des IHM Notre proposition, comment va-t-on le résoudre ? Préciser ces 3 points, en expliquant pourquoi on doit permettre de personnaliser tout le système, et que cette personnalisation va entrainer des adaptation à différents niveaux (SI - UI) Séparer les différentes notions IS – UI – User (application très évolutives) Découpage existe depuis longtemps ¨Pourquoi on s’y intéresse ? Presque le plan

Patterns Architecturaux de construction d’IHMs MVC (1979)‏ (Model-View-Controller)‏ PAC (1987)‏ (Presentation-Abstraction-Control)‏ P C A Controller View Model P C A Arch Model (1992)‏ Points communs Modèle qui ont découpage clair Retirer le discours, mettre en avant sur les schémas la séparation IS – UI Chacun de ces modèles permet de répondre à ces préoccupation Nous on a choisit Arch parce qu’il embarque déjà une part de personnalisation au niveau des adaptateurs. Représente bien le SI et SInt Et que l’utilisateur ressort bien. La notion de niveau entre MVC et PAC qui est proche de l’implémentation alors que l’Arch est beaucoup plus abstraite et permet de faire ressortir l’utilisateur. P C A P C A ... ...

Un modèle inspiré d’Arche pour les services 1 service interactif N services fonctionnels et leurs interactions utilisateurs : comment fusionner le tout ? Services Fonctionnel D’interaction Adaptor Dialogue On arrive au problème que si on souhaite représenter les besoins de tous les utilisateurs dans les différents contextes d’utilisation qu’ils peuvent avoir, ainsi que les différents services que l’on peut avoir. On se retrouve à devoir représenter toutes cela par une arche à chaque fois ce qui fait que l’on a une explosion au niveau du nombre d’arche, afin de représenter tout. Problème de capitalisation !!! L’utilisateur peut utiliser un même service sur différents dispositifs. Sur un dispositif différents services Un même service, un même dispositifs, différents utilisateurs. Problème de redondance des informations => l’utilisateur devra personnaliser à nouveau les services/dispositifs pour chacun des usages Travail à faire aussi bien au niveau développement qu’à l’exécution.

Quid des assemblages Comment fusionner 2 services respectant l’Arche ? Composition d’arches ? Assemblage des services fonctionnels On arrive au problème que si on souhaite représenter les besoins de tous les utilisateurs dans les différents contextes d’utilisation qu’ils peuvent avoir, ainsi que les différents services que l’on peut avoir. On se retrouve à devoir représenter toutes cela par une arche à chaque fois ce qui fait que l’on a une explosion au niveau du nombre d’arche, afin de représenter tout. Problème de capitalisation !!! L’utilisateur peut utiliser un même service sur différents dispositifs. Sur un dispositif différents services Un même service, un même dispositifs, différents utilisateurs. Problème de redondance des informations => l’utilisateur devra personnaliser à nouveau les services/dispositifs pour chacun des usages Travail à faire aussi bien au niveau développement qu’à l’exécution. Quid des dialogues ? Expression et fusion Quid des IHM?

Travaux de références pour le domaine utilisateur Travaux composants (Fractal, SOA, Noah, WCOMP MODEL) Gestion de la dynamique de l’application (apparition et disparition de composants et de services) Expression des assemblages (orchestration, règles isl, langages d’aspects…) Sureté des assemblages Travaux sur l’IDM Modèles et transformation de modèles Fusion de modèles Travaux en IHMs Plasticité des interfaces Expression de modèles pour l’IHM (taches, dialogues…) Pour éviter à l’utilisateur de devoir refaire ses préférences, on se propose d’avoir une arche à n pied côtés SI m pieds côté SInt pour capitaliser les préférences. Rajouter des utilisateurs qui arrivent sur le DC pour bien illustrer que l’on a qu’une arche pour tous les utilisateurs et pas n arche pour les n utilisateurs. Titre à revoir !!! Découpage de haut niveau. Une boîte ne représente pas forcément un service mais un assemblage de services. Assemblage au niveau de l’adaptateur (appel à différents services du FC)

Nos spécificités Etre centré sur le dialogue : relation « fonctionnel et IHM » Déterminer le bon modèle de dialogue et avoir une architecture N-Arches Etre indépendant plateforme : s’appuyer sur un modèle Etre indépendant dispositifs : s’appuyer sur les modèles d’IHM pour la plasticité Faire collaborer des modèles et pouvoir les changer Assurer la dynamique de l’application : assembler à tous les niveaux Déduire au maximum les assemblages Trouver le bon niveau d’IHM abstrait Pour éviter à l’utilisateur de devoir refaire ses préférences, on se propose d’avoir une arche à n pied côtés SI m pieds côté SInt pour capitaliser les préférences. Rajouter des utilisateurs qui arrivent sur le DC pour bien illustrer que l’on a qu’une arche pour tous les utilisateurs et pas n arche pour les n utilisateurs. Titre à revoir !!! Découpage de haut niveau. Une boîte ne représente pas forcément un service mais un assemblage de services. Assemblage au niveau de l’adaptateur (appel à différents services du FC)

Adapter l’interface à l’évolution du système (priorité 1) S’adresse au développeur ? Dialogues Intervention Si conflits Assemblage de services (Orchestrations, fusion d’aspects, Composants hiérarchiques) Assemblage d’IHMs (Utilisation d’IHMs abstraites, puis Projection sur devices) Pour éviter à l’utilisateur de devoir refaire ses préférences, on se propose d’avoir une arche à n pied côtés SI m pieds côté SInt pour capitaliser les préférences. Rajouter des utilisateurs qui arrivent sur le DC pour bien illustrer que l’on a qu’une arche pour tous les utilisateurs et pas n arche pour les n utilisateurs. Titre à revoir !!! Découpage de haut niveau. Une boîte ne représente pas forcément un service mais un assemblage de services. Assemblage au niveau de l’adaptateur (appel à différents services du FC) déduction

Adapter l’interface aux besoins utilisateurs (priorité 2) 2 utilisateurs : le développeur ou l’utilisateur final Choix des services – organisation de l’IHM Choix des devices Dialogue IS Service Marks Service Pour éviter à l’utilisateur de devoir refaire ses préférences, on se propose d’avoir une arche à n pied côtés SI m pieds côté SInt pour capitaliser les préférences. Rajouter des utilisateurs qui arrivent sur le DC pour bien illustrer que l’on a qu’une arche pour tous les utilisateurs et pas n arche pour les n utilisateurs. Titre à revoir !!! Découpage de haut niveau. Une boîte ne représente pas forcément un service mais un assemblage de services. Assemblage au niveau de l’adaptateur (appel à différents services du FC) IS Service WebCal Service Device Device IS Service WebCal Service

Adaptation du système (priorité 3) ? Déduire l’assemblage pour un utilisateur Pour éviter à l’utilisateur de devoir refaire ses préférences, on se propose d’avoir une arche à n pied côtés SI m pieds côté SInt pour capitaliser les préférences. Rajouter des utilisateurs qui arrivent sur le DC pour bien illustrer que l’on a qu’une arche pour tous les utilisateurs et pas n arche pour les n utilisateurs. Titre à revoir !!! Découpage de haut niveau. Une boîte ne représente pas forcément un service mais un assemblage de services. Assemblage au niveau de l’adaptateur (appel à différents services du FC)

Points communs aux adaptations visées MPI Conception Exécution Nouvelles Utilisations M IHM Préférences, Contexte d’utilisation … IHM Adaptation MD Adaptation Noyau Fonctionnel Evolution Noyau Fonctionnel Apparition, disparition de services MP Un langage abstrait orienté composition : SUNML puis LAIM / Flex Un composant d’IHM : représentation fractal Un modèle de dialogue et un modèle de plateforme Une collaboration entre les modèles

User Interfaces composition driven by the Functional Core composition SLIDES : CÉDRIC JOFFROY JOURNÉE DU PÔLE GLC 2010

Objective: compose existing applications Flight Application Hotel Application Compose these two applications to obtain a new one Virtual Travel Agency Application

What is an application? User Interface part User can give input data User can see result User can trigger an event Application Exchange between the UI and the FC Trigger an operation call Interaction part Functional Core part Contain the business logic Manipulate data Compute a result

Example of the hotel application User Interface Part (Flex) Hotel Application Interaction part Functional Core part (WSDL)

How can the developer compose applications? Flight Application Hotel Application She can create business process to describe functional core composition using BPEL (WebService) or Composite Component (SCA, Fractal…) UI UI FC FC VTA Application Composed FC What is happening to associate User Interfaces?

Future of existing UI for the composed FC Flight Application Hotel Application Loose of existing UI Rewriting or generating a new UI from scratch for the Composed FC Possibility of reuse in homogeneous UI UI UI FC FC VTA Application New UI Composed FC

Problems encountered with the composition of applications How to keep the consistency between the functional part and the User Interface part after a composition? How to keep the way that user interacts with a known application? How to reuse existing user interfaces inside the composition?

Existing solutions to compose UI and FC independently FC composition (WS-BPEL[1], Fractal [2]): Describes interactions between components or services Describes usage of data in the services orchestration Uses services or components that describe operation prototypes UI composition (Amusing[3], ComposiXML[4]): Describes structural composition based on operations (union, intersection…) Uses UI description with a simple representation of UI (SunML[3], UsiXML[5])

My solution to deal with applications composition Take advantages of functional composition that describe what is needed to use the new FC created Deduce from the functional composition UI elements to keep Have an homogeneous way to represent UI, FC and composition Create a framework to deal with all composition process with: A composition engine to manage the composition A metamodel to deal with application and FC composition Transformations to obtain information to compose

Framework to deal with applications composition Flight Application Hotel Application FC Composition FC UI UI FC FC VTA Application Composition engine . Deduction of UI elements to keep . Creation of the interaction links Obtain a new application Composed UI FC

AliasComponent: a way to describe application and composition Describe UI and FC in terms of component Components contains two types of ports: Data port Action/Event port Describe an application as a FC component, a set of UI components and a set of bindings Describe an FC composition as a composite component that contains a set of FC components and bindings

Problems resolved by this metamodel Keep only information needed for the composition process UI elements that interact with the FC Links between UI and FC Functional composition with data and control flow Independant of any technologies Can manage multiple kind of FC or UI Keep the consistency between UI and FC by describing directly FC composition and application are in the same metamodels

Description of a FC inside AliasComponent A FC is described in terms of: Inputs Outputs Actions that corresponds to an operation An Action is associated to inputs and outputs to keep the prototype Keep only information about operation prototype

Example of the Hotel representation in AliasComponent Input Id: fc_input1 Name: country Type: string Arity: SINGLE_REQUIRED Hotel FCComponent

Abstraction of a Web Service FCComponent id WSDL Action1 types (internal or in a XSD) Inputs Outputs message portType Action2 Inputs Outputs binding service

Description of a UI inside AliasComponent A user interface is represented by: Inputs where user can put data Outputs to display a result Event to trigger a call of operation We keep only elements connected to the FC that correpsonds to Input, Output and Action

Example of the research hotel UI in AliasComponent Input Id: ui_input1 Name: Country Type: string Arity: SINGLE Hotel UIComponent

Description of an application inside AliasComponent

Example of the Hotel application UIComponent Hotel FCComponent

Description of a FC Composition inside AliasComponent FC composition is represented by a composite component Subcomponents correspond to composed FC Links describe data exchange and operation calls

Example of BPEL control flow abstraction A BPEL workflow is transformed in a FCComposition Here, flow activity is transformed into a dispatch action link to trigger both operation in the same time

Example of BPEL dataflow abstraction Zoom on assign activity Description of the dataflow Correspond to dataLink (between inputs, outputs, input-output) Here inputs are merged

AliasComponent: a full view of the metamodel ba

Other transformations on AliasComponent Interaction with the composition engine To put Prolog facts in entry of the composition engine To retrieve the result of the composition engine Concretization of the resulting UI To validate results by a visualization in some concrete UI like Java Swing or Flex

To summarize This metamodel covers the description of: Application with an FC, mutliple UI and interactions between both Functionnal Composition It is in the center of the composition process It is associated with transformations (abstraction, concretization and engine interaction)

References [1]Diane Jordan, John Evdemon, Alexandre Alves, Assaf Arkin, Sid Askary, Charlton Barreto, Ben Bloch, Francisco Curbera, Mark Ford, Yaron Goland, et al. Web services business process execution language version 2.0. OASIS Standard, 11, 2007 [2]Objectweb Consortium. The Fractal Component Model, 2008 [3]Anne-Marie Pinna-Dery and Jérémy Fierstone. Component model and programming : a first step to manage Human Computer Interaction Adaptation. In Mobile HCI’03, volume LNCS 2795, pages 456–460, Udine, Italy, September 2003. L. Chittaro (Ed.), Springer Verlag. [6]Tsai, W.-T., Huang, Q., Elston, J., and Chen, Y. Service-oriented user interface modeling and composition. In ICEBE ’08, pages 21–28, Washington, DC, USA, 2008. IEEE Computer Society. [7] Gabillon, Y., Calvary, G., and Fiorino, H. Composing interactive systems by planning. In UbiMob’08, pages 37–40, Saint Malo, France, 28 - 30 mai 2008.

Existing solutions to compose applications SOA Planning ServFace Mashup Work SOAUI [6] Compose[7] Task driven [8] UI driven [9] iGoogle, Yahoo Pipes Principle Composition of known UI after the creation of a workflow Answer to a user need by creating all combination of UI Decoration of task trees with UI element + binding between system tasks and operations Give the possibility to have different kind of information on a same window Limitations Compose only known UI No reuse of existing UI Dedicated to technology Annotation of services No Merge of UI Objectif bien formalisé pour dire ce que l’on fait les autres n’est pas suffisant. 114 114

IHM Abstraite: Structure en espaces de dialogue Concrète : Fait le choix des interacteurs Finale: Fait le choix de l’environnement de programmation et d’exécution Contexte d’usage Environnement Utilisateur Plate-forme Composant d’IHM Abstrait