People give all things a name. Naming things is a way to give order to the world. It also helps other people to know what you are referring to. In science, the classification of species is called a taxonomy.
In any software development project, giving things a proper name, is also of crucial importance, for much of the same reasons. Don’t tax your taxonomy and make use or our experience.
At OpenC we apply a consistent and documented system for naming things in Studio (and in the rest of the Claris platform). Here is a summary of the rules of thumb we apply:
Studio name — make it short and sharp, for example: OpenC DEV
Important when you have to manage and develop several Claris Studios and switch between them.
User names — include the department or organisation name, for example: Remco van Buren of OpenC
There is no description field for the user, at the time of this writing. So we include the name of the organisation in the User name. We also add the word ‘of’ because sometimes we user that account name on a View, like this: ‘Hi Remco van Buren of OpenC!’ That makes more sense then something like ‘Hi OpenC | Remco van Buren!’
Group names — include the role, for example: OurClient, Users
In Claris Studio there is, as of 2025, no description field for a Group, at the time of this writing. That is why we put a description of the user role into the Group name field.
Hub names — keep the user in mind, for example: Your Clients
If the user has Member rights, and logs into Studio, and then it must be immediately clear what the Hubs they have access to, mean to them. Examples of hub names: ‘Sales funnel’ of ‘Project AI’.
View names — short and meaningful for the user, for example: Your Clients Form
The tile of a View indicates what kind of View it is. For example, a Spreadsheet View is a green tile with a table-icon in it. A Form View is a mid-blue tile with a form-icon in it. But still, at OpenC we put the name of the View type into the description, at the end, without the word ‘View’. Some examples:
Clients Sheet(Sheet as a shorter word for Spreadsheet View).Clients Form(for Form View).Clients CV(for Custom View).Clients Media(for Gallery View).
Frame — this functionality is yet to come, we’ll add our guidelines at a later moment
Table names — Begin-capital and in plural, for example: Clients
When a table is created in Studio, it gets a default name such as Spreadsheet16. Change it, otherwise it will be hard later on the select the right table, in Studio calculations or in Claris Connect flow steps.
Field names — apply the the underscore_method, but be aware! For example: client_name
In general there are two conventions of naming tables and fields: CamelCase and underscore_method. At OpenC we have decided to use the lower case underscore_method. We have several reasons for this choice. With this method:
- we do not have to use quotes in Studio calculations.
- we have no field names in curly brackets, which improves readability in Claris Connect.
- the meaning of certain words in English is clear. Examples: after-school and after school, backyard and back yard, or undervalue and under value.
Plus, CamelCase is a bit harder to read for some people than the underscore_method.
Object names on Views — Put the field name and the object type in the Object name, for example: client_full_name_shorttext
Always give the Object a proper name. We include the field name, then one underscore and then the object type. Other example: client_list or client_sheet.
Display labels and placeholders – be clear to the user
The Display Label instructs the user what to enter. It should be to the point, so that the user knows what to enter.
The placeholder can further assist the user: it can contain an instruction such as ‘Enter your name’ or it can give an example.
If it does not add value to the user we leave the placeholder empty. The user then has to read less text, and it gives a cleaner look to the screen.
As a bonus, here’s two more guidelines we apply at OpenC:
- In Studio, we only use number fields if we need a field for numeric calculations, such as add or divide. If we need a field for a status code, such as
0,1or2, we never use a number field, because these codes are not arithmetic values. Hence, we use a short text field for those. - Be aware that field names and also field descriptions cannot be labeled on screen, in certain objects, such as a Spreadsheet Object. These objects show the field name and description, for example
client_name. If that’s a problem for your users, you have to rename the field toClient namefor example.
Want to know more?
Download the OpenC guidelines here. This document contains some screenshots and a little more details, for clarification. Apply the OpenC naming conventions guideline for Claris Studio, or adopt them to suit your needs and those of your clients.