Soyons franc, sans l’insistance et la conviction de Françoise Fontaine-Martinelli, responsable de la mission lecture et handicap à la BCU (cf. ses billets sur le sujet), nous ne nous y serions pas encore mis (et nous aurions eu tort) ! Partant des propositions émises dans son rapport de mission, la bibnum (développeur et bibliothécaire) a mis en œuvre, depuis le mois d’avril, des mesures d’amélioration de l’accessibilité du site web. Ce travail s’est appuyé sur les recommandations et guides du site AcceDe Web ainsi que sur les outils du réseau Opquast.
Mise en conformité du site web avec les règles d’accessibilité standard
Affichage d’un fil d’Ariane sur toutes les pages
Création d’une page plan du site accessible depuis le pied de page
Mise en place de liens d’évitement pour permettre une navigation rapide
Mise en place de raccourcis clavier pour suppléer l’usage de la souris
Reprise du code HTML des pages pour rendre le HTML accessible et conforme
Reprise des galeries d’images pour les rendre accessibles (plugins Drupal)
Modifications de style diverses (soulignement des liens, marges des titres, etc.)
Intégration du format et du poids des fichiers pour chaque lien de téléchargement (voir par exemple la page consacrée aux outils de méthodologie documentaire)
Le plus dur est fait, mais il faut maintenant s’assurer que les sites restent accessibles dans le temps.
Consignes pour la rédaction
Le prochain chantier consistera à adapter la notice d’accessibilité éditoriale proposée par AcceDe Web. Il s’agit d’un guide de bonnes pratiques à suivre par les différents rédacteurs du site web. Il permettra à chacun d’adopter de bons principes de rédaction et d’utilisation des liens, images et autres objets du web.
Là réside la difficulté du projet car, même si nous établissons avec eux les consignes de rédaction, les rédacteurs devront certainement se confronter à quelques balises HTML, ce qu’ils ne maîtrisent guère. Le rôle du webmaster devrait s’en trouver renforcé : il devra certainement passer plus de temps sur le contrôle qualité des publications pour veiller à la conformité aux règles.
Conclusion
Malgré les incitations institutionnelles et la mission lecture-handicap au sein de la BCU, nous avions du mal à démarrer le chantier accessibilité de nos sites web. Il nous manquait essentiellement les recommandations techniques pour le faire.
Et puis nous pensions que respecter les standards du web suffisait à satisfaire les besoins de nos publics ; que travailler sur l’accessibilité ne profiterait qu’à une minorité de gens dont on ne connaît pas les attentes. Quel tort !
Il s’avère que l’accessibilité numérique profite à tous. Tout ce qui a été mis en place améliore considérablement la lisibilité et donc l’usage de notre site. Certes, il reste beaucoup de choses à faire pour augmenter l’utilisabilité de nos outils mais les rendre accessibles constitue une étape essentielle autant que nécessaire.
Nous avons eu la joie de présenter cette semaine notre poster lors des Journées ABES. Léonard Bourlet et moi-mêmes étions présents pour parler de notre travail mais je dois rendre hommage aux principaux artisans de ce poster, Mathieu et Karine.
Présentation du poster aux JABES 2013
Il nous est apparu très vite que le sujet à développer serait Blacklight et sa mise en œuvre. Nous avons voulu restituer notre expérience. Mathieu Bacault a donc conçu le scénario du poster en privilégiant l’aspect chronologique et les étapes du projet, de la réflexion initiale à la mise en production. C’est cette idée de fil conducteur qui nous a menés à la Linea.
Partant de là, Karine Vazeille a réalisé le poster, du dessin à la mise en page (avec Illustrator). Elle a repris le style de la Linea, en modifiant le dessin de la tête notamment, et a conçu toutes les illustrations et les boutons. Le tout en une quinzaine de jours. L’imprimeur a d’ailleurs fourni le poster la veille du pont de l’Ascension, donc juste avant le départ pour Montpellier.
Sur place, nous avons subi une petite douche froide en constatant que les panneaux n’étaient pas adaptés à un poster horizontal ! Et nous étions les seuls à arriver avec un tel format… Bref, voici le poster :
Aujourd’hui, nous abordons la question de l’élégance d’un code informatique. Pour parler des coulisses d’un logiciel ou d’un site web, on utiliserait plutôt les expressions « mettre les mains dans le cambouis » ou « regarder sous le capot ». L’esthétique du sujet étant peu évidente de prime abord. Tentons de voir les lignes de code sous un autre jour.
Fractal vegetable – Par Rum Bucolic Ape sur flickr – licence CC BY-ND 2.0
Pour commencer, un langage informatique a des similitudes avec celui d’une langue parlée. Il a des règles de syntaxe et d’orthographe très précises.
Ainsi, comme il y a de belles écritures manuscrites tant par leur forme que par leur style, il y a de gracieuses manières de disposer les caractères à l’écran, de choisir ses mots, appelés instructions.
Les développeurs inventent même des conventions dédiées à leurs logiciels. Drupal a par exemple des règles de codage qu’il est conseillé de suivre quand on est un de ses contributeurs.
La longueur des lignes, la taille des espacements, la disposition des instructions sont ainsi définies et utilisées par les « drupaliens ».
Il est alors plaisant visuellement d’avoir à parcourir un fichier bien structuré plutôt qu’un méli-mélo de sigles disparates. Il va de soi qu’un code bien présenté est aussi plus facile à comprendre et à modifier. Il existe différents styles de présentation associés ou non à un langage particulier.
Écrire de manière ramassée
À coté de cet aspect formel, le style de codage compte beaucoup dans l’appréciation d’un programme. Il y a souvent plusieurs façons de résoudre un problème et en règle générale, une solution courte est plus appréciée par un développeur soucieux de bien faire les choses.
Pour coder “joliment”, l’informaticien dispose parfois de raccourcis syntaxiques permettant d’exprimer rapidement ce qui aurait nécessité un plus long développement en temps normal.
Mais attention, comme il peut-être inconvenant d’avoir à lire un texte écrit façon “sms”, la concision en informatique n’est pas toujours gage d’un travail compréhensible.
Il y a un équilibre à trouver entre simplicité et lisibilité qui permet la reprise et la lecture du programme par d’autres personnes. Permettre le partage du code participe aussi à sa qualité.
Concevoir avec astuce et habileté
Un programme succinct sera souvent plus efficace en terme de temps d’exécution. Il est également plus satisfaisant intellectuellement de trouver une solution bien conçue et précise.
Faire preuve d’astuce et d’invention, éviter les répétitions inutiles, trouver un enchaînement logique des commandes, garder seulement les étapes indispensables comportent une certaine beauté à l’instar d’une démonstration mathématique ou d’un raisonnement argumenté.
Tout le monde connaît par exemple l’histoire de l’aiguille dans la botte de foin. Pour la résoudre vous pouvez, avec beaucoup de cœur à l’ouvrage, enlever les brindilles une à une. Il est plus aisé de mettre le feu à la meule et tamiser les cendres pour retrouver aisément le petit bout de métal.
C’est ce genre de résolution habile qui participe à l’élégance de la solution trouvée.
Du fractal au chou romanesco
Fractals – Sur flickr par cowicide – licence CC BY-NC 2.0
Les informaticiens ont à leur service un autre outil que vous connaissez peut-être sans le savoir : la récursivité.
On la trouve dans la nature sous la forme de la structure harmonieuse et équilibrée d’un flocon de neige ou celle du chou romanesco.
L’image fractale ci-contre en est un autre exemple où l’on voit un motif se répéter à l’intérieur de lui-même. Cette notion existe en mathématique, en linguistique, en biologie, dans les arts, et en informatique…
Le principe est simple en apparence, un programme récursif est un programme qui s’appelle lui-même.
Si vous aviez à calculer la hauteur cumulée d’une poupée russe et de ses descendantes, vous pourriez les aligner les unes à coté des autres.
Puis les mesurer chacune à leur tour pour trouver la hauteur totale, mais ce n’est pas satisfaisant.
Si vous êtes plus inventif vous allez utiliser une boucle en ordonnant au programme de parcourir toute la série de poupées gigogne, de mesurer leur taille respective et calculer le résultat que l’on souhaite.
Mais il y a une solution plus astucieuse avec la récursivité.
Vous mesurerez la figurine la plus petite, le travail est minimal, et appellerez votre programme sur toute la collection en lui donnant l’instruction suivante : la hauteur d’une poupée russe est une fois et demi plus grande que sa première fille.
Avec cette relation générale, votre script commencera par la poupée la plus grande, puis continuera avec la suivante en enregistrant le rapport entre les deux. Et ainsi de suite, jusqu’à l’ultime poupée dont il connaît la taille exacte. Alors, il pourra remonter la file des relations entre matriochkas et donner un calcul juste à partir de cette valeur terminale.
En conclusion
Voilà pour cette tentative d’éclairer « l’écriture informatique » sous un angle différent. Il n’y a évidemment pas de réponse universelle à cette question. C’est une affaire largement subjective et la beauté d’une solution informatique n’est pas tant dans l’enchaînement des caractères numériques que dans l’intention du codeur de rendre les choses agréables.
Pour finir, vous trouverez sur le site “99 bottles of beer“, les différentes versions d’un algorithme écrit dans 1500 langages et générant les paroles de cette chanson. Alors, quel est selon vous le langage le plus esthétique ?
Nous avons choisi Blacklight comme interface publique pour notre catalogue. Voici comment nous avons procédé pour indexer les données de notre SIGB et comment nous allons intégrer d’autres données (revues et livres électroniques).
Pour faire fonctionner Blacklight en mode OPAC de nouvelle génération d’abord, il a fallu répondre à 3 questions :
comment importer toutes les notices du SIGB dans l’index Solr ?
comment obtenir les données d’exemplaires (donner la disponibilité) ?
comment gérer les services et l’accès au dossier lecteur ?
Paramétrage de l’index Solr et procédure d’import
Blacklight n’est à proprement parler que l’interface qui permet de gérer l’affichage des données et les services au lecteur. Celui qui fait tout le boulot de traitement des données, c’est le moteur Solr. Il s’agit donc de lui faire avaler des données au format MARC ISO2709 afin qu’il puisse les indexer et les proposer sous forme de facettes, par exemple.
Indexation
La version standard de Blacklight proposée en téléchargement fournit une configuration de base opérationnelle. Mais comme c’est un produit développé aux États-Unis, le format par défaut est le MARC21. Donc, au minimum, pour une BU française, le travail consiste à remplacer les étiquettes de champs MARC21 par des étiquettes UNIMARC. Plutôt facile de mettre 200 là où on trouve 245 ! Mais quand on aborde les notions d’auteurs secondaires ou de titres complémentaires, on se rend compte que les deux formats ont une manière de voir les choses bien différente.
Pour obtenir des facettes intéressantes, il faut réaliser des mappings comme celui-ci, qui concerne le type de document :
# format mapping
# leader 06-07
map.format.aa = Article ou communication
map.format.ai = Ressource à mises à jour
map.format.ac = Recueil
map.format.am = Livre
map.format.as = Revue
map.format.lm = Ressource électronique
# leader 06
map.format.b = Texte
map.format.b = Manuscrit
map.format.c = Partition musicale
map.format.d = Partition musicale
map.format.e = Carte ou plan
map.format.f = Carte ou plan
map.format.g = Vidéo
map.format.i = Enregistrement sonore non musical
map.format.j = Enregistrement musical
map.format.k = Image
map.format.l = Support informatique
map.format.m = Ressource multimédia
# 007[0] when it doesn't clash with above
#map.format.h = Microforme
#map.format.q = Partition musicale
# none of the above
map.format = Indéterminé
Pour la facette « Sujets », nous avons utilisé les mots-clés RAMEAU en séparant les subdivisions : tout ce qu’on trouve en $a ou $x constitue une vedette « thème » tandis que les $y et $z sont distribués « région » et « période ».
Importation automatique
Comme on veut disposer de données bibliographiques à jour, il faut mettre en place deux procédures automatiques : une pour exporter la base catalographique du SIGB, une autre pour importer les données dans l’index Solr.
Nous avons demandé à notre fournisseur de SIGB (GFI) de créer une procédure d’export de toutes les notices au format ISO2709. Donc, tous les jours, l’ensemble du catalogue est mis à jour.
Ensuite, nous avons développé un script shell qui permet, toutes les nuits, d’effacer l’index et d’importer le fichier ISO généré par AbsysNET. Après avoir longtemps buté sur la question des notices supprimées dans le SIGB, nous avons en effet choisi d’effacer tout l’index avant import. Cela permet de ne pas avoir à gérer d’import différentiel (i.e. seulement les nouvelles notices) ni d’avoir à retraiter les notices modifiées ou supprimées. En effet, il nous a semblé impossible d’extraire des indicateurs fiables pour identifier les notices à traiter : pas de données dans le label de notice UNIMARC (position 5 concernant le statut de la notice).
Connexions pour les données d’exemplaire et du lecteur
AbsysNET comprend un serveur Z3950 qui permet d’interroger la base Oracle. C’est sur ce serveur que l’on s’appuie pour interroger en temps réel la base des exemplaires et connaître leur disponibilité.
La page Blacklight qui affiche la notice détaillée d’un document intègre une requête Z3950. Le serveur Z3950 d’AbsysNET renvoie une réponse XML qu’il suffit de mettre en forme à sa guise. Nous affichons donc les données d’exemplaires en tableau et indiquons par une icône rouge ou verte si le document est disponible, c’est-à-dire non emprunté, dans telle ou telle bibliothèque du réseau.
Notice détaillée avec disponibilité des exemplaires
En ce qui concerne le dossier lecteur et les services associés, nous utilisons un connecteur développé par GFI. Connu sous le nom de zabnetarch (car conçu pour fonctionner avec les portails Archimed), ce connecteur permet d’interroger les données du fichier lecteur et d’interagir avec les services permis par les politiques de prêt.
Notice détaillée avec bouton de communication
On peut ainsi intégrer des boutons pour demander un prêt (et générer l’impression d’un bulletin), réserver un exemplaire, prolonger un emprunt et fédérer toutes les informations dans une page « mon compte ».
Personnalisation de l’interface
Nous n’avons pas passé de temps sur la partie graphique du catalogue. Nous nous sommes contentés pour le moment d’utiliser le thème standard de Blacklight. La mise en forme nous a semblé bonne et nous n’avons pas fait de cet aspect du projet une priorité.
Nous avons travaillé essentiellement à la traduction de l’interface et des libellés, avec le souci de sortir du jargon bibliothéconomique. Ce n’est pas toujours facile d’y parvenir… Ce même souci de lisibilité nous a conduits à simplifier autant que possible la lecture des notices. Il a fallu faire des choix quant aux champs à afficher. La tension est forte entre la clarté de la présentation et l’exhaustivité de l’information donnée. Compte tenu des remarques des uns et des autres, ce travail se poursuit, d’ailleurs.
Pour illustrer le catalogue, nous avons utilisé les API Google Books qui permettent d’afficher les vignettes de couverture des ouvrages. Après quelques déboires dus à la requête sur l’ISBN (Google digère mal les tirets), nous avons traité les notices de manière à obtenir systématiquement un EAN. Le taux d’affichage des vignettes s’en est trouvé amélioré. Mais c’est encore insuffisant. Notre catalogue est peu illustré, nous le voyons bien avec notre page d’accueil qui recense les nouveautés.
Faute d’un taux de couverture suffisant, nous avons provisoirement affiché nos titres dans un cadre représentant un livre. Nous obtiendrions certainement de meilleurs résultats si on utilisait les API d’Amazon. Mais ici comme ailleurs, le débat reste vif entre les tenants de l’efficacité (plus de vignettes grâce aux API Amazon) et les défenseurs du petit commerce (non à la publicité pour le géant d’internet). Il faudra bientôt trancher.
Configuration de Solr
Dès les premiers tests, il est apparu que les résultats donnés par Solr ne nous convenaient pas. Il a fallu bien se documenter sur son fonctionnement avant d’en saisir les mécanismes et de pouvoir agir sur le calcul de pertinence.
Le plus difficile pour un bibliothécaire est de rompre avec la rigidité des sacro-saints opérateurs booléens. Certes, ils sont utilisés par le moteur mais pas seulement. C’est tout un système de pondération qui peut être paramétré. Le moteur est tendu vers un objectif : donner des résultats. Il n’aime donc pas répondre qu’il ne trouve rien.
Tout l’équilibre réside dans le fait de trouver les termes demandés tout en suggérant d’autres pistes. Solr donne la priorité aux premiers termes saisis et à leur place dans la notice. Le premier résultat de la liste sera toujours la notice qui contient tous les mots saisis dans son titre. Si ce n’est pas le cas, alors le moteur revoit ses exigences à la baisse : des mots placés dans le corps de la notice, moins de mots retrouvés, etc. Et puis si vraiment il n’y a aucune concordance possible, Solr fait des suggestions.
Là encore, les mécanismes sont complexes et tout est différent d’une langue à l’autre. Solr doit être paramétré pour le français afin qu’il puisse analyser les structures de mots pour corriger une faute d’orthographe ou étendre ses recherches à une famille de mots.
Nous avons beaucoup de connaissances à acquérir dans ce domaine pour optimiser le comportement du moteur.
Et maintenant ?
Notre catalogue est en place, sur un mode OPAC de nouvelle génération puisqu’il n’intègre que les ressources imprimées gérées par le SIGB. Il s’agit maintenant de travailler à l’indexation de nos ressources électroniques. Certaines sont déjà présentes : les livres électroniques pour lesquels nous disposons de fichier de notices au format ISO2709 sont indexés directement par import.
Mais le gros des ressources devra faire l’objet d’autres traitements. La base de connaissance SFX pourrait être importée au format CSV et fonctionnerait avec des liens open url. D’autres ressources dont les éditeurs proposent des échanges via le protocole OAI-PMH nécessiteront le développement d’un moissonneur.
Gaivota Bird oiseau Vogel uccello aves 鳥 птица – Sur Flickr par Rodrigo Sá – Licence CC BY 2.0
Déployer Blacklight offre plusieurs avantages. Tout d’abord, son serveur web proposé par défaut n’est pas assez robuste pour une mise en ligne. Nous devons donc en installer un nouveau à même d’assurer un nombre de visites élevé. Ce sera Apache avec le module Passenger.
Apache n’est plus à présenter dans le monde du développement web. Quant à Passenger, il s’agit d’un programme adossé à Apache pour rendre accessible en ligne une application faite avec Ruby On Rails. C’est une architecture complexe.
Si l’on récapitule :
Ruby est un langage de programmation.
Ruby on Rails est un framework, construit avec Ruby.
Blacklight est un moteur de recherche construit avec Ruby On Rails.
Apache et Passenger sont un serveur web mettant en ligne un logiciel fait avec Ruby On Rails, en l’occurrence : Blacklight !
Outils pour une maintenance aisée
Ces composants sont obligatoires pour rendre disponible notre nouveau catalogue. Nous utiliserons également Capistrano et Git pour faciliter les mises à jour du serveur de départ au serveur d’arrivée.
En revanche, ces deux derniers programmes ne sont pas nécessaires. Le déploiement peut se faire en copiant simplement les fichiers sur le serveur d’arrivée. Pourtant, même en étant un adepte féru de simplicité, leur relative complexité de prise en main est largement pondérée par ce qu’ils apportent.
Git pour garder un historique
Git, que l’on configure sur le serveur de développement, est un outil désormais prisé pour la gestion de versions. Il va nous permettre d’archiver toutes les étapes des développements ultérieurs. On pourra l’utiliser également pour rétablir une version antérieure de notre catalogue en cas de problèmes de mise à jour par exemple.
Déployer avec Capistrano
Capistrano est un logiciel écrit en Ruby permettant le déploiement automatisé d’une application d’une machine à une autre. Depuis le serveur de travail, il va se charger, avec très peu d’instructions de notre part, de déployer Blacklight en ligne, de passer d’une version à l’autre, ou de le mettre à jour aisément.
Il n’est pas simple dans cette nébuleuse d’utilitaires, modules, applications, serveurs de voir qui fait quoi et à quoi ça sert. Au final, on finit par l’oublier et ses avantages permettent de se concentrer plus profondément sur l’amélioration de Blacklight.
Voilà, notre catalogue est en ligne… Ah non me dit-on ! Il reste encore quelques menus détails à régler, mais bientôt Blacklight sortira en pleine lumière à la BCU…
Quand l’eau se fait RUBIS -Par CHRIS230*** – Licence CC BY-NC-SA 2.0 – Sur Flickr
Suite de notre série de billets sur Blacklight, commencée par une présentation générale.
La question qui nous intéresse désormais est de savoir comment connecter Blacklight à un SIGB. À priori, les nouvelles sont peu réjouissantes car Blacklight ne connait ni le z3950, ni OAI-PMH, ni aucun autre protocole pour interroger directement un catalogue. On peut l’alimenter d’une seule manière par défaut : en lisant des données au format Marc en XML ou ISO2709. Cependant, on peut le faire communiquer avec un catalogue, via z3950 notamment, sans devoir reprogrammer entièrement un client dédié. Si z3950 ne peut pas servir a récupérer un catalogue entier il peut être utile en revanche pour récupérer des informations en direct, comme les données d’exemplaires.
Nous allons utiliser ruby-zoom, une bibliothèque écrite en ruby et interrogeant ZOOM, une API disponible pour développer des services autour de z3950 (ce composant existe aussi pour PHP et C).
Pour l’installer sur un serveur Debian disposant d’un environnement Ruby, cette commande suffit :
[sourcecode language=”bash” gutter=”false”]$ apt-get install yaz libyaz4-dev[/sourcecode]
Ensuite, dans le fichier Gemfile de BL, ajoutons la ligne :
puis, dans le répertoire de BL, exécutons la commande suivante pour terminer l’installation de ruby-zoom (il sera compilé puis installé dans ruby on rails) :
À cette étape, il faut mettre la main à la pâte et programmer en Ruby. Le plus simple est de créer un nouveau modèle dans le framework Ruby on rails de BL dédié à la connexion z3950. Voici un exemple utilisant les fonctionnalités de ZOOM.
[sourcecode language=”ruby”]
class Z3950
attr_reader :ip, :base, :port, :url
attr_accessor :keyword
def initialize(ip, base, port)
@ip = ip
@base = base
@port = port
@url = @ip + ‘:’ + @port + ‘/’ + @base
end
def search
resultats = ”
begin
ZOOM::Connection.open(url) do |conn|
rset = conn.search(@keyword)
rset.each_record do |record|
resultats += record.xml
end
end
resultats.force_encoding(“ISO-8859-1”).encode(“UTF-8″)
rescue
nil
end
end
if root.respond_to?(‘elements’)
#parcours des champs 998
root.elements.each(“datafield[@tag=’998′]”) do |element|
resultab = {}
#pour chaque element fils on récupère les informations d’exemplaire (localisation, salle, cote, empruntable ou non)
element.each do |field|
if field.respond_to?(‘elements’)
resultab[:localisation] = field.elements[“[@code=’b’]”].text if !field.elements[“[@code=’b’]”].nil?
resultab[:salle] = field.elements[“[@code=’c’]”].text if !field.elements[“[@code=’c’]”].nil?
resultab[:cote] = field.elements[“[@code=’e’]”].text if !field.elements[“[@code=’e’]”].nil?
if !field.elements[“[@code=’h’]”].nil?
if field.elements[“[@code=’h’]”].text == ‘ ‘
resultab[:empruntable] = nil
else
resultab[:empruntable] = field.elements[“[@code=’h’]”].text
end
end
end
end
resultats << resultab
end
end
resultats
end
end
[/sourcecode]
La méthode search définie ici s’occupe de la connexion au serveur z3950 et la méthode get_localisations récupère et traite la réponse XML du serveur pour obtenir les données d’exemplaire.
Il reste à ajouter quelques lignes de code dans le fichier catalog_controller.rb ou l’on utilise les deux méthodes précédemment créées, puis dans le fichier show.html.erb pour afficher les résultats obtenus. Voici le résultat sur notre serveur de test, suivi des quelques lignes de code adéquates dans la vue et le contrôleur.
Affichage des données d’exemplaire dans BL
Le code à ajouter dans le fichier catalog_controller.rb :
[sourcecode language=”ruby”]
# surcharge de la méthode show du module catalog de blacklight
def show
@response, @document = get_solr_response_for_doc_id
connexion_z3950 = Z3950.new(‘X.X.X.X’, ‘base’, ‘port’)
connexion_z3950.keyword = @document.id
resultats = connexion_z3950.search
@localisations = connexion_z3950.get_localisations(resultats)
respond_to do |format|
format.html {setup_next_and_previous_documents}
# Add all dynamically added (such as by document extensions)
# export formats.
@document.export_formats.each_key do | format_name |
# It’s important that the argument to send be a symbol;
# if it’s a string, it makes Rails unhappy for unclear reasons.
format.send(format_name.to_sym) { render :text => @document.export_as(format_name), :layout => false }
end
Le développement web devient une tâche rapidement complexe quand il s’agit de rendre un site compatible avec le plus grand nombre de navigateurs possibles. D’un côté, HTML5 ET CSS3 font course en tête et sont chaque jour un peu mieux pris en charge par les nouveaux navigateurs. De l’autre, Internet Explorer dans ses versions 6 et 7, freine l’utilisation des nouveaux langages qu’ils comprennent très mal, ou pas du tout. Ajoutons à cela, l’expansion des mobiles et tablettes nécessitant des feuilles de style dédiées et le casse-tête devient difficile à résoudre. Pour tenter d’y voir plus clair et adapter nos choix techniques en conséquence, nous pouvons utiliser les statistiques du site web (fournis par notre logiciel Piwik) qui fournit des informations détaillées sur les équipements de nos usagers.
D’abord, Piwik fait la distinction entre le nombre de visites et le nombre de visites uniques (un visiteur est alors compté une seule fois même si il visite le site plusieurs fois dans la journée). Les résultats sont sensiblement différents entre ces deux chiffres. Le nombre de visites est significatif des utilisateurs les plus actifs tandis que le nombre de visites uniques représente mieux la diversité des visiteurs. Voyons ce qu’il en est pour les navigateurs de nos usagers.
On voit que le navigateur Chrome est largement représenté (camembert de gauche) mais que c’est Firefox et Internet Explorer qui sont les plus utilisés (à droite). Quand on regarde les statistiques plus précisément, Internet Explorer 6 et 7 comptabilisent 10% des visites.
Pour les utilisateurs de mobiles, les chiffres sont surprenant. Leur proportion est de 10% en visites uniques et tombe à 1% quand on regarde leur activité sur le site (la catégorie “autres” contient des systèmes aussi incongrus que la playstation ou la nintendo wii).
Que conclure de ces chiffres ?
D’abord, la proportion des usagers d’Internet Explorer 6 et 7 n’est pas négligeable et les développements doivent tenir compte de leurs spécificités. Adieu donc les bonnes pratiques de développement en CSS et adieu également aux innovations de pointe proposées par CSS3. Nous pouvons cependant utiliser la technique de dégradation élégante qui permet de rendre le site compatible avec tous les navigateurs pour un rendu meilleur sur les plus modernes et moins bon sur les plus anciens.
Concernant les mobiles, leur proportion est loin d’être négligeable également mais leurs utilisateurs ne semblent pas réellement actifs sur le site. Comme nous n’avons pas encore de feuille de style dédiée à ces équipements, c’est compréhensible. Cependant il serait intéressant de connaître l’usage réel fait avec ces appareils (une recherche documentaire semble peu probable sur mobile) pour mieux connaître leur impact.
Petit outil clé-en-main pour bien démarrer l’année universitaire…
Nous avons repris l’excellent billet de Lully pour l’adapter à notre catalogue absysNET et proposer une extension du navigateur Chrome permettant d’afficher, pour une requête Google, le nombre de résultats dans le catalogue local. Voici ce que cela donne en image :
Le nombre de résultats du catalogue dans la page Google : ici, BU Nice et BCU
Nous ne reprenons pas ici toutes les étapes de constitution de l’extension, puisque Lully l’a très bien fait. Nous nous contentons de livrer les fichiers adaptés aux catalogues absysNET (merci Mathieu) dans lesquels vous pourrez modifier les url et les libellés.
1. Récupérer l’ensemble des fichiers nécessaires
Nous avons mis à disposition sur notre serveur le fichier .zip qui contient les fichiers à modifier. Assurez-vous que vous pourrez placer sur un serveur PHP le script nb_res_bcu.php pour faire vos tests. Dézippez puis modifiez les codes comme suit.
Script nb_res_bcu.php (pour “nombre de résultats BCU”) : vous pourrez bien entendu renommer vos fichiers en changeant sudoc ou bcu le cas échéant.
function getUrl($url){
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL,$url);
curl_setopt($ch, CURLOPT_HEADER, TRUE);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, TRUE);
$res=curl_exec($ch);
curl_close($ch);
return $res;
}
// Cette page va passer une requête au catalogue
//BCU pour récupérer le nombre de résultats
if (!isset($_GET['q']))
{
print "Manque la requête en paramètre";
exit;
}
$q = $_GET['q'];
$q = str_replace(" ", "+", $q);
// On récupère la page correspondant
//au résultat de cette requête
$url = "http://195.221.120.229/cgi-bin/abnetclop?ACC=DOSEARCH&xsqf99=".$q;
$res = getUrl($url);
if (preg_match('/URL=(.*)"/', $res, $match))
$new_url = 'http://195.221.120.229'.$match[1];
$res = getUrl($new_url);
$tab_sortie = Array();
if (preg_match(
'/Enregistrementss[0-9]+/[0-9]+sdes([0-9]+)/', $res, $match
))
$tab_sortie["nb"] = $match[1];
else
$tab_sortie["nb"] = 0;
print json_encode($tab_sortie);
Vous devez ici changer l’url de requête vers l’OPAC absysNET en modifiant la racine du serveur (votre adresse IP ou nom de domaine). La suite de l’url correspond aux paramètres de requête tout champ d’absysNET. Les lignes
if (preg_match('/URL=(.*)"/', $res, $match))
$new_url = 'http://195.221.120.229'.$match[1];
constituent une particularité d’absysNET car la page de requête génère une redirection (une page intermédiaire avant la page de résultats). Là aussi, modifiez la racine.
Cette ligne permet au script de déterminer, dans la page de résultats absysNET, où se trouve affiché le nombre de résultats. Si vous n’avez pas modifié le template standard de l’OPAC, pas de problème. Si oui, il faudra modifier la ligne de code en remplaçant tous les termes qui entourent votre nombre de résultats.
Vous pouvez maintenant déposer nb_res_bcu.php sur votre serveur PHP, de préférence dans un répertoire comme /BcuInGoogle/ puis faire des tests avec des requêtes comme http://biuintra.univ-bpclermont.fr/BcuInGoogle/nb_res_bcu.php?q=orwell. Vous vérifiez que le nombre de résultats est correct.
Fichier background.html
Vous modifiez l’url du script que vous venez de déposer (ligne 27)
var url = 'http://biuintra.univ-bpclermont.fr/BcuInGoogle/nb_res_bcu.php?q='+q;
Fichier sudoc_in_google.js
Vous modifiez les libellés relatifs à votre bibliothèque (lignes 22 et 32), l’icône logo.png qui se trouve dans le répertoire img de l’extension (remplacez par votre image 48 x 48), ainsi que l’url de requête vers l’OPAC (ligne 26).
Fichier manifest.json
Personnalisez votre extension en modifiant les lignes 2 et 4 et remplacez le nom de domaine de votre serveur à la ligne 17.
2. Empaqueter l’extension
Ouvrez Chrome et cliquez sur le bouton Clé anglaise. Dans le menu Outils, sélectionnez Extensions. Sur la page, ouvrez le mode développeur et cliquez sur le bouton Empaqueter l’extension. Choisissez le répertoire qui contient vos fichiers modifiés puis OK. 2 fichiers sont alors générés, dont un .crx qu’il faut placer sur votre serveur de manière à proposer le téléchargement de l’extension comme la nôtre !
Une limite importante à l’usage
L’extension fonctionne très bien sur la première recherche Google (les résultats peuvent s’afficher cependant avec une certaine lenteur en fonction de votre OPAC). En revanche, on n’obtient aucun résultat catalogue lorsqu’on modifie la requête. On s’aperçoit en effet que l’url de la page Google ne se rafraîchit pas correctement, la première requête étant conservée dans l’url. Donc, il faut toujours revenir à la page d’accueil Google pour faire une nouvelle recherche et bénéficier des résultats catalogue.
Quand une bibliothèque dispose d’un développeur, la question des logiciels libres est au cœur des développements. Leur utilisation amène pourtant des contraintes et influence l’organisation du travail. Voici un état des lieux sur leur pratique, avantages et inconvénients.
Un développeur seul n’est rien
Course de gnous – Licence CC BY-NC 2.0 – Par Thiery49 Flickr
Commençons par un constat : pour un développeur web, ce n’est pas très productif de programmer un logiciel de A à Z. La plupart des fonctionnalités de base (création de pages web, gestion d’utilisateurs, etc.) sont fournies par la majorité des CMS et il serait vain de vouloir faire mieux ou de les reproduire à l’identique en travaillant seul. Autre écueil, le travail d’une personne, ne peut rivaliser avec celui d’une communauté de développeurs fournissant mises à jour régulières et correctifs contre les failles de sécurité.
Cependant, on peut comprendre l’envie de l’informaticien de créer sa propre application. Concevoir, modéliser, pratiquer de manière avancée la programmation objet et les patrons de conception sont autant d’étapes passionnantes du cycle de développement. A la manière du forgeron, c’est en développant que l’on devient développeur et l’exercice de son cœur de métier lui permet de réfléchir à sa pratique de la programmation, le code devenant plus propre et efficace, et même beau, au passage.
Des logiciels de qualité
Partant de ce constat, l’utilisation des logiciels libres devient un atout considérable pour un service informatique en bibliothèque. Leur licence permet leur réutilisation, leur modification et offre au développeur la possibilité de les enrichir et les adapter en mettant ses compétences en application. La bibliothèque profite également du travail de la communauté de développeurs fournissant les logiciels, d’autant plus lorsque ces derniers sont spécialisés dans le métier. Leur nombre et leur diversité représente une manne considérable, souvent gratuite. A la BCU, nous n’hésitons pas à les tester et les déployer pour répondre à des besoins précis et ponctuels. Nous avons ainsi mis à disposition des chercheurs une galerie d’images numérisées (piwigo), pour qu’ils puissent les décrire en Dublin Core. Cette description sera réutilisable pour une bibliothèque numérique.
Bref, le tableau est presque idyllique mais à l’usage on rencontre quelques contraintes.
Une course à l’évolution
En premier lieu, intéressons-nous aux mises à jour accompagnant tout logiciel libre. Signe de bonne santé d’un projet, elles permettent de bénéficier des correctifs comblant les failles de sécurité inhérentes à tout logiciel complexe. Elles offrent également les toutes dernières innovations techniques et fonctionnelles du web. A priori, c’est donc un bénéfice de les installer et de faire évoluer le logiciel.
Mais ce processus a une contrepartie. Les temps de maintenance augmentent au fur et à mesure du nombre d’applications installées. Pour preuve, wordpress, utilisé pour l’alambic numérique, propose environ une mise à jour par semaine, que ce soit pour le corps du programme ou pour les extensions installées.
De manière générale les logiciels libres, au moins les plus actifs, souffrent d’une instabilité chronique (au sens d’évolution permanente). Prenons l’exemple de Drupal. Nous l’avons sorti en version 6, au moment même où paraissait la version 7. Dans un an et demi ou deux, quand la version 8 sera prête, la version 6 ne sera plus maintenue. Faut-il passer à la version 7 dès que possible ? Faut-il attendre la version 8 et refondre entièrement le site à ce moment là ? Si l’on veut respecter ces changements de version (et continuer à bénéficier du support de mise à jour), le remplacement du site impliquera de recommencer un cycle de développement (cahier des charges, acquisition de connaissances, formation des utilisateurs, etc.) peu de temps après le précédent.
Il faut toutefois pondérer cet inconvénient. Si le logiciel évolue, les services évoluent en parallèle. Dans deux ans, on peut imaginer que de nouveaux besoins seront apparus et que le remplacement de notre site deviendra évident, et pas seulement pour des raisons logicielles. En bibliothèque, l’avenir proche amènera sans doute à s’intéresser au web de données et au format RDF. On peut toutefois se demander si les efforts fournis aux étapes précédentes ont le temps de porter leurs fruits.
S’adapter au cycle de vie des logiciels apporte son lot de questions importantes : Comment gérer au mieux l’ensemble d’un grand nombre de logiciels installés en interne ? Comment ne pas se laisser déborder par les tâches de maintenance? Comment profiter des changements de version sans devoir tout recommencer à chaque fois ?
Nous n’avons pas les réponses dans l’immédiat, mais ces questions seront au cœur de nos travaux à venir…
Logiciels libres et bibliothèques est une association de plus en plus répandue. Leur utilisation amène pourtant des contraintes et influence l’organisation du travail. Voici un état des lieux sur leur pratique, avantages et inconvénients.
