# Auto-archiver avec facilité dans une archive institutionnelle: microinteractions et expérience utilisateur

Sonya Betz, Robyn Hall, Nicolas Alarcon

► To cite this version:

Sonya Betz, Robyn Hall, Nicolas Alarcon. Auto-archiver avec facilité dans une archive institutionnelle : microinteractions et expérience utilisateur. 2015. hal-01222927

HAL Id: hal-01222927

https://univ-reunion.hal.science/hal-01222927v1

Preprint submitted on 13 Nov 2015

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
# AUTO-ARCHIVER AVEC FACILITÉ DANS UNE ARCHIVE INSTITUTIONNELLE :
MICROINTERACTIONS ET EXPÉRIENCE UTILISATEUR

SONYA BETZ ET ROBYN HALL
Nicolas Alarcon (Traduction)

## Résumé

Chaque détail compte, particulièrement quand il peut influencer l'investissement des usagers envers une nouvelle initiative numérique qui se base beaucoup sur leur soutien. L'Université MacEwan (Edmonton, Canada) a récemment lancé son archive institutionnelle (Ro@M), les bibliothécaires qui menaient le projet ont souhaité s'assurer que le site offrait un moyen facile et efficace de déposer des documents et ainsi assurer la viabilité de l'application sur le long terme. Cet article présente leur approche des tests d'utilisabilité en mettant en pratique le cadre des microinteractions de Dan Saffer. Il souligne les étapes suivies pour les tests et précise la procédure d'auto-archivage, mettant en lumière comment d'autres peuvent appliquer le concept de microinteractions pour mieux comprendre l'utilité et l'expérience utilisateur prodiguées par un site web.

## Introduction

Le challenge le plus important lors de l'implantation d'une archive institutionnelle est de remporter l'adhésion des chercheurs. Leur soutien est primordial pour que le partage des documents académiques via les archives soit possible, sans compter la conservation numérique à long terme de ces travaux. De nombreux mandats ont émergé dans le monde, développés par des universités, des gouvernements ou des organismes de financement. Ils ont servi à faire progresser les contributions en faisant déposer les chercheurs(1). Cependant, de nombreux gestionnaires d'archives dans les bibliothèques universitaires ne peuvent pas s'appuyer sur un mandat dans leur institution. Seulement une fraction des travaux académiques peut être déposée en raison du copyright, les auteurs ayant transféré leurs droits aux éditeurs via contrats. Le véritable challenge est de convaincre les chercheurs de trier leur travaux et d'auto-archiver ceux qui ne sont pas couverts par des restrictions juridiques.

L'utilisation de logiciels d'archives institutionnelles comme Dspace, Digital Commons ou ePrints joue assez peu dans l'amélioration de la facilité et de l'efficacité du dépôt. Dorothea Salo l'écrivait déjà dans cette critique des archives institutionnelles gérées par les bibliothèques universitaires, citation largement reprise, « la proposition "Construisons-le et ils viendront" a été manifestement fausse »(2) Elle pointe un problème majeur, les archives institutionnelles sont construites sur le « présupposé que les chercheurs déposeront, décriront et géreront leur propre production" (2, p. 100).

Sept ans après la publication de son article, une vaste majorité d'archives opérationnelles fonctionnent sur ce modèle et bataillent pour attirer un soutien massif des chercheurs (3). Pour déposer dans ces archives, les chercheurs doivent souvent remplir un formulaire en ligne et télécharger individuellement chaque document. Cela peut être une procédure laborieuse qui implique le décryptage de longs contrats de cession de droit, le renseignement d'une série de
métadonnées, et l'assurance que format et taille de fichier sont compatibles avec les prérequis de l'application.

En août 2014, les bibliothèques de l'Université MacEwan à Edmonton ont lancé l'archive institutionnelle Research Online at MacEwan (RO@M http://roam.macewan.ca). Nous espérions que la simplicité de l'interface utilisateur et la facilité de la procédure de dépôt aideraient à augmenter les contributions des chercheurs. Le site a été construit sur le logiciel open-source Islandora qui offre une certaine flexibilité aux développeurs dans l'apparence et les fonctionnalités. En essayant de trouver un équilibre entre leur désir d'indépendance dans leur activités et la facilité d'utilisation, les chercheurs et les bibliothécaires ont opté pour deux manières de déposer dans RO@M : ils peuvent choisir de remplir un rapide formulaire et de télécharger leur publication, ou ils peuvent simplement télécharger leur publication et laisser un membre de l'équipe RO@M créer les métadonnées et compléter le dépôt.

Le test minutieux de chacune des procédures était primordial pour le succès de l'archive institutionnelle. Nous voulions nous assurer qu'ils ne subsistait pas d'obstacle dans le *design* qui pourrait dissuader les chercheurs de déposer leur publication une fois qu'ils avaient décidé de se lancer dans la procédure de dépôt. L'objectif premier étant l'ajout de contenu dans l'archive et comme cela avait été signalé par d'autres institutions, notre plus haute priorité était de *designer* avec précaution chaque étape de la soumission de document. Nous nous sommes basés sur l'ouvrage de Dan Saffer *Microinterations : Designing with details* pour nous aider à focaliser nos tests sur les détails importants et fournir un cadre d'analyse pour affiner notre *design*. L'étude de cas suivante décrit notre usage des microinteractions en tant qu'approche des tests d'utilisabilité pour les bibliothèques et débat des résultats trouvés.

# Analyse de la documentation

## Expérience utilisateur et auto-archivage dans une archive institutionnelle

L'Expérience Utilisateur (UX en anglais) en bibliothèque a gagné un large écho ces dernières années et fournit un cadre utile pour explorer les manières dont les utilisateurs interagissent et se représentent les technologies que nous créons et maintenons en bibliothèque. Bien qu'il subsiste des désaccords sur sa définition et son périmètre, il semble exister un consensus sur le fait que l'UX déplace le focus de l'utilisabilité d'un produit vers des qualités moins utilitaristes comme la signification, l'affect et la valeur (4). Hassenzhal définit simplement l'UX comme "une impression d'évaluation primaire et momentanée (bon/mauvais) lorsqu'ils interagissent avec un produit ou un service"(5, p. 11). Hassenzhal, Diefenbach et Goritz avancent que les expériences émotionnellement positives avec les technologies interviennent quand l'interaction remplit certains besoins psychologiques tels que la compétence et la popularité (6). La norme ISO de 2010 sur le *design* centré-utilisateur des systèmes interactifs définit l'UX encore plus largement, suggérant qu'elle "inclut toutes les émotions, croyances, préférences, perceptions, réponses physiques et psychologiques, comportements et accomplissements de l'utilisateur qui surviennent avant, pendant et après l'utilisation" (7). Lorsque l'on crée des outils dans l'environnement des bibliothèques, il peut être difficile pour le praticien de traduire des pré-requis émotionnels ambigus, tels que la satisfaction de besoins émotionnels et psychologiques, l'accroissement de la motivation avec des résultats pragmatiques (développement d'une fonctionnalité spécifique ou le *design* de l'interface utilisateur).
La difficulté des gestionnaires d'archive à motiver les chercheurs à auto-archiver leurs travaux a été
bien documentée (8). La littérature sur la manière dont les fonctionnalités d'auto-archivage des
archives institutionnelles aident ou contraignent le soutien et l'investissement des chercheurs
n'est, en revanche, pas florissante. Une de ces études fut conduite par Kim et Kim en 2006, qui ont
mené des tests d'utilisabilité et des focus groups sur une archive institutionnelle en Corée du Sud
(9). Leurs résultats fournissent des pistes pour améliorer l'utilisabilité : éviter le jargon, fournir des
instructions compréhensibles lorsque le besoin s'en fait sentir plutôt que noyer les usagers dans
les sous-menus. Pareillement, Veiga e Silva, Goncalves et Laender rapportent des résultats de tests
d'utilisabilité conduits sur la Brazilian Digital Library of Computing, qui confirment leur objectif
premier de construire une archive facilement maîtrisable, confortable et efficace (10). Les auteurs
de ces deux études suggèrent qu'un design user-friendly peut aider à assurer le soutien actif et
durable de leur service, cependant l'usage à long terme restait à étudier. Entre temps, Bell et Sarr
recommandent l'intégration de fonctions à valeur ajoutée dans les archives institutionnelles afin
d'attirer les chercheurs (11). Leur stratégie gagnante pour refondre l'ingénierie de leur archive en
difficulté à l'Université de Rochester comprend : des outils permettant d'éditer les métadonnées et
d'ajouter/supprimer des fichiers, de fournir des portfolios où les chercheurs listent leur travaux, de
faire des liens sur leurs travaux où qu'ils se trouvent, de détailler leurs centres d'intérêt
scientifiques et de charger une copie de leur CV. La question reste ouverte quant à savoir si une
expérience utilisateur positive dans une archive institutionnelle peut constituer un facteur de
motivation significatif pour augmenter la participation des chercheurs. Il semble exister assez de
preuves pour en faire une approche viable.

Appliquer les microinteractions aux tests d'utilisabilité

L'ouvrage de Dan Saffer, *Microinteractions : Designing with Details* émerge logiquement du mouvement de l'UX. Bien qu'il utilise le terme "expérience utilisateur" avec modération, Saffer connecte constamment les technologies interactives avec l'état d'esprit émotionnel et psychologique de l'utilisateur. L'auteur se focalise sur les "microinteractions" qu'il définit comme un "moment produit et contenu tournant autour d'un seul cas d'utilisation" (12, p. 2). Saffer affirme qu'une microinteraction bien designée fait « la différence entre un produit que vous adorez et un produit que vous tolérez »(12, p. 3) Le cadre proposé par Saffer est une application efficace de la théorie de l'UX à un tâche pragmatique. Il ne place pas seulement l'état émotionnel de l'usager comme une priorité pour le design, il fournit aussi des recommandations concrètes pour designer une technologie qui engendre un état psychologique positif comme le plaisir, l'engagement et le fun.

Lorsqu'on transpose la théorie de Saffer dans le contexte des bibliothèques, il est important de
définir ce que nous entendons par « microinteractions ». Il décrit une microinteraction comme
« une petite partie d'un fonctionnalité qui fait seulement une chose ... à chaque fois que vous
changez un paramètre, synchronisez vos données ou supports numériques, que vous réglez une
alarme, choisissez un mot de passe, allumez un appareil, vous identifiez, rédigez un message de
statut, que vous mettez en favori ou likez quelque chose, vous vous engagez dans une
microinteraction »(12, p. 3). La simple dimension technologique des bibliothèques interactives
peut avoir un grand nombre de microinteractions distinctes et font souvent partie d'un écosystème
plus large de processus connectés. Par exemple, un SIGB est composé de centaines de
microinteractions designées à la fois par les utilisateurs et le personnel tandis qu'un automate de
prêt est designé d'abord pour faciliter une seule microinteraction.

Le cadre théorique de Saffer propose un nouvel angle sur la manière dont nous pouvons
interpréter les interactions des usagers au sein de notre archive institutionnelle. Nous
conceptualisons généralement nos archives comme des collections interrogeables de contenus
académiques, nous pouvons aussi les comprendre comme des collections de microinteractions. Par exemple, le cœur de **RO@M** est constitué de microinteractions qui permettent de rechercher du contenu, de naviguer dans les collections, de visualiser et télécharger du contenu, de s'identifier, de soumettre des documents et de contacter le personnel. **RO@M** inclut aussi des microinteractions dédiées au personnel : télécharger, réviser et éditer du contenu. Comme nous l'avons abordé plus haut, l'un des premiers objectifs lors du développement de notre archive institutionnelle était de permettre aux chercheurs de déposer du contenu académique comme des articles ou des articles de colloque, directement dans l'archive. Nous voulions que cette procédure soit simple et intuitive et que les chercheurs aient certains contrôles sur les mots-clés ou d'autres métadonnées tout en requérant le minimum d'efforts. Nous avons décidé de mettre en place des tests d'utilisabilité pour examiner attentivement la procédure de dépôt comme une microinteraction distincte. Nous avons aussi appliqué le cadre théorique de Saffer comme un moyen d'évaluer à la fois la fonctionnalité et l'UX. Nous espérions que se focaliser sur les détails de cette microinteraction nous permettrait de faire des choix de design prudents et avisés qui déboucheraient sur une UX cohérente et agréable.

## Méthode et étude de cas

Nous avons mené deux sessions de tests d'utilisabilité pour la procédure d'auto-archivage. Notre test initial a été conduit en janvier 2014. Nous avons demandé à 7 chercheurs de réviser et commenter un brouillon de formulaire de dépôt pour tester le workflow. Ce simple exercice nous a permis de confirmer les étapes de la procédure de téléchargement et d'identifier quelques problèmes critiques que nous avons pu résoudre avant de construire l'archive avec Islandora. Après avoir complété le développement de notre outil et une copie du site installée sur notre serveur de test, nous avons conduit une seconde session de tests d'utilisabilité approfondis avec notre nouveau cadre de microinteractions.

En avril 2014, nous avons recruté 6 chercheurs grâce au bouche-à-oreille et à un appel à participation diffusé sur la newsletter électronique hebdomadaire de l'université. Les volontaires représentaient les disciplines majeurs de l'Université MacEwan, dont les sciences de la santé, les sciences sociales, les humanités et les sciences naturelles. Saffer suggère que le moyen le plus pertinent de tester les microinteractions est d'inclure « des centaines (si ce n'est des milliers) de participants » (12, p. 142). Cependant, il poursuit en décrivant les méthodes les plus efficaces comme étant qualitatives (conversation, entretien et observation). Tester des milliers de participants lors d'un entretien en face-à-face ou une session d'observation est bien au-dessus des moyens de la plupart des bibliothèques académiques et va à l'encontre de la méthodologie des tests d'utilisabilité. Tester seulement six participants peut sembler assez peu, susceptible de fournir des résultats non-concluants et gêner le feedback, c'est poutant hautement recommandé par les experts en utilisabilité comme Jakob Nielsen. Durant nos tests, nous nous sommes rapidement référés à ce que Nielsen évoque dans son billet « Combien de testeurs dans un test d'utilisabilité » comme le « point de rendement décroissant » (13). Il suggère que cinq testeurs est en fait un nombre tout à fait convenable selon la plupart des études qualitatives visant à étudier le design d'un site et son UX. Nous approuvons cette recommandation sur la base de notre propre expérience ; à partir du 4e participant, nous recevions des retours très répétitifs sur ce qui marchait correctement et ce qui devait être changé.

Les tests se sont déroulés dans le propre bureau même des chercheurs sur leur propre ordinateur afin qu'ils interagissent avec le site comme ils l'auraient fait au quotidien. Chaque session de test a duré entre 45 et 60 minutes et a été facilitée par trois membres de l'équipe **RO@M**: le bibliothécaire web/UX guidait chaque chercheur à travers le test, le bibliothécaire chargé de la
communication académique observait les interactions et un technicien prenait des notes détaillées sur les commentaires et actions du participant. Chaque chercheur devait déposer un de ses articles sur le serveur de test. L'équipe RO@M a observé attentivement tout le processus, en notant particulièrement toute interaction problématique tout en encourageant le testeur à penser à voix haute. Une fois le test terminé, la bibliothécaire chargée de la communication académique analysait les notes et identifiait les problèmes et confusions des participants aussi bien que les suggestions d'amélioration. Des modifications étaient apportées au site à partir de ces retours. Comme nous le verrons dans la prochaine section, chaque tâche réalisée par les chercheurs, facile ou frustrante, représentait une interaction avec l'interface utilisateur qui affectait l'expérience des participants et nous informait des changements que nous pourrions faire avant le lancement de l'archive institutionnelle trois mois plus tard.

## Les éléments de base des microinteractions

La théorie de Saffer décrit 4 composants primaires pour une microinteraction : l'amorce, les règles, le feedback et les boucles/modes. En considérant le dépôt dans une AO comme une microinteraction devant être efficace et user-friendly, nous devions identifier chacun de ces composants en fonction de leur rapport à la procédure (voir Figure 1) et ensuite évaluer l'outil dans sa globalité à travers le test d'utilisabilité.
<figure><img src="image_2.png" /><figcaption>Figure 1 : Procédure d'auto-archivage dans l'AO et composants de la microinteraction</figcaption></figure>

Le premier composant à examiner dans une microinteraction est l'amorce qui est simplement « tout ce qui initie la microinteraction » (12, p. 48). Sur un iPhone, l'amorce pour une application pourrait être l'icône qui permet de la lancer ; sur un lave-vaisselle, l'amorce serait le bouton utilisé pour démarrer la machine ; sur un site web, l'amorce pourrait être le bouton d'identification ou un item du menu. Des amorces bien designées suivent les principes d'une bonne utilisabilité : ils apparaissent quand et où les usagers ont besoin d'eux, ils initient la même action à chaque fois et ils agissent de manière prévisible (par exemple, un bouton se presse).

L'examen de l'amorce était la première étape pour évaluer à quel point notre microinteraction de dépôt était correctement designée. Télécharger et ajouter du contenu est une fonction primaire des archives institutionnelles et l'amorce avait besoin d'être particulièrement visible. Nous pouvons affirmer que les usagers essayent de suivre des objectifs dans leur approche d'une archive ; les chercheurs visiteraient le site avec le but spécifique de télécharger du contenu et rechercheraient en premier lieu l'amorce pour démarrer l'interaction qui leur permettrait de le faire.
Le design initial de RO@M incluait un menu en haut de page comme seule amorce pour participer au dépôt. Dans le menu de navigation supérieur et persistant, les utilisateurs pouvaient cliquer sur l'item intitulé « Contribuer » où ils étaient orientés vers un écran d'identification pour commencer. Ce fut immédiatement évident pour la moitié des testeurs. La seconde moitié a tout de suite cliqué sur le mot « Partager » qui apparaissait dans la moitié inférieure de la page à côté d'une petite icône, utilisée comme apport esthétique sur la page d'accueil au côté des termes « Découvrir » et « Préserver ». Sans surprise, les utilisateurs ont interprété les termes et les icônes comme une amorce. En fonction du comportement que nous avons pu observer, nous avons décidé d'ajouter des liens sur les trois termes, « Partage » lié à l'écran d'identification pour le dépôt (voir Figure 2), « Découvrir » lié à la page de navigation dans les collections et « Préserver » lié à la FAQ pour auteurs qui proposait des informations sur la préservation numérique. Cela a augmenté significativement la visibilité de l'amorce pour la microinteraction.

<figure><img src="image_3.png" /><figcaption>Figure 2 : "Partager" comme amorce additionnelle pour le dépôt</figcaption></figure>

## Règles

Le deuxième composant des microinteractions décrit par Saffer sont les règles, c'est-à-dire les paramètres qui dirigent les microinteractions ; elles fournissent un cadre de compréhension pour aider les utilisateurs à atteindre leurs objectifs en lien avec la microinteraction. Les règles sont définies comme « *ce qu'on peut et ne peut pas faire et dans quel ordre* » (12, p. 82). Alors que les usagers n'ont pas besoin de connaître l'ingénierie derrière un automate de prêt, par exemple, ils ont besoin de comprendre ce qu'ils peuvent et ne peuvent pas faire lorsqu'ils utilisent la machine. Le hardware et le software d'un automate de prêt est *designé* pour mettre en œuvre les règles, en encourageant les utilisateurs à scanner leur carte pour démarrer la machine, à aligner leurs livres ou vidéos pour qu'ils soient scannés et démagnétisés et pour indiquer à quel moment ils ont achevé l'interaction.

Lorsque nous avons *designé* une procédure d'auto-archivage dans RO@M, le but était de s'assurer que les règles étaient faciles à comprendre, suivaient une structure logique et n'étaient pas trop
complexes. À cette fin, nous avons fait appel à l'approche de Saffer pour designer les règles des microinteractions, accompagnée de la philosophie mise en œuvre par Steve Krug dans son ouvrage influent sur le web design : *Don't Make Me Think : A Common Sense Approach to Web Usability* (14). Krug et Saffer plaident pour la réduction de la complexité et la suppression des prises de décisions pour les usagers, si possible, afin de supprimer les erreurs potentielles de leur part. Les règles dans RO@M suivent une approche formulaire standard; les utilisateurs se connectent, ils acceptent les contrats de licence, ils créent des métadonnées pour leur document et ils téléchargent le fichier (voir Figure 1). Déterminer l'ordre de chaque élément et s'assurer que les utilisateurs pouvaient comprendre comment remplir un formulaire avec succès a demandé un réflexion minutieuse, ce qui a été largement attesté par les tests menés.

Par exemple, nous avons conçu RO@M pour être connecté aux mêmes systèmes d'identification utilisés par les autres applications de l'université, s'assurant ainsi que les chercheurs pouvaient s'authentifier avec les identifiants qu'ils utilisent quotidiennement pour le mail institutionnel ou l'accès au réseau. Forcer les chercheurs à créer et se souvenir d'un identifiant/mot de passe pour soumettre du contenu aurait augmenté les possibilités d'erreur d'identification et engendré confusion et frustration. Nous avons également laissé tomber certaines métadonnées lorsque cela était possible au lieu de demander aux chercheurs d'entrer des données comme le type de fichier, le nom de la faculté ou du département ou le type de contenu dans des champs libres.

Durant les tests, nous avons trouvé que les champs où les métadonnées étaient entrées sous forme de texte libre menaient le plus souvent à la confusion et l'erreur. Par exemple, il est rapidement apparu que l'autorité-auteur serait un problème. Au moment de remplir le champ Auteur, certaines personnes utilisaient des initiales, d'autres le deuxième prénom, d'autres enfin ajoutaient Dr avant leur nom, ce qui pouvaient affecter négativement les résultats de recherche et la capacité à tracer où et quand ces travaux étaient cités. Lorsque nous avons demandé d'inclure les références bibliographiques de la publication, la plupart des participants ont été frustrés parce qu'ils ne pouvaient le faire aussi rapidement qu'ils le souhaitaient. Ils ont également eu des problèmes avec la création d'une référence bibliographique correcte. Finalement, plusieurs participants ont été désorientés par le dernier champ optionnel du formulaire qui leur permettait de choisir une licence Creative commons pour leur publication.

Nos tests ont montré que nous devions être attentif à la manière dont les informations comme le nom des auteurs et les références étaient entrées par les utilisateurs avant de rendre disponible un document sur le site. Idéalement, nous aurions dû modifier le formulaire pour s'assurer que les informations sur l'utilisateur connues du système soient intégrées : ce que Saffer appelle « Ne commencez pas de zéro » (12, p. 64) Cela peut inclure de remplir automatiquement des détails comme le nom de l'utilisateur. Cependant, comme beaucoup de bibliothèques nous avons choisi d'adapter un logiciel existant plutôt que de développer notre microinteraction du départ ; implémenter de tels changements aurait été trop chronophage et coûteux. En réponse, nous avons ajouté à la place un worflow additionnel qui permet aux administrateurs d'éditer les métadonnées avant qu'une contribution soit publiée sur le web, nous pouvons ainsi corriger les erreurs. Nous avons également changer le champ «Référence bibliographique» en « Information sur la publication » indiquant que les utilisateurs n'ont pas besoin de le remplir complètement. Enfin, nous nous sommes assurés que « Tous droits réservés » était le choix par défaut pour le champ optionnel « Ajouter une licence Creative commons » du formulaire, c'est un terme familier pour nos utilisateurs et une manière de faire rassurante.

Les contraintes politiques sont un autre aspect des règles qui déterminent la structure autour des microinteractions et qui peuvent aussi limiter les choix de design. Un pré-requis de nos règles était de faire compléter aux chercheurs un accord de licence non-exclusive qui assurait qu'ils disposaient des droits de copyright appropriés pour soumettre leur travaux. Sans cet accord, nous
risquerions d'être responsable de violations du copyright et nous ne pouvions accepter le contenu dans notre archive institutionnel. Nos premiers designs de l'archive intégrait cette étape à la fin de la procédure de dépôt, après que les chercheurs aient créé les métadonnées de leur document. Nos sessions initiales de tests ont révélé que plusieurs participants n'étaient pas sûr d'avoir les droits pour ajouter du contenu et ne voulaient pas poursuivre le dépôt, une expérience frustrante pour eux après avoir passé du temps à remplir les informations sur les auteurs, les mots-clés, le résumé et tout le reste. Nous avons essayé de résoudre ce problème en déplaçant l'accord plus tôt dans la procédure, forçant les utilisateurs à prendre connaissance de l'accord avant de créer les métadonnées. Nous avons aussi utilisé un langage simple et direct pour l'accord, ajouté des informations additionnelles sur la manière de déterminer le copyright et le contact RO@M pour toute assistance. Nous envisageons d'intégrer une API qui recherche automatiquement les politiques d'archivage des revues dans SHERPA/ROMEO à ce niveau de la procédure de dépôt, afin de réduire la complexité pour nos utilisateurs.

Feedback

Comprendre le concept de feedback est primordial pour le design des microinteractions. Si les bibliothèques sont familières de la collecte des feedbacks de la part de leurs usagers, celui défini par Saffer va dans la direction opposée et fait référence au feedback que l'application ou l'interface fournit à l'utilisateur. Il donne des informations à l'utilisateur quand et où ils ont besoin d'être aidé dans la microinteraction. Comme le dit Saffer : « *le véritable but du feedback est d'aider l'utilisateur à comprendre comment les règles de la microinteraction fonctionnent* » (12, p. 86)

Le feedback peut transiter par différents chemins. Une action aussi simple qu'un changement de couleur quand l'utilisateur passe au-dessus d'un lien est une forme de feedback, en fournissant une information visuelle qui indique que du texte est cliquable. Les messages de confirmation sont une forme évidente de feedback alors qu'un dossier affichant le nombre d'items ajoutés est plus subtil. Les feedbacks visuels sont les plus utilisés, Saffer décrit pourtant des cas où le feedback auditif et haptique (toucher) peuvent être utiles. *Designer* des feedbacks, comme *designer* des règles devraient cibler la réduction de la complexité et de la confusion pour l'usager et être explicitement connecté à la fois fonctionnellement et visuellement à ce que l'usager à besoin de savoir.

Dans un environnement web, une grande partie des feedbacks proposés à l'usager devrait être basée sur de bons principes d'utilisabilité. Par exemple, le feedback peut être conçu dans le *design* : en formatant les liens de manière cohérente et en fournissant des éléments prévisibles de navigation. Il est aussi crucial de proposer des feedbacks selon les besoins des utilisateurs. C'était particulièrement important pour nos testeurs sur RO@M. La section « A propos » de notre archive institutionnelle, accessible dans la navigation permanente en haut du site contenait des instructions détaillées et des informations sur comment soumettre ses travaux et sur les conditions d'usages de ces soumissions. Ce contenu était virtuellement invisible pour les utilisateurs observés. A la place, ils se fiaient beaucoup au feedback contextuel (lorsque visible) proposé durant le processus.

Ces observations nous ont amené à repenser notre manière de proposer des feedbacks dans plusieurs cas. Par exemple, en raison d'une contrainte malheureusement imposée par notre logiciel, nos utilisateurs sont obligés de choisir une faculté ou école et un département puis cliquer sur « Ajouter » avant de sauvegarder et continuer. Nous avons ajouté des instructions au-dessus du menu déroulant, indiquant « Sélectionner et cliquer sur Ajouter » afin de prévenir les erreurs.
Pourtant, nos participants ont manqué l'instruction et ont inévitablement activé un bref message d'erreur (voir Figure 3). Plus tard, nous avons changé la couleur du terme « Ajouter » dans l'instruction de noir à rouge brillant dans l'espoir d'augmenter sa visibilité. Nous nous sommes également assurés que le message d'erreur affiché quand l'utilisateur oubliait d'ajouter expliquait clairement comment corriger le problème et passer à la suite. Nous avons observé également que le bouton « + » pour ajouter des auteurs et des mots-clés n'était pas visible des utilisateurs. Nous avons ajouté du texte et des icônes plus détaillés (voir Figure 4). Cependant, cela reste un problème pour nos utilisateurs que nous devons explorer. Après avoir achevé son dépôt, les utilisateurs accèdent à une page de confirmation qui les remercie de leur contribution, à une chronologie qui indique quand leur document sera visible sur le site et prévient qu'ils recevront un email lorsque ce sera le cas. Le feedback sur cette page était positive car elle reprenait toutes les informations que les utilisateurs pensaient nécessaires à la fin de leur dépôt.

<figure><img src="image_4.png" /><figcaption>Figure 3 : feedback sur le bouton "Ajouter"</figcaption></figure>
Step 4: Item Information

<figure><img src="image_5.png" /><figcaption>Author(s) or Creator(s)</figcaption></figure>

<figure><img src="image_6.png" /><figcaption>Year</figcaption></figure>

<figure><img src="image_7.png" /><figcaption>Faculty Advisor or Mentor</figcaption></figure>

<figure><img src="image_8.png" /><figcaption>Keywords</figcaption></figure>

<figure><img src="image_9.png" /><figcaption>Figure 4 : feedback sur l'ajout de multiples auteurs et mots-clés</figcaption></figure>

Modes et boucles

Les deux derniers composants des microinteractions définies par Saffer sont les modes et les
boucles. Saffer définit un mode comme un « *embranchement dans les règles* » ou un point dans la
microinteraction où l'utilisateur est confronté à un nouveau processus, interface ou état (12,
p. 111). Par exemple, Google Scholar propose à ses utilisateurs un paramétrage pour afficher les
« liens d'accès des bibliothèques » pour activer les résolveurs de liens (15). Les utilisateurs qui ont
choisi cette option voient une page de résultats différentes de la page par défaut qui propose des
liens supplémentaires vers le résolveur de leur institution. Notre microinteraction comprend deux
modes distincts. Une fois identifiés, les utilisateurs peuvent choisir de déposer leur travaux avec la
soumission « Do-it-Yourself » que nous avons décrite précédemment ou ils peuvent choisir le
dépôt « Laissez nous faire » et compléter une version simplifiée qui leur demande de connaître la
licence, télécharger le fichier et fournir dans un champ de texte libre toute donnée additionnelle
qu'ils estiment nécessaire (voir Figure 5). La majorité de nos testeurs ont signalé qu'ils auraient
opté pour « Do It Yourself » afin d'avoir la maîtrise sur les métadonnées décrivant leurs travaux,
(résumé, mots-clés). Pourtant, depuis le lancement de l'archive, plusieurs soumissions sont
arrivées via le mode « Laissez nous faire », ce qui montre un certain intérêt pour cette option.
<figure><img src="image_10.png" /></figure>

RO@M
Research Online at MacEwan

Home About Browse Contribute Contact

Search RO@M

search

Home |

Step 1: Licensing

Not sure if you hold copyright? Contact us with information about your work (e.g., title, publisher). We will look into it and get back to you.

You can also look up journal archiving policies, review publication agreements, or contact rights holders directly. Learn more.

Licensing Information

RO@M Non-Exclusive Distribution Licensing Agreement *

I hold the copyright to this work and grant permission for posting it in the Research Online at MacEwan (RO@M) institutional repository, or have the approval of the copyright holder to do so, and agree that it may be made available to the public.

I warrant that the posting of the work does not infringe any copyright, nor violate any proprietary rights, nor contain any libelous matter, nor invade the privacy of any person or third party, nor otherwise violate RO@M Terms of Use.

Accept *

<figure><img src="image_11.png" /></figure>

MacEwan University | Library | Research Services
© 2014 MacEwan University Library

<figure><img src="image_12.png" /><figcaption>Figure 5 : Le formulaire "Laissez Nous Faire"</figcaption></figure>

Les boucles, d'un autre côté, sont simplement la répétition d'un cycle de microinteractions. Une boucle peut être une procédure qui tourne en arrière-plan, vérifiant les connections au réseau ou une procédure plus visible qui s'adapte en fonction du comportement de l'utilisateur. Par exemple, dans le procédure de dépôt de RO@M, les utilisateurs peuvent avancer ou reculer dans le formulaire. Les boutons « Précédent » et « Sauvegarder et continuer » sur chaque page facilitent la navigation. L'étape finale du formulaire « Do It Yourself » permet aux utilisateurs de revoir les métadonnées et le fichier téléchargé. Ils peuvent utiliser le bouton « Précédent » pour effectuer des changements sur ce qu'ils ont entré, avant de terminer la soumission. Idéalement, les utilisateurs devraient pouvoir modifier directement les données depuis le récapitulatif mais les contraintes du logiciel nous ont empêché d'inclure cette fonctionnalité. Le bouton « Précédent » n'a pas posé de problèmes majeurs à nos testeurs. Autre exemple de boucle dans RO@M, le bouton « Déposer un autre document » disponible sur l'écran de confirmation permet aux usagers de revenir au début de la microinteraction. Cette fonctionnalité a été suggérée par l'un des participants, elle étend la durée de vie de la microinteraction et peut mener potentiellement à d'autres contributions.

Discussion et conclusions

Se focaliser sur les détails du processus d'auto-archivage de notre archive institutionnelle nous a permis d'obtenir des données qualitatives extrêmement riches pour améliorer l'interface utilisateur. D'autre part, l'analyse de la structure des microinteractions en suivant le modèle de Saffer constituerait un exercice pour réfléchir aux besoins des usagers et au design de l'application à partir d'un point de vue différent des tests habituels. Les améliorations faites à partir de la théorie de Saffer et des résultats des tests ont apporté des fonctionnalités significatives et une facilité

<figure><img src="image_13.png" /></figure>
d'utilisation à la procédure d'auto-archivage. Penser soigneusement les éléments comme le
positionnement des boutons, les changements mineurs dans la terminologie ou le circuit et la
bonne synchronisation des instructions ou des feedbacks d'erreur montrent à quel point les petits
éléments peuvent avoir de grands effets sur l'utilisabilité.

Il y a pourtant des limitations à la théorie et à notre approche des tests qui influent sur la manière
de comprendre et d'utiliser nos résultats. En particulier, la manière dont les tests enregistrent
l'expérience utilisateur d'un chercheur au-delà de l'utilité ou de la facilité d'utilisation d'une
interaction. Avec l'observation, on peut se fier aux commentaires des participants et aux
déclarations-clés qui renseignent son état émotionnel ou affectif, mais nous n'avons pas inclus de
questions ciblées pour recueillir ces données, nous avons préféré nous concentrer sur le détail
des microinteractions. Nous ne leur avons pas demandé comment ils se sentaient en utilisant
l'archive ou si télécharger avec succès un document leur donnait un sentiment d'autonomie et de
compétence ou si l'expérience les encourageait à soumettre à nouveau dans le futur. Néanmoins,
améliorer l'utilisabilité est le meilleur moyen de fournir une expérience utilisateur positive.
Hassahzhal décrit la différence entre un objectif-faire (remplir une tâche) et un objectif-être (les
humains ont psychologiquement besoin d'être compétent ou de développer des relations) (5).
Selon lui, les objectifs-être sont les stimuli ultimes de l'UX, il suggère aussi que créer des outils qui
rendent l'objectif-faire facile à atteindre peut rendre l'objectif-être plus atteignable en supprimant
les barrières. Au final, une stratégie de tests d'utilisabilité peut mener à l'amélioration de
l'interface utilisateur, si ces tests s'appuient sur un examen précis des microinteractions, une
analyse des nombreux jeux de données produits par Google Analytics ou des entretiens avec les
groupes-clés d'usagers. La théorie des microinteractions représente une approche utile et valable
dans sa conceptualisation, elle devrait pourtant être l'un des nombreux outils que les
bibliothèques devraient adopter pour améliorer leur UX en ligne

Pareillement, se concentrer sur l'UX de l'archive ne devrait être que l'un des nombreux moyens
déployés pour améliorer le taux d'auto-archivage des chercheurs. De récentes études montrent
qu'en dépit de la plateforme ou du processus, les dépôts à l'initiative des chercheurs restent une
chose inhabituelle (16). Elles suggèrent que la soutenabilité provient du marketing, des contacts
directs avec les chercheurs et d'un engagement du personnel dans l'identification du contenu à
déposer, l'étude des droits et le dépôt au nom du chercheur. Se fier seulement au design user-
friendly d'un site web, à la production de matériel promotionnel ou aux efforts pour rencontrer les
chercheurs pour assurer le succès de l'archive ne serait voir qu'à court terme. Le maintien de
l'accompagnement est un processus continue et multifacette. Il dépend largement de la culture
académique de l'institution aussi bien que des ressources financières et humaines. Les tests des
usagers offrent un aperçu de qualité sur la manière dont les processus et les fonctions pourraient
être améliorés afin d'assurer la viabilité de ce type d'initiatives.
Bibliographie

1. Welcome to ROARMAP - ROARMAP. [en ligne]. [Consulté le 3 octobre 2015]. Disponible à l'adresse : http://roarmap.eprints.org/

2. SALO, Dorothea. Innkeeper at the Roach Motel. *Library Trends*. 2008. Vol. 57, n° 2, pp. 98-123. DOI 10.1353/lib.0.0031. <p>Volume 57, Number 2, Fall 2008</p>

3. OpenDOAR - Home Page - Directory of Open Access Repositories. [en ligne]. 6 septembre 2006. [Consulté le 29 septembre 2015]. Disponible à l'adresse : http://www.opendoar.org/OpenDOAR est un authoritative worldwide directory of academic open access repositories.

4. LAW, Effie Lai-Chong, ROTO, Virpi, HASSENZAHL, Marc, VERMEEREN, Arnold P.O.S. et KORT, Joke. Understanding, Scoping and Defining User Experience: A Survey Approach. In : *Proceedings of the SIGCHI Conference on Human Factors in Computing Systems* [en ligne]. New York, NY, USA : ACM, 2009. pp. 719–728. [Consulté le 29 septembre 2015]. CHI '09. ISBN 978-1-60558-246-7. Disponible à l'adresse : http://doi.acm.org/10.1145/1518701.1518813

5. HASSENZAHL, Marc. User Experience (UX): Towards an Experiential Perspective on Product Quality. In : *Proceedings of the 20th International Conference of the Association Francophone D'Interaction Homme-Machine* [en ligne]. New York, NY, USA : ACM, 2008. pp. 11–15. [Consulté le 29 septembre 2015]. IHM '08. ISBN 978-1-60558-285-6. Disponible à l'adresse : http://doi.acm.org/10.1145/1512714.1512717

6. HASSENZAHL, Marc, DIEFENBACH, Sarah et GÖRITZ, Anja. Needs, affect, and interactive products – Facets of user experience. *Interacting with Computers*. 9 janvier 2010. Vol. 22, n° 5, pp. 353-362. DOI 10.1016/j.intcom.2010.04.002.

7. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. *Human-centred design processes for interactive systems = Processus de conception centrée sur l'opérateur humain pour les systèmes interactifs*. [Geneva, Switzerland] : International Organization for Standardization, 1999.

8. DAVIS, Philip M. et CONNOLLY, Matthew J. L. Institutional Repositories: Evaluating the reasons for non-use of Cornell University's installation of DSpace. [en ligne]. mars 2007. [Consulté le 29 septembre 2015]. Disponible à l'adresse : http://ecommons.cornell.edu/handle/1813/5195

9. HEE KIM, Hyun et HO KIM, Yong. Usability study of digital institutional repositories. *The Electronic Library*. 14 novembre 2008. Vol. 26, n° 6, pp. 863-881. DOI 10.1108/02640470810921637.

10. VEIGA E SILVA, Lena, GONÇALVES, Marcos André et LAENDER, Alberto H. F. Evaluating a digital library self-archiving service: The BDBComp user case study. *Information Processing & Management*. juillet 2007. Vol. 43, n° 4, pp. 1103-1120. DOI 10.1016/j.ipm.2006.07.023.

11. BELL, Suzanne et SARR, Nathan. Case Study: Re-Engineering an Institutional Repository to Engage Users. *New Review of Academic Librarianship*. 19 octobre 2010. Vol. 16, n° sup1, pp. 77-89. DOI 10.1080/13614533.2010.509517.

12. SAFFER, Dan. *Microinteractions : Designing with Details* [en ligne]. Beijing; Cambridge :
O'Reilly, 2013. [Consulté le 29 septembre 2015]. ISBN 1-4493-4268-X. Disponible à l'adresse :
https://ezproxy.saskpolytech.ca/login?url=http://proquest.safaribooksonline.com/9781491945957

13. NIELSEN, Jakob. How Many Test Users in a Usability Study? *Nielsen Norman Group* [en ligne]. 4 juin 2012. [Consulté le 29 septembre 2015]. Disponible à l'adresse :
http://www.nngroup.com/articles/how-many-test-users/

14. KRUG, Steve. *Don't make me think!: a common sense approach to Web usability*. Berkeley, Calif : New Riders Pub., 2006. ISBN 0-321-34475-8.

15. Assistance Google Scholar destinée aux bibliothèques. [en ligne].
[Consulté le 3 octobre 2015]. Disponible à l'adresse :
https://scholar.google.com/intl/fr/scholar/libraries.html

16. DUBINSKY, Ellen. A Current Snapshot of Institutional Repositories: Growth Rate, Disciplinary Content and Faculty Contributions. *Journal of Librarianship and Scholarly Communication* [en ligne]. 2014. Vol. 2, n° 3. [Consulté le 29 septembre 2015]. DOI 10.7710/2162-3309.1167. Disponible à l'adresse : http://jlsc-pub.org/articles/10.7710/2162-3309.1167

**Sonya Betz** (*sonya.betz@ualberta.ca*) est bibliothécaire en charge du Projet dess initiatives numériques, Bibliothèques de l'Université de l'Alberta, Université de l'Alberta, Edmonton, Alberta.

**Robyn Hall** (*HallR27@macewan.ca*) est bibliothécaire responsable des communications académiques, Bibliothèque de l'Université MacEwan, Université de MacEwan, Edmonton, Alberta

Traduction en français : **Nicolas Alarcon** (*alarcon.nicolas@gmail.com), chef de projet Open Access et responsable Évaluations et indicateurs à l'Université de La Réunion (France)

<figure><img src="image_14.png" /></figure>