Before you create templates for your application, you need to determine which configuration settings are to be centrally managed by the Configuration Manager. The most simple solution is to create templates containing every possible configuration setting, but this approach may create an unnecessary amount of work and often results in settings being displayed by the Configuration Manager that are never used.
Which settings to choose while creating templates depends heavily on the application in question, but the following list may provide some guidelines which settings to use:
Settings that deal with security.
Settings that deal with lockdown.
Settings that reference resources, such as hosts, ports, URLs, paths, and so on.
Settings that are used to define corporate identity, such as fonts or colors
The concrete names of the categories and pages are completely up the template developer. There are only two rules to obey:
The names must be unique for every level in the tree so that a unique path can be created, and
The first category must uniquely identify the application and its
version, for example, “
StarOffice 6.0” .
Choosing an apt:section element or an apt:page element should depend on the following two requirements: You should try to avoid scrolling in the Content Area by restricting the amount of configuration items per page to no more than six. If you are mapping an already existing GUI to the Configuration Manager GUI, you should try to map the application GUI to the Configuration Manager GUI as precisely as possible to optimize usability by recognition. If these two requirements contradict, choose the latter one. If you are considering a deviation in the Configuration Manager GUI from an application GUI, it should be a small one.
Every text displayed on the GUI should present a consistent look. Apply the following capitalization guidelines for text that appears in GUI design elements:
Use sentence capitalization for the inline help and the online help. Capitalize only the first word of each sentence, unless the text contains proper nouns, abbreviations, or acronyms that are always capitalized.
Observe proper punctuation within and at the end of full sentences.
Avoid the use of long phrases that are not full sentences. If you must use a phrase that is not a full sentence, no punctuation is required at the end.
Use headline capitalization for labels, titles, checkbox text, menu and list items. To apply headline capitalization, capitalize every word except articles ("a", "an", and "the"), coordinating conjunctions (for example, "and", "or", "but", "so", "yet", and "nor"), and prepositions with fewer than four letters (such as "in"). The first and last words are always capitalized, regardless of what they are.
A label should not be concluded with a semicolon.
Be consistent within your application.
In general, the packages are self-contained. There are only two exceptions: You can reuse resources of other packages (see Localization) and you can reuse chooser definitions of other packages with the apt:extendsChooser attribute (see Basic Data Elements: property, value, constraints). Use this kind of references sparsely and deliberately. References to other packages introduce a dependency to that package and you cannot guarantee that every installation of the Configuration Manager contains the packages that you depend on.
As the Configuration Manager potentially scans every installed package for resource recovery, every resource key should be unique - not only inside your package, but also compared to the other packages. Either use the category hierarchy to prefix the local resource key or create your own hierarchical prefix, for example, by using a structure akin to the Java package structure or by using your product name.
The online help should be designed akin to the HTML files already provided in the standard packages. Include the following lines to allow for proper browser detection and CCS definitions:
Use the styles "help-header-1", "help-header-2" and "help-header-3" for title layout.