Name databases so that URLs are easy to remember

Meaningful and non-cryptic URLs are easier to remember and less likely to be mistyped by users. When you create an application, use simple and meaningful titles and filenames. Filenames like the following are easier to remember:

Using a consistent directory structure will also make URLs easier to use:

Use standard versioning for design templates

It is good practice to archive a copy of the current production design template before beginning to modify that design. If code management tools are installed in your organization, use them and adhere to local development standards. However, if you are on your own to handle your design templates, then use a consistent procedure for managing them. For example, archive templates in an organized fashion in a restricted location on a server that is routinely backed up to an offsite location.

Keep copies of the previous design(s). There will be times when you will want to review how something was done before you changed it. And in the case of a major problem with the new design, it may be required to reapply the old design to the staging or production databases.

A simple naming strategy adds a version number to the title and to the filename of a new template and a new development database. This version identifier should be recorded with the design's release notes, perhaps in the application's About document.

In this example, the application is entitled "ABC Change Management". Using a specific versioning scheme, the following titles and files might exist. (Files with the ntf extension are templates; files with the nsf extension are applications).

The current and some previous design templates may be stored on the development server. By way of illustration, here is a set of templates; the application titles are followed by the filenames (title / file name):

ABC Change Management 2.3 Template / ABCChangeManagement23.ntf

ABC Change Management 2.4 Template / ABCChangeManagement24.ntf

ABC Change Management 2.5 Template / ABCChangeManagement25.ntf

ABC Change Management 2.6 Template / ABCChangeManagement26.ntf

Also on the development server, one or two test databases might exist; the database filenames are matched easily with the associated templates. Consistency in naming is important:

ABC Change Management 2.5 / ABCChangeManagement25.nsf

ABC Change Management 2.6 / ABCChangeManagement26.nsf

When a design moves from a development server to a staging server where the users will test the application, the version identifier should be removed. This enables a user to establish a single URL bookmark that will still work even as the design is upgraded.

ABC Change Management / ABCChangeManagement.nsf

On the production server, the title, directory, and filename mirror those on the staging server. Again, this scheme simplifies a user's transition from testing to production.

ABC Change Management / ABCChangeManagement.nsf

The template from the development server is applied to the existing database on the staging server. After user acceptance testing is complete, the template is then applied to the production server. If for any reason the application's design must be rolled back, the previous design template is still available on the development server.

This example is intended to illustrate how templates can be easily versioned. Other factors should be taken into account when setting up your code management practice.

Keep in mind that design elements on the development server are signed by the developer who last updates them. Designs migrated to staging and production servers are generally signed with a specific organizational signing ID by the Domino administrator. It is not a good practice for users to run code signed by developers.

Use standard versioning for major design elements

Enhancing an existing application generally means changing one or more major design elements, perhaps a form or view or an agent. In addition to versioning the design template, developers should consider versioning design elements within a template.

A simple versioning strategy for major design elements would include the following steps:

Set most of these attributes on the Info tab of Properties. For a form, here's what it might look like:

To hide a design element, follow these steps:

In this example, the Customer form was versioned. It was last changed on September 25, 2009. The old form is hidden from all clients, while the new form is available on the Web. A comment indicates that the old form can be deleted in the future:

Use unique names for all major design elements

If two major design elements share a common name, Domino may select the wrong element, leading to incorrect and confusing results.

In the following example, a view and a form are each named XML1. The intent of the URL is to link to an attachment stored in a document.

Opening the document from the XML1 view was successful, but then opening the attachment in that document was unsuccessful: http://server/path/database.nsf/XML1/document-unid/$file/filename.ext.

The browser displayed an error message: HTTP 500.

The Domino log entry contained an error message: HTTP Web Server: Lotus Notes Exception Note Item not Found.

Changing the name of the view to XML1vw solved the problem: http://server/path/database.nsf/XML1vw/document-unid/$file/filename.ext.

Uniquely naming all major design elements will avoid some rather obscure problems.

Create different versions of design elements for Notes and the Web

At one time it was estimated that 70-80% of Notes functionality translated well to the Web. Personally, I think that estimate is a bit high, especially for earlier versions of Domino. Design elements (forms, pages, views) can be crafted to look reasonably good both in the Notes client and in web browsers, but at some point, particularly with regard to styling, you simply cannot achieve what you want to achieve with a single dual-purpose design element. When HTML, CSS, and JavaScript are fully supported by the Notes client, this issue may become moot. Until then you may want to develop two versions of a design element, one for Notes and one for the Web, to achieve the results you desire.

Beyond styling, other issues should be considered, such as:

Simply create two forms (or views, and so on) with the same name. Use Design Properties to hide one form from Notes and the other from web browsers. In this example, two forms share the same name. Comments remind us which form is for the Web and which is for Notes:

You may be tempted to complete a development task for Notes, which is often the simpler environment to develop within, and then to see how the design works on the Web. I would recommend working both sets of enhancements more or less at the same time.

For example, if you have several forms and views to update, start with one form and make sure that it works well in both environments. You may find that some of your basic assumptions about how a feature will translate to the Web just don't work out. Lessons learned earlier in a project can shorten the development effort for similar design elements later on.

Name Domino groups and roles appropriately

Domino groups are defined in the Domino directory. Each group contains a list of Notes IDs. When a group name is added to an application's ACL, individuals included in the group are permitted access to the application; privileges group members receive are also defined in the ACL. Creating a group is a task for the Domino administrator. Naming that group may be a task for you, the developer.

Consider defining unique Domino groups for each application or suite of related applications. Use names that can be readily identified with the application they support. Use a consistent naming convention. For a "Help Desk" application, the following names might be appropriate:

Use the Comments field in a Domino Directory group document to provide more information about the use of the group, especially which applications use it:

Document the groups associated with an application in the application's About or Using documents. Down the road there will be fewer questions about which groups belong to which applications.