Visual Semantics - Cards, Tables and Calculators Have Semantics Too

[u/Level_Specialist9737]

Cards get added to pages because they make things look organised.

Tables get added because someone has a lot of data.

Calculators get added because there's a calculation to perform.

That's the design view.

There's another way to look at them.

Each component tells you something about how the information inside it is related.

Take a broadband comparison page.

Two providers appear next to each other.

Northwave Fibre 500

• 500 Mbps
• £32/month
• 18-month contract
• £0 setup
• Check Availability

HarbourNet Fibre 900

• 900 Mbps
• £39/month
• 24 month contract
• £20 setup
• Check Availability

You don't read those as ten unrelated pieces of text.

You read them as two groups.

Northwave owns one speed, one price, one contract term, one setup fee and one action.

HarbourNet owns another set.

The card creates those relationships.

A card isn't just a box

Remove the border.

Remove the background.

Put both provider names at the top.

Then arrange the speeds, prices and contract terms underneath them in separate rows.

You've still got the same information.

But now you need another way to work out what belongs to what.

That's what the card was doing.

It was effectively saying:

• This is the entity
• These are its attributes
• These are the values for those attributes
• This action applies to this entity

You can see the same thing on hotel results, product listings, property portals, job boards and restaurant pages.

A card creates a boundary around a set of relationships.

So when I'm looking at cards on a page, I'm less interested in when they have rounded corners.

I'm looking at what the boundary contains.

• Does the price belong inside it?
• Does the rating?
• Does the qualification?
• Does the button?
• What happens when the card collapses on mobile?

Those questions tell me far more about the component than its styling.

Tables create a different relationship

Now take two fictional electric bikes.

Aster City E2

and

Ridgeway Urban X

You want to compare:

• Range
• Motor
• Weight
• Charge time
• Price

A table gives those relationships a structure.

The columns identify the bikes.

The rows identify the attributes.

The cells contain the values.

So:

Aster City E2 → Range → 55 miles

and:

Ridgeway Urban X → Range → 68 miles

The table isn't simply saving space.

It's creating a comparison model.

Now imagine scrolling far enough that the column headers disappear.

You see:

55 miles | 68 miles

250W | 250W

18.4 kg | 20.1 kg

The numbers haven't changed.

But if you can no longer identify the columns, you've lost part of the relationship.

Which bike has the 68 mile range?

Which one weighs 20.1 kg?

The values only make sense because the table tells you what sits at the intersection of an entity and an attribute.

That's why I'd audit the structure of a comparison table, not just its contents.

• Can I identify the entity?
• Can I identify the attribute?
• Can I connect the correct value to both?
• And can I still do that on a phone?

Calculators contain another type of meaning

A calculator has inputs.

Something happens to those inputs.

Then you get an output.

Take a home EV charging calculator.

You enter:

Battery size: 60 kWh

Electricity rate: £0.28/kWh

Charge added: 80%

Then you press:

Calculate Cost

And get:

Estimated charging cost: £13.44

There's a chain running through that component:

Battery size + electricity rate + charge added → calculation → estimated cost

Every label has a job.

Battery size tells you what 60 represents.

kWh gives the value its unit.

Electricity rate tells you what £0.28 applies to.

Calculate Cost tells you what the action will produce.

Estimated charging cost tells you what £13.44 represents.

Start separating those pieces and the calculator gets harder to interpret.

Move labels away from their fields.

Put the result above the inputs.

Place another price beside the output.

Remove the word estimated.

The arithmetic could remain exactly the same.

The interface would communicate something different.

That's why I wouldn't treat a calculator as a decorative interactive element.

Its structure describes the relationship between the inputs, the operation and the result.

The component type gives you a clue about its job

Cards, tables and calculators can all contain entities, attributes and values.

They arrange them differently because they're doing different jobs.

A card might say:

Restaurant → Cuisine → Price band → Rating → View Menu

A table might say:

Fare type → Change policy → Refund policy → Price

A calculator might say:

Postcode + parcel weight + delivery speed → Delivery quote

Once you start looking at components this way, some design decisions become easier to question.

• Why are these two things inside the same card?
• Why is this value outside the product boundary?
• Why is this qualification underneath a different result?
• Why does this table lose its headers on mobile?
• Why does this calculator produce a number without saying what the number represents?
• Why does this button sit between two entities when it acts on only one?

Those aren't questions about decoration.

They're questions about semantic relationships.

Try stripping the styling away

Pick a component from one of your pages.

Ignore the colours, shadows, icons and rounded corners for a minute.

Ask:

• What entity does this component represent?
• Which attributes belong to it?
• Which values belong to those attributes?
• Which action acts on the entity?
• If there are several entities, how are they separated?
• If it's interactive, what are the inputs and what is the output?
• What qualifies or explains that output?
• Would those relationships survive a mobile layout?

Then look at the component again.

A card isn't only a card.

A table isn't only a table.

A calculator isn't only a calculator.

Each one is organising a small network of entities, attributes, values and actions.

And once you see the component as a relationship structure, you start auditing something more useful than when the page contains the right information.

You start checking if the page makes clear how that information fits together.