Post navigation

On Tuesday, I discussed our use of an archaeological iPad app in fieldwork in Cyprus. Today I will discuss our use of iPads in the field more generally.

First, Glare. The major problem we encountered was the incredible glare from the sun. If we had thought ahead, we could have remedied this from the start by purchasing an anti-glare screen shield. But alas, we did not, and we could only view screens with the brightness cranked all the way up. Even that required squinting in the intense Mediterranean sun.

My solution initially with my own iPad was to sit in one of the rental cars and take notes in the shade, but that was not practical for the students recording notes next to their trenches. Lesson learned on this one.

Dust. This was not the problem we thought it might be. We brought along protective jackets to keep the dust out of the iPads designed for field use. We encouraged students to keep iPads in their jackets at most times, and if possible, all times. Some students simply entered the data through these covers.

Others took the covers off when they were using them.

Battery. Given the intensity of the sun and the need to crank up brightness to see the screens, we expected battery life would be a problem especially on those days when we were in the field from 7 AM to 6 PM. Not once, however, did we totally exhaust an iPad battery. Setting the Auto-Lock to 5 minutes helped keep the iPad batteries charged and lasting longer.

Camera. We sometimes used the iPads for taking photographs. We instructed students to take photos of the bottom of every Stratigraphic Unit upon completion, but some trenches did this more consistently than others. These photos would act as a backup to the digital photos we took with point-and-shoot cameras. For one trench, the iPad’s camera unfortunately failed to function at all.

The camera was not linked to the PKapp, but Sam Fee tells me that it may be possible for future version of the app to do so. That would be valuable, especially if the resolution of the iPad camera improves. The quality of the photos (5 megapixels) was not nearly as good as the point-and-shoot hand-held cameras we were using to record photographs.

Compare the two following contexts. The first photo in each comparison was shot with the iPad, the second with a 10 megapixel camera.

And SU 5309

The 10 megapixel provides enough extra detail to make it a significant improvement on the iPad. We could not use the iPad camera for serious fieldwork at its current resolution.

On the other hand, the iPad camera was great for capturing and modifying photos of people in action, and was especially useful for sharing via social media sites like Facebook

Recording. In Tuesday’s post, we discussed the use of PKapp for recording stratigraphic contexts. As the area director, I also kept an “Area Notebook” to describe my impressions of the “big picture” across the site. This notebook acted as a running log of the simultaneous work of all four trenches. In the past, we recorded these general notes in an old school field notebook. My problem was always writing legibly in such small notebooks — I have such terrible handwriting.

This year I recorded comparable notes using the iPad. Besides glare, my main problem with using the iPad for recording was simply getting used to the keyboard. Initially, I used a table with an external keyboard, but this required establishing a bluetooth connection every time I wanted to use it, and the setup was no good for roaming from trench to trench.

Eventually I got used to the internal screen keyboard, and I could use it with one hand, or could type with both hands by the end of our season.

At the beginning of the season, I used the simple Notes app that comes with the iPad, which I would email to myself and append to a master notebook file in MS Word (on my laptop). By the end of the season, though, I realized how much potential there was for using more sophisticated apps. How I would have liked to use an app like Dragon Dictation for turning voice into text, but this required an internet connection, and our iPads were not 3G capable.

By the last week, I was experimenting with Evernote and wish I had used this from the beginning since it allowed me to make audio recordings and include photos inside each log. The next time I teach this course, in fact, I will have students take their personal iPads into the field and use an app like Evernote to record a running notebook on what they are finding. These will complement the master field notebook for each trench.

In the end, our experience with iPads in the field was very positive. We used the devices in a sophisticated way to collect data via an app designed for the project (PKapp). And we used the devices in very simple ways to record notes and take photos. What strikes me about the use of the iPad in archaeological fieldwork is its potential. Given this explosion of apps, I can only imagine that mobile technology will be one of the main ways that archaeologists complete their work.

In my final post tomorrow, I will conclude the use of iPads in the Cyprus class.

As Dr. Fee has now completed his series of posts on the technical aspects of designing and implementing “PKapp,” I want to discuss here how we actually used PKapp in the field. I will follow with a couple of other posts on our use of the iPads more generally.

Messiah College gave us 13 total iPads for use with our course. Nine were assigned to students, who used them for a range of purposes, some of which I’ve already discussed (here and here). Four of the iPads were assigned to trench supervisors responsible for our four different “excavation units”. These were iPads strictly used for the field, and they contained a minimal set of apps: Find iPhone in case the device went missing; Dropbox for transferring files, photos, etc..; a PDF reader; “Files” and “FileApp Pro” for storing PDFs and documents related to our work on Cyprus (see below), and most importantly, “PKapp” the PKAP app designed by Sam Fee and labeled according to the Excavation Unit number (in the case below “EU 15”). We initially considered using all 13 iPads in the field, but this seemed too involved, and students generally did not bring their own iPad into the field.

In archaeological fieldwork, most especially excavation, recording is among the most important responsibilities of the fieldworker. As excavation destroys the contexts that it removes, the finds (artifacts) and the notes are the only material for reconstructing the occupations being investigated. The goal always is to record detail sufficient for understanding finds in their natural and cultural contexts (strata).

You can understand, then, both our excitement and hesitation about using these iPads in the field. On the one hand, iPads could offer new ways to improve our note-taking through, for example, devices like the camera and video, and apps for recording audio and visual notes. On the other hand, we were terrified at the many ways we might lose our information and electronic data. We did not want to leave Cyprus with nothing to show for our work. Our solution was to treat the PKAP 2012 season as an experimental year for using iPads in the field. Initially, in our modified excavation manual, we put it as follows:

We will record the excavation process according to the basic unit of the stratum (SU) and describe as we excavate. We will collect data in two ways in 2012: 1) A volunteer will fill out a standardized SU form for each new SU (see below) and 2) the trench supervisor will collect the same data via an iPad designated for the SU. The iPad will contain the master version of the data, the paper copy the backup. It is important for the supervisor to bring both SU forms and the trench iPad into the field each day, and the supervisor should charge the iPad each night.

After some discussion with co-director, Bill Caraher, however, we changed the language of this section so that the paper version would be the master and the iPad the backup. The trench supervisor or his proxy would record the master set of notes in paper version, while the students would record the backup using the PKapp on the iPad. In the end, for reasons we will discuss below, we were very glad we did it this way.

In Excavation Unit 15 (below), trench supervisor Aaron Barth keeps the master paper notebook in the red clipboard while David Crout records with the iPad.

In Excavation Unit 14, trench supervisor and field director Brandon Olson advises students Megan Piette and Jimmie Nelson on how to fill out forms. Megan uses the iPad while Jimmie records the same information with the paper.

In both cases, our paper forms and iPad PKapp recorded nearly identical information on each “Stratigraphic Unit,” the basic spatial for recording stratigraphic contexts.

The second page simply contains identifying fields (in case the page becomes separated from the first) and blank lines for description and interpretation. The recorder can use as many of these description pages as necessary to record the context.

As Sam Fee has described it, the PKapp on the iPad was designed to duplicate the same information collected on paper form. So, in the image below, one can see some parallels with the image of the paper form above.

Like any other app requiring text, selecting inside any field brought up the keyboard for keying the data.

You will notice in the description field above “See hard copy.” In this instance, this SU description marks a complete duplicate of the hard copy—and the trench supervisor (Crowley) recorded it in this way because in this small trench, he was responsible for both the digital and paper form. Generally, though, we did not attempt to duplicate the “Description” field because we felt that this field allowed us to record two distinct interpretations of each stratigraphic unit. And each interpretation could inform the other.

A major advantage of the digital version is that it forced the recorder to enter data in standardized ways and did not allow (as the paper version did) for inconsistency in entering certain fields. For example, the fields related to soils required the user choose one of several options from a list rather than try to remember what the options were. This ensured a more normalized data set.

Clicking the “Load SU Data” allowed the user to revisit data from previous SUs. This was extremely useful in comparing SUs in the field. However, the continual improvement of the PKapp during the field season meant that a couple of new versions were issued after fieldwork was already underway. Each new version required wiping the iPad of its previous data (after backing up the data). We were not, consequently, able to pull up SUs of previous versions. Note that the data for EU 14 below starts with SU 5107, but it does not contain 5101-5106 (we did have these in paper form). Perhaps a future version of PKapp could reimport data back into the PKapp.

We encouraged trench supervisors to back up their iPad frequently whenever a connection was available. Our simple wireless iPads required a wireless connection at the hotel, and data was backed up less frequently than we would have liked. In one case, I could not get a good wireless connection to backup the data. Having iPads with 3G would have allowed us to do this from the field at the end of each day.

Backing up data was a two-step process. Touch the “Export these data” button, which converts all the data into CSV format. Then touch the “Email the data” button.

…which resulted in this confirmation screen.

Only in one case did this process result in data loss, but the details of this loss are too cloudy to be sure that the app was to blame.

We also lost data once or twice at a different stage of the data recording process, when a student forgot to hit the “Record the Data” button while collecting data on the SU. That was unfortunate but not unexpected. All the same, we were glad that our iPad was the backup in this first season using them and that we had the paper version to go along with them.

Besides the PKapp, we also used the iPads in the field for several other purposes. We used the devices to take photographs, to circulate files (via Dropbox), and to load files. It was extremely useful, for example, to have the SU Form Guide for filling out the SU forms at the touch of a button. Same with the instructions for describing features and soils. In the past, we have had to drag out the entire paper version of the field manual, which is a hassle to look through on an afternoon when the coastal winds are powerful.

In the end, collecting data via the PKapp was easy and worked remarkably well. We have some hiccups to work out in regard to data preservation, but our use this season did not result in major losses.

In Thursday’s post, I’ll continue this series with a discussion of the practical dimensions of using iPads in the field.

We learned a lot from developing PKapp. First, it forced us to think again about the data we were collecting, and how we might validate that data before adding it to the database. But aside from reviewing our methodology and re-thinking our data analysis needs, we also learned a number of specific things about implementing mobile apps for data collection in the field. This post will focus on three technology issues that seem to relate toward such work:

Ease of Development

Web App vs. Native App

Data Import/Export

In their simplest forms, mobile apps aren’t very hard to create – you can build one based on an RSS feed in minutes. But we were collecting, storing, and accessing data specific to PKAP, and there weren’t really any tools out there that would do that job for us. In the end, we were able to use libraries to generate some of the general formatting of the app; but we still had to write a database in javascript manually, and that’s a bit of programming work. We also had to customize a lot of the button actions, and that was also hard work. Overall, the process was quite time-consuming. It might have been easier to implement pre-existing apps to do this work. But had we done so, we would have needed to work with multiple apps and we could not have customized them nearly enough to do exactly what we wanted. So in the end, writing our own app was more difficult; but we had one app that did exactly what we wanted, and it did that precisely the way we wanted it to.

Native Apps are written for iOS or Android (primarily). Web Apps are based on the HTML5 Standard. There are advantages and disadvantages to each approach, and deciding which route to take would depend upon your project. In the end, we decided on a Web App approach for one primary feature: I could update the app at any time and post it for the team to install in Cyprus almost instantaneously. This made life much easier as we were testing the app in the field, since we were able to fix bugs as they appeared, or modify features based upon actual use in the field. One of the problems we encountered however (since we were using iPads) was that we could not access the local file system of the device to write/retrieve files. In the end, this created a hassle for us when exporting the data.

Since Apple hasn’t implemented the fileSystem API from the HTML5 spec into mobile Safari, we couldn’t write local files in javascript (other browsers have begun implementing this, but support is still sketchy). Normally, this wouldn’t be a very big deal – you would just write the data to a server. But that assumes constant connectivity, and when working in the field in Cyprus, that’s not an assumption we wanted to make. So we developed a mechanism to export the data in CSV format to the app itself. Then, when connected later, the app could email the data. That data would then need to be copied from email and imported manually to the primary database. Given more time, I could likely have written a component to write the data to a Dropbox account; but again, we were trying to avoid having to rely on an Internet connection. The email solution allowed us to upload the data infrequently, whenever a connection was present. At all other times, the data was persistent and resided in the SQL database we’d written into the app. Still, it is a less than perfect approach, and ripe for revision when we put the app back into use in the future.

So, in the end, what would we do differently? What features will we implement for the next time around? Well, I think that the Web App approach is a real win. Being able to make immediate updates to the app in the case of a bug or problem, really helps. As HTML5 matures and the fileSystem API get fully implemented, that will resolve the data export problem for us. A DropBox solution might be useful as well. As for features, we’d like to add camera functionality to the app, so we can easily attach images to each SU. Voice dictation might make large text entries less of a chore also. Implementing the camera and voice recognition protocols will force us to take the app native, although if we can do that and avoid the app approval process through the Apple and Android Stores, it could be worth it.

In the end, I don’t see why we wouldn’t input field data electronically. In terms of efficiency, it’s a considerable improvement since it removes steps in the process and, with the right programming, can reduce the possibility of user input errors. We still have way to go toward developing software tools that make this easy; but as the technology continues to mature, data collection apps should become increasingly accessible to any researcher.

While developing PKapp we ran into a number of technical difficulties. These were essentially the reality of implementing the technologies we’d decided upon; it wasn’t so much the specific features we were trying to implement, as it was the immaturity of the toolset we were using. I’ll break this down more in a bit, but first, let’s get clear on the software tools we used to write PKapp.

The App is essentially created using HTML5. Now, it’s very important t understand what HTML5 actually is: a collection of HTML, CSS, and Javascript. In essence, the HTML5 spec is this collection of pre-existing scripting languages along with a much more robust support for web forms. In many ways, this makes it perfect for what we wanted to do, since we wanted to develop a web app that we could update on the fly in the States while folks were working in the field in Cyprus. So, we ended up with a web app using HTML5 with a good amount of form cutomization along with a ton of custom javascript.

Specifically, we implemented the jQuery Mobile javascript libraries which handled a lot of the look-and-feel of the app. In addition, we customized a good bit of the form mark-up and added a number of attributes to help us validate the data and eliminate a number of potential user errors in the input of data. For the most part, this was all rather straight-forward and creating this type of app (in retrospect) is very doable. We ended up with two real problems though during our development:

1. The Database – at the risk of getting too technical, we implemented a WebSQL database locally on the device. This requires a webkit browser. It was a real challenge to decide which database structure to implement since WebSQL has already been deprecated from the HTML5 spec (for petulant reasons, IMHO). Anyway, the alternatives are localStorage and IndexedDB. Unfortunately IndexedDB really isn’t fully implemented in webkit browsers, and we were already using localStorage to keep track of any data already in the form (remember, one of our critical design parameters was that we wanted to make sure we never lost any data). So, we went ahead with a WebSQL implementation which basically means we wrote a database in javascript. We made the unique identifier the SU, so there is a new row created int he database every time a new SU is saved.

We had some struggles in writing this database. Actually saving the data was no big difficulty; but reading it, re-importing it (with the Load SU button) and exporting it to CSV format all required custom scripting and creating arrays in Javascript. Once you know how to do it, it’s not too horrible – but this does require some real programming to a certain extent.

2. Exporting the Data – this was the other big problem for PKapp. And the challenge is really because Apple hasn’t implemented the fileSystem API for HTML5. That’s probably because they want to keep control over what files can be created; but in essence, it means that we can’t write files with javascript. This creates some big hurdles in exporting the data, so we circumvented this by exporting the data to the screen then using a PHP script to send the data via email. Not the sexiest solution, but it does get the job done.

If we were willing to write a native app, we could avoid this challenge and write a file locally. We could then even set it up for writing the document to Dropbox. This will likely be the final solution, but we wanted to test the app repeatedly during the field season and we wanted the ability to update the app overnight and that meant we couldn’t go native.

So in the end, we learned quite a bit in the development of this custom app. I’m taking those lessons and creating an open-source framework for developing custom filed data collection apps, so that others can build customized apps for their projects. I’ll write more about those lessons in my next (and last) installment.

Designing the interface for PKapp was fairly easy – essentially we were just re-creating the paper form for collecting data. But we also had the opportunity to validate some of the data at the entry point. HTML5 adds some nice features for implementing forms, so we took advantage of those. Essentially, in most places the user can only enter in the specific type of information that actually fits the way the data is tracked in the database. So, for instance, the EU numbers are 2 digits – you cannot enter more than that. The same holds true for SU numbers, elevations, or any text entry area. For other types of content, the entry options are also limited. This is most easily seen in the select menus. Basically, by making only specific options selectable by the user, it guarantees that the data is formatted in a way that will import directly and correctly into the database.

Another nice feature is being able to bring up the correct keyboard for data entry. I hate apps that bring up a QWERTY keyboard when I’m being asked to enter numeric data. Is it a big deal to just switch the keyboard? Maybe not if you are doing it just once, but if you look at PKapp, we’d be doing it a lot. Its very easy to specify a numeric keypad when needed, so we made sure to do that.

Otherwise, there are basically only four buttons that lie outside the basic form paradigm. Remember that the stratigraphic Unit (SU) is the unique identifier for our fieldwork at PKAP.

PKapp Main Buttons

The first button loads any previously entered SU data. We actually didn’t have this in the early version of the project until I realized that I couldn’t see any of the data I’d entered on the iPad. Oops! (It was actually there in the local database – you just couldn’t see it.) So, the Load SU Data button lets you re-load any SU data you already put in the device.

The Clear Data / Begin New SU button does just what it says – wipes all data that is currently visible in the form. The data isn’t actually deleted, it’s just removed from the form so the user can enter new data. The previous data can always be re-loaded using the Load SU Data.

The Record the Data Button is pretty simple: it writes the data to the local SQL database. It’s essentially a glorified Submit button that you would find on any web form – we’ve just written some specific scripts to have it perform some additional functions. (I’ll explain more about this in the technical details post.)

The last real interface elements are for exporting the data. In the Data Export section at the bottom of the form there are two buttons: one exports the data form the SQL database into CSV format, and the other emails those data directly to an email address we’ve set up just for this purpose.

Data Export

Why did we email the data instead of saving a file? Well, that’s a bit more complicated, but I’ll write about that in my next post…

Our initial thoughts for PKapp were to wed archaeological methodology with technological innovation. Bill, Scott, David and I had all gone to grad school together at Ohio State – so we had some shared background to draw upon. It seemed most appropriate to us, to take what had been the traditional paper and pencil approach to data collection in the field, and turn it into an electronic process. The goal was to achieve improved efficiency and speed with our data collection, which would free up time for education and analysis.

So, PKapp was initially envisioned as an electronic data collection form. And in many ways, the timing was good – HTML5 had become a relatively stable standard in the past year. Technically, we would be able to do things more easily and more reliably that we would have been able to with earlier versions of those technologies. Also, we’d be able to easily install and operate the software on tablet computers – and we had iPads.

We had a number of parameters we wanted to address while developing the app:

1) It was imperative that we not lose data.
2) Entering data needed to be an easy process for students.
3) The app needed to provide some limited data validation.
4) PKapp had to run locally on the device (without Internet access).
5) The app had to export the data for import into the master database.
6) Updates to the app needed to be easy and quick.
7) We wanted the software to be platform agnostic.

In the end, we were successful in achieving all these goals. I’d say we have a very good initial version of the software. Of course, we have ideas for ways in which we’d like to expand PKapp’s features; and PKapp 2.0 will likely include photo capture and possibly voice dictation. These features will likely force us to revisit one of the above parameters, but we’ll see where we are after the 2012 summer field season wraps up.

One of our first orientation activities for students was a self-guided tour of Larnaka, the city where we are living for a month this summer. A city of about 70,000, its coastal orientation is oriented to tourist circuits and vacationers: long promenade along a line of palm trees and sandy beach line with overpriced hotels and restaurants.

Over the years, we’ve sent students on a photo scavenger hunt on their first full day on the island. We typically give students a paper map of Larnaka. Students walk around and collect photos of places both historically significant and practically useful (e.g., the post office). Students become familiar immediately with the coastal area of the city, see parts of the older city, learn practical information, and get some photos of the city.

Here’s a snippet of the exercise:

Now, requiring that students use iPads for this small group exercise, on the one hand, does not really improve on the paper forms. Carrying around a 2 pound device is more burdensome than paper. But the iPads enhanced the experience with the potential for photographs and the maps.

If we had devices with 3G, we could have used the Map app consistently, but our wi-fi devices restricted internet access to the lobby of the hotel. Still, students did find a way around the problem of no connection: load the map of Larnaka at the appropriate resolution in the hotel lobby (when Wifi was available) and track location by the blue dot. There was, of course, no way of resizing the map during the tour without internet access. Walking around with an iPad makes one conspicuous, but it is much less so than opening up a huge tourist map to pinpoint one’s location.

Students took photographs with their own cameras, but could easily have taken them with the iPads. When we toured other sites on the island, in fact, I noticed students using the iPads for this purpose. In both the case of Tim at the Kolossi castle and Kaylee at the church of Ayios Ioannis Lambadistis (below), the iPads were a nice substitute for dead camera batteries.

We also used iPads in self-directed exercises in the museums. I transferred paper versions of the exercises into Dropbox. Students added the documents to “favorites” (so that they could access it without wifi), and then copied and answered the questions in the Notes app.

Below, students in the back courtyard of the Larnaka District Archaeological Museum.

Besides the map and photograph potential, the iPad improved the experience in one other way. When we ran guided historical tours of the city of Larnaka / Kition and the ancient site of Kourion, we made reference to a number of plans and maps of the sites to show how the topography had changed. We could have passed around paper maps and plans as we have done in the past, but there were multiple documents to keep track of. It was actually easier to transfer multiple PDFs of maps and plans and have students look at them through the Files app. This feature does have the potential to enhance our tours and presumably student learning. I could imagine, for example, a self-guided tour of Larnaka through a set of questions (as above) and these digital plans and maps.

Map of 19th century Larnaka in Nikolaou’s The Historical Topography of Kition

The downside to using iPads on tours was carrying around the 2 pounds in the heat of the day, the glare from the sun, and students being frequently distracted from the iPads by Cypriot lizards!

I think using these devices for tours has great potential for enhancing knowledge of the history of sites, especially if we can adopt apps and structure exercises that make use of the best features of the iPads.