Field Type Reference Table

This comprehensive reference provides detailed specifications for all Fieldmark field types, supporting informed selection for digital data collection notebook design. We present technical capabilities, validation options, and platform-specific considerations for each field type within the Designer interface.

Text and Identifier Fields

Field Type	Purpose & Description	Typical Examples	Technical Specifications	Validation Capabilities	Platform Considerations
Single-line Text	Brief textual entries where neither controlled vocabularies nor auto-generation are appropriate	“North wall”, “Sandy matrix”, “Excavator notes”	Character limit: ~255 practical maximum Input types: text, email, url Returns: String	Pattern matching via regex Length constraints Required field option	Universal compatibility Predictive text on mobile
Multi-line Text	Extended descriptive content requiring paragraph formatting	Context descriptions, interpretation notes, detailed observations	No practical character limit Adjustable row height Returns: String	Length validation Required field option No pattern matching	Touch keyboard challenges on mobile Consider voice-to-text
Email	Validated email address collection	“projectlead@university.edu”, “lab@institution.org”	Standard email validation Returns: String	RFC 5322 compliant validation Required field option	Keyboard switches to email mode on mobile
Address	Structured physical address components	Site locations, institutional addresses, property details	Multiple sub-fields (street, city, state, postcode) Returns: Structured object	Component-level validation Postcode format checking	Auto-complete varies by platform
Templated String	Auto-generated identifiers combining multiple field values	“SITE1-2024-CTX045”, {{project}}-{{date}}-{{counter}}	Mustache.js templating Supports conditionals Returns: String Read-only display	Not user-editable Updates dynamically	Essential for human-readable IDs No parent field access
QR/Barcode Scanner	Camera-based code capture for pre-printed labels	Specimen barcodes, equipment tags, location markers	Supports multiple formats (QR, Code128, etc.) Returns: String	Format validation possible Pattern matching	Mobile applications only Not available on web

Numeric Fields

Field Type	Purpose & Description	Typical Examples	Technical Specifications	Validation Capabilities	Platform Considerations
Number Field	Basic numeric entry without constraints	Artefact counts, simple measurements	Integer or decimal JavaScript number type Returns: Number	Type checking only No range validation	Period (.) required for decimals No locale formatting
Controlled Number	Numeric values with enforced boundaries	pH (0–14), percentage (0–100), depth (0–500cm)	Min/max enforcement Step increments Default values Returns: Number	Range validation Precision control Required field option	Supports sticky behaviour Spinner controls optional
Auto-incrementing	Sequential identifier generation	Context numbers (001, 002…), Sample IDs	Configurable padding Starting value Returns: String	Uniqueness guaranteed No user override	Cannot reset mid-project Team coordination critical

Date and Time Fields

Field Type	Purpose & Description	Typical Examples	Technical Specifications	Validation Capabilities	Platform Considerations
Date Picker	Calendar date selection without time	Excavation date, sample collection date	ISO 8601 format Returns: Date string	Min/max date ranges Required field option	Native date pickers on mobile Calendar widget on desktop
DateTime Picker	Combined date and time selection	Precise event timing, scheduled observations	ISO 8601 with time Returns: DateTime string	Date and time ranges Required field option	Platform-specific interfaces
DateTime Now	One-tap current timestamp capture	Record creation time, observation moment	Automatic capture User-triggered Returns: DateTime string	Always valid Can be required	Device clock dependency Timezone considerations
Month Picker	Year and month selection only	Seasonal data, approximate dates	YYYY-MM format Returns: String	Year range limits Required field option	Simplified interface No day selection

Selection Fields

Field Type	Purpose & Description	Typical Examples	Technical Specifications	Validation Capabilities	Platform Considerations
Checkbox	Binary true/false decisions	“Sample collected?”, “Photography complete?”	Returns: Boolean Default: false	Required completion Can control logic	Large touch target on mobile
Radio Buttons	Single selection from 2–7 visible options	Preservation state, weather conditions	All options visible Returns: String value	Required selection Option validation	Excellent mobile usability Space consuming
Dropdown (Select)	Single selection from many options	Species list (50+ items), material types	Conserves screen space Returns: String value	Required selection Dependent on vocabulary	Scrolling challenges on mobile
Multi-select	Multiple simultaneous selections	Construction materials, observed behaviours	Checkbox list Returns: Array of strings	Min/max selections Required field option	Touch selection challenging Consider chip display
Hierarchical Dropdown	Nested categorical selection	Taxonomies, period → phase → subphase	Tree navigation Returns: Full path or leaf	Depth validation Required at any level	Complex navigation on mobile Consider search function

Spatial Fields

Field Type	Purpose & Description	Typical Examples	Technical Specifications	Validation Capabilities	Platform Considerations
Take GPS Point	Single coordinate capture	Find spots, sample locations, photo positions	Returns: GeoJSON point Includes metadata (accuracy, altitude)	Accuracy thresholds Required field option	Mobile GPS superior Browser geolocation limited
Map Drawing	Visual feature creation on base maps	Site boundaries, excavation areas, transects	Points, lines, polygons Returns: GeoJSON Multiple features	Geometry validation Area/length constraints	Requires internet for base maps Touch precision varies

Media Fields

Field Type	Purpose & Description	Typical Examples	Technical Specifications	Validation Capabilities	Platform Considerations
Take Photo	Camera capture or gallery selection	Context photos, artefact images, working shots	JPEG/PNG EXIF preserved Returns: File reference	File size limits Required field option	Compression settings Storage considerations
File Upload	Arbitrary file attachment	PDFs, spreadsheets, audio, video	Any file type No size limits (practical) Returns: File reference	Type restrictions possible Required field option	Upload time considerations Bandwidth dependent

Relationship Fields

Field Type	Purpose & Description	Typical Examples	Technical Specifications	Validation Capabilities	Platform Considerations
Related Records	Inter-record connections	Stratigraphic relationships, sample → context links	Parent-child or peer Vocabulary pairs Returns: Relationship array	Required relationships Cardinality limits	Performance degrades >50 relationships Mobile interface limited

Display Fields

Field Type	Purpose & Description	Typical Examples	Technical Specifications	Validation Capabilities	Platform Considerations
Rich Text	Formatted instructional content	Warnings, procedures, contextual help	Markdown support Display only No data storage	Not applicable	Responsive rendering Image embedding supported

Critical Implementation Considerations

Human-Readable Identifiers (HRIDs)

Whilst technically optional, we strongly recommend implementing HRIDs using Templated String fields for every form. Without HRIDs, the system defaults to opaque UUIDs (e.g., “rec-5f8a9b3c”), substantially complicating data management, export interpretation, and team communication. Configure the hridField property in your viewset to specify which Templated String field serves as the identifier.

Conditional Logic Architecture

Fields capable of controlling logic (marked in specifications) can trigger visibility conditions through standardised operators (equal, not-equal, greater-than, less-than). Complex conditions utilise AND/OR combinations. Note that controller fields require the logic_select property or inclusion in conditional_sources for optimal performance.

Platform-Specific Limitations

Critical platform disparities require careful consideration:

• QR/Barcode scanning functions exclusively on mobile applications

• Map fields require internet connectivity for initial tile loading

• GPS accuracy varies significantly between mobile devices and browsers

• Touch interfaces present challenges for precise selection and text entry

Performance Boundaries

Documented performance thresholds inform design decisions:

• Relationship fields: Noticeable degradation beyond 50 relationships, unusable beyond 200

• Long option lists: Consider hierarchical organisation beyond 20 items

• Media synchronisation: Device-specific download toggles essential for photo-intensive notebooks

• Complex conditional logic: Multiple controller fields may impact form responsiveness

Validation Limitations

Current validation architecture exhibits specific constraints:

• No cross-field validation (cannot compare Field A to Field B)

• No custom validation functions for project-specific rules

• No mathematical operations between fields

• No prevention of logical contradictions in relationships

• Validation occurs client-side with limited server verification

Export Considerations

Each entity type exports as a separate CSV file with relationships preserved through identifier columns. The export format maintains relationship semantics (e.g., “cuts/CTX-042;fills/CTX-043”) but requires manual reconstruction for hierarchical analysis. Design vocabularies and identifiers with post-processing requirements in mind.