User interface objects
Guidelines for designing the user interface objects cover guidelines for designing forms, fields, menus, and views.
This section provides guidelines for designing forms.
This section provides the naming convention followed for form names.
When extending BMC Remedy ITSM applications, use the standards provided here to define a system code and form code that is unique. This helps to distinguish which code is standard out-of-the-box workflow and which is specific to you. Also, in a multitenant environment, this can help distinguish code that belongs to particular tenants.
Form name format
All form names must be unique. The standard format for a form name is as follows:
System Code:Form Name Description
Use the following information to generate form names for all types of form usages (for example, regular, join, dialog, console):
- System Code — Forms within a system are prefixed with an uppercase letter code. This prefix is used to distinguish the system's forms and must contain uppercase letters. Always use a colon to separate the prefix code from the remainder of the form name. For example, AST: is used to represent the BMC Asset Management application, and CHG: is used to represent the BMC Change Management application.
Form Name Description — The remainder of the form name should be an informative text string that reflects the purpose of the form. This string should use CamelCase notation, which is a mixture of uppercase and lowercase letters with each distinct word beginning with an uppercase letter followed by lowercase characters and no spaces between words. The first part of the name can be used to group forms to define a subsystem or component.
Example form names
In this descriptive part of the name, do not include words that describe the form's intent, such as join or dialog.
Form web alias — The web alias is based on the form name and follows CamelCase notation. Characters such as a colon and spaces are not permitted.
Example form web aliases
Form web alias
Form code — Every form in an application should have an associated form code. This form code is composed of three uppercase letters. The form code is used in the creation of active link, filter, escalation, guide, and menu names.
Example form codes
Example form name
CHG: Infrastructure Change
For more information about the purpose of join forms, see .
For join forms, use the same label, database name, and field IDs as the fields on the parent forms of the join, unless there is a reason not to do so. For example, if the same field ID from the primary and secondary forms is being included in the join form, the field from the secondary form should be assigned a new field ID. The form code prefix followed by an underscore is added to the database field name. Conforming to this convention allows for easy duplication of code from parent forms and facilitates the administration and maintenance of these forms.
Join form fields
Database field name
CTM:Site Company Association
CTM:Site Alias LookUp
CTM:Site Alias Company LookUp
Site ID (from Primary form)
CTM:Site Alias Company LookUp
STL_Site ID (from Secondary form)
New field ID generated
Use reference images on BMC Remedy ITSM forms to avoid embedding images
The Image Objects server object type is available with BMC Remedy Developer Studio, and it provides the following functionality:
- More efficient handling of images in applications
- Store images only once in the BMC Remedy AR System server database
- Reference images by name instead of embedding the binary image contents in display properties and display instances of views and fields, which results in a smaller server cache memory footprint
When you attach images to the forms and to the objects in the form, attach them to a reference image and not an embedded image.
To use reference images
- Have the image on your system.
- Create a new image object in BMC Remedy AR System by using BMC Remedy Developer Studio.
- Provide a description for the image object.
- Save the image object with a name.
- Add the image to an object.
For example, to add an image to a button, go to the properties of the button and select image. You are prompted to select the image. By default, the image type is set as Image Reference, which is the correct setting.
- Click Select and select images and set them from the image objects list.
This section provides guidelines for designing fields.
Choose field names that are informative and reflect the purpose of the field. A form with fields that are organized and well-named is easier for administrators to maintain and end users to follow.
General database field names
For all general database fields, create names that are distinct and informative. Use CamelCase notation for the names, which is a mixture of uppercase and lowercase letters with each distinct word beginning with an uppercase letter followed by lowercase letters and no space between words. When possible, make database field names the same as label names, but without spaces. Do not use special characters in database field names.
Use database field names that can help indicate that they are extension attributes.
For the steps to create or manage fields, see .
A label is the name associated with a field that the end user sees when navigating through forms.
If a field has any functionality associated with it, place a plus sign at the end of the label. For example, a user presses Return in a given field and other fields on the form become auto-populated with information. A plus sign at the end of the label reminds the user that hidden functionality exists for certain fields. Do not include spaces at the end of a label.
If a field is required, place an asterisk sign at the end of the label.
Be consistent when creating names.
Appearance of label
Bold label with an asterisk (*)
The field is required to submit and update the form.
Any label, bold or not bold, with a plus sign (+)
The field has functionality associated with it. For example, if the user presses Return in this field, a search dialog box or a search based on the value typed into the field could be displayed. If the label has both an asterisk and a plus sign, BMC uses the following order: label name followed by *+.
Label not bold
The field is optional.
The field is a system field generated by BMC Remedy AR System. These fields are usually read-only and are automatically populated by the system.
Display-only and global fields
Display-only fields are non-database fields. Begin these fields with z1D, followed by an underscore, either the field name or function for a specific field or field type, and a two-digit number for generic field usage. This convention groups all hidden display-only (or temporary) fields together for manageability and to facilitate field lookups.
Begin global fields with z1G, followed by an underscore and the field name or function. z1G_Global_SandBoxEnabled is an example of a global field and it is used to determine if the Sandbox data set is enabled in the Asset Inventory component. This is a global setting that can be referenced in workflow by looking at the data stored in this field.
Display-only field name guidelines
A display-only (specific use) field is a temporary field that is created to store the data for one specific variable. For example, if you need to store the Customer Login ID for future reference in workflow, you could create a temporary field called z1D_Customer_CorporateID.
A display-only (general use) field is a temporary field that is created to store data for a defined workflow set. Display-only (general use) fields can be overwritten by other workflow sets, which means that you should not store data in this field if you need to reference it for future workflow needs. These fields are typically named in a generic fashion. An example of a display-only (general use) field is z1D_Char01, which is a temporary field used to store character data that will be referenced in workflow for a defined workflow set.
Field name prefix (database and label are the same)
Display-only (specific use)
Display-only (general use)
Fields on display-only forms and attachment pools are considered non-database fields and should be prefixed with z1D. However, if a display-only form such as a console or search dialog box contains general database fields, use the field ID, database name, and label already registered — for example, the Company Name field.
Placeholder fields include page holders, page fields, table fields, and attachment fields. Begin the database name of these fields with a lowercase z2, followed by the type of placeholder field being created, an underscore, and then the placeholder field name in CamelCase notation. The first part of the name can be used to group forms to define a subsystem or component. If there is a label, it has no prefix, and fieldName should have spaces if it is visible.
Placeholder field names
Database field name prefix
Page Holder field
Table (Holder) field
Table (Column) field
Label name of field
Control fields include buttons and navigation fields. Begin buttons with a lowercase z3, followed by the type of control field being created, an underscore character, and then the control field name in CamelCase notation. The label has no prefix, and fieldName should have spaces.
Navigation fields (vertical navigation bar and horizontal navigation bar) begin with z2N, followed by the type of navigation field being created, an underscore character, and then the control field name in CamelCase notation. The label has no prefix, and fieldname should have spaces.
Control field names
Database field name prefix
Navigation menu item
For information about the purpose of trim fields, see .
Trim fields include text, lines, and boxes. Begin these fields with a lowercase z5, followed by the type of trim field being created, an underscore character, and then the trim field name in CamelCase notation. Where applicable, the label has no prefix, and the field name should have spaces and a & symbol before the hot key accelerator or separator symbols. This naming convention groups all trim-only fields together for manageability and to facilitate field lookups. Text fields are primarily used out of the different trim fields listed in the preceding table. Some consoles contain a box field around the navigation area and above tables.
Trim field names
Database field name prefix
Menu item (Toolbar)
fieldName and & for a hot key
Field help text
Help text is a requirement for all fields but especially for those that have a special meaning or use. These fields are often not visible but they are used in workflow. Always complete the Help text field in the Help text tab of these individual field properties. Make the Help text informative, and include details on any specific functionality associated with the field. Also, note any escalations that might be triggered on the given field.
Field identification numbers
Field identification numbers (field IDs) should be numbered within the designated range for manageability and maintainability. If a field is in multiple forms, it must use the same ID, database name, and label in all locations. This consistency makes it easier to maintain and enhance applications.
Any field IDs that you add should not be within the BMC reserved field ranges. For more information, see .
This section provides guidelines for designing menus.
This section details the naming conventions for menus.
The following different types of menus are available for use:
- Data Dictionary
Query, SQL, and data dictionary menus
Query, SQL, and data dictionary menus are named according to the data they retrieve. Use the example provided in the following section as a reference when creating these menu names.
Query, SQL, and data dictionary menu naming convention
The standard format for a query, SQL, and data dictionary menu is as follows: System Code:Form Code:Description
Query, SQL, and data dictionary menu name format
System code that uses two to six uppercase letters
Actual form code of the form from which the data is being retrieved. If a form code cannot be supplied (for example, a data dictionary menu that is using a field), use DD0 (zero) for the code. The form code is optional but must be consistent within applications and application suites.
Describes the type of lookup performed by the menu. Use CamelCase notation, which is a mixture of uppercase and lowercase letters with each distinct word beginning with an uppercase letter followed by lowercase characters and no spaces between words.
Character and file menus
Character and file menus are named according to the type of data that they contain. Use the example provided in the following section as a reference when creating these menu names. If a character or file menu is used by several systems, use the SHR:SHR: prefix for the system and form code. In such cases, the form code is not optional.
Character and file menu naming convention
The standard format for a character or file menu is as follows: System Code:Form Code:Description
Character and file menu name format
System code that uses two to six uppercase letters. If a menu is used by several systems, use SHR.
Form code of the form where the menu is to be used. If it is used by more than one form, use SHR. The form code is optional, but it must be consistent within applications and application suites.
Describes the type of information contained in the menu. Use CamelCase notation.
Choose the type of menu and refresh options that you implement carefully, with the following considerations:
- If possible, do not create SQL menus. Although SQL menus retrieve information more quickly than search menus, they are not as portable between databases and as easy to maintain.
- Minimize or eliminate the use of character and file menus. Every time a character menu is updated, the client cache refreshes the next time any user of the system loads a form that uses the updated menu. If the character menu is large, this could cause a performance impact.
- Use the $MENU$ pattern matching function of BMC Remedy AR System only with character menus. Using this function with search menus can cause inconsistent behavior.
This section provides guidelines for designing views.
Views across all forms must have consistent names, labels, web aliases, and view ID values.
View user interface (VUI) IDs must have a range specified per view locale. The default locale is en-US, and this is left blank in all default views.
Example of view attributes
Blank for default
Blank for default
View aliases and labels
A view alias is the name that is seen by the end users for forms that are directly exposed, like consoles. Aliases can be assigned to each view. Assign alias values that are, where possible, similar to the form name following the system code. For example, if a console has a form name of AST:AssetManager, the various alias values for singular, plural, short singular, and short plural would be Asset Manager. If a form has multiple views, assign appropriate alias names that reflect the form name, if possible.
View labels can be assigned to each view for the new and search entry points, and are required only on forms that have entry points enabled. If such labels are assigned values and the entry points are enabled, the label content is shown in preference to the form name.
Example of view aliases and labels
Console Default User View