Infinities Loop

Just a bit off topic today, but this has been bugging me for years and years and I finally have a significant channel through which I can attempt to set the record straight.

I'd like to report a bug in English language culture.

Often times a co-worker, friend, or family member may approach you and explain a situation they are in, a situation that does not concern you what-so-ever. Normally you show interest, because you're nice like that. Good for you. But sometimes you simply aren't in the mood. There are many ways you can communicate this to your conversationist, some are polite white lies like "I'm sorry, can we talk about this another time, I am late for a dentist appointment." Some are trickery, like "Look! Over there! <runs away>"

But the best one by far if you are feeling particularly foul is the blunt exaggeration:

I couldn't care less.

This lets them know that the subject is so uninteresting to you, so unimportant, that you could not possibly care about it any less than you do, no matter how hard you may try. You have in fact reached absolute zero on the caring scale. Wow... that's cold man. Have you no compassion?

However... as is the case for many sarcastic remarks, the sayer does not always appreciate the meaning of what they are saying. They just say it because they've heard it, basically. There's nothing wrong with that. But if you're going to spout a phrase designed to strike your subject with pure and utter rejection, you best get it right!

The bug is that so often what people actually say is:

I could care less.

O RLY? So what you're saying is that there is still a detectable trace of care left in your heart. You care somewhat, therefore it's possible that you could care less about it. That gives me hope... heck, it's almost a way of urging your conversationist to continue! Yes, yes, please continue... I could care less about the subject, so perhaps you have hit upon a subject we can share together! Hooray!

It's more common than you think. I'm surely not the first to call this out as a common mistake. But clearly we as a people have not been doing enough about it. It's even crept its way into the lyrics of a hit song!

One more thing... if you find any grammatical or spelling errors in this article, just know this: I couldn't care less about them. :)

Update:

You simply must check out this awesome diagram :)
http://www.incompetech.com/gallimaufry/care_less.html

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.

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?