Query Filters, UI Design and the CNF/DNF caveat nobody talks about

ManojGompa — Sat, 16 May 2026 09:03:09 +0000

I've worked on plenty of things — some more complex, some more well-known. But every now and then, something small stops you mid-implementation and turns out to be worth thinking about properly. No architecture concepts, no distributed systems — just a quiet little observation that I thought was worth writing down.

As part of a project I started working on recently, I had to integrate a custom boolean expression filter into the product. Let users define conditions, combine them with AND/OR, nest them — you know the kind of thing.

And my first instinct was obvious: a visual tree-like expression builder. Interactive, widely used, makes the logic visible without making users write raw expressions. Done, right?

But then I started wondering — is there a way to do better than the tree? Something flatter, more constrained, but still usable? Even though I'm not a UI designer or engineer, this felt like an interesting problem to sit with for a bit.

So I thought about it. And the more I thought, the more I kept circling back to the same two goals:

User friendly — the UI shouldn't require users to understand grammar, parentheses, or boolean syntax at all. Just point and click.
Flexible — even if the UI is constrained to a specific form, users should still be able to express whatever nested logic they have in mind. The shape restricts the interface, not the expressiveness.

Those two goals seem simple. They're actually in constant tension. And that tension is exactly what makes filter UI design surprisingly hard to get right.

The two obvious extremes (keeping the tree aside for now)

Let's start from scratch. You need users to express logical rules. Your first instinct gives you two options:

Option A — just let them type it:

(country = "IN" AND plan = "pro") OR (referral = true AND NOT churned)

Powerful. Expressive.Shows every user who isn't a developer the exit.

Option B — a flat AND/OR toggle:

Match [ ALL ▾ ] of the following:

  ┌─────────────────────────────────┐
  │  country     is    India        │
  │  plan        is    Pro          │
  │  signup_date after  Jan 2024    │
  └─────────────────────────────────┘

Clean. Approachable. Works fine until someone needs (A AND B) OR (C AND D) — at which point they're completely stuck and don't even know why.

And that got me thinking — is there a way to keep the UI minimal and clean, but not silently take away expressiveness from the user? Like, can you have both?A UI that looks simple but doesn't secretly cap what logic you can express?

That question is what pulled me deeper. And that's when I started thinking: what if you take a more structured approach to the logic itself ? What if the UI enforced a specific logical form?

That's where CNF and DNF entered the picture — and honestly, they seemed like the perfect answer at first.

Wait, CNF and DNF? — a quick refresher

If those terms are unfamiliar, here's the short version:

DNF — Disjunctive Normal Form = OR of ANDs

Group 1: (A AND B) ─┐
Group 2: (C AND D) ─┼─ OR'd together
Group 3: (E AND F) ─┘

CNF — Conjunctive Normal Form = AND of ORs

Clause 1: (A OR B) ─┐
Clause 2: (C OR D) ─┼─ AND'd together
Clause 3: (E OR F) ─┘

Both are normal forms for boolean logic. Both are well-studied, well-understood, and — crucially — both have a shape that maps directly to a UI.

DNF especially clicked for me, because it directly addressed both goals:

Goal 1 — user friendly:

You never show the user a text box or ask them to write parentheses. The UI becomes:

Add conditions inside a group → they get ANDed together
Add another group → the groups get ORed together

That's it. No syntax, no grammar, just buttons and dropdowns.

Goal 2 — flexible:

Here's the thing that actually made DNF feel like the right answer — any boolean expression can be converted to DNF. In theory, that means the form doesn't cap what users can express, just how they express it. Unlike the flat AND/OR toggle, a user could say "all of these conditions together, OR this other set" — which covers a meaningfully wider slice of real-world logic.

HubSpot does something similar :

┌─── Group 1 ─────────────────────┐
│  country = India                 │  ← ANDed together
│  plan = Pro                      │
└──────────────────────────────────┘
           OR
┌─── Group 2 ─────────────────────┐
│  referral = true                 │
│  signup_date > Jan 2024          │
└──────────────────────────────────┘

You can explain this to a non-technical people in 30 seconds.It's flat. It's readable. User friendly. More expressive than a flat toggle.

Both goals, one clean structure. I was pretty convinced this was it.

So when does it fall apart?

The explosion problem — this is the caveat

Here's the part that actually surprised me when I dug into it.

Both CNF and DNF have what's called an explosion problem — and it goes in opposite directions for each.

Take this expression: A AND (B OR C OR D)

Totally reasonable thing to want. But DNF doesn't allow OR inside an AND-group. To get it into valid DNF, you have to distribute A across the OR:

  A AND (B OR C OR D)
             ↓
  (A AND B) OR (A AND C) OR (A AND D)

Three output clauses from one input. Now go a step further:

  A AND B AND (C OR D OR E OR F)
             ↓
  (A AND B AND C)
  OR (A AND B AND D)
  OR (A AND B AND E)
  OR (A AND B AND F)

A is duplicated four times. B is duplicated four times. And this is provably unavoidable — the exponential blowup when converting to normal forms is so well-documented that a whole separate technique, the Tseytin transformation, was invented specifically to work around it. It's not a bug you can engineer around. It's a property of the form itself.

CNF hits the same wall in reverse when you distribute OR over AND.

The bottom line: any arbitrary boolean expression converted to CNF or DNF can blow up exponentially in clause count. And when your UI is the CNF/DNF structure, that blowup hits the user directly — as repetition, as confusion, as "why do I have to add this condition to every single group?"

Real users hit this all the time without knowing why. There's a HubSpot Ideas thread where users have been asking for custom filter rules with proper nested logic — the ask has been open for years.
The problem isn't that these UIs lack expressive power — mathematically, DNF can represent any boolean logic. The problem is that the moment complexity crosses a threshold, the UI stops feeling like a tool and starts feeling like a constraint. Users know exactly what they want — they just can't map it to the interface without repeating the same painful things over and over.

So where does that leave us?

Honestly, the flat DNF/CNF UI isn't widely used in the wild — and I think this is why. The explosion problem is real, and once you've seen it, a strict two-level structure feels like a trap.

What most UIs that handle complex logic actually reach for is some form of a tree abstraction — technically an Abstract Syntax Tree (AST). Instead of enforcing a fixed two-level shape, you let users nest groups inside groups:

AND
 ├── country = India
 ├── plan = Pro
 └── OR
      ├── referral = true
      └── AND
           ├── signup_date > Jan 2024
           └── trial_used = false

Visual indentation replaces parentheses. You can nest as deep as you need. No duplication, no explosion.

┌─── AND ──────────────────────────────────────┐
│  country = India                              │
│  plan = Pro                                   │
│  ┌─── OR ──────────────────────────────────┐ │
│  │  referral = true                         │ │
│  │  ┌─── AND ───────────────────────────┐  │ │
│  │  │  signup_date > Jan 2024            │  │ │
│  │  │  trial_used = false                │  │ │
│  │  └────────────────────────────────────┘  │ │
│  └──────────────────────────────────────────┘ │
└───────────────────────────────────────────────┘

So the tree approach answers the question I started with: yes, you can have a minimal-looking UI that doesn't secretly limit what the user can express. You just have to go one abstraction level deeper than DNF/CNF.

The spectrum — and why this is worth knowing

All of this sits on a spectrum:

Flat toggle → DNF/CNF editor → Tree/AST builder → Free-text expression
  (simple,          (structured,      (flexible,       (powerful,
 hits ceiling      hits explosion     scales well,      intimidating
   fast)            at scale)        but can be flashy)   to use)

Move right →more expressive power, more complexity to build
Move left → easier to build and use, hits a ceiling faster

This whole thing started from one implementation question and ended up pulling in boolean algebra, normal form theory, and how real products have handled it. That's the part I find genuinely interesting — not that the problem is hard, but that you wouldn't even know there's a formal angle to it unless you happened to dig sideways into it.