Archives par étiquette : interface

dépôt des thèses [2] interfaces [2]

Plus d’un an après la phase de maquettage, nous avons mis en production la nouvelle version du guichet de dépôt légal des thèses AMU (6 mois de développement). Je détaille ici les éléments de l’interface et j’aborderai dans un prochain billet les aspects plus fonctionnels.

Sur la méthode, nous avons travaillé en binôme. Laure Denoix a développé l’application avec le framework Symfony alors que je réalisais les spécifications, l’interface et les tests. La simplicité d’utilisation du moteur de template Twig nous a permis de répartir les rôles et de mettre en place une vraie collaboration lors de la construction de l’application.

Interface doctorant

  1. page d’accueil
    1. rappel de l’obligation de dépôt légal
    2. procédure de dépôt et de contrôle par le directeur de thèse
    3. modalité de signalement des sujets et de diffusion des thèses
    4. sélection de la langue : français/anglais (en cours de traduction)
  2. page d’informations administratives (authentifiée)
    1. issues du système de gestion de scolarité Apogée : identité, titre de la thèses, mention du diplôme, directeur de thèse, rapporteurs, membres du jury, confidentialité
    2. informations utilisées pour le signalement du sujet en préparation et de la thèse soutenue ainsi que l’édition du diplôme
    3. doivent figurer sur la page de titre de la thèse
    4. demandes de correction de ces informations transmises automatiquement au gestionnaire de scolarité concerné
  3. page résumés et mots clés (authentifiée)
    1. renseignement du titre traduit, des résumés et des mots clés
    2. champs contrôlés pour UTF-8, pour la limite de 1700 caractères avec un compteur visuel de caractères restants/en trop
  4. page dépôt des fichiers (authentifiée)
    1. dépôt du fichier principal en PDF et des fichiers complémentaires en XML, TXT, MP4, GIF, PNG, etc.
    2. test de conformité des fichiers pour archivage PAC : interrogation du web service FACILE
  5. page de validation (authentifiée)
    1. renseignement des droits de diffusion et validation du dépôt
    2. téléchargement le contrat de diffusion pré-rempli

exemple page résumés et mots clés :

exemple page dépôt des fichiers

Interface directeur de thèse (privée)

  1. page validation par le directeur de thèse
    1. téléchargement des fichiers
    2. validation ou mise en attente de corrections

exemple page validation par le directeur de thèse

Interface gestionnaire (authentifiée)

  1. page dépôts
    1. liste cherchable, triable, sortable, exportable, de tous les dépôts
    2. visualisation des états du guichet pour chaque enregistrement
    3. export vers STAR par web service en un clic (import complet)
    4. lien vers espace de dépôt (interface doctorant)
    5. lien vers la gestion individuelle du workflow (modification, historique, ajout d’une adresse complémentaire pour le directeur de thèse, lien vers la page de validation par le directeur de thèse)
  2. page modification des libellés de l’application
  3. page modification des emails du workflow
  4. page de gestion des destinataires du workflow (gestionnaires de scolarité)
  5. page d’administration des relances du workflow (fréquence et délai)

exemple page dépôts

API [1] poster

Les Journées Abes 2016 se sont déroulées à Montpellier le 10 et 11 mai 2016. Ce fut l’occasion de présenter un poster, je l’espère pédagogique, sur l’utilisation des API pour améliorer les interfaces de recherche proposées par les bibliothèques AMU.

poster_fullsize

J’en profite pour saluer le grand professionnalisme des équipes de l’Abes dans l’organisation de ces journées et tout au long de l’année sur les projets qui y sont déployés.

dépôt des thèses [2] interfaces [1]

La refonte de l’interface du guichet de dépôt des thèses AMU intervient dans le cadre du projet « Faciliter l’accès aux thèses » inscrit au schéma directeur du numérique de l’université.

Ce travail est en cours, voici donc comment nous travaillons.

Nous avons réalisé avec Marion Laurent, bibliothécaire membre du groupe de travail, une première ébauche au crayon des différents écrans. Ce premier travail nous a permis de réduire le nombre d’écran à 5 au lieu de 7 précédemment. Pour cela, nous avons regroupé les pages de téléversement du fichier principal et des fichiers complémentaires et intégré l’action de validation du dépôt sous la forme d’une fenêtre d’alerte modale. A cet étape, nous avons également pensé les dispositifs d’assistance et de demande correction des informations en utilisant systématiquement des formulaires.

chemin

Nous avons ensuite réalisé un prototype non fonctionnel afin de tester les éléments d’interaction tout au long de la procédure de dépôt et sur l’interface d’administration.

Guichet de dépôt électronique des thèses

Cette maquette va évoluer en fonction des commentaires et préconisations des membres du groupe de travail dans InVison.

InVision

La phase suivante devrait faire intervenir des beta testeurs puis se sera la phase d’implémentation avec Laure Denoix, chargée du développement de l’application.

résolveur de liens OpenURL [7] version 1.0

Après deux ans de mise en service du résolveur de liens AMU, nous pouvons comparer la progression moyenne 2013-2014 : +90% sessions et +70% pages vues d’une année sur l’autre. L’objectif en 2015 est de maintenir un nombre de pages vues supérieur à 200 000.

L’interface a connu 3 évolutions en 2 ans pour pouvoir intégrer les différents développements. Elle propose maintenant deux sections dans la partie droite, BIBLIO+ pour les rebonds auteurs et citations vers Google Scholar, DISPO+ pour la disponibilité du texte intégral en archives ouvertes, la disponibilité de la revue ou du livre en bibliothèque et enfin la possibilité de commander un article via le PEB.

Ces rebonds ne sont pas toujours actifs mais toujours visibles, leur accessibilité est signalée par un code tricolore : orange = interrogation des services, vert = disponible, rouge = indisponible. Par exemple, lorsqu’un lien vers le texte intégral d’un article est présent, le lien « Commander l’article » est inactif, en rouge. A l’inverse il passe au vert et devient actif lorsqu’il n’y pas de texte intégral en ligne et l’usager peut alors d’un simple clic générer le formulaire de PEB pré-rempli sur le site des bibliothèques AMU.

exemple : un article non disponible dans les abonnement AMU mais present en OA ne peut pas être commandé par le PEB

Exemple : un article indisponible dans les abonnements AMU mais en OA ne peut pas être commandé par le PEB.

 

 

résolveur de liens OpenURL [6] aucun lien disponible

Il y un peu moins d’un an, je m’interrogeais sur les possibilités de rebonds lorsque le résolveur ne trouve pas de liens vers le texte intégral. Je vais donc reprendre point par point les pistes envisagées.

  • Commander le document par le service du PEB (prêt entre bibliothèques) :
    Il n’y a pas eu d’évolution notable dans la clarification de ce service proposé par les bibliothèques AMU, les conclusions du groupe de travail dédié à ce sujet ne sont pas encore connues. Sur ce front, on notera aussi que le service RefDoc devrait rouvrir cet automne et qu’une enquête est en cours concernant la facturation centralisée.
  • Visualiser la disponibilité du texte intégral dans les collections imprimées :
    En juillet, l’ouverture du serveur SRU du SIGB nous a permis d’exploiter les données du catalogue. Ce service s’appuie sur un script de conversion du résultat de la requête en XML vers JSON hébergé sur Google App Engine avec la librairie pUrl.
  • Visualiser la disponibilité dans des archives ouvertes  :
    Nous utilisons l’API CORE (COnnecting REpositories) pour récupérer les données, le script Simple PHP Proxy avec Google App Engine et pUrl pour contourner la limitation des requêtes inter-domaines. Ce service sera mis en place en version bêta lors de l’Open Access Week. Il s’agit surtout d’une fonctionnalité destinée à communiquer. En effet, le résolveur est surtout utilisé par le public identifié recherche, cela permet donc d’exposer l’AO dans l’interface pour des articles qui seraient aussi accessibles via le rebond Google Scholar.

Ces changements nous poussent à rapprocher la prochaine mise à jour de l’interface pour mieux intégrer ces nouveautés ainsi que la directive européenne sur les traceurs.

smashbeta

Certainement lors du creux de fin d’année.

charts01

résolveur de liens OpenURL [5] mise à jour de printemps

En mars 2014 l’interface du résolveur de liens SMASH a été mise à jour. Les précédents billets documentent les changements opérés et vous pouvez tester une version statique en ligne. En résumé, les actions principales depuis le résolveur ont été simplifiées et les fonctionnalités liés aux document physiques abandonnées (interrogation SRU du catalogue et service PEB). Celles-ci seront donc intégrées lors de la mise à jour suivante lorsque ces services seront disponibles.

Après deux mois de recueil statistique, l’analyse des événements nous permet de constater :

  • l’échec des métriques de niveau revue, dont la consultation proche de zéro nous pousse à repenser/supprimer l’accès à cette information ;
  • l’échec relatif des rebonds Google Scholar auteur et citation dont il faudra aussi repenser l’emplacement ;
  • le taux très élevé de clic sur le lien DOI actif dans la référence (27%), sans doute perçu, et utilisé à tort, comme moyen d’accès absolu au texte intégral en ligne.

Cette révision a permis d’harmoniser l’apparence de plusieurs applications et de généraliser l’accès à l’assistance via UserVoice : SMASH (résolveur de liens), lama (système d’accès distant) et Bento (revues et articles en ligne) . La communication de ces changements a été commune aux usagers (site web bu) et aux professionnels (mailing).

résolveur de liens OpenURL [4] interfaces [3]

Il faut faire un effort d’imagination …

Après une interface pour le résolveur de liens lorsque celui-ci matche une référence disponible en ligne, imaginons les interactions possibles pour un texte intégral non disponible. Celui-ci peut-être disponible en ligne mais en dehors de la base de connaissance (cible non déclarée, archives ouvertes, etc.) ou disponible dans les collections imprimées, celles de l’université ou d’une autre université via le prêt entre bibliothèques (le temps de fourniture d’un article par le PEB est en moyenne de deux semaines). Il reste toujours possible de l’acheter directement en pay-per-view sur le site de l’éditeur.

… merci de votre participation.

Les pistes :

  • Relance d’un groupe de travail AMU sur le PEB en janvier 2014 qui devra harmoniser, simplifier le circuit du PEB et pourra être un espace de proposition.
  • Visualiser la disponibilité du texte intégral dans les collections imprimées de l’université depuis l’interface du résolveur de liens. L’université Rennes 2 (Julien Sicot), dans une configuration logicielle similaire à celle de l’université d’Aix Marseille, exploite déjà cette solution. Le réseau des bibliothèques AMU est étendu et la fourniture rapide de l’article serait un service intéressant en sortie du résolveur.
  • Visualiser la disponibilité dans des archives ouvertes via le résolveur OpenURL AIRwayprésenté par Benjamin Bober. Un plus, mais les cibles disponibles restent peu nombreuses.

résolveur de liens OpenURL [4] interfaces [2]

Voici la première maquette de la nouvelle interface du résolveur de liens SMASH lorsque celui-ci matche une référence :

Screenshot_2013-12-17-12-50-57  Screenshot_2013-12-17-12-51-26

Nous avons choisi de simplifier au maximum les éléments d’interaction : bouton vers le texte intégral placé au dessus de la référence, la base cible n’est plus cliquable, disparition des informations concernant la couverture de la revue, les rebonds plus nombreux sont visibles uniquement  en dépliant le menu « Services + ».

Le design est pensé tablet first mais il s’agit plutôt d’un design qui demeure identique pour toutes les tailles d’écran afin de proposer une expérience unifiée. Cela se justifie pleinement pour une page intermédiaire entre deux sites (source et cible) dont le temps de consultation est de l’ordre de quelques secondes.

Le CSS s’appuie sur la bibliothèque Pure, vous pouvez tester une version statique en ligne.

résolveur de liens OpenURL [1] interfaces [1]

Nous voulions proposer dans notre université une alternative à l’interface d’origine du résolveur de liens 360Link. Voici un exemple de page proposée par défaut :

360Link native interface

Nous avons mis en place une autre interface en utilisant le code Javascript/jQuery proposé par Matthew Reidsma (Grand Valley State University). Les explications par l’auteur dans rethinking stock user interfaces. Avec cette méthode c’est l’interface native qui est modifiée, l’accès aux résultats se fait sur la page d’origine hébergée par Serials Solutions. Cela nous a permis d’ajouter des rebonds et de construire une mise en page plus lisible.

SMASH - 360Link reset

Les inconvénients de cette méthode sont liés au mode de paramétrage de 360Link : administration dépendante des mises à jour quotidiennes et environnement de test peu adapté à l’édition du code.

Nous avons donc choisi d’explorer une autre solution basée sur Python/Django/Heroku et présenté par Ted Lawless (Brown University). Cette fois-ci l’API 360Link est utilisée, cela permet de travailler en local puis de déployer en ligne avec Heroku. En séparant développement et production nous pourrons mieux tester chacune des fonctionnalités.

obscure-oasis-fugu 360Link Django

Cette solution ne sera peut-être pas utilisée en production mais il s’agit aussi de se familiariser avec l’interrogation d’une API avec en point de mire l’interrogation d’un éventuel résolveur de liens déployé sur la base de connaissance national.