Collaborative Approaches to Archaeology Programming and the Increase of Digital Literacy Among Archaeology Students

: Digital methods provide archaeologists with ever-increasing opportunities to collect more data about the past in new formats. These larger evidentiary datasets, in turn, help us to address questions about the human past with increasing precision. To take full advantage of these opportunities, archaeologists must develop digital literacy skills and learn how to lead digital projects. Here, we describe seven digitally-based projects we have undertaken at the University of Pennsylvania in order to create new tools for archaeological data collection and sharing, as well as to test collaborative models for the digital humanities programming process. In these projects, archaeology students work directly with engineering students. Through this interface, the students from both areas gain valuable transdisciplinary experience while experimenting with new ways to accomplish programming goals and to collect archaeological data. The learning potential for these students was a key motivation for our initiative. Our projects have already led to several websites and digital applications that are available as open source downloads. We present our impressions of this collaborative process with the goal of encouraging other archaeologists to form similar digital humanities partnerships.


Introduction
Digital methods are now central to all archaeological practice, enabling archaeologists to record, analyze, and share data more efficiently, accurately, and openly than ever before.These improvements provide the opportunity for archaeology to participate in the Open Science movement, thus enabling quicker research advancement and greater impact and engagement with contemporary society.To take advantage of these new capabilities, archaeology students at all levels must now develop excellent digital literacy skills.For us, digital literacy means that archaeologists are not just proficient users of digital tools; they must be prepared to think critically about the creation and application of the tools as well, and be able to lead the development of current and future digital-centric methods for advancing knowledge.As digital methods have become embedded in the knowledge creation process, so too has it become necessary for archaeologists to be able to critically evaluate others' digital approaches and to design their own, just as archaeologists must be able to assess and design traditional programs of archaeological knowledge creation such as excavation strategies.base functionality of these existing off-the-shelf products, archaeologists should focus limited resources for custom computer programming on adapting existing solutions to better fit emerging archaeologyspecific needs.For example, how do archaeologists push forward the 3D scanning of artifacts so that the shapes of all excavated objects can be openly shared among projects in their complete forms (e.g., Karasik & Smilansky, 2008;Karasik et al., 2014), or how do researchers build comprehensive high-accuracy datasets of the surface colors of those objects (e.g., Stanco, Tanasi, Gueli, & Stella, 2012)?Using existing technologies and applying only the minimum computer programming efforts required to adapt and integrate them, the archaeological community efficiently improves its ability to collect more and better data.
Although archaeologists can learn programming, we rarely have time available to build tools ourselves, necessitating joint work with software engineers for these adaptive solutions.Central to our effort is the collaborative process, in which archaeology and engineering students work closely together.Over the course of four semesters at the University of Pennsylvania (fall 2016-spring 2018), we have undertaken several projects to address a variety of archaeological problems, allowing us to closely observe the teamwork processes.In our projects, we explored multiple ways to use existing resources at the university to create digital applications through collaborations among archaeology and engineering students.We partnered with classes in the engineering program to have student programming groups work on our projects as class assignments.We also found internal digital humanities funding to hire engineering students on a part-time basis to do programming work.We treat the entire exercise as a pedagogical experience since our archaeology students will need digital literacy skills in whichever career path they choose.We had the advantage that some of us on the archaeology side had previous experience working as professional programmers or in technology companies with programmers, but our goal was to provide this type of experience to all archaeology students.
In our projects, we have sought to make the best use of our technological resources by foregrounding the software development process itself.This paper first provides an overview of the seven programming projects and the archaeological problems we hoped to solve (see summary in Table 1).These are not unique problems, as many archaeologists face them, but through a detailed description of each we highlight the contexts in which the archaeology and engineering students learned together.We also hope to demonstrate how projects can be designed to solve real archaeological problems with minimal resources.Next, we turn to the collaborative process itself, detailing how we worked together.We sought out partnerships with engineering students in a variety of contexts, and we collaborated through a mix of in-person and online methods.Software development and management has been a major subject of business management research and instruction for decades (Brooks, 1975).This can lead to the assumption that software development is a fixed process, with little left to be learned.However, we learned from our experiences, so we end this paper with a reflection on the overall process and its applicability by other archaeologists and humanities researchers.

Related Work
Archaeologists were early adopters of digital technology, with groups beginning to discuss computer applications for archaeology at least since the 1960s (Chenhall, 1968;Brown, Freeman, Jr., & Martin, 1964;Wilcock, 1973).This utilization of computational methods has continued in archaeology up to the present day, with almost every field or museum-based project utilizing some form of digital methods.This ubiquity underpins the importance of an archaeologist's capability to manage digital projects, beginning during student training.
The annual Computer Applications in Archaeology (CAA) conference is replete with presentations about technical solutions to archaeological problems.Many examples find ways to adapt existing technologies to new applications in archaeology.Bobowski (2012) used free online database software to rapidly create data entry forms for field recording, thus avoiding the development costs faced by teams attempting to recreate data entry form functionality through custom programming.Gruber, Bransbourg, Heath, and Meadows (2013) developed a series of linked data approaches to studying ancient coins, some of which involved the use and modification of technologies borrowed from the commercial sector.Cascalheira, Bicho, and Gonçalves (2017) also tried to make as much use as possible of existing customizable software to improve data collection and analysis in the field.
Many archaeological teams have employed technical staff to develop custom systems and software for use in archaeological data collection and research (Kansa, Kansa, & Watrall, 2011;Ravindranathan et al., 2004;Smith & Levy, 2014).Laužikas, Vosyliūtė, and Jaronis (2016) coded in a customizable website development framework to create a web service that shares standardized local place names and other geographical information.Zambanini and Kampel (2013) developed an algorithm that uses computer vision technology to compare photographs of Roman coins to images in a reference collection, and were consequently able to reduce the time and expertise required to identify ancient coins.
Some examples even attempt to apply computer programming management frameworks directly to technical parts of the archaeological process.Baldwin and Flaten (2012) applied the Agile programming framework to the digital construction of 3d graphical models.This framework highlights iterative reworking of code together with close communication between programmer and client.In another example, Zhu, Wang, Keogh, Rampley, and Lee (2010) present their programming methods that apply several digital transformations and identification algorithms to the documentation of petroglyphs-a facet of material culture that has proved difficult to analyze via traditional means because of the wide array of motifs and the general subjectivity of interpretation.The team-composed of members from the departments of Computer Science & Engineering and Anthropology at the University of California, Riverside-overcame these problems by introducing a novel distance-measure algorithm.Their publication also provides an overview of their programming strategies.
Another major project of note is the Federated Archaeological Information Management Systems (FAIMS) in Australia, designed to build a digital system for recording archaeological data for that country (Ross, Sobotkova, Ballsun-Stanton, & Crook, 2013).This project is engaged with creating apps for data collection and dissemination both for cultural heritage initiatives and archaeological research in Australia, focusing on how to best record the heterogeneity of data that archaeological projects tend to create.Their team spent significant effort on the design process, collecting information from many archaeologists and technical specialists while developing their plans.Ultimately, FAIMS hired a team of programmers to create multiple apps.
Most of these projects, like ours, are focused on pushing the boundaries of what can be done with the technology, rather than reproducing functionality already available in off-the-shelf software.We hope that they will also make their software open source, as we have, so that the field as a whole can advance through widespread adoption of shared solutions (Ducke, 2013).In addition to the tool development common among all these projects, our goal is to make sure students get training in digital literacy and especially in the leadership of digital projects.Ultimately, all archaeologists should gain experience engaging with digital projects so that digital literacy will be as basic an archaeological skillset as excavation techniques.This would allow future archaeologists to take full advantage of the technology created by our and other projects through a familiarity with how to navigate software development communities, including knowing how to find and manage resources to adapt available open source software.

Technology Projects for Archaeological Research
As an initiative of the new Center for the Analysis of Archaeological Materials (CAAM) at the University of Pennsylvania, we have leveraged technological solutions to tackle several data collection and sharing issues faced by archaeologists (Table 1).Each of these projects engaged students from the University of Pennsylvania's School of Engineering and Applied Science (Penn Engineering).We began the collaborative process with archaeologists and archaeology students acting as "clients" for group projects in a set of software engineering classes where programming students experienced solving real-world problems.The archaeologists outlined challenges related to the collection of archaeological data and the requirements that must be met by software used during fieldwork.Groups of three to five engineering students developed software to address those challenges as a graded group project for their course.To continue development after these classes ended, we directly hired engineering students to work part-time on our projects, with support from the Price Lab for Digital Humanities.We also transitioned two web projects to the Digital Scholarship group of the Penn Libraries, where the websites will receive longer-term institutional stability and support.Our overall initiative provides a training ground for archaeology students to learn the complete lifecycle of digital project management.Our individual projects, outlined below, include websites, Android apps, and experiments with affordable new field equipment.Each of these projects aims to solve a different problem involving data collection or sharing within archaeology.Here, we provide an overview of the problems we identified and the solutions we are implementing.

For the Field
One of our goals in undertaking these projects is to improve data collection during archaeological fieldwork; we have focused on both surface surveys and excavations.Our first project tests new global navigation satellite systems (GNSS) equipment for recording precise geographic locations.Three more projects automate data acquisition routines for the artifacts collected from the field.One of these involves digitally scanning and reading object labels to automatically identify an object in a database.Then, two additional apps record data about the object directly into that database: one automatically reads data from peripheral devices (such as weight scales), while the other aims to use computer vision techniques to identify object surface colors in photographs.Our final field project saw the integration of these apps into a single app.

Precise Location Tracking
Our first project deploys new affordable differential GNSS equipment for measuring centimeter-level accurate locational information during archaeological fieldwork.An archaeological surface survey project typically implements an arbitrary division of space-for example, a high-level grid or the boundaries of existing agricultural fields-to geolocate finds.These survey units are the highest resolution geolocational recording units of the objects found by the fieldwalkers.In other words, the archaeologist will know that a ceramic sherd came from a particular survey unit, but not where the object was found within that unit.In this system, the finer the grid or division of space, the more granular and useful the locational data will be; however, finer divisions also require more time and effort to record and walk.By equipping each fieldwalker with a high-accuracy GNSS device paired with an automated data collection mobile app, our intention is to enable the efficient recording of a geolocation for each individual artifact found during fieldwalking and thus obviate the need for arbitrary survey units.GNSS equipment has been used at many archaeological projects and a particular type of GNSS, called differential GNSS, provides very precise locations by minimizing the normal errors that GNSS equipment faces when collecting data from distant satellites (Barratt, Gaffney, Goodchild, & Wilkes, 2000).This system works by placing one GNSS receiver over a known location, called a base, while another GNSS unit, often called a rover, is used to record dispersed points.If the two receivers communicate, the base can send spatial corrections to the rover, thereby increasing the accuracy of the locational data it records.Although differential GNSS technology is not new, it has reached the point at which its accuracy (many modules advertise three-dimensional accuracy of within a few centimeters) and, especially, price (under US $1000 per receiver) make it a viable tool for wider archaeological deployment.
Our goal was both to test one of these new low-cost differential GNSS modules and to build an app to help speed up the geolocation and photography of individual objects using a mobile device.The GNSS equipment we selected is a set of products under the brand name Reach, developed by a company called Emlid.We tried three Reach products: for our base module, we first tried a basic Reach, a lightweight circuit board and antenna intended for integration into other applications such as drones.The standalone circuit board appealed to us due to its costing only about $250, and we hoped it could function as a stationary base.Unfortunately, we were unable to establish a reliable communication link between this product and the GNSS satellites in the field.On the other hand, the Reach RS product that we also tested was able to acquire a stable signal.Therefore, we plan to use the Reach RS and the newer version Reach RS+ as both the base and rover.These products contain the basic Reach computer circuit board plus the antenna and battery protected by a ruggedized case.This ruggedized package costs about $700 for a single unit, but is much simpler to deploy; we chose the Emlid products for the field potential of the RS unit.Although we are testing this particular product, we note that a number of such price-competitive products have entered the market in the last few years.
To complement the differential GNSS modules, we developed a simple mobile app to enable the collection of point and artifact data during fieldwalking.The user carries both the rover (Reach RS) and an Android phone that serves as a camera, data recording device, and mobile hotspot to keep the rover connected to the internet so it can communicate with the base.When the user spots an archaeological find, such as a ceramic sherd, she or he uses the app to take photographs, record the point location in UTM, and note other basic data about the object such as material (Figure 1).We are currently using an Asus Zoomphone with this app, given that it has a camera with 3x optical zoom useful for photographing objects on the ground.The app stores data and photographs locally until synchronization is manually initiated to upload them to the main internet-connected project database.Software packages that record precise information in the field, such as ESRI's ArcGIS Collector, already exist, but such products are constrained in their ability to adapt to existing databases.In addition to being open source, the advantages of our freely-available app include the automatic acquisition of coordinate data from the Reach, greater customization and integration with existing project data gathering workflows, and the support of true relational databases.Through our Digital Humanities grant, we hired our first programmer for this project in the spring of 2017.He was able to build the basic Android app to collect the photographs and other data.A second programmer, hired on the same grant in January of 2018, has tested and troubleshot the GNSS hardware and integrated it with the app.Our initial field tests of the app and hardware within the Philadelphia metropolitan area led to our discovering the problems with the basic Reach circuit board and encouraged us to upgrade to the Reach RS+ for our second unit.In June of 2018, this app and hardware underwent final field validation during an archaeological surface survey project in the Middle East.The programming student continued development of the app as a member of the field team, joining the project through a travel grant from the Penn Museum.

Object Identification
Archaeological projects and museums usually assign unique identifiers to artifacts.These identifiers consist of strings of alphanumeric characters, containing meaning within an internal system and enabling differentiation of objects for maintaining an inventory.Projects often also use a database to record the characteristics of each object, linking data through the object's unique identifier.Each project has its own system for cataloging objects -an example identifier used by the Penn Museum would be MS3515, with "MS" indicating "Mediterranean Section," and a unique sequential number for the object in that section.Another example at the Penn Museum would be 67-19-2, indicating the (2-digit) year of accession, the group collection number from that year, and the sequential number of the object within that collection.At many projects, these identifiers are written directly on the objects.In some experiments, tiny QR codes have also been printed and glued onto objects (MacDonald, 2012;Smith & Levy, 2014).
Researchers must enter the object's identifier into the museum's or project's database to retrieve or record information about that object.Although this is normally quick for a single object, it does not scale well, and slows down any process requiring interaction with hundreds or thousands of objects at a large project or museum.We designed a mobile app that would help speed up this process by automating the recognition of the identifier on the object itself.Since each project may have a differently formatted unique identifier, the app has modular code that can be adapted by any museum or archaeological project.The app opens the device camera, where an Optical Character Recognition (OCR) function automatically scans the identifier written on or affixed to an object, and allows the user to manually correct any misread characters.This screen can also toggle to a QR code reader or to manual entry for the identifier.The app allows users to bookmark any objects that they would like to quickly revisit, and tracks their search history.Handwriting recognition proved to be a challenging problem, mainly due to the lack of significant openly available training sets for the machine learning algorithms, but we hope to continue to develop this functionality.
This app was initially built by a team of five programming students in an introductory software engineering class.Since it allows the identification of an object prior to further data collection, this app now serves as the entry point for additional data collection routines we designed.Two such routines were developed as separate Android apps, discussed in the following sections.

Peripheral Device Control
Archaeological projects record a variety of data about each object, and different types of data can be collected with specific digital devices.For example, an archaeologist might record the weight of an object using a precise scientific scale, or photograph an object using a digital camera.These devices are often referred to as peripheral in the sense that they augment the existing functionality of a computer, usually through a USB connection, without being a core part of the computer.Each of these peripheral digital devices normally captures information independently of a centralized database; a user must photograph the object and then manually organize the photograph files.The challenge is that each peripheral data collection device communicates using different protocols and application programming interfaces (APIs).We set out to build a mobile app that would enable the control of one specific peripheral device, a Bluetooth weight scale, while at the same time serving as a template for interacting with other peripheral devices (Figure 2).The goal is to be able to collect specific information about an object such as weight, but have that information automatically saved back to the main project database, obviating the need for manual data transfer steps.Weight provides a way to quantify archaeological objects.This app reads the weight of each object from a scale over a Bluetooth connection and then stores the weight in a relational database.Technological challenges make this more complex than it initially sounds.The specific hardware used by this app was the Reflex Wireless NutriCrystal scale.Surprisingly, at the time we were initially building this app, few scales of gram-level precision could communicate wirelessly, with the exception of kitchen scales targeted at cooking and dieting audiences.The first step in the app is to identify the object being weighed, thus allowing the data to be stored with the correct object database record.Next, the app must verify that it has an active Bluetooth connection to the scale.This step is particularly challenging because the scale has an automatic timeout of a few minutes.Thus, while the user has been completing other steps, the scale often powers down and the connection to the app is dropped, so the app must deal with this smoothly.The method by which the scale communicates data also complicates the programmer's job.The app cannot simply request the current weight on the scale; rather, the scale will broadcast a weight only when the weight measured by the scale changes.Therefore, the app must be prepared to capture this data at any time, whether or not the user has prompted the app to capture it.Then the app must deal with the weight's not changing if the user leaves the object on the scale.
Initially, a team of four programmers built this app as part of the same introductory software engineering class for which the other team produced the object identifier app.We hope that this app can eventually be expanded to connect to other types of wireless data collection devices.

Reading Color
Digital cameras have been central to archaeological work for over two decades, and they provide one of the quickest ways to capture comprehensive information about an object, including decoration, color, and scale.An app previously developed with support from the Penn Museum can remotely control a Sony QX1 digital camera and upload photograph files to a networked information system.Usually the files are renamed and placed onto a cloud server file system based on database identifiers, which is more efficient than placing these large files into a database but still retains the link between the database and the image files.We are expanding this camera app to include the ability to automatically measure surface colors of objects from the photographs.Traditionally, archaeological objects are manually compared to a Munsell color book in order to record an objective measure of surface color.Although specific surface color-measuring devices exist to facilitate this process, they require the extra steps of placing the device on the surface of the object and of transferring the data from the device to the database, both of which serve as impediments to processing large numbers of artifacts.Automatically gathering color information from the photograph that has already been taken as part of the object study process allows researchers to operate at a higher level of efficiency.
We have worked both with class projects and hired students to modify our existing app to add support for reading colors.Upon taking a photograph, the image is displayed on the screen of the mobile device running the app.We have experimented with a number of ways for the user to interact with the image through touch.Initially, the user was able to navigate around and magnify the image of the object, and use a finger to draw a selection box around an area in the image that she wished to identify as a "representative" color.A later iteration of the app has allowed the user to touch on the object and see an enlarged circle showing the average Red Green Blue (RGB) values of the pixels in an area around the touch point.This value is associated with the closest (in Euclidean space) Munsell color, and could also be associated with values from other color systems.The color value is then uploaded to the database.This function can be carried out multiple times, each time with the ability to designate the type and location of the target area, allowing for the identification of more than one color on polychromatic objects-for example, this enables differentiating between slip and decorative elements on a ceramic sherd.Currently the photographs are corrected with a white-balance function, but we next plan to add automatic color-correction of the photograph using a color standard placed in each image.

App Integration
The prior apps for collecting data about archaeological objects were built as individual projects in introductory computer science classes or by hired programmers.An advanced software engineering class provided the opportunity to integrate multiple apps into a single workflow.A group of engineering students combined the object identification, peripheral device control, and color-reading apps described above into a single app, which we now refer to as the archaeological object data collector app.In this single app, an object is identified using handwriting recognition, QR code, or manual entry.This leads to a screen on the mobile device that displays existing data about the object and provides buttons that allow the user to take further actions such as weighing or photographing the object (Figure 3).The user can then advance to the next object in the database or return to the identifier screen to read the label of another object.This combined app is designed to increase the efficiency of collecting data on many objects during fieldwork.We have also tried to modularize the code so that other projects can quickly adapt the app to use their database structures and object identifiers.The open source code is available for download on GitHub, where we continue to make improvements with the help of hired programming students (https://github.com/anatolian/archaeology-object-data-collector-app).

Data Sharing
The projects described to this point have focused on the "data collection" step of the archaeological process, attempting to increase quantity and accuracy.This sets the stage for the end goal: the open sharing of information online.The wide sharing of data enables reuse and revaluation of the archaeological record, thus following the Open Science paradigm.New platforms for the dissemination of archaeological data have become available in recent years, and there are already several sites available for basic data sharing in archaeology, including Open Context (opencontext.org),the Digital Archaeological Record (tDAR), and the Archaeological Data Service (ADS).We are developing two projects geared towards specific types of online data sharing: a website for sharing object datasets across projects and a geographical presentation of archaeological bibliography.

Object Sharing and Analysis Website
The open publication of archaeological datasets in existing online systems enables potential reuse of the data; these existing systems, however, still lack robust tools for directly analyzing data online, and most in-depth analysis occurs after data are downloaded.We designed a website that would allow more robust online comparison and analysis of archaeological objects.A user can create an online record for each object, and upload associated data, photographs, and 3D digital models (the website allows for the direct in-browser viewing of 3D models using the WebGL graphics library) to that record.These objects can be linked to objects uploaded by other users to form object groups.
One of the eventual goals of this website is to enable analysis of object data using an expandable set of algorithms directly within the website.For example, users should be able to collate a group of ceramic sherds, both from their own field projects as well as from neighboring projects.They should then be able to write an algorithm, within the website, that can compare the characteristics of the sherds within that group.For example, a researcher could write an R script that can quantify shape similarity among 3D models of sherds, and should then be able to share the algorithm for others to use.This may be enabled with programming environment containers that can run code on cloud resources.By obviating the requirement that data be downloaded before analysis, we hope to greatly increase the capability and speed of experimentation on the data with algorithms.This online sharing approach would also provide access to these algorithms for people who may not know how to write and run code themselves.
The construction of this prototype website began as an Introduction to Web Programming class project with a group of four student programmers.They constructed an initial infrastructure that enables user accounts, as well as the upload and management of object data.The website can also be used to view 3D models in the browser.A future project will focus on enabling dynamic analytical tools.

Mapped Bibliography
Scholarly publications about archaeological fieldwork often focus on single sites or regions, yet research on a wider scale necessitates the comparison of many proximate places.For researchers to find information about neighboring sites, they must have prior knowledge about the names and locations of those sites.Online mapping provides a way to index archaeological publications spatially and make site data more easily discoverable for researchers, thereby making the research process more efficient and opening the data to a broader audience (Cobb, 2008).This project created the initial prototype for a bibliographic resource that indexes archaeological fieldwork publications by the geographic locations that they address, and displays them at the corresponding locations on a map (Figure 4).The user interfaces with this dataset primarily through graphical, map-based searches.The searches can be further refined using the properties of the article such as authors, years, and keywords.To limit the scope of the prototype, the dataset currently contains bibliographic information only on current fieldwork in Turkey.The construction of the prototype website began as a class project for a group of programmers in the Web Programming class.The Penn Libraries Digital Scholarship group has undertaken further development.

The Digital Humanities Interface: Archaeology and Engineering Students Working Together
These projects required a significant degree of teamwork among archaeology students and engineering students.We have collaborated with engineering students in two ways: via structured courses with project teams and via non-class contexts with individual part-time programmers.We hired the programmers using digital humanities grants and advertised these jobs on the engineering student email lists.In either case, we held periodic meetings, either weekly or monthly in frequency.
We found that throughout the development process, archaeologists assumed four broad roles.First, we served as the projects' "clients" or "customers," with the responsibility of clearly articulating a need to a team of programmers in order to help them develop a useful and usable product.Then, we functioned as project managers, and participated actively in the programming progress by setting priorities, answering questions, testing prototypes, and offering feedback; again, our goal was to facilitate the development of a viable archaeological product through close collaboration with the programming team.Once the projects were completed, we became their end users, and have effectively deployed several in our field and museum research.Finally, we acted as observers and students throughout the development process, learning about it through our involvement in order that we may be more effective collaborators in future digital projects.At various stages, all roles were filled by both archaeology students and instructors, all with different degrees of prior technological experience.Although in some cases, certain roles were best suited to certain individuals (when programmers were hired, for example, an archaeology instructor with a grant was the primary client), we found that the general tasks of guiding, learning, and using had few prerequisites.
One of our primary motivations for engaging in these projects was to introduce humanities students to the software development process.Thus, for several projects, archaeology or ancient history graduate students attended the regular meetings as both project clients and observers.In these roles, they helped guide the design of the apps while simultaneously learning about the challenges of programming.Other projects were overseen by a CAAM archaeology instructor to guide the process from the archaeological perspective.In this way, the archaeologists served as clients for the programming projects.
Our development arrangement mimics how products are designed outside of academia; the client communicates specifications for a tool, and the programmer chooses how to build the tool to fit those specifications.During the process, the programming students would rely on us, the clients, to provide continuous feedback to ensure the project was fulfilling the articulated requirements.We also answered questions about the archaeological process so that they could better understand how we work in the field.As we reviewed progress during our periodic meetings, both parties would ask questions and make suggestions, so that adjustments could be made not only to solve the original problem, but also to make sure that the software could feasibly be completed within the allotted timeframe.As in non-academic projects, this process is closely collaborative, and is designed to make tool-building as efficient as possible, with all team members aware of the goals and progress.
The structured courses were introductory undergraduate and graduate software engineering (i.e., programming) classes offered through Penn Engineering that were designed to simulate the product delivery model for students.At the beginning of each semester when the courses were being offered (fall 2016, spring and fall 2017), we submitted multiple short project descriptions defining an archaeological problem and desired technical solution.Our projects were only a few of the dozens of potential projects that could be undertaken by the classes, with other project proposals developed by the engineering instructors or submitted by other departments on campus, such as Penn Medicine.Students would list their project preferences, and then would be assigned and grouped accordingly.Anecdotal evidence indicates that our projects were somewhat popular, as more students requested to work on them than could be assigned to the project groups.This may be due to an interest among the students in working on archaeological projects and/or a desire to work with "real customer" projects.The engineering classes assigned a project manager to each project group; these managers were students who had previously taken the class and were interested in gaining management experience.The project manager greatly facilitated the development process by organizing meeting schedules, moderating meetings, serving as a centralized point of communication, and keeping track of all tasks.This obviated the need for the archaeologists to engage with the administrative or group-leadership tasks, freeing up time to focus solely on the functionality of the products as client and user.
For the non-class context, where we worked with individual part-time programmers, we served as both the clients and the project managers.Funding for hiring the students came from a Price Lab for Digital Humanities grant that began in fall 2016.We wrote job advertisements and sent them to the email lists of the Penn Engineering students.After receiving several resumes, we interviewed the programming students.Understanding a programmer's ability based only on an interview conversation is challenging, so we tried to develop lines of questioning that demonstrated general problem-solving skills.We hired two students for the spring 2017 semester.An archaeology graduate student served as the project manager and worked closely with each programming student, meeting weekly to review progress and set priorities.Overall, working with a single programmer as opposed to a group on each particular task made following progress and coordinating work less complex.We continued the development of these apps during the spring 2018 semester with two new hired programming students.In this case, we had met the students through prior classwork, so the hiring process was more straightforward.During this period, we also met with the students weekly.
The online coding collaboration tool GitHub proved to be useful for communications, especially with the individual part-time programmers."Git" is a type of software that allows the management of code and project files, and GitHub is one of the dominant online communities for managing Git repositories of code.GitHub's ubiquity in the programming world meant that the programming students were already very familiar with its use.Because of its popularity, it was beneficial for the archaeology students to learn about this tool in preparation for future collaborations, even if they did not build the code themselves.We have also published the resulting code for all projects on GitHub to provide open access to the code for anyone (see various repositories here: github.com/anatolian).

Impressions
One of our main goals for undertaking these projects was to introduce the archaeology students to the software development process and prepare them for their own digital humanities work.Thus, now we reflect upon the interactions between the engineering and humanities students.We developed our projects as transdisciplinary case studies to give the students opportunities to design and work through transdisciplinary methodologies that they might apply later in their careers; although the immediate participants in the projects were all members of Penn's academic community, the client relationship that we modeled was meant to reflect the way in which groups outside of academia might be involved in research projects (Scholz, Lang, Wiek, Walter, & Stauffacher, 2006).This was a mutual learning process, in which both engineering and humanities students acquired better understandings of the needs and work processes of communities that they might collaborate with in the future by working together on our projects (Lang et al., 2012).By exposing the students to new teamwork strategies and asking them to communicate effectively about goals, specifications, and progress with non-specialists, the projects also helped them develop the skill set of the transdisciplinary researcher (Pohl & Hirsch Hadorn, 2008).
Our collaborative arrangement followed standard industry processes for product design and development: the archaeology students wrote specifications for a digital tool, and the programmers decided how to build the tool to match those specifications.During this process, the engineering students brought questions to the archaeology students, who also periodically reviewed the programming work to guide the course of development.As in non-academic projects, this process was closely collaborative, and was designed to make tool-building as efficient as possible by keeping all participants abreast of goals and progress.
Involving both engineering students as developers and archaeology students as clients provided benefits to both parties: the engineering students researched and utilized different methods of programming while gaining practice in presenting material to non-specialists interested in the outcome of their work, and the archaeology students engaged in forming ideas for apps based on problems within their discipline, while also brainstorming about how these apps could then be employed in a field or research context.Additionally, the archaeology students, by meeting with engineering students, gained expertise in monitoring application development and building strategies for partnering with non-archaeologists.
For example, the archaeology students learned about some of the challenges in building a computer application.One major issue has been designing effective fallback procedures in case of app failure.Although the ultimate goal is to produce a digitally-assisted workflow which fails less frequently than an entirely human process, there are a number of possible points of failure during data gathering and storage.In the case of the precise location tracking app, for example, coordinates may not be properly received from the GNSS module or locally saved records may not be successfully uploaded to the cloud.These problems are particularly worrisome for surveys being conducted in areas that have poor cellular coverage or hostile climates.As a result, a fallback sequence had to be put in place to prevent data from being lost due to app failure.In this case, the fallback for GNSS problems was to revert to the Android device's built-in location tracking, and to make sure to carefully record this fact along with the point data.If there were problems with the data upload, we made sure to preserve a copy of the data on the mobile device.
Whether we collaborated with groups of students in a class project or worked individually with a hired programmer, the process was generally similar.Perhaps the biggest difference was that the classes provided more of a formal context, where evaluation of work was impacted by the grading for the class in addition to the success of the project.For both contexts, we found that communication skills and task management skills were critical to our success.For this, we relied on collaborative online tools, especially GitHub (as mentioned), as well as the periodic team meetings.Here, we will touch in more detail on each of these topics.
As obvious as it sounds, we cannot overemphasize the importance of clearly communicating the requirements of a proposed tool.As non-archaeologists, the final uses of these applications and the environments in which they would be employed were unfamiliar to the programmers.Appropriately, we as clients needed to explain the hurdles to overcome during use.Naturally we needed to convey the challenges faced by a field archaeologist such as unreliable internet and electricity, hot and dusty environments, and the difficulty of carrying equipment through rough terrain.But we also needed to clearly communicate things as basic as how archaeological data is collected and organized on a day-to-day basis in the field.
We found that development proceeded most smoothly when we broke each project into specific, achievable tasks.We recognized that describing a desired application did not provide enough background and guidance for the projects to adequately move forward, and that we needed to offer details on individual components of each app so that the engineering students could organize their development processes.Especially in working with individual programmers who were not collaborating with a team, it was important to communicate what the next steps should be and to assign priority to specific aspects of the application.
Online collaborative tools were key to facilitate the process.We used Microsoft OneDrive to share documents, requirements, and other files.The most important tool for collaborative programming was GitHub.This allowed the engineering students to keep their progress in an organized, accessible, shared space, while also allowing the archaeologists to set up checkpoints and specific tasks, along with adding corrections or identifying problems which could then be reconciled before the next meeting.These were tracked through a built-in ticket and enhancement request system.GitHub provided both a place for archaeologists and programmers to collaborate, as well as a functioning workspace.
Despite the benefits of GitHub, face-to-face meetings were still essential.It was necessary to conduct periodic app walkthroughs and user interface testing, engage in real-time questions and answers, and test apps with real equipment and artifacts.In-person meetings provided structure to the relationship between the groups of students and created a natural deadline by which different parts of the projects were completed and discussed.Personal side conversations provided an opportunity for the students in the two disciplines to understand each other's work, and what their different career trajectories might be.

Conclusions and Future Work
Technological innovation and interdisciplinary collaboration are two pillars of the digital humanities.Our projects strive to equally represent archaeology and engineering in the creation of applications for use in humanities research.In particular, we tried to engage archaeology students directly in the app development process.As digital methods become an increasingly central part of archaeological research, we are motivated by a desire for all students to gain technical skills they can apply across their careers.This may be in traditional academic paths or alternative paths within and without the academy.Roles are increasingly hybridized and archaeologists need to be digitally literate, especially given that organization and analysis of evidence are central to our field.
While other archaeological projects have collaborated with programmers to create custom code, what we try to uniquely highlight with our projects is the opportunity of working with engineering students in the university.Although this may seem to present logistical challenges, our experience indicates that with good communication, projects such as the ones presented here can succeed.Bringing software to completion within a one-semester class may not always be feasible, but with sustained effort on the part of the archaeologists it is possible to continue to improve and test apps across multiple classes and outside of classwork.In our case, we took the multiple apps developed in the first class and by individual programmers, had some of them integrated during the second class, and then continued to have hired programmers work on all the apps in the subsequent semester.One of the websites has been further developed by the Penn Libraries since initial development during the first class.In addition to the advantages of archaeology students' gaining experience with development, we also strongly believe that exposure to humanities research enhances the engineering curriculum.In the future, we hope to find ways to measure the learning outcomes of these interdisciplinary interactions for both archaeology and engineering students.
There is an obvious cost-savings benefit to working with student engineers versus professional contractors.Serving as clients to engineering classes required no financial commitment on our part.The part-time students were hired at standard university-wide rates of $12-15 per hour, substantially less than external engineers.
We highly recommend other archaeologists to emulate our experiments by reaching out to engineering programs at their respective universities.Through experimentation we can increase digital literacy across the discipline, making future projects easier to conceive and execute.As we continue to construct and refine the apps discussed in this article, we will continue to search out partnership opportunities to advance our field and develop new interdisciplinary relationships.Ultimately this will improve our ability to create and share the robust datasets that will help drive forward our research as an Open Science.and Owain West.Finally, we should thank our graduate student colleagues in ancient history for their patient participation in this process: Bryn E. Ford, Jordan Rogers, and Gavin Blasdel.

Figure 1 .
Figure 1.Screen capture of the location tracking app user interface.

Figure 2 .
Figure 2. Screen capture of the peripheral device control app interface for a Bluetooth scale.

Figure 3 .
Figure 3. Screen capture of the object photography app data display.

Figure 4 .
Figure 4. Mapped bibliography landing page with a circle designating the parameters of a geographic search.

Table 1 .
The collaborative projects between engineers and archaeologists discussed in this article.