Prepare and test NAHPU on each device before relying on it for collection records. NAHPU is designed to make setup easy and config sharing straightforward. Setup is where error prevention is cheapest. A constraint added in Settings before departure removes a class of errors that would otherwise be found, if at all, by a curator years later.
Agree on the configuration
Section titled “Agree on the configuration”Settle the configuration with the team, not device by device. This ensures consistency across all devices and reduces the likelihood of errors. We recommend dedicating one person to run the setup in NAHPU. Then share the config with all members so they can configure their own devices.
Review field visibility and presets in Settings. Hidden fields can still hold data and appear in exports. Define a custom field only when a built-in field does not express the observation, and agree on its placement, type, scope, applicable catalog, units, and allowed values. Enter a test value and check its export.
Prepare shared resources
Section titled “Prepare shared resources”- Personnel and taxa. Assign the required personnel and review the taxon list, including identification ranks and uncertain identifications. Reuse existing database entries when they represent the same person or taxon.
- One maintainer. Decide which device maintains shared definitions and distributes updates.
- Documents and fonts. Prepare export presets, document templates, print layouts, and required fonts. User-config transfers do not include custom font files or images; install those assets separately and test the resulting documents.
- Project identity. Use project identity to establish a common project UUID when several devices contribute to one project. Everyone else using a different device imports that identity before creating records. A project name alone does not establish a shared UUID.
Rehearse the workflow
Section titled “Rehearse the workflow”Use a clearly named practice project. Create a site, coordinate, event, and specimen; change an identification; add a part, media, and an associated file where applicable. Leave and reopen each record to confirm the values persisted. Dialogs need an explicit confirmation button; many record fields save automatically.
Then run the exercise the way the field will run it:
- Work without internet, including the required location and camera permissions.
- Check the actual exported table and a printed label.
- Import a project archive on a separate test installation and open its records and files.
- Test database replacement only on an installation whose contents you can discard.
Verify by reading the record, not the export
Section titled “Verify by reading the record, not the export”Reopen each practice record and compare it against the physical tag, field by field. Scanning an exported table for gaps and outliers is not equivalent, and the difference is measurable: almost every real entry error is a plausible value in an allowed range, so it survives a check based on missing values and impossible numbers. Treat a clean-looking export as evidence of nothing in particular.
Where a value matters enough to justify it, enter it twice from the source and compare. Double entry costs time, which is a defensible trade for identifiers and measurements that cannot be recovered once the specimen is in a jar.
Before departure
Section titled “Before departure”Confirm available storage, power, installed resources, backup destinations, and the team's working project. See Devices, Device Choice and Care, and project recovery.
References
Section titled “References”Barchard KA & Pace LA (2011). Preventing human error: the impact of data entry methods on data accuracy and statistical results. Computers in Human Behavior 27:1834–1839.
Chapman AD (2005). Principles of Data Quality. GBIF Secretariat, Copenhagen.