For your design:

Pros:

• Relatively simple UI model to interact with

• Requires few interactions to set up a filter

• Simple to implement

Cons:

• Size of form will increase as more options become available.

• Could be overwhelming to some users.

• No live preview to see the effect changes have on your result data.

• Not very funky :)

Another idea could be to have a filter builder, I've moqued up an example here:

http://www.tobinharris.com/NHProf_Filters.png

This requires more work to implement.

My FAVOURITE filters are ones that you apply to the ACTUAL data as you're viewing it, where you can see results immediately, and tweak. So, you'd be able to click on the duration column in the results, and filter it directly. No need for a context switch.

Most backoffice views (be it desktop or html form) exists from three parts: search, overview and detail. It's a methodology we started using beginning 2001 for our online html based backoffice. Now we more and more are shifting towards WPF, IoC and Composite UI's (very roughly based on SmartClient Software Factory).

Let's say we want to query some customers. Our search screens don't perform the search itself, they only collect the input from the input element and assign them to a (disconnected) entity instance.

This instance is used to build the search query in what I find a rather simple matter:

('s' is a ISession and 'tx' is a ITransaction instance, 'cust' is the 'Customer' instance create by the search screen)

We start with a simple statement:

ICreteria q = s.CreateCreteria(typeof(Customer));

Than we start building up the where clause:

if (!string.IsNullOrEmpty(cust.Lastname))

if (QueryUtils.ContainsWildcards(cust.Lastname))

 q.Add(Expression.Like("Lastname", QueryUtils.PrepareSqlLikeString(cust.Lastname));

else

 q.Add(Expression.Eq("Lastname", cust.Lastname));

Other properties are added is a similair way.

All left to to is calling the List method to get the result:

IList <customer results = q.List <customer();

tx.Commit();

return results;

But than again, we always know what type of information we are looking for.

BTW: We use the normale DOS-like wildcards for backoffice users and replace the '*' and '?' characters with the correct sql versions ('%' and '_'). Because we check if a field contains wildcards we don't perform unneeded like queries.