In this paper we re ect on our research of Japanese video game culture, with focus on strategies of interdisciplinary collaboration. We understand our collaborative research as ongoing negotiation that aims at nding common ground between researchers from di erent backgrounds. We decided not to work on a single extensive question over the research period. Instead, we chose to work on a number of smaller problems (called Tiny Use Case (TUC)) that are aligned with superordinate research interests. Various methods from both humanities and information sciences were adapted and customized to these needs. A fundamental mutual understanding is essential for the various tasks in the team. The right choice and mix of methods and tools does not only depend on the speci c team constellation (age, backgrounds, skills) but also a matter of available resources such as time, and the exibility to explore.
In this study we re ect on our research, focusing on strategies of interdisciplinary collaboration. This is not only about working together, but sharing knowledge and establishing a mutual understanding. Our pursuit of this goal will be contextualized within our current research of Japanese video games.
We found that several adjustments to pre-existing concepts were bene cial to our work. We present our strategies in more detail in later sections, but sending ahead a brief summary hopefully helps drawing the connection from research content to our collaborative strategies more easily.
We understand our collaborative research as ongoing negotiation that aims at nding common ground between researchers from di erent backgrounds. Flexibility is crucial for collaboration, as long as it means to balance freedom of action with bindingness of reached agreements. We formalized this in what we call TUC work ow which is described after a brief introduction of the project diggr. The next section provides the evolution of the research interest and points to di erent methods we used to collaborate. These methods are presented in the following section. After a re ection about limitations of our approach we will end this paper with a conclusion about our work.
diggr is a research project funded by the Deutsche Forschungsgemeinschaft
(DFG, German Research Foundation) and conducted by the IT department of
University Library Leipzig and the Institute for Japanese Studies of Leipzig
University. Our research focuses on Japanese video games in the context of global
resp. globalized video game culture. Six members of both the library and the
Institute for Japanese Studies with di erent disciplinary backgrounds
(Information Science, Librarianship, Cultural Studies, Japanese Studies) will attempt to
integrate expertise in data management directly in the research of humanities
scholars from 2017 until 2019. According to Tabak [
The project pursues two goals. Firstly, build a data driven research infrastructure that uses e.g. Linked Open Data technologies and provides scholars with best practice solutions. Secondly, generate substantial contributions to video games research in general, research of Japanese video games more speci cally. Our two humanities scholars lead their own sub-projects. The other sta members pursue tasks like software development, system administration or data modeling. One of these sub-projects will provide the context for our discussion and should, therefore, be presented as well. But before doing so, we discuss our adjusted use case structure which both sub-projects follow. 3
The beginning of the project presented itself as a challenge, as both the data
situation and the required technologies were unclear, which in turn made it
difcult to formulate objectives [
search interest for each TUC as a research question to the team. This is as sensitive as it is critical. Without at least a basic understanding of the research interest presented to them, D cannot be expected to provide guidance in regards to software solutions that t H's requirements. In turn, H have to adapt to the perspective of D if they want to be able to evaluate whether a proposed software does actually solve the task. This leads us to the next step, where negotiation shifts from conveying an idea to assessing adequacy of software tools. Exploring software solutions In order to enable H to specify their software requirements appropriately, knowledge exchange is key. The basic idea of our approach is that D and H educate each other about the respective domain speci c blind spots which leads to a common understanding and a shared technical terminology.
Evaluation A TUC work ow usually concludes with an evaluation. This is not only helpful for tracking progress of the team's work. It also allows us to critically re ect on the research conducted and to determine whether we reached the goals we set for ourselves. By evaluating frequently, as opposed to a single evaluation towards the end of a project, we have opportunity to thoroughly document our work.
One researcher in our team is investigating video game fan practices on social media in order to learn about their position and scope of action within the gaming industry. Many video game related practices on social media services like YouTube translate consumption practices into public or semi-public performances. By reconstructing careers of YouTubers, their transition from users to content creators to In uencers1, H12 intends to learn about the relation between fan practices, consumption and labour. What kind of labour is it being a Youtuber, which tensions do they face and how do attempt which changes in the gaming industry? 1 In uencer Marketing is a name for a strategy pursued by advertisers. The presumably stable relation between YouTubers and their audiences is targeted in order to convey advertising messages. 2 H1 refers to a single H-researcher
H1 chose the video game series Metal Gear as a topical frame. In TUC1, our
rst and rather prototypical TUC, H1 was interested in the reconstruction of
canonicity among the 31 titles that are associated with the series. He began his
exploration in one of the games [
In abstract terms, H1 found that the design of the Deja vu mission showed various references to titles from the Metal Gear series. Regarding gameplay mechanics (i.e. the design of player interactions with the game software), H1 found an odd, normative distinction in how players could interact with these in-game references. While being an optional objective, successful manipulation of the game world is rewarded with a personal message from lead designer and producer Hideo Kojima.
Equipped with a list of titles that were referenced in the aforementioned gameplay situation, we investigated Kojima's contribution to the productions. We approached this by analyzing credit information from transcripts of sta rolls4. This allowed us to associate person names with functions and production units, and to count the roles attributed to individual names. H1 interpreted his in-game ndings as an attempt to draw an image of Kojima as authorial gure and to enforce the canonic status of a subgroup of games from the Metal Gear series. While we could reconstruct that Kojima had the highest number of role attributions, several other sta member executed multiple production roles as well, indicating an inner circle surrounding Hideo Kojima. This dismantles the notion of him being the single author and shows that video game productions are predominantly team e orts. This raises questions on why and how the prominence of Hideo Kojima is maintained. 4.2
When it was time to begin TUC3, the focus then shifted to YouTube. This platform was chosen from various social media services. Aside from YouTube, we considered Twitch, Facebook, Twitter and Patreon. But eventually we chose to limit ourselves to researching YouTube due to its relatively high API request quotas and accessibility. This time, the research question was based on the assumption that practices like Let's Plays closely relate to consumption practices. 3 METAL GEAR SOLID V : GROUND ZEROES - Kojimas Kanonisierungsstrategie? https://www.youtube.com/watch?v=Z1frZ-zWptM 4 This is quite similar to movie credits. If public consumption of video games generates considerable income for the respective person, is it reasonable to view this as labour?
TUC3 was divided in three episodes, labeled with a, b and c. 3a was designed to perform an assessment of the eld, YouTube in this case. H1 stated that he views the relation between YouTubers and their audiences or communities to be of critical importance for social practices on YouTube. Otherwise, e orts like e.g. In uencer Marketing would make little sense and could not be as popular and e ective. The focus on social interaction determined the kind of data that had to be procured.
TUC3a produced valuable orientation and knowledge on how to cater to the researcher's requirements. The next two phases were headed in a similar direction: 1. extend the subject area, or: how much more data from YouTube can be handled with what tools?, and 2. stabilize the more advanced prototypes.
In order to decide on appropriate software solutions, D commissioned H1 to try already existing tools and document this as user stories. These documents provided the foundation for D to extrapolate H1's requirements. This includes tasks like interface design.
Although diggr strives for re-using existing solutions, this is not always possible. In order to enable individual researchers to deal with millions of comments on their own, semi-automated means of analysis seemed very appealing to us. DH-Tandems were formed in order to educate H1 on basic functionalities and align these methods with his superordinate methodological considerations.
Frequent evaluation of our progress did enable us to negotiate viable solutions. The results of these discussions were documented by H1 as requirement pro les. To experienced software developers, a requirement pro le might be a rather common tool. For a humanities scholar who is somewhat distant from IT matters, this might seem rather unfamiliar and by no means self-explanatory. 5
In this section we describe the methods and tools we used in the TUCs. We
made use of various methods from both humanities and information sciences
and adapted them to our needs. \As research generally is a creative process,
some of the most interesting research questions only develop over time" [
Figure 2 illustrates the process that lend to our inventory, beginning with selecting and customizing methods from rather speci c domains. If an evaluation shows that chosen methods su ciently helped solve their task, they are introduced to our inventory, which we discuss in the following sections. 5.1
Starting diggr's search for traces of Japanese video games turned out to be di cult, at least di cult to explain. Is there a shortcut that bridges the gap between H1, who spent many hours with the games, and D, who might only know the titles from trailers or hearsay? How can in-game research be presented to team members so they provide a starting point for further research? H1 adapted a common practice of video game enthusiasts called Let's Play. While videos of this genre may be very diverse, they all have in common that gameplay is recorded as video and then uploaded online for others to view. Our team bene ted from the low threshold and relative immediacy of this approach and, accordingly, we could soon start working on solutions. As the Research Let's Play can be seen as a protocol of an action or event, it is to be preferred over a live demonstration as it can be used as reference at a later time. 5.2
Finding a common language is essential, when it comes to accurate description of expectations on functionality and user interface of software tools. D tend to overestimate the IT skills of H, while solid knowledge of the current research is expected. On the other hand, H have to be careful not assume that D are aware of Humanities speci c presuppositions. Simultaneously, H depend on D's assessments regarding practicability of technical solutions.
In our group user stories turned out to be a good method to perform requirements engineering. H describes his expectations and wishes on the tools to be built, in simple and clear sentences. No attention is paid to the actual or presumed e ort necessary to realize these. This is essential as some features appear simple to implement but aren't and vice versa. The user stories are then discussed in a feedback round in the group. D and H together agree on the desired and realizable feature set.
However, these procedures might yield the insight that some requirements cannot be met. In our case, this occurred when researching various social communication services in regards to their API accessibility. We discussed Facebook, Twitch, Twitter, YouTube and Patreon. Restrictive APIs and issues of privacy protection were reasons to focus on YouTube. The decision on a subject area therefore is the result of frequent adjustments and ongoing negotiation between the involved parties within the team. Collaboration has to be intensi ed in order to develop solutions when requirements can neither be fully met nor abandoned. In the following section, we present one way that helped us solving tasks that require a stronger focus. 5.3
The DH Tandem consist of two persons: D and H. It is a temporary working group committed to a speci c and small work package, while the rest of the team works on other topics. In our case, the Tandem worked on the design of the research dataset.
In the process both, H and D become domain experts, as H gets a better understanding of the process of acquisition and composition of data, while D is introduced to the scope of the research question. During the tandem sessions, both parties develop a common vocabulary, which does not consist of new words, but technical terms from the elds of both D and H. The tandem members function as translators and contact persons outside the tandem for the rest of the team. They can be seen as the collective product owners of a research question. Therefore in the tandem sessions, both parties, D and H, are on eyelevel, but with a clear understanding of their roles. Therefore, it is possible for them to negotiate on the requirements of the software and research dataset. While cost here usually is not the limiting factor, it is human resources and temporal constraints that pose limitations on the nal feature set and extent. 5.4
Traditionally, when it comes to software, magic is allowed to happen { even
desired { to surprise the customer and enhance its user experience. Capability,
usability, performance, reliability, installability, maintainability and
documentation appear to be the only metrics to be accounted for when evaluating customer
satisfaction with software products [
In contrast, H do not strive for surprises, but comprehensibility. Magic is not
allowed. For reproducible science, the ow of data in the program, the
intermediate steps, manipulation, modi cations, enrichments etc. need to be made
transparent to H. Lack of transparency of the methods and transformations
applied appears to be a common problem with research software, as Gibbs et al.
[
Burghard et al. [
In contrast to commercial software development, scienti c development requires transparency and comprehensibility in regards to solutions and results. While individual TUCs are designed to be of short duration and intentionally limited scope, they line up iterative steps to contribute to superordinated research interests. Accordingly, this means including previously used data. In terms of comprehensibility, this iterative progression leads to the requirement to trace back how data was used and manipulated by whom. This is important for assessment and critique of the methods used and in extension the research conducted.
To allow for comprehensibility under these premises, this metadata about
the origin and modi cations of a le or data set is stored alongside the les. It
is shipped with every research dataset in our group. To ease creation and use of
provenance data the diggr team developed a tool for the creation, modi cation,
display and export of provenance information: provit. [
Graphical User Interfaces (GUIs) are essential for accessible research
infrastructures. Lower entry bars, allow more scholars to work on their research questions
empirically [
In contrast usable GUIs require a lot of e ort in creation and maintenance. Insisting on GUIs for every experiment in the research process con icts with the fast paced creative research process in general. (ib.) Often the tools D develop are only used once, or for a very limited amount of time. To verify our intuition, we developed GUIs for two applications: Human veri cation of automatically created links of entities of di erent databases and research of missing information on Japanese video game companies. After the tasks were completed, it was concluded, that the e ort required to develop and maintain these tools was to much compared to their utility.
Not developing GUIs is not an alternative we could a ord, so we decided to use parameterized GUIs, as they provide easy to use graphical representation of the data, with no need to navigate through code or command line interfaces. The advantage is, that instead of building hardly recyclable specialized GUI we now combine existing widgets, spend less time coding and more time educating H how to use the tools. Collaborating in this way was perceived to be way more sustainable, as the skills H learns in here are also useful outside the limited scope of a TUC, which cannot be stated for specialized GUIs. We acknowledge that other projects might come to di erent solutions for their projects, as our work ow is quite special and fast paced.
Elasticsearch, Logstash, Kibana (ELK) represents one of the most heavily used software stack in data science. Its popularity comes from its combination of powerfulness and ease of use. While Elasticsearch is a very powerful search engine, Logstash is a data processing pipeline collecting and aggregating data. Kibana is a frontend which can be used by the end user to operate Elasticsearch. With its integrated ltering and graphing tools it is useful to explore new datasets. ELK's great bene ts for H lie in emphasis on data exploration and dynamic visualizations. In our case, H require a solution that allowed for exportable visualization that maintain the connection to the referenced or aggregated texts. Since H intend to employ various software tools for di erent purposes (preselection of data, orientation, visualizations outside of ELK), ELK proved very useful as hub where all research data is stored and from where derived datasets can be send to other tools for further processing.
Jupyter Notebooks are used by all team members at almost all stages of the
software development process and research work ow prototyping process. \Jupyter
notebooks are one means to make science more open." They \embody the FAIR
(Findable, Accessible, Interoperable, Reusable) principles for digital objects and
assess their utility as viable tools for scholarly communication." [
Jupyter Notebook is a web based development environment and interactive user interface. The notebook server can be run in a data center. This turned out to be useful, as the computers H uses, sometimes are not powerful enough to run complex tasks in a reasonable amount of time. The notebooks are linear lists of cells, where each cell can be a piece of code, documentation, formulas, tables, images, plots and videos. With that, it can even be used to create interactive collages or even publications. The cells are executed one after another. Changes in one cell do not require the other cells to be rerun. E.g. to train a complex machine learning model, and then prototype the further data processing pipeline is very easy. This feature makes it a great tool for prototyping work ows and experimenting with datasets.
Jupyter notebooks also can be used in combination with repositories such as Github and Zenodo (for versioning and publishing). They o er a great intermediate step between providing a Graphical User Interface and exposing the scientists to a Command Line Interface. Getting in touch with source code in an environment which, through enrichment with pictures, explanations, plots and instructions can be way more appealing to a novice than a classical Integrated
Development Environment (IDE). Technical details are not hidden away, which
makes the whole work ow more transparent for the whole research group [
From H's perspective, this is a valuable solution because H's actions are limited to small customizations at speci c locations in the source code, as opposed to full access. The risk of causing damage to the software by unskilled editing or other reasons can be quite burdensome for H. Being freed of the need for permanent caution, H can contribute to the research process safely while also bene ting from working software { even at prototypical development stages. This is especially useful when refering to data analysis and (quasi-) dynamic visualizations.
Yet, being able to understand a scripting language is a valuable skill for H (ib.). We learned, that it helps H to follow the software development process more closely and get a better understanding of overall mindset. 5.7
H needs to be able to con gure programs according to their research interests and requirements, without having to build a GUI. A comparison of di erent machine data formats and data serialization formats led to the conclusion that YAML Ain't Markup Language (YAML), a data serialization format, is easy to be written by H and to be processed by our tools. YAML is with a clear syntax which shortens the time required by H to learn how to use it within the project.
In contrast to Jupyter Notebooks, which are used for analysis purposes, maintenance of con guration les turned out to be more practical when it comes to data acquisition. When assembling a dataset, e.g. from selection of YouTube channels, maintaining and managing YAML con guration les are relatively simple tasks which H can learn to solve more quickly than it takes D to write and provide Jupyter Notebooks { not to mention fully edged GUIs. 5.8
For texts which are not to be printed, like README les and documentation, blog posts, text drafts, meeting protocols, etc. document oriented le formats like Open Document Format and O ce Open XML appeared unsuitable, as we often ran into formatting and paging issues. While H mostly used Microsoft Word and other WYSIWYG text processors, the information scientists preferred LaTex. As a compromise we decided to use Markdown as markup language for text in general. This has the advantage, that it can be written in a collaborative manner with CodiMD, and the results are easily and predictably convertible to Redmine Markup (for the issue tracker), HTML (for blog posts), PDF (for documents) latex (for publications) etc.
While having many output options, the clear and minimal syntax make it easy to read and write. It can be used directly within Jupyter Notebooks, or semi-WYSIWYG editors like CodiMD. There is immediate feedback on the correctness of the markup used, which helps both D and H to learn and remember the new languages.
Using Markdown and YAML has proven to be an e ective approach for H and D to collaboratively work on projects with the same tools. This helps both the H and the D to better assess the skills and expectations of each other. 6
The methods presented here have proven to be e ective within our research group. Yet, they are far from being recommendable as best practices. The characters in the team and our environment aid intense collaboration. The relatively low demographic diversity in our team (all members between 28 and 38) may have contributed to nding common ground and a shared terminology. Team building events, such as gaming sessions in the GamesLab of the University Library Leipzig helped to build our team and increase the understanding for each other and the research context.
Spatial conditions might have made some methods and approaches more favorable than others. The whole team shares an o ce, which is (almost) exclusively used by diggr. Therefore face to face communication is common and problems often can be solved immediately without using an issue tracker.
Our TUC work ow has proven bene cial for collaboration in our team. But the applicability of methods outlined in this study is likely to depend on further customizations and adaptions by the adopting teams. A continuous evaluation of the research process helps to nd compatible methods. 7
In this paper we presented our experiences, methods and tools for collaboration inside the digital humanities project diggr. A fundamental mutual understanding is essential for the various tasks in the team. To choose the right mix of methods and tools for the speci c team constellation is a challenge and requires time, exibility and the willingness to experiment.
It has shown that the humanities can bene t from agile approaches and
methods in computer science. Computer science can also be enriched by the
humanities, for instance through the continuous re ection of one's own work [
With this paper we hopefully contribute to further studies about the collaboration in digital humanities projects.