search

Lundalogik / lime-elements

Provides reusable web components for Lime CRM
https://lundalogik.github.io/lime-elements/versions/latest
Other
38 stars 11 forks source link

In Chip-set, the `<input>` `type` should be `search` #1718

Closed Kiarokh closed 2 years ago

Kiarokh commented 2 years ago

Current behavior

Currently the limel-chip-setused also in limel-picker uses a limel-input with a type of text.

image

This creates usability problems in certain cases, because there is a difference between search and text types for browsers. You can read about some of these differences here. But here are a couple of reasons why we should have used type search for the Chip-set at least.

Accessibility

Screenreaders do not know that users can search in the input box, just because we put a magnifying glass there. Thus they cannot announce that the form is a search form or this is a search box. More…

Usability on smart devices

Smart devices (at least on iOS) know what language the user is writing in (due to the keyboard layout that's chosen). Normally, their auto-correction kicks in when user is typing in input fields. Because it could be a form they are filling in or a message that they're typing. This is a good thing. But not user is searching. When searching, the keywords could be really anything, and it should be up to the search engine (like Elastic, or Google) to guess suggest what may be a relevant keyword. This happens a lot when searching for Persons Names, Company names, since the auto-correction dictionary does not have all of those in the chosen language.

Here is an example of how auto-correction switches user's input to something else, as soon as the Enter key is pressed in a relation picker in Lime CRM. If user is not paying 100% attention, they will wonder why aren't they getting the results they expect. Since corrected words are very similar to the assumed typos, it'll be very hard to distinguish.

https://user-images.githubusercontent.com/35954987/162478333-eb89053b-02db-49d1-ab06-398538178b76.MP4

⚠️ One thing to be careful about

Sometimes browsers put a ( X ) icon for clearing the typed input, or put a 🔍 icon by default to <input type="search">. When fixing this, we have to check that we won't get the same behavior as below:

https://user-images.githubusercontent.com/35954987/162479245-ae264f7a-a32a-42b3-b35c-669d76762a21.MP4

adrianschmidt commented 2 years ago

@Kiarokh wrote (https://github.com/Lundalogik/crm-feature/issues/2723#issuecomment-1093045589)

I don't know if it makes sense to allow input type to be either text or search.

I wonder if there is any case where the input type should not be search in the picker 🤔

In the case of limel-chip-set, it's possible to let the text input become chips, and in that case, I don't think the correct input type would be search.

I think there's a similar possible use case for limel-picker, but it's not identical. If we look at the label picker here on GitHub, it's similar to a limel-picker, but if the value in the input field is not an exact match for an existing label, and you have the permission required to create new labels, you get an option to create a new label with the current value. However, that doesn't just happen when pressing enter, instead, pressing enter selects the top option (and Create new is the second to last option, with only Edit labels coming after), so pressing enter will not select Create new unless there are no matches at all. So, in all but that very specific case, I think search is clearly the correct type to use, and 1) even in that specific case it's not obvious that search would be the wrong type, and 2) I don't think we want to be switching types for the input at the user is typing 😂

Sure, the consumer could probably choose to just create a chip if the user presses enter, even if there is an exact match. But that doesn't seem to me like a good way to use limel-picker… (right?) I think it makes more sense to use the support for static actions, to make it a "menu option", like the GitHub label picker's Create new. (Side track: for accessibility, we need to fix keyboard navigation for pickers with static actions.)

So, so far as I've been thinking about it while writing this comment, I can't come up with any scenario where search would not be the correct type to use… can you think of any? @Kiarokh @LucyChyzhova

If not, I think we can just switch the type from text to search.

Kiarokh commented 2 years ago

Oh sorry, I think I confused both myself and everyone. 🙈 The topic of issue is for the chip-set, not the Picker! I have updated the title. Read more below to see why…

Thanks Adrian... Here are my follow-up thoughts:

In the case of limel-chip-set, it's possible to let the text input become chips, and in that case, I don't think the correct input type would be search.

I actually think it is correct that chip-set allows the input type to be either search or text. So in the screen recording I attached in the issue, we have a chip-set in the CRM, which we use to preform a kind of "search".

What happens when using the chip-set is that the auto-correction kicks as soon as the user presses the Enter key, and right before the "chip" is created. So the chip will be a different keyword than what user typed. There are no search suggestions or a list to choose from. That's rather a feature of the Picker.

However, this might not be the only use case for a chip set like that. These kinds of chipsets could be used in a form context as well, when the auto-correction is a good thing. For example, a form question could be:

  • Please suggest three short titles for the the cycle name.
  • Please type five of your favorite fruits

For such a use case, you wanna have auto corrections (type="text") for a smoother user experience.

However, we have a custom built Picker which uses the Chip set. The way we have built our picker, you cannot do anything by typing and then pressing the enter key basically. I'm not saying that is the way a sanely designed picker should optimally behave though. Maybe a better interaction design should be (as you mention too) so that pressing Enter after typing some (even potentially misspelled) keywords would select the first item from the search suggestions list. Pressing ↓ then Enter would choose the 2nd item.

With that said, I also think the correct type for the picker is search, because what takes care of understanding the user's input (and understanding the typos) should be the search engine behind the picker, not the picker itself.

What do you think?

LucyChyzhova commented 2 years ago

I wonder if there is any case where the input type should not be search in the picker 🤔

I think input field for notes should not have the search type.

adrianschmidt commented 2 years ago

I actually think it is correct that chip-set allows the input type to be either search or text. So in the screen recording I attached in the issue, we have a chip-set in the CRM, which we use to preform a kind of "search".

Yeah, given the example from Lime CRM Web Client above (this one), I agree that it makes sense to make it possible to configure the type for limel-chip-set of type input.

What happens when using the chip-set is that the auto-correction kicks as soon as the user presses the Enter key, and right before the "chip" is created. So the chip will be a different keyword than what user typed.

image

But, yes—while a very interesting philosophical question—it doesn't matter for our case, because we know there are a lot of people in the left circle… 😖

With that said, I also think the correct type for the picker is search

Yeah, I agree with that too. So we should make it possible to choose the type of the input field for limel-chip-set 👍

adrianschmidt commented 2 years ago

I wonder if there is any case where the input type should not be search in the picker 🤔

I think input field for notes should not have the search type.

If you mean history notes in the CRM web client, those aren't using the picker(?). I didn't mean all input fields, just when used inside limel-picker 🙂

LucyChyzhova commented 2 years ago

With that said, I also think the correct type for the picker is search, because what takes care of understanding the user's input (and understanding the typos) should be the search engine behind the picker, not the picker itself.

100% And the chip-set which we use in the table view should definitely have a type search, as there is a huge chance that users type non-existent words.

If you mean history notes in the CRM web client, those aren't using the picker(?). I didn't mean all input fields, just when used inside limel-picker 🙂

ah, no, it's not used inside the lime-picker :)

Kiarokh commented 2 years ago

Thanks for the responses. I'll make a PR at some point for this issue. And I think we can't use this anyways for our other issue: https://github.com/Lundalogik/crm-feature/issues/2723#issuecomment-1093045589 given what we concluded here.

lime-ci commented 2 years ago

:tada: This issue has been resolved in version 35.1.0-next.10 :tada:

The release is available on:

Your semantic-release bot :package::rocket:

lime-ci commented 1 year ago

:tada: This issue has been resolved in version 36.0.0 :tada:

The release is available on:

Your semantic-release bot :package::rocket: