IBM Lotus Domino: Classic Web Application Development Techniques: This tutorial takes Domino developers on a straight path through the jungle of techniques to deploy applications on the web and introduces you to the classic strategies. Why Google it when it’s all here?

While you browse the Web, gather ideas about what makes web pages look good. Great websites should inspire you. Inspect the layout, the use of images and color, and the navigational strategies. If you see an interesting control, peek under the covers and take notes about how it was coded. But be sensitive to intellectual property and copyright laws not everything published on the Web is free.

In particular, collect links to public websites that use Domino and show it to good advantage. Relatively speaking, only a smaller number of public-facing websites are served by Domino. But browse around; you will find hundreds of them in short order. This collection of websites can become a marketing and public relations tool for you as you sell your ideas to your customers.

Too often Domino web applications crafted in the past were functional, but not pretty. That might have been okay ten years ago, but no longer. Today's customers expect the same kind of functionality from your applications that they see elsewhere on the Web. And there really is no reason why you can't provide it to them.

Take some time and build yourself a small application to hold the links. Eventually, roll this application to the Web so that the links can be shared readily with customers and others who are interested.

In this sample Domino Websites application, details about each website are stored in a separate document. The blue hotspots link to views which display lists of Commercial, Consultants, Government, and Other Sites. With sufficient privileges to the database, a user can add, edit, and delete these documents with the Notes client or with a browser.

Honing your skills by doing is essential. The more applications you build and the more time you spend on this work, the better you should become at it. Experience is a great teacher.

But you do not have time to figure everything out yourself. So you must read and study what others have done, which is especially easy today with a fast connection to the Internet. Set aside some time every week (or each day if you can swing it) and graze the web landscape.

Commit yourself to preparing for, taking, and passing certification exams in Lotus Notes / Domino application development. If possible work through the Administrator exams as well. Effortful and extensive preparation should make it easier to pass the exams the first time. More importantly, preparation for the exams will broaden your understanding of Domino and teach you about features and techniques that you might not otherwise stumble upon by yourself.

And, of course, holding this certificate looks good on the resume.

Experienced developers rely on Domino Help. Be aware that there are separate help databases for each of the clients: Notes, Administrator, and Designer.

The Lotus Domino Designer 8 Help database contains over 9,000 documents. In it, you will find extensive information about features, language syntax, classes, limits, errors, tips, and code examples.

The code examples can be particularly useful. If you find some code that looks just like what you need, simply copy it into your application, and then modify it as necessary.

Especially if you are new to Domino, spend enough time with Help to be comfortable with where things are and how to find information on specific topics. The Contents view organizes the information like a book, by general subject area. Use the Index if you know what you are looking for the syntax of a specific @ function, for example. Use the Search feature when you are not quite sure for what you are looking. Beware of searching too broadly. Search for the term "web" and you will find over a thousand documents!

Once you are comfortable with Designer Help, try Designer's context sensitive help, which is invoked by opening or highlighting a design element and then pressing F1. Display forms in the Work pane and press F1 help on designing forms displays. Select a tab in a Properties box and press F1 help on that tab displays, and so on.

Designer provides basic editing for text, so for the most part, you can develop applications without using external editors. However, dedicated editors for HTML, JavaScript, Java, and CSS will provide you with conveniences such as syntax checking, color coding, validation, and ready-made functions which may appeal to you. If you develop code in an external editor, you will have to import the files as resources into your application or copy/paste the text into appropriate locations in your design.

You can reasonably get on without external text editors, but learning to use an image editor may be well worth the time it takes, especially if you do not have access to a graphic designer or a library of images. Almost any image editor will do as long as it saves images as JPEG or GIF files. (Designer can accommodate other graphic types, but JPEG and GIF files are natively compatible with the Web.) Although it may take some effort to learn, the open source program GIMP is a no-cost, feature-rich image editor. Find more information at the GIMP website: http://www.gimp.org.

In this book, except where noted, examples rely on only the native capabilities of Designer.

New ideas for solving problems constantly present themselves. But introducing a new, untried technique into an existing application may result in many more problems than it solves due to unintended consequences and side-effects.

Create one or more sandbox applications in which to try out new ideas. Constraining new development this way facilitates isolating and resolving problems specifically related to the new technique. And if, at the end of the day, the technique does not live up to its promise, then nothing needs to be removed from the real application design on which you are working.

Solutions discovered or invented for one application inevitably find their way into other applications. Code snippets, strategies, and even entire agents are often reused to save development time and effort.

Keeping track of such ideas may be difficult over a period of years, especially if you work on dozens of applications or move from job to job. It might be inappropriate (ethically or legally) to keep personal copies of designs created for previous employers without permission, but it is certainly reasonable to keep detailed personal notes in one form or another. The tools are readily available: paper notebook, flash drive, optical disk.

Keep your notes organized and periodically review items in your cookbook. Revise and annotate. Include variations and caveats. As it is impossible to remember in detail all the code you will ever write, you will find your notes to be an invaluable resource.

Over time, the language of Notes and Domino changes, as do the tools. At one time, the Domino Directory was called the Name and Address Book or NAB. The file that contains design elements and documents was called a database and is now referred to as an application. In Designer, the Design Pane became the Application Navigator. Of course, you will come across references that use the older language and some developers who continue to use deprecated terms out of habit or stubbornness.

Be alert for these changes of terms and the definitions which go with them. Be mindful of the old names, but use contemporary and correct vocabulary, just as you should use contemporary development techniques.

Domino applications intended to be accessed with a web browser can take advantage of many contemporary web technologies like Ajax, CSS, and XML. In fact, support for these standards has been included in Domino for many years. As web technologies evolve, so does Domino.

So pay attention to non-Domino web technologies and strategies. Web-enabled Domino applications should be crafted using the best web programming practices.

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:

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 can be organized into common types as follows:

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

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

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.

When you are young and brilliant, your mind might be as sharp as a tack and your memory as long as the Great Wall of China. But as your responsibilities increase, as your projects become larger, as you attend more meetings and deal with more customers as you get older your infallible memory will become fallible.

Take notes. Write things down. Some people prefer to use a laptop or PDA. Personally, after many years of trying several methods, I've come to appreciate the simple notebook. I jot notes all day long at my desk, in the car, at a meeting, in bed at night. It contains my list of tasks, my key contacts, notes from meetings, to-do lists, and timestamps. It is my work-life in a compact, lightweight, versatile package and it works without electricity.

It is a simple fact that people who make lists of things they must do, tend to get more things done. This is true on a personal level as well as on the job.

Start each day by making a list of tasks you will work on, meetings you will attend, and phone calls you must make. Keep that list nearby and refer to it often. If things come up during the day, add them to your to-do list. As you finish an item, check it off or scratch it out.

At the end of the day, review what you achieved and what is still undone. Create a new to-do list for the next day. Prioritize each item either in terms of how important it is to do or in terms of when you will do it. This simple activity will help you focus, and when you focus, you accomplish more.

If you are not used to working with to-do lists, it will take some self-discipline. You might also consider creating weekly, monthly, quarterly, or annual to-do lists as well. As you plan each day, consult the lists which deal with the longer timeframes and incorporate all relevant items on the daily to-do. The adage "Plan the work and work the plan" can be fulfilled easily with the simple to-do list.

Developers and other technicians are often loath to spend time documenting, especially writing progress reports to managers. Managers, on the other hand, really do need to understand what their employees are doing. Well-informed managers can make better decisions when authorizing new work, prioritizing current tasks, handling contrary customers, reporting accomplishments to their managers, and requesting budget for the coming year.

As a developer, you should submit a summary of your work on a regular basis. Your organization may have a prescribed format for this activity. If not, here is a simple outline for weekly e-mail which can work satisfactorily:

Add bulleted items in each section. Be concise, clear, and plain-spoken. Your goal is to convey a sense of your activities and progress to your (possibly non-technical) manager. Send this summary to him or to a project leader at the end of each work week when the information is fresh. Do not embellish, don't minimize. Use this report also to help plan the week ahead.

Some users will tell you exactly what to do and how to do it; others are reluctant to ask for any changes whatsoever. Some developers would rather not speak with customers at all, believing they "know" what the customer needs.

The best circumstance is that in which the developer and the customer work together to advance a project. They share ideas and come to a common understanding of what needs to be done.

Lotus Notes and the Web are very visual environments. As a developer, you need all the help you can get to craft a good-looking and functional application which helps and pleases the customer. Engage with the customer early and often.

It may be difficult to convey in words what a screen will look like or how a workflow will progress. Early in the project, develop a prototype which includes approximations of the forms, pages, views, and other visual elements of the design. Take screenshots and paste those images into an e-mail or a document, and send them along to the customer. Ask for feedback.

If possible, sit with the customer in front of a computer and show him what you want to do. A picture can convey meaning clearly and efficiently, and workflow can be demonstrated really only by trying it out. Do this several times. The customer will share ownership of the project and will offer suggestions to improve the final product. Take notes and take heed. Be a hero.

If the task at hand involves enhancing or web-enabling an existing application, then one of your first tasks is to familiarize yourself with the application as it exists already. If there is any existing documentation, read it. If not, you will have to undertake the discovery process on your own.

Start by taking a copy of the design. If there is an archived authoritative design, request a copy of it. If there is no authoritative design, don't trust any copies you may find on the development or staging servers. Previous developers may have left pre-production changes lying around that never made it to production before they moved onto something else. Ask for Editor access to the production database and take the design from there.

Examine the agents in the current design. If any of them are enabled and scheduled, make notes about which ones are enabled and then disable them. It may well be that some of these agents send e-mail notifications to people as part of a workflow. Other agents may automatically download or upload data to other databases. Until you know what the agents do, disable them.

Determine if there is a version or release designation for the production design. If not, assign it one. Then set the designation for the new version you are about to craft (for example, "Version 1.3").

Create a development database from the production design on your development server. You will be accessing this database with a web browser, so placing it on a server provides you with a more realistic view of how the application is accessed (or will be accessed) by your customers.

If you can copy documents from production without compromising security, then do so. Otherwise, copy some documents from another non-production database or simply create your own documents with the current design.

Examine the Access Control List (ACL) of the production database. Take note of which groups are listed and what privileges and roles each is assigned. Adjust the ACL of your development database if necessary to assure you have Manager access to it. This level of access enables you to modify the ACL if your design changes require it.

Open the application with Notes and look around. Read the About and Using documents. Look to see if there is any other internal documentation which may be helpful in understanding the design. Open the views and a document or two. Look over the agents.

Open your web browser and create a bookmark to the development database. Try to open it. If the database fails to open properly, re-open it with Notes and look for a "configuration" view and document of some sort. A configuration document or application profile may require changes before the database will open properly on the Web perhaps the configuration document lists the wrong server name or database file path. Make changes and try again. Once you have the application open in a browser, explore it. Begin to think about what you must change in order to implement the requested changes.

A customer may inquire about web-enabling an existing Notes application. As a first step you may be called upon to assess the condition of the application as it currently exists and to provide a work estimate for the uplift.

The first task, assessing the application as it currently exists, might best be undertaken by a quality assurance tester or by a power user who will "think like a user" rather than like a developer. On the other hand, if someone like that is not available, you may be tasked to perform the assessment.

Issues arise during the course of development, and even during routine maintenance tasks. There are decisions to make, problems to investigate, code to fix, tests to run, and documents to write. Typically, there are too many items to keep in your head, and jotting notes on scraps of paper, frankly, does not work well when there are many issues or when several people are involved in a project.

Keep an active log of items in a spreadsheet, in Team Room documents, or even in outline form with a word processor. Read and prioritize this list regularly. Review items with your project team, manager, and customer as appropriate. The issues log will help to keep you focused and moving forward. Fewer issues will fall through the cracks.

Track information about each issue in a consistent way. Keep enough information about each item to answer questions that arise, but do not overdo it. Create the issues log which you need for your project. Here are a few key items which might be tracked. Add to or subtract from this list as appropriate to your needs:

Customers are concerned with look and feel and with functionality. These are aspects of an application which they can see and about which they may have opinions or demands. They assume that applications will perform well and flawlessly, and therefore considerations like good response time and effective error trapping are unlikely to make it to their requirements list.

However, these are things which developers should care about in great detail. A good looking, feature-rich application which is slow or which hangs, or displays many error messages, such an application is a failure.

Here are some things to consider. Each of these topics is elaborated in later chapters.

Prior to or coincident with rolling a new application or a design upgrade to production, prepare a somewhat detailed Summary of Changes for the new version or release. In this document, identify for each change the following things:

The Summary of Changes is the final report of the project, a clear statement of what was done. You may wish to include a list of suggestions for the next design upgrade.