What a tick in a platform comparison table hides and what to write instead

A tick in a comparison table is the least informative mark in publishing. It means the capability exists somewhere, in some form, on some tier, for somebody. It does not mean the reader can have it, and two ticks in the same row routinely describe arrangements that have almost nothing in common.

This page is about the cell. What a tick is actually hiding, the vocabulary that replaces it, and the handful of words that should never appear in a comparison table because they cannot be checked.

What to take away

What a tick can mean

At least five different things, and readers cannot tell them apart.

Present and included. The reader gets it on the plan being compared. This is what a tick implies and it is the least common case.

Present on a higher plan. Real, and not available to the reader at the price in the column header. Very common, and the single biggest source of misleading tables.

Present with a limit. Real up to some quantity, then it stops or costs more. A tick with no limit stated is a tick that will be wrong for anyone who uses the feature seriously.

Present in some places. Real where the reader is not. Regional differences in this category are ordinary and almost never marked.

Present in name. Something exists under that word and it does not do what the word implies elsewhere in the table. This is where a comparison quietly becomes fiction, because the same label is being applied to two different things.

Each of those is a legitimate state of the world. What is not legitimate is compressing them into a mark and letting the reader assume the first.

The closed vocabulary that replaces the tick

Pick a small set of values, define each in a sentence, and use nothing else. A controlled vocabulary is what makes a column filterable and what stops two editors meaning different things by the same cell.

Seven values, all short, all filterable, and each one a claim somebody could check. The last one is the value most catalogs refuse to use and the one readers benefit from most.

The row definition is doing all the work

A cell can only be checked against a definition, so each row needs one: a sentence saying what would count as the capability being present. Write it before filling anything in.

"Export" is not a row. "The account holder can download every post they have made, with dates and authorship, in a machine-readable file, without contacting support" is a row. It has an obvious test, and a service that provides a partial version scores as limited with the boundary named rather than as a tick.

This is what an operational definition does: it replaces a word everyone thinks they agree about with a procedure that settles it. Rows without one are where two editors, or one editor a year apart, quietly disagree.

Definitions also give you the comparison's boundary. A row nobody can write a test for is a row that should not be in the table, however much readers ask for it.

Words that should not appear in a cell

Powerful, extensive, comprehensive, intuitive, flexible. None can be checked and all read as endorsement. If a capability is better on one service, say on which dimension and by what test.

Some, many, may, up to, various. These are weasel words, and in a comparison table they usually mean the editor did not find the number. Write not established instead; it is the same information without the implication of knowledge.

Unlimited. Almost always bounded by something stated elsewhere, usually in an acceptable-use section. Quote the boundary or write limited with the boundary as not established.

Coming soon. Not a state of the world. A capability that does not exist yet is absent, with a dated note of the announcement if there is one.

What every cell carries besides its value

Four small pieces of metadata, and they take one line in the record even if the published table shows them only on hover or in a note.

The plan. Which tier the value describes. Without it the whole table is ambiguous.

The region. Where it was checked from. Regional variation is normal, and an unmarked cell claims universality.

The date. When it was checked, not when the page was published.

The kind. Measured, quoted, or not established, in the sense the protocol for running a comparison as one experiment sets out. A quoted cell is the operator describing itself and is weaker evidence than a test.

A table where every cell carries these is longer to build and much harder to argue with, and the four pieces are exactly what a reader needs to decide how much weight the row can bear. The same reasoning produces the checkable sentence in the notes on writing a fact a reader can verify.

Why feature rows should be a small part of the table

Capabilities converge. Anything popular on one large service appears on the others within a season or two, so a table made mostly of feature rows is describing a temporary state and will be quietly wrong within the year.

The rows that stay true are structural: who decides a post is seen, what leaving costs, who the service sells to. Those change rarely and decide far more about what building somewhere will be like.

A comparison that spends twenty rows on features and one on distribution has inverted the weights. That is the argument running through the six-axis method.

Keep the feature rows for the specific capabilities the reader stated as requirements, and let the structure carry the rest. The reason published figures cannot fill the gap is the subject of the notes on how platform numbers are produced, and it applies to any cell containing a quantity the operator defined.

Common questions

Is a tick ever acceptable?

Where the row definition is binary and the test is unambiguous, and where the tier and region are shown for the whole column rather than per cell. That is a narrow case and it is worth checking that it really applies rather than assuming it.

What if a capability exists but is bad?

The cell says it is present on those terms; a quality judgment is a separate, signed note, not a downgraded cell. Mixing the two means a reader cannot tell whether a service lacks something or the editor disliked it.

How many rows should a comparison have?

Between five and ten, most of them structural. Longer tables are padding, and padding is where the ties live that make a comparison look thorough and read as undifferentiated.

The operator says my cell is wrong.

Ask which plan and which region they are describing, because that resolves most of these. Where it does not, publish their statement beside your test with both dates, correct the cell if they are right, and keep the old value visible with the reason.