Building an Archaeology Data Recording App

Today, I’m working at the Western Washington University archaeology lab, but since I wrote about that for Day of Digital Humanities a few months ago, I thought instead I’d write about the work I do with my company where I create software and tutorials for archaeologists.

9-12pm Worked through a Database Tutorial

This morning I finished up working through the tutorial for FileMaker Pro 12, a database management system (DBMS). I’ve heard great things about Filemaker from other archaeologists who have used it to create custom databases for recording archaeological sites. Compared to some other DBMS, Filemaker’s interface is very simple, and the program has some nice features, like tight integration and easy portability for iOS devices (e.g. iPhones, iPods, iPads) through the FileMaker Go app. This past year, I attended two conferences where several archaeologists demonstrated the Filemaker databases they built for academic projects. In particular, the Center for Digital Archaeology built their impressive Codifi app using FileMaker. Although I’ve yet to hear of any CRM companies who use Filemaker, I think it should work as a short term solution for a friend of mine to use this summer on field projects. In fact, I built a simple relational database for archaeological survey this morning based on the Intermountain Antiquities Computer System (IMACS) and Filemaker made it pretty simple for me to transfer the database to an iPad.

A Quick and Dirty Filemaker Form for iPad

Although Filemaker seems great so far, I’m hesitant to rely on the whims of two different companies, Filemaker and Apple, to ensure that I will be able to access my data when I need it. I interned briefly at Digital Antiquity (the organization that runs the Digital Archaeological Record data repository) and know that archaeologists who trusted their data to propriety database systems regretted it later when the database companies went under, leaving archaeologists with datasets that were difficult to access on new computers that couldn’t run the older database software. If the archaeologists were cautious, they might have translated their databases into less flexible but more stable preservation file formats, like plain-text comma separated value (CSV) files, but in many cases that didn’t happen.  Because of that experience, I always try to ask myself “how can I get data back out of here?” whenever I use a new piece of software.

For the past few months, I’ve also been building a custom archaeology data recording application for mobile devices using the Adobe Cordova/Phonegap framework.

Picture of an archaeology data recording application.

Screens from our data recording application.

The Phonegap framework allows me to use web languages like HTML, CSS, and javascript to create mobile applications that will run on multiple platforms, including iOS, Android, Windows Phone, Blackberry, and webOS. I’m already familiar with these coding languages from building websites and I like the idea of being as platform agnostic as possible. As an added plus, if my partner and I decide to make the application open-source, other archaeologists will be able to edit and customize the code more easily than if we wrote the app in C or Java. Phonegap and HTML5 do have their limitations though, so in case we run into issues that slow our app down too much to make it useful, we’re also looking into porting the app to native code. For now though, Phonegap allows us to quickly prototype the application using languages we’re familiar with.

1-3pm Videoconference with Chris at DigTech  

Two archaeologists communicating over Skype

I’m working on the PhoneGap application with Chris Webster of DigTech, LLC. Chris is a long-time shovelbum, project manager, and podcaster who recently started his own cultural resource management (CRM) archaeology company. Chris wants to do as much of his site recording digitally as possible in order to increase efficiency and data accuracy, spend less of his clients’ money, and free up his archaeologists’ time to do more research, analysis, and publication rather than data-entry. Chris has accomplished a lot of this by using various off-the-shelf applications like Tapforms and MementoDatabase, but decided that none of them were doing everything he wanted or needed to do for CRM archaeology.

Chris and I meet weekly to discuss projects and to collaborate on the application. Chris primarily works on the interface design: making sure that the app is useful in field situations, with large enough buttons, text, and easy access to vital data. I primarily handle the coding and database design, but Chris and I have also been challenging each other to learn more about computer programming as we go. Simply designing a database to hold archaeological data has forced us to carefully consider and try to anticipate the different needs an archaeologist might have for a database in the field: if sites can contain features and artifacts, but features can also contain artifacts, how do you map that relationship? How many controlled terms for material types do you need to offer to standardize and streamline recording without limiting an archaeologist’s ability to add in an unexpected material type? Others have put much more thought into this area, but the end goal is to design databases that are specific enough to increase efficiency and accuracy while being general enough to compare data across sites, archaeologists, and regions. For Chris and I though, it’s been useful mental exercise to think about these kinds of problems as we program.

Recently the app has started to resemble something that would be useful out in the field, but we still have a lot of work to do. Some of the field situations we need to adapt our app to handle are to expand beyond simple survey to being able to quickly and efficiently record rock art. We have a database up and working in the app and have tested recording coordinates using the mobile device’s internal GPS (it’s nowhere near submeter accuracy, but it’s still handy), but we’d also like to add in some other features, like simple mapping, storing photographs, and making the data exporting work more easily.

3-4pm Wrote an email to a programmer to collect bids on fleshing out the application.

Because neither Chris nor I are professional programmers, we’re contacting several people who are to see what they might charge to help us add features. We’re not sure yet whether we’ll fund that ourselves, release a beta version to fund further development, or seek funding through a crowdfunding website like Kickstarter. If you’re an experienced programmer, we’d love to talk to you. You can contact us through our websites or at russell[at] or chriswebster[at]

4-6pm Geeked out with other archaeologists over a new toy

A few other archaeologists and I have been eagerly awaiting a low-cost tablet with both an internal GPS and a >3mp camera that we can use for field recording. Today, Google announced the new version of their Nexus 7 tablet which met our requirements. I’ve been waiting awhile for that right combination of specs, so I bit the bullet and bought one. I’m really excited the Nexus 7 runs on android 4.3, which means I can finally run the FAIMS application on a real device; up until now I’ve had to emulate a Nexus 7 on my laptop, which is not ideal. From their website: “The Federated Archaeological Information Management System (FAIMS) Project is funded by the National eResearch Collaboration Tools and Resources (NeCTAR) program[…] an Australian Government program to build new infrastructure for Australian researchers.” The researchers at the University of New South Wales and elsewhere have specifically designed for CRM data collection in Australia. I’ve been interested in the FAIMS project since speaking with Dr. Sobotkova at the 2012 SAA meeting in Sacramento and was very impressed when Dr. Crook showed me the progress they made when I saw FAIMS’s booth at the 2013 SAA meeting in Honolulu. The FAIMS project has open-sourced their app, which I love, and a friend and I want to customize the app for an excavation project here in the United States. Now that I will have a new android device, I can finally move forward with playing with the app and (hopefully) pay things back by contributing some code or tutorials back to the project.

If you couldn’t tell already, I’m generally pretty hopeful that technologies like databases, mobile devices, internet blogs, and social networks can help archaeologists record, analyze, and publish about archaeological sites more quickly, sustainability, and openly.  I’m excited about all the other posts I’ve seen on Day of Archaeology today that involved everyone from academic archaeologists to CRM archaeologists, community members, students, authors, and more. I hope this post has been interesting and helped add to the diversity of the voices on this blog. I’m looking forward to reading more posts and can’t wait until Day of Archaeology comes back around next year.



6 thoughts on “Building an Archaeology Data Recording App

  1. Hey Russell –

    great post! I wanted to add some things to the mix, since I’ve been relatively silent on why, given projects we’ve done like Mukurtu CMS (drupal, pure ‘community dev’ open source) and my work back in the day on Open Context with AAI, we’d roll with Filemaker.

    At CoDA, we fully embrace open data. Codifi is an linked open data (LOD) model based on the CIDOC-CRM ISO standard that aims to radically simplify semantic relations for archaeology. It’s a lofty, but worthy goal. We wrote a couple papers about it,, back in the day. The model is graph based, you see it in FAIMS, in ARCHES and in Open Context. We’re all on the same page, I think we’re looking at handwriting flourishes at this point, and this is good news for archaeology!

    So, what does Filemaker have to do with open data? It turns out that Filemaker is remarkably good at dealing with text, and at transforming text. We use Filemaker, and the 1000’s of developers worldwide who support it, as the engine to power the field experience of creating archaeological data. But the results, we save as XML, or CSV, or SQL, whatever. In other words, the data are separate from the engine. Put differently, we adhere to a pretty radical concept of data separation, where data, media, code are all handled, and fully documented, separately. This assures longevity beyond Filemaker, but also beyond the coders hipster flavor of the week. Long live RSS….

    Filemaker databases, like SQL databases, are proprietary. So are Nikon, Leica, Pentax and Canon RAW files. And so are MySQL databases that are undocumented. Whether intentionally unreadable or not, it’s up to us to make sure the data we produce is in open formats. Adobe created DNG, and Filemaker outputs HTML and XML.

    Filemaker provides something that few other applications do – profound capabilities for non-technical people to be empowered in their own development. With little training, archaeologists who are not programmers can create layouts, charts, run reports, truly interact with their content. It’s really amazing, liberating. Since at least 2000, we’ve held the belief that you shouldn’t need to be a computer specialist to do great things with technology (

    Our litmus test is whether the systems and content we create can outlive us, and will be intelligible to the ‘next generation’ of people interested in archaeology. Filemaker is a tool, like a pen is a tool. I’d like to see us create durable content, it doesn’t matter so much what the tool is so long as the result is made to last. I’m still not convinced that archaeologists should need to know how to pull code from github in order to get their jobs done (as cool as that is).

    Codifi will ultimately be open source. I’ve envisioned a raft of ways to implement our data model, html 5 and javascript being the flavor of the week, but tastes change. Today it’s HTML 5, tomorrow it’s H.265, in 10 years… who can imagine? What matters now is to produce the best ‘knowledge’ we can, and to steward that knowledge through the sea changes of technological advances… and regressions.

    I’d love to see us all focus on the prize of data, written in well documented, open formats [open data]. I think this is something we can all get our heads around and get excited about, no matter how we get there.

    I’m super excited to see what you come up with, especially with FAIMS, as I’m a huge fan of the project. Let’s stay in touch! And thanks for the shout-out about Codifi. We’re doing our best to make it awesome and it’s exciting times!



  2. Yay! Mentions of FAIMS!

    I’d love to discuss module development with you. We just completed a module for a survey in a South American country and we’re getting ready to go gold.

  3. Brian, I’d love to. I’m very excited about finally getting to play around with FAIMS. I’ll be in touch.

    Michael, thanks for your post! I replied, but it showed up as a separate comment, rather than a proper reply. See below for the full reply.

  4. Michael,

    Thanks for the response! I’m glad you cleared up some of CoDA’s reasoning behind choosing FileMaker. Filemaker really does have a great and easily understandable UI. It’s honestly a breath of fresh air after using other DBMS like Access. Certainly laying out forms is much easier. I am building my practice around the same idea that technology should conform to archaeologists’ needs, not the other way around.

    As you said, we are on the same page that there are many ways for archaeologists to collect data, but we should all share the end goal that our systems not only improve archaeology now, but that the data collected and content created outlive both the specific technologies and people used to gather them.

    I very much enjoyed the CoDA presentations and meeting some of your staff during the DDIG meeting at the last SAAs. I have followed CoDA for the past few years and loved seeing all the different projects you’re working on. I hope I can make it down to Berkeley to attend a workshop someday and would love to talk more about both Codifi and Mukurtu; both are very, very cool platforms for collecting and sharing cultural information.


Comments are closed.