New Result Options in the FT Search Manager

For many years now, the FT Search Manager has been presenting search results in table format, like a Notes View;

This is useful because it allows additional functionality like re-sorting results by column, then 'Jumping To' results starting with a specific string;

It also allows re-searching by Facet, as show here with a Date facet;

However some users rightly complained that they found the spacing on large screens difficult to navigate, and when we looked at common web search engines, they had a point. Those search engines all truncate result widths at 100 characters or less.

Therefore we've allowed users to (optionally) select a different result format. Like all the other options, Administrators can default it to their preference then prevent it being changed, or let users decide.

This then displays results truncated in a 'list' format, with the UI being customisable as usual;

Re-sorting results by column and facet-based searching is no longer possible, but you can still perform other functions, like selecting & processing results (and you can define your own processing options also);

For more information, demos & downloads, please visit the FT Search Manager page. 

Adding Google-style Category-based searching

The latest addition to our Notes FT Search Manager is (optional) Category-based searching directly from the Results Page, as per most common Web search engines. 

This means the Results Page also displays the available Categories, so users can refine their search, using both Notes or Web. 

If you're using a Category-based search originally, the Category list is the same, otherwise it's based on the Categories defined for your selected Databases (and even documents within each Database can be defined as different categories).

This functionality also applies to Domain Search and Frame/iFrame based searching.

For example, from a Web search like this;

You get results back like this (the 'Category' area, colours, fonts, logos etc are all customisable via CSS);

You can then click each category to search again using the same criteria, but limited to that category only, e.g. here searching only the 'File Systems' category; 

and again in the 'Directories and Bulletin Boards' category;

The same functionality also applies to the Notes Client;

For more information or a demo version, please visit http://www.ionetsoftware.com/search.

Speeding up Notes applications

Our FT Search Manager product (http://www.ionetsoftware.com/search) has been around for a while now, and being a search tool, we're always trying to increase it's search speed. The latest version (4.6 - sound familiar?) is a lot faster than previous versions - FYI here's a short YouTube demo showing the faster speed achieved http://www.youtube.com/watch?v=FFcxSQ8PaIM.

If anyone's interested, here are the main methods we used to speed it up;

1. Each multi-threaded search agent only populates up to the first page of results (e.g. 10 results if that's how many results are displaying per page) then writes it's full result set to a storage document. It only populates the first X results because that's the slow part - getting data from each document. The last agent to finish assembles all the results, re-sorts them, then presents them. The first couple of pages are already available, and the remaining stubs are then populated in the background, which means the first page displays in the shortest possible time.

2. Concatenating evaluate statements. We use fields & @formulas to return document data. If there are 4 fields & @formulas required, it's much faster to execute one evaluate statement, e.g. Evaluate(@formula1 : @formula2 : @formula3 : @formula4, NotesDocument), rather than repeating it 4 times.

3. Using NotesDocument.Save only when necessary.

4. Using NotesRichTextItem.GetUnformattedText instead of GetFormattedText.

5. Using Lists to store commonly used databases, views & variables.

6. Using the LS 'Split' function as much as possible.

7. Moving everything unnecessary out of loops.

8. Performing only one @DBLookup to get all required data in one operation, then splitting the results into separate fields.

9. Storing data in Profile documents and only retrieving new data if the relevant option changes.

Hopefully someone finds these points useful.