Skip to main content
Skip table of contents

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 the AccountConditional 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 account Field Name. If you selected the BusinessRuleConditional class, enter the Business 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 ISEN Account 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.
  • 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. 
JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.