Before approaching customization, it is important to clarify exactly why the customization is being undertaken. For example, to add corporate branding, you can use the Modify Layout Samples to do so. Or to change security features, you can use components to modify the default security settings.
Customization often occurs to make the Content Server match the business practices of an organization. Often, after evaluating your business processes, you may find that sometimes it is more efficient to slightly alter your procedures before customizing the Content Server.
There are six major stages in customization:
Determine why you want to customize. Is there corporate personalization to be done? Is there a better way to present navigation options or material? Depending on what type of need you find, you can determine which tools are best to use.
Oftentimes the cosmetic details that you change are the ones that can most satisfy your users; changing items such as layout, colors, and images often provide the effect that users are looking for.
Plan the customization carefully, taking into account those aspects of the Content Server environment that might be changed even peripherally by the customization. All customization should be done in a test environment, separate from the site's production environment.
Check to see if a solution may be available. The Samples on the Support Web site contain many types of customization. It's possible that there may be an existing component that can be used with just a little editing. A number of 'samples' are provided on an as-is basis. These are components or files that demonstrate, enhance or extend the functionality of your Content Server products.
Evaluate the problem and how essential it is to solve. Some problems may require more effort to fix than will provide payback. Perhaps customization is not needed, but simply a minor change in business practices.
Test the customization thoroughly in a separate environment. If possible, have end users assist with the testing. When the testing has passed all criteria for release, inform users about the changes and how to implement them.
Document the customization that you create. All alterations should be documented as completely as possible, both within the actual customization (for example, as a comment in a dynamic server page or in a component) and as a separate README document. This provides an historical audit trail for others who may need to add to the customization later.