This is what's possible when you rethink ‘advanced search’

In our last post we discussed some of the challenges of Boolean search and identified three specific shortcomings with the conventional approach. We argued that each of these limitations provides sufficient motivation to pursue an alternative, and taken together, they provide compelling evidence that a change may be long overdue. In this piece we revisit those shortcomings, and explore ways in which they may be mitigated by alternative approaches.  

Seeing is believing

Let’s start by returning to the example we saw in our previous post:

(“business analyst” or “systems analyst” or “system analyst” or “data analyst” or “requirements analyst” or “functional analyst”) and crystal and report* and analy* and data near analy* and not inventory and not retail and not (ecommerce or “e-commerce” or b2b or b2c)

This example may be relatively simple, but its shortcomings become rapidly apparent:

  • The structure is difficult to perceive: to understand it we have to parse the sequence of tokens and re-create the dependency structure in our heads;

  • It scales poorly as further content or keywords are added;

  • It is highly error prone, as misplaced or missing brackets can be extremely hard to trace. Worse still, such errors may appear innocuous but fundamentally change the semantics.

So what is the alternative? Well, let’s enter this string into 2Dsearch and see what happens:

nested.png

This is how this above example appears using what we call the Nested Layout, in which logical expressions are rendered as a set of nested containers. In this form, it becomes apparent that:

  • The overall expression consists of three sub-expressions and a handful of keywords

  • They are all connected by a logical AND

  • Three of the elements have been negated (as indicated here by the black background)

Transforming logical structure into a visual layout provides a more direct mapping between the underlying semantics and the physical appearance. Moreover, we can now manipulate this expression in ways that were previously not possible: for example, to make it more readable (in a left to right manner), we can configure the layout horizontally (as shown above). Conversely, to fit a narrower space on the canvas, we could configure it vertically or as a square.

So far, so simple. In fact, there have been many attempts to visualize Boolean expressions in precisely this way. But the point here isn’t about information design: instead, it is about interaction design. If we want to edit the expression, we can move terms from one block to another simply using drag and drop. Likewise, we can cut, copy, delete, and lasso multiple objects. If we want to study the effect of one block in isolation, we can execute it on demand:

execute.png

Conversely, if we want to remove one element from consideration, we can temporarily disable it:

disable.png

In each case, the effects of the operation are displayed in real time in the adjacent search results window.

Rendering expressions in this way makes the logical structure more apparent, and thus mitigates the structural issue outlined above. But it also delivers a second benefit: by displaying sub expressions as visual groups, it offers support for abstraction, whereby lower-level details can be progressively hidden and overall structure revealed. For example, by progressively collapsing each of the groups, we can hide details of sub expressions that we don’t need to see.  This mitigates the scalability issue highlighted above. Moreover, we can now give meaningful names to sub groups, so that they can be saved and re-used as modular components. For example, the first disjunction could now become a module for ‘Business analyst’ job roles:

name.png

Finally, what happened to all those brackets? Most of us appreciate how error prone they are, and how difficult it is to match them up by eye. By dispensing with them, we create an environment in which it is no longer possible to make simple syntactic errors. By allowing only the formulation of syntactically correct expressions, the Nested Layout mitigates the reliability issue outlined above.

In summary

In this post we’ve reviewed some of the shortcomings of traditional approaches to advanced search, and explored an alternative, visual approach which we call the Nested Layout. In particular, we’ve shown how transforming logical structure into a visual representation provides a more direct mapping between the underlying semantics and the physical appearance, and shown how this transformation can mitigate these shortcomings. In future posts, we’ll review further variations on the visual approach, and dig deeper into some of the additional benefits that they afford.

In the meantime, if you want to try it out yourself, you can open the above example using this link: https://app.2dsearch.com:/new-query/5b44c81c31a3370004446269

Tony Russell-RoseComment