Interopérabilité des images : de la nécessité des tests d’utilisabilité

Interopérabilité des images : de la nécessité des tests d’utilisabilité
Introduction

La numérisation de masse en haute qualité des collections patrimoniales a ouvert de nouvelles possibilités de diffusion et d’utilisation des contenus au sein de l’industrie des GLAM (Galleries, Libraries, Archives, Museums). Contrairement aux métadonnées, les images, vecteurs d’informations provenant de sources primaires et secondaires, n’ont historiquement pas fait l’objet d’un protocole ou d’une norme pour partager et moissonner ces données entre différentes institutions et entrepôts.

Cette lacune a été comblée grâce à l’avènement du cadre international d’interopérabilité des images (International Image Interoperability Framework – IIIF[1]). IIIF est une initiative communautaire qui désigne autant une communauté qu’un ensemble d'interfaces de programmation applicative (application programming interface – API) spécifiant des fonctionnalités d'interopérabilité pour les entrepôts d'images numériques.  Ces API permettent de développer un écosystème de serveurs et de clients capables de décloisonner les silos et d’exposer plus facilement des images numériques sur le Web.

Les institutions célèbres qui ont notamment mis en oeuvre des solutions conformes aux spécifications de IIIF sont la British Library, La Bibliothèque nationale de France (BnF), les universités d’Oxford, de Harvard et de Stanford. En Suisse, la plus grande collection conforme aux standards de IIIF, et ceci depuis décembre 2014, est e-codices, la Bibliothèque virtuelle des manuscrits. Si les API de IIIF sont majoritairement déployées au sein des institutions patrimoniales et de recherche, elles peuvent également être utilisées et appliquées pour tout type d’organisation voulant mettre à disposition de leur public des images numériques. Les humanités numériques et la communauté scientifique au sens large ont notamment commencé à rejoindre la communauté IIIF.

En dehors des avantages institutionnels, l’un des buts de IIIF est de fournir une expérience utilisateur (UX) de grande qualité par le biais des interfaces clients ou visionneuses compatibles avec les spécifications techniques. Cependant, seules quelques méthodes de conception centrées sur l’utilisateur (user-centred design – UCD) ont été réalisées par les développeurs ou les responsables et curateurs de collections ayant déployé IIIF.

Depuis octobre 2016, le projet nommé « Infrastructure nationale pour les éditions » (NIE-INE) vise à construire une plateforme nationale sur le Web pour les éditions scientifiques. Comme le projet NIE-INE a de nombreux intérêts communs avec IIIF et aussi parce que les membres du projet ont commencé à réfléchir à leur architecture technique, des tests d'utilisabilité ont été effectués sur les visionneuses Universal Viewer (UV) et Mirador. Les futurs utilisateurs de la plateforme de NIE-INE et, plus largement, les chercheurs des humanités numériques ont été désignés comme le public cible des tests d’utilisabilité. A partir d’une revue de la littérature et des résultats des tests, il a pu être déterminé à quel point les standards IIIF peuvent s’appliquer au projet NIE-INE et aux communautés scientifiques similaires.

Contexte

Trois objectifs ont été définis au sein du travail de bachelor :

• Mener des tests d’utilisabilité sur UV et Mirador en évaluant principalement la satisfaction et l’efficience d’utilisation

• Fournir une description exhaustive de IIIF pour attirer des nouvelles institutions souhaitant rejoindre cette communauté, notamment en Suisse

• Evaluer l’intérêt de déployer des solutions technologiques conformes aux standards de IIIF sur des plateformes diffusant des éditions scientifiques.

A la suite de ces objectifs, une question de recherche principale a été identifiée : « Comment la communauté scientifique de Suisse, en particulier les chercheurs travaillant sur les éditions scientifiques, peut-elle bénéficier des technologies sous-jacentes de IIIF ? »[2].

Utilisabilité et concepts connexes 

Préalablement à la méthodologie et au travail empirique des tests d’utilisabilité, il était impératif de dresser une revue de la littérature sur l’utilisabilité[3] (usability) ainsi que les concepts autour de l’UX et de l’UCD.

L’utilisabilité

L’utilisabilité est une notion multidimensionnelle et qui ne peut être réduite à un système étant « facile d’utilisation » (Quesenbery, 2001) car ce dernier attribut n’est qu’une de ces nombreuses caractéristiques. Dans le tableau ci-dessous, trois dimensions ont été retenues.

Tableau 1: Les dimensions de l’utilisabilité[5]

(Nielsen, 1993 ; ISO, 2017 ; Quesenbery, 2001)

L’utilité

Selon Nielsen (1993, p. 24‑25), l’utilité pratique (usefulness) est une équation entre l’utilité théorique (utility) et l’utilisabilité (usability).  Il définit un système utile (useful) si ce dernier « (…) est utilisé pour atteindre certains objectifs souhaités »[6].

Afin d’évaluer les bibliothèques numériques en Open Access, le modèle triptyque de l’interaction (Interaction triptych framework - ITF), regroupant trois axes dont l’utilité pratique et l’utilisabilité, a été conçu (Tsakonas, Papatheodorou, 2008, p. 1237‑1239). Sur le modèle de l’ITF (voir Figure 1), l’axe de l’utilité est placé entre le contenu et les utilisateurs alors que l’utilisabilité est une interaction entre les utilisateurs et le système (Hügi, Schneider, 2013).

Figure 1 : Interaction tryptich framework (ITF)

(Tsakonas, Papatheodorou, 2008)

L’expérience utilisateur (UX)

L’UX est un concept plus large que l’utilisabilité car il couvre toutes les facettes de l’interaction d’un utilisateur final avec un système donné (Norman, Nielsen, 2007). Globalement, l’UX est « (…) tout ce qui touche à l’expérience d’une personne avec un produit [7]» (NNgroup, 2016).

Afin d’aller au-delà de l’utilisabilité, Peter Morville (2004) a démontré à l’aide d’une visualisation en nid d’abeilles (UX Honeycomb) que l’UX se composait de sept composantes ou qualités. Ces hexagones (voir Figure 2 ci-dessous) peuvent parfois s’appliquer au domaine de l’utilisabilité (usable, findable, accessible) ou de l’utilité (credible, desirable, useful). Le concept central de cette visualisation, et par extension de l’UX, est ce qui a de la valeur (ce qui est valuable).

Figure 2 : Les qualités de l'UX selon Peter Morville

(Morville, 2004)

La conception centrée sur l’utilisateur (UCD)

L’UCD est une philosophie, de conception d’un système qu se base sur les besoins et les attentes des utilisateurs finaux (ISO, 2010, § 2.7). Les méthodes applicables sont itératives et peuvent être appliquées à chaque étape d’une implémentation d’un produit.

Le but de l’UCD est de rendre les systèmes plus utilisables, de réduire le stress que rencontrent les utilisateurs, ainsi que de diminuer le nombre potentiel d’erreurs qu’un utilisateur pourrait effectuer sur une interface donnée.

Synthèse des concepts présentés

Dans le tableau 2 ci-dessous se trouve une synthèse des différents concepts autour de l’utilisabilité. Dans la troisième colonne, il y a également l’application que ces notions ont eues tout le long du mandat.

Tableau 2 : Définitions et pertinence des concepts par rapport au mandat

(Quesenbery, 2001 ; Nielsen, 1993 ; Tsakonas, Papatheodorou, 2008 ; NNgroup, 2016 ; ISO, 2010)

International Image Interoperability Framework (IIIF)
La communauté IIIF

L'initiative IIIF a démarré en Californie en 2011 après un rassemblement informel de développeurs et de bibliothécaires des universités de Stanford, d'Oxford, et de la British Library. Ils ont tous admis que la diffusion d'images sur le Web dans le domaine culturel n'était pas du tout satisfaisante car il n'y avait aucun consensus viable pour livrer et échanger les images numériques entres les différents acteurs du milieu (Cramer, 2016). Bien souvent, les interfaces n'étaient pas esthétiques, les infrastructures technologiques étaient trop complexes, trop lentes et il existait autant de solutions que d’interfaces (Snydman et al., 2015 ; Brantl et al., 2016 ; Crane, 2017).

Les institutions qui participent activement à IIIF comportent majoritairement des bibliothèques nationales et patrimoniales, des musées, des agrégateurs, et des centres de recherche universitaire (IIIF, 2017d). En plus des trois organisations fondatrices citées au préalable, IIIF peut notamment compter sur le soutien de l’université de Harvard, du Yale Center for British Art, d’Europeana, de l’université de Kyoto, du Wellcome Trust, de la Bibliothèque apostolique vaticane ou encore de la BnF (Robineau, 2016 ; Cramer, 2017).

La communauté IIIF a défini trois buts[8] (IIIF, 2017a, 2017h):

• Donner aux chercheurs un niveau d'accès sans précédent, uniforme et riche aux images numériques hébergées autour du monde

• Définir et adopter un ensemble d'interfaces de programmation applicative (APIs) soutenant l'interopérabilité entre différents entrepôts d'images

• Développer, cultiver et documenter des technologies communes telles que des serveurs d'images et des clients web apportant une expérience utilisateur de classe mondiale dans la visualisation, la comparaison, la manipulation et l'annotation d'images.

Depuis juin 2015, IIIF a établi un consortium (IIIF-C) dans le but de pérenniser et de piloter la communauté  (IIIF, 2017i). A ce jour, plus d’une quarantaine d’institutions, dont deux suisses (le Digital Humanities Lab de l’Université de Bâle et l’Ecole Polytechnique Fédérale de Lausanne), ont rejoint IIIF-C. Chaque institution désirant rejoindre le consortium doit signer le mémorandum d’accord (Memorandum of Understanding – MOU) et s’engage à payer une cotisation annuelle de $10,000 pour au moins six ans (IIIF, 2015). Les fonds obtenus sont supervisés par le Council on Library and Information Resources (CLIR)[9] et la gouvernance de la communauté est assurée par trois entités :

• Le groupe de direction (Executive Group) s’occupe de la stratégie et des orientations générales

• Le comité de coordination (Coordinating Committee) supervise les groupes de spécifications techniques et les activités régulières de la communauté

• Le comité de rédaction (Editorial Committee) crée, révise et maintient les API.

Au sein de la communauté IIIF, sept groupes de travail et d’intérêts se sont créés (IIIF, 2017l). Il existe deux types de groupes (IIIF, 2017g) :

• Les groupes communautaires (community groups) qui collaborent sur des intérêts précis de IIIF : manuscripts, museums, newspapers, software developers

• Les groupes de spécifications techniques (technical specification groups) qui se chargent de prendre des décisions quant à l’implémentation de nouvelles API : A/V (audiovisual), discovery, text granularity

Toutes les activités de IIIF, en présentiel et à distance, doivent respecter le code de conduite (IIIF, 2017f). Un comité composé de 9 membres a vu le jour en août 2017 (Rabun, 2017b). Celui-ci est chargé de gérer les conflits selon des lignes directrices transparentes et acceptées par le comité de coordination (IIIF, 2017e).

Les interfaces de programmation applicative (API)

La motivation à l’origine du développement des API de IIIF était de décloisonner les silos virtuels que les institutions ont créés pour diffuser leurs images numériques sur le Web (Snydman et al., 2015 ; Bayerische Staatsbibliothek, 2016). L’utilisation d’API communes permet aux institutions de maintenir des infrastructures technologiques cohérentes, flexibles, interopérables, ainsi que de faire diminuer les coûts sur le long-terme (Sanderson, 2016 ; Rabun, 2017a ; IIIF, 2017h).  Les API de IIIF fonctionnent comme des couches intermédiaires autorisant une interaction entre différents serveurs et clients comme l’illustre la figure 3 ci-dessous.

Figure 3 : Les API de IIIF au sein de l'environnement serveur-client

(Sanderson, 2016)

Quatre API RESTful[10] sérialisés en JSON-LD (JavaScript Object Notation for Linked Data) ont été définies et approuvées par la communauté IIIF (2017b):

• Image API : ce service web retourne une image par rapport à une requête HTTP ou HTTPS. L’URI peut également spécifier une zone d’intérêt, une qualité particulière ou encore le format de l’image demandé. Les éléments techniques (pixels) d’une image numérique sont rassemblés au sein d’un fichier nommé « info.json ». L’Image API fournit plusieurs profils ou niveaux de conformité, du niveau 0 qui peut servir des images statiques jusqu’au niveau 2 où une profondeur de couche des images est requise. http://iiif.io/api/image/

• Presentation API : fournit les informations nécessaires et contient juste assez de métadonnées descriptives pour permettre la représentation et l’affichage d’objets dans un environnement riche sur le Web. Cette API est généralement utilisée en conjonction avec l’Image API car c’est en quelque sorte « une glu » entre les différentes images, séquences par exemple de pages d’un manuscrit ou d’une exposition virtuelle. Une ressource structurée au sein de l’écosystème IIIF est décrite dans un fichier nommé « manifest.json ». http://iiif.io/api/presentation/

• Content Search API : donne accès aux annotations textuelles, telles que la reconnaissance optique de caractères (OCR) ou les commentaires provenant d’une indexation personnelle, d’un objet numérique conforme. http://iiif.io/api/search/

• Authentication API : conçu pour supporter le contrôle d’accès aux ressources par le biais de quatre types d’interaction. http://iiif.io/api/auth/

Les deux premières API sont considérées comme les spécifications principales de IIIF car elles garantissent déjà, à elles deux, l’interopérabilité d’objets numériques. Il faut encore préciser que toutes ces spécifications techniques suivent un modèle de conception établissant plusieurs règles comme par exemple la simplification des processus de migration et de partage de données (Appleby et al., 2017a) ou la conformité aux standards du W3C tels que le Web Annotation Data Model (IIIF, 2017k).

Serveurs et clients conformes aux API

Les logiciels utilisés par la communauté IIIF ont été soit adaptés soit créés de toutes pièces pour se conformer aux spécifications techniques. Il existe des solutions open-source et propriétaires tant du côté client que du côté serveur. Voici une liste non-exhaustive[11] de logiciels présents au sein de « l’écosystème IIIF » (IIIF, 2017c ; Rabun, 2017d) :

• Clients : OpenSeaDragon, Leaflet-IIIF, Diva.js, IIIFViewer, Universal Viewer, Mirador

• Serveurs : Loris, IIPImageServer, Cantaloupe, ContentDM, Djakota, SIPI

La mise en adéquation avec un écosystème IIIF permet aux institutions de ne publier qu’une fois les objets numériques et leurs métadonnées associées (Ying, Shulman, 2015). Au vu du nombre important d’institutions de renom utilisant désormais des systèmes conformes aux spécifications, les API sont devenues de facto des standards (Markus et al., 2017 ; Haskiya, 2017).

La figure 4 ci-dessous montre l’interaction entre un client effectuant une requête d’un IIIF Manifest[12] (les informations contenus à l’intérieur du manifest.json) et du info.json, ainsi que du serveur qui répond à ces demandes. Une fois que le client/la visionneuse[13] reçoit les informations du serveur, il peut afficher les images (Reed, Winget, 2017 ; Ronallo, 2017).

Figure 4 : Interaction client-serveur au sein d'un écosystème IIIF

(Reed, Winget, 2017)

IIIF en Suisse

Quelques institutions publiques et privées ont collaboré ou utilisé les standards de IIIF. Seul e-codices[14], projet piloté par l’Université de Fribourg, a à ce jour déployé les deux API principales et exposé plus de 1800 manuscrits d’une cinquantaine d’institutions patrimoniales suisses (e-codices, 2016). Leur infrastructure a été conforme aux spécifications lors de la mise en ligne de la deuxième version du site en décembre 2014 grâce à l’appui de l’entreprise text&bytes (e-codices, 2014).

Une autre application conforme à IIIF est le projet Fragmentarium[15], également pilotée par l’Université de Fribourg, qui rassemblera des fragments de manuscrits d’une quinzaine de bibliothèques partenaires dans le monde entier. La mise en ligne publique de leur plateforme est prévue pour 2018.

En 2017, trois autres organisations suisses ont participé à des événements IIIF pour y présenter leurs travaux de développements d’outils.

En premier, lieu, Klokan Technologies[16], entreprise basée dans le canton de Zoug et spécialisée dans la publication de cartographies en ligne, a développé « Georeferencer », une plateforme où des images se font assigner un emplacement géographique[17]. Klokan a également créé un client (IIIFViewer) et un serveur (IIIFServer) conforme aux API (Klokan Technologies, 2016).

Deuxièmement, le laboratoire des humanités numériques (DHLab) de l’Université de Bâle a rejoint IIIF-C en janvier dernier (Rabun, 2017c) et a développé un serveur IIIF (SIPI) dans une optique de préservation à long-terme (Rosenthaler, Fornaro, 2016) et prêt à se conformer à la future API audiovisuelle de IIIF prévue pour 2018 (Raemy et al., 2017).

Puis, l’Ecole Polytechnique Fédérale de Lausanne (EPFL) a contribué à la mise en place de deux plateformes en utilisant l’Image API. Il s’agit des archives numérisées du journal « Le Temps »[18] (Rochat et al., 2016) et de la bibliothèque numérique du Musée de l’Elysée[19]. L’EPFL a aussi rejoint IIIF-C en août, devenant ainsi la deuxième institution suisse à faire partie du consortium (Rabun, 2017b).

Infrastructure nationale pour les éditions (NIE – INE)

NIE-INE est une initiative qui vise à construire une plateforme nationale recensant des éditions scientifiques, critiques, dans le domaine des sciences humaines. Ces éditions sont autant des sources primaires que secondaires (DHLab, 2017 ; FEE, 2017b).

Ce projet est piloté par le Forum für Edition und Erschliessung (FEE) de l’Université de Bâle et est financé par le fonds CUS-P5 de Swissuniversities jusqu’à septembre 2019. Six entités coopèrent à ce projet :

• L’Académie suisse des sciences humaines et sociales (SAGW)

• L’Université de Bâle

• L’Université de Berne

• L’Université de Zurich

• La Bibliothèque universitaire de Bâle

• La Bibliothèque centrale de Zurich

Pour l’instant, il est prévu de mettre en ligne 14 projets d’éditions (ou sous-projets de NIE-INE), essentiellement en théologie et en philosophie tels que les commentaires sur les Sentences de Pierre Lombard ou encore les éditions critiques des récits de Perceval (FEE, 2017a).

Le public cible des futurs utilisateurs de la plateforme NIE-INE, et par extension des tests d’utilisabilité qui ont été effectués sur UV et Mirador lors du travail de bachelor, est majoritairement composé de chercheurs, professeurs, d’étudiants, ainsi que de curateurs.

Tests d’utilisabilité
Interfaces/Visionneuses testées

En leur qualité d’interfaces les plus implémentées au sein de l’écosystème IIIF, UV et Mirador ont été toutes deux choisies pour les tests d’utilisabilité.

S’il y a beaucoup de fonctionnalités communes (affichage des images et des métadonnées associées, rotation, zoom[20], vignettes, navigation au sein d’objets structurés) entre les deux visionneuses et qu’elles sont interchangeables la plupart du temps, elles diffèrent à certains égards.

UV (voir figure 5 ci-dessous) est une interface open-source qu’il est possible d’encapsuler aisément à l’intérieur d’une page HTML, de chercher des occurrences en plein texte ou encore de télécharger la totalité de l’objet, une page ou encore un extrait (UV, 2017a). UV a été à la base conçu pour le compte de la Wellcome Library et ensuite adapté pour se conformer aux spécifications de IIIF (Digirati, 2015).

Figure 5 : Universal Viewer (version  2.0.1)

(UV, 2017b)

Quant à Mirador (voir figure 6 ci-dessous), il s’agit d’une visionneuse créée en 2013 pour les besoins des chercheurs en histoire de l’art et des spécialistes de manuscrits à l’université de Stanford (Reed, Winget, 2017). En 2014, l’université de Harvard s’est jointe aux efforts de développement. Mirador a été conçu dès le départ en s’alignant sur les API de IIIF en offrant à ses utilisateurs, généralement des universitaires, la possibilité de comparer et d’annoter différents objets à l’intérieur d’un même espace de travail (Mirador, 2015, 2016).

Figure 6 : Mirador (version. 2.3.0)

(Mirador, 2017)

Méthodologie

Quatre grandes étapes ont été nécessaires pour réaliser les scénarios des différents tests d’utilisabilité :

1.       Définir le contexte d’utilisation des publics cibles

Les spécificités des futurs utilisateurs de la plateforme NIE-INE ont été prises en compte dans la conception des tests d’utilisabilité. Les considérations telles que les connaissances en informatique des utilisateurs, la mise à disposition d’une interface intuitive, ou encore le type d’environnement sur lequel les chercheurs travaillent ont été des éléments clé. Il a été décidé par exemple de ne se focaliser que sur des tests prenant place sur ordinateur portable ou stationnaire.

2.       Trouver les exigences des utilisateurs finaux en se basant sur les récits utilisateur (user stories)

Les récits utilisateur de IIIF et ceux reçus de NIE-INE ont permis de sélectionner les types de tâches les plus importantes à effectuer sur les deux interfaces évaluées comme la configuration de l’affichage, la recherche et le partage, le zoom et la rotation, ou encore l’annotation ou la comparaison des objets numériques. 

3.       Sélectionner les outils pour mener à bien les tests

Afin d’avoir des données quantitatives et qualitatives, il a été décidé de mener deux sortes de tests d’utilisabilité, un premier à distance et asynchrone avec le logiciel Loop11[21] et un second de manière modérée et en présentiel sur Morae[22]. Le choix des logiciels s’est fait essentiellement sur la base d’évaluations similaires faites par des alumni de la filière Information documentaire de la Haute Ecole de Gestion de Genève (Prongué, 2012 ; Meystre, Rey, 2014 ; Guzzon, 2016).

4.       Créer les tâches et les questions

Le scénario s’appuie sur des évaluations effectuées au préalable par la British Library et Toronto University courant 2016 sur UV ou/et Mirador (Ridge, 2016 ; Miekle et al., 2016). En général, une série de 2-3 tâches est suivie par une question portant sur la satisfaction ou demandant des informations complémentaires difficiles à tracer.

Indicateurs de mesure

L’efficience et la satisfaction étaient les deux dimensions d’évaluation choisies pour les tests d’utilisabilité. Dans un second temps, l’utilisabilité perçue ou globale (perceived usability) est devenue un troisième critère principal. 

Efficience

L’indicateur qui a été retenu se nomme l’efficience relative globale (overall relative efficency) et est un ratio entre le temps moyen pris par tous les participants ayant réussi une tâche et le temps moyen pris par la totalité des participants (Sergeev, 2010 ; Mifsud, 2015). Le résultat peut être exprimé en point ou en pourcent.

Satisfaction

Un sous-ensemble de la catégorie satisfaction du sondage USE (Usefulness, Satisfaction, and Ease) créé par Lund (2001) a été retenu. Il s’agit des trois critères suivants qui furent évalués sur l’échelle de Likert :

• Cette interface fonctionne comme je l’attendais (it works the way I want it to work)

• Cette interface est plaisante à utiliser (it is pleasant to use)

• Cette interface est amusante à utiliser (it is fun to use)

Le résultat de satisfaction globale était une moyenne de ces trois critères, donnant au maximum 5 points.

Utilisabilité perçue

Afin d’avoir une référence commune, le System Usability Scale (SUS) a été choisi comme instrument de mesure pour avoir une référence connue dans le domaine de l’utilisabilité. Ce questionnaire élaboré par Brooke (1996) comporte dix questions alternant les énoncés positifs et négatifs. Les participants répondent sur l’échelle de Likert où chaque énoncé vaut entre 0 et 4 points. Ce résultat intermédiaire sera ensuite multiplié par 2.5 pour donner un percentile. Une manière d’interpréter le score obtenu est de le convertir en note de A à F. Sauro (2011) a développé cette méthode sur la base d’une centaine de tests d’utilisabilité pour dégager un point de référence. Les repères les plus importants sont les suivants :

• 80.3 et plus est considéré comme une excellente note et équivaut à un A

• 68 comme une note suffisante : C

• 51 et moins comme une mauvaise note : F

La satisfaction et l’utilisabilité perçue ont été évaluées autant lors des tests à distance qu’en présentiel. L’efficience n’a elle été mesurée que lors des tests d’utilisabilité à distance. Pour avoir un indicateur qui se rapprochait de l’efficience, la notion « accomplissement d’une tâche » (task completion), déterminant trois niveaux de facilité, a été incluse pour l’évaluation en présentiel.

Résultats[23]

En excluant le pré-test (ou test bêta), effectué uniquement pour vérifier différents paramétrages du logiciel Loop11, trois évaluations ont été prises en compte dans la matrice des résultats (voir tableau 3) :

1. Le test pilote (pilot test) a été fait avec Loop11 avec 29 étudiants de la Haute école de gestion de Genève le 5 avril 2017. Le but de ce test était d’avoir des utilisateurs n’ayant jamais entendu parler de UV ou de Mirador et de voir quels types de problèmes des utilisateurs non expérimentés pouvaient rencontrer.
2. Le test « cible » (target test) a été fait avec Loop11 avec comme public cible les futurs utilisateurs de la plateforme NIE-INE et la communauté élargie[24] des humanités numériques. 45 personnes[25] ont participé au test disponible entre le 20 avril et le 8 mai 2017.
3. Le test en présentiel (in-person test) a été fait avec Morae pendant le mois de mai. Cela s’est déroulé sur le lieu de travail de 7 chercheurs ou curateurs en humanités numériques. Il était demandé aux participants d’utiliser la méthode de la pensée à voix haute (thinking aloud protocol).

Problèmes principaux d’utilisabilité à résoudre

En parallèle à l’un des objectifs principaux qui consistaient à évaluer l’efficience et la satisfaction des deux interfaces, quelques bugs et problèmes d’utilisabilité ont été découverts, essentiellement par les participants des tests en présentiel.

UV

Dans la figure 7 ci-dessous quatre zones représentant différentes fonctionnalités de l’interface UV ont posé des problèmes aux participants des tests. Sous l’image se trouvent les explications de chaque zone.

Figure 7 : Problèmes d'utilisabilité de UV

1. L’épingle – « goutte d’eau » : cette fonctionnalité était assez frustrante pour la plupart des participants qui tentaient de la faire glisser pour passer d’une page à l’autre alors qu’elle ne sert qu’à indiquer un mot cherché à l’intérieur du corpus.
2. Les options de téléchargement : le nombre important d’options rendaient cette tâche difficile à appréhender.
3. Les icônes de zoom et de rotation : les participants n’arrivaient pas à trouver les icônes car elles disparaissent trop rapidement lorsqu’il n’y aucune action de la part de l’utilisateur.
4. Les types de visualisation : les icônes n’étaient pas clairement identifiables, probablement à cause de la surbrillance grise.

Mirador

Sous la figure 8 se trouvent les explications des six zones problématiques de l’interface Mirador en termes d’utilisabilité. Les six zones représentent cinq fonctionnalités distinctes.

Figure 8 : problèmes d'utilisabilité de Mirador

1. Les fonctions de panoramique et de zoom : cette zone était déroutante pour les nouveaux utilisateurs qui l’employaient pour passer d’une page à l’autre et elle n’était aussi jamais utilisée par les utilisateurs aguerris qui préféraient zoomer avec leur souris.
2. Les types de visualisation / le changement de mise en page : souvent les deux icônes ont été confondues par les participants qui ne comprenaient pas la différence entre les deux labels.
3. Les options de manipulation des images : les tests ont relevé qu’une grande majorité des participants n’arrivaient pas à retourner une image dans un sens ou dans un autre car il faut appuyer sur une icône avant de voir apparaître les différentes options.
4. Ajouter un nouvel objet : deux participants ont repéré un bug au sein du système lorsqu’ils ont essayé de glisser/déposer une image provenant du panneau des miniatures.
5. Le panneau des miniatures : les petits points qui affichent et font disparaître le panneau ont rarement été trouvés par les participants aux tests.

Synthèse des résultats

Au sein du tableau 3 se trouvent les résultats obtenus des trois différents tests d’utilisabilité. Si globalement les deux interfaces se retrouvent avec des bonnes notes, UV a été préféré pour sa facilité de prise en main et s’en sort mieux dans chaque évaluation. Néanmoins, les utilisateurs expérimentés appréciaient les fonctionnalités offertes par Mirador et non disponibles au sein de l’interface UV.

Tableau 3 : Synthèse des résultats des tests d'utilisabilité

Recommandations et perspectives

Si l’on reprend la question de recherche posée initialement, à savoir comment faire bénéficier la communauté des chercheurs suisses des technologies IIIF, on peut émettre les recommandations suivantes.

Il a été recommandé au projet NIE-INE de partager ses récits utilisateur de manière exhaustive avec la communauté IIIF pour évaluer les besoins spécifiques qu’ils ont vis-à-vis d’autres institutions utilisant des solutions IIIF. Ce serait un premier pas intéressant à effectuer car cela permettrait de les mettre en contact avec d’autres institutions ayant les mêmes exigences et de créer des liens avec des experts du domaine.

Par ailleurs, les développeurs des interfaces UV et Mirador ont reçu toutes les données issues des tests d’utilisabilité et vont d’ici l’année prochaine résoudre les problèmes identifiés et tenter de développer de nouvelles versions plus efficientes.

IIIF a décidé récemment de créer un groupe communautaire de sensibilisation (Outreach Community Group) pour atteindre un public plus large, notamment les institutions de petite et moyenne taille. Ce groupe devrait voir le jour dès janvier 2018 et aura, entre autres, comme objectifs de mieux documenter les processus d’implémentation et d’animer des ateliers. Les institutions suisses pourraient tirer profit de ce groupe pour déployer plus aisément des solutions conformes aux spécifications techniques.

Conclusion

Tout comme pour les collections issues du patrimoine culturel, le projet NIE-INE ainsi que les initiatives similaires ont tout intérêt à se conformer aux spécifications techniques qu’offre IIIF. Chaque nouvelle institution arrivant au sein de la communauté fait profiter tout l’écosystème, que ce soit du côté des utilisateurs finaux ou pour les membres IIIF. Il suffit pour cela de discuter et collaborer avec la communauté IIIF, même s’il faut au préalable comprendre certains concepts techniques. Avant de passer à une lecture exhaustive des API, il est préférable d’assister à un événement IIIF qui est également une occasion d’élargir ses connaissances, aussi à l’international.

Les résultats obtenus au cours des tests d’utilisabilité démontrent que les interfaces UV et Mirador avaient toutes les deux leurs forces et leurs faiblesses, mais ne présentaient pas de problèmes considérables qui empêcheraient les utilisateurs de réaliser la grande majorité des tâches demandées.

Tous ces résultats ont été rendus publics et présentés aux personnes impliquées dans les développements des interfaces testées ainsi qu’aux membres du projet NIE-INE. Les réponses ont jusqu’ici étaient positives et plusieurs changements devraient être effectués lors de la mise à disposition des prochaines versions majeures (UV et Mirador 3.0).

Chaque institution souhaitant modifier ou construire un nouveau système doit faire en sorte d’implémenter une interface conviviale par le biais de tests d’utilisabilité. Quant à celles qui souhaitent mettre en œuvre une solution conforme à IIIF, elles peuvent soit déployer UV pour le grand public grâce à sa simplicité d’utilisation, soit Mirador pour un public plus aguerri et scientifique susceptible d’employer un nombre important de fonctionnalités.

En Suisse, il y a encore un long travail de sensibilisation à effectuer, notamment auprès des bibliothèques, sur les bénéfices de IIIF. Le lancement d’un sondage auprès d’institutions patrimoniales et scientifiques ainsi que l’organisation de présentations et d’ateliers sont quelques pistes qui ont été évoquées à la suite du travail de bachelor. Ces éléments semblent essentiels pour parvenir à connaître les besoins des institutions suisses à implémenter des infrastructures flexibles et interopérables permettant un meilleur accès aux objets numériques.