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 #4

Open
govuk-design-system opened this Issue Jan 12, 2018 · 3 comments

Comments

@govuk-design-system
Collaborator

govuk-design-system commented Jan 12, 2018

What

A text input that suggests options to the user as they type.

screen shot 2018-02-20 at 10 44 08

Why

Anything else

@govuk-design-system govuk-design-system created this issue from a note in GOV.UK Design System Community Backlog (Agreed) Jan 12, 2018

This was referenced Jan 12, 2018

@joelanman joelanman added the candidate label Apr 4, 2018

@timpaul timpaul added component and removed candidate labels May 21, 2018

@timpaul timpaul moved this from To do to In progress in GOV.UK Design System Community Backlog Jun 28, 2018

@hannalaakso

This comment has been minimized.

Member

hannalaakso commented Jul 13, 2018

Current status of autocomplete work

We currently have accessible autocomplete and "country picker" prototypes.

Country picker consumes both accessible autocomplete and picker engine through npm. The latter contains the sorting and synonyms functionality.

Feedback from @edwardhorsford suggests that the sorting and synonym logic in the picker engine is particularly coupled up with the country data and should stay as its own entity. Additionally, the picker engine has a jQuery dependency in Twitter's Bloodhound that it consumes.

We should therefore build the sorting and synonyms logic separately in accessible autocomplete.

We could look at the picker engine sorting functionality for ideas for sorting. It:

  1. Matches exact canonical name
  2. Matches start of canonical name
  3. Matches start of another word in canonical name (eg Kingdom in United Kingdom)
  4. Exactly matches synonym
  5. Matches start of synonym
  6. Matches start of another word in synonym
  7. Matches within words in canonical (not the start - doesn’t work anyway)
  8. Matches within words in synonym (not the start - doesn’t work anyway)

Each of these gives a score - we then sort by score by using a score, we can also have biases on some entries - which multiply the score this means that an entry with a bias of 2x (eg UK) will rise in the rankings, but not necessarily to the top, if it was only a very low score to begin with (thanks Ed!)

Here's an example (thanks Ed!) of what the current autocomplete without sorting logic does (only sorts alphabetically):

without-sorting

The example doesn't show synonyms but if we had them, it would make sense to rank canonical names higher than (potentially obscure) synonyms.

We should also test that the country picker that consumes accessible autocomplete remains functional.

What could be the MVP?

Features to discuss are:

  • sorting
  • synonyms
  • typo fixing
  • weighting (biased results)

We could also consider deprecating some existing functionality in accessible autocomplete (and potentially bring some of it back in at a later point):

Some examples of Accessible Autocomplete synomym logic that don't depend on jQuery

  1. @frankieroberto has built a government organisation autocomplete that uses the accessible autocomplete and accepts alternative names.

  2. The TEN prototype contains a simple example of synonym matching.

Should we continue to use Preact with the accessible autocomplete?

The current autocomplete imports Preact which is an alternative React, a library for building interactive UIs, and extends the Preact events.

If we were to switch to not using a JavaScript framework, we could give ourselves an awful lot of work to solve the problem of managing interactivity and state that has already been solved well in Preact. As Preact is only 3kb in weight and supports Progressive Enhancement (so that if the browser doesn't run JavaScript the user is presented with the native select element), it would seem sensible to continue using it.

@joelanman

This comment has been minimized.

Member

joelanman commented Jul 13, 2018

My 2 cents:

I think an MVP should be as minimal as possible while giving value.

I think the results algorithm should be plug-in able if possible, so people can write their own if needed, or extend the default.

I think we need sorting, as otherwise very unexpected results can happen as seen in the gif in the comment above.

I don't think we need synonyms, weighting or typo fixing for an MVP - not all autocomplete use cases will need them.

Not sure why we would remove functionality that exists, unless there's a reason for removing them?

@hannalaakso

This comment has been minimized.

Member

hannalaakso commented Jul 13, 2018

The deprecation suggestion was due to the fact that at the moment we are getting issues raised for things like the autocomplete not working with the latest version of React. It's good to support React if there's a need but as we're still trying to move out of the prototype phase I think we should probably focus our efforts for now on getting the core product working.

@mikeash82 mikeash82 referenced this issue Nov 29, 2018

Open

Names #53

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment