Datalist polyfill Autocomplete - can't scroll, can't type issues

[neoinsight]

Usability participants had a lot of trouble using the datalist polyfill autocomplete element when it was filled with a list of countries.

1. One of the biggest issues is that it still displays the drop down arrows, but it's not scrollable for all participants on Chrome (7 of 13 participants). Also, when it opens, it opens from the bottom of the list (showing Z to S) if the field is lower on the page, or the page is big. I was able to replicate on Chrome, but if I made the page much shorter, the list opened at the top (starting from A).

   P7 on Chrome can't scroll up: https://www.youtube.com/watch?v=_LZPp3xOgBs P4 on Chrome can't scroll up: http://youtu.be/laSnVBkcfbs

   Yet for P9 on Firefox v33, it opens the dropdown into a window with a scrollbar. So the person is able to select the country by scrolling - painfully but successfully. http://youtu.be/ZVB-YdtnSQE

2. If the user types AFTER clicking the dropdown, the field doesn't seem to have focus, so nothing happens. They have to move into the field - like at the end of this clip. That means they can't apply their usual 'type to move within the dropdown' behaviour. I expected it to apply their typing to the field.

   see the video clip for P2 Chrome: http://youtu.be/9kB_0Sjoc6Q

3. Maybe I didn't implement it correctly, but people were confused about seeing both the label and the value for the same country - the code looks like this. That's how the example is formatted. Is there a way to force it to only display the value in the dropdown? Page is here: http://neoinsight.com/test/wetform1/exform3-en.html

       <input class="form-control" type="text" id="country2" name="country2" list="suggestions" />
<datalist id="suggestions">
  <!--[if lte IE 9]><select><![endif]-->      
    <option label="afghanistan" value="Afghanistan"</option>
    <option label="albania" value="Albania"</option>
    <option label="algeria" value="Algeria"</option>
    <option label="american-samoa" value="American Samoa"</option>

1. Finally, on Safari, it's a mess. Can't scroll, shows values and labels... See image:

[LaurentGoderre]

Chrome does not use our polyfill because it supports the datalist natively. This is a bug with Google Chrome. Furthermore it seems like the user does not get the point of the autocomplete where you start to type.

In this example, the problem really is that a datalist is not the right control for the information being requested.

[neoinsight]

Ok, so a Chrome bug. Re not using datalist, in previous tests for another department, we watched people struggling to choose a country from a long list of countries, so datalist seemed like a good option to help them. And if these bugs and issues hadn't made it so difficult, maybe it would have worked. But more basically, shouldn't this work better? When is it the right control?

[LaurentGoderre]

It is rather awkward. In that case, you want user to select a value from a controlled list but the field allows the user to enter whatever they like so from a data integrity it's not optimal. To me it seems like this field lacks some maturity. There could be an option to specify whether to allow free form data to be allowed of if only known value can be selected.

[thomasgohard]

The goal here is for the list of options to get filtered based on the user's input to speed up the selection. Is that correct @neoinsight?

If so, validation should be added to ensure that the value that is inputted/selected is in the list of options.

Another related problem will be that users may not spell the options as they've been labelled (e.g., "St. Petersburg" vs. "Saint Petersburg"). In simple cases like "St." vs "Saint", that may not be a problem. But, in other situations, the same option can have very different labels (e.g., "platform scale" vs. "bench scale", they're both the same thing, but different countries use one name or the other).

[RobJohnston]

And the markup is wrong. Instead of

<option label="afghanistan" value="Afghanistan"</option>

It should be this:

<option label="afghanistan" value="Afghanistan"></option>

Note the missing closing bracket after the country name. The error produces some weird markup, different depending on the browser.

[LaurentGoderre]

nice catch!

[pjackson28]

@RobJohnston Good catch! It would be interesting to see if those markup errors are at least partially responsible for the reported Chrome and Safari bugs.

@neoinsight Do you have any additional testing scheduled where you could find out whether or not fixing the markup addresses some of the bugs that were encountered?

[neoinsight]

Hey thanks for the markup catch! We do have more testing planned - so yes, could fix the markup first and then check.

@thomasgohard Yes, the idea is to have something easy and fast to use as an alternative to long dropdowns.

[neoinsight]

Markup is fixed. Does not seem to solve Safari problem or Chrome bug.

[pjackson28]

@neoinsight Another thing to try is reducing the number of entries (to say 50) to see if there is any change in behaviour. There was one report a while back about the native datalist support misbehaving in certain browsers when there were a large number of entries (well over 100) and the issue went away when there were a smaller number of entries. Could you please check to if you are encountering the same? This type of information would be helpful should a bug be filed with the browser vendors.

On a side note, using a dynamic datalist (dynamically populated from a server) seemed to fix the issue with the large number of entries (don't know if a dynamic datalist is possible in your scenario but we have an example provided through WET).

[neoinsight]

@pjackson28 I have reduced the country list down to 50. No difference that I can tell on Chrome or Safari. Using a dynamic datalist is beyond me - this prototype is just to test the concepts. Also, not needed for countries, which is the problem I'm trying to solve. Many government forms use country selections.

[neoinsight]

@thomasgohard Do you know if it's possible to suppress the drop down indicator in the field? Would like to test it again but without any dropdown showing up,since that's where most of the bugs are happening - it would act more like BizPaL's city selection autocomplete that way (you can see it here - it also has all the synonym and spelling support http://services.bizpal-perle.ca/eng/?b=01).

[LaurentGoderre]

there might be but I'm not sure how reliable it will be

[neoinsight]

@LaurentGoderre Yes, looks like you are right. Because even suppressing the dropdown on a numeric HTML5 field looks very complex. Too bad.

[LaurentGoderre]

Here's to hoping that Chrome jumps on the user testing band wagon!

[pjackson28]

Probably would be good to raise this with the HTML5 spec as well. If certain behaviour is important or needs to be avoided then it should be spelled out in the spec. It likely will be easier to encourage browser vendors to align with the spec rather than to try and convince them to change something they've implemented that is not spelled out in the spec. Of course it is easier to get something into the spec when browser vendors are on board so likely it would be best to tackle the two in parallel.

Is there any suggested wording for describing how this should look and behave (that would be appropriate for the HTML5 spec)? It would make it easier to shop around and to get support if we have proposed wording ready.

[LaurentGoderre]

The spec is often written around what browser implement. Maybe it would be worthwhile to use the polyfill and create a design that works and then send the demo as an example with supporting evidence that ours perform better?

[neoinsight]

@pjackson28 @pcwsmith What I'd like to do is get some help to implement this version https://github.com/JamieAppleseed/selectToAutocomplete which is pretty well the way it should work, then I could test it (starting March 9). I don't understand what he means though about the jquery autocomplete. You can see that he's addressed the same issues I was trying to solve by just using the datalist. Having the data would certainly also make it easier to shop around.

[neoinsight]

@LaurentGoderre Yes, exactly what I need. Sorry - we overlapped there. But am hoping the Appleseed stuff would help us create the design that works.

[LaurentGoderre]

This however means that the change might take years to get implemented

[neoinsight]

@LaurentGoderre Holy smokes - I had no idea.

[LaurentGoderre]

Seems like my instinct was partially right. Without using any CSS, the list does not start at the bottom but at the top

[LaurentGoderre]

Nevermind...whether it's starting at the top or bottom depends on the position on screen

[LaurentGoderre]

I can hide the down arrow by using the following CSS

input[list]::-webkit-calendar-picker-indicator {
    display: none;
}

[pjackson28]

Looks like someone already filed the datalist scrolling issue with Google: https://code.google.com/p/chromium/issues/detail?id=375637

[LaurentGoderre]

@neoinsight would you be able to apply that code to your test site so that we can test before applying it to WET?

[neoinsight]

Summary of status of this issue:

1. @LaurentGoderre I have applied that code to just the page on the site, and yes, it does appear to work. Combined with the placeholder I have added that says 'Start typing...', this will hopefully people avoid the known Chrome issue completely. I will report the usability testing results here.
2. In Safari, another bug causes the dropdown format to be displayed with the values and labels on separate lines, as shown in the image above. The dropdown is displayed as soon as the focus moves into the field - unfortunately.

[LaurentGoderre]

@zachfalsetto can you look into this with your Safari?

[neoinsight]

@LaurentGoderre I should have updated this issue after the last round of testing. Sorry.

• Hiding the down arrow in the polyfill field and adding the 'Start typing' placeholder really helped performance - no participants experienced the known Chromium datalist scrolling issue.

Are those changes something you can or cannot add to the polyfill so that anyone who does implement it gets the improved version?

Also outstanding is the Validation issue @thomasgohard mentions above.

[LaurentGoderre]

actually, it's not a change to the polyfill but a change to the native implementation in Chrome. We can implement it in WET. @pjackson28 do you have any issue with that?

[pjackson28]

Shouldn't be an issue as doing so doesn't seem to conflict with anything in the HTML5 spec.

[pjackson28]

Note that someone should still file an issue with Chrome to try to get it fixed natively but this workaround can do as a stop-gap measure.

[jvanulde]

I believe that this is also related to the geocoder issue reported in #6751

[LaurentGoderre]

The first issue mentioned is probably them same but not the other one

[hsrudnicki]

Are you ready to close this issue?

[neoinsight]

@hsrudnicki I will close this issue once I have the data to do so. It is complex. Analysis is happening now. Until then...

[hsrudnicki]

Based on the above, this issue should have been resolved, so again can be this issue, just labeled as "Going Stale" closed or otherwise? Either way, please update this issue's status, thank you

[hsrudnicki]

Based on the milestone settings and provided inputs, can be this issue closed as already resolved/fixed? Either way, please update this issue's status, whether this issue can be closed as resolved/fixed or if otherwise, thank you

[hsrudnicki]

Based on the above, this can be closed as resolved. If you think otherwise, please update the status, as well the milestone of this again, thank you

[duboisp]

I read the issue and it don't seem to resolved yet. I think a solution that would worth exploring will be to develop a combobox plugin. Some research and incomplete work is available here https://wet-boew.github.io/wet-boew-documentation/research/1-datalist-JSON-suggestion.html

[lisafast]

Agree it is not resolved since 2015. The proposed combobox plugin looks like a good solution. The Feature request specification looks like a good fit with user behaviour. I note though that the spec says both:

1. "Users must select one of the items from the options, they cannot type whatever they want and submit" - Yes absolutely, cannot make up the name for the Country name use case! Let's call this use case Selection required. See BizPaL for a good user-tested implementation of this solution, and the error message if the user presses Enter without selecting anything: https://services.bizpal-perle.ca/?b

2. "When an option is not available in the list, upon submission, redirect the user to a page where it would be able to submit the new items". - This is problematic, have never seen this type of implementation. In my experience you either implement the Selection required use case, or you implement - the Selection not required use case. Users are more familiar with Selection not required since this is how Google search autocomplete works.

[ghost]

Unfortunately DataList are plagued (there is 15 open issues) with issues that are out of WET-BOEW controlled, so I believe a replacement for the functionality would be the best direction.

Reason these are out of WET-BOEW control is Datalist is a polyfill and the polyfill is only suppose to run if the browser does not support it.

As you can see here https://caniuse.com/#search=datalist most browsers support it, but lot that support it are not fixing issues with it.

So if we where to use the plugin suggested by @duboisp it would need to override browser support (if still using the datalist tag).

I also had suggestion about this here #8634.

[duboisp]

"When an option is not available in the list, upon submission, redirect the user to a page where it would be able to submit the new items".

That requirement was for an integration with fieldflow, which is out of scope here.

I think your are looking for a combo box with the grid popup or the tree popup design.

The specification for a combo box is well defined here:

• https://www.w3.org/TR/wai-aria-practices-1.1/#combobox
• https://www.w3.org/TR/wai-aria-1.1/#combobox

it would need to override browser support

The propose solution is to create a new combo box plugin, which could be designed as an extension of an HTML datalist or be an independent plugin.

The developer that would work on developing that plugin would need to have a good understanding of what is a combo box with a list box popup, combo box with a grid popup, combo box with a tree popup, combo box with a dialop popup, an HTML datalist, the autocomplete feature (in a HTML input, inline autocomplete, list autocomplete) and the multiple attribute for input.