Capitalisation

Sentence case — the default

Sentence case means capitalising the first word of a sentence or label, and any proper nouns. Everything else is lowercase — regardless of how important it seems.

Sentence case applies to:

• Page headings and section headings
• Navigation labels
• Button labels and action text
• Form labels and helper text
• Tooltip text
• Empty state messages
• Error messages and notifications
• Table column headers
• Tab labels
• Modal titles

Title case — proper nouns and product names only

Use title case for proper nouns: the names of specific people, places, organisations, products, and officially named things.

What counts as a proper noun in Open Point context

• Product names: Open Point, Social Point, Orbit (always title case or all-caps respectively)
• Feature names that are officially named: Check with the product team before treating a feature as a proper noun — most features are common nouns (a dashboard, a report, an export)
• Product entity names: Stakeholder, Property, Event, Consultation, Response (Open Point) and Project, Team, Team Leader, Campaign (Social Point) — see below
• Organisation names: City of Brisbane, Department of Transport, Queensland Government
• A specific named instance of an entity, used as a proper name: “Northern Rail Corridor Consultation” — a single, uniquely-identified Consultation, capitalised for the same reason as any proper name
• People’s names and job titles when used before a name: “Project Administrator Chen” — but “the project administrator” in running text

Product entity names — capitalised (pending review)

Product entity names are capitalised wherever they appear in UI copy — labels, buttons, headings, running text — regardless of whether the reference is generic or specific:

• Open Point SRM: Stakeholder, Property, Event, Consultation, Response
• Social Point: Project, Team, Team Leader, Campaign

The case for reconsidering this

This comes up often, usually from engineering, in the other direction: an entity is named and typed in the data model — Stakeholder, Property, Event — and the argument is that this alone justifies capitalising it in the UI. That reasoning is worth being precise about, because it’s the same reasoning that got us to today’s standard, and it has real limits:

• “Official” has two different meanings, and only one of them is about grammar. Being an officially-named entity in the schema or API is a fact about the codebase. Being a proper noun is a fact about grammar: proper nouns name one specific, unique thing (a person, a place, a single named event) — not a category of things. “Stakeholder” names a category of record, which is why, grammatically, it would default to a common noun. A database column named created_at doesn’t get rendered as “Created_At” for the same reason.
• The current standard only holds together because it’s applied to every entity, everywhere. If one entity is capitalised because it’s “official,” every entity can make the same claim — which is exactly why this only works as a blanket rule (every entity, every surface), not a case-by-case grant. The moment it’s inconsistent, it’s worse than either consistent choice.
• Some products do capitalise their core objects — deliberately, and everywhere. Salesforce capitalises Account, Contact, and Opportunity throughout its UI, which is the closest precedent for what Open Point/Social Point are doing today. It’s a legitimate, consistently-applied product decision — but even Salesforce’s own style guidance describes it as a judgement call rather than an absolute rule, with acknowledged inconsistency at the edges (e.g. plural references).

Today’s standard is capitalisation, applied consistently across both products. This section exists so that if marketing’s review lands on the grammar-first argument instead, the reasoning is already written down.

All-caps — status badges and defined label types only

All-caps text is visually heavy and should be used sparingly. In Open Point products, all-caps is reserved for:

• Status badges: DRAFT, PUBLISHED, CLOSED, ARCHIVED — these are short, well-defined states where all-caps increases scannability in dense data views
• Section labels in navigation: when the design uses a visually distinct uppercase label to separate navigation groups (e.g. the Orbit sidebar)
• Abbreviations: Orbit, CRM, API, PDF — these are initialisms and follow their own conventions

All-caps should never be used in running copy, headings, button labels, or form fields. It reads as shouting in prose context and reduces readability.

Common mistakes to avoid

• Capitalising for emphasis. If something is important, say it more directly — don’t capitalise it. “This action is permanent and cannot be undone” is clearer than “This Action Is Permanent And Cannot Be Undone”.
• Treating UI sections as proper nouns. “the Dashboard” should be “the dashboard”. “the Settings page” should be “the settings page” or just “settings”.
• Inconsistently capitalising the same term. Pick one treatment for every term and use it consistently across the product. “Consultation” and “consultation” in the same interface creates confusion about whether they mean the same thing.
• Over-capitalising feature names. Most features are described with common nouns — “the export tool”, “the settings panel”, “the activity feed” — even when a capitalised entity name appears inside them: “the Stakeholder map”, “the Consultation dashboard”. Capitalise the entity, not the whole feature name.
• Title-casing navigation items. Navigation labels follow sentence case, not title case: “Project settings”, not “Project Settings”.