Design once, run it every season
Most fieldwork repeats. The same protocol runs during the next season, at the next site, with the next cohort of students, or across a dozen teams who all need to record the same things the same way. A template captures the design so none of that starts from a blank page.
What a template holds
A template carries the whole design of a notebook: the forms and the sections inside them, every field and its options, the validation, the conditional logic that shows and hides fields as a record is filled in, and the pattern that builds each record’s human-readable identifier.
What it does not carry is data. A template is the shape of the work, not the records.
Two ways to arrive at one
Refine a notebook, then keep it. Build a notebook, take it into the field, find out what works and what does not, and save the proven version as a template. This is the route most projects take: a design that has survived contact with the field is worth reusing.
Or build the template first. Where the protocol is already settled, in a standard that several teams have to follow or a survey that must match last year’s, design the template directly and deploy notebooks from it.
Deploying from a template
Creating a notebook from a template takes the design across whole. Each notebook is then its own thing, with its own records, its own team, and its own roles. Working out a problem in one team’s notebook does not disturb another team’s, and editing the template later leaves every notebook already deployed from it untouched.
The same, or nearly the same
Repetition is rarely exact. A second site needs two fields the first did not, a consulting job follows the standard protocol with a client’s extra requirement, and a long-running survey learns something each season that changes what is recorded the next. A template accommodates all of these situations. Deploy a notebook from it and then edit the resulting notebook to add what a particular deployment needs, leaving the template as a shared core, or fold the change back into the template so that every deployment from now on carries it.
A template becomes the place where a protocol evolves deliberately. Each notebook records which template it came from, so the lineage from season to season or site to site is visible, and the decision to change the protocol is made once, in one place.
Templates have roles of their own
Who may create, edit, and use a template is governed separately from who may work in a notebook, so the person who owns a protocol need not be the person who runs each deployment of it.
A template can belong to a team, where anyone with the right team role can deploy notebooks from it, so a lab or a survey programme keeps its projects consistent without a single person having to build each one.
See also
- Shaped to your protocol for the Notebook Editor, where a template is designed and edited.
- Shared on your terms for teams, roles, and who may change a design.
- Works offline for what happens once a notebook built from a template reaches a device.
- FAIR from the field for the metadata a notebook carries and where it goes on export.