An AutoCompleteExtender does not an Advanced DropDownList make!

I've received a lot of feedback on my SmartAutoCompleteExtender as of late. But I've noticed a disturbing pattern with the suggestions people have.

A few of the features people have asked for are:

  1. Ability to remember unique identifiers for each of the suggested items, so that it may be tied back in with the database record it came from.
  2. Ability to have the list of suggestions popup automatically rather than wait for the user to start typing, or,
  3. Ability to support a 0 length minimum prefix length.
  4. Scroll bar handling -- as in the case of a huuuge list of suggestions.

I'm the last person in the world to argue against features. In general, I'm in favor of flexibility over simplicity, perhaps too much so. And these are all great ideas to enhance the flexibility of the auto complete extender, no doubt about it.

What I don't like about it.

The AutoCompleteExtender is not a replacement to the built in HTML select list! It is not meant to be one, nor can it be one. But all of the suggestions listed above came from people who are attempting to use it as one, and all of the suggestions are geared toward making it act more like one.

The AutoCompleteExtender extends a TextBox. It's supposed to enhance the functionality of a TextBox. When you are faced with choosing a UI element to represent user input on your form, how do you decide between a TextBox and a Select list? Simple... a TextBox allows free-from user input, with some possible validation rules behind it. A Select list (or any equivalent UI such as a radio button list of multi select list) forces to the user to pick one of an existing set of values. There's an important difference here.

Many of you have used Google's toolbar, no? One of its nifty features is automatically popping up a list of search suggestions as you type. Pretty cool. Of course, the Live toolbar has this feature too :) Start typing "inf..." and it will say, hey, maybe you're trying to type "infinity"? Great... now I don't have to figure out how to spell it, it's right there, along with a bunch of other things I might mean.

Why doesn't it suggest InfinitiesLoop? :(

Of course... maybe I really wanted to search for "infuriating", which wasn't even in the list. The point of the list of suggestions is just that... suggestions. It's nothing more than an enhancement to a textbox, a regular textbox where you expect the user to type in anything they feel like. How "infuriating" would it be if you couldn't search for anything you want.... no, it had to be in this suggestion list. Oh, you could type anything you want, but you'll just get an error, "please pick from the list". Right... so, why do I have to type again? If you're going to force me into some known value, just present me a list of the values so I can choose one! Don't make me type and choose.

There's more to it as well... Google does know about the word "infuriating", but it wasn't in the list. Why not? Because according to Google, that was not a likely word for me to search for. Who knows how they decide this, maybe its just alphabetical, maybe its based on common search terms, who knows. The point is, Google did not present me with a list of all 1,123,764,102 possible matches to the prefix "inf"! That would be ridiculous, and unusable. The list of suggestions is not a complete list, its just the most-likely-to-be-useful-list.

That is the subtle but important difference between a TextBox with AutoComplete and a DropDownList.

If you think of it this way, it doesn't make sense to maintain an ID for the items in the suggestion list -- what if the user doesn't chose from the list, maybe they just type it in manually? Either you frustrate the user with an error or you end up having to match the text to its ID manually anyway -- so just do it that way.

Nor does supporting scrollbars make sense .... if you have more matches than will fit on the users screen, chances are they won't see them anyway, and it would be easier for them to narrow down the results by continuing to type rather than use the awkward, ugly scrollbar. Users hate scroll bars.

How about automatically popping up the suggestion list rather than wait for the user to type? If the textbox is empty... there's nothing to suggest. What would the Google search box do in this scenario? It doesn't even make sense. The only reason you'd want this feature is if the list of possible values was small -- in which case, using a select list would be easier anyway.

Ok ok ok... enough feature bashing :) The other side of this story is even more complex. There certainly are scenarios where a dropdownlist, radio button list, or multi select list leave much to be desired. And in those scenarios, an AutoCompleteExtender-like control seems like it may be a great solution. For example, if you are selecting a city in a U.S. State -- there are so many cities in each state, a dropdownlist would be huuuge and hard to use. How nice would it be if the user could start typing the city name, and find a match?

It would be nice... but remember the user is typing in a TextBox, so nothing stops them from typing in some non-existent city! You would have to handle that somehow. With issues like this, it quickly grows into a complex problem. Simpler and easer would be a search form. The user types into a textbox, and then by either hitting enter, clicking a button, or automatically in the background, a search is made and a list of possible results appear. The user must click on a result to continue. In ASP.NET you could easily accomplish this sort of UI using a repeater within an update panel, and some javascript. As the user types, the Repeater is re-databound with matching results, and since its in an update panel, it's all very "ajaxie".

In the end... it may be that the features would be abused, but I still think they would benefit the AutoCompleteExtender. From a "the right thing" perspective, it's better to have the features than not, so long as it doesn't over complicate the control's API. I may consider some of these features in a future version of the SmartAutoCompleteExtender. But as I think about these issues, sometimes I wonder if I may be doing the web more harm than good by encouraging abuse of suggestion lists :)

Anyway... thats my two cents. What do you think?

26 Comments

  • This is a great writeup ... I loved the way you looked at the individual feature requests and provide a good case for why they may not make sense for the auto-complete scenario.

  • What these people are looking is a combobox. What's amazing is that none of these developers actually seemed to know what a combobox is.

  • (Having just read this summary and not the original comments - there's too many of them!!) a combo box seems to be what people are asking for. The problem is that combo boxes don't exist in HTML. You either get a select list, or a text box.

    So a "proper" combo box would be a nice control to have. Though I agree a combo box might be a DIFFERENT control to this one.

  • A ComboBox might be what some people really want, but not all. A ComboBox still lets the user type whatever they wan't if I'm not mistaken (hey, its been a while since I entered the client world :)), and it shows all possible results.

    I think there are many varied scenarios, and they form a breadth of issues that is too great for a single control to solve. The problem is trying to force AutoCompleteExtender into solving them... it's too tempting for most.

  • Most combobox controls allow either free-text or pick-one.

    Telerik has a nice combobox control for the web.

    But yes, some of the scenarios you have mentioned require some thinking, rather than a control :)

  • I think taking a step back and looking at the requirements may shed some light. Let me paint a scenario. Consider an element whose representation in the database is a simple ID/Name pair. The users are accustomed to refer to these elements by Name and know nothing about ID. This list of elements is upward of 100,000. Using a dropdown list is the right way to ensure the user selects an existing element, but it is not ideal for obvious reasons. So, what does one do?

    An alternative, as identified, is to use a Search feature where the user enters as much of what they may remember with the hopes to find the correct element. Once found they simply select it. If no match is found, the user is not allowed to select anything.

    In order to do this the "correct" way would require the user to say "hey, I want to find the element!" (perhaps click on a search icon). The control would then present the user with a Search control (err, a TextBox) so they can type in what they are looking for... you get the point.

    I am currently using the AutoCompleteExtender (the SmartAutoCompleteExtender to be precise) as a quick way to allow the user to find the proper element and later validate the entry, which they can type entirely if they want. What I don't like about this approach is the fact that the user is not able to tell the difference between a TextBox and a selection list of sorts.

    So, the scenario to consider, if I may refer back to requirements, is how to help the user find an element by Name, while preventing them from entering something that is not part of a preset list? At the data level, the ID is really what is needed for integrity. So, how would you do that? Using the AutoCompleteExtender is simply a means to an end.

  • lvildosola, that's when you'd use a combobox.

    Go to Telerik's website to see an example.

  • I'm really interested in this topic, because I'm working on an application that uses this input mode (select an existing value from a large set) all over the place. We're using the Yahoo UI autocomplete, which supports constraining input to the listed values. I hate it. It's ugly, and the key handling is clunky.
    What I want (but don't want to have to write) is a drop down list that, when it gets alphanumeric keypress events, pops up a little "search" DIV above the control to display the current search text, and starts doing AJAX hits to populate the dropdown with the found matches. At no point is free text entered into an "input" per se.
    Does such a thing already exist? I'm perfectly willing to pay for this one.

  • Your AutoCompleteExtender is not compatible with the final version. Do you have any plan about a new release?

    Regards

  • You will need to make 2 changes to the code.
    1. In SmartAutoCompleteBehavior.js, go to the end of the file and replace the last line with the following. Note the namespace of the base AutoCompleteBehavior has changed.
    Sys.UI.Controls.SmartAutoCompleteBehavior.registerClass(i88.UI.SmartAutoCompleteBehavior', AjaxControlToolkit.AutoCompleteBehavior);
    2. In SmartAutoCompleteExtender.cs, go to the method GetScriptReferences() and change the first reference line with the following.
    references.Add(new ScriptReference("AjaxControlToolkit.AutoComplete.AutoCompleteBehavior.js", "AjaxControlToolkit"));
    If you made the necessary reference changes to the new dlls and updated your Web.config you should be up and running in no time.

  • Please note there is an error in my previous post. The line should read:

    i88.UI.SmartAutoCompleteBehavior.registerClass('i88.UI.SmartAutoCompleteBehavior', AjaxControlToolkit.AutoCompleteBehavior);

    Sorry for the copy/paste error.

  • Is it possible to modify the CompletionList property or the return parameter of the ICallbackEventHandler.GetCallbackResult() so that I can get it to render actual html? Lets say if I wanted to show a bunch of links to other pages in the results by setting the CompletionLits to "text". This didnt work, the ouput looks exactly like that, it doesn't get rendered. Any ideas?

  • Bilal -- you'd have to tweak how the update method creates the completion items. I believe it is using createTextNode and dynamically appending them into the div. I'm not sure how those items containing HTML may affect the mouse over events and all that.

    FYI for great ideas like this you should get involved with the toolkit. Its a community driven project, so there's no reason why you shouldn't be able to implement and get it checked in for everyone else in the world to enjoy!

  • Bilal, you can get it to process your HTML by overriding the _update function and appending to the completionListElement.innerHTML attribute instead of calling document.createTextNode. But this will not work anyway since you would have to change the behavior of how the mouse click works or how the Enter key is processed. The base AutoCompleteExtender behavior is to set the value of the text box. You would have to change all that. Sounds like a differnt control to me.

  • I like the idea of BJ very much. I also need to find a way to link the selected text back to an database entry. Is it possible to extend the ACE in the way a combo box uses DataTextField and DataValueField...?

  • Dirk -- The text can be typed by the user or selected from the list, so you must be able to map the text to the database entry by its value alone. This control just isn't designed to be used as a dropdownlist that lets you type to find items. There's another control in the toolkit now, ListSearch, that does this, maybe that would be better suited to your needs?

  • Thanks for your response.

    > There's another control in the toolkit now, ListSearch, that does this...

    As I understand it the ListSearch extenter needs a compleate DataSource already bound to the parent control. So if I like the user to select one city from about 10000 available cities in the database first I have to load ALL 10000 cities in the drop down before the user can select the desired one.

    Of course this is not a very nice and performant way as the page size is a little to big with all cities loaded. I have no idea how to solve this as I´m not able to reduce the amount of relevant cities (e.g. prefilter with cascading drop downs...). The ACE would be just perfect...

  • My general thoughts on the ajax.net autocomplete box is that it is garbage.

    I started using it to create something that needed slightly advanced features and found it to be fairly unusable, and so I wrote my own. It performs better, and does what I want.

    It seems to me the old Atlas one was better.

    Lame.

  • Joe -- what old atlas one? If I'm not mistaken the implementation has more or less been the same since it was first introduced in the Atlas CTPs.

  • "Simpler and easer would be a search form. The user types into a textbox, and then by either hitting enter, clicking a button, or automatically in the background, a search is made and a list of possible results appear. The user must click on a result to continue. In ASP.NET you could easily accomplish this sort of UI using a repeater within an update panel, and some javascript. As the user types, the Repeater is re-databound with matching results, and since its in an update panel, it's all very 'ajaxie'."

    This sounds almost identical to just using the AutoCompleteExtender. The user types into a textbox, and automatically in the background a search is made and a list of possible results appear below the textbox. The only difference is that the user isn't forced to click on a result to continue.

    The only reason I can think of implementing your search feature is to allow the user to page and sort their autocomplete results. However, Facebook seems to get away without implementing this kind of functionality in their "choose a friend" textboxes, and their interface seems to work great.

  • For me, I'd like to associate an ID with the AutoCompleteExtender because I do not want to switch the user to another form to do the lookup.

  • Great article, you've convinced me AutoComplete is not the best option for what I want to do. Thanks!

  • Why can't Microsoft just get us a good ComboBox control?

    I'd rather have that than an AutoComplete textbox.

  • As far as ABILITY TO REMEMEMBER THE ID of the list item. Take a look at Facebook. They also use autocomplete for the CITY for example. There is a logic that even if you start typing and try to navigate away from the textbox, it will select the first item in the list.

    So what Facebook has logically is either select from the list OR nothing at all. They are all tied to the CityId (I would imagine). So it CAN be done.

  • The highlighted item in the dropdown is always yellow and I don't seem to have any control over this color. What can I do to change the color of the highlighted item in the dropdown?

  • Hi,

    I have implemented smartautocompleteextender in my project and now we have got a requirement to add button in it so that it can be activated through button instead of spacebar. Can you please tell me how can I implement this functionality in it as it is very urgent issue?

    you can contact me at jaydev.dhinoja@core.gb.com

    Thanks
    Jaydev

Comments have been disabled for this content.