EP2612236A1

EP2612236A1 - Method of gathering data of an event-like nature from electronic forms

Info

Publication number: EP2612236A1
Application number: EP11764809.7A
Authority: EP
Inventors: Benoit Ferlin
Original assignee: BANQUE ACCORD
Current assignee: ONEY BANK
Priority date: 2010-09-02
Filing date: 2011-08-30
Publication date: 2013-07-10
Also published as: RU2640715C1; FR2964484A1; RU2013114686A; FR2964484B1; CN103262049A; BR112013006365A8; WO2012028817A1; US20130227386A1; CN103262049B; BR112013006365A2

Abstract

Method of managing an electronic form accessible on an application server (2) via a user terminal (10) provided with at least one input peripheral, this method comprising the following steps: - upon the loading of the electronic form by the user terminal (10), identification (11) of the fields of the electronic form that are liable to be relevant to user interactions; - detection and storage of data relating to any event produced on each of the identified fields; - downloading of the data stored upon submission of the electronic form; - analysis of the downloaded data.

Description

METHOD FOR COLLECTING CHARACTER DATA

EVENTS OF ELECTRONIC FORMS

The present invention relates to the technical field of online services and more particularly to the study of user interactions with electronic forms online.

With the widespread use of the Internet and / or Intranet, the number of online services continues to grow: for example, e-commerce, e-banking, e-learning and e-government services. . In fact, more and more companies - especially in the banking sector - tend to offer their services electronically through online applications. Thus banking and financial transactions can now be completed online, remotely.

In order to respond to economic and commercial prospects, these online services use various computer resources ranging from the simplest, such as a "contact us" email or an electronic form, to the more complex, such as communication tools interfaceable on Web 2.0 (instant messaging or "chat", social tagging, blog, dynamic web site of "Wiki" type).

In this context, the electronic form is considered one of the main promoters of online services. The form allows, in fact: a high reactivity: data entry can be accelerated - by comparison, for example, with an email application - using drop-down menus or checkboxes; obtaining pre-formatted data that can be automatically integrated into a database;

the assistance of the user when entering the required information: compulsory data (username, password for example) or optional (address, profession, age, email address for example), procedure to follow (identification, payment, verification , confirmation for example); the economics of retranscribing user information (unlike in particular chat or e-mail, in which user information must be retrieved and retranscribed, with a risk of error in the retranscription);

obtaining relevant information, for example, by causing the user to make a choice from a predefined list at the convenience of the online service administrator.

As a result, the electronic form has become a key computing resource for online services, whether informative, advisory or transactional.

However, the administrators of online services are struggling to design efficient and user-friendly forms, with no critical feedback from users: it would be necessary to have the latter fill out satisfaction forms, which would be a vicious circle. . So that the quality of the ergonomics of electronic forms, which is fundamental for the acceptance by Internet users of the subscription of online services, is generally appreciated only incompletely because of the absence of statistical study. about how people fill out forms. It goes without saying that the behavior of Internet users when filling out a form varies according to age, gender, socio-professional category, type of terminal, browser used. However, it is not conceivable, for reasons that are not only commercial but also ethical, to make access to an online service requiring the filling of a form to the prior identification of a category to which the user belongs. : in principle, any user must be able to fill out a form to access the service.

Yet the reactions of Internet users to forms are diverse and complex. Thus, if the organization of the fields to be completed is fundamental, we note that the logics vary according to the individuals. This logic can also oppose the interests of the service provider. So, if for some service providers the age of the user is a given fundamental condition conditioning the provision of the service (let us mention for example the services reserved for adults and prohibited to children), the presence of the field "age" at the top of the form can immediately put off the user who will turn away from the service. Similarly, the capture methodology is fundamental and there is little data to date on how, statistically, Internet users enter the information requested of them.

An objective of the present invention is to improve the ergonomics of electronic forms in order to facilitate the access of Internet users to online services conditioned by the submission of these forms.

To this end, the invention relates, in a first aspect, to a method of managing an electronic form accessible on an application server via a user terminal provided with at least one input device, this method comprising the following steps: - as soon as the electronic form is loaded by the user terminal, identification of the fields of the electronic form likely to be concerned by user interactions;

- Detection and storage of data concerning any event produced on each of the identified fields;

- unloading the stored data when submitting the electronic form;

analysis of the discharged data, this analysis step comprising a step of distinguishing successive event chains that translate user interactions. According to a second aspect, the invention relates to an event recorder for managing an electronic form accessible on an application server via a user terminal provided with at least one input device, this recorder being the event being configured for:

- as soon as the electronic form is loaded by the user terminal, identify the fields of the electronic form that may be affected by user interactions; - detect and memorize data concerning any event produced on each of the identified fields;

- Unload, when submitting the electronic form, the stored data to an analysis server configured to distinguish in this stored data at least one chain of successive events reflecting a user interaction.

According to a third aspect, the invention relates to a computer program product implemented on a memory medium that can be implemented within a computer processing unit and includes instructions for implementing the process summarized above.

Other features and advantages of the invention will appear more clearly and concretely on reading the following description of preferred embodiments, which is made with reference to the accompanying drawings in which:

FIG. 1 schematically illustrates a nonlimiting functional representation of an embodiment;

Figure 2 schematically illustrates an alternative embodiment.

FIG. 1 shows a user 1 requesting, via a user terminal 10, access to a content and / or an online service from an application server 2.

The user terminal 10 (a computer, a digital tablet, a smartphone, a mobile phone, or more generally any device allowing the user 1 to interact with a remote server) is, in particular, provided with input and output devices. a display means (a screen). Here we mean by input device any device for sending instructions (text input, pointing for example) to the user terminal 10. A keyboard, a touch screen, a digicode, a joystick, a mouse, a trackball , a touchpad, a graphics tablet or any combination of these are examples of input devices of the user terminal 10.

The user terminal 10 is also provided with a web browser (FireFox®, Fennec®, Opera®, Opera Mobile®, Internet Explorer®, Google Chrome® for example) or any other means of consulting a website set online via the application server 2. This web browser is arranged to transmit a request for access to a service and / or a content posted, as well as to display the response to this request transmitted from the application server 2.

The communication between the user terminal 10 and the application server 2 is established according to a navigation protocol simultaneously supported (http, https, WAP for example).

The application server 2 allows access to (or hosts) at least one website (or a WAP site) including an electronic form. As a non-limiting example, the application server 2 offers an online service such as an online banking loan application, requiring the filling of an electronic form by a user wishing to benefit from this service.

In its interactions with the content posted via the application server 2, the user 1 transmits an access request 120 to an electronic form to the application server 2. In response, the application server 2 returns to the user 1 the required electronic form 121 including an event recorder.

The event recorder is a computer program product (i.e., a set of lines of code representing instructions) attached to the electronic form required by the user 1. According to a particular embodiment, the Event recorder is embedded in the source code of the electronic form.

It should be noted that the event recorder is however independent of the electronic form required by the user 1, and can be integrated with any other electronic form. The purpose of the event recorder is to allow the reconstitution over time of the manner in which the required electronic form is filled by the user 1. In this respect, there are three phases: an initialization phase making it possible to inventory all the electronic form fields that may be affected by user interactions; an execution phase during which the event recorder detects and stores any event produced on each of the inventoried fields of the electronic form;

an unloading phase for attaching the stored data to the electronic form when submitted by the user.

Here we mean by "field" of an electronic form any constituent element of the electronic form, or more generally any component of the graphic interface included in the electronic form (icon, push button, check box, radio button, menu of command, context menu, tab, scroll bar, text box, tooltip, dialog box, floating window, hypertext link for example). Moreover, a "user interaction" designates, here, any instruction (selection, input, pointing for example) triggered by the user 1 via an input device of the user terminal 10 or by a computer program product (a robot for example).

Upon loading, by the user 1, the electronic form 121 including an event recorder, the latter, in an initialization phase, - performs an exploration of the electronic form (step 11 of Figure 1) in order to identify all the fields whose values can be modified by the user 1 (an input zone, a drop-down menu, a checkbox, a radio button, a button, a link to another document for example), and

- Stores (step 12 of Figure 1) the properties of the identified fields; ie for each identified field, memorizes the name, the type (button, checkbox, file, hidden, image, password, radio, reset, select-one, select-multiple, submit, text, textarea for example), and the initial value (empty, checked for example). Thus, the event recorder builds a detailed repository characterizing all the fields present in the electronic form loaded by the user 1. In a particular embodiment, the event recorder scans the electronic form to extract the structure (that is, all the fields present in the electronic form) to store it in a Structural table] whose form is as follows:

Property Description

i Form number

j Field appearance number in the structure

Idx Field index in "i / j" format

type Field type:

button A

checkbo) B

file C

hidden D

image E

passworc 1 F

G radio

reset H

select-or 1

select-m ultiple J

submit K

text L

textarea M

window X (in the browser sense)

no reco nnu Z

val_ini Initial value of the field

name Name of c: hint in the HTML sense

id identifies int from the field to the HTML meaning Each field of the electronic form is indexed by a number of the electronic form and its appearance number in the structure of this electronic form.

During the execution phase, a listener (in particular, "listener" in English) is associated with each field listed on the electronic form, in order to detect any event produced on this field, and trigger, therefore, the memorization of this event. As non-limiting examples of events, mention is made of:

Auditor Description

keydown A key is pressed

keypress A key is "pressed"

keyup A key is released

The field catches the focus

Blur The field loses focus

select An item from a list is selected

paste The paste event occurs on the field

Cut The "cut" event occurs on the field copy The "copy" event occurs on the field

change The content of a field has changed in value

click The field has been clicked

dblclick The field has been double clicked

contextmenu A context menu was triggered on the mousedown field A mouse button is pressed on the mouseup field A mouse button is released on the resize field The user resizes the window of the electronic form

mouseover The mouse arrives at the top of the field mouseout the mouse leaves the field

In particular, the focus event occurs when a listed field is selected. As soon as this field loses "focus", the "blur" event occurs. These two events make it possible, in particular, to know that the user 1 performs a swap from the electronic form to another document. The two events "focus" and "blur" inform, among others, the attention of the user 1 to the electronic form.

Auditors programmed to detect "focus" and "blur" events are implemented on the "window" object of the Document Object Model (DOM) that triggers a storage function associated with the "window" object.

The "resize" event results from resizing the electronic form window using one of the following browser functions: "handle" (usually accessible in the lower right corner of the browser), "full screen", " lower level "or" enlarge "(the last three are usually in the upper right corner of the browser).

Time management is performed by means of a variable fed with the current time, making it possible to calculate the time (in milliseconds) elapsed between two consecutive events and / or the duration of an event (also in milliseconds).

In a particular implementation, any captured event is stored in a Trace [] array, including the following properties: Property Description

i Number ck î sequence of the event

dh Number of milliseconds elapsed since the previous event ctrl Event index on which the event occurs

keycode keycode o u charcode on a key type event

selTxt Selected text in a "text" or "textarea" field selDeb Offset in the field of the beginning of the selected text

selFin Offset in the end field of the selected text

new_val_vide Indicator to know that the new value of the field is

"Empty".

special_key Lets you know that a special key has been pressed when

the event

Event Event Code Occurred

new_val New field value

mouse Last known mouse p osition before it happens

the event

Preferably, the stored data relating to an event produced and picked up by a listener includes: the event, the field in which the event occurred, the elapsed time (in milliseconds) since the previous event, the instruction transmitted from the input device to the user terminal (ie the value of the key pressed, or the mouse button pressed), the content of the selected text / item, a start index and / or end of the selected text, the new value of the field, a modification of the value of a field, the status of special keys such as "CTL", "ALT", "SHIFT" for example. In addition, when a given event is generated by:

- a click of the mouse, then this one is identified (left click, middle click, right click);

- pressing a key (keydown - keypress and keyup event), then the "keycode" of the key (for the keydown and keyup events) or the "charcode" (for the keypress event) is identified.

It also stores the support on one or more special keys, namely the keys "Ctrl", "Alt", or "Shift" for example, when the event occurs in the property "special_key". The "ctrl" property, for example, is therefore associated with the field on which the event occurs. If the event concerns the window itself of the electronic form, then, for this window (i = 0, j = 0, according to the Structure table []), the event "focus" or "blur" is memorized. If the event is for an unknown field type (which may be a bug in the browser), the "ctrl" property is set to "none" so that the event is removed from the Trace [] event table.

For example, if the event concerns an element of type "text", "textarea" or "password" and text is selected, the following information is stored:

- selTxt: Selected text;

- selDeb: Offset in the element of the beginning of the selection;

- selFin: Offset in the element at the end of the selection.

If the event concerns an element of type "select-one" or "select-multiple", one feeds the property "new_val" which will format in a chain the selected elements in the following way:

Character '['

For each selected item:

Order number of the item,

The text of the item in which the character "| " by

"& Pipe" and the character "/" by "& slashe",

The character " / "

Character "]".

If the event concerns a "radio" or "checkbox" type field, the property "new_val" (1: checked or selected, 0 the reverse) is fed to "1" or "0".

Finally, for all the other fields for which the "value" property is defined (text, textarea, password), we supply the "new_val" property with the value of the element by replacing the "| By "&pipe". In particular, if the new value is empty while the previous one was different from the empty one, we put the property "new_val_vide" to 1. Lastly, we feed the property "ex_val" of the field with the new value. In one embodiment, the "event" property stores an alphabetic character associated with the event that has been triggered while respecting a certain nomenclature, such as the following:

It should be noted that the stored data relates to the way in which the user 1 interacts with the electronic form and not on the content of his interactions (ie the text entered).

The submission of the electronic form (step 122 of FIG. 1) by the user 1 to the application server 2 triggers the unloading phase enabling the memorized data to be attached to the electronic form.

In particular, the unloading phase allows:

- To format the data stored during the initialization and execution phase in a technical trace;

- to join, in a dynamically created zone, the technical trace to the electronic form to be submitted.

For this, first of all, in order to avoid any problem of interpretation of the technical trace with certain "special" characters (of the type "<", "?" For example), these are, preferably, replaced by respecting a certain nomenclature such as the following: Character Replacement String

<% 3c

=% 3d

>% 3rd

&% 26

? % 3f

The technical trace is then formatted to include a header, a structure and the event trace already stored.

The header, delimited by a tag of type <header> and </ head>, enriches the information included in the trace of events by including, by way of non-exhaustive example, the elements of the following table.

Name Description

Version Version of the recorder (for example, 1.0)

host The name of the host on which the event recorder turned (by

example e www.oney.fr)

pathname Path of the page on the site (for example, / aperture / map php) search String of the possible parameters of the url (by

example e? mode = subscription)

Date_Deb Date - Load time of the form

Date_End Date - \ at the time of the function execution

appCodeName The code name of the browser (for example, Mozilla)

appMinorVersion Type of? minor version of the browser

appName Full name of the browser (eg Netscape)

appVersion Browser version (for example 5.0 (Windows; U; Windows NT 6.1) cookieEnabled Boole î indicating that the browser accepts cookies cpuClass Type of \ processor

language Language? browser (for example, fr)

onLine Booler indicating that the browser is connected to the Internet or not platform Name of the operating system (eg Win32)

systemLanguage Code the ngue of the operating system

. . Concatenation of several browser information (for example, userAgent .. ...

3 Mozilla '5.0 (Windows; U)

userLanguage Code the ngue of the browser

availHeight Number ^> useful pixels of the vertical resolution of the screen

availWidth Number ^> of useful pixels of the horizontal resolution of the screen

colorDepth Color depth in bits

height Resolute actual vertical ion of the screen

width Resolute actual horizontal ion of the screen

innerHeight Height in pixel of the visible content area of the browser

innerWidth The pixel width of the browser's visible content area

XOffset Positior î of the page in the browser (elevator) in the direction

horizon tal

YOffset Positior î of the page in the browser (elevator) in the vertical direction

Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR

1.1.4322) | en 19961128013211024112801881112291010 </ cap>

The structure of a technical trace, delimited by <structure> and </ structure> tags, includes a description of the listed fields of the electronic form as shown below:

An illustrative example of a structure of a technical trace is given below (the character "|" is replaced by "& pipe" in each property containing text):

] | [1: Mr.] 10/31 first name | first name | L | | Benoit 10/41 name | name | L | | Ferlin 10/51 nameYoungGirl I young-girl-name I L | | | 0/6 | dateNaissanceJour | | L | [0 -

0/20 email L (text) bferlin@test.fr

The event trace includes all the events that occurred during the execution phase on the form and that can be delimited with the "<trace>" and "</ trace>" tags. The trace is composed of the following elements each separated by the character "| »:

Name Description

Dh Number of milliseconds since the previous event

Ctrl This is the identifier of the field, ie '' Idx of the structure

Event Code

keydown A

keyup B

keypress C

jibs

blur E

select F

event

paste G

had H

copy I

change J

click K

dblclick L

contextmenu M mousedown N

mouseup 0

Other Z

keycode ^* Keycode or charcode on a key type event

selTxt ^* Text selected in a "text" or "textarea" field selDeb Offset in the field of the beginning of the selected text

selFin Offset in the field at the end of the selected text

new_val ^* New field value

new_val_vide Indicator to know that the new value of the field is

"Empty".

spe_key Lets you know that a special key was pressed when

event

For privacy reasons, the event trace is preferably encrypted. In particular, the content of the structure of the technical trace can also be encrypted.

In a non-limiting embodiment of the event trace encryption, encryption keys are calculated by the event recorder in a random manner and stored in the system variable "window.name". Advantageously, this encryption method makes it possible to keep the same encryption method for all the electronic forms loaded (ie open) on the same browser. For this, in a preferred embodiment, three encryption matrices are defined from three distinct zones of an input device of the user terminal (a keyboard):

matrix A (mA): the keys F1 to F12;

- matrix B (mB): the keys 1 to 0 of the main keyboard and the same of the numeric keypad;

- matrix C (mC): the keys A to Z.

The keys numbered according to a key encryption table make it possible to obtain encryption matrices composed of the keys relative to each zone.

Each matrix is initialized with its corresponding key numbers, for example:

- mA: numbers from 1 to 11;

- mB: figures from 17 to 26; and - mC: numbers from 31 to 40 + figures from 45 to 54 + figures from 59 to 64.

For each matrix thus formed, a large number (for example 1000) of permutations two by two of the elements of each matrix is performed.

These matrices are then saved in the "window.name" variable. The following example illustrates the format of this variable (the numbers are used here for illustrative purposes only):

[m A = new Array (2,12,8,1,6,3,10,9,7,5,4,11);

mB = new Array (19,20,22,24,17,21,23,25,26,18);

mC = new Array

(48,60,64,31, 39,47,45,50,63,54,40,46,49,62,35,36,38,53,61, 59,37,32,51, 33, 52 , 34);]

Encryption matrices mA, mB, and mC are generated as soon as the event recorder is loaded. If, during a later loading of the event recorder, the presence of the matrices is detected in the variable "window.name", the chain is reworked to erase the opening and closing hooks and a simple evaluation of the chain allows to load the matrices keeping the same permutations.

In order to constitute a table of mixed keys respecting these blocks, an array named tcp [] indexed from 0 to 105 takes the matrices mA, mB and mC: var tcp = new ArrayQ;

for (i = 0; i <105; i + +) {

tcp [i] = i;

if ((i> 0) && (i <13)) tcp [i] = mA [i-1];

if ((i> 16) && (i <27)) tcp [i] = mB [i-17];

if ((i> 94) && (i <105)) tcp [i] = mB [i-95];

if ((i> 30) && (i <41)) tcp [i] = mC [i-31];

if ((i> 44) && (i <55)) tcp [i] = mC [i-35];

if ((i> 58) && (i <64)) tcp [i] = mC [i-39];

It should be noted that when pressing a key, three events produce:

- keydown: the key is pressed, and the keycode of the key is intercepted; - keypress: the key is pressed, and the charcode of the key is intercepted;

- keyup: the key is released, and the keycode of the key is intercepted. In particular, it is advisable to maintain coherence between the values of "keycode -charcode" and the value of the characters entered, making it possible, for example, to detect that the user 1 has corrected his name by inverting two characters of a previous one capture.

An example is given below illustrating the encryption method in which two keys, for example 53 (L) and 64 (N) according to a key encryption table, were inverted during the creation of the encryption matrices:

The following two tables, respectively of correspondence between an element and its key number and the correspondence between a key number and its element, are used by the encryption method.

The correspondence table between an element and its key number can be as follows:

Name Description Example kd Correspo idance between a keyCode and a key number kd [76] = 53 kc Correspo idance between a charcode and a key number kc [108] = 53 kcm Correspo idance between a "uppercase" charcode < is a number kcm [76] = 53

of touchi

because Correspo idance between a character and its number of touch <? because [T] = 53

because [L] = 53

The correspondence table between a key number and its element can be as follows:

Name Description Example tkd Correspo ndance between a key number and a keycode tkd [64] = 78 tkc Correspo ndance between a key number and a tkc charcode [64] = 110 tkcm Correspo ndance between a key number and a key charco de «in tkcm [64] = 78

majuscu the »

te Correspo ndance between a key number and a carael: era in tc [64] = 'n'

minuscule e

tem Correspo ndance between a key number and a carael: era in tcm [64] = 'N'

capitalize it Encrypting a keycode following the keydown and keyup events includes the following steps:

- recovery, from the table kd, the number of the key associated with the keycode to encrypt: in this example kd [76] = 53;

- read the permutation of the key in question in the table tcp: in this example, tcp [53] = 64;

- search, in the table tkd, for the keycode associated with the key number obtained: in this example, tkd [64] = 78.

Encrypting a charcode following the keypress event includes the following steps:

- recovery, from the table kc, of the key number associated with the charcode to encrypt (if this element is not defined, one recovers then this number of key in the table kcm): in this example kcm [76] = 53

- search, in table tkc, for the charcode associated with the key number obtained: in this example, tkd [64] = 78.

A comparison of the capitalization of a character with the character itself allows to know if a character is lowercase or uppercase (except for special characters such as, for example, "to", "ù" or "ç"). By way of example, according to the above examples, since ['L'] = 53, whereas tcp [53] = 64 corresponds in tcm to 'N' ie. tcm [64] = 'N'. Of course, other methods of encrypting the event trace can be used.

In one embodiment and for security reasons, the formatted technical trace is attached in a hidden manner (a "hidden" element) to the electronic form to be submitted by the user 1 to the application server 2. In another embodiment, even if the user 1 cancels the submission or abandons the electronic form (backtracking from the browser, closing the electronic form page for example), the technical trace is sent to the application server 2 (step 122 of Figure 1) or the analysis server 3 (step 130 of Figure 1). In this case, the technical trace makes it possible to locate the areas of the form where user 1 has stopped. This makes it possible, for example, to identify the fields that represent an obstacle to users to complete their transactions. In one embodiment, the application server 2 is provided with a plugin 21 programmed to extract the technical trace of the submitted form and transfer it to an analysis server 3. This transfer is intended, in particular, not to disturb the operation of the application server 2 which is dedicated to processing the content of the submitted form. As a result, the management of the technical trace is reserved for an analysis server 3 so as not to penalize the processing time, by the application server 2, of the content of the form submitted by the user 1.

As a variant, the technical trace is directly transmitted (step 130 of FIG. 1) to the analysis server 3. The analysis server 3 is configured to:

check the coherence of the technical trace (step 31 of FIG. 1): the structure of the trace, the presence of the information of the header, for example;

analyzing the trace of events included in the technical trace (step 32 of FIG. 1); and

- Store (step 33 of Figure 1) the analysis of the technical trace in a database 30.

The analysis step 32 of an event trace includes several steps such as: the normalization of the event trace by deleting, for example, superfluous events dependent on the browser used by the user 1 (for example, the fact of passing from one field to another generates in Internet Explorer an event of the type "the window gains the focus");

- the distinction of successive chains of events translating user interactions, for example the chain of events

"Mousedown - mouseup- contextmenu-paste" corresponding to the action "paste into an area using the context menu";

- evaluation of the typing dynamics (normal typing: keydown-keypress-keyup, fast typing: time between keyup and keydowns, repetitive typing: duration of the keypress time).

The distinction of successive events chains translating user interactions can be made, according to a particular embodiment, by analyzing the trace by a technique called "regular expressions": we associate a letter of the alphabet with each event of the trace and form a string of characters consisting of all events, one after the other. Each regular expression is searched in the chain of events, and when it is found, we associate an "analysis flag" to know that the elementary events correspond to a particular action. At this level of analysis, the event trace is decomposed into understandable events, in other words in user interactions: a key has been pressed, a field has undergone a "paste" action, or a box has been checked, for example.

Advantageously, the translation of all the events included in the event trace into user interactions makes it possible to reconstitute in time the manner in which the electronic form has been completed by the user 1. More precisely, this step makes it possible to reconstitute, by a tracing of user interactions (copy-paste, text entry, item selection, page switching for example) taking into account, in particular, the temporal aspect (duration / order of user interaction) or the scenario according to which the form electronic is filled.

The evaluation of the striking dynamics can be carried out by calculating, for each event of the trace, the distance "Levenshtein" (or according to any other measure of similarity between two chains of events) resulting from the changes of value of the zone on which the event occurred. The distance "Levenshtein" quantifies the algorithmic cost of passing from one word to another. This step of evaluating the typing dynamic makes it possible to identify how the fields of the electronic form have been filled. Indeed, there are three types of keystrokes:

- normal typing: The field is modified following the events "keydown + keypress + keyup";

- fast typing: this event occurs when user 1 quickly typed on the keyboard; the sequence is characterized by the fact that the keyup event of the first key pressed has not yet occurred even though the keydown event of the next key has occurred. This analysis tends to show that the user who made the typing usually enters this information on the keyboard;

- Repetitive typing: This event occurs when the user presses a key for a long time and triggers repetitive field feeding with the same character. In addition, the analysis of the technical trace also makes it possible to identify the fields that have been modified using "copy / paste", the "auto-completion" technique offered by certain browsers, or the using robots for example.

This analysis step allows the reconstitution of the way the electronic form has been filled by the user 1. For example, the user 1:

- clicked on the "name" field, filled it with the keys on the keyboard by making X normal entries, Y quick entries, Z corrections;

- jumped from the "name" field to the "address" field using the tab key; - swapped to a window other than the electronic form window (the electronic form window lost focus, and a blur event was subsequently generated);

- has activated again the "address" field of the electronic form ("focus" event produced on the "address" field);

- pasted content into the "address" field using the context menu (the following chain of events occurred on the "address" field: "mousedown - mouseup- contextmenu-paste").

Based on the data collected during this analysis, a human decision can be made (for example by a group of people such as a marketing management) to modify the form, for example if the statistics show difficulties for some users to fill out correctly or quickly enough the form. For this purpose, a person authorized to access the analysis server 3 can consult (step 41 of FIG. 1), for example daily, the analyzes of the technical traces recorded in the database 30 of the analysis server 3 and define (step 42 of Figure 1), accordingly, a plan of action.

According to another embodiment illustrated in FIG. 2, the application server 2 can request (step 231 of FIG. 2) the analysis of the technical traces that have been transferred to it from the analysis server 3 (step 232 of the figure 2) for further processing of the submitted form (for example, to accept or reject a bank transaction in the case of an e-banking form).

In this embodiment, the analysis server 3 is configured to apply itself processing rules of the form (step 34 of Figure 2).

The system and method just described above make it possible, on the basis of a behavioral statistical analysis (anonymous) of the user interactions, to modify the architecture of the forms in order to improve their ergonomics without as much as it is necessary to modify the client terminals, both in terms of hardware and software. The behavioral characteristics of the user include the manner in which the user uses an input device (the keyboard and / or the mouse for example).

It is also possible to put online several types of forms according to the supposed performance of users. The different types of forms can thus comprise different functionalities (in particular assistance with filling, for example by means of drop-down menus instead of free input window).

It goes without saying, moreover, that alternative embodiments are possible. Thus, the application server 2 can perform the analysis server function 3.

Claims

A method for managing an electronic form accessible on an application server (2) via a user terminal (10) provided with at least one input device, this method characterized in that it comprises the following steps :

- as soon as the electronic form is loaded by the user terminal (10), identification (11) of the fields of the electronic form that may be affected by user interactions;

- unloading the stored data when submitting the electronic form;

analysis of the discharged data, this analysis step comprising a step of distinguishing successive event chains that translate user interactions.

2. Method according to claim 1, characterized in that the identification step comprises a step of memorizing the properties of the identified fields.

3. Method according to any one of claims 1 or 2, characterized in that it further comprises a step of associating a listener to each identified field of the electronic form to detect any event produced on this field.

4. Method according to any one of the preceding claims, characterized in that the events to be detected are chosen from the following events: keydown, keypress, keyup, focus, blur, select, paste, eut, copy, change, click, dbelick , contextmenu, mousedown, mouseup, resize, mouseover, mouseout.

5. Method according to any one of the preceding claims, characterized in that the stored data relating to an event produced on an identified field are selected from the product event, the field on which the event occurred, the time elapsed since the previous event, the instruction transmitted since input device to the user terminal, the new value of the field, a change of the value of a field, the state of special keys of the input device.

6. Method according to any one of the preceding claims, characterized in that the step of unloading the stored data comprises a formatting operation of the stored data and an operation of joining the formatted data to the electronic form.

7. Method according to claim 6, characterized in that the stored data are formatted to include a header, a structure and a trace of the events produced.

8. Method according to claim 7, characterized in that the trace of the events produced is encrypted.

An event recorder for managing an electronic form accessible on an application server (2) via a user terminal (10) provided with at least one input device, said event recorder being characterized in that it is configured for:

- as soon as the electronic form is loaded by the user terminal (10), identifying (11) the fields of the electronic form that may be affected by user interactions;

- detect and memorize data concerning any event produced on each of the identified fields;

- Unload, when submitting the electronic form, the stored data to an analysis server (3) configured to distinguish in this stored data at least one chain of successive events reflecting a user interaction.

10. Event recorder according to claim 9, characterized in that it is attached to the electronic form required by the user terminal (10), in response to an access request (120) to this electronic form, issued since the user terminal (10).

11. Computer program product implemented on a memory medium, capable of being implemented within a processing unit computer and comprising instructions for carrying out the method according to one of claims 1 to 8.