DHQ: Digital Humanities Quarterly
2017
Volume 11 Number 3
2017 11.3  |  XMLPDFPrint

Interdisciplinary Collaboration and Brokerage in the Digital
 Humanities

Anela Chan <anelachan_at_gmail_dot_com>, Independent Scholar
Tamara Kohn <tkohn_at_unimelb_dot_edu_dot_au>, University of Melbourne

Abstract

Interdisciplinary collaboration brings the benefit of multiple perspectives to a research project, yet it also provides opportunities for reflection on each discipline’s knowledge base. This article presents a case study in interdisciplinary collaboration between two disparate fields, web development and anthropology. We explore the challenges of translating between domains with differing values, aims and methodologies, as well as issues that arose for us during the development of a web application designed to provide a digital output of an ethnographic project. We consider our experience using the Agile style of software development, which emphasises rapid prototyping, iteration and even failure. In the long run, we find negative experiences in web development can be more valuable than the positive ones. The concept of ‘knowledge brokerage’ is a useful term to describe the collaboration between the academics – who were forced to conceptualise their data in new ways – and the developer – who negotiated these transitions between abstract information and binary data, and between academia and a public-facing web application.

Introduction

Interdisciplinarity is a key concept driving many calls for collaborative research and innovative teaching in the humanities. The benefits of interdisciplinarity in education (and research) include “an integration of knowledge, freedom of inquiry, and innovation”  [Boix Mansilla and Dawes Duraisingh 2007, 217] which is considered crucial to solving contemporary social problems and enhancing understanding of the arts and literature. That said, it is often difficult to embark on given that “disciplinary silos and discourse communities… stand as barriers to interdisciplinary research and education” which in turn keep researchers from benefitting from each other's knowledge [Borrego and Newswander 2010, 62]. This article recounts the story of an interdisciplinary research project (which united the fields of web development and cultural anthropology) that highlights failure as an important part of the research process. As an example, we reflected on the frequent crashing of the website by the anthropologists as they tried to input new material in a custom content management system. The anthropologists often entered data in ways that yielded the message “502 Bad Gateway”, an error which appears whenever two servers running simultaneously aren’t communicating. In the early days of the project, we came to see this phrase as a metaphor for the process of working collaboratively, with our web project traversing many gateways, between multiple viewpoints, priorities and interests, holding fast in some instances, and breaking down in others.[1] Despite its negative connotations, we employ this phrase constructively to explain the negotiated, stop and start process that characterised the working relationship between stakeholders. Forte, who has examined the social and cultural “constructedness” of websites, has written about the process of organising ethnographic data and recorded sounds as the:

product of intense social organization, brokerage and exchange, revealing quite a different story from that may appear on the seemingly placid surface of a site. Websites do not just tell stories; they contain stories within them about themselves.  [Forte 2005, 94]

This idea that a “seemingly placid” website conceals a dynamic and complex creative process that lies beneath also speaks to a more specific definition of what a digital repository is; it is not just a storage site, it is also a place to think through, to imagine what is not present and to interpret what is. Sonic Japan aims to be such a website, communicating these meanings by sharing sounds field-recorded in the sonically intense environments of Japan through a browser-based web application.[2] The site was created by an interdisciplinary team comprised of researchers in anthropology working with a graduate student intern (in the University of Melbourne’s Masters of Information Technology program[3]) who served multiple roles of product manager, designer and web developer (and is hereafter referred to as “the web developer”, even when discussing product and design concerns).
From an academic perspective, this project required a web presence because the researchers wanted a digital format for a broader audience and to provide a more immersive and holistic view of sonic practice through multimedia, including audio, text, and images. This requirement echoes a call from researchers in the digital humanities who wish to challenge “the primacy of text” to produce “an expanded concept of the sensorium of humanistic knowledge”  [Burdick et al. 2012, 121]. Scholars such as Bellamy [Bellamy 2012] and Murray and Wiercinski [Murray and Wiercinski 2014]have described digital humanities projects in terms of the ways in which software practitioners build tools for humanities scholars in the earlier “input” phases of the research cycle. Yet, Sonic Japan can be understood as a digital research output which demonstrates the intersection of utility (in terms of its educative dissemination of research findings) and art (as a creative and expressive product).
This article explores what was learned about web development, anthropology and interdisciplinary collaboration as the web developer and anthropologists came to work together. Web developers and academics both work within standard constraints such as time, budget and role management. The anthropologists, however, had to reconceptualise the way they viewed their data to produce Sonic Japan. For instance, rather than merely writing up their impressions of the field and adding analytic comments, they had to ask themselves new questions regarding information and ethical considerations, such as: What metadata needs to be attached to the sound files to be meaningfully understood in a digital domain? How do ethical requirements regarding privacy and anonymity in human research interface with the precision of digital representation in terms of mapping and description?
For the developer, on the other hand, the challenges around the translation and interpretation of data in the digital realm were not unique, because software engineers routinely work with non-specialists. Rather, her challenge was to effectively act as a “knowledge broker” between the academics, their data, the software, and a public audience. Meyer defines knowledge brokers as those who “facilitate the creation, sharing, and use of knowledge”; they also “establish and maintain links between researchers and their audience” and “link know-how, know-why, and know-who [...] in the public domain as much as in the private domain” [Meyer 2010, 119]. This definition was an apt one for the web developer, who was focussed on taking the anthropologists’ data to a lay audience via the website, a distinct task outside the anthropologists’ comfort zone of writing for academic audiences.
As in often the case in independent study projects, the web developer took on the project with vague goals, no clear workflow and no budget to be completed within the 12-week internship period. Despite this, she used an iterative development style called Agile to overcome some of these obstacles and was able to launch a prototype site within the timeframe. Presenting initial user interface prototypes to the anthropologists helped expose further goals and design questions. Bugs emerging during the implementation of a content management system for Sonic Japan’s sounds also invited a re-examination of code and engineering methodology. Later on, deployment on the web led the developer to re-evaluate product development methodology, design decisions and project priorities. While the anthropologists had no experience with the startup mantra of “fail fast, fail often” (and were generally frightened at the thought of visible failure!), they soon found that the refrain certainly applied in the anthropology domain, and had undeniable benefits.
In the first part of this article we outline the gaps emerging when the two fields of web development and anthropology collaborated on this project. Then, we discuss the application of web development methodologies for Sonic Japan, focusing on design questions and the critical intersection between the interdisciplinary teams’ various definitions of “success” through prototyping and iteration. Lastly, we reflect on the hindrances and opportunities that emerged from our interdisciplinary partnership, using the metaphor of a “bad gateway” for the learning experience.

Anthropology versus Web Development

Anthropology sits somewhere between the social sciences and the humanities, and since the 1980s has been known for its reflexive and critical gaze. Ingold notes that

[p]erhaps uniquely among academic disciplines, anthropology thrives on the art of its own perpetual deconstruction. Caught at the intersection of two cross-cutting tensions, between the humanities and the natural sciences on the one hand, and between theoretical speculation and lived experience on the other, it leaves little room for intellectual complacency.  [Ingold 1994, xii]

On the other hand, web development is more concerned with synthesis than analysis, particularly the synthesis of tools and systems to solve problems. Developing Sonic Japan prompted both anthropologist and developer team members to rethink their definition of “data”. In object-oriented programming, data is typically a series of fields or attributes which together form an object analogous to a real-world concept. For example, an employee in X Department with salary Y, position Z and employee number 12345; this collection of attributes creates an instance of an Employee. Of course, the employee’s humanity is more complex than that, but a computer “thinks” only in ones and zeroes, and data must be parceled into discrete units for the machine to process. Thus, in computer science, data is a specific type of approximation of empirical reality. An object is an abstraction to the developer. Software engineering feeds on discovering abstractions, which form the basis of flexible, maintainable systems.
In winnowing down a complex world to one of binaries, or of fields and objects, the representation of nuanced ideas can be limited. Compared to software engineers, anthropologists see their data as constantly constructed, contextualised and contested in time, in space, and by the individuals involved as demonstrated through differences in language, sociocultural position and value. Categories are not so objectively defined, and often have blurred boundaries. Schreibman, Sievers and Unsworth note that collaboration in the digital humanities brings to light these differences, especially in the case of what they call “knowledge-bearing artifacts”:

The process of such representation – especially so when done with the attention to detail and the consistency demanded by the computing environment – requires humanists to make explicit what they know about their material and to understand the ways in which that material exceeds or escapes representation.  [Schreibman et al. 2004]

In this case, the web design and development process pushed the anthropologists to re-evaluate their data not only in terms of its content and communicative impact, but also what they themselves understood about their relationship to the data and how that relationship shaped its presentation and meaning. For example, one of the initial design proposals was to situate each sound as a marker on an interactive map, using the Google Maps API. Some sounds recorded in-place could be attributed to a single latitude and longitude point, but what of a sound recorded in motion? What of sounds recorded at the same site, but at different times? The anthropologists, as experts in ethnographic writing, had less experience in thinking about how best to organise and present the complexity of their material in ways other than text. However, the web developer faced the challenge of translating and ordering anthropological data into a version appropriate for a computer to manipulate, without sacrificing too much of the data’s cultural significance and analytic potential. Specifically, the anthropological data had to be modeled into objects with fields and data types to introduce enough abstraction to create a flexible system. Because the researchers had “been there” when the data was recorded, they often had very specific ideas about how it should be presented, and these requirements were not always logical to a developer aiming to design a web system based on repeat functionality through abstraction.

Differing Aims and Methodologies

Software engineering aims to solve problems with software systems. All methodologies that follow primarily stem from The User. Though business models and technical constraints are also considered during development, software that purely emphasizes the software engineer – instead of the user – would result in a product with limited potential. Thus, the software development life-cycle aims to satisfy users within constraints. This life-cycle typically includes phases of requirements engineering, design, implementation, testing and maintenance.
Meanwhile, humanities research generally aims to observe, transcribe and seek to understand human experience. While engineering and humanities projects both consider audiences, in engineering the audience is the consumer of a product who generates the goal through some need or desire. In the humanities, however, the author draws material from the empirical world to articulate questions that address problems. Humanities research can be seen as a form of both translation and authorial self-expression; the audience that consumes the research output is considered but likely not the primary driver of the output. A humanities research life-cycle would occur in roughly this order: project formulation, data gathering, writing, editing, submission for peer review, revision and publication. The design of output takes place after data collection, and before and during writing, and the text becomes the final product that appears to require no maintenance after publication (even if it may attract external critique and response). Humanities research has an interest in process and change, yet its outcomes – as in published findings as text – are in general static and unchanging.
If these textual products are mostly unchanging compared to software products, these methodology differences become even starker when considering Agile software development. Agile software development is iterative; rather than move from extensive requirements analysis to a “final product” over months or years, the developer rapidly cycles through requirements, design, implementation and test, often in cycles of two weeks or less. Its overall “philosophy” emphasises working software, customer focus, collaboration and flexibility, thus welcoming change [Cohen et al. 2003]. To align with these Agile values, the developer usually breaks up product ideas into small pieces of functionality to build a “minimum viable product” for immediate feedback. This feedback may take the form of user testing, A/B testing (a kind of semi-controlled experiment) or clickstream data – the goal is to discover whether or not the software is solving problems. Based on this feedback, the team can move on to the next iteration and improve the product more quickly, at lower cost and with fewer risks. Hence, the project is never finished but is continuously evolving.
Agile project management has become widespread among software developers. A recent Hewlett Packard survey noted that the majority of their respondents used at least some Agile styles in their project management, for reasons including enhanced collaboration, better quality software, increased customer satisfaction, decreased time to market and lower costs [Hewlett Packard 2015]. Moreover, this style of development aligns with such Tech mantras as “fail fast, fail often” and “move fast and break things”, which emphasise rapid learning, and especially learning through mistakes. This emphasis on failure and breakage is part of a self-critique process, a constant search for refinement. This differs from anthropology, where critiques of a textual product mostly occur after submission or publication, and arise from differences in opinion and interpretation more than from outright personal “failure”.

What's the Problem? Requirements Analysis

Software development, cyclical or otherwise, typically kicks off with a phase of “requirements engineering”. Here, technical team members engage with stakeholders and potential users to determine software needs. At the core of requirements engineering is the question, “What is the problem we are trying to solve?” When problems are clearly defined and analysed, the engineer can design an appropriate solution. For the anthropologist, the creation of a research question begins with the individual scholar, and is usually generated from previous research, encounters with the people whose ideas and activities become the center of study, or other serendipitous interactions.
Web development is concerned with problem-solving, but the digital humanities brings challenges because the question, “What is the problem we are trying to solve?” is not always immediately answerable; sometimes the research questions change as the research is gathered, sorted and contemplated. To illustrate this challenge: in contemporary software development, the design, product and engineering teams often write “user stories”. These user stories take the format:

As a X [type of user], I want to Y [do something] so that I can Z [accomplish some goal].

The user story format above somewhat mirrors Booth, Colomb and Williams’ description of the research process in the humanities, which involves a topic, a research question and a research motivator, or a meta-level statement about the world around us that advances knowledge:

I am studying X [topic] because I want to know more about Y [research question] to help my reader understand Z [research motivator].  [Booth et al. 2003, 52]

These stories are meant to drive feature design and development in software engineering, and to justify academic interest and investment in humanities research; combined, they represent the first step in the digital humanities creative process. It is important to stress that the “user story” seeks to satisfy an audience, and to encourage empathetic thinking to tailor a solution to the audience’s needs, while the Booth, Colomb and Williams framework seeks self-expression with a transformative effect on the reader (which is generally one-way).
In the digital humanities, the user story variables are not so easily filled, particularly when considering the goal of the user. One user story for Sonic Japan might be “As a student of Japanese, I want to hear / see / feel the culture of Japan so that I can better enhance my learning of the language, history and culture through deeper engagement with the ethnographic field.” Another could be “As a person interested in Japan and things Japanese, I want to  hear / see unusual sounds / images of Japan that go beyond the typical travel book / textbook / promotional website to satisfy my curiosity about this place and its people.” Thus, project goals were relatively abstract; rather, the anthropologists began with their desire to trigger ideas, feelings and associations in users, and to transmit cross cultural understanding through the digital expression of sensory and affective experience. The web developer had to “link knowhow (&) know-why” from the anthropologists to the public via the eventual website [Meyer 2010, 119]. As such, the user stories for a site like Sonic Japan demonstrate evolving relationships between knowledge, audiences and technology. The Internet facilitates circulation of knowledge, and the web developer plays a critical role as knowledge broker between users and scholars.

Developing Sonic Japan

The idea of a sonic-focused website was inspired by a rich body of research in anthropology. In the past few decades, a “somatic turn” in the humanities and social sciences has inspired an internationally recognised field of sensory anthropology, which rightly points out an over-reliance on the visual and the auditory in anthropology [Classen et al. 1994] [Howes 2003]. Erlmann noted that even for those writing about sound, instead of examining “scores or meanings that are the result of acts of inscription”, we should “instead focus...on the materiality of...communication [and] issues of sensuality.”  [Erlmann 2004, 2]. How to best achieve this, however, has puzzled social scientists for generations. Charles Seeger, the forefather of American ethnomusicology, addressed these limitations of text and declared that speech and music are incompatible as modes of communication and indeed that we should be musicking about music [Seeger 1977, 179]. It follows that we should be “sounding” about sound more generally.
Thus, by emphasising sound, the anthropologists in this project hoped to encourage the user to focus on and think critically about auditory details and how sound is produced, linking the sound to action and in some cases intent. They thought a focus on sound might also help to take the user out of his or her visual and intellectual “comfort zone” by destabilising the sensory focus of the experience, opening up new channels for interpreting cultural information. We can never fully share a sensory moment, but can help our audiences imagine that moment with the aid of a number of sensory and other cues [Kohn 19994, 25].
To support the reception of aural data, we considered a variety of visualisation methods to portray sound through a browser-based user interface. In fact, Sonic Japan joins a tradition of digital projects – arising from sensory anthropology, urban studies, ecoacoustics, sound art and even technology startups – that present sound recordings through the web and mobile apps. For example, repositories of user-uploaded sound recordings like Soundcloud or Foundbite make sounds – including field recordings – accessible with search and social features. Archivists like those at the British Library have also undertaken this endeavour. On the browser, geographic sound maps (like the MoMA Sound Map or the University of Turin/Bell Labs’s Chatty Maps), interactive graphs[4] or video game-like experiences (like Sounds of Street View) create highly interactive, multi-sensory experiences of sound that depart from the ‘primacy of text’, capitalise on browser technology and invite engagement from broader audiences. However, the researchers noted that these technologies often fail to provide anthropological context, and were impressed with sound blogs like the Sensory Studies Sound Gallery which pair sound recordings with ethnographic description.[5] Ultimately, the Sonic Japan team decided that it wanted a product with the voice and context of a blog, the spatiality of a soundmap, the searchability of a Soundcloud and the interactivity of a graph or immersive experience, aiming for a holistic representation reinforcing our view that sound is a complex whole.
The Sonic Japan project could be seen as a “gateway” which sought to combine both the goals and processes of the two disciplines involved. Our process was as following: After initial discussion of the anthropologists’ requirements — which at times appeared nebulous and difficult-to-measure to the web developer — she started designing with pen-and-paper drawings, later expanding to build mock-ups and dummy prototypes. She then developed working prototypes, concentrating on small segments of functionality, which were critically reviewed by the anthropologists as well as university IT advisors. By participating in design and examination of prototypes, all the team members were encouraged to think with empathy about the user, refine the story they wanted to tell, and consider the implications of varying visual communication choices.
The anthropologists often found the Agile style confusing because of the wealth of possibilities and multiple and frequent decisions about which direction to take. This recalls Schreibman, Sievers and Unsworth’s comment on how collaboration with computer scientists pushes humanities scholars out of their comfort zone [Schreibman et al. 2004]. Moreover, prototyping revealed design questions that provoked the anthropologists to defend their choices of subject matter, and claims of relevance to a wider audience. In many ways, this validated the Agile style as we felt we were moving quickly toward a stronger product by examining its actual sensory effect, though we lacked the financial resources to conduct real user testing. Overall, we sought to strike a balance between user-focused design and the presentation of academic ideas, with a revealing dialogue emerging as a result.

Design Issues Discovered

To illustrate the collaboration’s effect on anthropological research, the following section describes various presentation issues discovered during the prototyping process. In each case, discussions during the collaborative design process led the anthropologists to better define their desires for Sonic Japan as research output and to rethink how their data would fit into the web medium.
For example, representation – how to locate the sounds in space – meant that the basic sound files needed to be associated with a series of metadata. For the anthropologists, this raised a number of issues. What photos should be associated with a sound? The photo of the object, person or machine that made the sound, the landscape in which the sound was produced? Another design issue was that of curation of material. Sonic Japan did not need to be curated – sound data could be presented without significant editorial commentary but rather a small amount of metadata, focusing instead on the less personal properties of the sounds (such as audio, categorical or geographical) to encourage a user to explore on her own – for example, through an interactive graph. But after initial design discussion, the anthropologists felt their main contribution to the project was not only the recording of sounds but also the “value added” commentary that would augment the user’s experience by relating the sensory experiences of the anthropologist at the time of recording. This is consistent with Burdick and colleagues, who characterise the digital humanities partly “by an emphasis upon curation as a defining feature of scholarly practice.”  [Burdick et al. 2012, 121]. Hence Sonic Japan organises its sounds around the notions of Places and Themes, partially to introduce geographical and cultural concepts to those without background knowledge of Japan. Further, rather than publishing sounds without comment, we added titles, textual descriptions, and blog posts to enhance accessibility, interest and understanding through academic curation.
Figure 1. 
Map markers are linked to contextual information about the sound recording
Figure 2. 
Blog post snippets give researcher perspectives and analyses
The anthropologists also debated the use of crowdsourcing. Many sound maps and other websites utilise crowdsourcing through user contribution. This heightens the potential for gathering large amounts of data, introduces a multiplicity of perspective and invites a continuous stream of fresh content. However, after reviewing prototypes, the team decided against extensive use of crowdsourcing because they questioned whether these additional voices and perspectives might push aside the researchers’ unique contributions to the project (as in the curation and contextualisation issues described above). For example, for Place and Theme page visuals, the team considered supplementing the researchers’ images with user-generated photos from Flickr, which provides user-uploaded photos through its API. Yet, the anthropologists raised concerns over the appropriateness of “random” draws of images from Flickr, as prototypes revealed that user-generated photos sometimes created inappropriate or misleading associations with our data, for instance with the API sometimes presenting tourist photos with a potentially Orientalist framing. In general, non-contextualised data could be misleading, such as offering up sounds of traffic in Tokyo (potentially creating an image of a congested polluted city, devoid of the quiet green spaces which exist there too) or only presenting the sounds of traditional music “frozen in time”, without explaining its role in contemporary society.
The final design issue considered during prototyping was the privacy of human subjects captured in the recordings. Geolocation technology creates the potential for individuals to be unknowingly and perhaps unwillingly tracked as well as personally identified. Deciding which recordings should be disassociated with geo-data to protect subject anonymity was difficult. Though we did not identify the subjects’ names, some of our recordings contain fully audible conversations. These were recorded in places that could be construed as public, but given that people’s movements often align with spatial and temporal habits, we envisioned potential privacy infringement. Further, many people conduct private conversations in public spaces believing that no one is listening, and some conversations may have been recorded without all of the speakers’ knowledge or consent. Yet, we also considered that sound is spontaneous and moves in and through private and public spaces, which naturally brings potential for privacy infringement. Upon examination of Sonic Japan’s automatically generated sound maps, the anthropologists decided to protect only the spatial anonymity of vulnerable subjects such as children and patients at an alcohol treatment centre by masking the exact locations of these recordings; other sounds were presented without anonymity.
All of the above issues exemplify the effect of Agile web development on the creation of an anthropology-focused web application. In the Sonic Japan case, the prototypes presented at weekly meetings helped the anthropologists clarify their desires for a sound website as curated research output that would highlight their unique perspectives and emphasise contextualisation of the sounds, while still providing value to a variety of users. In other words, the web developer “brokered” sessions where her knowledge was harnessed to explain possibilities of her design as well as to forecast the format’s limitations. Not all of the anthropologists’ wishes could be answered, but in these failed attempts, the researchers gained new perspectives on their data. These discussions added new layers to a research project previously focused mainly on recording sounds and producing written commentary – a positive effect through occasional bad gateways.

Beyond Prototypes: Methodology Issues

Rapid prototyping brought Sonic Japan’s design questions over visualisation, curation and privacy to light, which lent support for the Agile style. Yet for the web developer, this project eventually lent support for multiple product development and engineering methodologies, creating new learning on the digital side of this digital humanities collaboration.
For example, one criticism of Agile is that while it avoids over-engineering in favor of flexibility and working code, it can lead to under-engineering, especially by novices who are overly concerned with shipping features instead of sound technical design (see [Cohen et al. 2003]). Rakitin objects that Agile’s focus on working software is “an attempt to legitimize hacker behavior”  [Rakitin 2001, 4]. Indeed, Sonic Japan’s web developer eventually had to refactor application code to introduce appropriate abstractions. While this repayment of “technical debt”  [Krutchen et al. 2012] does not necessarily invalidate Agile development, it illustrates the need to strike a balance between rapid prototyping and a more planned style of engineering. In another example, when developing a content management system for uploading sounds and entering sound metadata, frequent emergent bugs both invited code repair and lent credence to methodologies like Test Driven Development (TDD), in which tests are written before implementation (different from the previously described software development lifecycle). As per Janzen and Saiedian, TDD’s test writing is “essentially an analysis step” that should clarify code requirements and improve code quality by encouraging early refactoring [Janzen and Saiedian 2005]. For Sonic Japan, the developer learned the value of TDD through literal breakages during development.
Further, once the web application was deployed, the developer-as-product-manager quickly perceived a lack of data support in favour of the initially chosen designs. Though the team had iterated to ensure alignment with research needs, the product manager did not have any hard numbers nor even anecdotal feedback proving that Sonic Japan was achieving goals of reaching users, of introducing users to Japan and sensory anthropology, and of “triggering feelings and associations”. Thus, we needed to track user actions through web analytics. Data from web analytics caused the developer to question design decisions. For example, initial data revealed low user engagement with the website’s sound maps, with many users leaving the map page without interacting with the sounds. Highlighting the anthropology commentary in the form of blog posts instead of maps, however, gave different results, and this data provided concrete evidence in support of curation.
Furthermore, with analytics data, the developer refined project priorities on the whole toward a system of formalised project goals and metrics. For example, the analytics data revealed that few people were actually visiting the site since the team had not initially focused on marketing or distribution. After all, one of our goals was to break out of what Parker has called the “ivory tower” model of research communication [Parker 2013, 50] to make publications and recent knowledge accessible to a wide variety of readers. Did our data indicate that the digital format was not helping this project to reach a wide variety of readers? The developer-as-product-manager decided the project needed to focus more on distribution, and progress toward this goal would be measured by unique visits, search engine rankings, social media followers and/or subscribers. Hence, the developer-product manager began to work within a new framework of goals, measurement and specific tactics to align with both goals and data.
The project proved to be a continuous evolution not only in terms of design and implementation but also in terms of methodology, process and management style. Thus, the developer, besides negotiating between the researchers and software, also began to negotiate between the project on the whole and the outside world. Through failures, bad gateway errors and dismal analytics data, the developer learned the importance of different methodologies, even for a project that initially seemed to lack of concrete problem definition.

Conclusion

How scholars study the social world — how they see the world, how they record it, how they relate their version of the world to others, and how readers react to the stories presented by others — is increasingly mediated through communication technologies. These technologies afford new ways of capturing and sharing ideas, creating a new record of social life that that can be conceived as truly “beyond the text”. Technologies do not just mediate the outcomes, however; they have the potential to frame inquiry from the start into new and exciting territory, encompassing the sensorial experience (albeit a mediated one) that the text cannot always deliver.
This article has charted the ups and downs of an ongoing collaboration between anthropologists and web developers and how brokerage led to problem solving; it also demonstrates that provides an opportunity for us to think about the ways in interdisciplinary research advances in stops and starts rather than in smooth progression which we move forward in this relationship. As a case study in interdisciplinary collaboration in the digital humanities, Sonic Japan provided an opportunity for web developers and anthropologists — despite their differences in their definition of data, goals, disciplinary values and methodology — to create new knowledge. While these differences may lead to friction, confusion and errors when developing a web application, they can also lead to positive outcomes. The interdisciplinary nature of the Sonic Japan project prompted new ways of thinking for team members in both web development and anthropology research, as the design and development process brought a host of challenges to light. These challenges spanned design issues as well as methodology. The anthropologists grappled with the best way to represent their data in the web medium, struggling with the need to monitor their level of curation and maintain location privacy in an ethical way. Meanwhile, the web developer sought to bring the anthropologists’ research practices within methodological frameworks of product management and software engineering, despite their preference for flexibility. Rapid prototyping and testing revealed issues anthropological, technical and even managerial, demonstrating the value in continuous iteration for this interdisciplinary exercise. Thus, our experience creating Sonic Japan can serve as an illustrative example of an interdisciplinary developmental process. We speak to our case study as a transformative journey rather than a destination, a journey that traversed various disciplinary “gateways”.

Notes

[1]  Note that the pronoun “we” is used throughout the paper when referring to actions and ideas shared by the interdisciplinary team. When designers and anthropologists are isolated in their experience, this will be indicated appropriately.
[2]  The sound data was collected as part of the Australian Research Council project Sonic Japan DP130102035 and involved the researchers travelling to Japan to conduct ethnographic fieldwork in different locations, collecting sound recordings of different events and activities accompanied by interpretative text.
[3]  This internship was initially for 12 weeks and was then extended into a research assistant position attached to the research project.
[4]  See for example an audiophile’s interactive project: http://daftpunk.themaninblue.com/

Works Cited

Bellamy 2012 Bellamy, C. “The Sounds of Many Hands Clapping: Teaching the Digital Humanities through Virtual Research Environments (VREs)”, Digital Humanities Quarterly, vol. 6 no 2. (2012) http://digitalhumanities.org:8080/dhq/vol/6/2/000119/000119.html.
Boix Mansilla and Dawes Duraisingh 2007 Boix Mansilla, V. and E. Dawes Duraisingh. “Target Assessment of Students’ Interdisciplinary Work: An Empirical Framework Proposed”, The Journal of Higher Education, vol. 78, no. 2. (2007) 215–237.
Booth et al. 2003 Booth, W., G. Colomb, & J. Williams. The Craft of Research. University of Chicago Press, Chicago, 2nd Edition (2003).
Borrego and Newswander 2010 Borrego, M. and L. K. Newswander. “Definitions of Interdisciplinary Research: Toward Graduate-Level Interdisciplinary Learning Outcomes”, The Review of Higher Education, vol. 34., no. 1 (2010) 61–84.
Burdick et al. 2012 Burdick, A, J. Drucker, P. Lunenfeld, T. Presner, J. Schnapp. Digital_Humanities. Cambridge, MIT Press (2012).
Classen et al. 1994 Classen, C., D. Howes, & A. Synnott (eds). Aroma: The Cultural History of Smell. New York: Routledge, New York (1994)
Cohen et al. 2003  Cohen, D., M. Lindvall, and P. Costa. “Agile software development”, DACS SOAR Report 11 (2003).
Erlmann 2004 Erlmann, V. “But what of the Ethnographic Ear? Anthropology, Sound and the Senses”. In V. Erlmann (ed) Hearing Cultures: Essays on Sound Listening and Modernity, Oxford, Berg (2004) 1-20.
Forte 2005 Forte, M. C. “Centring the Links: Understanding Cybernetic patterns of Co-production, Circulation, and Consumption”. In C. Hine (ed) Virtual Methods: Issues in Social Research on the Internet, Oxford and New York, Berg, (2005) 93-106.
Hewlett Packard 2015 Hewlett Packard. Brief: Agile is the New Normal: Adopting Agile Project Management (2015) http://www8.hp.com/h20195/v2/getpdf.aspx/4AA5-7619ENW.pdf?ver=1.0
Howes 2003 Howes, D. Sensual Relations: Engaging the Senses in Culture and Social Theory. University of Michigan Press, Ann Arbor (2003).
Ingold 1994 Ingold, T. “Introduction”. In T. Ingold (ed) Companion Encyclopedia to Anthropology, Routledge, London (1994) xiii-xxii.
Janzen and Saiedian 2005  Janzen, D. and H. Saiedian. “Test-driven development: Concepts, taxonomy, and future direction”, Computer 9 (2005): 43-50.
Kohn 19994 Kohn, T. “Incomers and Fieldworkers: A Comparative Studies of Social Experiences”. In K. Hastrup and P. Hervick (eds) Social Experience and Anthropological Knowledge, Routledge, London (1994) 13-27.
Krutchen et al. 2012  Kruchten, P., R. L. Nord, and I. Ozkaya. “Technical debt: from metaphor to theory and practice”, Ieee software, vol. 6 (2012): 18-21.
Meyer 2010 Meyer, M. “The Rise of the Knowledge Broker”, Science Communication, vol. 32 no. 1 (2010) 118–127.
Murray and Wiercinski 2014 Murray, A. and J. Wiercinski. “A Design Methodology for Web-based Sound Archives”, Digital Humanities Quarterly, 8.2 (2014) http://digitalhumanities.org/dhq/vol/8/2/000173/000173.html.
Parker 2013 Parker, J. “Speaking out in a Digital World: Humanities Values, Humanities Processes”. In E. Belfiore and A. Upchurch (eds) Humanities in the Twenty-First Century: Beyond Utility and Markets. London and New York, Palgrave Macmillan (2013) 44-62.
Rakitin 2001  Rakitin, S. “Manifesto elicits cynicism”, IEEE Computer vol. 34, no. 12 (2001): 4.
Schreibman et al. 2004 Schreibman, S., R. Siemens, J. Unsworth. “The Digital Humanities and Humanities Computing: An Introduction”. In A Companion to the Digital Humanities, Schreibman, S., R. Siemens, J. Unsworth (eds) Blackwell, Oxford (2004), n.p.
Seeger 1977 Seeger, C. Studies in Musicology, 1935-1975, Vol. 1. Berkeley, University of California Press (1977).
2017 11.3  |  XMLPDFPrint