FR3038744A1 - - Google Patents

Abstract

L'invention concerne un système pour générer une interface d'utilisateur (UI) à exécuter sur un dispositif d'utilisateur, le système comprenant : un ou plusieurs dispositifs mémoires (212, 228) mémorisant des caractéristiques associées au dispositif d'utilisateur, à un ou plusieurs utilisateurs du dispositif d'utilisateur et/ou à l'environnement du dispositif d'utilisateur ; et un dispositif de traitement (224, 304) adapté à générer du code UI pour mettre en œuvre l'UI : en générant une première portion du code UI en utilisant une ou plusieurs premières transformations sélectionnées sur la base d'une ou plusieurs des caractéristiques ; en générant une deuxième portion du code UI en utilisant une ou plusieurs deuxièmes transformations sélectionnées sur la base d'une ou plusieurs des caractéristiques ; et en assemblant au moins les première et deuxième portions pour générer le code UI.

Description

SYSTEME ET PROCEDE POUR L'ADAPTATION MAGNETIQUE D'UNE INTERFACE

D'UTILISATEUR

Domaine

La présente description concerne le domaine de l'interaction homme-ordinateur, et en particulier un système et un procédé pour générer une interface d'utilisateur.

Exposé de 11 art antérieur

Les interfaces utilisateurs comprennent des dispositifs matériels et des applications logicielles qui facilitent l'interaction entre les humains, appelés ici utilisateurs, et des machines. Dans le domaine des technologies de l'information, un composant essentiel de 1'interface utilisateur est l'interface utilisateur graphique (GUI), qui est affichée sur un afficheur d'un dispositif d'utilisateur. Le dispositif d'utilisateur pourrait par exemple être un ordinateur de bureau, un ordinateur portable, un smartphone, une tablette informatique, etc... En plus ou à la place de l'interface d'utilisateur graphique, une interface utilisateur peut comprendre une interface de type audio basée sur de la parole, et une interface de type tactile et/ou un autre type d'interface.

Les interfaces utilisateurs sont utilisées dans une grande diversité d'applications logicielles, comme le traitement de texte, les tableurs, les navigateurs web, etc...

Le contenu numérique des interfaces utilisateurs, et la manière avec laquelle elles sont présentées.sur le dispositif d'utilisateur, sont déterminés par les données fournies par un fichier mémorisé sur un dispositif d'utilisateur ou transmis par un serveur distant. Par exemple, des fenêtres d'affichage concernant certaines applications peuvent être représentées par des fichiers codés en Java ou en C++, alors que les pages sont en général codées par des fichiers de type HTML (langage de marquage hypertexte).

De nos jours, les interfaces utilisateurs sont en général conçues pour être compatibles avec une gamme relativement large de dispositifs d'utilisateurs, de sorte qu'un utilisateur peut accéder avec succès à des informations, faire des sélections, naviguer vers de nouvelles fenêtres/pages, et introduire des données. Cependant, on s'est aperçu qu'il peut être souhaitable d'adapter ces interfaces utilisateurs aux catégories de dispositifs sur lesquelles elles sont exécutées. Par exemple, dans le cas d'une page web, on fait souvent la distinction entre dispositif « de bureau » et dispositif « mobile ». Alors qu'un dispositif de bureau est en général considéré comme comprenant un écran relativement grand de 12 pouces ou plus, un clavier et une souris, un dispositif mobile est en général caractérisé en ce qu'il utilise un écran tactile de dimensions relativement faibles, et par l'absence de clavier ou de souris. Par conséquent, il y a souvent deux versions d'une interface utilisateur graphique, l'une étant adaptée aux dispositifs « de bureau », et l'autre étant adaptée aux dispositifs « mobiles ». L'utilisateur installe la version de l'application correspondant à son dispositif, ou dans le cas d'interfaces web, les deux types de pages web sont mémorisés par le serveur distant hébergeant le site, et les unes ou les autres sont transmises au dispositif d'utilisateur, par exemple sur la base d'une détection automatique du type du dispositif d'utilisateur, et/ou sur la base d'une sélection par l'utilisateur.

Au cours de ces dernières années, de nouveaux types de dispositifs d'utilisateurs sont apparus, comprenant des dispositifs correspondant à la technologie appelée en anglais « wearable technology », c'est-à-dire « technologie pouvant être portée sur soi », comme des montres à capacité internet, ou des écouteurs ayant la forme de lunettes. En outre, il est devenu courant que des utilisateurs utilisent leur dispositif d'utilisateur pour accéder à du contenu ou exécuter des applications logicielles dans une grande gamme d'environnements, comme dans les trains, les avions, les automobiles, pendant des réunions, etc. Au vu de ces facteurs, il serait souhaitable d'avoir une plage encore plus grande de versions d'interface, chaque version étant adaptée à une catégorie de dispositifs différents, à des utilisateurs différents et/ou un environnement d'accès différent.

Une solution pour obtenir de telles versions de l'interface utilisateur serait d'étendre la stratégie actuellement adoptée pour créer et mémoriser plus d'une seule version de chaque interface. Toutefois, puisque le nombre de versions à prendre en charge augmente, cette solution conduirait à un coût élevé en stockage de données, et aussi à ion coût élevé pour le développement et la maintenance de chaque version.

Une approche conceptuelle connue sous le nom anglais de « Responsive Design » a été proposée pour adapter une page web à une taille particulière de fenêtre d'affichage. Cette approche implique la programmation du fichier CSS (Cascading Style Sheets) associé à un document HTML de telle sorte que le format d'affichage soit sélectionné sur la base d'une taille de fenêtre détectée dans laquelle la page web doit être affichée. L'adaptation peut changer l'organisation de l'affichage (par exemple, modifier 1'emplacement de certaines parties de l'interface utilisateur), ou rendre certaines parties de l'interface utilisateur invisibles. Ainsi, le même code d'interface utilisateur est transmis à tous les dispositifs accédant à la page web, et l'un des formats d'affichage défini dans le fichier CSS de ce code va être sélectionné en fonction de la taille de la fenêtre. Toutes les données qui pourraient être affichées sur le dispositif sont transférées, même si les directives CSS expriment que, dans la situation courante, certaines des données ne sont pas affichées.

En plus du fait que l'adaptation d'une conception réactive soit limitée à la taille de la fenêtre, un inconvénient de l'approche « Responsive Design » est que, au vu de la taille supérieure des fichiers CSS et HTML, les temps de téléchargement des pages web peuvent être accrus, et que les performances du dispositif sur lequel l'interface utilisateur est affichée sont aussi réduites. En outre, le fait de développer une interface utilisateur sur la base de cette approche conceptuelle est complexe et consommatrice de temps.

Il existe donc un problème technique pour permettre qu'une grande gamme de versions d'interface soit accessible, sans augmenter de façon significative les coûts de stockage de données, de développement et de maintenance. Résumé

Un objet de modes de réalisation de la présente description est de résoudre au moins partiellement un ou plusieurs problèmes de l'art antérieur.

Selon un aspect, on prévoit un système pour générer une interface d’utilisateur, UI, à exécuter sur un dispositif d’utilisateur, le système comprenant : un ou plusieurs dispositifs mémoires mémorisant des caractéristiques associées au dispositif d’utilisateur, à un ou plusieurs utilisateurs du dispositif d’utilisateur et/ou à l’environnement du dispositif d’utilisateur ; et un dispositif de traitement adapté à générer du code UI pour mettre en oeuvre l’UI : en générant une premiefé' portion du code UI en utilisant une ou plusieurs premières transformations sélectionnées sur la base d’une ou plusieurs des caractéristiques ; en générant une deuxième portion du code UI en utilisant une ou plusieurs deuxièmes transformations sélectionnées sur la base d’une ou plusieurs des caracté ristiques ; et en assemblant au moins les première et deuxième portions pour générer le code UI.

Selon un mode de réalisation, lesdits un ou plusieurs dispositifs mémoires mémorisent en outre un contenu dynamique à représenter par l'UI, et le dispositif de traitement est adapté à sélectionner lesdites une ou plusieurs premières et deuxièmes transformations en outre sur la base du contenu dynamique.

Selon un mode de réalisation, les caractéristiques comprennent une ou plusieurs caractéristiques parmi : une indication de la taille de l'afficheur du dispositif d'utilisateur ; une indication d'au moins un langage de programmation d'UI compatible avec le dispositif d'utilisateur ; une indication d'un niveau de lumière ambiante détecté par le dispositif d'utilisateur ; une indication d'un niveau de bruit ambiant détecté par le dispositif d'utilisateur ; une indication d'un niveau d'expertise de l'utilisateur du dispositif d'utilisateur ; une indication de la langue de l'utilisateur du dispositif d'utilisateur ; et une indication du niveau de la vue de l'utilisateur du dispositif d'utilisateur.

Selon un mode de réalisation, le dispositif d'utilisateur comprend un ou plusieurs éléments parmi : un détecteur de lumière ambiante pour détecter le niveau de lumière ambiant ; un microphone pour détecter le niveau de bruit ambiant ; et un dispositif de localisation pour détecter la position du dispositif d'utilisateur.

Selon un mode de réalisation, l'UI est une interface audio.

Selon un mode de réalisation, l'UI est une interface utilisateur graphique, et chacune des première et deuxième portions du code UI génère une fenêtre élémentaire correspondante de l'interface d'utilisateur graphique.

Selon un mode de réalisation, au moins l'une des première et deuxième portions du code UI met en œuvre un élément de saisie d'utilisateur pour permettre à un utilisateur d'introduire une sélection.

Selon un mode de réalisation, le dispositif de traitement est en outre adapté à générer un code d'entête et un code de terminaison du code UI.

Selon un mode de réalisation, pendant l'exécution du code ÜI par le dispositif d'utilisateur, le dispositif de traitement est en outre adapté à recevoir une ou plusieurs caractéristiques modifiées et à adapter le code UI sur la base des caractéristiques modifiées.

Selon un mode de réalisation, l'adaptation du code UI sur la base des caractéristiques modifiées est une adaptation globale du code UI comprenant la régénération de la totalité du code UI.

Selon un mode de réalisation, le dispositif de traitement est adapté à identifier au moins la première portion du code UI à adapter sur la base des caractéristiques modifiées, et l'adaptation du code UI comprend une adaptation locale du code UI dans laquelle la première portion du code UI est adaptée mais pas la deuxième portion.

Selon un mode de réalisation, le dispositif de traitement est adapté à sélectionner les première et deuxième transformations en calculant une distance par rapport à un volume Vi correspondant à chaque transformation sur la base de 1'équation suivante : d(C,V) = Σ" m,. T,· ^ min(|Kic - KiviminUKic - Kivimaxl)l2 [(Klc > Klvimin Λ Klc < Klvimax) ? 0 : UKi----—---Γ wmax ^min 1-1 où Kîq est une valeur courante de chacune des caractéristiques Ki, chaque volume. Vi est défini par des valeurs minimum et maximum de chaque caractéristique Kl à Kn de la façon suivante : Vi=<Kl: [Klyjj^j^, Klyj_j^x] . . . Kn[Knyjj^j_n,Knyjj|^ax]>, et chaque caractéristique Ki est associée à une valeur maximum Kimax et une valeur minimum Kimj_n, et πκί est un coéfficient de pondération.

Selon un mode de réalisation, le système est mis en oeuvre : dans le dispositif d'utilisateur ; et/ou dans un serveur distant agencé pour communiquer avec le dispositif d'utilisateur par l'intermédiaire d'un ou plusieurs réseaux intermédiaires.

Selon un autre aspect, on prévoit un procédé pour générer une interface d'utilisateur, UI, à exécuter par un dispositif d'utilisateur, le procédé comprenant : générer du code UI pour mettre en oeuvre l'UI : en générant une première portion du code UI en utilisant une ou plusieurs premières transformations sélectionnées sur la base d'une ou plusieurs caractéristiques associées au dispositif d'utilisateur, à un ou plusieurs utilisateurs du dispositif d'utilisateur et/ou à l'environnement du dispositif d'utilisateur ; en générant une deuxième portion du code UI en utilisant une ou plusieurs deuxièmes transformations sélectionnées sur la base d'une ou plusieurs des caractéristiques ; et en assemblant au moins les première et deuxième portions pour générer le code UI ; et exécuter le code UI par le dispositif d'utilisateur.

Selon un mode de réalisation, l'assemblage d'au moins les première et deuxième portions pour générer le code UI comprend la génération d'un code d'entête et d'un code de terminaison du code UI.

Selon un mode de réalisation, la première portion de code correspond à une fenêtre élémentaire de 1'interface d'utilisateur, et la génération de la première portion de code comprend la génération d'un entête de code d'un élément de GUI (interface d'utilisateur graphique) et d'une terminaison de code d'un élément de GUI.

Selon un autre aspect, on prévoit un support de stockage lisible par un ordinateur mémorisant sur lui des instructions qui, lorsqu'elles sont exécutées par un dispositif de traitement, mettent en oeuvre le procédé susmentionné.

Brève description des dessins

Les caractéristiques et avantages susmentionnés, et d'autres, apparaîtront clairement à la lecture de la description détaillée suivante de modes de réalisation, donnés à titre d'illustration et non de limitation en référence aux dessins joints dans lesquels : la figure 1 illustre schématiquement un exemple de système pour fournir une interface utilisateur à un dispositif d'utilisateur ; la figure 2 illustre schématiquement un système pour fournir une interface utilisateur à un dispositif d'utilisateur selon un exemple de réalisation de la présente description ; la figure 3 illustre schématiquement un dispositif d'utilisateur selon un exemple de réalisation ; la figure 4A représente une interface utilisateur graphique selon un exemple de réalisation ; la figure 4B représente une fenêtre élémentaire d'introduction de données de l'interface de la figure 4A selon un exemple de réalisation ; la figure 4C représente des fenêtres élémentaires d'identification de l'interface de la figure 4A selon plusieurs exemples de réalisation ; les figures 5A, 5B et 5C sont des organigrammes illustrant des opérations dans un procédé pour générer une interface utilisateur selon un exemple de réalisation ; la figure 6 est un schéma représentant des catégories d'interfaces utilisateurs adaptées à des niveaux de lumière, à l'expertise de l'utilisateur, et à la surface d'affichage, selon un exemple de réalisation ; la figure 7A est un schéma représentant des volumes dans un espace monodimensionnel selon un exemple de réalisation ; la figure 7B est un schéma représentant des volumes dans un espace monodimensionnel selon un autre exemple de réalisation ; la figure 7C est un schéma représentant des volumes dans un espace bidimensionnel selon un exemple de réalisation ; la figure 8 est un organigramme illustrant des opérations dans un procédé pour générer une interface utilisateur selon un exemple de réalisation ; les figures 9A et 9B sont des organigrammes représentant des opérations dans un procédé de sélection d'un volume magnétique sur la base d'un calcul de distance selon un exemple de réalisation ; la figure 10A est un organigramme illustrant un procédé d'adaptation dynamique d'une interface utilisateur selon un exemple de réalisation ; la figure 10B est un organigramme illustrant des étapes d'une opération de la figure 10A de surveillance de contexte selon un exemple de réalisation ; la figure 10C est un organigramme illustrant des étapes d'une opération de la figure 10A pour sélectionner une interface utilisateur préexistante selon un exemple de réalisation ; la figure 10D est un organigramme illustrant des étapes d'une opération de la figure 10A pour gérer un fonctionnement défectueux selon une approche centralisée ; et la figure 10E est un organigramme illustrant des étapes d'une opération de la figure 10A pour gérer un fonctionnement défectueux selon une approche distribuée. Description détaillée

Bien qu'on décrive ici des modes de réalisation faisant référence à une interface utilisateur graphique (GUI), il sera clair pour l'homme de l'art que les techniques décrites ici pourraient être appliquées à d'autres types d'interfaces utilisateurs, comme des interfaces basées entièrement ou partiellement sur du son, comme une interface vocale interactive.

La figure 1 illustre schématiquement un exemple de système 100 pour fournir une interface utilisateur graphique selon une solution similaire à celle décrite dans la section d'art antérieur susmentionnée. Le système comprend un certain nombre de dispositifs d'utilisateurs, comme un ordinateur portable 102, un smartphone 104, et une montre à capacité internet 106. Chaque dispositif d'utilisateur 102, 104, 106 comprend un afficheur pour afficher un GUI.

Par exemple, chaque dispositif d'utilisateur 102, 104, 106 peut exécuter un navigateur web agencé pour communiquer avec un serveur distant (SERVER) 108 par l'intermédiaire d'un ou plusieurs réseaux intermédiaires 110 comprenant par exemple le réseau internet. Un navigateur web est une application logicielle, chargée sur un dispositif d'utilisateur, qui permet d'accéder à des informations par l'intermédiaire de pages web fournies par un serveur distant. Le navigateur web amène des ressources d'information à un utilisateur, permettant à l'utilisateur de visualiser les informations, d'introduire des données, et d'accéder à d'autres informations en navigant sur d'autres pages. Le serveur distant (SERVER) 108 transmet par exemple des pages web aux dispositifs d'utilisateurs 102, 104, 106 afin d'afficher un contenu et de recevoir des sélections faites par l'utilisateur. Les pages web sont par exemple mémorisées en format HTML par un ou plusieurs dispositifs mémoires (MEMORY) 112 au niveau du serveur distant 108. Dans l'exemple de la figure 1, la mémoire 112 mémorise différentes versions de chaque page web, chaque version assurant une interface utilisateur graphique (GUI) différente, GUI 1 à GUI N. Chacune de ces interfaces est par exemple adaptée à un type différent de dispositif d'utilisateur, d'expertise de l'utilisateur et/ou d'environnement. Bien que le temps de réponse soit relativement court pour la transmission d'une version appropriée des versions de la page web vers un dispositif d'utilisateur demandeur, lorsque le nombre N de versions GUI devient relativement élevé, il y aura une augmentation correspondante des ressources mémoires nécessaires pour stocker ces interfaces.

En plus ou à la place, chaque dispositif d'utilisateur 102, 104, 106 est par exemple agencé pour exécuter une ou plusieurs applications logicielles. En association avec chaque application logicielle, le dispositif d'utilisateur 102, 104, 106 mémorise par exemple N interfaces GUIl à GUIN (non illustré en figure 1).

Pour prendre un exemple, il peut être souhaité que les différents GUI prennent en compte les caractéristiques variables suivantes :

Caractéristiques du dispositif : - 4 tailles d'affichage : montre, smartphone, tablette, PC ; - 5 langages de programmation : Objective C sur

Windows, AppKit sur MacOs, UIKit sur iOS, Java sur Android et une version HTML pour les autres cas ;

Caractéristiques de l'utilisateur : - 5 langues écrites : français, anglais, allemand, italien, espagnol ; - 5 niveaux d'expérience de l'utilisateur : novice, débutant, compétent, performant, expert ; - 4 types de qualification d'utilisateur : élec tricien, plombier, ingénieur en électronique, spécialiste réseau ;

Caractéristiques d'environnement : - 3 niveaux de lumière ambiante : faible, moyen et fort.

Dans le cas où les GUI sont stockés au niveau d'un serveur distant et mis à la disposition de n' importe quel type de dispositif, le développement d'un GUI correspondant à chaque combinaison possible de ces caractéristiques nécessiterait la création d'un nombre N d'interfaces égal à (nombre de tailles)*(nombre de langages de programmation)*(nombre de langues écrites)*(nombre de niveaux d'expérience)*(nombre de types de qualification d'utilisateur)*(nombre de niveaux de lumière ambiante), en d'autres termes 4*5*5*5*4*3 = 6000 versions du GUI. En supposant qu'une application ou un site web comprennent 100 GUI, en d'autres termes 100 pages web ou fenêtres, cela conduirait à un total de 600 000 interfaces. Les besoins en stockage pour ces nombreuses interfaces seraient 6000 fois ceux des 100 GUI, et le coût de développement et de maintenance serait excessif.

Dans le cas où la sélection entre les GUI se fait de façon native sur le dispositif lui-même, le nombre de versions de GUI pourrait être déjà limité à un type donné de dispositif et à un langage de programmation donné, ce qui diviserait par 20, dans l'exemple précédent, le nombre de versions devant être disponibles. Cependant, le nombre de versions de GUI serait encore de 300, ce qui est susceptible de dépasser la capacité de stockage disponible d'une montre à capacités internet ou d'un smartphone.

La figure 2 illustre schématiquement un exemple de système 200 pour fournir une interface utilisateur selon un exemple de réalisation de la présente description. Selon l'exemple de réalisation de la figure 2, des interfaces utilisateurs (UI) adaptées sont générées par un serveur 208 et transmises aux dispositifs d'utilisateurs (non illustrés en figure 2).

Comme dans le système 100 de la figure 1, le système 200 peut communiquer avec un ou plusieurs dispositifs d'utilisateurs par l'intermédiaire d'un ou plusieurs réseaux intermédiaires 110 comme l'internet. Le système 200 comprend le serveur 208 et un ou plusieurs dispositifs mémoires (MEMORY) 212 stockant des profils d'utilisateurs ou de dispositifs 1 à N (USER/DEVICE PROFILE1 à USER/DEVICE PROFILEN), comme on va le décrire plus en détail ci-après.

Le serveur 208 comprend par exemple une interface de communication (COMMS INTERFACE) 220 pour communiquer avec les dispositifs d'utilisateurs par l'intermédiaire des réseaux intermédiaires 110. L'interface de communications 220 est couplée à un module de génération d'UI 222. Le module 222 est par exemple mis en œuvre par du logiciel. Par exemple, le module 222 comprend un dispositif de traitement (P) 224 comprenant un ou plusieurs processeurs sous le contrôle d'instructions mémorisées dans une mémoire d'instructions (INSTR MEM) 226. Le module 222 comprend aussi par exemple une ou plusieurs mémoires (MEMORY) 228 mémorisant le contenu dynamique (DYNAMIC CONTENT) d'un UI, et des transformations (TRANSFORMATIONS) utilisées pendant la génération de l'UI, comme on va le décrire plus en détail dans la suite.

En fonctionnement, le module de génération d'UI 222 génère par exemple des UI, pratiquement en temps réel, en réponse à des requêtes provenant de dispositifs d'utilisateurs. Par exemple, pour chaque dispositif d'utilisateur, et/ou pour chaque utilisateur, la mémoire 212 mémorise par exemple un profil indiquant des caractéristiques concernant le dispositif d'utilisateur, comme le type de dispositif, la taille de l'écran d'affichage, et d'autres capacités du dispositif. La mémoire 112 mémorise aussi par exemple des caractéristiques concernant l'utilisateur, comme sa langue préférée, son niveau d'expertise, et une indication d'exigences spécifiques de l'utilisateur, comme une taille de texte plus grande pour des utilisateurs ayant une mauvaise vue, etc. Par exemple, pour un dispositif d'utilisateur donné, il pourrait y avoir une pluralité de profils d'utilisateurs, chacun correspondant à chaque utilisateur qui peut se servir du dispositif. En plus ou à la place, pour chaque utilisateur, il pourrait y avoir une pluralité de profils de dispositifs, chacun correspondant à chaque dispositif d'utilisateur que l'utilisateur peut utiliser pour accéder à des pages web.

Le module de génération d'UI 222 génère par exemple des UI sur la base du profil de l'utilisateur et/ou du dispositif demandant un accès à une page web/UI, et sur la base d'une ou plusieurs caractéristiques d'environnement, qui sont par exemple reçues du dispositif d'utilisateur. Optionnellement, le module de génération d'UI 222 adapte aussi l'UI sur la base d'ion contenu dynamique récupéré par le serveur 208 et qui doit être affiché à l'utilisateur. L'adaptation de l'UI peut être décrite comme étant « magnétique » dans le sens où l'UI générée est par exemple celle qui correspond le plus à un contexte courant, en d'autres termes à des caractéristiques courantes de dispositif, d'utilisateur et/ou d'environnement.

La figure 3 illustre schématiquement un dispositif d'utilisateur 300 selon un exemple de réalisation. Comme cela est illustré, le dispositif d'utilisateur 300 comprend par exemple une interface de communication (COMMS INTERFACE) 302 permettant des communications avec le serveur distant 208. En outre, le dispositif 300 comprend par exemple un dispositif de traitement 304 comprenant un ou plusieurs processeurs sous le contrôle d'instructions mémorisées dans une mémoire d'instructions (INSTR MEM) 306, les processeurs 304 réalisant les fonctions du dispositif mobile. Parmi les applications mémorisées par la mémoire 306, un navigateur web permet par exemple de visualiser des pages web sur un afficheur (DISPLAY) 307 du dispositif d'utilisateur. En plus ou à place, d'autres types d'applications mémorisées par la mémoire 306 peuvent permettre que d'autres types d'UI soient affichés à un utilisateur.

Le dispositif d'utilisateur 300 comprend par exemple un ou plusieurs détecteurs, comme un détecteur de lumière ambiante (AMBIENT LIGHT DETECTOR) 308, un microphone (MICROPHONE) 310, et un dispositif de localisation (GPS) 312. Par exemple, le détecteur dé lumière ambiante 308 indique le niveau de luminosité à utiliser pour l'UI. Les données provenant du microphone indiquent par exemple si l'utilisateur est dans un environnement calme comme un bureau, ou dans un environnement bruyant comme dans des transports publics. Le GPS 312 peut par exemple indiquer la position du dispositif d'utilisateur et/ou la vitesse avec laquelle l'utilisateur se déplace, ce qui pourrait influencer la façon dont l'UI est généré pour ce dispositif d'utilisateur.

Le dispositif d'utilisateur 300 peut recevoir des interfaces d'utilisateur, comme des pages web, générées par le serveur distant 208. Dans un tel cas, pour aider à cette génération, des données capturées par un ou plusieurs des détecteurs 308, 310, 312 sont par exemple transmises au serveur distant 208 et utilisées pour définir le profil du dispositif 300 mémorisé dans la mémoire 212.

En plus ou à la place, le dispositif d'utilisateur 300, et en particulier le dispositif de traitement 304 sous le contrôle de la mémoire d'instructions 306, peut lui-même générer des interfaces utilisateurs adaptées. Pour cela, le dispositif d'utilisateur 300 comprend par exemple un ou plusieurs dispositifs mémoires (MEMORY) 314, qui pourraient être la même mémoire ou une mémoire différente de la mémoire d'instructions 306, et qui par exemple mémorisent un profil d'utilisateur et/ou de dispositif (USER/DEVICE PROFILE) 316 et des transformations (TRANSFORMATIONS) utilisées pendant la génération de l'UI, comme on va le décrire plus en détail dans la suite. Le profil de l'utilisateur et/ou du dispositif peut inclure une ou plusieurs lectures provenant des détecteurs 308, 310 et 312. En plus ou à la place, le profil de l'utilisateur et/ou du dispositif peut inclure d'autres caractéristiques pertinentes concernant le dispositif d'utilisateur 300 et/ou son environnement, comme une indication des dimensions de l'afficheur 307, une indication de l'espace de stockage mémoire disponible du dispositif pour mettre en tampon des pages web, une indication de la puissance de traitement desdits un ou plusieurs processeurs 304, une indication du niveau de lumière ambiante, etc. Dans certains modes de réalisation, ces caractéristiques peuvent en plus être transmises périodiquement au serveur distant 208 pour former le profil de dispositif associé au dispositif d'utilisateur 300.

La figure 4A illustre un exemple d'interface utilisateur graphique 400, qui est par exemple généré par le module de génération d'UI 222, ou par le dispositif de traitement 304 du dispositif d'utilisateur 300. Le GUI 400 a par exemple la forme d'une page web au format de fichier HTML, ou d'un autre langage de programmation approprié. Le GUI 400 est représenté à l'intérieur d'une frontière 401 représentant la limite extérieure de la fenêtre UI globale formant le GUI 400. Lorsque le GUI 400 est affiché sur un afficheur, cette fenêtre globale 401 peut être entièrement visible sur l'afficheur, ou bien seulement une partie de cette fenêtre peut être visible, et l'utilisateur peut naviguer dans la fenêtre 401, par exemple en provoquant un défilement en utilisant une souris ou en touchant un écran tactile.

Le GUI 400 comprend par exemple des fenêtres élémentaires à l'intérieur de la fenêtre GUI globale, chaque fenêtre élémentaire comprenant un ou plusieurs éléments d'interface comme des titres, des boîtes de dialogue, des boutons à cliquer, etc.

Dans l'exemple de la figure 4A, le GUI fournit, par exemple en réponse à une requête d'utilisateur faite en utilisant une page web séparée, une liste de cinémas dans une zone de 1 kilomètre autour du dispositif d'utilisateur. Cela est indiqué dans une fenêtre élémentaire 402, ayant le titre « Cinémas dans un rayon de 1 Km ».

Le GUI 400 comprend par exemple un contenu dynamique dans une fenêtre élémentaire 404, qui par exemple indique une liste 406 de cinémas (CINEMA 1 à CINEMA J), une liste 407 des distances de chaque cinéma par rapport à l'utilisateur, et une liste 408 des adresses de chaque cinéma.

Un formulaire de réservation de tickets de cinéma 410 est aussi par exemple prévu sur le GUI 400, permettant à un utilisateur du dispositif d'utilisateur de réserver des tickets en ligne pour aller voir un film passant dans un des cinémas. Le formulaire 410 comprend par exemple une fenêtre élémentaire 412 répétant la liste des cinémas identifiés, chacun muni d'une case de sélection 413 permettant à l'utilisateur de sélectionner l'un des cinémas. Une fenêtre élémentaire d'introduction de date et d'heure, 414, permet par exemple à l'utilisateur de sélectionner une heure et une date pour le film. Une fenêtre élémentaire 416 fournit une boîte de sélection de films pour présenter, en réponse au fait que l'utilisateur tape une ou plusieurs lettres du film, une liste 417 de films disponibles dont le nom commence par ces lettres.

Une fenêtre élémentaire d'identification 418 est aussi par exemple prévue dans le GUI 400, et est constituée de boîtes d'introduction de texte où l'utilisateur peut introduire un nom d'utilisateur et un mot de passe d'identification. Par exemple, en s'identifiant sur le site web, des données de compte d'utilisateur préenregistrées, comme des détails de carte de paiement, peuvent être récupérées pour permettre l'achat d'un ticket de cinéma. C' est par exemple le module de génération d'UI 222 du serveur distant 208, ou du dispositif d'utilisateur 300, qui sélectionne le format et/ou le type de fenêtre élémentaire 402, 404, 412, 414, 416 et 418, sur la base de caractéristiques du dispositif d'utilisateur, de l'utilisateur et/ou de l'environnement. Par exemple, chacune des fenêtres élémentaires 402, 404, 412, 414, 416 et 418 est générée sur la base de caractéristiques telles que les dimensions de l'afficheur du dispositif d'utilisateur, du fait que l'afficheur est un écran tactile, du fait qu'une souris est ou pas disponible, et/ou de l'expertise de l'utilisateur pour réaliser ce type d'introduction de données. En outre, bien que cela ne soit pas représenté en figure 4A, dans certains modes de réalisation, la couleur et/ou le contraste du GUI 400 sont adaptés sur la base du niveau de lumière ambiante détecté par le dispositif d'utilisateur. Par exemple, dans certains modes de réalisation, le format de fichier HTML peut permettre de définir un réglage de luminosité pour contrôler la luminosité de l'afficheur du dispositif d'utilisateur.

La figure 4B illustre un exemple de variante d'une fenêtre élémentaire d'introduction de date 414' qui pourrait se substituer à la fenêtre élémentaire 414 dans une version différente du GUI 400. Par exemple, la fenêtre élémentaire d'introduction de date 414 de la figure 4A est adaptée pour les utilisateurs avancés, et permet d'introduire une date et une heure. La fenêtre élémentaire d'introduction de date 414' est par exemple destinée à des utilisateurs moins compétents, et ne permet qu'une sélection de la date.

La figure 4C illustre des exemples de la mise en œuvre de la fenêtre élémentaire d'identification 418 qui pourrait être utilisée dans le GUI 400.

Par exemple, une fenêtre élémentaire 420 selon une mise en œuvre minimum comprend seulement une boîte d'introduction de texte 422 permettant à un utilisateur d'introduire des données d'identification et une autre boîte d'introduction de texte 424 permettant à un utilisateur d'introduire un mot de passe, et un petit bouton 426, que l'utilisateur peut cliquer en utilisant une souris, ou toucher sur un écran tactile, afin de soumettre les données qui ont été introduites. Cette mise en œuvre est par exemple appropriée pour un très petit afficheur, et pour des utilisateurs raisonnablement avancés, puisqu'il n'y a pas d'indication concernant les données qui sont requises dans chaque boîte de texte.

Une fenêtre élémentaire légèrement plus grande 430 mettant en œuvre la fenêtre d'identification 418 comprend les mêmes éléments que la mise en œuvre 420, mais avec les mots « Identifiant : » et « Mot de passe : » ajoutés. Cette mise en œuvre est par exemple appropriée pour des utilisateurs moins avancés que pour la fenêtre 420, mais nécessite aussi un afficheur légèrement plus grand.

Les fenêtres élémentaires 440 et 450 fournissent des mises en œuvre progrèssivement de plus en plus grandes de la fenêtre d'identification 418, contenant les boîtes d'introduction de texte 422, 424 et le bouton 426, les deux mises en œuvre comprenant l'instruction "Veuillez-vous identifier ce qui rend ces interfaces adaptées à des utilisateurs encore moins compétents. La fenêtre élémentaire 450 comprend en plus un logo de société 452 et une image d'arrière-plan 454, nécessitant un écran d'affichage relativement grand.

La figure 5Ά est un organigramme illustrant des opérations dans un procédé de génération d'UI selon un exemple de réalisation. Ces opérations sont par exemple réalisées par le module de génération d'UI 222 de la figure 2, en exécutant des instructions de logiciel mémorisées dans la mémoire d'instructions 226.

Comme cela est représenté par un bloc 501 en figure 5A, on suppose que l'interface d'utilisateur est représentée : par un modèle de domaine représentant les concepts manipulés sur le GUI. En prenant l'exemple du GUI 400 de la figure 4, les concepts pourraient inclure les cinémas ; par un modèle de contexte représentant tous les paramètres à prendre en compte pendant le processus d'adaptation de l'UI, comme la luminosité, la taille de l'écran, le niveau de la vue de l'utilisateur, etc... ; par une ou plusieurs transformations, et un modèle définissant 1'interface utilisateur, qui est soit un modèle en tâches, représentant l'interface sous forme d'une série de tâches, soit ion modèle d'UI abstrait qui représente les divers espaces de travail dans l'UI et les possibilités de navigation entre eux, soit un modèle d'UI concret qui représente les intervenants sélectionnés, comme des intervenants composites (par exemple un panneau), ou des intervenants élémentaires (par exemple un champ de texte), des espaces de travail de l'UI abstrait.

Dans une opération 502, le niveau d'abstraction du modèle d'UI est détecté. Par exemple, chaque type de modèle est associé à un méta-modèle donné décrivant le modèle, et le système est capable de détecter le type du modèle sur la base du méta-modèle.

Dans le cas où le modèle d'UI est un modèle en tâches, dans une opération 503, le modèle est transformé en un modèle d'UI abstrait, et l'opération suivante est l'opération 504.

Dans le cas où le modèle d'UI est un modèle d'UI abstrait, ou à la suite de l'opération 503, le modèle est transformé en un modèle d'UI concret, et l'opération suivante est l'opération 505.

Dans le cas où le modèle d'UI est un modèle d'UI concret, ou à la suite de l'opération 504, le modèle est transformé en code pour exécuter l'UI, par exemple au format de fichier HTML ou similaire.

La génération de code de l'opération 505 va maintenant être décrite plus en détail en faisant référence aux figures 5B et 5C.

La figure 5B est un organigramme illustrant un exemple d'opérations dans un procédé de génération du code de l'UI au niveau global, en d'autres termes pour la fenêtre UI globale, comme la fenêtre 401 dans 1'exemple de la figure 4A.

Dans une opération 506, une ou plusieurs transformations concernant la fenêtre UI globale sont sélectionnées. Par exemple, chaque transformation génère une fenêtre UI globale ayant des dimensions particulières, un modèle de couleur particulier, un agencement particulier des fenêtres élémentaires, et/ou d'autres éléments caractéristiques. La sélection d'une transformation va maintenant être décrite plus en détail.

Dans une opération 507, un entête de code GUI global du code représentant le GUI est généré.

Dans une opération suivante 508, le corps du code GUI global est généré en utilisant lesdites une ou plusieurs transformations sélectionnées. Le corps est généré par l'exécution d'une ou plusieurs tâches élémentaires pour générer chaque fenêtre élémentaire. Ces tâches élémentaires sont appelées éléments enfants.

Dans une opération 510, on détermine s'il y a un élément enfant à traiter. Si oui, l'opération suivante est l'opération 511, dans laquelle le code de l'élément enfant est généré, comme on va le décrire en référence à la figure 5C. Le procédé revient ensuite à l'opération 510. Dans l'autre cas, si tous les éléments enfants ont été traités, l'opération suivante est une opération 512 dans laquelle une terminaison du code GUI global est générée afin d'achever la représentation du code du GUI.

Dans une opération 513, on détermine ensuite si le code nécessite une compilation. Si oui, le code est compilé dans une opération 514.

Dans l'autre cas, si aucune compilation n'est nécessaire, ou après l'opération 514, l'opération suivante est une opération 515, dans laquelle le fichier comprenant le code généré est transmis à un dispositif d'utilisateur pour être affiché.

La figure 5C est un organigramme illustrant un exemple d'opérations pour mettre en œuvre l'opération 511 de la figure 5B afin de générer le code pour un élément enfant.

Dans une opération 516, une ou plusieurs transformations sont sélectionnées afin de générer le code d'une fenêtre élémentaire du GUI, sûr la base du contenu à afficher, et des caractéristiques du profil d'utilisateur et/ou du dispositif et/ou de l'environnement (luminosité, bruit, etc.). Par exemple, pour au moins certaines des fenêtres élémentaires de 1'interface utilisateur, il y a une pluralité de transformations potentielles qui peuvent être utilisées afin de générer la fenêtre élémentaire ayant des éléments adaptés à certaines caractéristiques du dispositif d'utilisateur, de l'environnement et/ou de l'utilisateur. La sélection d'une transformation peut impliquer un calcul d'une distance représentant l'étendue dans laquelle chaque transformation concorde avec les caractéristiques, avec optionnellement l'application d'une pondération différente à chaque caractéristique. Un exemple de procédé pour sélectionner une transformation va être décrit plus en détail ci-après.

Après la sélection de la transformation, dans une opération 517, un entête d'élément de code GUI est généré.

Dans une opération 518, un corps d'élément de code de GUI est alors généré en utilisant une ou plusieurs transformations sélectionnées.

Dans une opération 519, on détermine s'il y a un élément enfant à traiter. Si oui, l'opération suivante est l'opération 520, dans laquelle le code de l'élément enfant est généré. On revient ensuite à l'opération 519. Dans l'autre cas, si tous les éléments enfants ont été traités, l'opération suivante est l'opération 521, dans laquelle une terminaison d'élément de code de GUI est générée afin d'achever la représentation en code de l'élément enfant du GUI global.

Des techniques pour sélectionner les transformations à utiliser pour générer une ou plusieurs fenêtres élémentaires de l'UI, correspondant à l'opération 516 en figure 5C, vont maintenant être décrites en faisant référence aux figures 6 à 9.

La figure 6 illustre un exemple d'espace 3D de caractéristiques, dans lequel un niveau d'expertise d'utilisateur (USER EXPERTISE) est représenté sur l'axe x, un niveau de lumière ambiante (LIGHT LEVEL) est représenté sur l'axe y, et la taille de l'affichage (DISPLAY SURFACE) est représentée sur l'axe z. Bien sûr, les caractéristiques présentes en figure 6 ne sont qu'un exemple, et en fonction de la fenêtre élémentaire UI à générer, des caractéristiques différentes pourraient être prises en compte.

Dans l'exemple de la figure 6, on suppose que, pour une fenêtre élémentaire UI donnée à générer, il y a trois transformations différentes possibles. Une première transformation conduit à un composant élémentaire d'UI qui est approprié pour des niveaux de caractéristiques tombant dans un volume VI de la figure 6, une deuxième transformation conduit à un composant élémentaire d'UI qui est approprié pour des niveaux de caractéristiques tombant dans un volume V2 de la figure 6, et une troisième transformation conduit à un composant élémentaire d'UI qui est approprié pour des niveaux de caractéristiques tombant dans un volume V3 de la figure 6.

Pour un niveau donné d'expertise de l'utilisateur, de niveau lumineux et de surface d'affichage, le module de génération d'UI 222 sélectionne par exemple la transformation associée aux volumes VI, V2 et V3 sur la base d'un calcul de distance par rapport à chaque volume. On va maintenant décrire plus en détail des exemples de calculs de distance en faisant référence aux figures 7A, 7B et 7C.

La figure 7A est un diagramme illustrant le cas de volumes monodimensionnels VI et V2 pour une seule caractéristique, chaque volume correspondant à une transformation donnée. La distance d(C,Vi) d'un point C par rapport à un volume Vi est par exemple considérée nulle si le point C tombe dans le volume, en d'autres termes si νί^^ΟΧνί^χ, où le volume Vi a des limites inférieure et supérieure Vijj^ et Vimax respectivement. C' est le cas pour le point Cl en figure 7A, qui tombe dans le volume VI.

Pour des points qui ne tombent dans aucun volume, ce qui est le cas des points C2 et C3 en figure 7A, la distance est par exemple calculée comme étant la distance par rapport à la frontière Vi la plus proche, en d'autres termes d(C2,Vl)=C2-Vlmax et d(C2,V2)=V2min-C2, en d'autres ternies, d(C2,Vi)=min(|C2-Viminl'l^-Vij^xl) ·

Pour un point donné, on sélectionne par exemple le volume ayant la distance la plus courte, qui, pour les points C2 et C3, est le volume V2.

La figure 7B illustre un autre exemple de volumes monodimensionnels VI et V2, mais pour une caractéristique définie par des valeurs discrètes. Dans l'exemple de la figure 7B, la valeur est le niveau de compétence de l'utilisateur, qui est par exemple l'une des cinq valeurs suivantes classées dans l'ordre : novice ; débutant ; compétent ; performant ; et expert.

Dans 1'exemple, Cl est « débutant », qui appartient au volume VI, et C3 est « performant », qui appartient au volume V2 . Cependant, le point C2 est « compétent », qui ne fait partie ni de l'un ni de l'autre des volumes. Chacun des niveaux discrets est par exemple affecté à une valeur numérique, par exemple novice = 1, débutant = 2, etc., et la formule d(C2,Vi)=min(|C2-Vim:Ln|, ^-Vijj^xl), est par exemple appliquée. Cependant, dans cet exemple, d(C2,Vl)=l, et d(C2,V2)=l. Dans le cas de distances égales, on peut sélectionner l'un ou l'autre des volumes, ou on peut par exemple sélectionner le volume le plus sûr, qui dans cet exemple est le volume VI, qui ne risque pas de dépasser le niveau de compétence de l'utilisateur.

Dans le cas d'une caractéristique ayant une valeur binaire, comme vrai ou faux, la distance est par exemple égale à 0 si le volume et le point ont la même valeur, et égale à 1 si le volume et le point ont des valeurs différentes. Par exemple, si la caractéristique est la présence ou l'absence d'un système de positionnement dans le dispositif d'utilisateur, et si le volume VI est adapté à une utilisation où il y a un système de positionnement, la distance sera égale à 0 si le dispositif d'utilisateur a un système de positionnement, et égale à 1 autrement.

La figure 7C illustre un exemple d'un cas dans lequel des distances doivent être calculées dans un espace bidimensionnel sur la base de caractéristiques Kl et K2. Les volumes VI et V2 sont par exemple définis par : VI : <k]_ : [Kly]_m-j_n, Κίγι^χ] , K2 : [K2y]_min, K2y]_max] > V2: : [Kly2min, Kly2max] , K2 : [K2y2mj_n, K2y2max] >

Dans l'exemple de la figure 7C, un point Cl tombe dans le volume VI, et ainsi sa distance par rapport à ce volume est égale à 0. Cependant, le point C2 est dans la plage du volume VI en ce qui concerne la caractéristique Kl, mais pas en ce qui concerne la caractéristique K2. Le point C3 n' est pas dans les' plages des volumes VI ou V2 pour aucune des caractéristiques Kl et K2. Chacune des distances entre C2 et C3 et les volumes VI et V2 est par exemple définie comme la plus petite longueur d'une ligne droite joignant un point situé dans le volume Vi au point C : d(C,Vi)=V(dK1 (C,Vi)2+dK2 (C,Vi)2)

De préférence, lorsqu'on applique cette équation, les valeurs des caractéristiques Kl et K2 ont été normalisées l'une par rapport à l'autre, par exemple sur une échelle de 0 à 100, où 0 correspond à la valeur la plus faible Kjnin de la caractéristique K, et 100 correspond à la valeur la plus élevée Kmax de la caractéristique K. La formule pour la distance entre un point C représentant un contexte courant et un volume V=<k: [vKmin'vkmax] >' Pour une caractéristique K=[%in,Kmax] est ainsi :

K-min) ·

Pour un espace multidimensionnel dans lequel il y a n caractéristiques Ki, et dans lequel C est un point correspondant à des valeurs courantes Kxq de chacune des caractéristiques Ki, la distance à un volume Vi peut ainsi être définie par :

En outre, dans certains modes de réalisation, certaines caractéristiques peuvent être pondérées pour avoir des importances différentes. Par exemple, dans le cas d'un UI destiné à être utilisé dans des environnements de bureau bien éclairés, les conditions de lumière ambiante peuvent ne varier que relativement peu et être d'une importance relativement faible. Par contre, pour un UI destiné à être utilisé dans des conditions tout terrain, par exemple comme outil de navigation pour des randonneurs, les conditions de lumière ambiante peuvent avoir une grande importance, et être ainsi pondérées en conséquence. Un coefficient de pondération πκί est ainsi par exemple ajouté à la formule, qui devient la formule suivante :

Dans certains cas, la sélection de certains volumes pour des caractéristiques de certaines plages peut être complètement empêchée. Par exemple, il pourrait être impossible qu'une certaine fenêtre élémentaire associée à un certain volume soit appliquée à un écran d'affichage qui est plus grand qu'une certaine taille. De tels volumes sont par exemple définis par : v=<vmin' vmax' Limmin' Li%iax>' où Lil%iin est la valeur la plus faible d'une caractéristique K pour laquelle le volume V peut être sélectionné, et Lin^nax est la valeur la plus forte de la caractéristique K pour laquelle le volume V peut être sélectionné. Bien sûr, dans certains modes de réalisation, seule la limite inférieure Lirt^n ou seule la limite supérieure Liit^^ pourrait être prévue.

La figure 8 est un organigramme représentant un exemple d'opérations dans un procédé de création de modèles et de transformations pour générer une fenêtre élémentaire selon un exemple de réalisation. Ces opérations sont par exemple réalisées par un concepteur pendant une phase de conception.

Dans une opération 801, on identifie un ensemble de n caractéristiques pertinentes {Kq}n. Par exemple, cette opération implique de déterminer, pour le contenu donné à afficher, quelles sont les caractéristiques pertinentes qui peuvent affecter la façon avec laquelle le contenu est affiché. Par exemple, lorsque le nombre d'éléments à afficher est supérieur à un certain nombre, la taille de l'afficheur du dispositif d'utilisateur peut devenir pertinente pour décider de la façon de représenter ce contenu.

Dans une opération 802, une plage de valeurs possibles, entre Kjman et Kjmax, est récupérée ou définie pour chaque caractéristique, comme cela est représenté par

{<Ki,Kimj_n,KImax>}n. Par exemple, chaque caractéristique peut prendre l'une des formes suivantes : - une valeur binaire, comme « vrai » ou « faux ».

Exemple : une caractéristique définissant si le dispositif d'utilisateur a ou pas un système de positionnement global ; - un classement ordonné de niveaux prédéfinis.

Exemple : le niveau d'expertise d'un utilisateur, qui peut être défini parmi les niveaux « novice », « débutant », « compétent », « expérimenté », et « expert » ; - une valeur dans une plage continue de nombres. Exemple : une valeur représentant le niveau lumineux ambiant, qui va par exemple de 0 (noir absolu) à 120000 (soleil direct) ; - des valeurs discrètes. Exemple : les valeurs représentant la taille de l'afficheur, qui pourrait aller d'une valeur de diagonale la plus petite de 0,27 pouce jusqu'à une valeur de diagonale la plus grande de 4015 pouces.

Dans une opération 803, on définit des poids relatifs 7tki pour chaque caractéristique. Les poids sont définis sur la base du contenu. Par exemple, en fonction du contenu à afficher, la taille de 1'afficheur du dispositif d'utilisateur peut avoir une importance élevée lors de la définition de l'UI.

Dans une opération 804, on définit une pluralité de volumes magnétiques Vi, par exemple en subdivisant chaque plage de caractéristique en deux ou plusieurs sous-plages, chaque volume magnétique correspondant à un vecteur d'une combinaison de sous-plages sélectionnées.

Dans une opération 805, on définit par exemple des conditions pour un fonctionnement effectif de chaque UI afin de spécifier les exigences fonctionnelles de l'UI et/ou des composants élémentaires de l'UI. Par exemple, si l'UI affiche la température courante, il a besoin d'une connexion à un capteur de température pour obtenir des mesures de température. Si cette connexion est perdue, l'UI ne peut pas fonctionner correctement, et par exemple il produit une réaction comme l'affichage d'un message d'avertissement ou d'erreur. De telles conditions fonctionnelles et de telles réactions peuvent être définies au niveau de l'UI ou au niveau composant élémentaire.

Dans une opération 806, un ou plusieurs modèles et une ou plusieurs transformations sont conçus et générés ou créés d'une autre façon pour générer une fenêtre élémentaire d'UI associée à chaque volume. Par exemple, les transformations qui comprennent des instructions utilisées par le module de génération d'UI ou par un dispositif d'utilisateur pendant la génération d'un UI, sont créées par un concepteur. En outre, des modèles de tâches, de domaines et de contextes sont par exemple créés par un concepteur, et ces modèles sont aussi utilisés pendant la génération de l'UI. Le modèle de contexte peut être rempli par un concepteur sur la base de caractéristiques d'utilisateurs, ou par des programmes et/ou des capteurs, par exemple sur la base de géolocalisation. D'autres modèles, comme le modèle d'UI abstrait et le modèle d'UI concret peuvent être générés automatiquement sur la base du modèle de tâche.

La figure 9A est un organigramme illustrant des opérations dans un procédé de sélection de transformations pour générer un UI constitué d’une ou plusieurs fenêtres élémentaires. Ce procédé est par exemple réalisé pendant l’opération 516 de la figure 5C.

Comme cela est représenté dans l’opération 901, on suppose qu’un processus de conception a fourni N caractéristiques de contextes K={<Ki, Kimin, Kimax, , et des transformations pour générer des fenêtres élémentaires d’UI ayant des volumes magnétiques correspondants V={<{KVImin,KVImax}n, UIi>}*, où * est un entier égal ou supérieur à 0 représentant le nombre de volumes.

Dans une opération 902, une fonction "getTrans-formation" est appelée, avec comme paramètres d’entrée le contexte courant C, les volumes magnétiques V, et les caractéristiques de contexte K avec leurs poids associés nKi.

Dans une opération 903, une variable "minDistance" est mise à l'infini, une valeur de résultat "Transformation" de la fonction est mise à une valeur nulle, et une variable v est mise à 0.

Dans une opération 904, on détermine si la variable v est inférieure à Card(V), en d'autres termes le nombre de volumes magnétiques. Si la réponse est non, les opérations 905 à 908 sont réalisées.

Dans l'opération 905, une distance est calculée en appelant une autre fonction "magneticDistance", avec comme paramètres d'entrée le contexte courant C, le volume V[v], et les caractéristiques de contexte K.

Dans l'opération 906, on détermine si la distance déterminée dans l'opération 905 est inférieure à la valeur de la variable minDistance. Si oui, l'opération suivante est l'opération 907, dans laquelle la variable minDistance est mise égale à la valeur de distance, et la valeur de "Transformation" est mise égale à la transformation associée au volume V[v]. Après l'opération 907, ou si dans l'opération 906 la distance n'est pas inférieure à la valeur de la variable minDistance, l'opération suivante est l'opération 908, dans laquelle la variable v est incrémentée, puis on revient à l'opération 904.

Lorsque la valeur du paramètre v n'est plus inférieure au nombre de volumes magnétiques V, 1'opération après l'opération 904 est une opération 909, dans laquelle la valeur de la variable "Transformation" est retournée comme résultat.

La figure 9B illustre un exemple d'opérations mettant en oeuvre le calcul de distance de l'opération 905 de la figure 9A.

Comme cela est représenté en 910, la- fonction est appelée avec des paramètres d'entrée C={Ci}n, vol={<{KVImin,' KVImax, LimVImin, LimVImax>}n, où vol est l'un des volumes de l'ensemble V de volumes, et K={<Ki,Kimin,Kimax, nKi>}n.

Dans une opération 911, la variable "distance" est mise à 0, et une variable i est mise à 0.

Dans une opération 912, on détermine si i est inférieur à n. Si oui, l'opération suivante est l'opération 913, dans laquelle la distance est calculée par : distance=distance+(Ck>Kyjmj^&amp;&amp;Ck<Kyjmax?

Dans une opération 914, la variable i est incrémentée, puis le procédé revient à l'opération 912.

Si dans l'opération 912 on détermine que i n'est pas inférieur à n, l'opération suivante est l'opération 915, dans laquelle la racine carrée de la valeur de la distance est renvoyée comme résultat.

La figure 10A est un organigramme illustrant un exemple d'opérations dans un procédé d'adaptation d'un ÜI sur la base d'un contexte de changements d'utilisation survenant pendant l'affichage d'un UI sur un dispositif d'utilisateur. Par exemple, bien que les caractéristiques du dispositif d'utilisateur soient peu susceptibles de changer, certaines caractéristiques de l'environnement, comme le niveau lumineux ambiant, ou le bruit de fond, pourraient changer pendant que l'UI est visualisé. Le procédé de la figure 10A permet à l'UI d'être adapté sur la base d'un tel changement.

Dans une opération 1001, le contexte courant est surveillé, et dans le cas de changement, l'opération suivante est l'opération 1002. L'opération 1002 est aussi par exemple réalisée si dans une opération 1003 un utilisateur demande de naviguer vers un UI qui doit être généré, ou si dans une opération 1004 un fonctionnement défectueux est détecté.

Dans l'opération 1002, on détermine s'il y a un UI préexistant adapté au nouveau contexte courant. Par exemple, dans certains modes de réalisation, un nombre limité des UI les plus courants peut être généré à l'avance et stocké en mémoire. En plus ou à la place, à la suite de la génération d'un UI donné, le code peut être maintenu pendant ion certain temps dans le cas où un autre dispositif d'utilisateur a le même contexte et demande le même UI.

La vérification dans l'opération 1002 comprend par exemple un calcul de distance similaire à celui décrit en relation avec les figures 9A et 9B susmentionnées, mais dans lequel on identifie qu'un UI est associé à un volume, plutôt qu'à des transformations.

Si dans une opération 1002 un UI est trouvé, l'opération suivante est l'opération 1005, dans laquelle cet UI est considéré comme étant une Interface Utilisateur Finale (FUI), en d'autres termes du code à exécuter, après compilation si nécessaire. L'UI, appelé magneticFUI en figure 10A, est ainsi transmis vers le dispositif d'utilisateur et exécuté par celui-ci. En variante, si aucun UI n'est trouvé, dans une opération 1006, l'UI est généré en utilisant par exemple le procédé décrit en relation avec les figures 5A, 5B et 5C, puis le procédé passe à l'opération 1005.

Dans le mode de réalisation décrit en relation avec la figure 10A, l'adaptation de l'UI en fonction du contexte dans les opérations 1002, 1005 et 1006 est réalisée globalement sur l'UI, plutôt qu'au niveau du serveur ou sur le dispositif d'utilisateur. En d'autres termes, l'adaptation du code de l'UI sur la base des caractéristiques modifiées est une adaptation globale du code de l'UI comprenant la régénération de la totalité du code de l'UI.

Cependant, dans des variantes de réalisation, l'adaptation de l'UI en fonction du contexte dans les opérations 1002, 1005 et 1006 pourrait être réalisée localement, en d'autres termes sur seulement une portion de l'UI, en régénérant au niveau du serveur seulement une partie du code de l'UI (par exemple lorsque certaines parties de l'UI ne peuvent plus être affichées) ou en modifiant localement, au niveau du serveur ou sur le dispositif d'utilisateur, le code de l'UI (par exemple lorsque la couleur du texte est mise à rouge). Par exemple, l'opération 1001 implique l'identification, par le dispositif de traitement 224, d'une ou plusieurs portions du code de l'UI à adapter sur la base du contexte modifié. Dans les opérations 1002, 1005 et 1006, seulement lesdites une ou plusieurs portions identifiées du code de l'UI sont alors adaptées. Une adaptation locale est avantageuse puisqu'elle peut être réalisée plus rapidement qu'une adaptation globale de l'UI, et/ou implique des ressources de traitement réduites.

La figure 10B est un organigramme illustrant l'opération de surveillance de contexte 1001 de la figure 10A plus en détail selon un exemple de réalisation.

Dans une opération 1007, le contexte d'utilisation C est capturé à partir du dispositif d'utilisateur. Le contexte d'utilisation C est par exemple défini par n valeurs de contexte {Ci}n.

Dans une opération 1008, on vérifie si le contexte d'utilisation C a changé par rapport à la valeur précédemment conservée. Si ce n'est pas le cas, le procédé revient à l'opération 1007. Par contre si le contexte a changé, l'opération suivante est l'opération 1009.

Dans l'opération 1009, on détermine si le changement dans le contexte nécessite une adaptation de l'UI. Par exemple, un calcul est fait pour déterminer si les transformations à sélectionner sur la base des valeurs de contexte sont identiques aux transformations sélectionnées lorsque l'UI a été généré pour la dernière fois. Si elles sont identiques, le procédé revient à l'opération ' 1007. Par contre, si une ou plusieurs des transformations ont changé, on considère qu'une adaptation est requise, et le procédé passe à l'opération 1002 de la figure 10A.

La figure 10C est un organigramme illustrant plus en détail l'opération 1005 consistant à exécuter l'UI, selon un exemple de réalisation.

Dans une opération 1010, on détermine si le code de l'UI est exécutable. Si la réponse est non, dans une opération 1011, un fichier exécutable est généré puis, dans une opération 1012, on détermine si le fichier nécessite ou pas une compilation. Si la réponse est oui, le fichier est compilé dans une opération 1013. L'opération apres l'opération 1013, ou après l'opération 1010 ou 1012 si le fichier est exécutable ou ne nécessite pas de compilation, est l'opération 1014 dans laquelle le fichier est exécuté sur le dispositif d'utilisateur.

Bien que la figure 10C soit basée sur le cas d'une adaptation globale de l'UI, une adaptation locale pourrait être réalisée comme cela a été décrit précédemment, soit au niveau du serveur soit sur le dispositif d'utilisateur. Dans un tel cas, les opérations 1010 à 1014 sont par exemple réalisées pour chaque composant élémentaire de l'UI qui doit être adapté.

La figure 10D est un organigramme illustrant l'opération 1004 de la figure 10A plus en détail selon un exemple de réalisation. L'exemple de la figure 10D correspond par exemple à une approche centralisée mise en œuvre par le module de génération d'UI 222 de la figure 2.

Dans une opération 1015, des conditions pendant l'exécution d'un UI courant sont par exemple examinées pour déterminer, dans une opération 1016, s'il y a des conditions non remplies. Les conditions non remplies correspondent, par exemple, à une ou plusieurs valeurs d'entrée manquantes qui doivent être affichées par l'UI. Si la réponse est non, le procédé revient à l'opération 1015.

Dans me opération 1017, on sélectionne l'une d'une pluralité de réactions, comprenant par exemple : me opération 1018 dans laquelle m UI alternatif est affiché ; me opération 1019 dans laquelle m autre utilisateur, comme m technicien surveillant le système complet, est informé du problème ; une opération 1020 dans laquelle l'UI est dégradé, par exemple en modifiant l'aspect de la fenêtre élémentaire de l'UI concernée par la condition non remplie, par exemple en changeant la couleur de son texte de noir à rouge ; et une opération 1021 dans laquelle une alerte est affichée. Dans certains cas plusieurs des réactions 1018 à 1021 peuvent être réalisées. A la suite des réactions 1018 à 1020, l'opération 1002 est par exemple réalisée, afin d'adapter l'UI. A la suite des réactions 1019, 1020 et 1021, le procédé revient en plus ou en alternative à l'opération 1015.

La figure 10E est aussi un organigramme illustrant plus en détail l'opération 1004 de la figure 10A, et les éléments similaires à ceux de la figure 10D ont été représentés avec les mêmes références numériques et ne seront pas décrits de nouveau en détail. Cependant, la figure 10E correspond à une approche distribuée, dans laquelle au moins une partie du procédé est réalisé au niveau des dispositifs d'utilisateurs. Par exemple, les opérations 1015 et 1016 sont réalisées au niveau du dispositif d'utilisateur. Cependant, si une condition est trouvée non remplie dans l'opération 1016, l'opération suivante est l'opération 1022, dans laquelle le dispositif d'utilisateur détermine la réaction qui est par exemple soit de modifier le style de l'UI dans une opération 1022, par exemple en affichant une forme de signe d'avertissement sur l'afficheur du dispositif de l'utilisateur, soit de transmettre un rapport au serveur 208 dans une opération 1023. Dans ce dernier cas, le serveur par exemple met en œuvre l'opération 1017 et met en œuvre une ou plusieurs des opérations 1018, 1019 et 1020 avant d'exécuter l'opération 1002.

Un avantage des modes de réalisation décrits ici est que, en générant une interface utilisateur adaptée à des caractéristiques associées à un utilisateur, à un ou plusieurs dispositifs d'utilisateurs, et/ou à l'environnement, l'interface peut être adaptée à des contextes d'utilisation spécifiques, sans avoir besoin de créer à l'avance, de maintenir et de mémoriser toutes les versions de l'UI disponibles. En effet, comme cela a été décrit précédemment, le nombre de versions augmente exponentiellement avec le nombre de caractéristiques différentes d'utilisateurs, de dispositifs et/ou d'environnement à considérer, ce qui rend rapidement infaisable de créer et de mémoriser chaque version.

Avec la description ainsi faite d'au moins un mode de réalisation illustratif, diverses altérations, modifications et améliorations apparaîtront facilement à l'homme de l'art.

En particulier, bien que certains exemples des caractéristiques utilisées pour définir les UI aient été donnés, il apparaîtra à l'homme de l'art que les modes de réalisation décrits ici pourraient être appliqués à n'importe quelles caractéristiques pertinentes.

Claims (17)

1. REVENDICATIONS

   1. Système pour générer une interface utilisateur (UI) à exécuter sur un dispositif d'utilisateur (300), le système comprenant : un ou plusieurs dispositifs mémoires (212, 228) mémorisant des caractéristiques associées au dispositif d'utilisateur, à un ou plusieurs utilisateurs du dispositif d'utilisateur et/ou à l'environnement du dispositif d'utilisateur ; et un dispositif de traitement (224, 304) adapté à générer du code UI pour mettre en oeuvre l'UI : en générant une première portion du code UI en utilisant une ou plusieurs premières transformations sélec tionnées sur la base d'une ou plusieurs des caractéristiques ; en générant une deuxième portion du code UI en utilisant une ou plusieurs deuxièmes transformations sélec tionnées sur la base d'une ou plusieurs des caractéristiques ; et en assemblant au moins les première et deuxième portions pour générer le code UI.
2. 2. Système selon la revendication 1, dans lequel lesdits un ou plusieurs dispositifs mémoires (212, 228) mémorisent en outre un contenu dynamique à représenter par l'UI, et dans lequel le dispositif de traitement (224) est adapté à sélectionner lesdites une ou plusieurs premières et deuxièmes transformations en outre sur la base du contenu dynamique.
3. 3. Système selon la revendication 1 ou 2, dans lequel les caractéristiques comprennent une ou plusieurs caractéristiques parmi : une indication de la taille de l'afficheur du dispositif d'utilisateur ; une indication d'au moins un langage de programmation d'UI compatible avec le dispositif d'utilisateur ; une indication d'un niveau de lumière ambiante détecté par le dispositif d'utilisateur ; une indication d'un niveau de bruit ambiant détecté par le dispositif d'utilisateur ; une indication d'un niveau d'expertise de l'utilisateur du dispositif d'utilisateur ; une indication de la langue de l'utilisateur du dispositif d'utilisateur ; et une indication du niveau de la vue de l'utilisateur du dispositif d'utilisateur.
4. 4. Système selon la revendication 3, dans lequel le dispositif d'utilisateur comprend un ou plusieurs éléments parmi : un détecteur de lumière ambiante (308) pour détecter le niveau de lumière ambiante ; un microphone (310) pour détecter le niveau de bruit ambiant ; et un dispositif de localisation (312) pour détecter la position du dispositif d'utilisateur.
5. 5. Système selon 1'une quelconque des revendications 1 à 4, dans lequel l'UI est une interface audio.
6. 6. Système selon l'une quelconque des revendications 1 à 5, dans lequel l'UI est une interface utilisateur graphique, et dans lequel chacune des première et deuxième portions du code UI génère une fenêtre élémentaire correspondante de 1'interface utilisateur graphique.
7. 7. Système selon la revendication 6, dans lequel au moins l'une des première et deuxième portions du code UI met en œuvre un élément de saisie d'utilisateur pour permettre à un utilisateur d'introduire une sélection.
8. 8. Système selon l'une quelconque des revendications 1 à 7, dans lequel le dispositif de traitement (224, 304) est en outre adapté à générer un code d'entête et un code de terminaison du code UI.
9. 9. Système selon 1'une quelconque des revendications 1 à 8, dans lequel, pendant l'exécution du code UI par le dispositif d'utilisateur, le dispositif de traitement (224, 304) est en outre adapté à recevoir une ou plusieurs caractéristiques modifiées et à adapter le code UI sur la base des caractéristiques modifiées.
10. 10. Système selon la revendication 9, dans lequel l'adaptation du code UI sur la base des caractéristiques modifiées est une adaptation globale du code UI comprenant la régénération de la totalité du code UI.
11. 11. Système selon la revendication 9, dans lequel le dispositif de traitement est adapté à identifier au moins la première portion du code UI à adapter sur la base des caractéristiques modifiées, et dans lequel l'adaptation du code UI comprend une adaptation locale du code UI dans laquelle la première portion du code UI est adaptée mais pas la deuxième portion.
12. 12. Système selon l'une quelconque des revendications 1 à 11, dans lequel le dispositif de traitement (224, 304) est adapté à sélectionner les premières et deuxièmes transformations en calculant une distance par rapport à un volume Vi correspondant à chaque transformation sur la base de l'équation suivante :

    où Kic est une valeur courante de chacune des caractéristiques Ki, chaque volume Vi est défini par des valeurs minimum et maximum de chaque caractéristique Kl à Kn de la façon suivante : Vi=<Kl: [Klvimin,Klvimax] . . -Kn[Knvimin,KnVimax]>' èt dans lequel chaque caractéristique Ki est associée à une valeur maximum Kimax et une valeur minimum Kim-Ln, et Ttja est un coéfficient de pondération.
13. 13. Système selon l'une quelconque des revendications 1 à 12, mis en œuvre : dans le dispositif d'utilisateur ; et/ou

    dans un serveur distant (208) agencé pour communiquer avec le dispositif d'utilisateur par 1'intermédiaire d'un ou plusieurs réseaux intermédiaires (110).
14. 14. Procédé pour générer une interface d'utilisateur (UI) à exécuter par un dispositif d'utilisateur (300), le procédé comprenant : générer du code UI pour mettre en œuvre l'UI : - en générant une première portion du code UI en utilisant une ou plusieurs premières transformations sélectionnées sur la base d'une ou plusieurs caractéristiques associées au dispositif d'utilisateur, à un ou plusieurs utilisateurs du dispositif d'utilisateur et/ou à l'environnement du dispositif d'utilisateur ; - en générant une deuxième portion du code UI en utilisant une ou plusieurs deuxièmes transformations sélectionnées sur la base d'une ou plusieurs des caractéristiques ; et - en assemblant au moins les première et deuxième portions pour générer le code UI ; et exécuter le code UI par le dispositif d'utilisateur.
15. 15. Procédé selon la revendication 14, dans lequel l'assemblage d'au moins les première et deuxième portions pour générer le code UI comprend la génération d'un code d'entête et d'un code de terminaison du code UI.
16. 16. Procédé selon la revendication 14 ou 15, dans lequel la première portion de code correspond à une fenêtre élémentaire de l'interface d'utilisateur, et dans lequel la génération de la première portion de code comprend la génération d'un entête de code d'un élément de GUI (interface d'utilisateur graphique) et d'une terminaison de code d'un élément de GUI.
17. 17. Support de stockage lisible par un ordinateur mémorisant sur lui des instructions qui, lorsqu'elles sont exécutées par un dispositif de traitement, mettent en œuvre le procédé de l'une quelconque des revendications 14 à 16.