Premiers résultats

Nous avons récupéré trois chiers de logs à l'issue des bêta-tests. Chaque chier correspond à plusieurs mois d'utilisation du logiciel installé sur un poste d'un client. Sur les trois clients démarchés, deux ont une utilisation corporate du logiciel, c'est-à-dire qu'ils s'en servent comme un outil de support à leur travail, pour imprimer leurs plans de conceptions par exemple. Le dernier client concerné est d'un autre type : l'impression est son corps de métier ; l'utilisation du logiciel est donc plus intensive (g. 2.4).

Comme nous l'avons mentionné plus haut, une première analyse a été réalisée sur les chiers obtenus lors du bêta-test. Nous ignorons si plusieurs utilisateurs se sont partagés le même poste ou si toutes les traces obtenues dans un chier sont le fruit d'un unique utilisateur. Les trois chiers obtenus forment un tout de 26 400 lignes toutes exprimées dans le même formalisme (g. 2.3).

Les premières analyses ont été réalisées grâce à un outil logiciel spécialement développé (voir l'annexe B). Elles ont pour objectif d'établir des statistiques globales d'utilisabilité, à partir de séquences d'évènements. L'étude se base sur la tâche de plus haut niveau : l'impression de documents. Le but est de détecter les séquences d'actions liées à une impression et d'en extraire l'information d'utilisabilité. Cette information tient en trois points :

1. le temps de travail eectivement passé à résoudre la tâche 2. le nombre de manipulations nécessaires

3. le nombre d'erreurs commises par impression réussie

0 1000 2000 3000 4000 5000

Répartition des évènements dans le temps

4141 8204 9581

Fig. 2.4: Répartition des évènements dans le temps Le temps de travail eectif

Du fait que l'enregistrement ne résulte pas d'une séance de tests encadrés, nous devons diviser le temps d'utilisation en trois parties :

 le temps d'activité où l'utilisation de l'application est eective

 le temps d'absence où l'utilisateur est passé sur une autre application, repé-rable par une désactivation immédiatement suivie d'une activation de la fenêtre de travail courante

 le temps d'inactivité où l'utilisateur reste sur l'application mais ne produit aucune action depuis un moment susamment long.

An de dénir une période d'inactivité, nous avons choisi de xer un seuil de temps de 5 minutes. Au-delà de cette durée, le temps entre deux évènements consécutifs est considéré comme une période d'inactivité (i.e. on considère que l'utilisateur fait autre chose). Nous distinguons ainsi les temps de " réexion " (pause pour lire le texte à l'écran, etc.), des périodes où l'utilisateur est, par exemple, parti manger en laissant l'application ouverte.

Sur le diagramme (2.5), on peut voir l'importance des durées d'absence et d'inac-tivité. De telles durées peuvent être facilement expliquées par le fait que l'utilisateur se sert du logiciel in situ sur son lieu de travail, qu'il peut être dérangé à tout mo-ment, qu'il peut aller manger ou qu'il peut " swapper " avec d'autres applications.

Le diagramme 2.6 montre le temps eectif moyen par impression réussie, par session. Nous dénissons plus précisément ce qu'est une impression réussie dans notre contexte dans la section 2.2.2. Pour l'exemple donné, on peut calculer le temps

Temps d'activité - 8204 0 500 1000 1500 2000 2500 3000 3500 4000 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 sessions s e c o n d e s

temps_actif temps_inactif temps_absence

temps par impression réussies - 9581 0 500 1000 1500 2000 26 28 35 46 49 50 81 85 86 87 91 ₁₀¹ ₁₀² ₁₀³ ₁₀⁴ ₁₀⁶ ₁₀⁸ ₁₀⁹ ₁₁⁰ ₁₁² ₁₁⁷ sessions se co nd es

Fig. 2.6: Temps par impression réussie

eectif moyen d'une impression réussie, sur l'ensemble des sessions, qui est de 526 secondes, soit presque 10 minutes. Cette information est précieuse dans notre éva-luation de l'utilisabilité.

Pour mémoire, on rappelle qu'une impression représente ici l'impression eective d'un groupe de documents et non d'un seul.

Le nombre de manipulations

Le nombre de manipulations est calculé après un ltrage des évènements en-registrés. En eet, la plupart d'entre eux ne désigne pas une nouvelle action de l'utilisateur.

On remarque sur la gure 2.7 des pics de manipulations. Ils correspondent en réalité à des évènements redondants qui n'ont pas été ltrés. Typiquement à la session 87, certaines actions, telles que l'appui prolongé sur un compteur, peuvent générer de très nombreux évènements alors qu'en réalité, cela ne correspond qu'à une action de l'utilisateur. Cela fait partie des pièges à éviter pendant l'analyse des logs. En moyennant sur l'ensemble des sessions, on obtient un nombre de manipulations moyen par impression réussie de 186.

Le nombre d'erreurs

Lorsque l'on considère la tâche haut niveau imprimer des documents, une er-reur est synonyme d'impression ratée. Nous dénissons une impression ratée par le

# d'events par impression réussie 0 500 1000 1500 2000 2500 3000 3500 4000 4500 1 7 13 19 25 31 37 43 49 55 61 67 73 79 85 91 97 103 109 115 sessions # d 'e ve n ts 9581

Fig. 2.7: Nombre d'évènements par impression réussie

Actions par impression réussie - 9581

0 500 1000 1500 2000 26 28 35 46 49 50 81 85 86 87 91 101 102 103 104 106 108 109 110 112 117 sessions

courbe d'erreurs - 9581 0 10 20 30 40 50 26 28 35 46 49 50 81 85 86 87 91 10¹ 10² 10³ 10⁴ 10⁶ 10⁸ 10⁹ 11⁰ 11² 11⁷ sessions # d'erreurs # de prints

Fig. 2.9: Courbes comparées du nombre d'impressions et d'erreurs (utilisateur 9581) critère suivant : lorsque l'utilisateur imprime deux fois de suite exactement le même ensemble de document, en modiant les paramètres d'impression entre les deux.

Nous sommes cependant conscients que l'interprétation en terme d'erreur ne se justie pas toujours. Par exemple, une telle séquence d'évènements peut transcrire un test de l'utilisateur qui va imprimer d'abord en qualité brouillon, avant d'imprimer en qualité supérieure. On peut interpréter ce cas d'au moins deux manières : soit l'utilisateur n'est pas sûr des réglages d'impression, soit il n'est pas sûr du rendu de l'image elle-même. C'est cette dernière option qui peut fausser notre interprétation en terme d'erreur, la première en faisant partie en tant que test. Nous considérons donc un bruit inhérent à ce genre d'observation.

On voit sur la gure 2.9 deux types d'utilisations. De la session 26 à 91, l'applica-tion a été testée, c'est une utilisal'applica-tion de type exploratoire. Au contraire, entre les sessions 91 et 106, on assiste a une phase particulièrement productive, caractérisée par beaucoup d'impressions et un taux d'erreurs faible par session.

Conclusions de l'analyse

Avec les données de l'exemple, pour une impression réussie on a :  Taux d'erreur = 1,3

 Temps de travail = 10 minutes  Nombre de manipulations = 180  Nombre d'impressions par jour = 3,5

Taux d'erreur - 9581 0 1 2 3 4 5 6 7 8 26 28 35 46 49 50 81 85 86 87 91 101 102 103 104 106 108 109 110 112 117 sessions #p ri n ts "r a tés" / #p ri n ts "réu s si s"

Fig. 2.10: Taux d'erreur (utilisateur 9581)

Ces premières statistiques - temps, manipulations, erreurs - nous permettent d'avoir une idée des ressources nécessaires pour réussir la conguration d'une impression.

An d'évaluer plus complètement l'utilisabilité de cette application, il nous manque les informations concernant le degré de réalisation de chaque impression. Cette don-nées n'est malheureusement pas accessible sans test adéquat.

2.3 Conclusion

Nous présentons dans ce chapitre la notion d'utilisabilité d'une application in-formatique et la palette de méthodes permettant de l'évaluer. Nous traitons parti-culièrement des techniques d'évaluation automatique, basées sur la récupération et l'analyse automatique de données d'interaction entre l'utilisateur et l'application.

Pour illustrer notre propos, nous avons mené une étude d'utilisabilité d'une ap-plication en phase bêta, développé par Océ. Nous en présentons les résultats, obtenus à l'aide d'un outil d'analyse automatique de logs, que nous avons développé. Notre approche s'inscrit dans une perspective complémentaire aux méthodes actuellement en usage chez Océ pour l'étude d'utilisabilité des futurs produits.

Ces travaux préliminaires illustrent la diculté de la tâche de conguration d'im-pression et renforce la conviction du besoin de méthodes automatiques pour aider à la résolution de ce problème.

Chapitre 3

Conguration d'impression

Dans ce chapitre, nous analysons et modélisons l'espace des paramètres d'im-pression, an de dénir l'ensemble des congurations admissibles, connaissant les caractéristiques du document à imprimer, les contraintes et directives de l'impri-meur, ainsi que les ressources d'impression disponibles.