Friday, February 18, 2005

to search or not to search

when is a search not a search? Something that has bothered me and something that I have had to argue for and in favour of is using a vaild search instead of using positioning to. Imagine you have a customer list stored in a file. There are several ways of allowing users to search this customer file, one way is to display the customer file alphabetically and then allow a user to "position to" a record within the list, so for example if I was looking for Smith, I could say position to the "S" records then scroll down until I found the "Smith" record. This is how a lot of database centric systems work by default, xbase does this, dbase, DB2 and so on. The reason is it is an effecient reading mechanism from a hard disk especially if the data is ordered the way you want it on the disk. My big problem is what if there are no "S" records in your list, "position to" always displays the next record, so if I was searching for "Smith" and I said position to "S" and there aren't any records that begin with "S" the program will display all records beginning with "T" providing there are "T" records or "U" if there aren't any "T" records, etc. For example if I ask for "Smith" and there aren't any records for "Smith" however there are some records for "Thompson" being that "T" is alphabetically after "S" a position to, scenario would return "Thompson" records, is it me or would that not be confusing? This is terribly wasteful as far as resources go and not very intuitive to the user using the system, although a user could adapt to this type of system. Its wasteful because I already displayed the first number of records from the list alphabetically however the user wasn't looking for a customer that began with a lower letter (in this case "Smith") . Being a web developer in the corporate world most of the data I would be displaying to a user is stored on back-end legacy systems, most of these systems are fast however their resources are not infinite. So anytime resources could be saved they should be. When a resource is saved whether it is bandwidth or processing time or disk access, you increase the scaling capability of a system.

So if I was writing a web site that could be used to search for a specific customer what would be the best use of the resources? Display a list of 25 customers alphabetically then allow them to do a "position to" and then display what the next 25 records after the position to? This involves 2 full round trips to back end system plus the bandwidth to send two full 25 pages of data to the end user. Noting that the user may still not find the data he or she is looking for. OR would a better use of resources be to display a text box for the user to enter full or partially what they are looking for, so in my example "Smith". Then go to the back end system query for only records that match the word "Smith" and return only those records that match. So if there are three records with the name "Smith" display only those records. If no records exists for "Smith" display nothing to the user to inform the user that "Smith" does not exist?

To me the latter seems far more sensible and for more realistic then the former. Not to mention it works the way you expect it to work. If I asked for "Smith" and got a list of "Thompson"s would that mean there aren't any records for "Smith"? Or would it mean the computer is screwing up and sending me the wrong data? Chances are good joe user will assume the computer is not working properly and try the query again and again. Just imagine if you search Google for Bob and they had no records for Bob so they sent you records on Boobs instead because that was the next record after Bob. I don't think the users would be very happy.

Comments:
I understand and agree with what you are saying in concept.
The problem is that most users are "click happy".

Against my better judgement, I was given the task of providing a drop down list of FIRST NAMES so that users could click instead of type.

The idea being that users would prefer to press 1 key (to position to) a name or a similar name.

Much to my disappointment this was ultimately the choice my client made against my suggestions otherwise.

Unfortunately my role is not to decide what good software is. It's my role to build the best technically sound software that meets the clients requirements. No matter how silly I may find them.
 
agreed the customer is king, but sometimes technical limitations override their wants. What happens if there are thousands of records? How can you honestly load thousands of records into a dropdown box and still make it useable? Think of the bandwidth that would be needed on a website to send that list down with every page load? Why put the names in the list in the first place why not fill the list with a filtered list once they type the first letter and update the filtered list when they type more letters? No matter what I think posisitioning to maybe preferred by some but is technically ineffecient.
 
Umm..in this situation, why not just grey out the "s" or otherwise make it un-clickable? If you can't click on it, there will be no confusion.

You say it's simple to have the user type the name, but what about something with slightly more complexity than "smith"? What if someone can't remember the 'eye before see unless after e' (or they're to dumb to know there is such a rule) and they're trying too look up "Seinfeld"?
 
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?