"Business applications" is a little broad I know, let me narrow a bit:
For example, say we are developing a suite of accounting tools. Search requirements are generally on account number, user name, street address, amount owed etc.
Is implementing a "search engine style" single text box search the preferred option, or should I use a specific search query that is contextual to each tool in my application?
Why not. The QuickBooks accounting package now comes bundled with Google integration. You can immediately bring up google maps from a vendor or customer record.
If you're going to combine several of these parameters into a single query (ie "I want all accounts with this amount owed, but not these account numbers") then it makes more sense to create a "parameter selector". The alternative is the user has to write something to the tune of "owed > 100 and not account 134141". Otherwise, if you're going for simple and quick searches, a Google style text field alone would work wonderfully from a user experience perspective.
You may also consider, based on what fields you're trying to search on, to pre-populate your parameter selectors based on the data current available. That way when you search for all account types, for example, the only things available in the selector are things actually in the database.
For an application based on data, the natural path is search based on data.
Textual searching based on words and their associations is very different from searching on data. It is harder to build a "google-style" search feature that works and is useful for an application based on data.
However, if you can build it right, a "google-style" search feature will feel extremely natural and powerful.
Higher cost, higher benefit.
The main problem I've found with system-wide searches on large systems is following all the rules regarding visibility.
For instance, a user who only sees payables and not HR should not get certain search results, yet the controllers should get everything.
Even in a relatively simple purchasing system where internal users use the same tools as external users, some internal users might not be able to search for products which are not yet approved by supervisors, yet can see some discontinued products which external users cannot search for.
I would say definitely, it is becoming more and more an expected user experience now days, and its a well understood paradigm that's relatively easy to implement.
Hey Jim - so, I developed a 'google style' search for an application I wrote and chose that approach specifically because it is pretty much known to anyone online. I like it because it was easier a cleaner design than the alternative one I had.
One thing I like about the single text box search is that the UI is clean and if you need to search for new stuff down the road, you may be able to avoid modifying the View completely. It might be a little more (or a LOT more) work under the hood for you but who really cares how hard it is to code anyhow? The users don't, generally speaking. I like simple searches and your single text box approach would appeal to me as a user. Anyhow, that's my opinion.
I think the answer depends on your end users. If you have a younger demographic, they might be more used to the Google style search of just one box where they form their own search query. However, if you have an older demographic, they might be used to having a separate field for each search option (account #, address, etc.).
Perhaps a middle ground might be that you can have the one search box with a drop down for possibly fields to search. You would be able to type "account:0123456789" in the search box or be able to select from a drop down "account" and a pop-up would ask what account number to search for. Once they type "0123456789" in the text box it would add "account:0123456789" to the search box. This would get the users adjusted to the correct searching syntax if they are not used to it.
If you can make you search smart enough to work out the context from the search term, I think any interface that takes options away from the user is going to be more usable.
It depends on your precise use-case, but one pattern I have used a number of times recently is a single search field coupled with some optional parameters to narrow the search if required. The search will do its best to derive the context, but the user still has the ability to say "I am looking for an account number".
You can slick the interface to hide those options (in some sort of "advanced" panel) and/or remember the user's preference (not with a config setting, but based on their actual usage - so if the user uses the advanced options, they default to being visible).
Much depends on the users. Unless they are technical users, go with Google. Most users don't want powerful if it means complex and hard to use. They want simple and effective. If you have to train people to use it, they won't.
If you go the Google route, and you have the resources/time to spare, try and make the search intelligent by enabling it to recognize common patterns. Account numbers, addresses, dollar values, etc. Google does this sort of pattern matching. Type in coffee springfield, ma and it'll figure 'springfield, ma' is a town name and make that the context of your search, returning all the starbucks you can stand in springfield.
I'd say.. spend some time looking into how your users actually use search in the context of your application.
So searching for tags.. google style searchbox is good. If you have multiple locations where the user does search, slot in a searchbar to the top right (like a browser) and make sure it always works with the active/last used window. However if you have complex queries and the active filter must be displayed always (to let the user know of the context).. then you need something bigger.
Why not provide an option for both? I'm sure there will be scenarios where one or the other would be appropriate.
Give a specific/field-driven search option (which will use traditional SQL matching, for example) and a Google-style option (which will work using Full-text search features). I'm sure the customer will appreciate that.
If you're not sure if it's worth doing, stick to the old field-driven approach.
It really depends. With the single textbox style, you'll need to parse the input and kick start your search based on it. Example, if the length of all account numbers is 8,invoices, 12 etc, then check the imput, if all numbers and length 8 then execute the search for accounts...and so on.
It's sort of a hybrid control...what I do though is add a combobox right before the text box with options, the user then selects Invoice and then enter the invoice number...more a user friendly UI, but some of my peers says it's an extra click.
There should be optional check boxes to narrow the search. My public library's system really pisses me off when I type in the full exact title of a book and get 5 pages of results. I need to check a box that says "Search in book titles."
Google can be simple because they are really smart. Unless you can properly order the results, you won't make your users happy with a simple text box. You'll have to look at common use cases and really figure out if you can construct an algorithm based on how many input dimensions you want to have.