Tuesday, January 2, 2007 3:13 PM
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:
- 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.
- Ability to have the list of suggestions popup automatically rather than wait for the user to start typing, or,
- Ability to support a 0 length minimum prefix length.
- 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.
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?
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?
Filed under: .NET, ASP.NET, AJAX, Atlas, UI