The words we use
Embed
<a href="https://forumulate.com/guides/glossary"><img src="https://forumulate.com/guides/_api/public/orgs/046a9bc0-d530-43ae-9bae-af7945008cda/spaces/36aa4df0-1e95-4cef-8ae9-795169441345/pages/453b9520-b3f2-4f1f-b28b-bb44af3afd04/social-card.svg?v=3e7ae33eec8b" alt="The words we use" width="600" height="315"></a>One name per thing. A customer evaluating the product read studio, console and dashboard for the same surface, and reader, visitor and member for the same person, inside one afternoon — which reads as three features rather than one, so people go looking for a dashboard that does not exist.
This page is the decision. Where our own writing drifts from it, the page is wrong and this one is right.
The surfaces
Term | What it means |
|---|---|
console | The signed-in administrative surface for an organization, at |
studio | Editing a space in place. A space's root is the studio: your published site in the middle of the screen with a panel beside it. Narrower than the console, not another word for it. |
reader | The public surface itself — the pages a stranger sees at |
| Not a thing here. If you read it in our documentation, it means the console, and that page needs fixing. The exception is somebody else's product: your email provider's dashboard is theirs to name. |
The console and the studio are genuinely two things, which is why there are two words. The test: if what you are describing is about one space's content, it is the studio; if it is about the organization, it is the console.
The people
Term | What it means |
|---|---|
reader | Anybody reading a public surface — signed in or not, with an account or without one. The default word for a person on the outside. |
member | A person with an account in your organization, holding a role. A real and different thing from a reader: members are invited, counted against your plan, and can be granted capabilities. |
| Not a thing here. It always meant "reader". The one place the word survives is the name of a cookie ( |
A reader who signs in is still a reader. They become a member only when they are invited into the organization.
Content
Term | What it means |
|---|---|
space | One thing your site needs — documentation, a community, a blog — with its own address, its own type and its own permissions. |
piece | The generic noun for whatever a space is made of, because it is not the same noun in every space: a DOCS space holds pages, a FORUM holds topics, an EVENTS space holds events, a STATUS space holds monitors. |
page | A piece in a space whose pieces are pages. Not a synonym for "piece" — use the specific word when you know the space type, and "piece" only when you do not. |
collection | A group of pieces inside a space. What a documentation site would call a section. |
site | The published arrangement of one or more spaces under one address. |
So: "every piece in this space" is correct in a guide that covers all space types, and "every page" is correct in a guide about documentation. "Item" is the word the API uses for the same thing (/items), and it stays there — it is a route name, not prose.
Space types, named consistently
A space type has one name, and it is the one the product declares — the console, GET /space-types and this page all read the same declaration (packages/shared/src/space-type-specs.*.ts). Documentation that invents a second name for a type is the drift, not the declaration.
Two of them are easy to get wrong, because the displayed name and the API value differ:
The type is called | Its API value is | Its pieces are |
|---|---|---|
Community |
| topics |
Documentation |
| pages |
So write "a Community space", and FORUM only where you mean the value you send to the API. Lower-case forum is fine as the ordinary noun for what a Community space is — the product's own copy says "an empty forum stays empty" — but it is not the name of the type, and "Community (Forum) spaces" is not a heading: pick the name.