EP3320419A1 - Systeme et procede pour l'adaptation d'une interface d'utilisateur - Google Patents

Systeme et procede pour l'adaptation d'une interface d'utilisateur

Info

Publication number
EP3320419A1
EP3320419A1 EP16750941.3A EP16750941A EP3320419A1 EP 3320419 A1 EP3320419 A1 EP 3320419A1 EP 16750941 A EP16750941 A EP 16750941A EP 3320419 A1 EP3320419 A1 EP 3320419A1
Authority
EP
European Patent Office
Prior art keywords
code
user
user device
transformations
user interface
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP16750941.3A
Other languages
German (de)
English (en)
Inventor
Eric CERET
Gaëlle PAEN-CALVARY
Marc BITTAR
Sophie CHESSA
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Institut Polytechnique de Grenoble
Universite Grenoble Alpes
Original Assignee
Institut Polytechnique de Grenoble
Universite Grenoble Alpes
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Institut Polytechnique de Grenoble, Universite Grenoble Alpes filed Critical Institut Polytechnique de Grenoble
Publication of EP3320419A1 publication Critical patent/EP3320419A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/38—Creation or generation of source code for implementing user interfaces

Definitions

  • the present disclosure relates to the field of human-computer interaction, and in particular a system and method for generating a user interface.
  • GUI graphical user interface
  • the utili ⁇ sateur device could for example be a desktop computer, a laptop, a smartphone, a tablet computer, etc ..
  • a user interface may include an audio interface based on speech, and a touch type interface and / or another type of interface.
  • User interfaces are used in a wide variety of software applications, such as word processing, spreadsheets, web browsers, etc.
  • the digital content of the user interfaces, and the manner in which they are presented on the user device, are determined by the data provided by a file stored on a user device or transmitted by a remote server.
  • display windows for some applications may be represented by files encoded in Java or C ++, while pages are usually encoded by files of type HTML (Hypertext Markup Language).
  • user interfaces are generally designed to be compatible with a relatively wide range of user devices, so that a user can successfully access information, make selections, navigate to new windows / pages , and introduce data.
  • a desktop device is generally considered to comprise a relatively large screen of 12 inches or more, a keyboard and a mouse
  • a mobile device is generally characterized in that it uses a relatively small touch screen, and by the absence of keyboard or mouse.
  • a graphical user interface there are often two versions of a graphical user interface, one being adapted to "desktop” devices, and the other adapted to "mobile” devices.
  • the user installs the version of the application corresponding to his device, or in the case of web interfaces, the two types of web pages are stored by the remote server hosting the site, and one or the other are transmitted to the device.
  • user for example on the based on an automatic detection of the type of the user device, and / or on the basis of a selection by the user.
  • One solution for obtaining such versions of the user interface would be to extend the strategy currently adopted to create and store more than one version of each interface. However, since the number of versions to be supported increases, this solution would lead to a high cost in data storage, and also to a high cost for the development and maintenance of each version.
  • a conceptual approach known as "Responsive Design” has been proposed to adapt a web page to a particular size of display window.
  • This approach involves programming the CSS file (Cascading Style Sheets) associated with an HTML document so that the display format is selected based on a detected window size in which the web page is to be displayed.
  • Adaptation can change the organization of the display (for example, change the location of some parts of the user interface), or make some parts of the user interface invisible.
  • the same user interface code is transmitted to all the devices accessing the web page, and one of the display formats defined in the CSS file of this code will be selected according to the size of the window. All the data that could be displayed on the device is transferred, even if the CSS directives express that in the current situation, some of the data is not displayed.
  • An object of embodiments of the present disclosure is to at least partially solve one or more problems of the prior art.
  • a system for generating a user interface, UI, to be executed on a user device comprising: one or more memory devices storing a current context defined by characteristics associated with the user device , to one or more users of the user device and / or the environment of the user device; and a processing device capable of selecting an adapted UI from among predefined UIs if necessary, or, failing that, of generating UI code to implement the UI: by generating a first portion of the UI; UI code using one or more first transformations selected on the basis of one or more of the features, said one or more first transformations being adapted to transform at least one model defining a first portion of the user interface into said first portion of the code UI; generating a second portion of the UI code using one or more second selected transformations based on one or more of the features; and assembling at least the first and second portions to generate the UI code, said one or more second transformations being adapted to transform at least one model defining a second portion
  • the processing device is further adapted to calculate a distance between the current context and a context associated with one or more other UI codes generated previously, and to select one of the other UI codes according to this distance.
  • the processing device is further adapted to generate the UI code on the basis of one or more additional transformations previously selected for the generation of a user interface adapted to a previous context similar to the current context.
  • said one or more memory devices further store dynamic content to be represented by the UI, and the processing device is adapted to select said one or more first and second transformations further on the basis of the dynamic content.
  • the features comprise one or more characteristics among: an indication of the size of the display device of utili ⁇ sateur; an indication of at least one UI programming language compatible with the user device; an indication of an ambient light level detected by the user device; an indication of a noise level ambient detected by the user device; an indication of a level of expertise of the user of the user device; an indication of the language of the user of the user device; and an indication of the level of the user's view of the user device.
  • the user device comprises one or more of: an ambient light detector for detecting the ambient light level; a microphone for detecting the ambient noise level; and a location device for detecting the position of the user device.
  • the UI is an audio interface.
  • the UI is a graphical user interface
  • each of the first and second portions of the code IU generates an elementary window corres ponding ⁇ of the graphical user interface.
  • At least one of the first and second portions of the UI code implements a user input element to allow a user to enter a selection.
  • the processing device is further adapted to generate a header code and a termination code of the UI code.
  • the processing device is further adapted to receive one or more modified characteristics and to adapt the UI code based on the modified characteristics.
  • the adaptation of the UI code on the basis of the modified characteristics is a global adaptation of the UI code comprising the regeneration of the entire UI code.
  • the treatment device is adapted to identify at least the first portion of the UI code to be adapted on the basis of the modified characteristics, and the adaptation of the UI code comprises a local adaptation of the UI code in which the first portion of the UI code is adapted but not the second portion.
  • the processing device is adapted to select the first and second transformations by calculating a distance with respect to a volume Vi corresponding to each transformation on the basis of the following equation:
  • Kiç is a value current of each of the characteristics Ki
  • the system is implemented: in the user device; and / or in a remote server arranged to communicate with the user device via one or more intermediate networks.
  • a method for generating a user interface, UI, to be executed by a user device comprising: generating UI code to implement the UI: generating a first portion of the UI code using one or more first selected transformations on the basis of one or more characteristics associated with the user device, one or more users of the user device and / or the environment of the user device, said one or more first transformations being adapted to transforming at least one model defining a first portion of the user interface into said first portion of the UI code; generating a second portion of the UI code using one or more second selected transformations based on one or more of the features; and assembling at least the first and second portions to generate the UI code, said one or more second transformations being adapted to transform at least one model defining a second portion of the user interface into said second portion of the UI code; and execute the UI code by the user device.
  • the method further comprises calculating a distance between the current context and a context associated with one or more other UI codes generated previously, and the selection of one of the other UI codes according to this distance.
  • the assembly of at least the first and second portions to generate the UI code comprises generating a header code and a termination code of the UI code.
  • the first portion of code corresponds to an elementary window of the user interface
  • the generation of the first portion of code comprises the generation of a code header of a GUI element (interface graphical user) and a code termination of a GUI element.
  • Figure 1 schematically illustrates an exemplary system for providing a user interface to a user device
  • Figure 2 schematically illustrates a system for providing a user interface to a user device according to an exemplary embodiment of the present description
  • Figure 3 schematically illustrates a user device according to an exemplary embodiment
  • FIG. 4A represents a graphical user interface according to an exemplary embodiment
  • FIG. 4B represents an elementary data input window of the interface of FIG. 4A according to an exemplary embodiment
  • FIG. 4C represents elementary identification windows of the interface of FIG. 4A according to several exemplary embodiments
  • Figs. 5A, 5B and 5C are flow diagrams illustrating operations in a method for generating a user interface according to an exemplary embodiment
  • Fig. 6 is a diagram showing user interface categories adapted to light levels, user expertise, and display surface, according to an exemplary embodiment
  • Fig. 7A is a diagram showing volumes in a one-dimensional space according to an exemplary embodiment
  • Figure 7B is a diagram showing volumes in a one-dimensional space according to another embodiment
  • Fig. 7C is a diagram showing volumes in a two-dimensional space according to an exemplary embodiment
  • Fig. 8 is a flowchart illustrating operations in a method for generating a user interface according to an exemplary embodiment
  • Figs. 9A and 9B are flowcharts showing operations in a method of selecting a magnetic volume based on a distance calculation according to an exemplary embodiment
  • Fig. 10A is a flowchart illustrating a method of dynamically adapting a user interface according to an exemplary embodiment
  • Fig. 10B is a flowchart illustrating steps of an operation of Fig. 10A of context monitoring according to an exemplary embodiment
  • Fig. 10C is a flowchart illustrating steps of an operation of Fig. 10A for selecting a pre-existing user interface according to an exemplary embodiment
  • Fig. 10D is a flowchart illustrating steps of an operation of Fig. 10A for managing faulty operation according to a centralized approach
  • Fig. 10E is a flowchart illustrating steps of an operation of Fig. 10A for managing faulty operation according to a distributed approach.
  • GUI graphical user interface
  • FIG. 1 schematically illustrates an exemplary system 100 for providing a graphical user interface according to a solution similar to that described in the aforementioned prior art section.
  • the system includes a number of user devices, such as a laptop 102, a smartphone 104, and an internet-capable watch 106.
  • Each user device 102, 104, 106 includes a display for displaying a GUI.
  • each user device 102, 104, 106 may execute a web browser arranged to communicate with a remote server (SERVER) 108 via one or more intermediate networks 110 comprising, for example, the internet network.
  • a web browser is a software application, loaded onto a user device, which provides access to information via web pages provided by a remote server. The web browser provides information resources to a user, allowing the user to view the information, to enter data, and to access other information by browsing other pages.
  • the remote server (SERVER) 108 for example transmits web pages to the user devices 102, 104, 106 to display content and to receive selections made by the user.
  • the web pages are for example stored in HTML format by one or more memory devices (MEMORY) 112 at the remote server 108.
  • the memory 112 stores different versions of each web page, each version ensuring a different GUI, GUI 1 to GUI N.
  • Each of these interfaces is for example adapted to a different type of user device, user expertise and / or environment.
  • the response time is relatively short for the transmission of an appropriate version of the versions of the web page to a requesting user device, when the number N of GUI versions becomes relatively high, there will be a corresponding increase in resources memories needed to store these interfaces.
  • each user device 102, 104, 106 is for example designed to execute one or more software applications. In association with each software application, the user device 102, 104, 106 stores for example N GUI1 GUI interfaces (not shown in Figure 1).
  • GUIs are stored at a remote server and made available to any type of device
  • an application or website includes 100 GUIs, in other words 100 web pages or windows, this would lead to a total of 600,000 interfaces.
  • the storage requirements for these many interfaces would be 6000 times those of the 100 GUIs, and the cost of development and maintenance would be excessive.
  • the number of GUI versions could already be limited to a given type of device and a given programming language, which would divide by 20 in the previous example, the number of versions to be available. However, the number of GUI versions would still be 300, which is likely to exceed the available storage capacity of an internet-enabled watch or smartphone.
  • FIG. 2 schematically illustrates an exemplary system 200 for providing a user interface according to an exemplary embodiment of the present description.
  • adapted user interfaces are generated by a server 208 and transmitted to the user devices (not shown in FIG. 2).
  • the system 200 can communicate with one or more user devices via one or more intermediate networks 110 such as the Internet.
  • the system 200 comprises the server 208 and one or more memory devices (MEMORY) 212 storing user or device profiles 1 to N (USER / DEVICE PROFILE1 to USER / DEVICE PROFILEN), as will be described in more detail hereinafter. -after.
  • the server 208 comprises, for example, a communication interface (COMMS INTERFACE) 220 for communicating with the user devices via the intermediate networks 110.
  • the communications interface 220 is coupled to a UI generation module 222.
  • the module 222 is for example implemented by software.
  • the module 222 comprises a processing device (P) 224 comprising one or more processors under the control of instructions stored in an instruction memory (MEM INSTR) 226.
  • the module 222 also comprises for example one or more memories (MEMORY) 228 memorizing the dynamic content (DYNAMIC CONTENT) of a UI, and the transformations (TRANSFORMATIONS) used during the generation of the UI, in the sense of Model Driven Engineering and as we will describe it more in detail in the following.
  • the UI generation module 222 generates, for example, UIs, practically in real time, in response to requests from user devices.
  • the memory 212 stores for example a profile indicating features relating to the user device, such as the type of device, the size of the display screen , and other capabilities of the device.
  • the memory 112 also stores, for example, characteristics concerning the user, such as his preferred language, his level of expertise, and an indication of specific user requirements, such as a larger text size for users having a bad view, etc.
  • there could be a plurality of device profiles each corresponding to each user device that the user can use to access web pages.
  • the UI generation module 222 for example generates UIs based on the profile of the user and / or the device requesting access to a web page / UI, and on the basis of one or more environment characteristics. , which are for example received from the user device. optionally, the UI generation module 222 also adapts the UI on the basis of dynamic content retrieved by the server 208 and which must be displayed to the user.
  • the adaptation of the UI can be described as being "magnetic" in the sense that the generated UI is for example the one that corresponds most to a current context, in other words to common device characteristics, user and / or environment.
  • FIG. 3 schematically illustrates a user device 300 according to an exemplary embodiment.
  • the user device 300 comprises for example a communication interface (COMMS INTERFACE) 302 allowing communications with the remote server 208.
  • the device 300 comprises for example a processing device 304 comprising one or more processors under the control of instructions stored in a memory ins ⁇ structions (INSTR MEM) 306, the processor 304 performs the functions of the mobile device.
  • a web browser makes it possible, for example, to display web pages on a display (DISPLAY) 307 of the user device.
  • other types of applications stored by the memory 306 may allow other types of UIs to be displayed to a user.
  • the user device 300 comprises for example one or more detectors, such as an ambient light detector (AMBIENT LIGHT DETECTOR) 308, a microphone (MICROPHONE) 310, and a location device (GPS) 312.
  • the detector of Ambient light 308 indicates the level of brightness to be used for the UI.
  • data from the microphone indicates whether the user is in a quiet environment such as a desk, or in a noisy environment such as public transport.
  • the GPS 312 can for example indicate the position of the user device and / or the speed with which the user moves, which could influence how the UI is generated for this user device.
  • the user device 300 may receive user interfaces, such as web pages, generated by the remote server 208.
  • user interfaces such as web pages
  • data captured by one or more of the detectors 308, 310, 312 are for example transmitted to the remote server 208 and used to define the profile of the device 300 stored in the memory 212.
  • the user device In addition or instead, the user device
  • the user device 300 can itself generate appropriate user interfaces.
  • the user device 300 comprises for example one or more memory devices (MEMORY) 314, which could be the same memory or a different memory of the instruction memory 306, and which for example memorize a user profile and / or device (USER / DEVICE PROFILE) 316 and transformations (TRANSFORMATIONS) used during the generation of the UI, as will be described in more detail below.
  • the user and / or device profile may include one or more readings from the detectors 308, 310 and 312.
  • the user and / or device profile may include other features.
  • these features may further be periodically transmitted to the remote server 208 to form the device profile associated with the user device 300.
  • FIG. 4A illustrates an exemplary graphical user interface 400, which is for example generated by the UI generation module 222, or by the processing device 304 of the user device 300.
  • the GUI 400 has for example the form of a web page in the HTML file format, or another appropriate programming language .
  • the GUI 400 is represented inside a boundary 401 representing the outer limit of the global UI window forming the GUI 400.
  • this global window 401 can be entirely visible on the display or only part of this window can be visible, and the user can navigate in the window 401, for example by causing scrolling using a mouse or by touching a touch screen.
  • the GUI 400 comprises for example elementary windows within the global GUI window, each elementary window comprising one or more interface elements such as titles, dialogs, buttons to click, etc.
  • the GUI provides, for example in response to a user request made using a separate web page, a list of cinemas in a 1 kilometer area around the user device. This is indicated in an elementary window 402, with the title "Cinemas within a radius of 1 Km”.
  • the GUI 400 comprises for example a dynamic content in a basic window 404, which for example indicates a list 406 of cinemas (CINEMA 1 to CINEMA J), a list 407 of the distances of each cinema with respect to the user, and a list 408 addresses of each cinema.
  • a dynamic content in a basic window 404 which for example indicates a list 406 of cinemas (CINEMA 1 to CINEMA J), a list 407 of the distances of each cinema with respect to the user, and a list 408 addresses of each cinema.
  • a movie ticket reservation form 410 is also for example provided on the GUI 400, allowing a user of the user device to book tickets online to go see a movie in one of the cinemas.
  • the form 410 comprises for example a basic window 412 repeating the list of identified cinemas, each provided with a selection box 413 allowing the user to select one cinemas.
  • a basic date and time entry window 414 allows the user to select a time and date for the movie.
  • An elementary window 416 provides a movie selection box for presenting, in response to the user typing one or more letters of the movie, a list of 417 available movies whose names begin with those letters.
  • a basic identification window 418 is also for example provided in the GUI 400, and consists of text entry boxes where the user can enter a user name and password identification. For example, by logging on to the website, prerecorded user account data, such as credit card details, can be retrieved to allow the purchase of a movie ticket.
  • each of the elementary windows 402, 404, 412, 414, 416 and 418 is generated based on features such as the dimensions of the display of the user device, because the display is a touch screen, whether or not a mouse is available, and / or the expertise of the user to perform this type of data entry. Further, although not shown in Fig.
  • the color and / or contrast of the GUI 400 are adapted based on the ambient light level detected by the user device.
  • the HTML file format may allow a brightness setting to be set to control the brightness of the display of the user device.
  • FIG. 4B illustrates an example of a variant of a date introduction elementary window 414 'that could be substituted for the elementary window 414 in a different version of the GUI 400.
  • the elementary date introduction window 414 of FIG. Figure 4A is suitable for advanced users, and allows to introduce a date and time.
  • the elementary date introduction window 414 ' is for example intended for less competent users, and allows only a selection of the date.
  • FIG. 4C illustrates examples of the implementation of the elementary identification window 418 that could be used in the GUI 400.
  • a basic window 420 in a minimum implementation includes only a text insertion box 422 allowing a user to enter identification data and another text input box 424 allowing a user to enter a password. user to enter a password, and a small button 426, that the user can click using a mouse, or touch on a touch screen, to submit the data that has been entered.
  • This implementation is for example suitable for a very small display, and for reasonably advanced users, since there is no indication of the data that is required in each text box.
  • a slightly larger basic window 430 implementing the identification window 418 includes the same elements as the implementation 420, but with the words "Identifier:” and "Password:” added. This implementation is for example suitable for less advanced users than for the window 420, but also requires a slightly larger display.
  • the elementary windows 440 and 450 provide progressively larger implementations of the identification window 418, containing the text insertion boxes 422, 424 and the button 426, both of which are set. work with the "Please identify yourself" statement, which makes these interfaces suitable for even less competent users.
  • the elementary window 450 further includes a company logo 452 and a background image 454, requiring a relatively large display screen.
  • Fig. 5A is a flowchart illustrating operations in a UI generation method according to an exemplary embodiment. These operations are for example carried out by the UI generation module 222 of FIG. 2, by executing software instructions stored in the instruction memory 226.
  • GUI 400 the concepts could include cinemas
  • a context model representing all the parameters to be taken into account during the adaptation process of the UI, such as the brightness, the screen size, the level of the user's view, etc .;
  • this model being for example a task model, representing the interface in the form of a series of tasks, an abstract UI model that represents the various workspaces in the IU and the possibilities of navigation between them, ie a concrete UI model that represents selected stakeholders, such as composite speakers (eg a panel ), or elementary speakers (eg a text field), workspaces of the abstract UI.
  • a task model representing the interface in the form of a series of tasks
  • an abstract UI model that represents the various workspaces in the IU and the possibilities of navigation between them
  • a concrete UI model that represents selected stakeholders, such as composite speakers (eg a panel ), or elementary speakers (eg a text field), workspaces of the abstract UI.
  • the level of abstraction of the UI model is detected.
  • each type of model is associated with a given meta-model describing the model, and the system is able to detect the type of model based on the meta-model.
  • the model is transformed into an abstract UI model, and the next operation is the operation 504.
  • This transformation of the model is for example performed using one or more transformations selected on the basis of the characteristics of the device, the user and / or the environment.
  • the model is transformed into a concrete UI model, and the next operation is Operation 505.
  • the transformation of the model is for example carried out using one or more transformations selected on the basis of the characteristics of the device, the user and / or the environment.
  • the model is transformed into code to execute the UI, for example in the HTML file format or similar.
  • the transformation of the model is for example carried out using one or more transformations selected on the basis of the characteristics of the device, the user and / or the environment.
  • Fig. 5B is a flowchart illustrating an example of operations in a method of generating the UI code at the global level, in other words for the global UI window, such as window 401 in the example of Fig. 4A .
  • one or more transformations on the overall UI window are selec ⁇ tioned.
  • the at least one transform transforms at least one model defining the UI into UI code to generate a global UI window having particular dimensions, a particular color model, a particular arrangement of elementary windows, and / or other characteristic elements. The selection of the transformation or transformations will now be described in more detail.
  • a global GUI code header representing the GUI is generated.
  • the body of the global GUI code is generated using said one or more selected transformations.
  • the body is generated by the execution of one or more elementary tasks to generate each elementary window. These basic tasks are called child elements.
  • an operation 510 it is determined whether there is a child element to be processed. If so, the next operation is operation 511, in which the code of the child element is generated, as will be described with reference to FIG. 5C. The method then returns to the operation 510. In the other case, if all the child elements have been processed, the next operation is an operation 512 in which a termination of the global GUI code is generated in order to complete the representation of the child. GUI code.
  • the next operation is an operation 515, in which the file comprising the generated code is transmitted to a user device for display.
  • Fig. 5C is a flowchart illustrating an example of operations for implementing operation 511 of Fig. 5B to generate the code for a child element.
  • one or more transformations are selected to generate the code of a window elementary GUI, based on the content to be displayed, and the characteristics of the user profile and / or the device and / or the environment (brightness, noise, etc.) - For example, for at least some of the windows In the basic elements of the user interface, there are a plurality of potential transformations that can be used to generate the elementary window having elements adapted to certain characteristics of the user device, the environment and / or the user. Selecting a conversion may involve a calculation of a distance representative of the extent to which each processing is consistent with the charac teristics ⁇ , optionally with the application of a different weight to each characteristic. An exemplary method for selecting a transformation will be described in more detail below.
  • a GUI code element body is then generated using one or more selected transformations.
  • an operation 519 it is determined whether there is a child element to be processed. If so, the next operation is operation 520, in which the code of the child element is generated. Then return to operation 519. In the other case, if all the child elements have been processed, the next operation is the operation 521, in which a GUI code element termination is generated in order to complete the code representation of the child element of the global GUI.
  • Figure 6 illustrates an example of a 3D feature space, in which a USER EXPERTISE level is represented on the x-axis, a level of Ambient light (LIGHT LEVEL) is shown on the y-axis, and the display size (DISPLAY SURFACE) is shown on the z-axis.
  • LIGHT LEVEL level of Ambient light
  • DISPLAY SURFACE display size
  • a first transformation leads to an elementary component of UI which is suitable for feature levels falling in a volume VI of FIG. 6
  • a second transformation leads to an elementary component of UI which is suitable for characteristic levels falling into a volume V2 of Figure 6
  • a third transformation leads to an elementary component of UI which is suitable for feature levels falling in a volume V3 of Figure 6.
  • the UI generation module 222 selects for example the transformation associated with the volumes VI, V2 and V3 on the basis of a calculation. distance from each volume. Examples of distance calculations will now be described in more detail with reference to Figs. 7A, 7B and 7C.
  • FIG. 7A is a diagram illustrating the case of one-dimensional volumes VI and V2 for a single feature, each volume corresponding to a given TRANSFORMATION ⁇ mation.
  • the distance (C, V) of a point C with respect to a volume V is for example void if the point C falls within the volume, in other words if Vi m j_ n ⁇ C ⁇ V max, where the volume Vi has lower and upper limits Vi m -j_ n and Vi max respectively. This is the case for point C1 in FIG. 7A, which falls in volume VI.
  • the volume with the shortest distance is selected, which for the points C2 and C3 is the volume V2.
  • Figure 7B illustrates another example of one-dimensional volumes VI and V2, but for a characteristic defined by discrete values.
  • the value is the skill level of the user, which is for example one of the following five values in order: novice; beginner ; competent; powerful; and expert.
  • d (C2, Vi) min (
  • ) is applied, for example.
  • the distance is for example equal to 0 if the volume and the point have the same value, and equal to 1 if the volume and the point have different values.
  • the distance will be equal to 0 if the device user has a positioning system, and equal to 1 otherwise.
  • Figure 7C illustrates an example of a case in which distances must be calculated in a two-dimensional space on the basis of characteristics K1 and K2.
  • the volumes VI and V2 are for example defined by:
  • V2 ⁇ K1 e [K1 v2min , K1 v2max ], K2 e [K2 v2min , K2 v2max ]>
  • a point C1 falls in volume VI, and thus its distance from this volume is equal to 0.
  • point C2 is in the range of volume VI with respect to the characteristic Kl, but not with respect to the K2 feature.
  • Point C3 is not in the volume ranges VI or V2 for any of the characteristics K1 and K2.
  • Each of the distances between C2 and C3 and the volumes VI and V2 is for example defined as the smallest length of a straight line joining a point situated in the volume Vi at the point C:
  • d (C, Vi) V (d K1 (C, Vi) 2 + d K2 (C, Vi) 2 )
  • the values of the characteristics K1 and K2 have been normalized with respect to each other, for example on a scale of 0 to 100, where 0 corresponds to the lowest value K m -j_ n of the characteristic K, and 100 corresponds to the highest value K max of the characteristic K.
  • the distance to a volume Vi can thus be defined by:
  • certain features may be weighted to have different importance.
  • the ambient light conditions may vary only relatively little and be of relatively low importance.
  • ambient light conditions can be of great importance, and thus be weighted accordingly.
  • a weighting coefficient ⁇ ⁇ is thus for example added to the formula, which becomes the following formula:
  • selecting certain volumes for certain track characteristics may be completely prevented. For example, it may not be possible for a certain elementary window associated with a certain volume to be applied to a display screen that is larger than a certain size.
  • Lim m -j_ n is the lowest value of a characteristic K for which the volume V can be selected
  • Lim max is the highest value of the characteristic K for which the volume V can be selected.
  • only the lower limit Lim m -j_ n or only the upper limit Lim max could be provided.
  • Fig. 8 is a flowchart showing an example of operations in a method for creating models and transformations for generating an elementary window according to an exemplary embodiment. These operations are for example performed by a designer during a design phase.
  • a set of n relevant characteristics ⁇ K-j_ ⁇ n is identified .
  • this operation involves determining, for the given content to be displayed, which relevant features may affect how the content is displayed. For example, when the number of items to be displayed is greater than a certain number, the size of the display of the user device may become relevant to decide how to represent that content.
  • each characteristic can take one of the following forms:
  • weights 73 ⁇ 4- ⁇ are defined for each characteristic. Weights are defined based on the content. For example, depending on the content to be displayed, the size of the display of the user device may be of high importance when defining the UI.
  • a plurality of magnetic volumes Vi is defined, for example by subdividing each characteristic range into two or more sub-ranges, each magnetic volume corresponding to a vector of a combination of selected sub-ranges.
  • conditions are defined for an effective operation of each UI in order to specify the functional requirements of the UI and / or the elementary components of the UI. For example, if the UI displays the current temperature, it needs a connection to a temperature sensor to get temperature readings. If this connection is lost, the UI can not function properly, and for example it produces a reaction such as displaying a warning or error message.
  • Such functional conditions and such reactions can be defined at the level of the IU or the elementary component level.
  • one or more models and one or more transformations are designed and generated or otherwise created to generate an elementary UI window associated with each volume.
  • transformations that include instructions used by the UI generation module or by a user device during the generation of a UI, are created by a designer.
  • task, domain, and context templates are created by a designer, and these templates are also used. during the generation of the UI.
  • the context model can be filled by a designer based on user characteristics, or by programs and / or sensors, for example based on geolocation.
  • Other models, such as the abstract UI model and the concrete UI model can be generated automatically based on the task model.
  • Figure 9A is a flowchart illustrating operations in a method of selecting transformations to generate a UI consisting of one or more elementary windows. This method is for example carried out during the operation 516 of FIG. 5C.
  • a "getTransformation” function is called, with as input parameters the current context C, the magnetic volumes V, and the context characteristics K with their associated weights n Ki .
  • a variable “minDistance” is set to infinity
  • a result value “Transformation” of the function is set to zero
  • a variable v is set to 0.
  • an operation 904 it is determined whether the variable v is smaller than Card (V), in other words the number of magnetic volumes. If the answer is no, operations 905 to 908 are performed.
  • a distance is calculated by calling another function "magneticDistance", with as input parameters the current context C, the volume V [v], and the context characteristics K.
  • the operation 906 it is determined whether the distance determined in the operation 905 is smaller than the value of the variable minDistance. If so, the next operation is the operation 907, in which the minDistance variable is set equal to the distance value, and the value of "Transformation” is set equal to the transformation associated with the volume V [v].
  • the operation 908 in which the variable v is incremented, then it returns to operation 904.
  • the operation after the operation 904 is an operation 909, in which the value of the variable "Transformation" is returned as a result.
  • FIG. 9B illustrates an example of operations implementing the distance calculation of operation 905 of FIG. 9A.
  • variable "distance" is set to 0, and a variable i is set to 0.
  • operation 912 it is determined if i is less than n. If yes, the next operation is operation 913, in which the distance is calculated by:
  • distance distance + (Ck ⁇ Kyi mj _ n &&Ck ⁇ Ky; max ?
  • operation 915 the next operation is operation 915, in which the square root of the value of the distance is returned as a result.
  • Fig. 10A is a flowchart illustrating an example of operations in a method of adapting a UI based on a context of usage changes occurring during the display of a UI on a user device. For example, although the characteristics of the device utili ⁇ sateur are unlikely to change, some features of the environment such as the ambient light level or background noise might change as the UI is displayed. The method of Figure 10A allows the UI to be adapted based on such a change.
  • the current context is monitored, and in the case of change, the following operation is the operation 1002.
  • the operation 1002 is also for example carried out if in an operation 1003 a user requests to navigate to a UI which must be generated, or if in an operation 1004 a faulty operation is detected.
  • the operation 1002 it is determined whether there is a pre-existing UI adapted to the new current context. For example, in some embodiments, a limited number of the most common IUs may be generated in advance and stored in memory. In addition or instead, following the generation of a given UI, the code can be maintained for a certain time in the case where another user device has the same context and requests the same UI.
  • the check in operation 1002 includes, for example, a distance calculation similar to that described in relation to the aforementioned FIGS. 9A and 9B, but in which it is recognized that a UI is associated with a volume, rather than transformations. If in an operation 1002 a UI is found, the next operation is the operation 1005, in which this UI is considered to be code to execute, after compilation if necessary. The UI, called magnetic UI in FIG. 10A, is thus transmitted to the user device and executed by it.
  • an operation 1006 it is determined whether there is a similar UI, i.e. a UI generated for a context similar to the new context current, and which can be adapted on the basis of the current context.
  • a similar context is for example defined as a context sharing the same value of at least one of its characteristics with the new current context.
  • operation 1006 If in operation 1006 there is no similar UI, in an operation 1007, the UI is generated using, for example, the method described in connection with FIGS. 5A, 5B and 5C, then the process proceeds to operation 1005.
  • the similar UI is for example adapted on the basis of the new current context. This implies, for example, the determination of the transformations used for the generation of the similar UI, and the determination that one or more of the transformations should be replaced by one or more new transformations in the light of the new current context. For example, based on the differences between the context associated with the similar context and the new context, it could be determined that one or more of the transformations selected for the similar UI are not well adapted and need to be replaced. New selections are for example made for only these transformations.
  • the selected transformations can then be used to generate an adapted UI, and then the process proceeds to an operation 1014 of Figure 10C described in more detail below.
  • An advantage of the adaptation of a similar UI to the new current context is that only a moderate change in the UI results, and the selection of at least one of the previously selected transformations for the similar UI should not be repeated.
  • the adaptation of the UI according to the context in the operations 1002, 1005 and 1006 is performed globally on the UI, rather than at the server level or on the server. user device.
  • the adaptation of the UI code based on the modified characteristics is a global adaptation of the UI code including the regeneration of the entire code of the UI.
  • the adap ⁇ tation of the UI according to the context in the operations 1002, 1005 and 1006 may be performed locally, in other words on only a portion of the UI, regenerating at the server level only a part of the code of the UI (for example when parts of the UI can no longer be displayed) or by modifying locally, at the server or on the user device, the code of the UI 'UI (for example when the color of the text is set to red).
  • the operation 1001 involves the identification, by the processor 224, of one or more portions of the UI code to be adapted based on the modified context.
  • operations 1002, 1005 and 1006 only said one or more identified portions of the code of the UI are then adapted. Local adaptation is advantageous since it can be performed faster than a global adaptation of the IU, and / or involves reduced processing resources.
  • Fig. 10B is a flowchart illustrating the context monitoring operation 1001 of Fig. 10A in more detail according to an exemplary embodiment.
  • the usage context C is captured from the user device.
  • the context for use C is for example defined by n context values ⁇ Ci ⁇ n .
  • an operation 1028 it is checked whether the use context C has changed with respect to the previously conserved value. If it is not the case, the process returns to the operation 1027. By cons if the context has changed, the next operation is the operation 1029.
  • operation 1029 it is determined whether the change in context requires adaptation of the UI. For example, a calculation is made to determine whether the transformations to be selected based on the context values are identical to the transformations selected when the IU was last generated. If they are identical, the method returns to operation 1027. On the other hand, if one or more of the transformations have changed, an adaptation is considered to be required, and the process proceeds to operation 1002 of FIG. 10A.
  • Fig. 10C is a flowchart illustrating in more detail operation 1005 of executing the UI, according to an exemplary embodiment.
  • an operation 1010 it is determined whether the code of the UI is executable. If the answer is no, in an operation 1011, the system identifies the programming language used in the UI, then, in an operation 1012, it is determined whether the language requires compilation or not. If the answer is yes, the file is compiled in an operation 1013.
  • End User in other words the code to execute on the user device.
  • Figure 10C is based on the case of a global adaptation of the UI, local adaptation could be achieved as described previously, either at the server either on the user device.
  • the operations 1010 to 1014 are for example carried out for each elementary component of the UI that must be adapted.
  • Fig. 10D is a flowchart illustrating the operation 1004 of Fig. 10A in more detail according to an exemplary embodiment.
  • the example of FIG. 10D corresponds for example to a centralized approach implemented by the UI generation module 222 of FIG. 2.
  • conditions during the execution of a current UI are for example examined to determine, in an operation 1016, whether there are unfilled conditions.
  • the unsatisfied conditions correspond, for example, to one or more missing input values to be displayed by the UI. If the answer is no, the process returns to step 1015.
  • one of a plurality of reactions is selected, comprising for example: an operation
  • Fig. 10E is also a flowchart illustrating in more detail operation 1004 of Fig. 10A, and elements similar to those of Fig. 10D have been shown with the same reference numerals and will not be described again in detail.
  • Figure 10E corresponds to a distributed approach, wherein at least a portion of the method is performed at user devices. For example, operations 1015 and 1016 are performed at the user device.
  • the next operation is the operation 1022, wherein the user device determines the reaction which is for example to change the style of the UI in a operation 1022, for example by displaying a form of warning sign on the display of the device of the user, or to transmit a report to the server 208 in an operation 1023.
  • the server for example implements operation 1017 and implements one or more of the operations 1018, 1019 and 1020 before performing the operation 1002.
  • An advantage of the embodiments described herein is that, by generating a user interface adapted to features associated with a user, one or more user devices, and / or the environment, the interface may be adapted to specific usage contexts, without the need to create in advance, maintain and store all available UI versions. Indeed, as previously described, the number of versions increases exponentially with the number of different characteristics of users, devices and / or environment to consider, which makes it quickly unfeasible to create and memorize each version.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • User Interface Of Digital Computer (AREA)

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 œuvrel'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 D'UNE INTERFACE
D'UTILISATEUR
La présente demande de brevet revendique la priorité de la demande de brevet français FR15/56433 qui sera considérée comme faisant partie intégrante de la présente description.
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 1 ' art antérieur
Les interfaces utilisateurs comprennent des dispo- sitifs 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'infor¬ mation, un composant essentiel de l'interface utilisateur est l'interface utilisateur graphique (GUI), qui est affichée sur un afficheur d'un dispositif d'utilisateur. Le dispositif d'utili¬ sateur 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 1' 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 à un 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 l'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 un contexte courant défini par 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 capable de sélectionner un UI adapté parmi des UI prédéfinis le cas échéant, ou, à défaut, de 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 des caractéristiques, lesdites une ou plusieurs premières transformations étant adaptées à transformer au moins un modèle définissant une première portion de l'interface utilisateur en ladite première portion du code UI ; 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, lesdites ou plusieurs deuxièmes transformations étant adaptées à transformer au moins un modèle définissant une deuxième portion de l'interface utilisateur en ladite deuxième portion du code UI .
Selon un mode de réalisation, le dispositif de traitement est adapté en outre à calculer une distance entre le contexte courant et un contexte associé avec un ou plusieurs autres codes UI générés précédemment, et à sélectionner l'un des autres codes UI selon cette distance.
Selon un mode de réalisation, le dispositif de traitement est adapté en outre à générer le code UI sur la base d'une ou plusieurs transformations supplémentaires sélectionnées précédemment pour la génération d'une interface utilisateur adaptée à un contexte précédant similaire au contexte courant.
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'utili¬ sateur ; 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 corres¬ pondante 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 UI 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 l'équation suivante :
d{C,V) =
n
y min(|Kic - Kivimin|, |Kic - Kivimax
[(Kic > Kivimin Λ Kic≤ Kivimax) ? 0 : nKi-
1=1 où le symbole "Λ" représente un "ET" logique, l'opérateur "?" désigne une condition si/sinon de telle sorte que l'expression (x)?0: (y) implique que si la condition x est vraie, alors le résultat est égal à 0, sinon il est égal à y, Kiç 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=<Kle [Klvimin,Klvimax] ...Kne [ nvimin, Knvimax] >, et chaque caractéristique Ki est associée à une valeur maximum Kimax et une valeur minimum Kim-j_n, et nKi 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 1 ' 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, lesdites une ou plusieurs premières transformations étant adaptées à transformer au moins un modèle définissant une première portion de l'interface utilisateur en ladite première portion du code UI ; 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, lesdites une ou plusieurs deuxièmes transformations étant adaptées à transformer au moins un modèle définissant une deuxième portion de l'interface utilisateur en ladite deuxième portion du code UI ; et exécuter le code UI par le dispositif d'utilisateur.
Selon un mode de réalisation, le procédé comprend en outre le calcul d'une distance entre le contexte courant et un contexte associé avec un ou plusieurs autres codes UI générés précédemment, et la sélection de l'un des autres codes UI selon cette distance.
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 inter¬ active .
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 : électricien, 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, au sens de l'Ingénierie Dirigée par les Modèles et 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'un 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'ins¬ tructions (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 de 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' intro- duction 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 progressivement de plus en plus grandes de la fenêtre d'identification 418, contenant les boîtes d' intro- duction 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 5A 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 plusieurs transformations, une ou plusieurs des transformations étant sélectionnées pour générer le code UI, et au moins un modèle définissant l'interface utilisateur, ce modèle étant par exemple soit un modèle en tâches, représentant l'interface sous forme d'une série de tâches, soit un 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ù ledit au moins un 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. Cette transformation du modèle est par exemple réalisée en utilisant une ou plusieurs transformations sélectionnées sur la base des caractéristiques du dispositif, de l'utilisateur et/ou de l'environnement.
Dans le cas où ledit au moins un 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. Là encore, la transformation du modèle est par exemple réalisée en utilisant une ou plusieurs transformations sélectionnées sur la base des caractéristiques du dispositif, de l'utilisateur et/ou de l'environnement.
Dans le cas où ledit au moins un 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. Là encore, la transformation du modèle est par exemple réalisée en utilisant une ou plusieurs transformations sélectionnées sur la base des caractéristiques du dispositif, de l'utilisateur et/ou de l'environnement.
La génération de code de l'opération 505 sur la base des transformations sélectionnées lors des opérations 503, 504 et/ou 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 l'exemple de la figure 4A.
Dans une opération 506, une ou plusieurs transformations concernant la fenêtre UI globale sont sélec¬ tionnées. Par exemple, la ou les transformations transforment au moins un modèle définissant l'UI en code UI pour générer 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 de la transformation ou des transformations 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 transfor- mations sont sélectionnées afin de générer le code d'une fenêtre élémentaire du GUI, sur 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 l'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'utili- sateur (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 transfor- mation 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 transfor¬ mation 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 Vimj_n<C<Vimax, où le volume Vi a des limites inférieure et supérieure Vim-j_n 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) =V2m-j_n-C2, en d'autres termes, d (C2, Vi) =min (|C2- viminUc2-vimaxD ·
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 l'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-Vimj_n|, |C2-Vimax|) , 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 bi- dimensionnel sur la base de caractéristiques Kl et K2. Les volumes VI et V2 sont par exemple définis par :
VI : <K1 e [Klvlmin, Klvlmax] , K2 e [K2vlmin, K2vlmax] >
V2 : <K1 e [Klv2min, Klv2max] , K2 e [K2v2min, K2v2max] >
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 Km-j_n 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=<ke [ν^ίη,ν^χ] >, pour une caractéristique K= [Kmj_n, Kmax] est ainsi :
d (C, V) = / (Kmax-Kmin) où le symbole "Λ" représente un "ET" logique, et l'opérateur "?" désigne une condition si/sinon de telle sorte que l'expression (x)?0: (y) implique que si la condition x est vraie, alors le résultat est égal à 0, sinon il est égal à y.
Pour un espace multidimensionnel dans lequel il y a n caractéristiques Ki, et dans lequel C est un point correspondant à des valeurs courantes Kiç de chacune des caractéristiques Ki, la distance à un volume Vi peut ainsi être définie par :
d(C,V) =
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=<Vm-j_n, Vmax, Limm-j_n, Limmax>, où Limm-j_n est la valeur la plus faible d'une caractéristique K pour laquelle le volume V peut être sélectionné, et Limmax 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 Limm-j_n ou seule la limite supérieure Limmax 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 {K-j_}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 jmj_n et jmax, est récupérée ou définie pour chaque caractéristique, comme cela est représenté par {<Kj_, jmj_n,K;max>}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 7¾-ί_ pour chaque caractéristique. Les poids sont définis sur la base du contenu. Par exemple, en fonction du contenu à afficher, la taille de l'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émen- taires . 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 trans- formations 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, l'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, 7¾>}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≥Kyimj_n&&Ck≤Ky;max?
0:
(Ck≥LimVImin&&Ck≤LimVImax?
+∞ :
7¾*min (|Ci-KVImin|, |Ci-KVImax|) / (KImax-
Klmin) 2 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 UI 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'utili¬ sateur 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 un 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 du code à exécuter, après compilation si nécessaire. L'UI, appelé UI magnétique en figure 10A, est ainsi transmis vers le dispositif d'utilisateur et exécuté par celui-ci .
De façon alternative, si aucun UI n'est trouvé dans l'opération 1002, dans une opération 1006, il est déterminé s'il existe un UI similaire, c'est-à-dire un UI généré pour un contexte similaire au nouveau contexte courant, et qui peut être adapté sur la base du contexte courant. Un contexte similaire est par exemple défini comme un contexte partageant une même valeur d'au moins une de ses caractéristiques avec le nouveau contexte courant.
Si dans l'opération 1006 il n'existe pas d'UI similaire, dans une opération 1007, 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.
Si toutefois, dans l'opération 1006, il est déterminé qu'il existe un UI similaire, dans une opération 1008, l'UI similaire est par exemple adapté sur la base du nouveau contexte courant. Ceci implique par exemple la détermination des transformations utilisées pour la génération de l'UI similaire, et la détermination qu'une ou plusieurs des transformations devraient être remplacées par une ou plusieurs nouvelles transformations au vu du nouveau contexte courant. Par exemple, sur la base des différences entre le contexte associé au contexte similaire et le nouveau contexte, il pourrait être déterminé qu'une ou plusieurs des transformations sélectionnée pour l'UI similaire ne sont pas bien adaptées et doivent être remplacées. Des nouvelles sélections sont par exemple réalisées pour uniquement ces transformations. Les transformations sélectionnées peuvent ensuite être utilisées pour générer un UI adapté, puis le procédé passe à une opération 1014 de la Figure 10C décrite plus en détail dans la suite. Un avantage de l'adaptation d'un UI similaire au nouveau contexte courant est qu'il en résulte uniquement une modification modérée de l'UI, et la sélection d'au moins une des transformations sélectionnées précédemment pour l'UI similaire ne doit pas être répétée.
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'adap¬ tation 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 1027, 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 1028, 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 1027. Par contre si le contexte a changé, l'opération suivante est l'opération 1029.
Dans l'opération 1029, 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 1027. 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, le système identifie le langage de programmation utilisé dans l'UI, puis, dans une opération 1012, on détermine si le langage nécessite ou pas une compilation. Si la réponse est oui, le fichier est compilé dans une opération 1013. L'opération après 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, appelé FUI magnétique en figure 10C, est considéré comme étant une Interface
Utilisateur Finale (FUI), en d'autres termes du code à exécuter 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 une opération 1017, on sélectionne l'une d'une pluralité de réactions, comprenant par exemple : une opération
1018 dans laquelle un UI alternatif est affiché ; une opération
1019 dans laquelle un autre utilisateur, comme un 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

REVENDICATIONS
1. Système pour sélectionner, adapter ou 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 un contexte courant défini par 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 1 ' 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, lesdites une ou plusieurs premières transformations étant adaptées à transformer au moins un modèle définissant une première portion de l'interface utilisateur en ladite première portion du code UI ;
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, lesdites une ou plusieurs deuxièmes transformations étant adaptées à transformer au moins un modèle définissant une deuxième portion de l'interface utilisateur en ladite deuxième portion du code UI ; et
en assemblant au moins les première et deuxième portions pour générer le code UI .
2. Système selon la revendication 1, dans lequel le dispositif de traitement est adapté en outre à calculer une distance entre le contexte courant et un contexte associé avec un ou plusieurs autres codes UI générés précédemment, et à sélectionner l'un des autres codes UI selon cette distance.
3. Système selon la revendication 1 ou 2, dans lequel le dispositif de traitement (224, 304) est adapté en outre à générer le code UI sur la base d'une ou plusieurs transformations supplémentaires sélectionnées précédemment pour la génération d'une interface utilisateur adaptée à un contexte précédant similaire au contexte courant.
4. Système selon l'une quelconque des revendications 1 à 3, 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.
5. Système selon l'une quelconques des revendications 1 à 4, 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'utili¬ sateur 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.
6. Système selon la revendication 5, 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.
7. Système selon l'une quelconque des revendications 1 à 6, dans lequel l'UI est une interface audio.
8. Système selon l'une quelconque des revendications 1 à 7, 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.
9. Système selon la revendication 8, 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.
10. Système selon l'une quelconque des revendications 1 à 9, 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 .
11. Système selon l'une quelconque des revendications 1 à 10, 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.
12. Système selon la revendication 11, 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 .
13. Système selon la revendication 12, 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.
14. Système selon l'une quelconque des revendications 1 à 13, 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ù le symbole "Λ" représente un "ET" logique, l'opérateur "?" désigne une condition si/sinon, Kiç 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=<Kle [Klvimin,Klvimax] ...Kne [Knvimin, Knvimax] >, et dans lequel chaque caractéristique Ki est associée à une valeur maximum Kimax et une valeur minimum Kim-j_n, et nKi est un coéfficient de pondération.
15. Système selon l'une quelconque des revendications 1 à 14, mis en œuvre :
dans le dispositif d'utilisateur ; et/ou
dans un serveur distant (208) agencé pour communiquer avec le dispositif d'utilisateur par l'intermédiaire d'un ou plusieurs réseaux intermédiaires (110) .
16. 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'utili¬ sateur, à un ou plusieurs utilisateurs du dispositif d'utilisateur et/ou à l'environnement du dispositif d'utilisateur, lesdites une ou plusieurs premières transformations étant adaptée à transformer au moins un modèle définissant une première portion de l'interface utilisateur en ladite première portion du code UI ;
- 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, lesdites une ou plusieurs deuxièmes transformations étant adaptée à transformer au moins un modèle définissant une deuxième portion de l'interface utilisateur en ladite deuxième portion du code UI ; 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.
17. Procédé selon la revendication 16, comprenant en outre le calcul d'une distance entre le contexte courant et un contexte associé avec un ou plusieurs autres codes UI générés précédemment, et la sélection de l'un des autres codes UI selon cette distance.
18. Procédé selon la revendication 16 ou 17, 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 .
19. Procédé selon l'une quelconque des revendications 16 à 18, 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 .
20. 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 16 à 19.
EP16750941.3A 2015-07-07 2016-07-07 Systeme et procede pour l'adaptation d'une interface d'utilisateur Withdrawn EP3320419A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1556433A FR3038744B1 (fr) 2015-07-07 2015-07-07 Systeme et procede pour l'adaptation magnetique d'une interface d'utilisateur
PCT/FR2016/051742 WO2017006066A1 (fr) 2015-07-07 2016-07-07 Systeme et procede pour l'adaptation d'une interface d'utilisateur

Publications (1)

Publication Number Publication Date
EP3320419A1 true EP3320419A1 (fr) 2018-05-16

Family

ID=54848665

Family Applications (1)

Application Number Title Priority Date Filing Date
EP16750941.3A Withdrawn EP3320419A1 (fr) 2015-07-07 2016-07-07 Systeme et procede pour l'adaptation d'une interface d'utilisateur

Country Status (3)

Country Link
EP (1) EP3320419A1 (fr)
FR (1) FR3038744B1 (fr)
WO (1) WO2017006066A1 (fr)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7412658B2 (en) * 2002-11-14 2008-08-12 Sap Ag Modeling system for graphic user interface
US8276069B2 (en) * 2007-03-28 2012-09-25 Honeywell International Inc. Method and system for automatically generating an adaptive user interface for a physical environment
FR2985336B1 (fr) * 2011-12-29 2016-08-26 Thales Sa Procede de simulation de l'interface homme-machine d'un appareil

Also Published As

Publication number Publication date
FR3038744B1 (fr) 2017-08-11
WO2017006066A1 (fr) 2017-01-12
FR3038744A1 (fr) 2017-01-13

Similar Documents

Publication Publication Date Title
US10956128B2 (en) Application with embedded workflow designer
CN108292206B (zh) 具有易于使用特征的工作流开发系统
US8966405B2 (en) Method and system for providing user interface representing organization hierarchy
CN102483698B (zh) 动态web应用的客户端层验证
US20120166522A1 (en) Supporting intelligent user interface interactions
US20130212534A1 (en) Expanding thumbnail with metadata overlay
US20170255445A1 (en) Translation of natural language into user interface actions
KR102518172B1 (ko) 컴퓨팅 시스템에서 사용자 어시스턴스를 제공하기 위한 장치 및 방법
WO2013140076A2 (fr) Procede et systeme de developpement d&#39;applications de consultation de contenus et services sur un reseau de telecommunciation
CN102124460B (zh) 用于网站地图的标准模式和用户界面
US10997359B2 (en) Real-time cognitive modifying a mark-up language document
US20080288865A1 (en) Application with in-context video assistance
EP2187321B1 (fr) Procédé et dispositif d&#39;édition d&#39;un objet représenté dans une page web
Rodrigues et al. New trends on ubiquitous mobile multimedia applications
US20190250999A1 (en) Method and device for storing and restoring a navigation context
US20230247102A1 (en) Addressing previous client device technology in online platforms
US20210027643A1 (en) Augmented reality tutorial generation
US20210342130A1 (en) Systems and methods for software application generation and delivery
WO2017006066A1 (fr) Systeme et procede pour l&#39;adaptation d&#39;une interface d&#39;utilisateur
US20140237368A1 (en) Proxying non-interactive controls to enable narration
US20150378530A1 (en) Command surface drill-in control
US20230269322A1 (en) Cross-channel configurable navigation
US20220180452A1 (en) Automated Web Content Publishing
Delfos et al. Enhancing accessibility to web mapping systems with technology-aligned adaptive profiles
US20190102065A1 (en) Interaction personalization system and method

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20180116

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20190619

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20191030