Designing the Structured Search Experience: Rethinking the Query-Builder Paradigm

2.1 Boolean Strings

The use of command-line query builders currently serves as the de facto paradigm for all manner of advanced search experiences. However, despite their ubiquity, the practice of using Boolean strings to express complex information needs suffers from a number of shortcomings.

First, Boolean strings are an ineffective vehicle for communicating structure. The use of parentheses as delimiters may be commonplace in programming languages and other machine readable media, but when intended for human interpretation they rely on additional physical cues such as indentation. In the absence of such visual signals, parentheses can become lost in an undifferentiated sequence of alphanumeric characters, and trying to interpret the meaning and structure of such expressions can be overwhelming (Russell-Rose & Chamberlain, 2016).

Second, Boolean strings do not scale well. As users add terms to a Boolean string, it grows uniformly in length. This may be manageable for a handful of terms, but as the number grows to double figures and beyond, transparency degrades. A common solution to the analogous problem in software development is to offer some form of abstraction, so that lower-level details become progressively hidden, revealing higher-level structure. But Boolean strings in their native textual form offer no such facility.

Third, Boolean strings are very error-prone: even if the query builder automatically checks syntax, it is still possible to place parentheses incorrectly, which can inadvertently change the semantics of the whole expression. This gives rise to errors whose effects may not become apparent until long after the initial search is completed.

To mitigate these issues, many professionals rely on previous examples of best practice. Healthcare information professionals, for example, draw on repositories such as MedTerm Assist (Saleh et al., 2014), Search Strategy Library (Gulhane, 2019), or other sources of ready-made search blocks (de Jonge & Lein, 2015). These resources provide an archive of search strategies that users can reuse via copy and paste. However, the library and information science community has not universally adopted them, and the volume of content in such collections remains relatively modest.

Many information professionals use word-processing tools such as Google Docs or Microsoft Word as a platform for developing search strategies. However, there are many reasons document-centric tools such as these are not suitable for search-syntax development:

• Auto-correction can undermine truncation and corrupt truncated formats.
• Spell checking can obfuscate important differences between British and American English and can create unwanted duplicates.
• Auto-conversion of straight quotations (“”) into curly quotations (“”) can cause errors in some platforms such as Ovid SP.
• Copying and pasting text fragments between different word-processing tools can lead to loss of non-print characters.

In summary, the practice of manipulating search strategies as text strings compromises their ability to function as transparent, reproducible, executable artifacts.

2.2 Command-Line Query Builders

As mentioned above, the command-line query builder has served as the default for structured searching since the first online databases. However, errors and inefficiencies often compromise their output. In their study of sixty-three MEDLINE strategies, Sampson and McGowan detected at least one error in over 90 percent of these, including spelling errors, truncation errors, logical operator error, incorrect query line references, and redundancy without rationale (2006).

In command-line query builders, users build search strategies incrementally as a set of discrete expressions they reference by line number and combine using various operators. This type of approach offers the benefit that strategies can be built using techniques such as successive fractions or building blocks (Booth, 2008). It also allows the searcher to review the number of results returned at each step and to refine their expressions accordingly.

However, it is questionable whether line numbers are the most effective way to organize a series of interconnected logical expressions. If the goal is to provide a principled mechanism for structured searching, it seems odd to expect the user to rely on something as arbitrary as a line number. This is the conceptual equivalent of the GOTO statement used in first generation BASIC, and this approach was discredited many decades ago (Dijkstra, 1968).

We speculate on how much support is offered for constructing expressions that are syntactically correct and semantically transparent. A well-designed query language could, for example, support concepts such as:

• Encapsulation: whereby a single component contains data and functions. Arguably, the command-line approach supports this, but a lack of facility for naming reusable elements compromises it.
• Abstraction: whereby a collection of lower-level instances generates a higher-level concept. For example, in Figure 2, lines one to seven may be interpreted as the ‘problem’ element of a PICO search (Shokraneh, 2016). However, it is difficult to manipulate this sub-element as a discrete component, thus compromising its effective reuse.

There is a further issue with the command-line paradigm. As Figure 2 illustrates, the output of such query builders is a set of procedural commands that are combined to express the declarative semantics of which documents to retrieve. This raises the question: if the goal is to express the declarative semantics of an information need, then why force the user to think procedurally? One explanation may be that the command-line approach reflects the days when searchers sent text-based commands to remote—and expensive—subscription-based resources. In this context, the continued adoption of command-line query builders reflects a historical requirement rather than any enduring quality of the search experience.

4.1 Building Search Strategies

At the heart of 2Dsearch is a graphical editor which allows the user to formulate search strategies using a visual framework. Concepts can be simple keywords or attribute:value pairs representing controlled vocabulary terms (e.g. MeSH terms) or database-specific search operators (e.g. field codes and other commands). Users can combine them using Boolean—and other—operators to form higher-level groups and then iteratively nest them to create complex expressions.

Figure 3.

The 2Dsearch application showing the query canvas (left) and the results pane (right).

The application consists of two panes (fig. 3): a query canvas on the left and a search results pane on the right, both of which users can resize; they may also detach the results in a separate window. The canvas includes an overview widget which allows the user to navigate to elements outside the current viewport. Adopting design cues from Google’s Material Design (https://material.io) language, a sliding menu on the left provides file import, file output, and other options. Complementing this is a navigation bar which provides support for document-level functions such as naming and sharing search strategies.

Although 2Dsearch supports the creation of complete strategies from a blank canvas, its function and value are most readily understood by reference to a sample text-based search strategy, such as that in Figure 2. A trained professional may be able to mentally parse the sequence of commands and interpret the general approach, but without associated documentation it is difficult to understand exactly what the searcher intended, let alone modify, debug, or reuse this strategy.

Figure 4.

Visualizing a text-based search strategy.

However, opening this strategy using 2Dsearch makes its structure much more apparent (fig. 4). The overall expression consists of a conjunction of two disjunctions (Lines 7 and 22), the first of which articulates variations on the fungal infection concept, while the second contains nested disjunctions to capture the diagnostic test (serology) and associated procedures. Evidently, the line numbers themselves are arbitrary in this context, but by displaying them as nested blocks with transparent structure, 2Dsearch offers support for abstraction in which users can hide lower-level details and reveal higher-level structure. Moreover, it is now possible to give meaningful names to such blocks, so they can be saved and reused as modular components.

Although visualization of search strategies in this manner offers immediate utility, the true value of the approach is in the interaction design. For example, to edit the expression, the user can move terms from one block to another and create new groups simply by combining terms. They can also cut, copy, delete, and lasso multiple objects. If they want to understand the effect of one block in isolation, they can execute it individually or use its hit count, as shown in blue ellipses in Figure 3. Conversely, if they want to remove one element from consideration, they can temporarily disable it. The effects of each change display in real time in the adjacent search results pane, which allows users to rapidly optimize their search queries.

As we discussed in Section 2, crafting syntactically correct search expressions can be an error-prone and tedious process. Line numbers, parentheses, square brackets, punctuation, whitespace characters, and Boolean operators all have the potential for errors. However, a visual representation can delegate to lower-level system functions the task of generating syntactically correct expressions. Transforming logical structure into a visual layout provides a more direct mapping between the underlying semantics and physical appearance, and it provides a more intuitive experience for users wishing to experiment with different approaches.

The view in Figure 4 (which we call the Nested View) is just one of many. Another way to understand the hierarchy embodied in complex searches is to apply the metaphor of the family tree. The Tree View represents the search as a visual hierarchy, with the root node at the top and each level below represented as successive generations of children (fig. 5).

Figure 5.

The Tree View.

This example displays the search in its entirety, shrunk to fit across the page. But it’s easy to zoom and reveal just the higher levels or to close branches and focus on one particular region of the tree (fig. 6).

Figure 6.

The Tree View, partially expanded.

Boolean strings may be inefficient and error-prone, but they do offer one key benefit: one can read them left to right. Of course, this attribute may reflect nothing more than the inertia of decades of convention, but there remains something enduring about being able to read searches in this way. We developed a third visualization, the Inline View to support this principle. Like the Nested View, the Inline View maps conceptual hierarchy in a manner that aligns groups along a common midline, facilitating a natural left-to-right reading (fig. 7).

Figure 7.

The Inline View.

Notice that in this view we elevate the operators to same level as content items, so they appear in sequence. This means we can also reduce some of the chrome around groups, leading to a cleaner layout. Again, we’ve shrunk the figure to fit across a single page, but it is easy to zoom to display only the higher levels or to close branches to focus on one particular region of the search (fig. 8).

Figure 8.

The Inline View, partially expanded.

4.2 Optimizing Search Strategies

2Dsearch functions as a meta-search engine, so is in principle agnostic of any particular search technology or platform. In practice however, to execute a query and retrieve results the semantics of the canvas content must be mapped to the syntax of the underlying database. 2Dsearch achieves this via a set of adapters for search platforms such as Bing, Google, PubMed, Google Scholar, Epistemonikos, and TRIP Database. Users select these in the interface via a drop-down control.

In developing a search strategy, information professionals will often revise and create alternative versions to find the best combination of search blocks and to understand the contribution of each to the overall result set. With 2Dsearch, it is possible to disable or enable individual blocks and dynamically investigate their contribution to the results, eliminating the need to create or manage alternate versions.

It is common for healthcare information professionals to want to search more than one database, particularly when undertaking a systematic literature review (Russell-Rose & Chamberlain, 2017). This requires a process of translation of the search strategy to match the syntax of each database. For a relatively simple query this may not be a major undertaking, although the user still has to understand which elements are platform-specific, identify the closest equivalent in the other database, and manually edit their query—all of which is laborious and time consuming (Bramer et al., 2017). 2Dsearch invokes the PolyGlot Search Translator (http://sr-accelerator.com/#/polyglot) which provides automated translations on the Query tab of the result pane (fig. 9).

Figure 9.

Automated translations of search syntax.

Although the primary purpose of 2Dsearch is to embody new approaches to structured searching, we recognize that much content exists in legacy form. For this reason, 2Dsearch provides support for importing traditional text-based strategies and rendering them on the canvas as editable, executable objects. In so doing, 2Dsearch identifies errors in the form of redundant structure, e.g. spurious brackets or duplicate elements (fig. 10).

Figure 10.

2Dsearch identifies duplicates in imported search strings and labels them with exclamation marks.

A further challenge in search strategy development is identifying appropriate keywords and controlled vocabulary terms. 2Dsearch provides support for this via a natural language processing (NLP) services API (fig. 11), which uses a variety of machine-learning techniques and manually curated resources (e.g. MeSH, DBPEDIA) to provide interactive query suggestions (Russell-Rose & Gooch, 2018).

Figure 11.

Interactive query suggestions.

4.3 Working with Existing Search Strategies

Formulating effective search strategies can involve hours of effort, and consequently many information professionals routinely save their work as documents within their local file system. There have been various initiatives to provide a central repository for such artifacts, such as MedTerm Assist (Saleh et al., 2014), and various forums for reviewing them, such as the PRESS forum (Lefebvre et al., 2019). However, these repositories are not universally supported and are often closed to non-members. Moreover, they typically manipulate content as unstructured text strings or using word-processing tools which can result in the undesirable transformations we discussed earlier.

By contrast, users can freely distribute searches in 2Dsearch as hyperlinks generated using the Share button (see fig. 10). In this way, 2Dsearch offers an open-access, online platform for saving, sharing, and executing search strategies as validated, reproducible artifacts (fig. 12).

Figure 12.

Users can save searches in a public or private repository for archival purposes or peer review.