Autocomplete usage producing unusable results

[swcurran]

Something has changed in the auto-complete usage that is making it pretty unusable.

When I try to search on something that is a legal name I now get mostly BC Registry IDs in the autocomplete, which is pretty useless. See the example below. Most of the searches I do these days are producing the same result.

Can we make what shows in the drop down smarter? Something like:

• If all the characters are digits or the first two characters are letters and the rest digits
  • Show the current autocomplete results.
  • For bonus points, make it "If the first two characters are BC Registry identifier prefixes"
• Else
  • Filter out the BNs and BC Registry ID results from the dropdown

Not sure what this would do to paging, but for autocomplete, we just need 10 (? or so?) entries. Perhaps what is needed is the autocomplete API call is smarter?

[WadeBarnes]

Based on the release history the last search changes were made in v1.0.5

[amanji]

This needs a bigger discussion, IMO. The issue stems from https://github.com/bcgov/aries-vcr/pull/734 to allow for autocomplete to be used in form-filling scenarios where the Registration Number or Legal Name is required (i.e. not having to dispatch multiple API calls to get the Registration Number or Legal Name from a preliminary autocomplete lookup).

OrgBook API currently has multiple types of indexes (Name, Topic, and Credential). The 'strata' query string in the example is matching on two types of indexes: The Name index and the names list in the Topic index.

My initial thoughts are that it might be easy to either consolidate search results (post search processing) or we remove the Name indexes altogether (they are redundant if Topics include active names). The caveat here is that CRA 9-digit Business Number is a Name index. Therefore, we would likely have to reindex Topic to include the CRA 9-digit Business Number as well.

While the effort for reindexing would be greater than simply post processing search results it could actually cut down the number of indexes we have and need to populate going forward.

Thoughts @swcurran @esune @WadeBarnes ?

[WadeBarnes]

I think a meeting to discuss the technical details would help. I become concerned whether the term reindexing is used, but if we can increase usability and reduce the number of indexes I'm happy.

It seems like we're trying to cover multiple use cases with a single solution that is not providing a good user experience. Name search and registration number lookup are two completely separate use cases in my opinion. When you're searching for an org in OrgBook you expect your autocomplete results to relate to what you are typing. For most people using the interface having registration numbers popping up when they are typing in a business name is super confusing. Worst of all is as you type out the business name the top matches switch between business names to registration numbers (@swcurran example), which is even more confusing. The registration numbers are displayed without any context so there is no indication as to how relevant the result is if you were to click in it.

Is there a way to display the results like <Business Name> (<Registration Number>) so there is always context to the auto-complete results? It seems like it would be possible. The names results contain the topic_source_id which seems to be the registration number, and the topic results contain a names list containing the business name. The results for business number fall sort as they don't contain the business name. Could that be added?

[esune]

CRA 9-digit Business Number is a Name index

This seems incorrect, semantically. Reindexing this under topic might be better.

Is there a way to display the results like <Business Name> (<Registration Number>) so there is always context to the auto-complete results?

I like this idea for the UI, as it will display related information together. What happens if the entity has a name, a BC registration number and a CRA 9-digit business number though?

[swcurran]

I suppose another solution would be to have three input boxes and have the person choose the one they want to use up front. Having them all in a single box probably doesn’t help them that much — they know what they are trying to do.

If we can have the drop down populated with (as Emiliano says) the Business Name and Registration number, that would be good as well.

Happy to meet to discuss.

[esune]

Will be resolved by https://github.com/bcgov/aries-vcr/pull/746

The issue was caused by trying to "enhance" the autocomplete endpoint to resemble a search endpoint: this caused results to be returned for different categories than just names, which seems incorrect. We're reverting the change so that the autocomplete will only return names, as it was previously.