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.
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.
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…