Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F8/00—Arrangements for software engineering
  • G06F8/10—Requirements analysis; Specification techniques
• • 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 invention relates to a method of augmenting a task model to allow the management of human-machine interaction.
• the model of the user's task is buried within the interface.
• the task that the user must perform is not explicitly defined, but is implicitly found in the design of the interface.
• the interface designers define, according to the specifications, the more or less strict sequences which are authorized to the user. These sequences implicitly define his task model. This absence of an explicit definition of a user's task model results in a strong staticity of the user's task. If the user's mission changes or if the interface must be deployed for a class of users with a partially different mission, modifications are necessary on the interface.
• Some interfaces are designed taking into account this modification perspective and can be configured to be adapted to a different task.
• This practice imposes a heavy workload to design an interface open enough to allow different configurations.
• the interface configuration for a new task remains complex insofar as the configuration requires the joint work of an expert in the field to specify the new task and of an interface designer.
• This practice already relatively expensive, becomes particularly difficult to implement if the user's task is likely to evolve during a session, which requires modifying the application containing the task model.
• the subject of the present invention is a method of augmenting a task model allowing real-time management of the man-machine interaction without having to modify the application linked to this task model, in particular when one evolves task models, interaction can be multi-user.
• the method according to the invention is characterized in that from an existing task model, it is increased with the current state of the user in his task, the events allowing a change of state are described of the user, and for an event occurring during a state of the user, the interaction to be performed with the user to manage this event is described.
• the list of constraints necessary to trigger the interaction is added before each interaction procedure, and, also advantageously, the values that this interaction must provide according to the result of l are added after each interaction procedure. interaction and which must be presented to the user in return.
• FIG. 1 is a simplified diagram explaining different stages of the implementation of the method of the invention in an application
• - Figure 2 is a simplified block diagram of the architecture of a task manager according to the invention
• - Figure 3 is a simplified diagram of the workflow of the task manager of the invention.
• the method of the invention essentially consists in relieving designers of human-machine interfaces from the question of the task of the user.
• the designers will only have to focus on the interface functionalities that the user needs without worrying about the sequences that he will have to achieve to carry out his task.
• the invention starts from an existing external task model and extends it so that it can be used to steer the interaction.
• this model serves as a basis of specification for interface designers to find out the services necessary for users.
• this external task model is used by a task manager which is capable of taking into account in real time any change in the task model during the execution of the task.
• the invention described here specifies and implements responses to the problems posed by the need for development and configuration of the interfaces following modifications of the user's task or following a deployment request intended for other users. with a different task.
• this invention has repercussions on all categories of systems where humans hold a preponderant place, and this in all kinds of fields of application, such as for example: • Defense: weapons, command systems , simulation and training; • Transport: steering, supervision and reservation systems; • Communications: telephony, radio, television, Internet; • Daily life: household appliances, individual vehicles, ubiquitous and diffuse household computing ("ubiquitous Computing" in English); • Services: banking systems, electronic commerce, technical assistance; • Health: hospital systems, operational assistance; • Etc.
• the present invention provides a new method for augmenting an existing task model to allow real-time management of the interaction driven by the task model. Its fundamental principle is to use an existing user task model and to augment it with the knowledge necessary to steer the interaction.
• the operator's task model includes, in addition to the sequence of tasks to be performed, the events that can occur, the description of the interactions to be performed, the necessary trigger conditions and the information to be provided in return.
• This augmented task model makes it possible to control the interaction in real time thanks to an additional component, the task manager, which provides access services to the task model.
• the task model as knowledge external to the interaction is dynamic.
• the task manager authorizes an evolution of the task model over time with real-time repercussions on the interaction with the user.
• a task template describes the different steps that a user can or must take to complete their overall task.
• the user's task must be described in the form of an alternative, sequential or parallel sequence of subtasks with a specific mention for the initial state.
• the subtasks performed by the user correspond to as many states in which the user is (in a state to perform a subtask).
• the first step of the method of the invention starts from an existing task model provided by an expert, and it consists in increasing this representation with the current state of the user in his task. This additional knowledge makes it possible to follow the user in his task.
• the second step consists in describing the events allowing a change of state of the user (end of a subtask to start another). These events can be user-initiated events or external events that have occurred in the environment.
• the environment is defined here as everything except the user: the application (s), other users, sensors, ... This process thus adds to each transition between two user states the list of one or more events triggering the change of state.
• the events entered in the task model can be of more or less fine granularity depending on the needs.
• an external module is used which supplies the events (it is "used” in the sense of a customer using a supplier).
• This module is any kind of human-machine interface (IT or not), ⁇ can, for example, be a weight sensor on a seat that provides a "seated” event.
• This module provides an abstraction of user actions in the form of high-level events. This abstraction allows the same event to be used in the task model regardless of how the user interacted with the system (vocally, graphically, by gesture, ). It is also possible to use low-level events in the task model.
• low-level and high-level events are the generalization of one or more low-level events.
• the high-level event is the generalization of one or more low-level events.
• the third step consists in describing, for an event that occurred during a user state, the interaction to be performed with the user to manage this event.
• Interaction is defined as a procedure to be carried out (interrogation of applications, calculation of a value, verification of data, ).
• the task model can refer to several different applications.
• the user has a single interface, and it is then the interaction procedures which are responsible for accessing the necessary applications.
• Each interaction procedure must provide a result making it possible to decide the next state of the user.
• a transition labeled by the result makes it possible to reach a new state of the user. For example, in the case where the user is in the “disconnected” state and that he triggers a “connection” event, the interaction procedure, after interrogating the application, provides a polar response (yes / no).
• the fourth step consists in adding before each interaction procedure the list of constraints necessary to trigger the interaction. These constraints can be the supply of parameters, the verification of a value, ... (In the previous example, the constraint could be the supply of an identifier and a password.)
• the last step consists in add after each interaction procedure the values that this interaction must provide according to the result of the interaction and which must be presented to the user in return.
• the method of the invention clearly identifies the actions to be performed by the user as well as their sequencing, the events being able to be triggered or perceived by the user as well as the interactions (in the sense of the task) with the environment.
• a task model thus augmented can be presented in the form of a graph.
• the formalism used for this graph must offer sufficient expression power to express the states (subtasks) of the user, the constraints to be checked for the execution of an interaction procedure, the values provided by a procedure interaction, what events may occur and how to take them into account. It is also necessary that the formalism allows the representation of the task interruption, the resumption after interruption, etc.
• the real-time management of such a task model is carried out by the task manager encapsulating access to the task models. It behaves like a service provider which will be described below.
• the manager is able to manage several different task models and several users in parallel.
• the multiplicity of task models managed by the same manager allows collaboration between several users with potentially different tasks.
• the task manager takes into account the scalability over time of a task model by offering access services for components that could alter the models.
• input and proofreading tools are implemented. These tools allow an expert to easily be able to express or verify the task of one or more users, to specify the different synchronizations in the case of collaborative work and to check the consistency of the models.
• the present invention is to augment the task model with new knowledge.
• This augmented task model allows man-machine interaction to be controlled in real time. The designers of the modules managing the interaction with the user no longer has to worry about how to manage the interaction, this information being located within the task model and accessible via the task manager.
• the invention also has the advantage of memorizing the task context of a user and is thus able to help maintain consistency in his mission, whether in the event of voluntary interruption (end of session, etc.). .) or not voluntary (breakdown involving an interruption or a change of workstation, ).
• Another advantage is the automatic generation of interfaces.
• the task model describing the interaction necessary for the user according to the point of progress of his task, it becomes possible to set up an automatic generation system of interfaces on the fly.
• the task model provides the necessary information in the form of achievable states and triggerable events depending on the constraints, depending on the current state of the user.
• Another advantage lies in the real-time modification of the task model.
• the interaction with the user can be modified in real time if external constraints require it, such as for example a modification of the security levels.
• the user interface can then be changed in real time.
• the invention described here in addition to the advantages mentioned above, opens the way to new possibilities. Among these possibilities we can cite learning by an external module. This module must receive all user state changes in real time and must be able to learn its typical behavior. Learning can be done in real time or delayed, from a task model (what the user should do) from the activity of a user (what he actually does), thus allowing to influence his task model in real time.
• the learning module is then able to alter the task model to simplify the task, to optimize its progress or to adapt to the way of working of each user.
• the process allows these alterations to be taken into account in real time.
• Another advantage is to allow easy implementation of user task planning techniques. This planning allows you to plan your actions and anticipate its requests (early loading of software modules, early downloading of long data to obtain, ).
• the separation between the application and the hon_me-machine interface described in French patent application 02 12012 is applied.
• the interface is then developed in the form of interaction services according to the specifications. of the task model.
• the interface then no longer includes the user's buried task model. Before, the interface defined that such window presented such data and allowed access to such other windows (reports).
• the interface developers know the windows to be developed by consulting the task model. For each state, a window is required to display the information to be presented (diode preceding the state, with reference to FIG. 1, described below) and to propose functionalities for triggering the output events (buttons, for example).
• the interface developer no longer develops the complete interface, but a list of interface services for the reports.
• For automatic adaptation of the interface in real time we can consider systems where, depending on the state in which the user will arrive, knowing the data to be presented and the necessary functions (buttons), we choose the best interface service in a list. There can therefore be three interfaces allowing to present the list of flights and to access the rest of the task model.
• the task manager provides the knowledge defining the interface needs (presenting a flight list and triggerable events), and it is another module which, depending on the context of the user, calls this or that service. 'interface.
• This characteristic is very advantageous insofar as several interface services can exist in parallel and be chosen according to the context.
• This adaptation allows the user to perform the same task on different terminals, with different modalities, ...
• the choice of interaction procedures being defined within the task model, the development approach of the interface from a service point of view makes it independent of the underlying application. A change of application continuing to offer similar services, will only imply an update of the interaction procedures of the task model without alteration necessary on the interface.
• the development of an interface in the form of services thanks to the task model makes it possible to vary the task model according to the user without involving additional development at the interface level.
• the augmented task model also becomes the specification allowing the design and development of interfaces and makes it possible to federate the developers of the application with the developers of interfaces.
• this task model describes the interactions that will be necessary for the user to perform his task.
• This model guarantees an interface that meets the needs of users.
• the task model defines the interaction procedures (generally sets of application service calls) to be triggered when the user requests a change of state. This allows application developers to know the list of services necessary for the user.
• This formalism allows interface designers to abstract from all application services, because the description of the application services to be triggered is specified in the task model.
• One possible embodiment of the present invention is to augment the task model of a user.
• the knowledge provided at the input of the process is a task model for a user.
• This process made it possible to increase the task model in collaboration with the experts in order to obtain an extended version, a partial example of which is given below.
• one embodiment consists in setting up a "task manager". The latter aims to provide task access services for other software modules that need it.
• the task model is based on the XML format, which is easy to perceive for the experts who will have to express it and for the interface designers who will have to use it.
• the task manager provides access to several different task models for several users, in parallel and in real time.
• the task model describes the different states of the user within his task and describes the actions he can take to change the state.
• This formalism defines the starting state of a user who begins his task. For each of the user states, a certain number of possible actions (potentially only one) can lead him into a new state by triggering an interaction procedure (generally a call to one or more application services).
• the transitions present in this formalism may include constraints.
• the need to have specific data to authorize the initiation of an action is a form of constraint.
• the task models of several users can be linked together so that they can take into account collaborative work problems.
• the states of the user are described by ovals, the interaction procedures by diamonds and the parameters necessary to trigger a procedure by diodes.
• the information provided by an interaction procedure is also described in the form of LEDs and indicates to interface developers the information resulting from the previous interaction procedure which must be presented to the user.
• the task model allows to specify the hierarchy task models to facilitate the specialization or generalization of models.
• the task manager of the invention is in the form of an external, real-time module providing access to the task models for which it is responsible.
• FIG. 1 shows five main steps of the task augmentation method, according to the invention.
• the first step E1 represents the initial task model.
• two successive states of the user namely "Disconnected” (disconnected, or more precisely, not yet connected to a device, for example a microcomputer), and "Connected” (connected to this device) .
• the next step E2 the current state of the user is added using a
• step E3 the description of an event (represented in a rectangle), which is here "Connect” (request for connection), and which makes it possible to pass the user from the first state to the second.
• the description of another event, "Disconnect”, which introduces the user from the second to the first state is introduced.
• step E4 the interaction procedures (each represented in a diamond) are added. These procedures are the connection of the user to the machine (“connect”) and the disconnection (“disconnect”).
• step E5 the parameters governing the triggering of the planned action (shown by a diode), that is to say the triggering of the user connection process to the machine .
• the parameters governing the triggering of the planned action shown by a diode
• the disconnection must be done unconditionally.
• this connection procedure there is, for example, verification of the accuracy of the parameters supplied by the user using a keyboard, an identification card with integrated circuit (so-called “card to puce “or” smart card “in English, ).
• the task model describes that the "Connect” procedure must be called during this change of state. This procedure is external to the task model, and only a reference (here its name) allows it to be found.
• the task manager following the "connect” event in the "disconnected” state, specifies that the "Connect” procedure must be called. Then, it is the module which interrogates the task manager to call this procedure.
• the task model has no idea of the content of this procedure.
• common sense would require, in the present case, that there be verification of the user's identification word and password. If the parameters thus verified are incorrect, therefore refused ("connection refused"), the manager brings the user back to the initial state ("disconnected", by the broken line path). The manager only responds to requests and memorizes the state of the user.
• the manager returns the profile provided by the interaction procedure (profile which can for example appear on said identification card) to trigger the connection action and he memorizes that the user is now in the connected state and responds to its caller.
• these parameters are those of a flight list of an airline user ("Flight list"), and the connection is established with this user profile, which therefore passes into the second state. .
• the following part of the file corresponds to the translation of this schema in XML form.
• FIG. 2 shows the block diagram of the main functions implemented by the method of the invention.
• the invention starts from an augmented task model (1) which communicates bi-directionally with the task manager (2).
• the latter cooperates with services (3) of the application.
• the task manager provides services to modules that need them.
• the diagram in Figure 3 summarizes the operating process of the task Manager. The process begins with the initialization and positioning of the initial state of the user (4). This step is followed by the request for the next interaction procedure in connection with an event due to the user (5).
• This request dialogues with the request for the next state of the user as a function of the result of the interaction procedure (6), which in turn dialogues with the request for the next interaction procedure as a function of an external event ( 7).

Landscapes

• Engineering & Computer Science (AREA)
• General Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Software Systems (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Human Computer Interaction (AREA)
• Stored Programmes (AREA)
• User Interface Of Digital Computer (AREA)
• Bending Of Plates, Rods, And Pipes (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=34639578

Family Applications (1)

Country Status (4)

Families Citing this family (2)

Family Cites Families (12)

• 2003
  • 2003-12-24 FR FR0315354A patent/FR2864646B1/fr not_active Expired - Fee Related
• 2004
  • 2004-12-16 US US10/584,224 patent/US7698120B2/en active Active
  • 2004-12-16 EP EP04804874A patent/EP1697835A2/de not_active Withdrawn
  • 2004-12-16 WO PCT/EP2004/053527 patent/WO2005071536A2/fr not_active Application Discontinuation

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events