Switching to Tablets
I was in graduate school when I got the first iPad about 6 years ago. I didn't really have any knowledge about what apps to use for what tasks - primarily because there wasn't many available and no one really knew what to do with them anyway. My first thought, after working in the southeast for a number of years and dealing with soggy, muddy, paperwork was to use it for archaeology.
In one of my classes we were doing a shallow geophysical study of a portion of the Athens Cemetery on the campus of the University of Georgia. There were a lot of basic data points that needed to be managed with the various methods we were using. I set up a simple spreadsheet in the Apple Numbers app which I tied to an entry form. It was pretty slick. The spreadsheet didn't really do much except record and store data. I didn't know it, but, right out of the gate I was using an app exactly how it should be used. What I mean is, the entry form function of Numbers is only available on the iPad app and not the desktop app. So, it's a truly mobile feature of that particular app.
Advanced Data Entry
Shortly after that, I discovered TapForms. This app allowed me to do slightly more complex activities. I created drop down menus for common tasks, auto-filled text in boxes that never really changed, and duplicated records to increase efficiency. This was a great step forward, but at the same time, was a huge step backwards. Well, maybe not backwards but I definitely wasn't moving. More on this later.
Intense Field Trials
Last year I had a chance to send my iPads into the field on a couple of massive field surveys in California. There were certainly issues but we overcame them. For the ones we couldn't overcome we adapted and modified our methods. Remember that point - we modified our methods. This doesn't mean that the archaeology suffered or that we chose to change what we recorded. We simply changed how we recorded in order to fit the application.
One common and frustrating issue we had was in the export of the data. Actually, the basic export of a CSV file wasn't that bad. Photos sucked because the name of the photo was a hexadecimal UUID that was impossible to read. Where the workflow suffered was converting from the CSV file to a Word document. It worked most of the time but there were problems. We worked it out and still had 85% time and cost savings over the course of the project.
Now, I've recorded many sites on a tablet and I've done it in a number of ways. I hear of other companies adding words to Word documents live (no, that can't be right - except that it is) and still others entering words into fillable PDF documents (dear GOD make it stop). I say “words” because the result IS NOT DATA. Likewise, Word documents ARE NOT DATA. But why should you care?
We collect a lot of data in the field. At the end of the report, those data are locked in useless Word documents and PDF files. It's rare that you'll get a copy of the raw data tables with a report and nearly impossible to see those data with a site record. Let's change that. But first, a quick look back.
