Tables and Portrait Tables

The table types#

Choosing between the first two is purely a shape question. Twenty-four hours against four measures wants the standard table — periods down the page. Forty measures against three days wants the portrait table, because forty columns will not fit on anything.

Time Based Table#

The default. Create it with the constructor for your interval, drop measures on it, and each becomes a column while each period becomes a row.

This is the natural shape for the shift report — the document a supervisor prints or reads at handover, with the hours down the side and the key figures across the top. It is one of the most-used things in an Infohub deployment and worth building deliberately:

• Order the columns as the reader thinks, not as you happened to add them.
• Keep it to what fits without horizontal scrolling.
• Set formats on the measures so decimals align — 0.0 rather than #.#. See Format Strings.
• Include the unit in the column heading, which comes from the measure.

Portrait Table#

Rows are measures, columns are periods. Use it when you have many measures and few periods — a daily summary of every KPI for a plant, or a monthly view of an area's whole measure set.

It is also the more readable option when measure names are long, since a long name reads better as a row label than as a rotated column heading.

Comparison Table#

Shows values against a comparison, which is what most management reporting actually wants: this period, the comparison period, and the difference.

Build the variance as a calculated measure rather than expecting the reader to subtract mentally, and format it with an explicit sign so direction is unambiguous:

+#,##0.0;-#,##0.0;0.0

Where "better" is not simply "higher" — cost per tonne, downtime, energy per unit — say so in the column heading. A red negative variance on a cost measure is good news, and someone will misread it if the table does not make the direction explicit.

Event Based Table#

One row per event, with attributes as columns. This is the detail view for anything event-based: today's batches with their yields, the shift's stoppages with reasons and durations, the week's changeovers with their from-and-to products.

It is also where people go to check whether an event was captured correctly, which makes it worth having alongside any event scheme even if the analysis lives on a Pareto chart.

Create it with the Event Based constructor and drop the event scheme on it. Attribute columns follow. See Analysing Data by Event.

External links#

A Time Based Table or Portrait Table can carry links out to other systems, configured per measure in the table's Sections. Each link is a URL, and placeholders let it be built from the row's own context rather than being a fixed address.

This is what stops a dashboard being a dead end. The table shows that a batch failed its spec; the link goes straight to the LIMS record for that batch, the SOP for that product, or the raw trend in the historian — without the reader copying an identifier into another application and searching for it.

Three things worth knowing:

• Links are configured on the table's sections, not on the measure, so one measure can link somewhere different on two different tables.
• Placeholders make one definition serve every row, which is the difference between configuring one link and configuring hundreds.
• Available from Flow 7.1 onwards.

The usual mistake is linking somewhere the reader cannot reach — an internal tool behind a VPN, on a dashboard displayed on a plant-floor screen. Check the link works from where the dashboard is actually read, not from where it was built.

CSV export#

Tables support CSV export, which is more significant than it sounds.

A great deal of real reporting ends in a spreadsheet — someone needs the numbers to combine with data Infohub does not hold, to send to a customer, or to work through in a way no dashboard anticipates. A table with CSV export satisfies that directly, and it is a far better answer than someone retyping figures off a screen.

Practical implications:

• Where a table exists to be exported, favour completeness over on-screen tidiness. Extra columns cost little in a CSV and save a second request.
• Formats affect the export, so a format that renders a number as Pass exports as Pass. Usually helpful; occasionally not what a spreadsheet wants.
• If people are exporting the same table every week, that is a candidate for a scheduled report instead.

Images — JPEG, PNG, PDF — are available for charts generally, rendered from the chart itself. See Exporting and Scheduling Reports.

Readability#

Tables are dense, so small decisions matter more than on a chart.

Right-align numbers, left-align text. Aligned decimal points let the eye compare down a column.

Use consistent decimal places within a column. Achieved by setting the format on the measure, not per cell.

Do not show more precision than exists. Six decimal places on a temperature makes the table harder to read and no more accurate.

Use colour sparingly. Limits can colour cells, which is powerful for exception reporting — but a table where every cell is coloured has no signal left. Colour the exceptions.

Give the table a period the reader recognises. A table showing "the last 24 hours" rolling is harder to discuss than one showing "yesterday" or "this shift".

When not to use a table#

If the reader's question is "is this getting better or worse", a table is the wrong answer. Trend is a shape, and a column of twenty-four numbers does not convey shape to anyone.

The common failure is a dashboard that is entirely tables, usually built by someone recreating a spreadsheet they already had. It technically contains the information and communicates very little. Pair tables with trend charts: the chart shows the shape, the table gives the exact figures.

Diagnosing#

See also#

• How Infohub Charts Work
• Chart Type Catalogue
• Exporting and Scheduling Reports
• Forms and Data Capture