How can I implement user-friendly boolean logic in a web form GUI?

Question

Currently I have a web application where a user can use dropdown lists to generate SQL SELECT statements like so:

Column Select Dropdown | Operator Dropdown (= != >

Answer 1

I honestly don't see business value in writing the custom "where", "select", "from" or any other SQL commands proxies. Especially, in this particular context (DB access and custom on the fly query) the client opens security gates of hell.

Letting "dummies" (who I'd assume are not capable of using the regular SQL tools) compose "intuitive" query is a disaster waiting to happen. I guess BJ's club credit card info bust of 2003 or 2004 was pretty close to this in spirit. I guess (and it is only a guess!!!) some big marketing boss said "We will save the credit card stripe info so we can leverage that info later." "Do you want only publicly available info in one table and PII statistically bucketed" - asked the developer..... "No, we don't yet know how we want to use that information, develop us a tool to query it in a CUSTOM WAY....." was the first stepping stone on the path to the disaster. :(

Meanwhile, there definitely are places when the UI is needed for composing/parsing expressions (security policy analysis tools, boolean/switch algebra research, etc.) I believe that the best UI is yet to be created (always:)), but if it were created, I'd envision it having possibility to:

1. Parse the expression (should be trivial as one can build parsing tree as user adds expression chunks piece by piece)
2. Show the expression in a parsing tree form (that should be fun drawing it).
3. Show true/false table for the BF presented by the expression
4. Draw BF hypercube (especially valuable for "monotone-like" functions)
5. Create a Karnaugh Map with topological linking (good luck with high dimensional expressions though)
6. Dynamically generate Venn diagram for the expression.
7. Highlight non-essential variables or "expression chunks".
8. Use McCluskey or Petrick method of boolean expression minimization.

Answer 2

When I see a problem like this, I can't help but thinking about implementing it as a stack, similar to how RPN would solve this problem.

The problem here is that it doesn't seem too intuitive

Sample UI: ([Button] <a text box for user input> {list}

Value : < > [Push] [And] [Or]

Stack {

} (HP RPN calculators put the stack above the editing area)

So, if I wanted to write the expression ((A and B) or (C and D)), I would do this: A [push] (stack would contain "A") B [push] (stack would contain "B", "A") [and] (stack would contain "(A and B)") C [push] (stack would contain "C", "(A and B)") D [push] (stack would contain "D", "C", "(A and B)") [and] (stack would contain "(C and D)", "(A and B)") [or] (stack would contain "((A and B) or (C and D)")

if you wanted to add other operators, and there weren't too many, you could just add additional buttons, or make a separate textbox for the operator

Value: < > [Push] Operator < > [Combine]

If you wanted to support unary operators, you'd need to keep track of whether it's a prefix or postfix operator, or just assume prefix (the boolean unary operator "not" is generally prefix). Ternary operators generally have two infix designators, so there's more complexity if you want to support them. Some binary (and n-ary)operators have a prefix, infix, and suffix component "CallMethod(A,B)" So it really comes down to how complex you want to make it.

Just one idea.