B&S: Ideas in implementing search in GUI

[Aaron John]

I've been reading the forum posts on how others have implemented searching in their GUI. I have interpreted the requirements to:
- search by name
- search by location
- search by name AND location
- search by name OR location

Some people have two combo boxes, one for name and one for location. Others use textfields to enter name and location.

I don't really want to use combo boxes as it's not clear to me whether the number of names or locations will grow. And I'd rather not have more than one textfield, to save typing. Ideally, I'd have only one textfield and a search button, so that the user can enter name and/or location information, just like using a search engine. But I'm concerned about how to stop the user from entering information other than name or location, e.g. specialties. The find method is able to search on any field, but the GUI should only search by name and location. Hence I'm wondering how to enforce this on the GUI side.

Does anyone have any ideas? Thanks.

[Mike Ottinger]

Hi Aaron,

I implemented the searching using combo boxes. I felt, even with a potential increase in names and locations, that this approaches was still tenable. I had two drop-downs, one for name and location each. Then a radio button indicating a search mode of 'any' or 'both', defaulting to 'any'. With drop-downs, the user input is controlled, thus removing the need for me to do any intensive validation of search terms. Hope this helps...

[Aaron John]

Originally posted by Mike Ottinger:
Hi Aaron,

I implemented the searching using combo boxes. I felt, even with a potential increase in names and locations, that this approaches was still tenable. I had two drop-downs, one for name and location each. Then a radio button indicating a search mode of 'any' or 'both', defaulting to 'any'. With drop-downs, the user input is controlled, thus removing the need for me to do any intensive validation of search terms. Hope this helps...

Thanks Mike. Your reason for using combo boxes was very sound to me. I will most likely follow that approach. Was concerned about the increase in names and locations, but after looking at the data I was supplied with, there were only 12 different locations, and 8 different names. So like you said, any increase in names/location won't affect usability. The search mode of 'any' or 'both' is also a good one. So if the name was Fred, the location was Atlantis and the search mode was 'any', then all records with name Fred will be returned (regardless of location), and all records with location Atlantis will be returned (regardless of name). And it's good that I don't need to do any string validation on entered text, such as invalid characters, case sensitivity. I imagine going down the combo box route could save a lot of headaches later on. BTW, I haven't actually started coding functionality, just mocking up some screens on paper and in code at the moment.

[Liviu Carausu]

Hi Mike !
When do you transfer the names and locations to the client ? Are you making an additional "find" with an empty array every time when a user wants to search something, or are you caching the values somewhere ?
Thanks,
Liviu
[ February 10, 2008: Message edited by: Liviu Carausu ]

[Mike Ottinger]

Hi Liviu,

The contractor names and locations are retrieved from the database as the GUI search panel is being instantiated, and not again after that. If new contractors were to be added to the database, the app would need to be restarted to reflect that. This was the trade-off for a simpler design. Hope this helps.