Accessible UI: designing queries for non-technical users

Creating logical expressions and SQL-esque queries is something that comes naturally to many developers, but what happens when you need to give non-technical users the power to run their own queries without the assistant of a developer?

You need a UI that will guide them through in a way that they’ll understand, and in a way that won’t make them think.

Our software has been designed to be as accessible as possible, and here are some learnings picked up along the way –

Use natural language

Using natural language allow the user to follow the query as if it was a simple sentence. For example, instead of the query being myProperty > 40 it would instead be myProperty is greater than 40.

That is just a simple example, but it can be extended to more complicated ones, such as: SELECT * FROM data WHERE MATCH(foo) AGAINST ('myString' IN BOOLEAN MODE) could be simplified into the much more understandable foo that contains "myString".

Present presets, one at a time

The next issue is presenting to your users — they can’t be expected to just type these plain language questions.

One personal way I like to do this is to have forms that construct themselves as the user builds the query. It could start with a dropdown labelled “Choose the field,” and selecting an option will trigger another field appearing alongside it with all potential conditions (is, is not, contains, etc). If this is a number, then you’d want to show numerical conditions (equal to, less than, greater than, etc). If the condition requires an input, a third field would then appear.

This way, your user is only ever focused on one step at a time, with you thinking for them.

Complexity only comes when necessary

When adding another condition, the user will need to be able to choose how they work together. To continue on our self-constructing form, we don’t really want to show this extra complexity until the user actually wants it.

When they click “Add condition”, we can add an extra row that behaves the same as the first, and show that the fields are nested together. The user will also now need a way to choose how the conditions are joined (&& or ||), as well as a way to easily remove each condition.

Only expose understandable concepts

Whilst it’s possible to create user-friendly queries with multiple levels of nesting, I don’t believe that sort of functionality should be exposed to this level of user. Mixing &&s and ||s is a normal thing for developers, and they can understand the logic — but this is not necessarily the case for non-technical users.

These sort of editors make it possible for anyone who understands their data to be able to query it, but there will always be advanced users who want to push it to their limits. For that reason, I believe there should always be an “advanced mode” that lets power users write raw queries unaided.

The aim of UX design should always be to make things as simple and obvious as possible, and having UI features slowly build up their complexity whilst still guiding the user is a great way to do this, even for tasks that are more traditionally difficult.

We’re always trying to make our software as simple and intuitive to use as possible at DevicePilot, because we aim to make IoT device management and operational management accessible to any level of technical skill.

Interested in seeing more? Check out DevicePilot >>