2.3 Design 

Previous | Next

Domino applications are designed to enable users to collaboratively complete a particular process of a business in a group. For example, product development application for manufacturing industry involves several stages, gates, and activities. These activities are to be performed by several workgroups with each having different level of access and constraints in the process flow. This section provides an overview of design principles for developing Domino applications and suggests ways in which you can apply these principles when you create Domino applications.

Designing a Domino application begins with a business problem in backdrop of the requirement specification document generated through the requirement phase. Then work toward designing a solution that provides a positive user experience and maximizes productivity. The following are certain best practices of obtaining a quality design for Domino applications:

• A design demonstrates an architectural structure of the application to be developed.
• A design has to be modular such that the associated features are coupled as a single unit and logical distinct modules are created.
• A design demonstrates the inter dependency between the modules and the constraints, if any.
• A design describes data structure of the respective modules and the data flow between the modules.
• A design contains the details of interfaces (external and internal) with other systems to simplify the complexity of integration with other system.
• A designer aim of a flexible yet robust design structure for the application to easily adapt to the future improvements during the course of development and lifecycle of the application.
• A design describes the workflow process of the domino application and the details specific the workflow.
• A design contains the details of different roles and the access rights in different modules, and stages of workflow.
• A design describes any limitation, constraints, assumption, or special consideration about the application being developed.

Design specification

The design specification is no less than a bible for the application developer to create an application. The design specification translates the business requirements into the building blocks which would eventually bring life to the application. The design specification has cross references to the requirement document to indicate the application design that satisfies all the requirements. The design specification document should include the following sections:

• Graphic user interface (GUI) design
• Database design
• Module level design
• Workflow process
• Program specifications
• Security procedure design
• Detailed design document

GUI design

The graphic user interface (GUI) section describes the details about the GUI of the application such as screen layouts of different modules and their user interface description. It contains the details about the color themes, font settings, and formats for different components. This GUI design specification specifies the GUI standards to be adhered for the application development by the development team. The user accessibility features include the accelerator keys for action buttons and label fields. This section also should include the special GUI considerations if the multiple platforms portability is required, for example, mobile, web browser, and smart devices.

When designing the GUI for Domino applications, consider the following:

• Always use the CSS or Themes to format the user interface and its layout. Avoid inline styles or markup text for formatting the screen layout and user interface elements.
  This would help implement standard look and feel for your application. It is also a good practice for application user interface maintainability. In case the user interface needs to be revamped, you only need to modify the CSS. 
• Keep the user interface layout simple and uncluttered. If required, divide it into the logical sections, for example, navigation, actions, and application specific sub-sections.
• Avoid using pop-up unless really required to prevent errors caused by the pop-up blocker that does not allow the pop-ups to be launched. Instead, use the div layers to disable the main user interface screen and use the other div layer as top most with the fields and buttons to get the inputs as applicable.
• Avoid using the large size of images to mitigate problem that might caused by the disk space constraint (See 6.7 Graphics for details). 
• Design your GUI with a focus on the target audience device screen resolution for web browser, handheld device, or smartphone.
• Either you set a standard for your application users that the application would be best viewed in particular screen resolution, or design the GUI to support few standard screen resolutions (for example, 800 x 600, 1024 x 768, or 1280 x 1024) for browsers and set similar standards for the smart devices. This standardization for screen resolution or screen size in your application helps to deliver standard GUI to the users.   

Database design

This section describes the high-level overview of how the functionality and responsibilities of the modules are structured and integrated with the various modules. The detail of the module is not described in this section but only the overview the association among the modules. The main purpose of this section is to describe the general understanding of how and why the modules are separated, how the individual components work together as a unit to provide the desired functionality from the application.

The description includes the major functionalities and the various capability of the application in terms of features to be provided. Describe the interrelationship between the different modules and the hierarchy of modules and sub-modules. This section mentions the basis of deciding the design points about the modules along with the approaches that have been rejected and the reasons. In this section, the high-level design model diagram for the application is included.

Many Domino applications consist of a single nsf file. For more complex applications, there might be multiple nsf files which work together to make what appears to the end user to be a single application. At the database design stage, identify the number of databases required. Each separate database in the application should represent a logical entity. For example, the product development application of a manufacturing organization might have the following different databases:

• A master database to store all information related to the product, users, and other configuration parameters
• A product database to manage product development lifecycle
• An error log database to track various errors and background processes of application and so on.

Below is a checklist (not exhaustive) of the factors that lead to the different databases required in a Domino application:

• Complexity of the business processes and interdependencies between the modules. If there seems to be a natural division of the data according to who will use it most and who will maintain it, and if the complexity of the interface between the different parts is low, that suggests separate databases migh make sense.
• If there are several smaller modules which are not inherently complex such as leave management, then a single database is sufficient for the effective functioning of the application.
• The potential number of documents and rate at which the database expected to grow. How many documents are "a lot" varies depending on your hardware and the number of users. But if you expect to be creating thousands of documents a month, you might consider having one or more archive databases, both for better performance and to make it easier for users to create local replicas of just relevant/recent content or search for just desired documents.
• If you think the application will contain a lot of large file attachments, consider a separate attachment repository. Attachments don't have a lot of effect on performance -- number of documents is a much more important factor than total disk space. But users may like to have local replicas, or you might like to create more server replicas, of just the document data, and have just a few server replicas of the attachments, if they are lesser used.
• The performance efficiency expected out of the application for data search and filtration. If the data search and filtration are some of the key drivers of application and database is expected to grow in number of documents and size, a suitable separation of databases should be considered in terms of central and local repositories.  For example, the product development team from North America would deal with a database dedicated for that region and likewise a separate database for Europe and other locations. 
• A centralized repository of all documents or truncated document in a common database for reporting and escalation purpose at global level. You might, for instance, have similar databases each used in a single country, but automatically copy an extract from each of these into a central reporting database.
• The target audience of the application. For example. if there are few modules to be accessed by third party, then such modules are to be hosted on secured access zone behind the firewall. 
• The application expected to be hosted for third party internet users of the organization, For example, the partners and vendors. There are security concerns and legal restriction in terms of data access. A separate database with document available for third party access should be maintained in-line with the organization policy for data access. 
• Other access considerations. If your application contains a significant number of documents that should be visible to one group of users but not to others, you can secure the documents with Readers fields, but this both has performance implications, and is complex to implement with certainty that it has been done correctly. By comparison, putting private documents into a separate database and using the database ACL to limit access, is simple to implement and simple to demonstrate as secure.

Module level design

This section describes the features and functionality details of the individual modules. The purpose of this section is to provide the primary functionality of the module. It details the further specifics to any constraints, design considerations, dependencies, interfaces incoming or outgoing, and exceptions to be managed. The data flow in the module in terms of input and output process of the module is described here. The use cases specific for the individual modules is also defined here.

When working on the module level design for Domino application, consider the following:

• Try to limit the number of views. Too many and too complex views, is the most common factor limiting application performance.
• Try for a balance between the number of forms, and the complexity of each form. It takes a certain amount of experience in Domino development to get a feel for what makes sense to go together in a single document. If two document types are very similar, you can consider combining them. If a single form is huge and contains dozens of hide formulas, optional sections, and hundreds of fields, chances are you're trying to do too much with a single form, and should consider a main document and responses instead.
• Make use of common functions and reusable script libraries to provide the interfaces between the modules.
• Avoid duplicating the data across modules.
  For example, in a product development application, product related information and the related process to maintain it are better managed in one module and the reference view lookup or back-end script should be used to integrate the product data in the other modules.  However, there are tradeoffs here. If you have another application store only the product ID when it refers to a product, then whenever users use that form, either they only see the product ID and have to click on something to find out what product it represents, or the application has to do a live lookup with the product ID as key, to display the product name and other information. There's nothing wrong with that, but it has limitations: the looked-up data are not available for use in views, and if there are too many lookups on a single form, performance may be unacceptable. Therefore, you may occasionally need to duplicate data, but consider whether there is a need and how aggressively you have to keep the data up to date.
• Use shared code, sub-forms, shared columns, and shared actions to achieve reusability of similar features across modules. However, do not overdo the use of shared code component because there is a runtime overhead for Domino to link the shared items with other items for final rendering. A few simple rules:
• Use shared code components if the items could be used at more than one design element or modules. 
• Benefit of maintainability is more compared to the marginal overhead for the Domino to link the shared components.

Workflow process

Notes/Domino doesn't contain any specific feature called "workflow." Workflow is something you do with the product as part of your application design. There are, however, features in the product that are helpful in implementing your own workflow process from scratch. There are also add-on products available to assist you in implementing workflow in Notes, including:

• Lotus Workflow, a product offering from IBM.
• Various third-party products.
• At least one free workflow framework on openntf.org.

The domino application portfolio for an organization may include many applications that are workflow enabled. Building the workflow capabilities in Domino application can take considerable effort depending on the complexity of the workflow. If you do create your own workflow, design reusable components that can save you time in making the workflow functions available on all forms. Ideally you can reuse your workflow components in other Domino applications.
The following features of Domino are useful in building workflow into your applications:

• Reader and Author fields to control access to a document at different stages of its lifecycle.
• Electronic signatures in "signed sections" to prevent forged approvals.
• Scheduled agents to provide email reminders of overdue workflow steps.
• Hide formulas and controlled access sections to limit who can view or edit different parts of a document, depending on its workflow state.
• Document locking, to prevent replication/save conflicts during workflows which include parallelism or where there are multiple possible approvers at a given step.

To design a workflow capability that is easy to maintain with high rate of re-usability using Domino Designer, consider the following:

• Design a workflow engine instead of hard-code all the workflow rules spread across the application design.
  This approach helps the development team in efficient maintenance of the workflow process of the application and its scalability. Making the workflow process of Domino application configurable gives flexibility to reuse it in several applications.
• The workflow engine should have three major components:
• Workflow configuration documents:
  This is used to deal with the different phases, steps, activities or status of the workflow and associated details. Each workflow configuration entry stores the following details:
• Each workflow configuration document has configuration key or ID.
• Module name to which this configuration is associated.
• Name of the field in document to identify the current actors (to populate Authors) and spectators ( to populate Readers) by the workflow engine.
• Store the next workflow configuration key in case of approval or rejection of the current stage. This attribute help workflow engine define the document routing sequence.
• The mail subject and body in case of approval or rejection email requirement.
• The name of field in form/document to identify the names to send workflow emails
• Several other mechanisms to be considered in workflow configuration, is it parallel or sequential workflow or it’s a mix.
• Workflow engine script library: 
  The library is used to read the workflow configuration parameters defined in workflow master and act on the document as appropriate depend on current stage of the document triggered by users action.
• Workflow user interface components:
  This are the workflow actions to trigger the workflow step with reference to the respective workflow configuration. 

Program specifications

Program specifications should include the details of the GUI design, database design, module design, and workflow process. In the program specification, detail out the different possible Domino design elements required for various purposes that are input (Forms), output (Views and Forms), data storage (Documents), and Data manipulation programs (agent, script library, actions, events, and others). The program specification is the instruction for the developer to design and build business logic into the application. The input description includes the navigation, layout, input transaction, data editing rules, data validations, messages and general input processing. The output description includes the layout, panels, reports, screen output, messages and general processing. The data storage structure deals with the different fields, its data type, the access to data, data calculation or update rules. The data manipulation programs describes about the business logic for creation, update, and deletion of data, workflow processing rules, business logic, dependency of modules, and other components. 

Security procedure design

Domino is known for its granular level security control. Every single detail about the application security features to be considered, right from the database access control list to the documents, sections, and fields, the level of different access the business actor has on the database, and access rights of other system on this application are also documented in the program specification section. The following features provide a high level of security against unauthorized viewing and editing of documents:

• Database ACL
• Document Readers fields
• Document Authors fields (for users with Author access to the database - Authors fields are irrelevant for Editors and higher)
• Encryption (to hide individual fields)
• Electronic signatures (which don't prevent editing, but make unauthorized editing easy to detect).
• The $UpdatedBy and $Revisions items of documents, which make it impossible to modify a document without any trace.

There are also several Notes/Domino features which resemble security features in that they hide data from casual users, but are not secure from a "power user," particularly if they have a copy of Domino Designer. It's not wrong to use these features; you just need to be aware that if you need a higher level of security, they aren't sufficient on their own. A few of these features are:

• Hide-when formula
• Restricted category option in view URL, or restrict to category in an embedded view in the Notes client
• Restriction on document viewing or editing using JavaScript onload() redirection in a web application.
• Restriction on document viewing or editing in the Notes client by means of form events, e.g. Queryopen.
• Restricted access to views
• Different type of computed fields
• Other DHTML features of styling the visibility or editing features of fields and sections

As a general rule, if a user technically has access to view or edit a document or field, and they are sufficiently skilled, they can find a way to do so, through writing code that bypasses your UI or often by other, simpler means. If your application demands the highest levels of security, you must use the features in the first list.
To design security procedures for Domino application, consider the following:

• Avoid using the anonymous access to database unless it is required.
• Avoid adding individual user and server names to the database ACL. It makes maintenance of application access difficult. Instead, use groups to simplify the ACL entries.
• There is a limitation of about 75 roles supported through database ACL. Consider using ACL roles for security implementation only if the roles are expected to remain within the limit during the life of the application. 
  For example, using role such as country names to grant access to the users of respective country in a global application would lead to a situation of limitation. Use different groups for country or replica copies instead of role implementation.
  Roles are generally best used to control access based on a user's tasks within the application; for instance, there might be a "CostApprover" role with authority to perform a given workflow approval.
• Grant Editor and high level access in database only to the required users.
• Use Author and Reader level access to enforce the document edit and read access to the authorized user of the application. Readers fields have performance impact in views, which is detailed elsewhere in this wiki.

Detailed design document

On the basis of the design elements identified in the program specification, the detail design document must be prepared. This activity is a drill down version of program specification wherein every detail of each field in the form, each column in a view, each action button, hides-when formula, every event, agents, script library, function, every small detail about the application development are mentioned.  

Prototyping 

 Prototyping is the concept wherein subset model of the application attempts to simulate only a very few features of the final application. Prototypes are aimed to get feedback at early stage from the user about the critical aspects of the application. The prototype is also used to generate a proof of concept in case the application feature deals with either new technology or methodology and likewise. Prototyping techniques are used for early validation of operational concepts and user interface. It is also used when the user are not sure about how to implement a certain set of features. It also helps to validate the feasibility of a solution. Domino Designer, being a Rapid Application Development tool, is fast and facilitates rapid iteration between prototypes.  

Test planning

 
Test planning identifies the business requirements for which the system is developed and also specifies the application development aspect. It identifies activities, dependencies, and effort required to achieve the test objectives. The test planning adopted is based on the risks involved in order to make optimal utilization of test efforts. A manual testing of Domino application is guided through the test case document prepared. The test cases are the business scenarios for which the developed application must be tested against. 

The test plan describes how the testing will be implemented. It should state what will be tested, the major actions taken while testing, test techniques that will be used, the extent or depth of the test, and how the results will be verified. This approach shall ensure that the requirements are adequately tested.
 
The criteria for testing has to be well defined. It states the criteria for accepting and rejecting the test results. In case of unit testing, the code review should be completed and the associated defects detected in the code review cycle should be fixed. The entry criteria for integration testing should be the unit tested code, with the defects detected in the unit testing phase fixed. In case of systems testing, the code should have completed the Integration testing cycle, with the defects detected in the Integration testing phase fixed.

The application module tested may require another testing cycle if the variance between the planned and the actual number of defects detected in the testing process is considerable or a major defect is encountered during the testing process. 

It is crucial to plan to test the application with a realistic number of sample documents. It's very common for Notes/Domino applications to work fine in testing when using one workstation with a few dozen documents, but when they're in actual use with tens of thousands of documents and hundreds of users per server, performance bogs down. It's also a good idea to have a realistic number of (automated) test users for performance verification.

Design authorization

 
 The design authorization is an important step to obtain a buy-in from all the stake holders. The initial design authorization is done within the hierarchy of the development team. This final internal review of the design is done before it is presented for customer sign-off.  

Parent topic: 2.0 Application development lifecycle