The Problem​

Documentation is an integral part of all software products, and for it to be useful, it must be comprehensive and detailed. However, this presents a challenge for both users and developers. Users, especially those who are newcomers to the software, can find it daunting to sift through large blocks of text, while developers often struggle to make documentation appealing and digestible.

Throughout university, I have been in the former category. As a user, I have always found documentation difficult to grasp. It often left me with more questions than answers. It especially did not help that the documentation websites I used often had terrible navigation and few resources to help me grasp what I was reading, leaving me scouring through various sites to find information that was tucked away in some hidden corner.

As a co-op student with LINCS, I was tasked with migrating the Canadian Writing Research Collaboratory (CWRC) documentation site. This website provided information about and access to the three ontologies developed by the CWRC, each with its own set of documentation. This had me worried, because how could I develop a website that could display documentation effectively while taking into consideration navigation, aesthetics, and page layouts?

I have spent most of my summer improving the accessibility of the LINCS project website. During this process, I have learnt so much about how those with disabilities navigate the Internet. There has been a lot to do, and it's taken up a lot of my time—but it certainly doesn't have to be that way! If designers incorporate accessibility from the beginning, minimal extra effort makes for a better experience for all users, not only those with barriers.

Image: Woman punch card operators working on Roberto Busa’s Index Thomisticus. Back left: Rosetta Rossi Bertolli; bottom right: Livia Canestraro. CC-BY-NC. Thanks to Melissa Terras, “For Ada Lovelace Day,” 2015.

I am surprised and thrilled that someone thought it worth nominating me for the Roberto Busa Prize, and overwhelmed to have been placed by ADHO in such illustrious company, fully aware that there is so much superb work in our community deserving of this recognition.

All knowledge is relational. It is fabulous to have recognition of scholarship that emerges from an intersectional perspective and is embedded in process: from making things that try to leverage technology in new ways, trying and failing, and yet continuing to try to make a difference to how we work and to enable us to create and share knowledge together, in better ways, in a changing world. For such work, collaboration is essential, which is to say it’s all about people.

My absolutely stellar colleagues here at LINCS gelled into a phenomenal team, even though we came together remotely, many of us for the first time, at the height of the pandemic, to build an infrastructure for linking scholarly knowledge across disciplines. The core LINCS team is at the heart of a growing network of scholars, students, and professionals who are, thanks to the combined efforts of these brilliant people, able to engage in serious exploration of the capacity of linked data to enhance cultural research and cultural experiences. The CWRC virtual research environment has involved 200+ wonderful people (and counting, since our credits need updating before we launch this spring as an instance of the LEAF software framework). And my belief in the magic of producing knowledge collaboratively in new digital ways grew out of formative experience as a new scholar in the Orlando Project, whose sterling participants include as active contributors ~150 students.

When designing and building a web application, ensuring that it is responsive is paramount. A responsive application looks good and functions well on all screen sizes and devices. LINCS applications are being designed to be viewed in a wide range of ways: from tablets to laptops to whiteboard-sized interactive screens. It can be quite hard to achieve this level of responsiveness, but with the help of CSS tools, techniques, and frameworks, the task becomes a lot easier...

In my first meeting this summer as a data science research assistant, we each followed our personal introductions with declarations of our favourite ice cream flavours. Mine was and continues to be Häagen Dazs’ Strawberry Cheesecake ice cream, and I was pleasantly surprised to learn someone else on the team felt the same. However, the biggest surprise was learning that someone enjoyed microwaving their ice cream to change its texture. At that point is it still ice cream? Is it soup? Or a milkshake? What even counts as ice cream? ...

I’ve always found that context changes everything when learning something new, especially when it comes to understanding why that something matters. The first example I can think of is how, for all the general chemistry courses I’ve taken, the concepts never really clicked, nor did I see why I had to learn them. Four of these courses later, I wasn’t very excited to take biochemistry, but when I did, I couldn’t believe how much of a difference it made to have a real context: the human body, where chemical reactions happen for a reason. Suddenly, the abstract became pretty important—I could see how it all fit together, and in turn, my understanding of general chem probably increased threefold. Rest assured, this blog post is not going to be about chemistry. Rather, it’s about how the same phenomenon occurred this summer, when working on the Orlando Project changed the way I think about data...

LINCS is using ResearchSpace as a platform for exploring relationships in interlinked cultural datasets. With ResearchSpace, researchers can browse, search, and visualize data in the LINCS datastore. In summer 2022, I was part of a team that was developing new features for LINCS’s version of ResearchSpace.

Our team was a collaboration between contributors with a background in user experience (UX) and contributors with a background in software development. We worked in tandem: the UX group recommended features to improve the experience of using the web application. These recommendations were turned into tickets in GitLab. The tickets described what the desired end product would be, and it was up to the developers to determine how to achieve this goal. The development lead shared tickets out among the software developers, dividing them up based on what would be required to build the suggested features...

If you’ve ever listened in on a technical conversation between computer scientists, you might’ve heard them refer to something called an Application Programming Interface (API). What exactly is an API? Let’s break it down...

The UX team has been conducting user research on LINCS tools to get them ready to move from development to production. So far, we have completed card sorts, usability tests, surveys, and interviews. This research has provided us with a wealth of information. However, if we want to translate what we’ve learned into meaningful, productive changes to the tools’ designs, we must keep actionability at the centre of our research practice...

As an English student, I was always told to keep my writing concise. Doing so was often easy because I could assume that the person reading my work would be an English scholar, so their expectations of my writing and the knowledge they brought to it would sit within a very specific range. In this way, I trained myself to default to an academic tone and level of complexity and to produce writing that was comparative and analytical.

This summer, however, as a member of the LINCS documentation team, I worked on an entirely different kind of writing: user guides and instruction manuals for the many software tools developed or employed by the project. To begin writing documentation, I first had to relearn how to write...