Ayende @ Rahien

It's a girl

NH Prof: Balancing functionality, simplicity and form

There are two features that I want to get done before I call a feature freeze on NH Prof and just deal with any bugs and improvements that come up until I feel it is mature enough to call it v1.0.

One of them is filtering capability. This was a pretty common request once people started realizing the kind of things that they can do with NH Prof.

Ad hoc filtering into NHibernate’s activity can bring up a lot of insight, and I certainly think that this would be an good feature to have.

The problem is that while this is a good feature, it also introduce a significant amount of complexity. This wouldn’t be a problem if the complexity was on the application side. We can deal with complexity.

The problem is that I think that this introduce a not insignificant amount of complexity into the user's’ hands. Take a look at the mock UI that I created:

image

This isn’t the way it will end up looking, but it is a good place to start the conversation.

What is your opinion?

Comments

Tobin Harris
01/18/2009 11:50 AM by
Tobin Harris

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.

Dave
01/18/2009 03:00 PM by
Dave

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.

Comments have been closed on this topic.