Archives For author

Archaeological notebooks are sloppy. They just are. Take elevations, for instance. You need to use the level or total station when it is ready not when you are ready. This makes for some creative record keeping to store the elevations: the corner of your SU sheet, inside cover of your notebook, your hand, whatever is nearby. The data will often get transferred to its proper place later. This happens with a surprising amount of archaeological data. Ideas can creep up on you at any time: while walking home, just before you fall asleep, while having dinner with your trenchmates. These thoughts can get recorded in a bunch of odd places and sometimes they lie forgotten there, with no place to call home.

Most of the trench supervisors that I know compensate for this by spending a large amount of outside-the-trench-time working on their notebooks and forms. They have to gather these pieces of odd information and put them into the database, a drawing, or in a place in their notebook where they will have a context and can be useful for someone else later on.

But where to store these odd snippets until then? My best suggestion is to use a task manager on the iPads. There are hundreds of them to choose from. I am an early adopter of Things and I like some aspects of the program but lately I have been trying to get people to adopt some of the free software: Sorted, Wunderlist, or even Epic Win. You don’t have to use all of the features of any of these programs, but simply using it as a list of action items that can be checked off when completed can save an enormous amount of time when you have some time to focus and get some things done.

I have a hard time getting people to adopt to-do lists. I use them extensively, as does Steven Ellis, our director. But the trench supervisors are hesitant. I attribute this to the graduate student lifestyle. Grad students are notoriously bad at time management and almost all trench supervisors on excavations are grad students. So, in addition to any other changes we make to this year’s workflow, I am going to push for the adoption of any task manager for everyone on the project. I hope to wipe the task manager from the list of most unused features.

I have uploaded the latest version of the PARP:PS database. The major difference between this one and previous versions is the syncing. I have syncing working on the following tables: AuditTrail, Trenches, SU, Finds, Finds Attributes, Media, MediaLink, Ceramics, QuantifiedPottery, ReportPhases, SoilSamples, Measurements, and SUCompType (which I would like to get rid of but not right now).

Most of the details involving the syncing mechanism are described in an earlier post. In summary: the parent database is the one that lives on the ‘server’ computer. It is the master database. While it is opened, multiple other computers can connect to it from our limited wi-fi network and add/edit records. The parent database is then closed and copied onto each of the iPads (or other computers that are working outside of our network). Those databases are renamed PS_11_child. The child databases are then edited, copied back to the main laptop, and the scripts are run from the Parent database. Currently, I run the script 1_1 Import Audit Trail from the Scripts->Sync menu. That starts the ball rolling and the last step of each scripts is to run the next script. You can disconnect that process by removing that last script step from each section. The scripts also provide some feedback concerning the number of records that are being updated with each step.

The scripts themselves are written in pieces to make it easier to edit them. You might find that you have to do this if you change the name of the parent database. Script steps x_2 and x_3 import data from one table in the parent database to another table in the database. Those steps will have to be edited if you change the file name. If there is no file named PS_11_child when the script steps ask for one, you will be prompted to find it, so changing the name of the child databases shouldn’t be a problem.

An important point to make with this process is that the syncing steps are wholly dependent upon accurate timestamps in fields. Those timestamps are automatically entered when a record is created or modified but I ran into some problems late last week that were related to the iPad recording the wrong time. It was set properly in Settings-General-Date & Time. That is, my time zone was right, but when I tell the iPad to set the time automatically it sets it for four hours earlier. I haven’t figured out why this is the case, but I have to make sure that all iPads are set to the correct time in the field.

This database syncs by having a shadow table for each main table. So there is an SU table and an SU Shadow table. The child records go into the shadow table and are compared with the main SU table. For this to work properly, if you make a change to the SU table on the parent, you must make the same change to the SU Shadow table, or the fields will not import correctly.

We are currently still in the process of testing the scripts and syncing mechanism. We also have a couple of internal questions to settle on matrices and elevation recording, so this isn’t quite the database that we will use this year, but it is close.

Update– I added the full DDR report and reposted the archive. A DDR report is a full description of the database in (this case) html format. Open the DDR folder and double-click on Summary.html to see how detailed. I am in the process of updating the documentation for the use of the database as well.

One of the first things we realized in 2010 at Pompeii was that while the iPads were working for our data recording, too many people wanted to use them at the same time. One person needed to record some elevations at the same time someone wanted to write down a description of the soil of the fill. Our immediate answer to that was: put two in each trench. It wasn’t until this spring that I began to wonder just how that would work. Even if I had a full network going at the site, which I don’t, I couldn’t keep the two iPads totally in sync with their various documents. So you couldn’t pick up iPad 53000-1 (I named them after their trench) for twenty minutes, add some data, put it down, and then pick up 53000-2 and expect to pick up where you left off. And if you couldn’t do that, how do you separate the duties that the iPads need to perform?

While speaking to the trench supervisors this spring about it, we seem to have come to the conclusion that we can separate the software and duties that each iPad will handle.

iPad 1 will usually be at the trench supervisor’s side. That will be the primary tablet for the notebook and matrix information. iPad 2 will be the database and drawing tablet. My concern is that the drawing and data recording will need to be done at the same time but I have been assured that this isn’t the case.

The two iPads will have access to the other’s data, but it will be up to four hours old. I can copy the database and the drawings from the first iPad to the second and copy the documents from the second iPad to the first, but the team members need to know what is editable on each iPad.

We will see how that works soon.

I still haven’t finished getting syncing working with the entire PARP:PS database. The testing and troubleshooting phase of this is taking longer than I thought. But since I have worked out the basics, I decided to upload a demo file that explains the technique.

Sync_Trenches.zip

This file contains only a Trench table, not the full suite of tables used in the field. But by doing so, I was able to cut everything down to the basics to explain the parts of the database that are necessary for creating the audit trail and for syncing. In order to get everything to work there is a new table, changes to two fields, and the addition of a few fields. This file also uses Script Triggers and Conditional formatting to help create the audit trail and resolve sync issues.

There is a readme in the file. That text is reproduced below.

Special thanks to Chris Motz at Tufts for helping me with the scripting.

Read the rest of this entry »

The good news is that I have syncing working with FileMaker. Creating a syncing strategy turned out to be a bit trickier than I thought. Most of the difficulty involved the overall workflow if the data and the iPads. For instance: we will have two iPads per trench this year and I needed to work with the trench supervisors to figure out just how they intended to use the two together. Since we will have four trenches open this year, I needed to know if I was going to have to sync eight iPads or just four, or if the two for each trench had to be in sync with each other. I think we have worked out a strategy for the two iPad use, but I will write about that separately. Right now I want to write about the rationale behind the syncing strategy that I chose and how this was implemented. The files will be uploaded soon. Read the rest of this entry »