Question

Search Box Function Like Current Web Search Engines

WebLink

Updated June 27, 2024

asked on June 25, 2024

We have a template that has a DocType field and a DocDate field. Documents with this template are available via WebLink and are searchable via custom searches pointed to those two fields. The customer is requesting to be able to put multiple values into the main search bar (like shown below) and have it pull back documents that have fields with either and/or both values filled in to any metadata.

Right now, putting either of those individually in, it successfully pulls back documents. However even though there are documents that have both, nothing comes back when both are put in. I understand that the underlying issue is that WebLink is using Laserfiche search syntax and that does not allow for searching for different terms across the fields.

As this is public facing, the customer is wanting this search box to function like Google where people can put in various data and it return the relevant results across all data associated with a document (metadata, text, name, ...).

Is there any way to have this main search box function more like how end-users are accustomed to using searches (e.g. Google)?
If not, is this something that is on the to-do list for WebLink?
- This would also be helpful in WebLink for the quick search bar

0 0

Replies

replied on June 25, 2024

Hi Beau,

Is there any way to have this main search box function more like how end-users are accustomed to using searches (e.g. Google)?

In short, no. Putting multiple search terms together into the search string is basically never going to work well.

The singular remotely plausible option here is to add a Document Text search you drop the search string into, in addition to the Fields. If the document is indexed and the strings in the search term show up in there, maybe you get some extra hits you wouldn't otherwise. It's more likely to lower search result quality by returning hits for either the DocType or Date, but not both. Wouldn't recommend.

If not, is this something that is on the to-do list for WebLink?

This would also be helpful in WebLink for the quick search bar

No, as the "issue" here is about how Laserfiche repository search works at a fundamental level and has nothing to do with WebLink. The WebLink quick search bar is essentially doing the same thing as the Web Client default quick search, where it drops the search parameter into an "EntryName (%search) OR AllFields(%search) OR DocumentText(%search) OR AllAnnotations(%search)" combo search. There's no simple way to add the functionality to the core search features that isn't at best a hacky overlay with punishing performance characteristics.

I've found the best way to avoid end user confusion in most cases is to do away with the Quick Search bar entirely and make custom Search Forms for everything that you link from the main page. This way you can make the input types clear with separate "Doc Type" and "Date" search fields (or other, as appropriate).

1 0

replied on June 26, 2024 • Show version history

Agreed. I usually do away with the quick search as well for this exact reason. However I am having more customers who are expecting a Google like experience for their end-users, especially when it is public facing. In order to keep pace with the end-user experience that people are growing accustomed to in their day-to-day lives, I am hoping this functionality is on Laserfiche's roadmap.

In the meantime, I am thinking of a few options:

1) Creating a large template field that holds all the document's metadata

Create an indexed field & populate with metadata
Have Workflow write the key metadata into there, separated by white-space

This would be the easiest of the options but I am not sure how Laserfiche searches these indexed fields via the Quick Search toolbars. Does it treat them like OCR text when it searches Indexed fields or are the searches the same for all fields no matter what?

2) Have Workflow inject the key metadata to the end of the document's OCR'd text

This one is tricky as they use DCC to index the documents and thus it would take a special Workflow that circles back to add the text in later. Also, there is not a built-in activity that updates the document text, so it would likely require an SDK script activity to accomplish this.

I am trying option 1 for now as that would open up a world of search options for my customers if it works. What are your thoughts on these options?

0 0

replied on June 27, 2024

For those who run into this issue, option 1 above did not work. The Workflow properly updated the new indexed field, the index service updated the index, but the quick search bars in WebLink and WebClient still searched it like any other field.

However option 2 did work great. I built a quick Workflow that runs after the docs have been OCR'd, that injects the template field values at the bottom of the first page text. A HUGE thanks to @████████as his code worked perfectly, with a few tweaks for my process.

2 0

replied on June 27, 2024

For Option 1, you could try making a "General Search" search form with one field and search syntax like:

{[]:[WebLink Search]~="(%SearchTerm)"}

From the Advanced Search Syntax 10.3 whitepaper:

The ~= Operator
To take advantage of full-text search features when doing text searches on entry properties, use the ~= operator. If you use the = operator, you can use wildcards, but not features like fuzzy search, the Within search, logical operators between search phrases, sub-queries, stemming, and ranking of search results. The following examples illustrate the difference between the ~= and = operators.

{[General]:[Category] = "my category"} will return entries with the General template and the Category field where the value of the latter is exactly “my category”.

{[General]:[Category] ~= "my category"} is a multi-word text search on Category fields that are part of the template General. This search will work only if the field Category is indexed. It will return entries that have both words “my” and “category” in a Category field that is in a General template (including results that are within the limits set by your fuzzy search settings and results matching related words determined by word stemming).

The Basic search syntax generated from Web Client with all options checked is:

{LF:Basic ~= "SearchTerm", option="DFANLT"}

Which appears to be an indexed search, but search I'm not actually sure how the field search portion of that is implemented on the backend.

0 0

You are not allowed to follow up in this post.

Question

Question

Search Box Function Like Current Web Search Engines

Replies

Sign in to reply to this post.