Working with the Tiny Use Case workflow methodology in the JVMG project

Following the success of our project launching workshop in July 2019, the work on processing community databases started in earnest (you can read about the technical details of the process in relation to ontology creation and data transformation). By November 2019, we were ready to start examining the data and our infrastructure through the lens of exploratory research.

We decided to adopt the Tiny Use Case workflow methodology to have a number of short-term research projects that would be substantial enough to generate meaningful and interesting results in their own right, but would be compact enough to provide an ongoing stream of feedback on issues with the database, the project infrastructure, and researcher needs. Since each Tiny Use Case is only 3-4 months long, it provides us with an excellent tool for assessing our progress and for uncovering newer issues, as each TUC has a different focus and somewhat different requirements.

The first TUC ran from November 2019 to February 2020, the second one spanned the Spring of 2020, and we are currently in the process of Tiny Use Case three, which started in June and is scheduled to run until September. With two TUCs already completed and one very much underway we already have a number of takeaways that have come out of these research projects. Some of these are minor, but can still lead to new features, like the implementation of the “simple” view on the front-end prototype. While others can be so fundamental that they are not readily resolvable within the span of a single TUC and become mainstay fixtures of the feedback to come out of subsequent TUCs. An example of such a takeaway is our on-going realization of the severity and thus work required when handling big data issues in the research projects.

The wrap-up and evaluation phase of the TUCs also offers a chance to momentarily stop doing what we are trying to do the hardest, which may or may not be the right way of approaching certain problems, and just look at the big picture again for some much needed reflection. One of the ideas that has come out of these “taking a step back to reflect” moments is the need to engage with the toolkit of network analysis. The most common tools used in data analysis require tabular data as inputs, but we are actually investing a lot of time and effort into moving data out of their original various tabular formats and into a unified linked data format. One of the defining characteristics of the linked data format is that we end up with a graph of all data elements. What if we could harness this aspect of the data structure, either to gain new insights specific to network analysis, or maybe to perform certain types of analysis more efficiently? We are currently exploring the opportunities opened up by this approach, and will be reporting on our findings here on the blog in the future.

Finally, thanks to the iterative nature of the TUC workflow methodology we can also experience the way the growth of our library of data extraction and analysis pipeline elements, as well as of our list of identified best practices, directly contributes to making each subsequent TUC easier to get off the ground and running. Not to mention the way communication between the library and computer science researchers and the humanities and social science researchers is becoming increasingly smoother with each new TUC, as both parties learn more and more about the concepts and tools of the other group, with an increasingly shared vocabulary emerging from our work together.

We look forward to sharing the most interesting questions and findings from each of our TUCs here on the blog, so stay tuned!

What is a Tiny Use Case?

The term Tiny Use Case, or TUC for short, was coined by the diggr (Databased Infrastructure for Global Games Culture Research) research project team. A detailed description of this workflow methodology can be found in their paper With small steps to the big picture: A method and tool negotiation workflow (Freybe, Rämisch and Hoffmann 2019).

Taking their inspiration from agile software development principles, the Tiny Use Case workflow was created to handle the needs of a complex research project that required the meshing of expertise from very different disciplinary backgrounds and involved a high level of uncertainty regarding the types of challenges that would emerge in the course of the project. By working through a series of three to four month long Tiny Use Cases the diggr team was able to leverage a similar cycle of continuous incremental innovations and assessments that is one of the main strengths of agile approaches.

In their description of the TUC workflow, the diggr project identified three key phases:

  1. Mediation of the research interest/object
  2. Exploring software solutions
  3. Evaluation

As they themselves put it: “The basic idea of our approach is that D [the digital expert] and H [the humanities scholar] educate each other about the respective domain specific blind spots which leads to a common understanding and a shared technical terminology.” (p. 15) Thus, in the first phase the humanities scholar provides a research question that needs to be explained to the digital expert, so that they can translate the requirements of the project into technical terms together. And then in the next phase the digital expert works together with the humanities scholar to find an appropriate technical solution that can deliver the right type of data for the question at hand. Finally, the evaluation step is where the successes/short-comings of the TUC are identified, and takeaways for further TUCs are abstracted from the process.

The Tiny Use Case workflow methodology was adopted in the JVMG project precisely because of the similarities in the challenges faced by the two undertakings. Most importantly, the JVMG project also involves bridging disciplinary boundaries and developing an understanding between library and computer science on the one hand, and humanities and social science on the other. The fact that the TUC approach had already been developed and tested in a previous project was a huge help going forward for the JVMG project. It is important to emphasize, however, that this did not mean that our project was spared the same kind of difficulties that the diggr project encountered. Rather, it meant that we were more prepared for the types of problems that would inadvertently arise, and had a clear idea that these challenges were not to be automatically taken as signs of something going wrong, quite the opposite, they are the necessary steps through which each such project needs to develop.