Community Hub Component Design Guidelines
Community Hub Component Design Guidelines provide standards for naming and describing Community Hub components such as access controls, buttons, cards, card layouts, data sources, and pages.
For the examples in this topic, we'll refer to the International Society for the Exceptionally Nimble, which has an association acronym of ISEN.
Naming
More specific standards are provided for each type of component below, but the primary guideline is to use title case if the component's name allows spaces, otherwise use Pascal case.
Learn more about title case and Pascal case in Component Design Guidelines.
Naming Pages
We recommend naming pages in title case with the format:
[page heading label]
Specifically, for [page heading label], enter the value of the custom label specified in the page's Heading Label
. In other words, enter the title of the page the way it appears in Community Hub.
If you are creating an advanced page, [page heading label] is blank, so we recommend entering the same value as Label
for the Visualforce page you are displaying.
Naming Cards
The card's name should clearly indicate its purpose. The recommended way to name a card depends on whether you are cloning a Nimble AMS card or creating a new card from scratch.
Naming a Cloned Card
If you are cloning a Nimble AMS card and the default name clearly indicates the way you will use the cloned card, we recommend naming it in title case with the format:
[association acronym] [Nimble AMS card name]
In other words, preserve the name of the Nimble AMS card and simply prefix it with your Association's acronym.
Naming a New Card
Alternatively, if you are creating a new card that is not based on a Nimble AMS card, we recommend naming it in title case with the format:
[association acronym] [heading label] [additional context, if applicable]
Specifically:
- For [heading label], enter the value of the custom label specified in the card's
Heading Label
. In other words, enter the words that appear in the card's heading in Community Hub. For [additional context], enter more information about the card, particularly if there is more than one card in Community Hub with the same heading label. The additional context could be the object it is related to or the page it is used on.
Since the same card can be placed on multiple pages, we recommend introducing additional context only if it is necessary. As your Community Hub grows, you may discover that you can reuse a card that you originally planned to only use on one page.
If specifying additional context immediately after the heading label creates an unclear button name, you can include a hyphen before the additional context.
For example, ISEN has multiple cards labeled with the heading "Update Information" One of these is a card updating fields on a widget record, so it can be named ISEN Update Information - Widget
.
Naming Card Layouts
For card layouts, we recommend entering a Label
in title case and Card Layout Name
in Pascal case with the format:
[parameter 1] & [parameter 2] & [parameter n]
Specifically, list each field that is enabled in the card layout, separated by ampersands. Only 40 characters are allowed, however, so you may need to shorten the field name by only calling out the first word of the field or rewriting the field name.
For example, ISEN has a card layout with the following fields enabled:
Escape HTML
First Field as Heading
Group Cards
Striped Rows
Entering the full parameter names does not fit, so it can be named No HTML & First Field & Group & Striped
.
Pascal case excludes special characters, so the ampersands should only be included in the Label
, not in the Card Layout Name
.
If a field is disabled, that may be just as important to indicate in the card layout's name. For example, if Escape HTML
is not selected, you can include Display HTML
in the name.
Naming Data Sources
We recommend naming data sources in title case with the format:
[association acronym] [descriptor, including object name if applicable]
Specifically, for [descriptor], describe briefly and simply what data is being fetched by the data source's corresponding flow or query, in title case. Use spaces but avoid special characters because most of them are not allowed. For example, for ISEN:
- They have a data source linked to a query that queries business accounts created last week, so they named their query
New Business Accounts Last Week
. - They have a data source linked to a flow that collects all past registrations for the current account in Community Hub, so they named their query
ISEN Past Registrations Current Account
.
The maximum length for data source names is 40 characters. If you're hitting the limit, write a condensed version of the name that still clearly distinguishes the data source from others. For example, ISEN went for ISEN Past Registrations Current Account
instead of ISEN Past Registrations for Current Account
because it exceeded the limit. If they needed to buy even more space, they could have shortened words like changing Account
to Acct
or Registrations
to Reg
.
Naming Buttons
The button's name should clearly indicate its purpose. The recommended way to name a button depends on whether you are cloning a Nimble AMS button or creating a new button from scratch.
Naming a Cloned Button
If you are cloning a Nimble AMS button and the default name clearly indicates the way you will use the cloned button, we recommend naming it in title case with the format:
[association acronym] [Nimble AMS button name]
In other words, preserve the name of the Nimble AMS button and simply prefix it with your Association's acronym.
Naming a New Button
Alternatively, if you are creating a new button that is not based on a Nimble AMS button, we recommend naming it in title case with the format:
[association acronym] [button label] [additional context, if applicable]
Specifically:
- For [button label], enter the value of the custom label specified in the button's
Label
. In other words, enter the words that appear on the button in Community Hub. For [additional context], enter more information about where the button is used if there is more than one button in Community Hub with the same label.
The button name can only contain spaces, underscores and alphanumeric characters.
For example, ISEN has multiple buttons labeled "Submit." One of these is a button for submitting a new widget record, so it can be named ISEN Submit New Widget
.
Naming Button Menus
We recommend naming button menus in title case with the format:
[card name] Button Menu
Specifically, for [card name], enter the name of the card where the button menu exists.
If the button menu is used on multiple cards, you can use a name that broadens the scope, such as a page name or an area of Community Hub.
Naming Access Controls
We recommend naming access controls in title case with the format:
[association acronym] [object name, if applicable] [component name]
Specifically:
- For [object], enter the object name if the selected class reference an object. For example, the
QueryConditional
class references a specific object whereas theAccountConditional
class always references Accounts. For [component name], enter the metadata record you selected for the class. For example, if you selected the
AccountConditional
class, enter the accountField Name
. If you selected theBusinessRuleConditional
class, enter theBusiness Rule Name
.If the component name alone is not clear enough, you can include additional words to make the purpose of the access control clearer. For example, ISEN has an
AccountConditional
access control that uses the Anonymized field, so it can be named ISENAccount Is Anonymized
.The maximum length for access control names is 40 characters, so you cannot always include the entire component name. In these cases, write a condensed version of the component name that still clearly distinguishes the access control from others.
Descriptions
The component Description
can be used to provide more context about why the component exists and how and where it should be used. We recommend always providing a description.
The Description
is a long text area field. Since it is not a rich text field, we recommend consistently using the following basic formatting standards when writing descriptions:
- Write text in paragraph format. Insert an empty line—that is, two line breaks—between paragraphs.
- Treat a list as if it was a paragraph. In other words, insert an empty line—that is, two line breaks—before and after unordered or ordered lists.
- To indicate the beginning of each list item in an unordered list, use a hyphen followed by a space.
- For example:
- This is an unordered list item.
- For example:
- To indicate the beginning of each list item in an ordered list, use a sequential number following by a period and a space.
- For example:
1. This is the first list item in an ordered list.
- For example: