Domino View/Search Builder -- What's The Logic?
At the moment I'm working on a Flex app that will allow the user to build their own views from backend Notes data. It's a bit like a Search Builder and you can see the guts of it in the Flex app embedded below:
You can use the "Add New Filter" button to add new filters/search terms. The dropdown that says "Title" in it (by default") allows you to select the field and then (depending on what type of field it is) you can tailor the filter by text, number or date.
When you've added all the filters you press the "build" button and it will display the proposed view selection criteria in the white box.
Logical?
It works. Kind of. Where it falls down is its handling of the AND OR logic. I just can't get my head round it and [invoke lazy web now] I wondered if you could help.
How should a Search Builder compile the search terms with AND OR logic?
Consider the following terms:
At the moment the app comes up with the following search string:
SELECT title="Hello" | date_created < [02/24/2009] & unit_value<50 Surely that's wrong. Shouldn't it be:
SELECT ( title="Hello" | date_created < [02/24/2009] ) & unit_value<50 Or should it be:
SELECT title="Hello" | (date_created < [02/24/2009] & unit_value<50) The results of both are different, but how would it know which to assume the user meant?
It gets more complicated as you add more and more terms and I can't decide the best way to deal with it. Anybody know how to do it or of an example that already does?
Skip to the 
You can subscribe to an individual
As developers we know how the logic works. But general users do not understand logic. "I don't got nuffin'"
As it stands, traditional logic dictates that AND has a higher precedence. So your second bracketed formula would be the correct one. But as the old adage says, a computer does what you tell it to do, not what you want it to do. When the correct search query is the former how do you tell it?
Perhaps an additional tickbox to "pair" certain terms together. But again, would users understand what it is there for? Maybe changing the logical options to say "Or (pair)" or "And (pair)" to say which terms should be bracketed. It's a hard choice. But then, in my experience, whenever you give users choice you're in for a tricky ride.
Maybe you could add some braces displayed on the right, to show which terms are bracketed together, and force the user to accept the bracketing? Perhaps bracketing every two terms together. But is that the right thing to do? Like so many things, I think you've opened a can of worms here. No matter what you choose, you will almost certainly end up with a user training issue.
You could do a few things:
* like the smart playlists in iTunes, allow your user to define a series of conditions and then ask them if the search results should match any or match all of the conditions
* a "filter search results" option, which basically results in your original search conditions between brackets with an "AND ..." tacked on.
No matter which way you go though, you'll always have a user complaining about it - I 'd have thought you knew this by now ;-)
Its an interesting one.
My initial thought is - whose the user audience? You have designed a sophisticated query tool, do they really need that level of control?
If they do then try it this way. Don't allow the user to select an OR - approach it more as a wizard where they define the initial query with as many ANDs as they wish - in fact I wouldn't have your add new filter button have and clickable AND appear below the first row which displays the next row.
Once they have completed the first part of the query they can then add another filter / query which would be then appended to the first with an OR - you could also then bracket each of the queries separately.
It seems to me that the builder doesn't allow the user to specify exactly which term to apply each AND/OR to. That's why you're struggling to bracket the logic.
Why don't you allow the user to specify their own bracketed terms?
In between the AND/OR and field name parameters, give the user the option to specify an 'open bracket'. And give them an option to specify a 'close bracket' after the value field. Finally, do a validation that all open brackets have a corresponding close brackets before building the search term.
Then your code can just build the string exactly as specified by the user.
Jake,
(2cents)You're gettin into dangerous territory now, because like Dragon said, users don't know logic 101. But if you were to implement this for power users or trained users, I agree with everyone else to include a "bracket" icon that the users could indicate near the "X" icon to show how they wanted to group it. Otherwise assume a default operation based on the second interpretation you have written..(/2cents)
I did exactly the same as a Delphi 4 drag & drop SQL query component some 10 (or so) years ago. I ended up adding "(" and ")" as check boxes each start and end of the rows. It works but becomes a bit hard for the regular user.
GUI:
[x] ( [Type] [=] [Cat] ) [ ]
[OR] [ ] ( [Type] [=] [Dog] ) [x]
[AND] [ ] ( [Category] [=] [Pets] ) [ ]
=>
(Type = "Cat" OR Type = "Dog") AND Category = "Pets"
It helps to display the query as it will be executed too, not just the GUI.
What a can of worms! It's a relief to see it is in fact quite complicated and it wasn't just me being stupid.
I think I need to go back to the customer and work out what types of searches they are likely to perform and what level of user will be doing it (non-techies for the most part).
It might be that I can do away with it all and just have a "Match all/any of the following" option.
Thanks for the feedback so far though. I'll digest fully later on.
Jake
Doesn't the "mail rules" in the mail template already have something like this in it ?
I know it's probably not exactly the same, but it's always easier to follow an example...
Just a thought...
I second the problem with users. The best one is "Show me all red cars and all blue cars". The users then try something like
CARS = "Blue" AND Cars = "Red"
and then get nothing.
I would probably try to go for a simple search, with simple words lookup, like you said, and an advanced lookup where you can input a whole boolean logic string thingy.
I think Mark has it sorted best taking into account a broad user base. In addition to that, maybe add just a little tutorial help screen of what to do and what not to do? For example, not using the same field in each query (which you may be doing already).
Would you believe I just spec'd this for my customer today, before seeing your demo? Unbelievable timing. I really owe you now. :-)
To answer Mark's question, the audience in our case is the system owner who is randomly peppered with requests for information about their system from auditors and managers. The need ad-hoc ability on demand, not waiting for a view to be designed by the dev team. In our case, they understand the limitations but appreciate the flexibility.
Jake, I've got some stuff conceptualized already but nothing as detailed. We should work this over in concert.
To handle the situation where the user picks Cars="blue" as well as Cars="red", parsing the query should detect the duplicate and replace it with (Cars="blue" | Cars="red").
Doing this requires the query string to be parsed into tokens. You can provide ease of access to this in a number of ways, such as using a list / array of query terms. Looping through to assemble a query string should provide some cover to pick off conflicting statements and resolve them intelligently.
As I mentioned to you (Jake) in an email, post parsing the query is just about unavoidable and gives you the control needed to sort out the logic in a predictable manner.
I built something just like this in HTML a long time ago but it never went gold and didn't get hammered by real users. It can provide a lot of utility to someone who is just trying to answer a simple question.
Here's the page for my query builder ... hard coded for this particular application. The user fills in the fields and a Java query-save agent creates a query string much like those discussed here.
The real magic is in the agent. It's not all that big. Half of it is about building the query. The other half is formatting the output.
I can tell you it was quite difficult to work out the logic; the implied "AND" and "OR" operations between the various query fields in the form. It took a couple of months to get all the corner cases sorted.
Let me know if you want to see the code. I can send you a copy.
Peace,
Rob:-]
Forgot to post the link to the search page. Here it is. Rob:-]
http://www.simplesearchapartments.com/austin.nsf/search
Oh, one little brag ... Each time the customer wants to roll out another area all I have to do is make a new database from the template. They didn't even have the multiple city idea in their requirements, but I knew they'd want it. They rolled out Austin first and, when they asked for Huston they got a real (pleasant) shock at how easy another city was to add. Thanks Lotus!
Peace,
Rob:-]
Jerry. I'll be in touch.
Rob. Likewise, I'll be in touch.
Thank you both for offering to help.
BTW Rob - never tell a customer how easy something is ;o)