Mike B.'s comments:

Magnifying glass, anyone?
Notes has to be one of the worst applications on the market from a UI perspective. Buttons cannot have keystrokes and so on. The list is endless. Don't get me wrong, I love the product, just a few tweaks could make it fantastic.

I have worked for four large corporations in South Africa and the U.K. that have migrated from Notes to Exchange, and the most common comment is how much easier Outlook is to use.

The superior user interface
Sort your start menu.

Teamwork
Unfortunately products like CIAO do not support a distributed development environment with occasionally connected developers (e.g., local replica, centralized log/config files). It would be a great product if it could work in a JIT-outsourced environment.

Object orientation
A half-hearted implementation, at best. Can ND7 and fix ND4/5/6 first! Oh, and let's not forget the bug called DGW -- please fix that before doing anything else.

Make it snappy
It would be nice to see some examples of the techniques working on a 1.5GB database with more than 500,000 documents. I think that would result in a re-think of some of the content of the Redbook.

The right tools
Again, products that don't quite make it. Analyzer cannot help you find all cases where a view is used across a 10-database application.

Error handling -- interesting stuff, but when your error handler needs an error handler, IMHO, you have gone too far.

Andre's response:

Notes has to be one of the worst applications on the market from a UI perspective. Buttons cannot have keystrokes and so on. The list is endless. Don't get me wrong, I love the product, just a few tweaks could make it fantastic.

I have worked for four large corporations in South Africa and the U.K. that have migrated from Notes to Exchange, and the most common comment is how much easier Outlook is to use.

Unfortunately products like CIAO do not support a distributed development environment with occasionally connected developers (e.g., local replica, centralized log/config files). It would be a great product if it could work in a JIT-outsourced environment.

Of course, occasionally connected developers can check things out while they're connected and work on them offline.

Actually, if I recall correctly, it's also possible to do a provisional checkout in CIAO, so you can work on something locally without checking it out from the server. But it's a bother to deal with the situation then if there is a conflict. That's the risk you take working offline; for some, getting to work from Starbucks is worth it. You might have to do something to set it up, like create a local replica of the checkout control database. Consult Ives.

Object orientation -- a half-hearted implementation, at best. Can ND7 and fix ND4/5/6 first!

Oh, and let's not forget the bug called DGW -- please fix that before doing anything else.

It would be nice to see some examples of the techniques working on a 1.5GB database with more than 500,000 documents. I think that would result in a re-think of some of the content of the Redbook.

Notes/Domino is not a relational database, and databases with that many documents are at the very high end of what we envision the product being used for. The nsf file structure was not designed with that in mind. However, I think that you will be happy with the performance improvement if you try NSFDB2 in version 7. Or, in the meantime, LEI Virtual Documents give substantially better performance with very large data sets.

Again, products that don't quite make it. Analyzer cannot help you find all cases where a view is used across a 10-database application.

Error handling -- interesting stuff, but when your error handler needs an error handler, IMHO, you have gone too far.

If you want to limber up your accessible-design muscles, here are some educational exercises to give you an appreciation for the disabled experience:

• Get a screen reader, such as the popular JAWS, which is available as a free trial or Windows-Eyes from GW Micro, which also provides a free copy. Use it to listen to some of your applications. It's a revelation.

• Have a mouse-free day once a week (and try out your applications during it). This gives you a good chance to learn about the frustrations of keyboard-only users. It's also an excellent motivation for learning the keyboard shortcuts for commonly used functions, which are generally faster than the mouse anyway. Today is my mouse-free day, and I can tell you that some of the toolbar options in some of the programs from a certain company in Washington state are not easy to find in the menus! Hint: the F6 key and Alt+Tab will be very useful!

• Use the notes.ini parameter DISPLAY_FONT_ADJUSTMENT to increase the size of all your fonts in Notes, and see just how badly this messes up the design of your forms. To a certain extent, it doesn't matter whether the screen looks messy -- people who use large fonts get used to that -- though it is classier if it adapts well. The key question is: Is everything still visible? Can you see it all by scrolling around, or are parts irretrievably amputated? OS-style fields with an absolute size specified in inches or centimeters are a prime culprit here, as are layers with absolute positioning and size.

Norman has a new book out, Emotional Design: Why We Love (Or Hate) Everyday Things, about an interesting finding of researchers who study the effects of design on usability. Apparently, a visually attractive design is more usable than an otherwise equivalent unattractive one.

Since I love to create graphics and logos and make colors match and generally waste time making things look nice that could better be spent coding, this is a welcome finding for me! Maybe that time hasn't been all wasted after all.

Norman is also, however, very sarcastic about designs that have nothing doing for them but their attractiveness. Matte-black appliances with a row of identical black buttons are a subject of his scorn. Of a post office which won a design award, he notes that although all that clear uncluttered glass of the entryway looks stunning, people get trapped in it because they can't tell whether to push or pull the doors, and on which side to push or pull. Four choices, only one correct.

So, besides the newly discovered attractiveness advantage, there are other principles one must consider. I'm not going to write about them in detail, because that's less fun than giving bad examples. But here's a nice description of the basic principles.

As is appropriate, my first example is something that I did myself -- but fortunately not to anybody else (until now when I am inflicting it on you). So with some embarrassment, I present my Windows Start menu. How fast can you find "NetSupport" on this list? I'm not much faster -- I haven't memorized everything by position.

This menu badly needs organizing. I manage to get along with it because there are only a dozen or so programs I use frequently, and I put them right up front and give them shortcuts besides. Shortcuts and "frequently used" lists are an important part of good design, but when people have to make a choice from a list they're not familiar with, the list had better be short. If I were rolling out lots of PCs identically configured, the programs list would be very short and would consist of categories you can drill down through to find what you want.

Of course, when it's something a person can type and not have to think about, like what state they live in, a long list is appropriate. I certainly wouldn't want to have to first select my region of the country so that I can have a list of just seven states to choose from instead of fifty. It's not worth the extra key clicks and the bother of thinking about it.

Which brings us to the next bad example. I came across an application recently where you click the action button, and it asks you whether you want to do the action, yes or no, and if you answer yes, opens a dialog where you can specify more precisely what you want to do. In this case the choice is clear -- the yes/no dialog adds no value, so get rid of it. If you clicked the action button by mistake, you can just cancel. The principle: Count clicks and try to reduce their number. Also keep in mind that switching between keyboard and mouse takes time, and that not everybody can use a mouse in any case.

I also see lots of applications that prompt users for information in a series of one-field dialogs, which do not allow them to back up. Remember The Wizard of Oz? Like witches, there are evils wizards and there are good wizards. This is an example of an evil wizard. It's understandable why people would do this, because they can just write the code to ask the questions with a series of prompts, and they don't have to design dialog windows. But it's really obnoxious for end users. Deserves punishment.

One thing I don't understand -- I have to remember to talk with someone about this -- is why the default selection for Notes radio buttons and checkbox fields is an inset border. The default should be no border. In most cases, all they do is clutter up the form with extra lines without making it any easier to use. Sometimes you have a bunch of these fields next to each other and you need some division between them -- but there are better ways to do even that. Such as designing the form so that the fields are not right next to each other or giving them different background colors or using a single thin line to divide them. Forms are easier to use if they have a clean, simple look. There can be decoration around the edges, but in the key parts of the form, you only want to see things that convey needed information.

I could go on like this for quite a while, but instead let me just point you to a bunch more bad examples.

• Pokes fun at MS Windows
• How not to design vending machine controls

Now, of course, it was a big mistake for Leonard to allow himself to become involved in a big production song and dance number of any kind, much less about hobbits. It's clear that his friends and advisors completely failed in their responsibility to help him steer clear of error. Someone really should have taken him aside and said, "Look, Len." They should have said, "I know you want to prove you are not Spock, but believe me, this is not the way. Decades from now millions of people will watch this idiotic thing on the Internet, and it will eclipse all your serious acting work by sheer badness." Or maybe he was warned, but was stubborn or had already signed the contract. How the mighty have fallen.

It is in just this regard that it makes total sense to have developers review each other's work before it leaves their hands and goes to the testers. The human brain is a funny thing. Once it decides what's supposed to be there, it gets really difficult for it to see what's actually there. It's very difficult to review your own code, because your eyes skim over the parts that you're familiar with, which is to say all of it, and it all looks fine. When someone else looks at it, someone who doesn't know already how it's supposed to work, they see things you don't.

Code reviews also pay off big time. It might seem at the time that you're wasting people's time when they could be coding or fixing bugs, but get over it! Studies have shown that formal code reviews prevent so many problems down the line that they pay for themselves many times over. Read An ounce of goat is worth a pound of hero

I also advocate pair programming -- two people working together on the same task. Again, the justification in part is that one person will catch the other's errors or be able to think of a better way to do the task. But there are other reasons this makes sense:

• In the course of working out how they're going to approach the task, the developers are forced to actually plan the design, at least somewhat. This helps them structure their thinking about the problem and articulate reasons for choices that might otherwise be made by default (i.e., based on whatever the developer happens to think of first).

• It combines normal work with education, as each developer picks up techniques and obscure information from the other.

• It's more fun. This is not just my opinion; it's scientific fact.

Effective team development also requires that the members of the team know fairly well what the other people are doing. This is in part so they know who to ask when they have a question, in part for cross training purposes and in part to prevent duplication of effort (writing the same function someone else already wrote because you don't know they did). Both the code reviews and the pair programming advance this goal.

Resolving conflicts
These words have a different meaning to a Domino development team than to other types of teams. Team Domino development has special challenges. Since the entire Domino design is a single file, traditional versioning and check-in control systems don't work. It's not acceptable for one developer to hog a whole .ntf or .nsf file -- several people might need to be working on different parts of the design simultaneously. And if they do so, they are very likely to overwrite one another's changes.

In an earlier day's blog entry, I mentioned a tool for dealing with this problem. CIAO from Ives Software both keeps past versions of anything checked in and prevents simultaneous editing by requiring developers to check out design elements before working on them (or as they start to). In practice, this tool can be a little cumbersome, but there's nothing better that I know of, and it's so much nicer than when you discover that the 300 lines of LotusScript code that you wrote and painstakingly tested a week ago were overwritten by someone else who happened to be working on that design element at the same time, and now you have to try to reconstruct them from memory.

Paying attention to the "Save conflict" warnings is not enough to prevent this if developers are working on different replicas. Changes made in a local replica may still overwrite or be overwritten by changes made on the server or in another local replica, with no conflict warning. CIAO takes care of this.

Note: CIAO has a client install and a server install. It will work without the server part, but installing the server part guarantees that nobody not using CIAO can edit the design, bypassing CIAO's controls.

Then, like the Hobbit dance troupe in the video, you can coordinate your activities and keep from stepping on each others' toes.

The Dreaded Generic LSE Error
There's another issue that you're likely to come across even if you're working alone, but more so when you have a team. When you save LotusScript code that calls a script library, the LotusScript compiler creates code that's dependent on the specific version of the script library being used. If the script library is then edited, the LotusScript code that calls it might or might not work. This may cause various problems, most commonly the "Generic LSE Error" message, but occasionally other more subtle issues. If the problem doesn't happen when you debug, that's a pretty good sign that compile order is the problem.

The "Tools/Recompile All LotusScript" menu item in Designer 6 is the easiest way to solve the problem. However, it's kind of a sledgehammer approach since it recompiles all LotusScript, even the bits that didn't need recompiling. Especially difficult if the database uses design locking or CIAO, since for any person to use this function, everybody else has to check in their work first. Getting hold of everyone to make them do this may be a challenge.

It would be nice to have a more selective tool, which would recompile only those parts of the code that actually need compiling. I don't know of one, but perhaps someone could post a link to help out the rest of us? It wouldn't be that hard to code if it doesn't already exist. If someone has time on their hands.

In an earlier blog, I showed where to find reusable code. I also gave a link to a Notes database that lets you build up a library of reusable code and design elements that a team of developers can use. There are probably some other designs like this, but I know about this one because I wrote it. If you're ambitious, you could set this database up and send around a link to developers in your organization that it's there, and to please use it and contribute to it. If you're extra ambitious, you could go through the code samples in those other places I wrote about and create documents in the code library with a brief description and a link to any entries you think are particularly likely to be useful.

There are a couple of other such repositories specific to particular types of data:

• JavaScript library
• CSS library

You might not be in a position to institute a program of financial rewards, though if you do have any influence that would be nice. But rewards can come in many forms; people respond well to simple recognition, for instance. A monthly contest to see who has contributed the most reusable stuff and who has managed to reuse the most, with winners announced in team meetings, would probably be incentive enough for most people. Even just posting the stats where people can see them will help. It's a well-known principle of management that what you measure, improves.

The design element library database would probably benefit from some changes in its design to keep track of use. In particular, there ought to be a function to allow someone to record their use of something from the library, so that accounting views could be created to report the totals by element, developer and application where used. This information is also handy if you find a bug in one of these pieces of code, since you know which applications need to be updated.

Of course, the best reusability in the Notes world is where someone can take a whole application, create a new copy from the template and reuse it with few or no design changes. The whole team who worked on it should be recognized for that. This is actually a little easier to track, since you can scan a server to see how many instances of a particular design are on it -- provided you have some standard way of identifying a design that doesn't still have the template name in it. More about that another day.

It takes substantially more effort to write reusable code, compared to code that is suitable for a particular application. It's easy to see this if you browse the tips on SearchDomino.com, for instance. These are full of little functions that work for 30-80% of the cases you might encounter. For instance, see my comments at the end of A better way to track field changes. The author probably developed it for use on one particular form, it worked great with the data in their one form and that was all they needed. You can reuse this as is, but only if your form meets certain requirements -- no multivalued fields, for instance. Much better to have something carefully designed to meet all or nearly all conceivable circumstances, not just those of the particular project it was developed for.

This brings us to the Big Topic for today, which is how to go about doing Domino designs that can be reused.

Object orientation
First and most important, consider using an object-oriented approach for any code on the project. There are many excellent references about this, mostly not specific to Notes/Domino. An exception is Practical LotusScript, which I mentioned previously.

A well-designed class is easy to reuse and easy to extend. Of course, not every class is well designed; you still need to think about what you're doing. But the class syntax makes it easier to implement a modular design, should you design it in such a way.

For many Notes/Domino designs, the types of classes you might create relate to a particular type of document. Rather than having every piece of code know the specific fields on the document and their relationship to each other, you can design a class that presents the simplest possible interface to the outside world, by which I mean the other code that calls it. If you redesign the form, rename fields, change validation rules or what have you, you don't have to find every piece of code that refers to fields on that form and consider whether it's still correct. You just have to make sure that the one class is correct, keeping the programming interface to that class the same if you possibly can. The goal is to hide the details from the calling code; this limits the amount of code where the details matter.

Of course, a class that controls access to a particular type of document is not likely to be reusable in other projects unless they happen to have that same type of document. But there are cases where this can happen, particularly when integrating different applications.

Other resources specific to object orientation in Domino:

• Lotus Notes and Object-Oriented System Design (thanks to Keith Nolen for this link)
• Using the object-oriented features of LotusScript

Parameterization
This is covered in the above references also, but one key factor in writing a reusable anything is that the code should avoid referring to things by specific names that may need to be different in different contexts. Say you want LotusScript code to process all the documents of a particular form in a database and change the "server hint" from server A to server B in all the doclinks in one or more particular Rich Text fields. When the problem is expressed in those terms, you are almost forced to write some fairly reusable code. Because I haven't said which database, which Rich Text field or what servers server A and B are, it seems fairly natural to write a function that takes as arguments a Rich Text field and two server names and updates the server hints from the old name to the new name. That function by itself may be useful in other contexts (for instance, you might also want to update server hints in a document as someone is saving it) if they created a link to a local replica you want to redirect the link to a particular server.

If you had written the link updating code as part of a single large "Initialize" sub that included the hard-coded names of the fields and servers, it would be more work than it's worth to extract out the part that updates the doclinks. You might look at the old code to see what classes and methods you need to use, but the old code is a sample rather than a reusable element.

So far I've only been talking about code, but Domino designs can also be parameterized in a larger sense. Profile documents and other configuration documents let you define e-mail addresses of people to notify, keyword lists and whatever other factors you can come up with, so that they can be changed by someone who knows nothing about Domino development and who doesn't have a Designer client or high enough access to the database that their ignorance makes them dangerous.

Not only does this type of design make an application easier to maintain, but it also makes it much more likely that the entire design can be copied and reused for another purpose with no design changes -- again, the Holy Grail of Domino design.

Thinking ahead
A big part of making something reusable is just taking some time to think ahead about how people might want to reuse it. As we did with the doclink updating example in the previous section, try to put the problem in generic terms. Think about ways in which your situation is special, and consider ways in which the code could be written so that it will still work if your special situation no longer applies.

For instance, the doclink updating agent in the previous example is designed to be run in the case where we are replacing a server with another server that has a different name. The new server will contain all the same databases, so we're just assuming that by changing nothing but the server name, the link will still be valid. This is not necessarily the case in other situations where we might want to use this code. If nothing else, it makes sense to add functionality to test the updated link's validity, which the caller could optionally enable if they needed it. If the new link were not valid, the code could throw an error to the caller or otherwise indicate failure, allowing the caller to react in whatever way they see fit. Or, to go even further, the code could include functionality to have a list of possible replacement servers to search for a database containing the linked document. Then a single destination server just becomes the special case -- a list of one server instead of several -- and you're well on your way to developing a reusable doclink-fixing utility. Make it a class with internal data elements to keep track of which server it found a particular database on, so that it only has to search once for any given database, and now you're cooking with gas! But it's not the sort of thing you would have thought to do if you were wholly focused on the specific task.

Code/design reviews
Besides their role in assuring quality, about which more on a later day, code and design reviews are a great way to identify opportunities for code reuse and for identifying parts of a project that should be designed for reuse. The members of the review team might well be familiar with existing tools that the developer is not, and the mission of the review team is different, but the developer's task is to find a way to do it. The review team has a different role: to make sure that it's being done in the best possible way.

Get management buy-in
There's no getting around the fact that a reusable design costs more in initial development time than just slapping together something that works. The payoff comes in the later reuse -- the greater corporate ability to produce complex systems in a short time and the better ability to maintain the applications down the road. It's that sauna tradeoff: Do I get something cheap that leaks and that I can use only a few times or invest in something that'll last?

Another good way to speed up forms that do keyword lookups, especially if your keyword list changes infrequently, is by use of a shared profile document. Write an agent to execute nightly (or at whatever interval seems best), do all your @DbColumns just once and store the results in the profile. Since the Notes client and Domino Web server both cache all the profile document fields, access to them is a lot faster than a live @DbColumn -- though the data might not be as up to the minute.

Please write in with any other performance tips you can add to what's given in the above materials.

So, today I'm writing about the most common deficiencies in Notes/Domino application designs. Here's a list of the problems I've seen most often in production.

General

• Performance problems that don't show up in testing because you tested with 12 sample documents and the production database has 200,000 documents.

• Dates or numbers are stored in text form, causing problems in calculations, view sorting or differences when users with different formatting options use the app.

• Omitting Option Declare in LotusScript code. There's an option in ND6 to have it inserted automatically, so there's really no excuse. Of course, as Brian Mahoney eloquently points out, tools are no substitute for thinking, but why make more mistakes than you have to?

• GetNthDocument method to iterate through a large collection. In most cases, this is slow. Use GetFirstDocument, GetNextDocument.

• LotusScript errors are not handled.

• There are few or no comments in the code.

• There are few or no comments in the code.

• @Db function has no error handling.

• Formula code in action button assumes the user doesn't know how to open and close Notes windows. For instance, it uses @Command([FileCloseWindow]) three times because the developer believes this will close the current document, the other document from which this one was composed and finally the view that document was opened from. This neglects the possibility that the user has opened, closed or switched to other windows meanwhile or opened the original document from a doclink.

• Formula does the exact same lookup twice, both times with NoCache. The first time to check for errors, the second time to get the data. Use @IfError or store the lookup result in a temporary variable instead.

Now, I have to admit that I'm guilty of a lot of these errors myself. After all, Domino Designer is a rapid prototyping tool. It's a total waste of time to make the perfect input translation formula in a field before you're sure the field is even going to be in the final application. The problem comes about when you don't come back and finish that boring detail work before you call the application done; it's really easy to miss something when you're putting on that final polish.

Fortunately, most of these problems can be caught by an automated checker, such as the TeamStudio Auditor I described yesterday. It also helps to have a really good testing procedure (another thing I plan to cover in a future meandering diatribe). Of course, it's less expensive and time-consuming -- as well as better for your reputation -- to fix these errors before they get to the testing group and get written up formally. But, should some little error slip by you, just remember the magic words:

"I did that on purpose to see whether you were paying attention."

It doesn't work with my wife, but your QE department may be more gullible.

Off on a tangent: There's a custom among makers of handmade Turkish rugs to deliberately include an imperfection in the rug's pattern; the theory being that since only Allah is perfect, and it would be presumptuous of them to make a rug with no errors in it. In my mind, this gives rise to two questions. First, if they did it on purpose, how can they call it an error; and second, is it not more prideful to take pains to avoid perfection, since that implies that you could have done it perfectly if you chose? Doesn't it show greater humility to just do the best job you can, and assume it's not going to be perfect?

Call me a cynic, but I think that custom arose not for the greater glory of Allah, but so that rug merchants would have something to tell people who tried to bargain the price down by finding a flaw.

Like many things I write here, it's just a theory I have…

Ives TeamStudio for Notes
I've been a fan of these tools for years, and they keep adding new ones. This is a suite of several utilities that install as Notes toolbar icons (or if you're still in the dark ages of R5, smart icons).

• Analyzer creates a Notes database that describes the design of another Notes database. Each document in the output database describes one design element or sub-element (e.g., there's a separate document to describe each field on a form). The Notes/Designer client also includes a function to create a database synopsis, but this is better, because of the following reasons.
  • It works on large databases (unlike Design Synopsis, which tells you "too many paragraphs" if the design is too large).
  • It includes all the options and properties (or nearly all of them).
  • You can full-text index the database to search for names.
  • You can document design elements by writing in a Rich Text field on the documents; this is handy for the too-often-skipped documentation phase of a RAD project.
  • You can create views of design elements that fail to meet standards (text fields without help text or without input translation formulas, for instance). Then use these as to-do lists of things to fix.

• Auditor runs in conjunction with Analyzer. It applies a set of user-configurable search filters to each design element description. Those documents that match the filter are flagged with a message that you define along with the rule (e.g., "Shared view formula must not use @UserName"). The filtering rule syntax is limited, but it's good enough to automate nearly all the things you might want to test for. Many filter rules come with the product, and Ives sells additional ones, which I haven't seen. (If they ship me a free copy, I could have a look at it and post here whether I think it's worth it -- in case anyone from Ives is reading this.) I also wrote a set of filters for them to distribute free on their Web site. You must register on the site to download it.

• Configurator is a search-and-replace tool for Domino designs. Ives says this is handy for reconfiguring databases by changing a hardcoded replica ID or database path or Notes userID that may occur in the design, hence the name. In my opinion, it's better not to have hardcoded information such as this in your design, but that's material for another day's blogging. I use the search function much more often than the replace function. It's extremely valuable for tracking down precisely where in a hierarchy of 50 script libraries some global variable is defined or some field is referred to.

• Delta is a comparison function for Notes databases. You can either have a report of the differences written into a Notes output database or see them live on the screen, drilling down to the ones you're interested in.

  The one big flaw I've found with Delta is that it shows you all the differences, even extremely trivial ones. There's a so-called "smart filter" that eliminates a lot of the differences that don't matter, but it's still time-consuming when comparing two versions of a form to have to drill down to the bottom of a long list of nested tables just to find out that the width of a table cell has been changed by .003 inches -- not because someone deliberately changed it, but because they had their actions pane open when they saved the form, and the table is set to fit to margins. It needs an option to show only functional differences between design elements and ignore all text formatting, table sizing and so on.

• CIAO (Check In And Out) is a locking and version control mechanism for Domino designs. While locking has been addressed by ND6, the ability to record check-in comments and retrieve back versions of design elements is very valuable, especially on team projects. You can also invoke the "delta" tool on two versions of a design element to see what's changed between them, which has saved my sanity on more than one occasion.

There are other tools in the suite, but I find I don't use them so much. That might be due to my personal working style -- you might find them helpful.

The tool is far from free, but keep in mind, too, that developers' time is worth something. If you can use these tools to shave off a week here or a week there from a development project, you've more than repaid the investment.

NotesPeek
This tool lets you peek into the internal structure of a .nsf file. Not only can you see every note (at least those you have access to), but there's lots of technical detail about each note. This is just about the only way to tell how many deletion stubs are in the database, which is helpful for debugging replication problems. It's also a good way to learn more about how Domino databases are organized, which can help you figure out what's going to work and what's going to be efficient in your apps.

TopStyle
This CSS (cascading style sheet) editor is a tool for Web developers, but many Domino developers are also Web developers, and the Notes client implements CSS also (albeit less than completely). It pays to have a top-notch editor for CSS.

Which CSS editor is best is a religious issue. I freely admit that my opinion is totally subjective. Find one that you like, and it'll save you time.

Some kind of HTML editor
Since Domino Web apps often use passthru HTML, a tool to create it for you from a word-processor-like interface; it is a big timesaver. With version 6, the Notes client is also capable of rendering most HTML tags, which makes HTML useful when designing Notes client apps also.

For our purposes, a free or "comes with" HTML editor such as Microsoft Frontpage, is probably adequate. I am fortunate that my wife is a freelance Web site designer and we both work from home, so I have gotten spoiled -- when I want to create some HTML I ask her to go make us some tea or something and shift over to her computer for a few minutes, so I can use her copy of Dreamweaver MX 2004. I've been afraid to ask how much it cost us, but it's really nice.

A clip art collection on CD
For your control icons and decorations on your pages, you can get a lot of nice little GIF and JPEG files with an image search on Google. The problem with this is:

• They're usually not the exact size you need, and bitmap images don't scale very well unless they start out a lot larger than you need them.
• They're usually not free from copyright.
• It's hard to find all the images you need for a single app in a consistent style.

If someone can post a pointer to a clip art collection that has a lot of useful images on it -- not cartoon people with huge oval noses or anything that a three-year-old could have drawn -- that would be s-o-o-o terrific. It should be vector graphics -- not bitmaps of any kind, so that they can be resized without losing detail -- and should include lots of different pictures with many in a realistic style.

A vector graphics editor
If you're lucky enough to have an art department, you can get them to do this stuff for you; if not, you need to learn how to do it yourself.

I like to store my original images in vector form -- lines and shapes -- as opposed to bitmapped images, so I can resize them without losing detail and make new similar ones easily.

I use CorelDraw, which is adequate -- all right for the price.

A bitmap graphics editor
By which I mean something better than Windows Paintbrush. Again, I use CorelDraw because it's what I have, but Adobe Photoshop seems to be preferred by artists, probably mostly because it uses terminology they're familiar with. CorelDraw uses more geek terms, which is OK with me. Incidentally, the clip art I was complaining about came with Corel.

A decent programming font
A lot of people like the Proggy fonts. These are monospaced fonts that make it easy to distinguish between similar-looking characters and look nicer than Courier. If you've ever had a program that wouldn't compile because you had an "l" in a variable name in one place and a "1" in another, this is for you. (If it compiled but didn't work, then shame on you for not using Option Declare).

The one problem with the Proggy fonts is that they don't scale up well (not even the TrueType versions). Since I give presentations and like to be able to show code large enough for the audience to read, I use Andale Mono.

Other tools
Julian Robicheaux's NSF tools have been recommended to me recently by someone whose opinion I respect. I haven't had time to try them out myself, but they look promising.

Rocky Oliver's blog lists some free tools he's found useful.

It's going to be at least a couple of years before we attain that level of reuse here on Earth. But, in the meantime, any code you can find and reuse gives you that much more time to take that pellet gun and wait by the birdfeeder for the squirrels to arrive. So, before you write code, go search for an existing answer -- the birds will thank you. They'll also poop all over your car, but that's birds for you.

Some developers hoard bits of reusable code in much the same way that squirrels hoard nuts. Unlike squirrels (and fortunately for us), however, a few of them share their collections with the general Domino developer public. Of course, you can go to SearchDomino.com or the LDD forums and search -- always a good way to find answers to a question. But if you're looking for reusable code, there's a lot of chaff to sort through. So you're better off in that case going straight to the sources of high-quality pre-written subroutines and classes. Here's my list of best places to look for code. Readers, please chime in with any good ones I may have missed!

• OpenNTF.org -- This is a terrific source of complete applications that you can copy free of charge, though I encourage you to make a voluntary contribution to the authors of the application. The nice thing about open source communities is that they're packed with smarties -- er, experts -- who find the flaws in applications others post and either correct them or, at least, point them out so that the project owners can correct them. It makes sense to browse through these and see what's available. You might even see some things you can use right away in your environment.

  Beside the complete applications, there's also a "code bin" that shows how to do a plethora of useful tasks. This isn't maintained at as high a standard of quality as the applications are, but anything that's very wrong is at least likely to get commented on by the aforementioned experts, in time. So do read the comments posted in response to the code bin items!

• Martin Scott Consulting -- An online compendium of reusable code from a variety of sources, including many LotusScript functions (and function libraries), complex macro formulas, Java classes and C API code. An excellent resource.

• Codestore.net -- Run by Domino expert Jake Howlett, this U.K. site has a good collection of mostly high-quality code from Jake and many other contributors.

• IBM Lotus DeveloperWorks Sandbox -- This has a lot of good examples in it as well as downloadable applications that you can install and use. It doesn't, however, have the same level of quality control as some of the other sources listed here. Always read the comments others have posted.

• The View magazine -- Subscribers of this publication find it a good source of reusable code. Non-subscribers, though they can't read the actual articles without paying for a reprint, can still go to the Web site and, at no charge, download the sample files that accompany some articles. These are a good source of material for study and imitation. The articles in The View all go through a peer review process of sorts, though, in my experience, this applies only to the text of the article, not the design of any accompanying databases.

• TechTarget's Expert Answer Center and SearchDomino.com -- You probably already know about these sites, since you're here reading my blog. The expert answers are more reliable than the tips, which is why they call them experts. On the other hand, the tips are somewhat more likely to contain actual code. Again, pay attention to any comments people have answered at the end. And, do the rest of us a favor -- please don't vote on how good a tip is until you've actually tried it out! These are mostly not tested very thoroughly, and may easily fail if used in a situation the author didn't anticipate.

• SapphireOak.com -- Rocky Oliver, the heart of SapphireOak, speaks at a lot of conferences. And usually when he does, he makes a nice sample database to demonstrate how to do whatever it is he's talking about. The downloads section of his Web site contains several of these samples. These are generally not perfectly finished applications, because they're just a demonstration of the technology, but they do contain large chunks of code you can reuse.

• Domino Design Library Examples -- The examples in this database were all written or collected by me and Rocky Oliver. We tried to make sure that they are all of high quality, and I recently updated some of them for compatibility with ND6. The download includes a Notes database and a template. The database contains code snippets and documentation for the design elements that are stored in the template. Since some reusable tools in the template involve multiple design elements, the tool description documents contain a control to automatically copy all the needed design elements to a database you specify. You can also, of course, add your own bits that you've developed or swiped from elsewhere, making this a good personal or departmental repository.

• The Domino Designer 6 Developer's Redbook -- This book is a "how to" of Designer features and language information, not a code library. But the sample database that comes with it contains several examples of processing Rich Text using LotusScript.

• The Sametime Center database (stcenter.nsf) -- Available from Lotus, this is a good example of how to design Domino Web applications. Study the design and see what's there that you can borrow.

Disclaimer: No amount of peer review (or absence of criticism by the Web public) is a substitute for testing the code thoroughly yourself before putting it into a production application. The ultimate responsibility for making sure something will work in your environment and specific circumstances is yours.

Of course, the other side of finding other people's code to reuse is giving back. It makes sense, when you write your own code, to make it reusable if only so that you can reuse it yourself and in your company (about which I'll write more another day). And once you have some reusable code, why not share? Several of the above sites are eager to receive well-written code to post online. And then you will be famous and a beloved of the Domino developer community.

Good luck -- and good huntin'!

There are whole disciplines of project management, software engineering methodologies and tools that are a closed book to many Domino developers. I don't pretend to cover it all or even know it all myself. But I want to give you a little peek at a wider world.

Oh, and happy Valentine's day! I hope you are your valentine's valentine. And if you should by some mischance find your evening free, you could distract yourself and put the time to good use by thinking about improved error handling in your Domino applications or learn how to implement a company-wide error handling system.
Posted by Andre Guirard