Standardizing applications

Application development is part engineering and part art. Building some pieces of an application is fairly routine, while other aspects call for inventiveness and creativity.

Domino caters to developers to some extent by enabling applications to be built with any of the several programming languages. It also supports many web technologies which can be pieced together in an unlimited number of ways. This flexibility enables programmers to work the way they want to work. But this same flexibility makes it all too easy to ignore organizational standards.

Standardizing applications makes it easier to develop new ones since reusable components may already exist. And if applications look and operate in a similar manner, then users of new applications will need less training and will be more willing to use them.

Abide by your organization's web development guidelines

If your organization has written web development guidelines, find out what they are and try to embrace them in your own applications. The set of web applications deployed by your organization is probably much larger than just the Domino applications. If they exist, these development guidelines and standards define stylistic and functional commonality that your organization determined to be beneficial. Someone above your pay grade approved those standards, so abide by them!

Web application development guidelines can provide several benefits. They promote an organizational identity or brand through a common look and feel. They improve the effectiveness and the usability of web applications as a whole by standardizing how features and functions operate. And from a developer's point of view, they speed the deployment of new applications and simplify the maintenance and enhancement of existing ones.

If your organization has no written standards, consider discussing this issue with management. Consider taking on the task yourself.

The number of specific development standards can easily number in the hundreds, depending upon how detailed they are. Whoever determines these standards must understand to some extent the entire universe of options, and then must select those guidelines which make sense and which can be implemented within the existing development environment. Many guidelines turn out to be "nice to have" suggestions that are not practical to implement within the confines of budget and project deadlines.

Development guidelines can be classified roughly into three kinds:

• Usability guidelines

• Stylistic guidelines

• Mechanical or process guidelines

Usability

Guidelines that address the usability of an application or website concern themselves with issues of effectiveness, efficiency, learnability, and overall user satisfaction. How well does this application achieve its goals? How easy is it to learn to use? How well do users like it? Usability influences how willing people are to use an application, which can have a dramatic impact on whether they choose your solution or go somewhere else for assistance.

Usability guidelines focus on what things make a website easy to use from the end user's point of view. Examples of usability considerations include the following:

• Content organization

• Headings and labels

• Page and form layout

• Features and functions

• Accessibility

• Navigation

• Images

Explore this topic in greater detail. One online reference which you might consider reviewing is the http://usability.gov website maintained by the U.S. Department of Health and Human Services.

The Guidelines documents at this site were written based on the extensive research. They can serve as a good starting point for understanding usability issues.

Style

Guidelines which address style concern themselves with issues of look and feel, and sometimes function. An organization's font preferences and color palette can be identified. Layouts and menu styles can be defined. Acceptable logos and images can be specified, as can boilerplate text for Copyright, Privacy, and other notices. Very specific guidelines might address issues such as whether or not to underline links or how wide margins should be.

Beyond simply specifying preferences, an organization might codify style requirements into common style sheets. The guidelines would then provide information about how to link to and incorporate those style sheets into applications. Details such as style class names for headings and labels would be included.

Mechanics and process

Guidelines which address issues of coding and application deployment can be extensive and no small task to gather together.

Because Domino web applications can include so many different technologies, coding guidelines could address various options, including the use of these design tools:

• HTML

• CSS

• JavaScript and JavaScript frameworks

• LotusScript

• Java

• Images

Other guidelines might specify requirements for the following design aspects:

• The About and Using documents

• Element naming conventions

• Form and page layout

• Navigation

• E-mail notifications

• Data import and extract

• Context sensitive help

• Agent error handling

• Security and access control

Still other guidelines might concern themselves with the general way in which applications are designed, tested, and rolled into production:

• How development work is requested and prioritized

• How applications are named and sponsored

• The use of templates

• The use of shared code and resource libraries

• The use of roles

• The use and management of Domino groups

• Application signing

• Replication

• Testing and approval

• Migration to production

• Documentation and user training

Some developers might find coding and process guidelines to be onerous and overly constraining. Inevitably, there will be requests for exceptions to the rules, so organizations must be prepared to deal with the issues of exceptions and non-compliance.

Clearly, an extensive effort is required to compile standards and guidelines that are appropriate to application development within the context of a specific organization. Additional effort will be required periodically to review, update, and reapprove those guidelines.

Create libraries of common resources

Organizations should consider creating common repositories of reusable objects. The most obvious kinds of libraries (not surprisingly supported natively by Designer) would contain standard design elements such as:

• Images

• Java code

• JavaScript code

• LotusScript code

• Style sheets

Images can be organized into common types as follows:

• Arrows and lines

• Banners and logos

• Buttons

• Patterns

• Photos

• Squares and other common shapes

• Watermarks

Other repositories might include standard or approved "boilerplate" text:

• Copyright notice

• Disclaimers and caveats

• Error messages

• Privacy notice

Common repositories enable developers to work more rapidly and to create products which conform to organizational standards. Organizational management must address the following issues:

• Who will create and maintain the repositories?

• What process will be used to approve, add, and deprecate repository objects?

• Will applications be reviewed to assure the use of the approved objects?

• How will developers (especially new developers) be informed about the repositories and how to use them?

Common repositories, like development standards in general, can seriously boost productivity, but they also require ongoing maintenance and commitment. If your organization has such repositories, learn to use them. If no such collections yet exist, speak to management about instituting common repositories for approved design resources.