Component standards provide guidelines for naming and configuring metadata in Staff View and Community Hub. Components include, but are not limited to, apps, fields, list views, page layouts, search layouts, as well as Community Hub components such as cards and pages.
Adherence to component standards in Nimble AMS ensures a clear, efficient, consistent, and beautiful user experience. Administrators can refer to these standards when creating or editing components in Staff View or Community Hub to ensure both staff and constituents have a great user experience.
These standards prioritize competing design principles to ensure that an effective user experience is clearly defined and consistently configured throughout Nimble AMS.
The variety of interfaces makes adherence to standards very important. For example, if Maria Gomez, a membership staff user, is looking for a specific membership record, she has several ways to find and view it:
- A global search displays the membership in the Search Results search layout.
- The Memberships tab displays the membership in the Tab search layout and in list views.
- The related account record displays the membership in the Memberships related list.
A well-configured org consistently displays the same fields, in the same order, in all of these layouts. Regardless of the method Maria uses to access a membership record, she experiences a concise, familiar user experience.
Administrators also benefit from an org that adheres to component standards because it is easier to maintain components which have been clearly and consistently named and configured.
The standards for Nimble AMS components are guided by the four Salesforce design principles, which are, by order of importance: (1) Clarity, (2) Efficiency, (3) Consistency, and (4) Beauty.
How it Applies to Nimble AMS
Name components clearly. In layouts, include fields that most clearly identify a record.
|2||Efficiency||Keep names brief to minimize reading without sacrificing clarity. In layouts, rank fields by importance to reduce clicks.|
Configure components within an object as similarly as possible. Globally, configure components across all objects as similarly as possible. Consistency cannot sacrifice clarity nor efficiency.
Generally, the Salesforce platform or the Community Hub theme determines the final presentation of the user interface, but some components can be configured to be more visually pleasing.
Many components require a label and/or name. Nimble AMS uses the title case and Pascal case styles to name components.
Use title case for names and labels if the space character is allowed. Otherwise, use Pascal case.
When creating and editing components, some name fields are automatically populated with values that do not conform to these naming standards and therefore need to be manually corrected. For example, when creating an object where
Object Name is automatically populated with the value
Chapter_Membership, which is neither title case nor Pascal case.
Title case uses a space delimiter between words and capitalizes most words. For example: Year of Graduation.
- Nouns, pronouns, adjectives, verbs, and adverbs
- The first and last words, no matter what the words are
- The second element of a hyphenated compound. For example: Third-Party Software
- Prepositions that are part of a verb. For example: Log In
- Articles (a, an, the) and prepositions that are not part of a verb
- The to in an infinitive. For example: Modules to Complete
- Retain the capitalization of abbreviations and names. For example: pH Value; iPhone
Pascal case uses no delimiters between words and it capitalizes all words. For example: YearOfGraduation.
All words, including the first letter of names that start with a standalone lowercase letter. For example: IPhone
Acronyms, including the first letter of acronyms that start with a lowercase letter. For example: PHValue; NimbleAMSMembership
Some component names cannot start with a numerical character. Consider changing the number to its text equivalent. For example, instead of 1stDonationDate use FirstDonationDate.
Alternatively, change the order of the words. For example, instead of 401kApplicationDate use ApplicationDate401k.
Omit special characters such as ampersands (&). For example, the conversion of
All AV & Tech from title case to Pascal case is
App standards provide guidelines for naming and configuring apps, including recommendations on selecting and sequencing tabs, also referred to as items.
Community Hub Component Standards
Community Hub component standards provide guidelines for naming and describing Community Hub components such as access controls, buttons, cards, card layouts, data sources, and pages.
Custom Label Standards
Custom label standards provide guidelines for whether you should create custom labels or edit/override existing custom labels. It also provides standards on clearly naming new custom labels. Custom labels are primarily used for messages, heading text, and description text on pages and cards in Community Hub.
Field and Field Set Standards
Field and field set standards provide guidelines for naming fields, specifying field help text and descriptions, configuring field history tracking, and naming field sets.
Layout standards provide guidelines for naming and configuring compact layouts, list views, page layouts, and search layouts. Layouts should contain the most important fields for the record. Since some layouts cannot always display all the fields included in the layout, it is important that administrators use a standard approach for selecting the sequence of fields.
Object standards provide guidelines for naming and configuring custom objects. This includes recommendations on naming the object and its records, enabling object features, and enabling Chatter Feed Tracking.
Permission Set Standards
Permission set standards provide guidelines for naming and configuring permission sets. It can be difficult to tell at a glance what a permission set grants, so it is important to write clear names and descriptions to identify a permission set's purpose and scope.
Record Page Standards
Record page standards provide guidelines for when to create new record pages and how to name them. They also provide guidelines for selecting a template and organizing Lightning components.
Report and Dashboard Standards
Report and dashboard standards provide guidelines for naming and describing report folders, dashboard folders, reports, and dashboards.
Query standards provide guidelines for naming queries in a clear and consistent way.