Being the ultimate container to store structured and unstructured information, Notes databases are a knowledge worker's dream. But having all this information doesn't do you any good useless if you can find it!

Views are a very useful way to present and find information, especially if documents are categorized in various ways, such as by author, subject, date, or keywords. Plus, while in a view, you can press Ctrl+F to search for text that appears in that view. But because views can't display rich text, you must still open each document to see if it contains the information you are really looking for.

To speed up this information retrieval process, you can create a full-text index of a database, including all document text, rich text, and even attachments, and then search for words or phrases to quickly locate relevant documents.

This article is the second in a series of articles that focuses on application strategies. In the first article, we describe a rules-based task assignment application. In this article, we build an interactive search application. To increase the accuracy and relevance of searches, this article demonstrates how to tap into different ways of locating and discovering document content.

Full-text search

To enable full-text search, a user with Designer-level access or greater must first create the full-text index. This can be done from the Database properties dialog box or the Search Bar (as well as from the Domino Administrator).

To use full-text search, open any view and choose View - Search This View to turn on the Search Bar. Enter the desired search word, phrase, or Boolean phrase in the Search for field, for example:

Click the Search button to return the found documents in the context of the current view (column formulas and selection formulas apply to the results) with the more "relevant" documents listed at the top, for example:

When you want to clear the search results, click the Clear Results button.

Back to top

Challenges for Search Bar users

The Search Bar is indeed very useful to the savvy user; unfortunately, its power becomes somewhat of a liability to basic users for these reasons:

• The query language used in the Search for field is very flexible, but somewhat daunting. Without a thorough understanding of the query language, you cannot precisely locate information and will waste time manually scanning documents for content. The query can include such things as:
  • Word, phrase, or quoted phrase (for an exact match)
  • Wildcard characters asterisk (*) and question mark (?)
  • Boolean operators such as OR, ACCRUE, AND, or NOT
  • Parentheses to logically group search terms
  • Specific document field values using FIELD, CONTAINS, and equivalence operators, such as =, <, >, <=, and >=
  • Special query operators that increase the relevance of your search terms, such as EXACTCASE, SENTENCE, PARAGRAPH, or TERMWEIGHT (NEAR was dropped with R5)
• It is easy to become confused when a query is rejected for incorrectly using any of the reserved query language words. (You can search for search language reserved words and operators by surrounding them in quotes, for example: mortgage and "accrue".)
• Starting with the implementation of the IBM Global Text Retrieval (GTR) search engine in Notes R5, stop word files are no longer supported. This means that more results may be returned than expected when your query includes words common to virtually every document.

Much of the design of the More panel in the Search Bar was intended to overcome the starkness of the Search for field by providing a more user-friendly shell:

Here you can click the Conditions buttons to access dialog boxes (Date, Author, Field, and so on) to create the query without knowing the query language. You can even add multiple conditions and use Boolean operators to refine your search:

You can also set various options to widen or narrow the results. Users like the Search in results option, so that they can do one search at a time and keep narrowing down the results with additional terms. You can sort the results can by date or relevance (see below). Fortunately, the options you set here are "sticky" on a per-database basis, so you can, for example, sort the search results from one database differently from another database and the search options are retained until you change them.

The meaning of relevance

Sorting the documents by relevance puts them in order of the number of matches found in a document as compared to the number of matches found in other documents. The relevance rank of a document is elevated for a variety of reasons, for example:

• The document contains five instances of your search word and another document only contains one instance (hit frequency)
• The document contains more matches per total word count (hit density)
• When searching for multiple terms, a document contains more of the search words than another document (completeness)
• Matching words are closer together (proximity), and you have used the advanced query language operators:
  • PARAGRAPH (instead of AND; two of your search words are in the same paragraph and close to each other)
  • SENTENCE (instead of AND; two of your search words are in the same sentence and close to each other)
  • ACCRUE (instead of OR; emphasize the first term and then count both the number of the second search word matches and the density of those matches)

Back to top

Search Bar challenges for developers

For developers, the Search Bar is off limits other than to turn it off or on. You cannot programmatically drive a query into the Search for field and return the results to the view. So it is up to users to enter their own queries in the Search Bar. Further, users must have Designer-level access or greater to save a search, and saved searches cannot be created programmatically. So you, as a developer, may be asked to create commonly used queries and save them for users.

Custom search forms

Just because you can't programmatically operate the Search Bar doesn't mean that you can't submit queries to the full-text search engine from a custom search form or a dialog box. While you can't return the search results from a custom search form to a view, you can return the results to a folder or to a newsletter, which we'll show you later in this article.

There are two examples of custom search forms found at the developerWorks: Lotus Web site worth noting. In the Sandbox download SuperSearch, Vilhjalmur Helgason provides a structured way to precisely locate documents using field-specific conditions:

> In the June 1997 Iris Today article, "Adding a Friendly Ad-hoc Query Tool to Domino applications," Mark Gordon opens a special form to build a query that has search conditions very specific to the application:

Both of these examples shield users from the complexities of the Search Bar and the query language and return the found documents to a folder where users can sift the results (no relevance ranking is provided). While these custom search forms replace the guesswork of using the query language, they don't really provide any capability beyond what a savvy user has available from the Search Bar. The techniques this article shows you extend beyond the capabilities of the Search Bar with alternative ways to interactively search for information.

Interactive search can be considered an application strategy in that it combines design elements and techniques to make up a value-add feature that you can easily add to any application in which users need to search for information.

Custom search form in practice

Before we talk about the interactive search tools, let's look at the custom search form included in the Interactive Search application. When you open the database, you see a page with an embedded outline control in the left frame and a frame with a view on the right. A third frame, on the lower left, displays the MiniSearch form, allowing you to conduct a full-text search right from the opening frameset:

Note: To make things more interesting, we added these search features to a few documents copied (and stripped of graphics) from the LDD Today database.

This diagram shows the sequence of how to demonstrate the custom search form:

Step 1
Before you attempt searching the example database, open the Database properties dialog box and create the full-text index. Because you have copied the database to your local Notes data directory, you have de facto Manager access and can create the index.

Step 2
Click Application Settings in the outline to open the Application Settings profile document. This is where the database administrator defines the list of words to exclude from searches:

To give you a head start on a common word list, click the Append Defaults button. Click Save and Close to save the profile document.

Though not done in this database, it is presumed that you will limit who can edit the profile document to one or more database administrators, typically defined in the ACL as members of some role like [DBAdmin].

Step 3
While you could enter a search term in the MiniSearch form on the left, click the Advanced hotspot to open the Search form. The Search form opens to the Words or Phrase tab. For now, click the Search Options tab to set your personal search options.

These are pretty much the same options you can set from the More panel in the Search Bar, giving you the ability to refine the query and how to display the results (sort order and number of documents to list). This table describes the options you can set on the Search Options tab:

These options will be used by both the MiniSearch and Search forms as well as by other databases that use this custom search form. To reset the options to the default values, click the Restore Defaults button.

Step 4
Now click the Words or Phrase tab to conduct a search.

For demonstration purposes, we reveal the FTSQuery1 field and put it in red so you can see the query passed to the FTSearch method. (You should hide this field when you add this form to your application.)

Also remember that because you defined the common words in the profile document, they are stripped out of the query by the formula in the FTSQuery1 field. And if you select Any of these words or All of these words, the reserved query language terms are also stripped out of the query. For example, select Any of these words and enter this query:

I want to use lotusscript in a sentence

Press F9. Because the words I, to, use, in, and a are in the common word list and because sentence is a reserved query language term, the resulting query is:

Change the query type to All of these words and press F9 again. The OR is changed to an AND. (The date part of the query comes from the Document age setting on the Search Options tab.) But what if you want to include the common words in the query?

• Simply change the query type to Exact phrase and the whole phrase is surrounded by quotes.
• Choose Boolean phrase if you already know the query language and don't want the common or reserved query language terms stripped out.

So you still have total control over the search if you need it. This table summarizes the query types on the Words or Phrase tab:

Part of the fun here is to change the field values on this tab and on the Search Options tab to see the impact on the query. For example, click the Search Options tab and choose:

• (just) LDDArticle as the Document Type
• Add Wildcards - Yes

Click the Words or Phrase tab and press F9 to see the updated query in the FTSQuery1 field. The assumption of any word search is that the document author spelled the words correctly. Select the Spell Check option to verify that YOU have spelled your search words correctly before clicking the Search button. The benefit of the Words or Phrase tab is that it helps you:

• Build your query without having to know the syntax of the query language
• See the results of the search in a newsletter
• Return to the (still open) Search form and modify the query as desired

Step 5
Click the Search button to send the search to the full-text search engine and display the results in a newsletter formatted by the SearchResults form. The advantage of using the NotesNewsletter object over a folder is that a newsletter can display the query, list the results in order of relevance, show a doclink to open the document, and display the document title, for example:

Other advantages of the newsletter are:

• It contains a record of the query (which you can copy and paste into the Search Bar), the database name, and number of documents returned.
• You can edit and forward the search results to another user (or to yourself!) by simply clicking the Forward action button. If the recipient has the ability and rights to read the database, the doclinks are all live.
• You can copy the results and paste them into another Notes document.
• With about five minutes of design work, you can add a Save action button and a view of saved searches to the application design, so users can share the results of commonly requested searches. (Be sure to create a Search again action to update the results using the same query.)

Back to top

Search form

Let's take a look at how the search programmatically passes a query to the full-text search engine and returns the results to a newsletter. Here is the Words or Phrase tab in Domino Designer:

There are a few important things to point out on this tab in the Search form:

• The FTSQuery1 field computes the search query using what the user enters into the SearchWords field. It strips out the common words and query language reserved words, includes several of the parameters from the Search Options tab, and depending on the Clause chosen (Any of these words, All of these words, and so on), formats the query appropriately. (See below for a description of the FTSQuery1 field formula.)
• The Search button code is surprisingly simple because the FTSQuery1 field did all the hard work.
• The SaveOptions field is hidden, Computed when composed and always set to 0 so that users can never save the document.
• The $ASteps and $TSteps fields are also hidden, Computed when composed, used by the Ask and Troubleshoot tab Next/Previous buttons to progressively reveal the next step (switch table rows programmatically).

The Search button contains the code to conduct the search and create the newsletter. Open the Click event of the button to follow along with the explanation of the significant lines of code. Before you read the field values, make sure that the FTSQuery1 field is updated.

Call uidoc.refresh()

After some error trapping, the meat of the code starts on the following line, returning the results of the FTSearch method to a NotesDocumentCollection:

Set collection = db.FTSearch(thisdoc.FTSQuery1(0), Val(thisdoc.QTY(0)), Val(thisdoc.SortBy(0)), getVariants(0) )

You can consult the Domino Designer Help to learn about the parameters of the FTSearch method, all of which are determined by the settings on the Search Options tab.

Now that you have a collection of documents, you can see if any documents are in the collection and if so, instantiate the NotesNewsletter object starting in the line: Set newsletter = New NotesNewsletter (collection).

If collection.Count = 0 Then
   Msgbox "There were no matching documents using your words or phrases.
   Please try again.", 16, "Nothing Found"
   Exit Sub              
	Else	
		Set newsletter = New NotesNewsletter( collection )
		newsletter.DoScore = True
		newsletter.DoSubject = True
		newsletter.SubjectItemName = "Subject"
		Set doc = newsletter.FormatMsgWithDoclinks( db )
		doc.subject = thisdoc.FTSQuery1(0)
		doc.form = "SearchResults"
		doc.SaveOptions = "0"
		Set uidoc = w.EditDocument(False, doc)
End If

In the previous code snippet, the lines that begin with newsletter format the newsletter with a relevance rank and title. The line: Set doc = newsletter.FormatMsgWithDoclinks ( db ) shows how to stuff the newsletter into a new back-end NotesDocument object while at the same time formatting the newsletter to display a doclink next to every search result. This line sets the form to SearchResults: doc.form = "SearchResults".

The next line ensures that the document opened in the SearchResults form cannot be saved. If you change the design to allow users to save searches, be sure to remove this line. The final step in the line Set uidoc = w.EditDocument (False, doc) is to open a new window in Notes and open the back-end document in a front-end NotesUIDocument object so that the user can read it.

The Keywords and Ask tabs use virtually the same logic to pass a search query to the full-text search engine and to return the results as a newsletter.

FTSQuery1 field formula

Because the FTSQuery1 formula is responsible for the query parameter of the FTSearch method, we want to take a minute to highlight how it works. The first task is to read the (multi-value) common word list from the profile document:

CommonWords:=@GetProfileField("ProfileDoc"; "CommonWords");

Next we concatenate a multi-value list of reserved search language terms and the common words and use @Replace to remove all of them from the user's search words:

CleanWords:=@Trim(@Implode(@Replace(@UpperCase(@Explode(SearchWords)); 
"FIELD":"TITLE":"OR": "AND": "NOT": "EXACTCASE": "SENTENCE": "PARAGRAPH": "NOT" : 
\"TERMWEIGHT": CommonWords; "")));

If the user has chosen to use wildcards on the Search Options tab, we then surround each word with the asterisk (*) wildcard character:

WildCleanWords:=@If(WildCards = "1"; @Implode("*" + @Explode(CleanWords) + "*"); CleanWords);

Depending on the type of search selected by the user, we put the appropriate query language operator between the search words:

SearchWordQuery:=@If
(
	Clause= "1"; @Implode(@Explode(WildCleanWords); " AND " );
	Clause= "2"; @Implode(@Explode(WildCleanWords); " OR " );	
	Clause= "5"; @Implode(@Explode(WildCleanWords); " ACCRUE " );
	Clause= "6"; @Implode(@Explode(WildCleanWords); " SENTENCE " );
	Clause= "7"; @Implode(@Explode(WildCleanWords); " PARAGRAPH " );
	Clause= "3";  "\"" + @Implode(SearchWords) + "\"" ;
	@Implode(SearchWords)
);
Query:=" AND (" + SearchWordQuery + ")";

An important distinction for the preceding code is that for Clause=3 (Exact phrase-->) and for the else clause (in this case that means the Boolean phrase-->), the SearchWords field is used verbatim (we don't remove the common words or reserved query terms and don't add any wildcard characters). Although we haven't mentioned it yet, the DateSpec field (on the Search Options tab) concatenates the three user choices into a single query phrase to cut the number of documents based on either date field stored in the documents:

DatedWords:=" (FIELD " + DateSpec+ ")" ;

Having the DateSpec field do that work saves us from having to do it in the FTSQuery1 formula. Another setting on the Search Options tab is the form used to create the document, so part of the query phrase must be to cut the number of documents based on one or more form names:

DocQuery:= "(" + @LeftBack(@Implode("[Form]=" + @Trim(DocTypes) + " OR " ); 3 ) + ")";

Now that we have all the pieces of a search phrase, it is time to put them altogether into one phrase. We suspect we could have been more elegant in our logic here, but we wanted to keep the four possible conditions distinguishable (we have bolded them here so you can see them more easily):

@If(DocTypes!="All" & CleanWords!="";
		DocQuery  + " AND " + DatedWords + Query;
	DocTypes!="All" & CleanWords="";
		DocQuery + " AND " + DatedWords;
	DocTypes="All" & CleanWords="";
		DatedWords;
	DocTypes="All" & CleanWords!="";
		DatedWords + Query;
	DatedWords + Query
)

If you selected the All forms option, you don't need to add the search phrase that looks for all the possible form names; just leaving off that phrase entirely has the same effect (and is faster for the search engine). If the result of common word/search term removal results in no words, you don't want to include the Query part of the search.

The idea behind these four conditions is to always return a valid query to the FTSearch method regardless of whether or not any documents will be found by the search. Otherwise there is no advantage to using this custom form over the user making an attempt to use the Search Bar!

Keywords tab

The Words or Phrase tab really offers no added capability beyond what you find in the Search Bar, but it may be easier for novice users. Generally, when you search, you must have some prior knowledge about what you are looking for; otherwise, you spend time guessing which terms you think multiple document authors have used. This trial-and-error method can lead to unpredictable and unreliable searches.

With the Keywords tab, the nature of searching is distinguished from the Search Bar by adding an element of intelligence to the searching process:

Because the keywords come from the hidden view Keywords (which selects only documents that contain keywords), users don't need to know ahead of time which words to search for. So when they perform a search from the Keywords tab, they are guaranteed predictable and reliable results. As the searcher, you can scan the list of keywords and select those that match what you are looking for. Only the keywords of documents are searched during a keyword search, using an OR or AND relationship.

Similar Documents action button

If you haven't yet opened a document in the Interactive Search database, do so now. Do you see the Similar Documents action button?

This action uses almost the same logic of the Keywords tab on the Search form, except that instead of requiring you to select keywords from a list, the action uses the keywords in the current document to find other documents. If you saved your settings on the Search Options tab in the Search form, you will find that the Similar Documents action button reads your preferences from the Notes.ini file when searching for similar documents and displaying the results.

Prepare documents for keyword searches

Keywords have some connection to the concepts presented in the document. Some keywords provide a direct connection, while others are more secondary. Equally as important, like an index in a book, keywords identify documents with similar characteristics even though they may not be of the same document type or have anything else in common.

To make searching by keywords possible, document authors (or editors/knowledge librarians) are responsible for adding descriptive keywords to their documents. The mechanics of adding keywords to documents is made possible by adding the InteractiveSearchSupport subform to the existing forms. (In the example database, we put it at the bottom of the existing Pub subform.)

When you create or edit a document, the InteractiveSearchSupport subform appears at the bottom of the container form:

To enable keyword searching, the document author adds one or more relevant words in the Keywords field. The Keywords field allows multiple values and allows values not in the list, so document authors can add new values as needed. As more and more documents are given keywords, the richness of searching by keyword increases.

Note: You see below how the other types of searches in the Search form use the other fields in the InteractiveSearchSupport subform.

Input to the Keywords field is controlled to clean up the list and to prevent characters that cause problems for the full-text search engine:

• Input Translation formula to make sure the list is sorted and contains unique, non-blank values: @Sort(@Unique(@Trim(@ThisValue)))
• Input Validation formula to make sure invalid characters are not used (they cause problems for the full-text search engine and for the other types of searching): @If(@Contains(@ThisValue; "(":")":"]":"[":"~":";":",":")":"("); @Failure("Sorry, you cannot use these symbols in this field: ~ , ; [ ] ( )"); @Success)

The Keywords field dialog list is fed by the hidden view named (Keywords) to help promote consistency across documents. To make sure that searchers find documents described by a selected keyword, the (Keywords) view selects only documents that have keywords:

SELECT Keywords!=""

This view also feeds the keyword list on the Keywords tab used by searchers.

Note: The InteractiveSearchSupport subform also includes two hidden fields to capture the original document creation date (PostedOn) and the last modification date (ModifiedOn), which relates to the date options set on the Search Options tab when searching.

Ask tab

With the Ask tab, the nature of searching changes again by allowing you to enter a question or pick from a list of questions that authors have added to their documents. Although there is no natural language engine behind the search, the process of creating questions forces the document author to think like a user who wants to discover what the document contains. As a user, Step 1 on the Ask tab is to type in your question. You do not need to add a question mark. If you want to browse a list of questions, click the Pick Question button.

When you have asked your question, click the Ask Question button. The Ask Question button code scrubs the words in the question to remove common words and reserved query language terms and then searches for matches just in the Questions field (using an OR relationship between the words). Your results will improve if you:

• Make your question concise, avoiding multiple sentences or clauses
• Use a phrase or complete question (a question mark is not necessary)
• Include specific information about a particular model name/number or service
• Do NOT include Boolean operators, such as AND, OR, and NOT

To increase the odds that your question will be interpreted in the widest sense possible, the Ask Question button code has these FTSearch options hard coded:

• FT_STEMS (512) uses stem words as the basis of the search.
• FT_FUZZY (16384) searches for related words. Need not be an exact match.

Note: FT_THESAURUS (1024) was dropped with R5, so we didn't include that option.

The Ask Question button also advances you to Step 2, which returns a list of questions that have been answered by document authors and that include search terms found in your question.

Select a question and click the List Answers button. Documents that answer the same question that you selected in Step 2 appear in the embedded view.

Double-click the desired document in the view to open it. If you want to try another question, click the Previous Step button to pick or ask another question.

Prepare documents for Ask search

Ask tab searches are based upon the questions that document authors write on the InteractiveSearchSupport subform. As more and more authors include questions on this subform, Ask tab searches return progressively rich results. The questions, of course, should be answered by the document. To provide for better searching, document authors should write their questions using the standard who, what, where, when, why, and how.

Also, to increase the number of documents returned by a user question, if at all possible, document authors should reuse the exact questions from other documents. To make this easier, the hidden view named (Questions) is used in the Questions field in the InteractiveSearchSupport subform. The (Questions) view selects documents using this formula:

SELECT Questions!=""

This view also feeds the list of questions that appears when searchers click the Pick Question button on the Ask tab.

Troubleshoot tab

The Troubleshoot tab lets you solve common problems by narrowing them down to their essential components. This tab doesn't actually use full-text search, but it does provide an alternative way for users to locate answers to their problems. Although this is designed as a product-oriented troubleshooting tool, you can easily repurpose it to solve non-product oriented types of problems. As a user, the first step is to select a product from the list (AppliesTo field):

Click the Next Step button to advance to Step 2. The button refreshes the hide-when formulas on the form so that Step 2 (Row 2 of the table) displays; and the Refresh fields on keyword change option on the AppliesTo combobox forces the lookup in Step 2 to display only the Categories that are related to the selected key value:

Click the Next Step button to advance to Step 3. Using the choices from Step 1 and Step 2, Step 3 performs a lookup of Subjects that match the selected AppliesTo ~ Categories value. Step 3 is where you select a statement that you think might solve your problem (a list of Subjects):

Finally, click Show Solution to see the first 500 characters of the document Body field. This is the result of a lookup using the AppliesTo~Categories~Subject key:

To open the document to read more, click Show Details.

Prepare documents for Troubleshooting tab

Document authors must check the Use for Troubleshoot tab checkbox at the bottom of the InteractiveSearchSupport subform to include the document in the Troubleshoot tab; they are then required to enter information in all of these fields:

You may have seen two hidden fields in the InteractiveSearchSupport subform: TroublePick1 and TroublePick2. The values for these fields are populated during the QuerySave event of the InteractiveSearchSupport subform:

Sub Querysave(Source As Notesuidocument, Continue As Variant)
	If doc.Troubleshoot(0) = "1" Then Call TroublePick
End Sub

The TroublePick subroutine is responsible for creating permutations of the AppliesTo and Categories fields (both are potentially multi-value) in the TroublePick1 field, and permutations of the AppliesTo and Categories and Subject fields in TroublePick2. The outer loop starts with the first value in the AppliesTo field starting on Line 17 and then the inner loop reads through all the potential values in Categories in lines 18-21. The field values are concatenated using the tilde ( ~ ) as the delimiter.

Here is the code from the TroublePick subroutine (under the Globals events in the InteractiveSearchSupport subform):

Sub TroublePick
	Dim item1 As NotesItem
	If doc.HasItem("TroublePick1") Then 
	Set item1 = doc.ReplaceItemValue( "TroublePick1", "" )
 Else
	Set item1 = New NotesItem( doc, "TroublePick1", "")
 End If
 Dim item2 As NotesItem	
 If doc.HasItem("TroublePick2") Then 
	Set item2 = doc.ReplaceItemValue( "TroublePick2", "" )
 Else
	Set item2 = New NotesItem( doc, "TroublePick2", "")
 End If
 one = doc.AppliesTo 	
 two = doc.Categories 
 getSubject = Evaluate(| @Trim(@ReplaceSubstring(Subject;"[": "~":";":",":@NewLine;" "))|, doc)
 Forall a In one
	Forall b In two
		Call item1.AppendToTextList(a & "~" & b)		
	 	Call item2.AppendToTextList(a & "~" & b & "~" & getSubject(0))
	End Forall
 End Forall
End Sub

The result of the Call lines is the creation of two multi-value items:

• TroublePick1, for example: "Domino Designer~Application Development" : "Domino Designer~Web Applications" : "Notes~Application Development" : "Notes~Web Applications"
• TroublePick2, for example: "Domino Designer~Application Development~Creating dynamic categorized views" : "Domino Designer~Web Applications~Creating dynamic categorized views" : "Notes~Application Development~Creating dynamic categorized views" : "Notes~Web Applications~Creating dynamic categorized views"

The TroublePick1 and TroublePick2 fields are then used for the lookups to the Troubleshoot Problem Statement and Troubleshoot Solutions views in the last three steps of the Troubleshoot tab. This table describes the three hidden views that support the lookups performed from the Troubleshoot tab:

Back to top

Summary of design elements

To use these search features in your application, copy these design elements from the example database to your database:

• Forms: Search, SearchResults, ProfileDoc, MiniSearch (optional)
• Views: Categories, Keywords, Questions, TroubleshootProblemStatement, TroubleshootProductList, TroubleshootSolutions
• Subform: InteractiveSearchSupport

It is up to you to configure your application so that:

• Database administrators can open the ProfileDoc form as a profile document.
• Users can launch the Search form.
• If you use the MiniSearch form, a frameset displays the form.

You can follow the example of the HomeOutline Outline control.

Back to top

Conclusion

Information is useless if it can't be found. By utilizing this application strategy, you can encourage your company's document authors to more thoroughly describe their documents. Alternative search tools such as keywords, questions, and troubleshooting allow users to think about document content in different ways, thereby improving your organization's ability to manage volumes of knowledge tucked away in Domino databases. And because you are adding these features to a Notes application using Domino Designer, it takes very little effort to quickly realize significant benefits.

Resources

• Download the sample application with the Interactive Search form from the Sandbox.
  
  
• See the other articles in this series:
  • Notes application strategies: Rule-based task assignment
  • Notes application strategies: Mail processor
  • Notes application strategies: User activity tracking
  • Notes application strategies: Document rating
  
  
  
• See the LDD Today article, "Adding a Friendly Ad-hoc Query Tool to Domino applications," for another custom search form.
  
  
• Download SuperSearch from the Sandbox for another custom search application.
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Full-text search
• Challenges for Search Bar users
• Search Bar challenges for developers
• Search form
• Summary of design elements
• Conclusion
• Resources
• About the author
• Comments

Next steps from IBM

• Try: Lotus Notes and Domino Administrator
• Demo: Lotus Notes 8 composite applications
• Webcast: Modernization approaches to reduce the total cost for multi-platform enterprise applications
• Briefing: Smarter collaboration with IBM Lotus solutions
• Buy: Lotus Notes and Domino Administrator

My developerWorks community

Dig deeper into Lotus on developerWorks

Calling all developers

Download no charge Lotus Domino Designer

Special offers