mirror of https://github.com/zulip/zulip.git
673af19a4d
Previously, exact matches could be pushed off the typeahead list in the case where there were more prefix matches that happened to rank first, which is confusing to the user: if an emoji, for instance, falls into this category, it will never show up in typeahead, which is easy to confuse with the emoji not existing. This isn't a perfect fix — there are still cases where it's hard to find emojis because the prefix-space is very crowded, but it does fix a category of surprising and frustrating behaviour. This doesn't come completely without downside - it means that the exact match emoji will jump to the front of the list, which changes what is currently conceptually a "filtering" operation to a "filtering and sorting" operation, but it seems on the whole to be a more ideal experience. This is particularly notable in the non-typeahead emoji picker, which uses the same codepath, but this change seems somewhat desirable even there, since it allows the user to type the name of an emoji and press enter and have that emoji show up, without having to visually confirm that they aren't inadvertently selecting a prefix-matching emoji. A better solution to this in the long term might be ordering emoji results by shortest-first as a tiebreaker for alphabetical ordering, since that should provide the same behaviour while keeping the mental model as "filtering" (since the sort order won't change as the user types), but this seems like a reasonable first pass, and changing to shortest-first ordering after making this change won't break any muscle memory for existing users. |
||
|---|---|---|
| .. | ||
| emoji.js | ||
| fenced_code.js | ||
| typeahead.js | ||
| typing_status.js | ||
| typing_status.js.flow | ||