Full text search of docs

[grumpyinca]

A full text search capability on the ODOP documentation (on-line Help) is desired.

There are various implementation possibilities producing various capabilities. For example: 15 Open-source Full-Text Search Engine Solutions for developers

As of this writing, a Google search with a site: parameter seems to offer a limited capability for minimum implementation difficulty.

Example ... Pass this search string (search criteria) as input to Google Search: site:SpringDesignSoftware.org/odop/docs Prop_Calc_Method

If the search string is unique to ODOP, the results can be focused and quite helpful. If the search string is generic, the result set is both less useful and includes ads.

If it was possible to automatically apply a browser "Find on page" to a page selected from the result set by the user, the leverage (utility) of this function would be greatly increased.

It is currently visualized that this feature would be implemented as an entry on the Help menu. Possible titles might include "Full Text ...", "Full Text Search ..." or "Full Text Search of Docs ...". See the next comment for more on this point.

One possible interim approach is to have the Help : Full Text Search entry simply go to a Help entry that describes the process of using the site: syntax in Google search followed by a browser "Find on Page".

Note: It appears that only Google uses the "site:" syntax. No luck with Bing, Yahoo, Baidu & DuckDuckGo.

[grumpyinca]

From today's conversation on the subject:

Text Fragments Text Fragments Text Fragments

Google's Programmable Search Engine

Rather than positioning a "Full Text Search of Docs ..." entry on the Help menu, it would be better aligned with industry practice to have a text entry box on the menu line (to the right of Help and to the left of the design type icon). There should be a magnifying glass icon to the right of the text entry box. The lookup action should be initiated with a carriage return or a click on the magnifying glass icon. The results can be presented in a new browser tab. The entry box could have a dimmed text saying something like "On-line Help lookup". See client/src/components/MainPage.js.

[1fifoto]

Added a text input field and magnifying glass icon button. The input responds to 'enter' key.

Entered 'default design' and separate windows appears showing the following entries:

[1fifoto]

Merged into master, closing

[grumpyinca]

Reopening for two reasons.

1. It appears that contrary to initial impressions, the CNAME odop.springdesignsoftware.org/docs has not been fully indexed by Google. For example, when using the version of the app in the current development master with a search string like "stress", "cloud" or "Prop_Calc_Method". The search will completely fail or produce a significantly smaller result set that achieved with {searchstring} site: https://springdesignsoftware.org/odop/docs. The results seem quite erratic or inconsistent.

2. More testing is needed with a default Search engine that is not Google and default browser that is not Chrome based. Given lack of success in those situations, is there anything that can be done to improve the user experience ?

Note: SearchDocs.js submits the query directly to Google Search. The user's default browser configuration is not an issue.

[1fifoto]

Removed from production release. Disabled for production

As a alternative we could build our own index when we generate the documentation using harp or some equivalent. Did a Google search of "javascript indexing static pages" and found: How To Make Your Static Website Interactively Searchable which refers to Hugo and Lunr

Yet another alternative is: How to detect Chrome default Search engine

[grumpyinca]

Opened issue #676 to provide a place to experiment with Lunr.

Note that Lunr is the first item on the list of 15 full-text indexing solutions noted in the original description of this issue.

[grumpyinca]

The spreadsheet attached here provides a summary of indexing "hits". The bottom line is that the CNAME based docs hosted on Heroku are not indexed as well as the (now orphaned) docs hosted on Dreamhost (SpringDesignSoftware.org). Neither set has 100% coverage of the files as determined by Eclipse search of the source .md files. The totals for the arbitrary set of ~34 search strings are: 68 | 164 |  396

HelpLookupIndexing.ods

[grumpyinca]

An indexing approach based on Lunr is looking like the superior alternative. Closing in favor of #676.