-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Autocomplete usage producing unusable results #178
Autocomplete usage producing unusable results #178
Comments
Based on the release history the last search changes were made in |
This needs a bigger discussion, IMO. The issue stems from bcgov/aries-vcr#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 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 ? |
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 |
This seems incorrect, semantically. Reindexing this under topic might be better.
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? |
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. |
Will be resolved by bcgov/aries-vcr#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. |
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:
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?
The text was updated successfully, but these errors were encountered: