Forms and Data Capture

The three form types#

Time Based Form is the standard one: rows are periods, columns are measures, and users type into the cells. This is how monthly targets, daily lab results, and shift readings get entered.

Event Based Form is a table of events where the attribute columns are editable. This is how downtime reasons and batch quality results get captured — one row per stoppage, a reason dropdown to fill in.

Limit Based Form shows values against their limits, which suits exception review: the values that breached, with room to record what was done about them.

Building one#

Create the form with the constructor for its interval — or the Event Based constructor for an event form — then drop the measures or the event scheme onto it. Editable columns come from what you drop: manual entry measures are editable, and so are manually entered event attributes.

Place it on a dashboard where the people who fill it in already go. This is the single most important decision about a form, and it is a layout decision rather than a form one.

The coloured marks on a cell#

A small coloured disc in the top-left corner of a cell, or a triangle on it, is telling you something about that value. They are easy to overlook, and worth teaching to anyone who fills in a form regularly.

The triangle earns its place at data-entry time: it tells whoever is typing that the value is out of specification while they are still at the machine and can check it, rather than a week later when somebody queries the report.

The amber disc matters for a different reason. It is the visible trace of an edit, so a form full of amber discs is a form whose values have been revised — either careful correction, or a process problem worth asking about.

Read-only cells#

Not every cell on a form is editable, and the rules are worth knowing because they cause questions.

A cell is editable when the underlying thing is manually entered. A retrieved, aggregated, or calculated measure on a form is displayed but not editable — Infohub will not let a person overwrite a value the engine computes, because the next calculation pass would discard it.

This is often what you want: a form showing yesterday's actual production (read-only, calculated) beside today's target (editable, manual) gives the person entering the target the context to set it sensibly.

If a cell you expect to be editable is not, check the measure's retrieval type first.

Designing a form that gets filled in#

The technical part takes ten minutes. Completion rate is the whole game, and it is a design problem.

Put it where they already are. A form on the dashboard a supervisor opens at handover gets completed. The same form on a dashboard three clicks away does not. If necessary, put the form on the shift dashboard rather than in a tidy "Data Entry" section nobody visits.

Keep it short. Five fields get filled reliably. Twenty do not, and worse, a long form trains people to enter something plausible rather than something true.

Use enumerations for anything categorical. A dropdown is one click. Free text is typing, and it produces four spellings of one reason that no analysis can group. See Event Attributes and Enumerations.

Set limits on manual measures. A limit that flags an implausible entry catches the misplaced decimal point at the moment of entry, rather than after it has propagated into a monthly report. This is the cheapest validation available.

Set sensible defaults where a default is meaningful, so the common case is confirming rather than typing.

Order the fields as the person works. The sequence should match the order they encounter the information, not the order the measures happen to sit in the model.

Show them why it matters. A form beside the chart the data feeds is completed far more reliably than one that appears to send numbers into a void. Pair a downtime reason form with the Pareto chart it produces.

Manual values cannot be regenerated#

Everything else in Infohub can be rebuilt from its source. A number a person typed cannot.

The same applies to event attributes entered by hand, and to an event scheme's purge age. A purged event takes its manually entered reason with it. See Manual Entry Measures.

Spreadsheets versus forms#

When someone asks for a spreadsheet to be read into Infohub, ask where the numbers come from. If a person types them, a form is better in every respect that matters:

See Files and Spreadsheets.

Handling gaps#

People forget, so decide what a blank means rather than discovering it later.

• Blank means no target — calculations guard for zero or null and produce no value, so the gap stays visible.
• Blank means carry forward — an expression reaches back: Measure_<id>.Value ?? Measure_<id>[-1].Value. Reasonable for slow-moving reference values, dangerous for targets, because a stale target silently becomes the current one.
• Blank means zero — right for counts of things that did not happen, wrong for most else.

The failure to avoid is not deciding, then finding months later that a chart has been comparing actuals against last year's target.

Diagnosing#

See also#

• Manual Entry Measures
• Event Attributes and Enumerations
• Dashboards and Navigation
• Measure Limits and Thresholds