# Can digital site forms prevent unit mistakes? - Link: https://www.qtywise.com/blog/digital-site-forms-unit-error-checks/ - Published: 2026-11-10T09:00:00-05:00 - Author: Jamie C. ## Define the measurement record before configuring fields Digital site forms can prevent some unit errors by refusing incomplete records and showing a checked conversion. The form needs to know the quantity, measured value, unit and measurement boundary. A field that accepts any positive number cannot tell whether 12 means inches, feet or millimetres, even if the screen looks organized. Use the [Length Converter](https://www.qtywise.com/general-calculators/length-converter/) as an independent arithmetic check when testing supported length conversions. It accepts a value, source unit, destination unit and result precision. It cannot determine what the surveyor intended to measure or recover a unit that disappeared during export. Those facts must remain in the measurement record. For each entry, identify the room, element or marked measurement line. Define whether the dimension runs between finished faces, structural faces or another agreed boundary. A perfectly converted dimension from the wrong boundary can still produce an incorrect takeoff. Put this convention into the field instructions and the receiving quantity sheet. ## Keep the value and the unit together through every handoff Store a unit with each value or bind the whole measurement set to one explicit, controlled unit. Display that choice wherever the value is reviewed. If a unit selection changes after a number has been entered, define whether the system converts the number or asks the user to re-enter it. An invisible label change is unsafe. Retain the original value and unit alongside the normalized result. A record such as 12 in, converted to 304.8 mm, is more useful for an audit than a replacement value with no origin. Keep the conversion rule and software version with the project export where practical so later reviewers can reproduce the transformation. NIST’s [conversion tables](https://www.nist.gov/pml/special-publication-811/nist-guide-si-appendix-b-conversion-factors/nist-guide-si-appendix-b9) give an inch-to-metre factor of 0.0254. For an illustrative 12-inch record, 12 × 25.4 = 304.8 millimetres. Treat that as an exact unit relationship, while preserving the uncertainty of the actual field measurement. Converting a rough tape reading does not create extra surveying accuracy. ### Make mixed feet-and-inches entry explicit A hypothetical measurement of 5 feet 6 inches equals 66 inches, or 1,676.4 millimetres. It is not the same as 5.6 decimal feet, which equals 1,706.88 millimetres. The 30.48- millimetre difference is an input-convention problem. Use separate labeled fields or a documented parser and test the displayed normalized result. The same principle applies to fractions and decimal separators. Define whether a field accepts a fraction such as 3/8, a decimal such as 0.375, or a locale-specific decimal comma. Refuse unsupported formats with an explanation that lets the operator correct the entry. Do not silently strip punctuation and keep the remaining digits. ## Use field validation for the rules it can actually enforce MDN’s [number-input documentation](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/number) explains numeric validation, minimum and maximum values and step increments. It also notes that the default step is one, so decimal entries may be invalid unless the field is configured appropriately. Test the actual field configuration rather than assuming that a numeric keypad means decimal dimensions are supported. A valid range is a project decision, not a universal construction constant. A wall- height field and a bolt-diameter field need different bounds and units. Decide whether zero means a genuine measured zero, not applicable or missing data. Keep an unmeasured dimension visibly incomplete instead of defaulting it to zero and allowing it into a total. [MDN also warns](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/number) that browser validation does not replace validation of data received by the server. Apply the same business rules to imports and received records. The article’s test plan concerns data correctness; security and access control still need their own implementation and review. A valid-looking browser submission does not establish a trustworthy database record. ## Build tests with an independent expected answer Create a small acceptance dataset before rollout. Include ordinary measurements, boundary values, unsupported text and deliberately ambiguous input. Write the expected result independently of the form implementation. Reusing the form’s own conversion routine to generate every expected answer can allow the same defect to appear correct on both sides of the test. | Test input | Expected treatment | Reason | | 12 with unit in | 304.8 mm after conversion | Known reference conversion | | 5 ft and 6 in | 1676.4 mm | Mixed-unit record | | 5.6 with unit ft | 1706.88 mm | Decimal feet are different | | 12 with missing unit | Reject or request the unit | Quantity remains incomplete | | 1,25 in a decimal field | Apply the declared locale rule | Avoid silent punctuation changes | | Blank depth | Remain incomplete | Missing is different from zero | Check round-trip behavior with the [Length Converter](https://www.qtywise.com/general-calculators/length-converter/) and an independent calculation. Convert an accepted value to the normalized unit and back, allowing only the documented display-rounding effect. Preserve full necessary calculation precision behind a rounded display. A display precision control should not quietly alter the stored original measurement. Test the phone and keyboard layouts that workers will actually use, including copy- and-paste from another record. Keep a screenshot of the expected error message in the acceptance evidence when useful. A person should be able to understand the correction without knowing how the form was programmed. Record both the rejected input and the accepted correction. ## Test the export and the receiving calculation Follow a record into the spreadsheet, estimator or project system that consumes it. Check column names, unit fields, decimal handling and any import transformations. A correct entry screen can export a bare number that the receiver assumes is in another unit. Review a representative exported row with the person responsible for the receiving calculation. The NASA JPL [mission record](https://www.jpl.nasa.gov/missions/mars-climate-orbiter/) provides a documented warning from another industry: Mars Climate Orbiter was lost after a navigation error involving a failure to translate English units to metric, with last contact on September 23, 1999. This is not evidence of a construction- form error rate. It shows that agreed units must survive the interface between systems. Dimension also matters. A length conversion factor cannot be applied once to an area or volume. For example, converting square inches to square millimetres uses 25.4 squared, or 645.16. Cubic inches use 25.4 cubed, or 16,387.064. Test the quantity type before accepting any imported total, even when the numeric value falls within the allowed range. ## Retain corrections and approve the release Keep a correction record showing the original measurement, revised value, reason, date and responsible reviewer. If a unit mapping defect affects several records, identify the affected export version before recalculating quantities. Overwriting every original number makes the correction harder to review and can conceal whether the problem began at measurement, conversion or import. Run a small pilot with real measurement conventions and compare the results with a separately checked takeoff. Report the number of tested cases and their actual outcomes if you later claim improvement. Do not turn a successful demonstration into an invented percentage reduction in site errors or an unsupported return-on- investment figure. * Test required unit labels and missing values. * Separate mixed-unit entry from decimal entry. * Check conversion, rounding and quantity dimensions. * Follow exported records into the receiving system. * Keep original values and a reviewed correction history. Use the [Length Converter](https://www.qtywise.com/general-calculators/length-converter/) to verify individual length records before approving the form for production use. Keep that arithmetic evidence with the acceptance dataset, exported samples and signed measurement convention. A form is ready when the whole handoff behaves as specified, including the cases that it must refuse.