I appreciate the concept and what you are seeking as an admin, but to an end-user, that will go a long way to increasing animosity towards Notes. If a sought after word is deemed unsearchable, and they can see it on a document/form they will either (a) call the Help Desk, or (b) mumble that *%&$^ Notes product <expletive>. Which I think we would all like to avoid. :) For this reason, I will demote...

As a compromise, let's see if we can have FT compression, beyond where it is now. That would be a good thing.

If anything I'd like to see the ability to manipulate FT settings using lotusscript and not just on a database LOCAL to the script.

@Bill: It's never been the product, it's always been the developer and lack of testing. Having greater control over platform behaviour can only increase it's power, not reduce it. Hence the open source movement.

@Bill: I've seen end users call the help desk because the got search results and couldn't see the word in the document (for example a username who's hidden in reader field). So I would've been very happy if I'd had the opportunity to exclude some fields from FT index.

It should be the choice of the developer, shouldn't it?

@3) With all due respect, your open source argument is a non sequitur, as Notes will not be open source (and discussed passionately on a related Idea here). Customers lack the concept of a problem being focused to one small product area. They do know that, "I clicked a button and it didn't work. Therefore the product failed." Then, they call the Help Desk.

To alleviate, fix the back-end process to avoid this scenario dramatically. Empowering developers here compounds the effect--until the underlying issue is resolved. Then you can have discussion.


@4) Actually no, you can flag the document as having a search value in a hidden field; or exclude it at the server level. I can see where one might want it to be a dev property for custom apps, but not mail, as that should be an admin decision and perhaps set via Mail settings document...so there exists a divide here, based upon app-type.

One could also set a checkbox on the advanced search screen to hide documents with search matches in hidden fields. A customer does lack the concept of a document appearing due to hidden fields--it's a subtle concept, that eludes many. Either way, the solution here addresses a different matter than originally addressed, as Oliver's concern is less about performance and more about end-user lucidity.

@5 you miss one point just because the field is hidden, doesn't mean it's value isn't shown. Only the developer knows which fields have values that will be visible to an end users. We had to use an external search engine for a knowledge db. Why because people wanted to search on a name an see all docs created by that name. It would show any doc that had the name in any field. You can create a search form but it's a pain and hard to use. If you could force the user into a particular search form when they did a search in a view that would be a help.

@6) Hi Bruce... I know well that hidden fields provide visible data in some cases, and I appreciate the perspective here. Rather than go to an external search engine, why not just use a search query and store the search? Pretty simple to use. Choose the field in the DB with targeted value and store it for future use; the developer can provide the field name, since as you say, they would be the only one to know this.

Now, if the targeted value is changing with each query, then use a Notes query syntax in the respective DB's search field like this:
[Field_name] CONTAINS <user_name>
FIELD <field_name> CONTAINS <user_name>
field <field_name> CONTAINS <user_name>
(all are equivalent)

If you have setup the default to be web style syntax, and do not want to change the syntax to Notes style on a permanent basis, then pre-pend the search syntax with a "/" (sans quotes).

For fields that appear in a document header, rather than the field list (which a Developer would not have access to in their DB design), then use this format, as shown in these two examples:
[_CreationDate]=<date_value>
[_RevisionDate]=<date_value>

if you need to search for dates; I recall that your example indicated names, so I provided this additional example for completeness.

Hope this helps and addresses your point. Appreciate the comment.

If you can get an exec to type in that formula then you have smarter customers then me.

You can't programatically fill the view search bar via Notes.
You can't change the advanced search to make it easy to use.
They don't want to select a query.

The users just wants to enter a search value and see results, thats all.
also have the results appear in the view.

From the web, it's easier to manipulate the results. I use agents to do the search so I can fill table widgets.

It's been a problem for years. I use Omnifind and Google search appliance because they can be told what to index.

@8 With one simple formula, provided to an executive, I think it is possible. I know that they would prefer to just type it and make it all work, but that is where Notes' power creates some concerns as other products do less and appear to provide more (in some cases, not all).

To your point, I would prefer a FTI object class that allows a developer to put a FT query into an Action button, at the view level--for example. Then, you can code and filter to your hearts' content. Restricting the index though, is another matter entirely, and still not seeing the benefit. Restrictions there, appear to be a band-aid. You are advocating for a better interface and improved access, which I feel meets your needs as a coder and that of the end-user much better. If you want to draft that idea, I'll vote in favor of that.

Appreciate your perspective.

On review I believe the point has been teased out that the real problem is lack of control over the client perspective (ie Search Bar is untouchable programmatically), but also I'd like to add that since the rise of search engines with their default AND operator, has created problems for our users. Now being accustomed to what is now standard operation, the default behaviour of Notes search behaves oposite to what users now expect.

Example:

Red Cat in google finds the best combination of "Red Cat", with the full phrase hits afforded higher importance. (either/or/and)

Red Cat in Notes only returns hits with "Red Cat" exact phrase, whole words. If you want to find documents that have either word, you must use operators.

I'm not sure there is argument for reversing the default FT logic such that OR is assumed between words, any more than the argument that F9 should really be F5. However having at least some control as a developer provides a means of finding a solution, perhaps inelegant, instead of none at all. This is ultimately the point.

This is a great discussion...my idea was to exclude entire forms, but that did not deal with hidden fields you may not want to have indexed.

{ Link }

This has brought up some nice ideas.
It would be nice to have programmatic control over the search in a view. This could be done through a search property for the view that would allow one or more of the following:

1: List of Forms and/or fields that are searched in the view.
2: search string added to all searches but not displayed to user.
3: Have a search form be able to be displayed in place of the search bar. It would let you control what fields could be searched on and the building of the search string.

It's clear that the searching needs to be updated.

@10) In the Notes 8 client, there is a setting in N8 to have one use Notes search syntax or web-based and the default is web-style syntax.

From the Notes 8 Help Guide (annotated slightly for readability):
================================
If you prefer the web-style syntax for search queries, you need to do nothing since it is the default query type.

If you prefer Notes-style syntax as the default you can choose one of the following options:
(1) Select the preference Use (not web) query syntax in the view search bar.
To change this preference, choose File > Preferences and then click Basic Notes Client Configuration.

Then in the Additional Options list, select Use Notes (not web) query syntax in the view search bar

(2) Change the notes.ini setting UseFTSyntaxOnly=0 to UseFTSyntaxOnly=1.
-=-=-=-
Note: To switch to a Notes-style syntax for a particular query without changing the default web-style preference, you can prepend a forward slash (/) to the query, for example:

/sales results

This query only returns documents with these terms in the order specified.

@13 Wow. They slipped that one quietly under the radar. Thanks Bill.