Input clearing UX on escape

[andreyvolokitin]

Pressing an "escape" key closes the autocomplete, second keypress clears the input as shown in a demo. This is logical because it allows hiding autocomplete immediately, considering this is the thing the user wants (though not always, I stumbled upon a use-case when I'd want to first clear the input, i.e. if I want to search for another term ASAP, but currently for this I'd need to press "escape" twice).

In detached mode we have a modal and pressing "escape" closes it immediately. I thought that maybe this can cause problems. If the user wants to clear the input to search for another term, they would be required to re-trigger a modal by point-and-click a trigger button again, only then it will be possible to type a new search term.

Again, depending on what the user expects, this could be ok, but I personally considered it an issue, because there basically no "clear-on-escape" functionality in detached mode, there's just "close-on-escape", and then if you want to search a different term — you need to point-and-click again. This makes searching different terms less convenient, i.e. you need to use a mouse together with a keyboard to re-trigger a modal (as compared to only using a keyboard in regular mode, OR if the input would've been cleared on the first "escape" press, with a modal close on a 2nd press).

Maybe an option could be introduced for detached mode (or for all modes), i.e. prioritizeEscapeClearing or doubleEscapeClose, or persistPanelOnFirstEscape, which will allow input clearing on first "escape" press, and panel/modal closing on 2nd "escape" press?

[Haroenv]

This is interesting, but what I'd like to question whether the heuristic for escape being used for clearing the query. For me the query clearing is more of a side effect from closing the modal, which is the main goal of pressing escape. You can see analogies in native desktop applications. Escape either closes a modal/dropdown (with or without clearing an input), but will never only clear the input without also closing the modal.

Could I ask where you see people use escape to clear the query?

[andreyvolokitin]

AFAIK clearing the input on "escape" press is a native input[type="search"] behavior (so maybe it is quite popular/expected on the web), personally I find it useful, but can't vouch for a majority of people. Also InstantSearch itself is using it, which might quickly make it familiar (and convenient) for those unaware

Depending on if people are familiar with this behavior, immediately closing a modal can be desirable/expected or not. When I tested it I felt like closing a modal is not a "primary action" to escape, because I'm using a search, which just happens to be inside a modal, but using a modal forces me to give up on clear-on-escape functionality (so the logic for me is: "enter a modal -> enter a search -> escape a search -> escape a modal")

[Haroenv]

I understand. I actually only just now found out escape is keyboard in type search to clearing the input. I haven't seen that before, and other major players disable the default behaviour (eg google). The right solution is probably doing some research to find whether the existing behaviour or the clear the input behaviour is more common and making/keeping that default, rather than giving an option IMO

Alternatively maybe the keydown handler could get a way to be overridden/augmented, for extra behaviour like the one you describe

[andreyvolokitin]

I think a proposed behavior is definitely less common due to a keyboard experience often being neglected (even the modal closing on "escape" press is not a ubiquitous thing), this is just what I felt could be improved (or made more "uniform/predictable" in terms of using "escape" to clear the input — the other way would be to disable escape clearing completely, as you mentioned, probably Google has done some research on this, and I checked Amazon too, they both use type="text" for some reason though), and the option route came to my mind considering this can be controversial.

But maybe overriding/augmenting a handler can fit this better, just because all 3 option names I came up with aren't very clear (and I tried hard), as compared to just writing a code for those who need it

P.S.: I'm actually surprised Google isn't using it and curious of the reason why. I'm not very well-versed in deep practices of using a search, but when I started experimenting with Algolia I quickly found this functionality very convenient (though this might actually not be a "real" usage, because this is me being a dev testing different queries, not a user trying to actually search)