Toggle FIND button to OK in Find dialog when search result shown

Question

We have a search dialog that has a criteria pane at the top, and a result pane at the bottom. We have placed the FIND button between the two panes in the dialog, but in practice people are expecting to find the FIND button (to trigger the search) at the bottom of the dialog.

The question is: should we have 3 buttons at the bottom of the dialog: FIND, OK, CANCEL

• If you edit a criteria, the OK button is disabled
• If you select a row in the result list panel, the OK button is disabled.

or: should we combine the FIND / OK button into one, using the most recent focus pane to toggle the button?

• if you edit a criteria, the button toggles to FIND, and the result list is cleared.
• If you click a row in the result list pane, the button toggles to OK

Does anyone have experiences from a similar design?

Answer 1

In my experience, Buttons should almost never toggle between functions - this mostly leads to confusion and frustration.

If I have understood you correctly, the OK button would basically select a row from the result set and close the find window.

How about using just "Find" and "Close" as main dialog buttons at the bottom, and displaying a separate button at the selected row that would carry this result over to the main application and close the find window?

Answer 2

how much data are you dealing with?
what about instant search in realtime, eliminating the need for the FIND button?

Answer 3

Some reasons to not use a toggling button ...

1. Double Clicks. In my observation, a fair number of users are in the habit of double clicking buttons.
   You can tell them that they don't need to, that they shouldn't, that the odd things the application is doing are because of it, but they still do it.

2. Performance. You can't predict how long the transition will take (well, without using wall-time as a reference anyway).
   Think the transition is instant? Wait until one of your users is running the application on a netbook running World of Warcraft, Microsoft Word, a video encoder and three different browsers totalling 67 open web pages. Suddenly, instant is several seconds (or worse).
   Think the transition will take a few seconds? Read up on Moores Law and consider what might happen in 3 or 4 years to your runtime.

3. Intelligibility. Users could easily look at your "Find" window and think, "Well, sure, the Ok button must mean search because there's no Find button". Smarter captions aren't the answer, showing the user that there are two distinct operations (Find and Select) works.

Answer 4

Without being able to study your users and their expectations, I would likely just break it all up.

1) Implement search and the various criteria (I'm assuming it's multiple fields)

2) Search takes you to a search results page which displays the criteria above the results in a conspicuous way.

3) In proximity to that search criteria, users are presented with the options to execute a new search or edit their search criteria.

4a) New search returns to a blank criteria page

4b) Edit search returns to a criteria page with previous criteria filled in OR you are able to edit the criteria inline and re-submit the query

This may not be the 'sexiest' method in the world, but it should be solidly usable and you will find yourself devoid of most complaints if your search is fast.

Answer 5

Interfaces like Google Instant are creating the expectation that things happen on their own. Many search interfaces now have similar behavior where the results are altered as you fill in the criteria and things are selected when you click them (or more often these days - touch them).

A minimalist design would have no buttons.

1. Auto-populate the results as the user fills in the criteria (perhaps with nothing until some minimum measure of criteria is provided first to avoid loading the whole database).
2. Close the dialog when the user selects a row and pass that information back to the application proper.
3. Have a big 'X' to close the dialog without selecting anything.

One dialog, no buttons, no confusion, suitable for mobile too.

If you really can't do the auto search thing in step 1 then display a 'Search' button for the user to activate the search, but still have the other behaviors.