a example search screen

the above simply says that when you make it easy, then you make great software.

the whole search process, and selection of a match should happen with great ease. the user should not have to remove his hands from the keyboard. in other words, no mouse and keyboard dance should occur. in addition, if the user makes a mistake, then re-searching, or re-trying a another search should again not require the user to use the mouse. in other words, the user should be able to re-search, and re-try and re-search with a real ease. this means that a option to "clear" the existing search should also be available, and that should also be single quick keystroke. (i use the esc key).

ok, so lets run down how this search is going to occur. our example has a very small set of names to search, only 30,000. the little jet engine on a typical pc can return more than 100,000 records in less than a second. thus, 30,000 records is truly a very light weight search for even a desktop database like jet. in fact, since our search field is indexed, then any search is going but in a blink of a eye (200 records maybe?). this means that our search will not produce any kind of noticeable load on a typical office network. if you don't start restricting the records to that form, then you are asking for trouble. look at any software or any web site today that does searching, and you will see that these systems ask the user before they try and display the results. this is so basic to any software that you use. the designers of these systems not only ask the user because it performs faster, but it also eliminates you throwing up a huge screen with a zillion fields etc, and the user asking..ok, now what? so, asking the user what they want to search for is much more user friendly, and hey, it performs 1000's of times faster then being a lazy developer!

so, even with such a small number of names, the amount of matches you get for common names such as smith will actually be quite large. in other words, this is human interface problem, and not one of performance. with 30,000 names, and searching for a common name like smith, we are likely to get about 200 records.

surely, we are not now going to force the user look trough 200 records...are we? we really need some society to prevent cruelty to users. i am amazed that the torture we developers inflict on users by thinking that a search for names can be done with a drop down combo box! would you really want a user to troll thought 200 smiths?

so, the next obvious problem is give the user some type of drill down ability to select the sub set, and further refine the search. the simple trick here is to prompt for both the first name, and the last name. if there are only a few matches, then users can simply hit enter for the first name and cursor should now allow the arrow keys to browse through the pick list. most of the time, a name match by last name is ok, but we still have to help for those common names. in addition, if we provide a prompt for both the last and first name, then if you only know the first name, then you can easily search via first name, and not have to "switch" to some special first name search screen.

so, we have:

search for lastname : _______________

user hits enter key, and then a list of matches is displayed. you cursor is now in the firstname field. if the user chooses not to further refine the search, then hitting enter will place the cursor into the pick list. hence we have

search for lastname : _______________

{hit enter, or tab...match list is displayed}

search for firstname: _______________

the above approach is good for the typical small files you have with ms-access applications. by small, i mean in the few hundred thousand range. in fact, i have found it works well up to about 1 million names. when the files get that large, then the above search technique works well, but the match lists start to get larger and larger. i will save what is to done in those cases for another article.!

so, the resulting search screen looks like:

we are going to search for a person named jonah smith. you can see above that the user only typed in smi (the first 3 characters). however, with our good search screen that is all he needs to type. the user then hit enter. you can see how there are 20 matches. while this file has 30+ thousands names, the only reason why we see only 20 names is that the default radio button of "this season" restricts the search to people who only took a trip this tour season. now the user will probably type in jo in a attempt to match jonah. hence, the next screen show two important things.

  1. - the matches that now starts with jo is now displayed.
  2. - the cursor is now in the pick list. the user is free to use the arrow keys and hit enter.

at this point the user can use the down arrow once, and hit enter key to bring up our name of jonah smith. i of course do accommodate the mouse users. the little set of glasses icon really should be a non graphical with the simple text of view/edit button. while a view/edit text button is better from a user learning and training point of view, i simply like the glasses and it is my program! since i use the little glasses virtually everywhere in my application to bring up details, then the user only has to click on them once to discover and learn what they accomplish. in addition to the user hitting the enter key, or clicking on the little glasses, you can also double click anywhere on the detail line. this double click is again often used and seen in applications, and thus i threw that in also.

you will also notice that there is a add button. that means if the name you are looking for is not found, then you can easily add a new record. since the "add grouping" button is also hot keyed, then alt-a key will add a new record. this means that users can still search, and edit, or add names 100% via the keyboard.

if you curious as to what the booking screen looks like, if you hit enter, the booking would look like:

more neat screen shots of the above ms-access application can be found at:
rides report screens