Supplying the Front. French Southern Wine Wholesalers Facing World War I

This communication intents to present how, in a context of tensions and crisis, a sector (here the wine merchants from Languedoc) and a market can simultaneously face difficulties and sustain its activity during WWI.

First, I'd like to present the region studied, Languedoc, composed of 3 departments (doc 1).

Then the context : when the war broke, the Languedoc wine market is emerging from 15 years of turmoil, characterized by the irregularities of the production and of the prices1 , which lead the sector to considerable concerns and trouble (doc 2 +3). Now let's present the role of the merchants (or wholesalers), whose position on the market is inevitable (doc 4). Indeed, they assume the role of cogs between demand and offer.

Objectives of this communication:

Present the disruptive effects of the war

Show the different types of responses

Analyze how the war restructured the sector I. I. I. I.

General Mobilization and its disruptiv General Mobilization and its disruptiv General Mobilization and its disruptiv General Mobilization and its disruptive effects e effects e effects e effects

The question of the general mobilization and its effects on the economy more specifically is well known by the historians, especially with the works of several researchers. For instance, in a Companion to World War I, edited by John Horne, Theo Balderston states : " Few before 1914 anticipated a long war, and even those who did it rarely thought it in economic terms 2 ". Thus, the war in august 1914 is a shock and plunges the French economy into a certain chaos, even in Languedoc, 800 km from the Front. This for several reason.

On men -Mobilized

Mobilization in France draws 3.8 Millions of young and less young Frenchmen to the Front3 (8.4 % for the entire war).

The wine trading industry is deeply affected by the mobilization. During the 21 st of august session of the Regional wine syndicate, its president Marius Leroy d'Audéric wants to "pay homage to all our colleagues who answered the call from Motherland and who are today fighting for the right and sacred cause of our flag" But the family of the merchants are not the only ones who suffer from the mobilization. Other professions are deeply disturbed with, unsurprisingly a tremendous impact on the transactions and the sector.

In Sète, Auguste Malaval, a worker from the society "B. Tous" is appointed as a male nurse in the city military hospital6 .

Alphonse Artignan, a carter, is integrated to the 24 th battalion as a stretcher bearer and is wounded several times (at least 5 times) 7 .

In Montpellier, the service of official watchers affected to the surveillance of the transactions on route, is troubled by the mobilization of one of its guard, leading the local syndicate to complain about the reducing in speed of the controls8 .

In the vineyards, the effects of the mobilization are deep as well, especially during the times S. Le Bras, "Supplying the Front. French Southern Wine Wholesalers Facing World War I", Perspectives on the Great War, International conference, 1-4 august 2014, London. Working paper.

3 of high activity like the vendanges (grapes-harvest), pushing land owners to ask for temporary exemptions for their workers fighting up North9 .

Nonetheless, regarding the affectation, we could notice that a significant quantity of the merchants -especially the urban ones -were affected to non-fighting units, especially the automobile units. This could be explained by two main reasons : first, the merchants were members of the French bourgeoisie and thus were, through different means, affected to "protected" units. The other reasons is that most of them owned a car and were some of the few who could drive on the front (M. Roux ou M. Jeanjean).

-Deaths

Unfortunately, like thousands of French families, the families of wine merchants had to suffer from the loss of relatives, weakening threatening the activity and the future of the society. Death hits renowned and less famous families. In Montbazin, Leon Carrière, aged 21, the son a local merchants, is killed in june 1918 in Chaudun (Aisne) 10 . In Sète, we have

here the examples of two sons of famous local families killed as well on the front (doc 5b)11 .

On material

The mobilization affects as well the material question, especially through the use of military requisition.

These concerns more specifically 5 domains.

First the horses : thousands of them are requisitioned for the army and for the food supply in the region as well (doc 6).

Related to the horses, carts are demanded by the army as well12 .

The combination of these 2 requisitions disturbs deeply the sector because horses and carts are vital in the vineyard and in the expedition process since the productions journey in 600 litters barrels stacked on cart called "charroi".

More contemporary means of transportations are requisitioned as well : cars and trains mainly 13 . Here to carry military supplies as well as food supplies for both military and civilian populations.

In most town, vast buildings are requested by the army to host wounded soldiers or store merchandises and military stocks. Since the merchants owns large and convenient (near means of communication) warehouses, they are the targets of the army demands. Therefore, lots of wine depots are turned into ammunition storehouses, soldiers housing or temporary hospital like in Mèze (doc 7) 14 .

Ultimately, because of the increase of military demands in chemical products, their use if restricted which causes a lack of Phytosanitary products in the fields and in the warehouses.

Consequently, vineyards and stocked wines cannot be treated and suffer from disease and deterioration 15 .

Facing all these disturbances and disorders, let's see how the merchants react.

II. II. II. II. Individual and collective responses Individual and collective responses Individual and collective responses Individual and collective responses

To respond to the demanding effort caused by the war, the answers are on two levels : the one of the company and the one of the syndicates.

Coping as fast as possible

On the company level, the wine wholesalers in Languedoc follow the patterns of thousands of other shopkeepers, tradespeople or farmers.

-Family in support First, they rely on their family, especially the women and the youngsters.

On the doc 8, we can read the following caption : "As the war goes on, the women, who for twenty-nine months learnt so many new jobs, dedicated to the most unforeseen activities.

They are invested in easy and remunerative works which most will want to continue after the war." 16 Comment on the picture and caption : here is a grotesque and distorted vision of the woman (look at the man behind + woman only made for easy jobs) but it symbolizes the new place of woman in the wine industry. As in many other industries, they step up to replace - temporarily -men. This is recurring in the sector, especially in small or rural societies. For instance, the example of the Jeanjean Family in Saint-Félix-de-Lodez (Hérault) 17 . When François is joining his regiment, his wife, Cecile stand up to sustain the familial activity and replace her husband.

This one continue to give orders from the front, but the daily routine is managed by Cécile with some reluctance nonetheless from their former commercial partners. Letters from

Rouané who complains about the wife lack of abilities and expertise.

In other cases, the activity is took on by other members of the family, mostly the elders, or the youngsters, sometimes sick or estranged siblings, most of the times with difficulties and complications. In Saint-Chinian, Jules Viste hand the direction of the society to his sick brother and Abel Dessup from Gabian is forced to leave his 15 year old son in charge, helped by his brother, a civil servant living 20 km away, both ignorant of the uses in the industry 18 .

To avoid these complications, and the loss of capital, some merchants are compelled to close down their house.

-Closing down Aside these individual actions, we can observe patronal ones as well, through the involvement of regional and local syndicates.

Syndicates in action

As soon as august 1914, the Regional syndicate, even weakened by the absence of several of its members support an effort to restore regularity in the sector. Meanwhile, it participates to the Union Sacrée, the collective effort requested by the president Poincaré.

-Union Sacrée

In this context, the wholesalers, through their syndicates, decide to contribute to the generous donation made by the entire sector. Thus, in the autumn of 1914, 200.000 hectolitres are delivered to the front and the wounded in hospital (doc 9a). Until early 1915, we have proofs of deliveries of wine from the southern merchants to hospital and refugees lodging in the northern part of France21 . Even if this action is limited in time (in December 1914, the regional syndicate expresses fears that this donation could become regular22 ), this is the sign of a significant effort in a profession known for it individualism.

-Restauring pace But main concerns in the syndicates are to the restoration of a close-to-normal activity.

Indeed, war has caused three kinds of troubles to the expeditions of wine from Languedoc 23 .

The first one is the destruction of trains and infrastructures in the north.

The second one is the requisitions of material for military purposes.

The third one, consequence of the two first ones, is the disorganisation of the railroad system.

Based on a law from 1875, military transportations (ammunitions, food supplies, soldiers) are having priority and up until 1917, wine is not considered as a "staple product". Thus thousands of carts are abandoned or lost in august 1914 on the French railroad system, with no possible hope of a rapid return and, because of the state of war, the approval by the government of the non-responsibility for the rail companies. Moreover, in case of a return, this could be a breach in commercial contract and the loss may be supported by the merchants. This is a tremendous concern because in Languedoc a large amount of the expeditions are made by train (around 90%).

In the meantime, a moratoria for commercial transactions is ordained by the government. Many southern merchants, who were expecting payments from their clients in august 1914, are then facing huge delays that burden their firm's accounting. Furthermore, the circulation fees are increasing during war time, from 1,5 F in 1914 to 3 F en 1916 and 10 F in 1918 24 .

In this context, the regional syndicate is active in three directions:

-Giving advice to his members, especially advice of prudence and to trade only with solid and long-time running firms, less inclined to be weakened by the war. The syndicate offer as well services such as a collective service of commercial credit and try to facilitate the communication between commercial partners -Starting an intense propaganda and activity of lobbying, especially towards the Ministry of Public works, the one responsible for the railroad, with some results : in late 1914, government forces the rail companies to provide a regular service to commercial activities + in 1917, wine is decreed as a "staple product" -Being the unavoidable partner of the army in the supply of wine to the front. This is brought into being with the increase of demand from the front. In this tensed situation, the State and the Army must find reliable intermediaries in the productive regions : thus they rely on the Regional syndicate to get information, relay orders and control the sector (doc 9b The first one is classical : wine is part of the daily ration of the poilu and is used in the "rata", to accompany the meal.

The second one has a social dimension : wine is drank with friends, to fight boredom, to celebrate or to fraternise with allies.

Third point (doc 11): This last picture induces the question of propaganda, which is not absent in this matter, since wine is also a national catalyst.

-A booming demand

In this context, the demand is important, especially after a decree of October 1914, when the general staff headquarter decide that every soldier will be granted 25 centilitres of wine everyday (doc 12), which means almost 1 M litres per day, mainly coming from Languedoc (or at least transiting through it, from Spain and Algeria)26 .

To assure the distribution, large facilities are created both in Languedoc and in the near-front :

Store-stations as well as "wine trains" (doc 13).

This leads in the region to 2. Rapid and suspicious fortunes -An ongoing activity with large benefits Despite the difficulties, the activity is ongoing, especially for the strongest firms.

In Sète, so called "port of wine", the activity of the port doubled during the war (doc 14), and german prisoners are required to sustain the activity and fill in to replace the mobilized workers (doc 15). Many reports and testimonies describe the frenzy activity of the port27 , where wine from Algeria and Spain are imported, then dispatched to the front.

After the war, official reports indicates that many houses from the region realized tremendous benefits28 , especially in 1916-1917 when the wine prices reach 100 F/hl (12 F in 1914 -doc 16)).

This shed jealousy, suspicion and hatred to a profession which was already suffering from distrust since the turning of the XXth century and that is suffering from the bad image of wine-merchants on the front (called "mercantis") as well as those far way (doc 17).

This led as well to the intervention of the state.

- The second way is taxation. A first step is the luxury tax that strikes some wines, especially the aperitifs. But the main taxation is a law passed in 1916 and taxing all the benefits from august 1914 up until 18 months after the end of the war 30 . In some case, the taxation could rise up to 80 % of "extraordinary" benefits, which were numerous since wine prices were rising.

Conclusion Conclusion Conclusion Conclusion :

-'Cleansing' of the sector -Increase in wealth of the ongoing companies that were able to sustain their activities during the war -Emerging of the Regional syndicate, now a reliable and manifest partner of the State -Worsen the image of the wine merchants 29 BMS, juill. 191529 BMS, juill. -janv. 1916, p. 189 et sq. 30 , p. 189 et sq. 30 Loi du 1 er juillet 1916 concernant l'établissement d'une contribution extraordinaire sur les bénéfices exceptionnels réalisés pendant la guerre (Journal officiel de la République française des 2 et 6 juillet 1916).

  The intervention of the StateTo avoid the speculative (and sometimes overspeculative) attitude of the merchants, requisition. Because of the non-cooperative attitude of the wholesalers, offering poorquality and insufficient quantity of wine, the army decided to apply requisition to the wines as well in the summer of 1915 = up to 20 % of the harvest in 1915 ; 1/3 in 1917 (this leads to lots of complaints, because of the low price and the conditions of payment) 29 .

  The other cases of closing down are the one of foreign merchants and especially from german or german-originated family. This is a recurring situation in Languedoc since in the XIXth century, many german merchants installed their youngest sons in the region, to run the family interests directly. Here is the example of Louis Koester 20 . Koester is a famous and prosperous merchant, born in Sète in a german family. Even if his brother is fighting in the . Le Bras, "Supplying the Front. French Southern Wine Wholesalers Facing World War I", Perspectives on the Great War, International conference, 1-4 august 2014, London.Working paper.6 sector after the war, mainly thanks to his father in law, Louis Thau). We know through several indications that this examples is not unique and that all german-originated firms are under suspicion or forced to shut down.

	French Army, suspicions concerns and mistrust arise when Louis's father, Henrich, himself
	naturalized, flees to Spain in 1915. Louis Koester is then forced to officially hand his
	commerce over and is now only referenced as a land owner (even if he stays involved in the

This mainly concerns rural societies like one Henri Chabbert in Saint-Chinian who's driven to close his firm from august 1914 to February 1919 as he states in this letter

19

. The closing down is due to his impossibility to find a substitute and his inability to run his house far from it, without losing customers, hence money. It's then better off for him to shut down the firm during the conflict, limiting the risk to lose money. Other firms are in his situation, experiencing difficulties after the war. 17 Jeanjean M., Vigne et vin en Languedoc-Roussillon : l'histoire de la famille

Jeanjean, 1850-2006, Toulouse, Privat, 2006, p. 63 et sq. 18

ADH 8 M 309, Fonds de la Chambre de commerce de Béziers, Lettre d'A. Dessup, 03 mai 1920.

19

Idib., Lettre de « Chabbert-Poussines », 28/04/1920.

20

See his biography in Le Bras S., Négoce et négociants en vin dans l'Hérault : pratiques, influences, trajectoires

(1900-1970)

, thèse soutenue à Montpellier, novembre 1013. S

  ).Wine on the front has three main purposes, as suggested by the testimonies 25 . S. Le Bras, "Supplying the Front. French Southern Wine Wholesalers Facing World War I", Perspectives on the Great War, International conference, 1-4 august 2014, London.

	Working paper.
	III. III. III. III. The Home The Home The Home The Home front : a front : a front : a front : a significant opportunity significant opportunity significant opportunity significant opportunity
	1. Wine consumption in WWI (doc 10)
	-Pinard : sociability and a national catalyst
	8

For further and broader analyses, see Pech R., Entreprise viticole et capitalisme en Languedoc-Roussillon du phylloxera aux crises de mévente,Toulouse, Publications de Toulouse-Le Mirail, 1975.

Balderston T., "Industrial Mobilization and War Economies" in Horne J. (Ed.), A Companion to World War I, John Wiley & Sons, 2010, p. 217.

Becker J.-J., 1914, comment les Français sont entrés dans la guerre, Presses de la Fondation nationale des sciences politiques,Paris, 1977.

Bulletin mensuel du Syndicat regional (BMS), août-sept. 1914, p. 121.

Information from the website http://www.memoiredemontbazin.fr/des-hommes/guerre-1914-18/morts-pour-lafrance/

6 Macone G., Sète, mémoire en image, Tome IV,Saint-Avertin, Alan Sutton Ed., 2006, p. 49

.7 http://www.memoiredemontbazin.fr/des-hommes/guerre-1914-18/morts-pour-la-

france/ 8 BMS, déc. 1914-janv. 1915, p. 146.

Archives municipales de Frontignan, 3 F 13, Lettre de L. Koester, 28/08/1917.

http://www.memoiredemontbazin.fr/des-hommes/guerre-1914-18/morts-pour-la-france/

Information from the website http://www.memoiredeshommes.sga.defense.gouv.fr/

BMS, oct.-nov. 1914, p.

136-138.

ADH, 10 R 50, dons de vin, 1914ADH, 10 R 50, dons de vin, -1915. .

BMS, déc-janv. 1915, p. 142.

Figures from Gervais P., La viticulture en Francede 1913 à 1924, Paris, Chimie et Industrie, 1924.

See Cochet François, « 1914-1918 : l'alcool aux armées. Représentations et essai de typologie », Guerres

Archives du Sénat, Rapport fait devant la commission de l'armée sur le ravitaillement en vin, 1916.

Hélys M., Les provinces françaises pendant la guerre,Paris, Perrin, 1918, p. 212 et sq.

Archives de la Banque de France, inspection des succursales de Sète, Béziers, Montpellier, Narbonne etNîmes, 1919Nîmes, -1925. .


Blandine Ginon

Stéphanie Jean-Daubias

Pierre-Antoine Champin

Marie Lefevre

Setup of epiphytic assistance systems with SEPIA

Keywords: Language, user assistance, rule-based system, epiphytic tools

We propose a graphical language that enables the specification of assistance systems for a given application, by means of a set of rules. We implemented it through the SEPIA environment, mainly composed of an assistance editor aimed at assistance designers, and a generic assistance engine able to execute the specified assistance for the target-application end-users, without a need to modify this application. SEPIA has been tested out with 71 assistance designers and more than 250 end-users.

Introduction

User assistance is a solution to overcome the difficulties of handling and using software applications. However, the development of an assistance system suitable is a complex and expensive task, often neglected by applications designers. An alternative to the classical approach of development of an assistance system integrated into the application consists in adopting an epiphytic approach to make possible the a posteriori specification and execution of an epiphytic assistance system in an existing application. An epiphytic assistance is an assistant able to perform actions in an external targetapplication, without disturbing its functioning and without a need to modify it [START_REF] Paquette | EpiTalk, a generic tool for the development of advisor systems[END_REF]. We proposed an adjunction process of epi-assistance system in a target-application in two phases. The first phase involves an assistance designer: an expert of the targetapplication who wishes to design an assistance system. It enables the assistance designer to describe the target-application and then to specify the assistance that he/she wishes, by defining a set of assistance rules. The second phase involves the target-application end-users. It consists in the execution of the assistance specified by the designer in the target application. This phase manages the knowledge acquired during the assistance specification phase and relative to the target-application and to the assistance required.

In this paper, we present the SEPIA environment that implements this process and makes possible the adjunction of assistance systems in many applications, without programming work for the assistance designer.

2

The aLDEAS language

We propose aLDEAS (a Language to Define Epi-Assistance Systems), a graphical rule language aimed at assistance designers for defining assistance systems. We choose to propose a graphical language, very suitable to the representation by a set of simple rules of assistance systems, in particular epiphytic assistance systems. Its different components (like elementary assistance actions, waits and consultations) can be combined to create assistance actions addressing assistance needs; these rules will then be executed by SEPIA on top of the target-application. An aLDEAS block is a labelled direct graph, it must have exactly one source, which must be a "block start", and one or several sinks, which must all be "block end".

Fig. 1 gives the example of two assistance rules created for the target-application PhotoScape, a freeware for picture correction. Rule R0 contains a wait (the assistance launch, represented by a

) and a consultation of the user asking if he/she wishes help (represented by a

). R1 (represented by a ) will be triggered if the user chooses the option "yes I want help". The rule R7 is triggered by a click on component 228 (the "tools" menu of PhotoScape). R7 triggers an assistance action made up of two elementary assistance actions (represented by a ): the enhancement of component 210 (the "red eyes" button of PhotoScape) that will attract the end-user's attention in order to guide him, and a message suggesting the user to click on this button. The component indicates that the click on the "red eyes" button will put an end to the rule R7 and thus delete both the enhancement and the message.

SEPIA ENVIRONMENT

We implemented aLDEAS in the SEPIA environment (Specification and Execution of Personalized Intelligent Assistance) 1 . SEPIA is mainly composed of an assistance editor for the assistance specification, and a generic assistance engine for the assistance execution.

The assistance editor is a tool aimed at assistance designers. It implements aLDEAS and makes possible the specification, for any given target-application, of an assistance system described by a set of assistance rules. The assistance editor provides the assistance designer with an interface to handle the aLDEAS element in order to define the assistance system. No knowledge on aLDEAS is required to use the assistance editor.

Fig. 2. Screenshot of SEPIA assistance editor

As an example, Fig. 3 shows two zooms on screenshots of SEPIA assistance editor: it represents the creation of rule R0 on top and rule R7 on bottom (cf. Fig. 1).

Fig. 3. Zoom on the creation of rules R0 and R7 with SEPIA assistance editor

The SEPIA generic assistant engine is then able to execute the assistance specified by the assistance designer in the editor, in order provide the target-application end-users with personalized and contextualized assistance. To be able to provide contextualized assistance, the assistance engine must be aware of all the end-users actions in the target-application. For example, to execute rule R7 (cf. Fig. 1) in PhotoScape, that must be triggered and end by a click, the assistance engine must be informed when the end-user click on a component of the target-application, and more precisely on which component. For this purpose, we developed a set of detectors [START_REF] Ginon | Collecting fine-grained use traces in any application without modifying it[END_REF], based on accessibility libraries and able to monitor nearly any existing target-application: any web applications (except in flash), any Windows native applications, any Java applications for Windows and any GTK or Qt applications for Linux.

To be able to take into account the end-users' preferences, the generic assistance engine also provides end-users with an interface to edit their preference profile. These preferences will be used for the execution of assistance actions for which the assistance designer didn't specify all the optional parameters. As an example, Fig. 4 shows the execution of the rule R7 (cf. Fig. 1) in PhotoScape, for two different end-users: we can observe that the end-users preferences are taken into account for the enhancement (a blue arrow on left and an orange surround on right) and for the message layout.

CONCLUSION AND PERSPECTIVES

The aLDEAS language and the complex assistance action patterns that we proposed allow to define assistance systems suitable to their target-application. By adopting a fully epiphytic approach, we make possible the a posteriori plugging of assistance systems in existing applications. These applications have not to be specifically designed for the integration of assistance, no access to its source code is necessary and no programming skills are required of the assistance designer. The aLDEAS language is implemented in the SEPIA system. The experimentations that we performed showed that SEPIA can be used by assistance designers, with or without programming skills. What's more, SEPIA can be used to provide end-users with efficient assistance, in order to help them to achieve a given task, in particular in the context of discovery or occasional use of a target-application.

Fig. 1 .

 1 Fig. 1. Example of the assistance rules R0 and R7 for PhotoScape

Fig. 4 .

 4 Fig. 4. Personalized execution of rule R7 in the target-application PhotoScape, for two different end-users

Demonstration videos of both the specification and the execution of assistance systems with SEPIA are available at http://liris.cnrs.fr/blandine.ginon/PhDWork.html.


Vinh Le

Thai

Blandine Ginon

Stéphanie Jean-Daubias

Marie Lefevre

Adapting the SEPIA system to the educational context

Keywords: user assistance, education, pattern, domain knowledge, ILE

The SEPIA system allows creating assistance systems that meet technical assistance needs. In this paper, we aim at the exploitation of SEPIA in the educational context by confronting it to pedagogical assistance needs. This exploitation shows the limitations in the SEPIA system: complex description of rules by pedagogical designers, lack of domain knowledge. Therefore, we present our patterns that facilitate the creation of assistance systems in the educational context and our ideas to allow the exploitation of domain knowledge.

Introduction

Users often meet difficulties in handling and using applications: they under-exploit those applications by ignoring necessary functionalities and they can even abandon their use. In the educational context, these difficulties, under-exploitation and abandonment, can compromise learning when learners use either ILEs (Interactive Learning Environments), or classical applications for learning. Thus, one solution is the plugging of assistance systems that provide technical assistance to users. This solution can also be used to provide pedagogical assistance, if it is desired by the pedagogical designers or teachers but not supported by the target-applications. We identified the technical and pedagogical assistance needs [START_REF] Ginon | Adding epiphytic assistance systems in learning applications using the SEPIA system[END_REF] that an assistance system should meet in an educational context: handling, use, choice of the activity, learning prerequisites, explanation on steps, hints, examples, transitional diagnosis… Currently several systems (e.g. [1] [3]) allow the specification of assistance systems. However, they are specific to a given environment or to Web applications. By contrast, the SEPIA system [START_REF] Ginon | Adding epiphytic assistance systems in learning applications using the SEPIA system[END_REF] proposed in the AGATE project applies an epiphytic and generic approach. It proposes the setup of assistance systems to very diverse existing target-applications and has the capacity to personalize the assistance according to user profile, assistance history, user's past actions and state of the targetapplication. However, the SEPIA system aims only at technical assistance needs because of its generic characteristic. Thus, in this paper, we explain how we adapt it to the specific needs of the educational context.

At first, we present the SEPIA system and its possible exploitation in an educational context by presenting its capacities and identifying its limitations. We then present our solutions to adapt SEPIA to the educational context.

2

The SEPIA system

The AGATE (Approach for Genericity in Assistance To complEx tasks) project aims at proposing generic models and unified tools to make possible the setup of assistance systems in various existing applications, that we call target-applications, by applying a generic and epiphytic approach. This project led to aLDEAS (a Language to Define Epi-Assistance Systems), a graphical rule language allowing assistance designers to define assistance systems and aMEAS (a Model to Execute aLDEAS Assistance Systems) that explains how an assistance system is executed. The SEPIA system (Specification and Execution of Personalized Intelligent Assistance), the first product of AGATE project, is designed and implemented by operationalizing the aLDEAS language and the aMEAS model. The SEPIA system is composed of two main tools: an assistance editor that allows assistance designers to define assistance systems and a generic assistance engine that executes these assistance systems on the target-applications without disturbing them in order to provide assistance to users. The target-applications supported by actual SEPIA are Windows native applications, Java applications and Web applications.

3

Exploiting SEPIA in the educational context SEPIA is designed and implemented by taking into account the technical assistance needs. However, SEPIA can also meet pedagogical assistance needs. In the educational context, the assistance designer is the pedagogical designer who can be a teacher or a group of teachers and the user is mainly a learner. We tested SEPIA in the pedagogical context of a Human-Computer Interaction course. We created an assistance system (as a set of tutorials) for the handling of Java programing in NetBeans IDE. This experiment showed that students can acquire knowledge thanks to our tutorials. Thus, we can conclude from now that SEPIA is also useful in an educational context [START_REF] Ginon | Adding epiphytic assistance systems in learning applications using the SEPIA system[END_REF].

However, we identified several limitations to the use of SEPIA to create pedagogical assistances. Firstly, the pedagogical designers may not be familiar with the description of rules because they are not experts of SEPIA. Therefore, they may waste time in technical work instead of concentrating on the pedagogical work. Secondly, in order to propose a more complex assistance, we need domain knowledge that could be described with SEPIA, but complexly. As an example, a learner can submit different good answers if "X-5" is the solution, the system should identify that "X-4-1" or "X-3-2" are correct answers too. The automatic generation of examples or hints also requires domain knowledge in order to have a more suitable assistance.

4

Adapting SEPIA to educational context

In this section, we present our solutions to overcome the limitations of exploiting SEPIA in an educational context: proposition of patterns and integration of domain knowledge in the system. We aim not only at the technical facilitation of assistance systems description, but also at a more natural description for the designers.

Pedagogical assistances can be examples and explanations that consist of the consecutive steps of assistance or tutorials that merge them (as the tutorials we defined for NetBeans). In order to define such assistance, the designers have to create assistance rules with user consultations. This task is more complex if they want to modify the sequence of steps. Therefore, we proposed and implemented a first pattern called "sequence of steps". Assistance actions are associated with each step. They can be messages, enhancements, links to resources (web pages, programs…) or actions on the interface of the target-application (e.g. a click on a button). We proposed three modes to realize actions on the interface in this first pattern: automating the actions, waiting for user's actions and waiting for user's confirmation of the actions realization. The use of these modes depends on the pedagogical designer's needs and on SEPIA's capacities to detect and automate the actions on the target-application. In addition, we propose in this pattern the possibility to set up the back, next and finish buttons, in order to allow the final user to see again the previous step, the next step or to finish the sequence of steps. The designers can reuse and easily modify the sequence of steps. With this pattern, the pedagogical designers can concentrate less on description of rules and more on their choice of assistance actions for each step. This pattern is implemented and integrated to SEPIA as one assistance action of the system. The figure Fig. 1 shows a screenshot of this pattern that support three modes to realize actions on the interface. In order to assist more effectively the learner, the designers have to well identify the assistance needs and defining suited assistance rules. The designers first create a set of assistance actions (explanation, examples, hints, etc.) and then have to define conditions to specify how to launch these actions at the right time. We studied the modes of providing assistance in existing educational software: assistance upon the request of the learner, next assistance more detailed or closer to the solution than the previous one... These modes are based on different kind of approaches: proactive, reactive, parameterized and mainly mixed. In SEPIA, the application of these modes is compromised by the capacity of SEPIA (technical capacity, lack of domain knowledge) and the difficulty of the rules description (for example, how to provide easily assistance more and more detailed). Thus, we propose a second pattern "assistance needs refinement". We are defining a tree structure of the assistance steps for this pattern that will be then implemented.

More, the recommendation of activities suitable to learner requires organization of the activities. SEPIA does not support this organization. The designers have to create rules, conditions to identify activities suitable to the learner and create learner consultations to know his choice. These tasks are complex and the number of necessary rules is huge. Thus, we plan to implement a third pattern examining researches that concern the recommendation of activities. In addition, we will implement ways of visualizing a summary and a monitoring of activities (e.g. through a progression bar).

Finally, we will focus on defining and implementing an over layer to SEPIA that allows the system to use domain knowledge. We will first have to propose the architecture of this layer. For this purpose, we aim at reusing existing modules that allow pedagogical designers to define different domains knowledge, and at integrating modules of knowledge management specific to a domain (e.g. mathematics).

Conclusion

We have presented the exploitation of SEPIA in an educational context. SEPIA has been shown to have a strong potential to create assistance systems in an educational context. However, because of the genericity of our approach, it has some limitations. To overcome these limitations, our solutions concern the proposition of patterns and the integration of domain knowledge in our system. Thanks to these solutions, the pedagogical designers will concentrate mainly on the pedagogical works, but not on technical works. In addition, domain knowledge helps them to create assistance systems that provide more appropriate assistance because these systems will know more precisely the learner's problems and the assistance needs. We will validate these solutions by several experimentations with teachers, and students who will play the role of "pedagogical designers". We will compare the use of SEPIA with and without our solutions (patterns and domain knowledge).

Fig. 1 .

 1 Fig. 1. Screenshot of step creation in the pattern "sequence of steps"


Blandine Ginon

Stéphanie Jean-Daubias

Pierre-Antoine Champin

Marie Lefevre

aLDEAS: a Language to Define Epiphytic Assistance Systems

Keywords: Language, user assistance, rule-based system, epiphytic tools

We propose a graphical language that enables the specification of assistance systems for a given application, by means of a set of rules. This language is completed by several assistance actions patterns. We implemented these propositions through an assistance editor aimed at assistance designers, and a generic assistance engine able to execute the specified assistance for the target-application end users, without a need to modify this application. We performed several experimentations both with assistance designers and with targetapplications end users.

Introduction

User assistance is one solution to overcome the difficulties of handling and using software applications. It helps preventing the user from under-exploiting or even rejecting those applications.

We define assistance as the set of means facilitating the handling and use of an application, in a way suitable to the user and to the use context. The assistance aims at enabling the user to exploit fully all the possibilities of an application, and it facilitates the appropriation of the knowledge and competencies required to use this application. It includes the four assistance types defined by [START_REF] Gapenne | Defining categories of the human/technology coupling: theoretical and methodological issues[END_REF]: supplementation, support, assistance and substitution.

The development of an assistance system suitable to an application is a complex and expensive task, often neglected by applications designers. A person other than the application designer may then wish to plug an assistance system to an application that has no assistance or an incomplete one. For instance, in the context of a user community, an expert may wish to design an assistance system to make novice users benefit from his/her experience. In the case where the assistance designer is not the targetapplication designer, the source code of the target-application is most of the time not available; it is then not possible to integrate an assistance system directly in the application. What's more, as in our example, the potential assistance designer is not always a programmer. An alternative to the classical approach of development of an assistance system integrated into the application consists in adopting an epiphytic approach to make possible the a posteriori specification and execution of an assistance system in an existing application without the need to modify it. An epiphytic assistance, that we call an epi-assistant, is an assistant able to perform actions in an external target-application, without disturbing its functioning [START_REF] Paquette | EpiTalk, a generic tool for the development of advisor systems[END_REF].

The work presented in this paper takes place in the context of the AGATE project that aims to propose generic models and unified tools to make possible the setup of assistance systems in any existing application, that we call the target-application. For this purpose, we proposed an adjunction process of epi-assistance system in a targetapplication in two phases (cf. Fig. 1). The first phase involves an assistance designer: an expert of the target-application who wishes to design an assistance system. This phase enables the assistance designer to specify the assistance that he/she wishes for the target-application, by defining a set of assistance rules. The second phase involves the target-application end users. It consists in the execution of the assistance specified by the designer. This phase occurs at each use of the target-application by an end user; it is composed of three processes. The monitoring of the target-application exploits a set of epi-detectors [START_REF] Ginon | Collecting fine-grained use traces in any application without modifying it[END_REF] that enable the continuous observation and the tracing of all interactions between the user and the target-application interface. In parallel, the process identifying assistance needs exploits the assistance rules defined by the designer and triggers the process elaborating an answer to the identified assistance need. The answer is executed as one or several assistance actions, performed by an epiassistant in the target-application.

Fig. 1. Adjunction process of an epi-assistance system in a target-application

During the specification phase, the assistance designers need to elicit their knowledge about how to use the target application, in order to specify the assistance system. This phase must be accessible to an assistance designer that can be neither non-computer scientist nor knowledge engineering expert. Then the specified assistance is executed automatically during the execution phase. As a consequence, the assistance needs to be formalized enough. A solution to make these two points possible is to use a pivot language: we proposed aLDEAS, a graphical language to help assistance designers designing assistance rules. Moreover, we propose a set of patterns to guide them in defining complex assistance actions. We then present the im-plementation of these patterns in the SEPIA system. Finally, we describe the experimentations that we performed in order to evaluate the usability of aLDEAS and its implementation in the SEPIA system.

2

Related work

Several authors have studied the a posteriori specification of assistance systems for existing target-applications. The approaches of [START_REF] Paquette | TELOS: A Service-Oriented Framework to Support Learning and Knowledge Management[END_REF] and [START_REF] Dufresne | ExploraGraph: a flexible and adaptive interface to support distance learning[END_REF] allow to plug an advisor system in a scenario from the environments Telos and ExploraGraph. These advisor systems are defined by an assistance designer through a set of rules of the form <trigger event, trigger condition, assistance action, end event>. The trigger condition can include a consultation of the user profile and of the assistance history in order to personalize and contextualize the assistance. The proposed assistance actions are textual messages displayed in a pop-up for Telos, and animations or messages conveyed by an animated agent for ExploraGraph. The approach proposed by [START_REF] Richard | Enhancing the adaptivity of an existing Website with an epiphyte recommender system[END_REF] allows to plug an advisor system in a Web application, in order to trigger assistance actions when the end user clicks on a link. The proposed actions are textual messages displayed in a pop-up, which can contain links to a Web page or to resources related to the assistance. The provided assistance can be personalized according to a browsing history. The assistance provided by these advisor systems can also be expressed by rules with the form <trigger event: click on a link, trigger condition: browsing history, assistance action>. The CAMELEON model [START_REF] Carlier | Educational webportals augmented by mobile devices with iFrimousse architecture[END_REF] allows to plug an animated agent able to move, perform animations and display messages in a Web application, thanks to tags inserted in an epiphytic way in the page.

Assistance rules seem to be suited to represent epiphytic assistance systems. Nevertheless, these different approaches cannot be used in any application. Indeed, they are specific to a given environment or to the Web. We are interested in the a posteriori plugging of assistance systems to very diverse existing target-applications. What's more, we would like to allow a fine-grained personalization of the assistance, according to the user profile and to the assistance history, like in Telos and ExploraGraph, but also according to the user's past actions, not only the browsing history as in [START_REF] Richard | Enhancing the adaptivity of an existing Website with an epiphyte recommender system[END_REF], and according to the state of the target-application. Finally, to make possible a wider personalization of the assistance, we would like to propose a large choice of assistance actions: if the same assistance action can be performed in different ways, like pop-up or animated agent, it will be easier for the assistance designer to specify assistance suited to the user's specificities and to the context.

3

The aLDEAS language

We propose aLDEAS (a Language to Define Epi-Assistance Systems), a graphical rule language aimed at assistance designers for defining assistance systems. We choose to propose a graphical language, very suitable to the representation by a set of simple rules of assistance systems, in particular epiphytic assistance systems. Its different components (cf. Fig. 2) are presented in detail in this section. We will show thereafter how these components can be combined to create assistance actions addressing assistance needs that will then be executed by our system SEPIA on top of the target-application. An aLDEAS block is a labelled direct graph, with nodes and edges taken from Fig. 2. It must have exactly one source, which must be a "block start", and one or several sinks, which must all be "block end". It is executed by walking the graph; the effect of walking each type of node is described in the following.

Fig. 2. Components of aLDEAS

Waits

Waits are nodes that cause the execution to pause until the occurrence of a given event. Elementary waits, represented in the language by the symbol , can expect a specific user's action, like a click on a given button, they can expect an event of the assistance system, like the triggering of a given assistance action, or they can wait for the end of a timer. A timer is associated to a duration and can be triggered after any event linked to the user's action or to the assistance system. For instance, a timer can be used to trigger an assistance action after two minutes without any user's action.

Several elementary waits can be combined to create a complex wait, represented by . Thus, such elements can wait for a given succession of elementary events making up a higher level event, for instance an action of red eyes correction on a photo.

Consultations

Consultations are nodes that fetch information, in order to personalize and contextualize the assistance. The aLDEAS language proposes several types of elementary consultations, represented in the language by . It makes possible the direct consultation of the user, to make him choose between several options for instance. It is also possible to consult the target-application state, in order for instance to know the content of a text field, or which item is selected in a combo box. Finally, aLDEAS makes possible the consultation of resources linked to the assistance, such as the user's profile (that contains notably information on the user's preferences regarding assistance, or his skills in the target-application), the assistance history (that contains information relative to the rules and actions triggered for the user), and the user's traces (that contains information about all the interactions between the user and the target-application interface). Elementary consultations can be combined by a logical formula to create a complex consultation represented by . A consultation, either elementary or com-plex, returns a value which can have different types: Boolean, text or number. For instance, a consultation of the assistance history can return a number indicating how many times an assistance action has been trigger.

Consultation nodes typically have several outgoing edges, represented as (alternative branching), where each edge is labeled with a Boolean expression. The execution of the block will continue only along the edge(s) with the expression of which is satisfied by the returned value. If several edges are satisfied, the corresponding paths will be executed in parallel. An example of alternative is given in the rule R0 in Fig. 7.

Assistance actions

Our language proposes two categories of elementary assistance actions, represented by : integrated actions and actions external to the target-application interface. The grayed actions on Fig. 3 and Fig. 4 that are the only aLDEAS actions that are not implemented in the current version of SEPIA (cf. section 5).

Fig. 3. Elementary assistance actions integrated to the target-application interface

The integrated actions act directly on a given component of the target-application interface, like a button or a text field. aLDEAS proposes four types of such actions on a component (cf. Fig. 3): automated actions, to act on behalf of the user; addition of component, to enrich the target-application interface (for instance by a new button enabling the user to ask for help); enhancement, to guide the user and attract his attention on a component; and masking, to simplify the target-application interface to the user's eyes. An action integrated to the target-application interface can be associated to several optional parameters, indicated by dotted line in Fig. 3. For instance, for an enhancement, a component of the target-application interface can be shown by an animated agent or circled by a stroke with a given color and size.

On the other hand, actions external to the target-application interface are not specifically linked to a component. aLDEAS proposes three types of such actions (cf. Fig. 4): messages, associated to a text that can be displayed and/or read; animations, for instance an animated agent applauding; and resources that can be proposed to the user, for instance a demonstration video, a forum or an application like the calculator.

Fig. 4. Elementary assistance actions external to the target-application interface

Whenever an elementary action node is encountered, the corresponding action is launched, and the execution walks immediately to the next node; this allows several actions to be active at the same time (such as a message and an enhancement). Actions can stop on their own (e.g. playing a sound), be stopped by the user (e.g. by closing a message box), but some actions need to be explicitly stopped. This can be specified with the stop marker : this node causes all the actions started in the current block to stop. Fig. 5 gives the example of a block composed of two elementary assistance actions: a message and an enhancement. The action also contains an end event: the message and the enhancement will disappear after 30 seconds.

Complex assistance actions

Any aLDEAS block can be invoked in another block as a complex assistance action, represented by the symbol . This node causes the execution of the invoking block to stall until the execution of the invoked block finishes.

A complex assistance action can return a value, which must be indicated under the corresponding end marker (cf. examples Fig. 9 and Fig. 10). In the blocks invoking this action, the corresponding node will be followed by an alternative branching, as described in the end of Section 3.2.

aLDEAS patterns

In order to facilitate the definition in aLDEAS of complex assistance actions, we propose a set of patterns. For that purpose, we enrich our language with two structures: "or" branching and optional elements preceded by a "?". These structures do not describe the assistance execution; they represent a choice to be made by the assistance designer at the time of the pattern instantiation.

4.1

Assistance rules pattern Fig. 6. Assistance rules pattern

The aim of our language is to enable assistance designers to specify the assistance that they wish for a target-application, by means of a set of rules. In aLDEAS, we define an assistance rule as a complex action that complies with the pattern given in Fig. 6. A rule starts with a trigger event that corresponds to the waiting of an event. A rule then contains an assistance action or a consultation with an alternative branching followed by as many assistance actions. A rule can be associated with an end event that corresponds to a wait for that event followed by the stop marker. If a rule has no end event, it will leave all its actions to stop on their own (or be stopped by the user). Fig. 7 gives the example of two assistance rules created for the target-application PhotoScape, a freeware for photo correction. Rule R0 contains a trigger event (the assistance launch) and a consultation of the user asking if he/she wishes help. R1 will be triggered if the user chooses the option "yes, I want help". The rule R7 is triggered by a click on component 228 (the "tools" menu of PhotoScape). R7 triggers an assistance action made up of two elementary assistance actions: the enhancement of component 210 (the "red eyes" button of PhotoScape), and a message suggesting the user to click on this button. The click on the "red eyes" button will put an end to the rule R7 and thus delete both the enhancement and the message.

Complex assistance actions pattern

The aLDEAS language makes possible the definition of complex assistance actions, combining several elementary elements. The definition of such actions can be difficult. For this reason, we defined complex assistance actions patterns associated with our language, in order to facilitate the definition of some complex actions frequently encountered in existing assistance systems: animated agents actions, guided presentation and step-by-step. In this section, only the patterns relative to step-by-step actions are given.

An animated agent action makes possible the combination of several elementary actions for a given character: messages, animation (show a component, applaud, greet…), and moving on the screen. For instance: the animated agent places itself next to the "e-mail" field, it displays the message "don't forget to fill your e-mail address", and it shows the field until the user modifies the value of this field.

A guided presentation is made of several steps, in which a component is enhanced and possibly presented by a message. We frequently find this kind of assistance actions in existing applications, notably when an application is launched for the first time, or after an update. The instantiation of the guided presentation pattern is a way for the assistance designer to representation his knowledge on the targetapplication functionalities.

A step-by-step aims at facilitating the achievement of a given task by detailing it in several elementary steps. Each step corresponds to an action to perform on a component of the target-application interface. We call automated step-by-step a step-bystep in which the assistance system will perform the actions on behalf of the user. We call guided step-by-step a step-by-step in which the assistance system will ask the user to perform the required actions. The patterns of a step for automated step-by-step and for guided step-by-step are given respectively in Fig. 9 and Fig. 10: these two step patterns are used by the step-by-step pattern (cf. Fig. 8), on which the step are represented by . The instantiation of the step-to-step pattern is a way for the assistance designer to representation his knowledge on the different actions to do in order to perform a given task in the target-application.

IMPLEMENTATION IN SEPIA

We implemented aLDEAS and the patterns that complete it in the SEPIA environment (Specification and Execution of Personalized Intelligent Assistance).

The assistance editor is a tool aimed at assistance designers. It implements aLDEAS and makes possible the specification, for any given target-application, of an assistance system described by a set of assistance rules complying with the rule pattern (cf. Fig. 6). The assistance editor provides an interface for the definition the elementary assistance action presented in Section 3.3 (except the grayed actions on Fig. 3 and Fig. 4), and for the definition of action that instantiate the pattern proposed in Section 4.2. No knowledge on aLDEAS is required to use the assistance editor.

We developed a set of epi-assistants, able to perform in a target-application the elementary assistance actions proposed by aLDEAS and defined thanks to our assistance editor. The automated actions are available on any web application, on Windows native and Java applications, and on Linux GKT and Qt applications. Our epiassistants performing these actions use a user script for web applications and different accessibility libraries for desktop applications: UIAutomation, JavaAccessibility and ATK-SPI [START_REF] Ginon | Collecting fine-grained use traces in any application without modifying it[END_REF]. Enhancement and masking actions are available for the same categories of applications as they need the same technology to find the bounding rectangle of the component that must be enhanced or masked. Animated agent actions are available on any Windows web or desktop application. Messages and resource launch are available for any application.

We developed a generic assistant engine able to execute the assistance specified by the assistance designer in the editor. To perform elementary assistance actions, the engine invokes one of our epi-assistants. Regarding complex assistance actions instantiating one of our patterns, the engine ensures their management and invokes an epi-assistant when necessary.

EVALUATIONS

The propositions presented in this paper have already been evaluated in several ways. Regarding the feasibility of our approach, it is demonstrated by its implementation in SEPIA, through the editor and the engine, completed by our epi-detectors and epi-assistants. In this section, we present the studies lead to evaluate the usability of aLDEAS. We also performed several studies to evaluate the utility and acceptation of the assistance provided to end users that are not presented here [START_REF] Ginon | Adding epiphytic assistance systems in learning applications using the SEPIA system[END_REF].

Usability of aLDEAS

We made two experiments that aimed at evaluating the usability of aLDEAS language by assistance designers, with both computer-scientists and non-computer scientists.

Use of aLDEAS by computer scientists

In the context of a computer science master degree, students have developed in pairs simple ILE (Interactive Learning Environment), without any assistance system. We asked to the 29 students the create assistance system for the 14 ILE developed in order to demonstrate that aLDEAS can help assistance designers to specify an assistance system. First, each pair has been separated in two rooms, during 90 minutes. In the first rooms, 14 assistance designers have to define "on paper" an assistance system for their ILE, without any formalism. In the other room, 15 assistance designers have to define an assistance system in aLDEAS. They previously received explanations on aLDEAS. Each pair was then gathered during 90 minutes in order to share their work, and to define their final assistance system in aLDEAS. In a second time, the assistance designers had to use the SEPIA system during 3 hours, in order to define their assistance system, and to test it in their ILE.

Each pair succeeded in creating an assistance system with aLDEAS. A satisfaction questionnaire showed that 93% of the assistance designers found aLDEAS easy to use, and 76% thought that aLDEAS helped them to define their assistance system. 63% of the assistance designers thought that the use of aLDEAS facilitates the specification of the assistance with the SEPIA system and 67% found it easy to use to define assistance rules. Several assistance designers also noticed in their comment to the satisfaction questionnaire that aLDEAS helped them to work in pair and to formalize their ideas.

Use of aLDEAS by non-computer scientists

We ask five non-computer scientists to use aLDEAS in order to represent an assistance system for the red eyes correction on a photo with PhotoScape. These five assistance designers were between 11 to 68 years old. The assistance designers received explanations on aLDEAS during 5 minutes, and they had examples of aLDEAS rules, coming from another assistance system.

First, the assistance designer used successfully aLDEAS language to define "on paper" between 7 to 9 assistance rules complying with aLDEAS pattern. This work lasted between 30 to 45 minutes. In a second time, they used the SEPIA system to create and test their assistance system, after a short presentation of the SEPIA assistance editor. This work lasted between 55 to 95 minutes.

Four assistance designers on five found aLDEAS easy to use, and all of them declared that aLDEAS helped them a lot to create their assistance system. What's more, they found that the definition of rules with the SEPIA editor is easy once the rules are defined in aLDEAS. These encouraging results seem to show that the aLDEAS language and its implementation in the SEPIA system can be used by assistance designers without any knowledge in programming. It has to be confirmed by a wider experiment with non-computer scientists, with other target-applications than PhotoScape.

DISCUSSION

In order to evaluate the coverage of the language that we propose, we used it to model various existing assistance systems, representative of the assistance types that are the most frequently found. Thus, aLDEAS makes possible the modeling of assistance systems frequently used in Web applications that contain a form: for instance, theses assistance systems explain to the user where to find information to fill a field, or advise the user when a field is not filled. Guided presentation of a software or functionality, a typical assistance system, can also be modeled in our language. Otherwise, there are many tutorials proposed by expert users in order to guide a user step-by-step to achieve a task, thanks to annotated screen shots and messages. Our language allows to model such assistance systems, with the advantage that they will be integrated in the target-application. Thus, instead of annotated screen shots, the assistance system can directly enhance the target-application user interface. Nevertheless, some assistance systems cannot be modeled with our language: it is the case for assistance systems very specific to an application and that require information not available from outside the application. For instance, some recommender systems integrated in online sale applications use information relative to all the articles consulted or bought by all users. aLDEAS does not make possible the consultation of this kind of information.

We also evaluated aLDEAS language by comparing it to existing approach for a posteriori specification of assistance for a target-application. Compared to the approach proposed by [START_REF] Richard | Enhancing the adaptivity of an existing Website with an epiphyte recommender system[END_REF], aLDEAS can model such assistance action, as a wait for a click event on a given link, optionally followed by a consultation of the browsing history, then by an assistance action of type message (that can contain link towards another web page or resource). aLDEAS also proposes elementary assistance action to launch resources directly without a need use a link in a message. Compared to the approach proposed by [START_REF] Carlier | Educational webportals augmented by mobile devices with iFrimousse architecture[END_REF], aLDEAS allows to define assistance actions involving animated agents able to move themselves in a web page, to express themselves orally or textually, and by gestures and animations. We also facilitate the definition of such actions by proposing a pattern of animated agent actions. Finally, our language allows to define rules of the form <trigger event, trigger condition, assistance action, end event> (cf. Section 4.1) equivalent to the rules used in the approaches of [START_REF] Paquette | TELOS: A Service-Oriented Framework to Support Learning and Knowledge Management[END_REF] and [START_REF] Dufresne | ExploraGraph: a flexible and adaptive interface to support distance learning[END_REF]. What's more aLDEAS allows to define more complex and varied assistance rules. aLDEAS also proposes a larger choice of elementary assistance actions, and patterns facilitating the definition of assistance actions composed of several elements.

CONCLUSION AND PERSPECTIVES

The aLDEAS language and the complex assistance action patterns that we presented allow to define assistance systems suitable to their target-application. By adopting a fully epiphytic approach, we make possible the a posteriori plugging of assistance systems in existing applications. These applications have not to be specifically designed for the integration of assistance, any access to its source code is necessary and any programming skills are required of the assistance designer. The experimentation that we performed showed that aLDEAS can be used to define assistance systems "on paper", by assistance designers with or without programming skills. Moreover, aLDEAS seem to help assistance designers to represents the assistance that they wish for the target-application.

The aLDEAS language is implemented in the SEPIA system. The experimentation that we performed showed that SEPIA can be used by assistance designers, with or without programming skills. What's more, SEPIA can be used to provide end users with efficient assistance, in order to help them to achieve a given task, in particular in the context of the discovery or occasional use of the target-application.

We now work on a method to help the assistance designer to identify the assistance needs of an application, in order to help him/her to define an efficient assistance system. This method will also make possible the end users to provide the assistance designer with feedback, in order to help him/her to improve the assistance system.

Fig. 5 .

 5 Fig. 5. Example of a block with a stop marker

Fig. 7 .

 7 Fig. 7. Example of the assistance rules R0 and R7 for PhotoScape

Fig. 8 .

 8 Fig. 8. Step-by-step pattern

Fig. 9 .

 9 Fig. 9.Step for automated step-by-step pattern