1 Introduction

The WDFW Fish Program currently uses iFormBuilder as a platform for building and deploying mobile forms. Although there are numerous alternative mobile platforms, both commercial and open-source, among the benefits of iFormBuilder are an easy-to-use form building application, a fairly good system for syncing between forms and devices, and an excellent application programming interface (API). The API is particulary useful, as it allows us to automate many of the most burdensome aspects of building forms and managing data flows.

1.1 Why mobile forms?

1.1.1 Trade-offs

Mobile electronic forms provide a number of advantages over paper forms, but as always, there are trade-offs. For seasoned surveyors, the field notebook has long proven to be a simple and effective tool to jot down observations. Short-hand comments and codes have been developed that enable recording a great deal of information succinctly and quickly. Switching to mobile forms can slow down data entry in the field, at least initially. This can be frustrating when you have a large number of streams to survey, limited staff, or short windows of opportunity between fall and winter storms to get those surveys completed.

Avoiding unnecessary slowdowns and keeping your surveyors happy is important. This is also the main reason for making sure that the structure of mobile forms is kept as simple as possible. Minimizing the number of subforms can speed up data entry in the field. Conditionally hiding data inputs until they are truly needed keeps your forms streamlined and free of unneeded clutter. You should also consider creating separate forms for the different types of surveys you conduct. For example, by creating forms strictly intended for Steelhead surveys you can typically eliminate a large number of data elements that you would only need for fall carcass sampling. Fewer data elements result in forms that load faster and are quicker to navigate. But regardless of how simple the form, there will still be some pain to begin with. That pain will go away in time, especially as the benefits of using mobile forms become more apparent.

If your survey protocols are relatively simple, and you are only interested in recording a few core data elements, the benefits of mobile survey forms may not be immediately apparent. In such cases the entire process of capturing, recording, transcribing, proofing, analyzing data may need to be taken into account before the true efficiencies become compelling.

1.1.2 Automated, integrated, data capture

One of the greatest benefits of mobile forms is that it allows for capturing data using a variety of sensors quickly and accurately. Those data are then fully integrated with all your other observations. Much of this data would be impossible, or impractical, to capture using a field notebook. A good example is location data. It can often be useful to map locations of salmon redds to understand density over time, or see how changes in habitat have affected populations in a particular section of a creek or river. Using a typical combination of field notebook and a separate GPS unit, considerable work is required to download, proof, and integrate the location data with the field notebook data. Both the field notebook data and GPS data needs to be separately entered, proofed, and finally combined. These are tasks that humans are typically not very good at. Errors should be expected. By contrast, mobile devices include integrated GPS, and output integrated data. There is no need for manually combining disparate sets of data after the survey.

1.1.3 Enter once

Mobile forms avoid the need to transcribe data from a field notebook or write-in-the-rain datasheets to electronic format. Data only needs to be entered once. This avoids common transcription errors that can often be notoriously hard to spot. After the Done button has been clicked on the mobile device, the data can then be automatically written to our corporate database with no additional effort on the part of the surveyor or supervisor. After the data has been written to the central database it can be inspected, edited if needed, and exported for reports or analysis.

1.1.4 Validation

Another advantage of mobile forms is data integrity. Common errors can be automatically detected while still in the field by adding validation code directly into your forms. An unusual value can be flagged and the surveyor immediately asked to verify the suspect value before submitting. Validation code can be as simple or elaborate as needed. It is normal to add additional validation code during the testing phase, after you first launch your form, and start to notice where errors tend to occur. An especially useful feature of mobile forms is that you can add validation or other features as you progress through your testing phase. There is no need to print new survey forms. Updates to your form will be automatically synced to mobile devices every time the form is opened. Thorough testing is essential, but at the end of the process you should have a form that will be resistant to most common human errors.

1.1.5 Reporting

For biologists, an added bonus of mobile forms is a clean set of data that is housed in a predictable format, and securely backed up. With proper validation on the front-end, data transmitted from mobile form to back-end database is immediately available for reporting and analysis. Clean data, organized in a consistent format can make it easier to produce population estimates and reports. Data requests can typically be handled with a few mouse-clicks to export the relevant data. It is also relatively easy for someone familiar with scientific scripting languages such as R or Python to write scripts that can generate final publication quality escapement reports, complete with figures, and tables, directly from the database.

1.2 API

As mentioned earlier, a major benefit of using the iFormBuilder platform for building and deploying mobile forms is the application programming interface, or API. An API is simply a set of protocols that allows computers to talk to one another. One case where the API can avoid a great deal of pain is in constructing large filtered option lists. The prime example for spawning ground surveys are the drop-down pick-lists for survey start and stop points along a given stream. Lists with thousands of elements can be constructed and uploaded to the iFormBuilder cloud in seconds. The iformr package provides a set of functions that allows for using R scripts to automate many of these types of tasks. Instructions for how to get started can be found in iformr package GitHub repository.

1.3 Profiles

Since the source code for this manual is hosted on a public website, I will not go into detail on setting up devices, assigning AppleIDs, Google Play store accounts, or connecting to the WDFW iFormBuider account. The only prerequiste that needs to be stressed here is that you will want to get a separate iFormBuilder Profile set up for your workgroup. The main benefit is that it keeps your forms and option lists segregated from other groups. It makes it less likely you will lose data because someone accidentally edited your form…or deleted an option list. Please contact me, or other staff in the WDFW Fish Program, Science Division, Biological Data Systems team to get this set up.

1.4 Useful tips

1.4.1 Searching for help

There is a great deal of information available at the iFormBuilder website for learning how to build forms. This includes an extensive list of videos. Unfortunately, that information is not always well organized. You can often get better results doing your own internet search and prefacing a general search term such as parse location with the term iformbuilder. That said, the Customer Success Center is still a good place to start. If you have not already done so, watch the Art of Form Building video for an introduction to best practices. You can also use the iFormBuilder chat feature that typically pops up in the lower right-hand side of your screen when you open the Customer Success Center. This tends to be the quickest way to get answers to specific questions.

At some point you will need to write simple JavaScript code. This is especially important when you want to create conditional logic to hide or show a data input, validate data, or sum up a set of counts. An excellent website for help with JavaScript is w3schools. If you need to do something more complex, you will usually find that someone has already written a function to accomplish exactly what you want. Try searching on stackoverflow. In addition, there is a selection of commonly used JavaScript functions located in the appendix section of this manual.

1.4.2 Data column names

When adding new data inputs to your form keep in mind that the data_column names must be what is termed database friendly. They must all be in lower case, and you cannot use compound words, such as redd count without first tying the words together using an underscore. For example, redd_count. There is also a long list of reserved words that you cannot use for data_column names. The complete list can be downloaded from the link above.

1.4.3 Option lists

Always remember that option lists can be shared among different forms that are contained in the same profile. This means that whenever you edit an option lists you are editing options for all forms in the profile that share the list. This can cause major problems, including data loss, if you have other mobile forms in your profile and those forms share option lists.

1.4.4 Save often

When building forms, remember to Save frequently. Best practice is to get into the habit of clicking the save icon in the upper right-hand corner of the form builder interface every time you make a change.

Few things are more annoying than to make a series of changes to a form, then later realize that all your work has dissapeared because you forgot to save.

1.4.5 Test thoroughly !!!

Before you put a new mobile form into production you absolutely need to conduct extensive testing to make sure the form behaves as you intend. Train your surveyors on how to use the form and then let them loose to enter test data under realistic conditions. Humans can be extraordinarly creative when interacting with technology. You may find you need to add additional validation code, or restructure the flow of prompts in ways to work more naturally.

Once you have a form that works well you should resist making further changes during the survey season. Simple changes, such as adding items to an option list can be implemented on forms that are in production, but you may risk losing previously entered data if you make any substantive changes to data elements. In the Element Properties box of the form builder application, there is now text in red warning you of the dangers.

1.5 Conventions

This manual is meant to be an interactive resource for those learning to build mobile forms using the iFormBuilder platform. As such, there are numerous links to outside resources included. These are highlighted in blue. For example: w3schools.

You will also find snippets of code that can be copied and pasted directly from this manual to your forms. These are entered to code blocks such as:

if(species == 3 && redd_status == 0) {"Yes"} else {"No"}

Code blocks are also used to highlight text, code, or numbers that you enter directly into the form builder web application when designing forms. For example: ZCDisplayValue_stream, or the number -1, or data column names such as survey_method.

Screenshots are liberally included to help identify where commands are located in the form builder application. Bold text is used to bring attention to items of particular importance, such as Save often.

Finally, suggestions are always welcome on how to improve this manual. If you find errors, discover cases where conventions are not followed, locate additional outside resources that should be linked, or identify places where additional screenshots would be helpful, please let me know. You can file issues or contribute your suggestions at the project GitHub repository.