
Planning the design
Time spent planning means less time spent debugging and reworking the application later on. Resist the "newbie" tendency to jump right to the programming. Take some time to think, to write, to plan.
Identify your key user contacts and strike up relationships. Your customers will clarify their requirements, offer suggestions, and weigh in on decisions about the design. They will approach and test the application from different perspectives, which will highlight issues you had not considered.
Understand the scope of the project
From the requirements that you have, determine what kind of project this is. Are you changing the design of an existing application? Web-enabling an application? Or crafting an entirely new design? The answer to this question will in part tell you how much planning effort is required; the larger the task, the more planning that should be done.
Classify the project and its requirements. Here is a straight-forward taxonomy:
- Bug fixes
- Modifications to existing features
- Feature addition or removal
- Web-enablement
- New design
Decompose each requirement into one or more units of work. A unit of work may be quite limited, such as adding a field to a form, or more complex such as revising the way an application's search process works. It helps to think about each unit of work as a feature or change involving one or more design elements. Subdividing requirements this way helps to focus on one issue at a time.
How many changes are there? While you are assessing the requirements, set about discovering the application. For each requirement, investigate which major design elements are likely to be involved and what needs to be changed. Think about the order in which you might handle each item; are there any dependencies? Think about how you might test each change to assure that it does what it is supposed to do. Take notes.
Annotate the requirements document
It can be very helpful to restate and clarify each user requirement in a new working document, your developer notes or the changes document. This annotated requirements document should include the set of tasks you have identified, the design elements that should be reviewed and modified, and the test plan.
If a requirement is extensive, or if the assignment involves designing a new application, your planning must be much more extensive. The following list is intended to illustrate the kinds of questions you should ask:
- How many new forms will there be? Containing what information?
- What new views are required with what columns?
- Upon launch, what will be displayed first?
- How will users navigate between views?
- How will documents be created, edited, or deleted?
- What workflow is required?
- What roles are needed? With what privileges and responsibilities?
- Should security features be modified in some way?
- How will required changes impact other parts of the application?
- Will data in existing documents need updating to support the changes?
- Will users require additional training?
- What types of documentation are required?
Sketch or mock up forms and pages, draw workflow diagrams, make lists of issues, jot down any related notions or concerns. Of course all this writing takes time! But this is the essence of planning, and planning will save you time over the life of the project.
Understand the workflow
The concept of workflow can be difficult to understand, even though all of us routinely participate in workflow whenever we fill out a form or request a service. Volumes have been written about process analysis and modeling, and it is not my intent to do those subjects justice here.
In essence, workflow in a Domino context consists of a set of actions performed on documents by people over a period of time. Documents themselves are often the end product of a workflow process. But a document can also be a record of work that is done external to the application; the state (or status) of a document mirrors the state of the external work.
Work is initiated, assigned, performed, reviewed, and approved or rejected. A workflow application that tracks tasks from initiation to completion will offer some means of identifying the state of the work. It may also generate automated notifications through e-mail and provide reports of one sort or another. How all of this is instantiated in an application is up to the developer.
Here are some questions the answers to which will provide a general understanding of the workflow in (or required of) an application:
- What is the business process which this application's workflow will support?
- Who uses the application? Are there classes of users or actors? What do they do?
- Who originates or composes a document, and why?
- What is the life cycle of a document or task tracked by the application? In what states can a document or task exist (for example, New, Assigned, In Process, Approved, Complete)?
- What are the allowable sequence of states? What states can precede and follow other states? What sequence of states is not allowed?
- What must happen for a document or task to move from one state to another? What triggers a state change? What information must be recorded or who must do what?
- What conditions must exist for a document or task to be considered as complete?
Once you understand the gist of the workflow, drill down for additional information:
- What defined Domino groups are used or required? With what privileges? What roles are assigned? Is anonymous access required?
- What actions do each role and group perform?
- How is the state of a document known? (for example, what status values are used?)
- What agents are involved? Are they scheduled or triggered? What do they do to which documents?
- Are users notified that work has been assigned to them? Is anyone notified when a task is completed? How is this done?
Document your understanding of the application's workflow. Use the language that your customers use; do not use unfamiliar terms or jargon, even if your words are more "correct". Share your notes with your key contacts and ask for verification that the workflow processes work the way you think they do.
Determine the need to access external databases
Find out if the existing application or the new requirements rely upon an external data source to feed data into the Domino application or to receive data from the application. You may need to look into technologies like DECS, LEI, Notrix, Web Services, and so on. You may also need to engage an expert in Oracle, DB2, or some other database technology with which you are unfamiliar. These kinds of issues must be factored into the overall plan.
Decide on one database or several
Probably a large majority of Domino applications consist of one NSF file. But applications exist that consist of more than one NSF file, perhaps a few, perhaps dozens of interoperating and interdependent components. If you are dealing with an existing design, become familiar with the collection of components and how they interoperate. If you are creating a design from scratch, consider how best to organize the features. For example, you might architect an application with these NSF files:
- Main application
- Configuration and keywords database
- Log file
- Archive database
Consider the pros and cons of splitting an application into separate files. For example, an application consisting of several NSF databases may be a bit harder to manage, but it does facilitate multiple developers working in concert on different pieces, and it may actually be simpler to introduce incremental changes since each component is less complicated.
Review existing designs
IBM provides a few ready-made database templates which are usually installed along with Notes and Domino. If you are new to working with templates, this is a good way to practice creating databases with templates. And it is a good way to review the capabilities of some basic out-of-the-box applications.
For the most part, the IBM templates are used to create containers for documents; some, like Team Room, include a bit of workflow. Look at these templates in particular:
- Document Library
- Domino Blog (may be located on a server)
- Personal Journal
- Team Room (may be located on a server)
Which templates are available to you and where they are located depends of course upon your installation.
To create a new instance of an application from a template with the Notes client, open the following dialog through the menu File | Application | New:

To identify the new application, perform the following steps:
- Select the host computer that will house the application (your local workstation or a server).
- Enter a title for the new application.
- Enter a filename (the filename extension has to be
.nsf)
. - Select a target directory or folder.
To identify the source template, perform the following:
- Select a template server.
- Select a template name.
- Click on the OK button.
The new application is created.
You might find suitable or inspiring templates on the Web. One popular site for projects is http://www.openntf.org.
Copy the design of an existing application
Applications already deployed in your organization also can provide you with a design which fits or nearly fits the requirements. Using an existing application design as a starting point for building a similar application can save considerable time and effort. If an existing application might satisfy the majority of customer requirements, consider copying and reviewing that design with an eye towards repurposing it.
Copying a design is relatively straightforward. You must have Editor or higher access rights to the source application. Locate the application and bookmark it. Select the bookmark and open the following dialog using the menu File | Application | New Copy…:

- Select a target server.
- Enter a title for the new application or template.
- Enter a filename (the file extension should be
.nsf
for an application or.ntf
for a template). - Select a target directory or folder.
- Select Application design only.
- Uncheck Access Control List.
- Click on the OK button.
The design of the existing application is extracted and copied into the new "template" file.
There is a downside to repurposing existing designs. Too often unused design elements, features, and code remain in the new template, cluttering it up, and consuming resources. This "developer debris" can linger for years and migrate from design to design, serving no purpose. Future developers will puzzle over these abandoned elements until someone takes the time to delete them. Take some time towards the end of the development cycle to clear out unused elements.
Evaluate the security needs of the application
Domino security is multi-layered. Many options exist to protect the database, the documents, and the design elements within the application. Discuss security concerns and requirements with your customers early in the design phase of the project. In a new design, or a major redesign, building in the necessary controls early in development will save considerable rework later on. Here are some questions that can help to clarify security needs. Some of these questions may have been answered during your assessment of the application's workflow:
- What classes of users will there be? Administrators, editors, authors, readers?
- What privileges and restrictions will apply to each class?
- Are there any features which should be restricted or denied to classes of users?
- Who can create new documents in the database?
- What data should be captured and then never changed?
- Are there any restrictions about who can edit certain fields on forms?
- Are there fields or text on forms which should be hidden from certain users?
- What restrictions are there on who can perform the workflow actions?
- Are there any buttons, menu items, views, reports, or help pages that should be restricted in some way?
These kinds of issues should be discussed early in the project and then reconfirmed during development and testing. Getting security right is very important.