Le problème​

La documentation fait partie intégrante de tous les produits logiciels et, pour être utile, elle doit être complète et détaillée. Cependant, cela représente un défi à la fois pour les utilisateurs et les développeurs. Les utilisateurs, en particulier ceux qui découvrent le logiciel, peuvent trouver décourageant de passer au crible de gros blocs de texte, tandis que les développeurs ont souvent du mal à rendre la documentation attrayante et digeste.

Tout au long de mes études universitaires, j'ai fait partie de la première catégorie. En tant qu'utilisateur, j'ai toujours trouvé la documentation difficile à comprendre. Elle me laissait souvent avec plus de questions que de réponses. Le fait que les sites web de documentation que j'utilisais avaient souvent une mauvaise navigation et peu de ressources pour m'aider à comprendre ce que je lisais ne m'a pas aidé, me laissant parcourir différents sites pour trouver des informations qui étaient cachées dans un coin.

En tant qu'étudiant coopératif chez LINCS, j'ai été chargé de migrer le site de documentation du Canadian Writing Research Collaboratory (CWRC). Ce site web fournissait des informations sur les trois ontologies développées par le CWRC et permettait d'y accéder, chacune avec son propre ensemble de documentation. Cela m'a inquiété, car comment développer un site web capable d'afficher efficacement la documentation tout en tenant compte de la navigation, de l'esthétique et de la mise en page ?

J'ai passé la majeure partie de mon été à améliorer l'accessibilité du site web du projet LINCS. Au cours de ce processus, j'ai beaucoup appris sur la façon dont les personnes handicapées naviguent sur Internet. Il y a eu beaucoup à faire et cela m'a pris beaucoup de temps, mais ce n'est pas une fatalité ! Si les concepteurs intègrent l'accessibilité dès le départ, un effort supplémentaire minime permet d'améliorer l'expérience de tous les utilisateurs, et pas seulement de ceux qui ont des barrières.

Image: Opératrices de cartes perforées travaillant sur l'Index Thomisticus de Roberto Busa. En arrière à gauche : Rosetta Rossi Bertolli ; en bas à droite : Livia Canestraro. CC-BY-NC. Merci à Melissa Terras, "For Ada Lovelace Day," 2015.

Je suis surpris et ravi que quelqu'un ait jugé utile de me proposer pour le Prix Roberto Busa, et ravi d'avoir été placé par ADHO en si illustre compagnie, tout en étant pleinement conscient qu'il y a tant de superbes travaux dans notre communauté qui méritent cette reconnaissance.

Toute connaissance est relationnelle. Il est fabuleux de voir reconnue une recherche qui émerge d'une perspective intersectionnelle et qui s'inscrit dans un processus : de la fabrication d'objets qui tentent d'exploiter la technologie de manière nouvelle, en essayant et en échouant, mais en continuant à essayer de faire une différence dans notre manière de travailler et de nous permettre de créer et de partager des connaissances ensemble, de manière plus efficace, dans un monde en mutation. Pour un tel travail, la collaboration est essentielle, ce qui revient à dire qu'il s'agit avant tout de personnes.

Lors de la conception et de la réalisation d'une application web, il est primordial de veiller à ce qu'elle soit réactive. Une application réactive est belle et fonctionne bien sur toutes les tailles d'écran et tous les appareils. Les applications LINCS sont conçues pour être visualisées de différentes manières : des tablettes aux ordinateurs portables en passant par les écrans interactifs de la taille d'un tableau blanc. Il peut être difficile d'atteindre ce niveau de réactivité, mais avec l'aide d'outils, de techniques et de cadres CSS, la tâche devient beaucoup plus facile...

Lors de ma première réunion cet été en tant qu'assistant de recherche en science des données, nous avons tous suivi nos présentations personnelles en déclarant nos parfums de crème glacée préférés. Le mien était et est toujours la glace Häagen Dazs' Strawberry Cheesecake, et j'ai été agréablement surprise d'apprendre que quelqu'un d'autre dans l'équipe était du même avis. Cependant, la plus grande surprise a été d'apprendre que quelqu'un aimait passer sa glace au micro-ondes pour en modifier la texture. À ce moment-là, est-ce encore de la glace ? Est-ce une soupe ? Ou un milkshake ? Qu'est-ce qui est considéré comme de la crème glacée ? ...

J'ai toujours trouvé que le contexte changeait tout lorsqu'on apprenait quelque chose de nouveau, en particulier lorsqu'il s'agissait de comprendre pourquoi cette chose était importante. Le premier exemple qui me vient à l'esprit est celui des cours de chimie générale que j'ai suivis et dont les concepts n'ont jamais vraiment fait mouche, pas plus que je n'ai compris pourquoi je devais les apprendre. Quatre de ces cours plus tard, je n'étais pas très enthousiaste à l'idée de suivre un cours de biochimie, mais lorsque je l'ai fait, je n'arrivais pas à croire à quel point cela faisait une différence d'avoir un contexte réel : le corps humain, où les réactions chimiques se produisent pour une raison. Tout d'un coup, l'abstrait est devenu très important - je pouvais voir comment tout cela s'emboîtait, et en retour, ma compréhension de la chimie générale a probablement été multipliée par trois. Rassurez-vous, cet article de blog ne va pas parler de chimie. Il s'agit plutôt de montrer comment le même phénomène s'est produit cet été, lorsque le travail sur le projet Orlando a changé ma façon de penser les données...

Si vous avez déjà écouté une conversation technique entre informaticiens, vous les avez peut-être entendus parler de ce qu'on appelle une Application Programming Interface (API). Qu'est-ce qu'une API ? Décortiquons-le...

LINCS utilise ResearchSpace comme plateforme pour explorer les relations dans les ensembles de données culturelles interconnectées. Avec ResearchSpace, les chercheurs peuvent parcourir, rechercher et visualiser des données dans le dépôt de données du LINCS. Durant l'été 2022, j'ai fait partie d'une équipe qui développait de nouvelles fonctionnalités pour la version de ResearchSpace du LINCS.

Notre équipe était une collaboration entre des contributeurs ayant une expérience de l'expérience utilisateur (UX) et des contributeurs ayant une expérience du développement de logiciels. Nous avons travaillé en tandem : le groupe UX a recommandé des fonctionnalités pour améliorer l'expérience d'utilisation de l'application web. Ces recommandations ont été transformées en tickets dans GitLab. Les tickets décrivaient le produit final souhaité et il incombait aux développeurs de déterminer comment atteindre cet objectif. Le responsable du développement a réparti les tickets entre les développeurs de logiciels, en les divisant en fonction de ce qui serait nécessaire pour construire les fonctionnalités suggérées...

L'équipe UX a mené des recherches auprès des utilisateurs sur les outils LINCS afin de les préparer à passer du développement à la production. Jusqu'à présent, nous avons effectué des tris de cartes, des tests de convivialité, des enquêtes et des entretiens. Ces recherches nous ont fourni une mine d'informations. Cependant, si nous voulons traduire ce que nous avons appris en changements significatifs et productifs dans la conception des outils, nous devons garder l'actionnabilité au centre de notre pratique de recherche...

Lorsque j'ai commencé mon premier stage coopératif, je n'avais aucune idée de la manière dont le développement de logiciels fonctionnait dans un environnement professionnel. Auparavant, je n'avais fait l'expérience que de la salle de classe, où mes camarades et moi-même développions des logiciels pour des travaux. Lorsque j'ai intégré un contexte professionnel, j'ai découvert de nouvelles méthodes de collaboration, notamment les réunions debout (stand-up meetings) ou les réunions debout (stand-ups)...