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. |
||
|---|---|---|
| .. | ||
| js | ||
| README.md | ||
| package.json | ||
README.md
The files in this subtree are part of the Zulip web frontend, and are also incorporated by the Zulip mobile app.
Note that the deployment cycles are different:
-
In the webapp, this code is deployed in the same way as the rest of the web frontend: it's part of the server tree, and the browser gets it from the server, so the client is always running the same version the server just gave it.
-
In the mobile app, this code is deployed in the same way as the rest of the mobile app: it's bundled up into the app binary which is uploaded to app stores and users install on their devices. The client will be running the version built into their version of the mobile app, which may be newer, older, or simply different from the version on the server.
The mobile app always refers to a specific version of this code; changes to this code will appear in the mobile app only after a commit in the mobile app pulls them in.