The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Best 'Search' interface?

I work for a software house that develops bespoke business database applications (mostly Windows apps, in .NET 2005). We want to redevelop our standard 'search' user interface but we can't agree on what it should look like.

Ideally we need something that's very accessible/easy to use for casual users, but with an option to be used in a more sophisticated manner for advanced users (ie including AND's and OR's and possibly raw SQL).

What are the best 'search' interfaces you've seen? Or do you have any views on how to go about designing this? I'm meaning field-based searches, not just the full-text-search type of interface we see on this site and Google etc. Ones where the user will want to specify which field(s) in which table(s) they want to search within as well as specifying what data they want to look for.

Thanks in advance for your input.
Miranda Send private email
Tuesday, January 09, 2007
 
 
I think the iTunes one for constructing Smart Playlists is pretty good.
John Topley Send private email
Tuesday, January 09, 2007
 
 
The way trac handles 'custom queries' is quite straight forward, but allows for more complex searches without (initially) taking up space or looking 'scary'.
It's not particularly special, or unique, but I quite like it.


For an example:
http://trac.edgewall.org/query
G Jones
Tuesday, January 09, 2007
 
 
For business database apps, you’ve probably noticed that for a given user group and window there are only 1 to 4 query parameters and little boolean that account for the vast majority of use. For example, your customer service representative rarely if ever needs more than query by account number, customer name, and maybe range of order dates, with only AND Boolean (or no Boolean) combining the parameters. Nonetheless at least for some users need complicated ad hoc querying for rare but typically urgent circumstances. This implies a two-level basic vs. ad hoc querying UI design. The query dialog or panel by default displays the controls for the few basic parameters (e.g., a blank for account number, blank for name), and maybe controls to select one or two canned queries relevant to the user’s usual tasks (e.g., all orders with balances outstanding). An “Advanced” or “Custom” button opens another window for ad hoc querying for exceptions.

The ad hoc querying window may be something like trac, but if this feature needs to support things like joins and complex Boolean logic, and your users don’t know SQL, I’d look for ideas from research in graphic querying, particularly the work in the 1990’s out of the Database and User Interface Group at the University of Rome. For example:

- Albert N. Badre, Tiziana Catarci, Antonio Massari and Giuseppe Santucci (1996). Comparative Ease of Use of a Diagrammatic vs. an Iconic Query Language. Proceedings of the 3rd International Workshop on Interfaces to Databases, Napier University, Edinburgh, 8-10 July.
- Tiziana Catarci, Maria F. Costabile, Stefano Levialdi, and Carlo Batini (1997). Visual Query Systems for Databases: A Survey. Journal of Visual Languages and Computing, 8:215--260.
- Tiziana Catarci and Giuseppe Santucci. (1995). Diagrammatic vs Textual Query Languages: A Comparative Experiment. In Stefano Spaccapietra and Ramesh Jain, editors, Proc. of the 3rd IFIP 2.6 Working Conference on Visual Database Systems.
- Tiziana Catarci (1994). What Happened when Database Researchers Met Usability. Information Systems, 25:177-212.
- A. Massari, S. Weissman, and P. K. Chrysanthis (1996). Supporting Mobile Database Access through Query by Icons. Distributed and Parallel Databases, 4:249--269.
Michael Zuschlag Send private email
Tuesday, January 09, 2007
 
 
I'd kind of have to agree with Zuschlag.

From practical experience, it's very rare that a user will want multiple search options to the extent that you'd add additional checkboxes and radio buttons. More annoyingly, each group of users will want their own subset.

I get the impression that people prefer to "refine" their searches because of the immediate feedback. In other words, say I've written a real estate application. Most people tend to want to select all homes in a geographical area, get the results first, then eliminate homes above a certain price point, then eliminate homes with only one bathroom, and so on. When they've reached the point where there's no data to display, they instinctively know they just have to undo their last criteria.

In contrast, if you give them all of their options up front and they pick five or six different things and get no data, they don't know what to change or even if the system is working.

The significant collorary is that if a person is smart enough to figure out all of the search criteria ahead of time, and is comfortable enough with the system to know the difference between no data and a broken system, they're usually smart enough to use a SQL like query language. That is, they'll just use one search box and write something like "New York City AND three bedrooms AND two baths".

So it's really an audience dependent either-or situation, lots of hand holding or a query language.
TheDavid
Tuesday, January 09, 2007
 
 
There was a query interface developed by IBM back in the eighties called Query By Example (QBE) and is currently supported by DB2 in the Query Management Facility (QMF). The system is pretty simple, you just fill in each column with the value or range of values that you want to see in the resulting query (blank columns can have any value).

There is a good description of QBE in the textbook "Database Management Systems" by Raghu Ramakrishnan and Johannes Gehrke. Chapter 6, detailing QBE, can be had online here:

http://www.cs.wisc.edu/~dbbook/openAccess/thirdEdition/qbe.pdf

I would think that a limited, task specific version of QBE could be jinned up in a few man-months.
Jeffrey Dutky Send private email
Saturday, January 13, 2007
 
 
I also agree with Zuschlag.

Read up on inductive user interfaces before proceding. What you really need to ask yourself is "what task is the user performing". For any given task there will only be a couple of logical query parameters. Any more than that and your screen doesn't target any specific task which makes it much harder to understand. When you find 10+ query parameters on a screen or some box that says "type raw SQL here, group clauses with AND or OR" then you know a programmer was involved, not a real user. Programmers are data-centric. Users are task-centric.

Think about your current screens and try to imagine what tasks each user would be performing if they fill in certain query fields. You'll find most of them to be mutually exclusive which implies that they shouldn't be on the same screen at all.
anon
Tuesday, January 16, 2007
 
 
There are many types of searches you could design. There is the straightforward multiple parameter searches where you search a particular entity (table?) like accounts, invoices, payments etc. You would design the SQL from a base SQL (SELECT * FROM tablename WHERE...) and then append with the ...AND extensions.

A more customiseable search would be a custom database query where users could select tables and create their own SQL without any technical knowledge. You could also assist them with the SQL statement such as using dropdown lists for =, NOT EQUAL TO, GREATER THAN, JOINs, etc. Make it as simple as possible with much of the technical SQL constructs hidden from the user.

And of course, don't forget the SORT functionality. You could design so that sorting means just clicking the column headers (toggling between ascending and descending).
Ezani Send private email
Tuesday, January 16, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz