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:

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.

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.