An exploration into Query Builder UX, and interrogative HCI

In every company I have worked, there has been a situation where an interface to query/manipulate data has been needed. So just thinking about the approaches I have explored, pros and cons of each of them, I felt this was an article I should be writing. This article is in no way comprehensive, but I would just like to catalog all my learnings and thoughts on the various UX approaches and my thoughts on them

Code window / Command input

This is the original way of interacting way with computers. From when a keyboard and monitor have been attached to a computer, to even before that, direct commands that query stored data have always been used. More modern interfaces also will eventually translate the query into code that a computer can use to interrogate data.

UX wise this is very simple, all you need is an input box and an execute button

And we’re done, we have an effective UX paradigm for querying data. User just types in a query in an system defined format and results will be obtained

But no this won’t do, when you really think about it this paradigm has a lot of problems :

User can make syntax errors, syntax has to be learned
Editing with long queries can be error prone
Long queries are hard to read/understand
There might be context specific nuances
Can create blank page anxiety
etc

A lot of these can be fixed, some of these fixes can be seen in newer code editors also where things like auto suggestions, collapsible sections are already present

Below are images of an improved query window

These are some of the fixes

Replace placeholder text, with text that is suggestive (gets over blank sheet anxiety) and educative (remind users about syntax)
Add inline suggestions (with helpful descriptions)
Use colour coding to highlight different parts of the query (keyword, data type, user value etc)
Add inline error highlighting (Easier for users to identify and fix )
Allow nested queries to be individually collapsed or expanded
Allow entire query to be toggled between minified and expanded (over operators/conjunctions)

But even with all of these improvements, most novice users will find this interface intimidating. And hence such interfaces are generally exposed to pro users in highly contextual situations

Interface driven / prescriptive elements

This is a diametrically opposite approach, where textboxes and dropdowns are used to replace various parts of the query syntax. So instead of the user typing in freeform, for every part of the query he chooses options from the dropdown, or enters values in input boxes.

Are we done now. Yes this approach has no room for syntax errors, has no need for the user to even no syntax. Is both mouse and keyboard friendly etc. But the above UX is highly simplistic. Modifying it to have the same flexibility as that allowed by a simple command window, is where all the complexity and the problems come up.

Before listing the problems, let’s redesign the interface to allow for conditionals, and a 2 level nesting hierarchy.

Now the biggest problem becomes even clearer, but to make it even more obvious, lets just replicate the first query (used in the code editor paradigm) in this interface driven paradigm

Now we can get down to list the problems of this paradigm

The interface becomes large unwieldy when the query becomes more complex. This is intimidating to users, allows for mistakes and is not easy to glance and understand
Interface elements that might not be needed are retained
Interface allows for only one query structure

Just like before this interface can be improved, and here are the possible fixes

Collapse all sections that are not currently being edited
Add dropdown descriptions

and more. This is how the same interface would look then

While these are the two main approaches commonly seen in SaaS tools, I still think the major failing is in the selection of various fields. For the next part of this post I will look at other alternatives , both of my own creation and what I could find on the internet