How do we design interfaces to better support complexity in the search process? The intent of this paper is to illustrate that the search is not the complex piece, it is the search within its context that makes the process complex.
How do we design interfaces to better support complexity in the
search process? First I argue that the act of searching is not the
problem, nor what really represents the complexity of this
process. The complexity emerges from the work task and its
context
Secondly, I propose a set of tools that are complementary to, and
tightly integrated with the search box to facilitate users’ work task
completion. The tools are essentially apps or dynamic interface
features that theoretically should reduce the complexity of the
process, providing “all the tools that are commonly used for a
specific task or workflow”
While we can consider search now to be ‘easy,’ there are
limitations. The former sophistication is no longer possible
leaving the user struggling to make sense of the process. What
was once a single interaction now takes multiple steps to achieve
a similar result. At the same time, the sophistication in search
algorithms means that a query now retrieves mostly relevant
results. In a study of over 400 searchers, Toms et al (2014) found
that the system delivered relevant results, but the users continued
searching as they appeared not to know when to stop, leaving the
authors to conclude that the interface failed the users by not
guiding them through the process beyond search to use. Over 30
years ago, Jarvelin and Repo (1982) concluded that user “seems to
happen just by itself,” which remains equally true today.
Arguably, complex search tasks do not exist (which suggests that
I am contravening the very objective of this workshop). The
complexity of search resides with the work tasks
In general, a work task has a defined objective or goal that can readily be mapped to an at-the-moment unknown outcome or result. There may be known conditional/unconditional requirements. To complete the task requires a series of activities each of which uses actions performed with a set of tools. These tools, one of which is a search tool, consume information/data from diverse sources (see model of the process augmented and expanded from Bystrom & Jarvelin (1995) in Toms (, 2011)). This is a generic description of how search fits within the larger work task. But this is not a single process; there may be multiples of these and within each, search may (or may not) be required. Think about the process used to piece together a response to a request, write a report, make a decision, or plan for a future event. There may be multiple sub processes in addition to search that requires extraction, analysis, comparison, prediction, modification, and/or manipulation, for which the found information is a critical ingredient. Thus a work task is usually complex; the searching is for discrete pieces of information, analogically like the ingredients brought together for a recipe, and like a recipe, search is just one of the many elements required to get the job done. 3. INTERFACE TO SUPPORT SEARCH Interfaces to applications intended to support those complex work tasks are very limited. In fact, arguably they are non-existent. Most of the typical complex work tasks in knowledge work environments are completed using the lowly word processor that is partnered with perhaps a browser, with one of more windows/tabs used to access the essential information, and possibly additional applications such as spreadsheets, and concept mapping tools which are also used to manipulate or analyse some of that found information. At present, search remains mostly unintegrated with work task and tends to be treated as an independent activity.
Instead we look to the emerging work on re-thinking the generic
search interface with a view to the proposition that it may be
directly integrated with a workplace digital solution in the future.
Initially started as command-line interface, the implementation of
search evolved into a form-fill-in style of interaction enhanced
with direct manipulation elements – a search box and command
button, or else a faceted style interface implemented as a series of
menus with filtering options. This approach to thinking of the
search interface as query formulation/reformulation (or concept
selection), search results display and/or some visualization of
these
Perhaps the first systematic approach to search interface design is Wilson’s four key features: 1. Input: components for a user to indicate the search intent; 2. Control: components that enable query expansion, modifying and augmenting the input; 3. Informational: components that output the results, or information about the results; 4. Personalisable: components that relate to characteristics of the user and/or their past interactions.
In addition, White (2011) identified a set of techniques that specified how some of those components can be rendered. For example, Search box, QBE, form fillin, faceted metadata, and categories are types of Input; while Corrections, sorting, IQE + assistance, filters, grouping; relevance feedback are types of Control; Text snippets, images, thumbnails, shortcuts, techniques for visualizing relevance or content are types of Informational components. Notable about these components is that they map to primarily physical user interface actions, on par with the typical physical actions in office applications, e.g., cut and paste, insert, format, track changes and so on.
Missing from most approaches to date is assistance for the truly
complex piece: work-in-head. Searching and digesting
information is a complex cognitive or mental process, and one
could speculate about whether searchers need “cognitive
prostheses,” aids that assist the user with that level of intensive
cognitive activity
The search box itself is a coarse approach to the entire information search problem, although it lends itself to a procedural method. Other than some very simple options, e.g., auto correct, spell check, auto suggest, etc., very little assistance is provided at this point. At each step in that search procedure a user performs a series of actions but at present very little support is provided by the system. Spell check, query word suggestion, some use of relevance feedback, and some filtering are perhaps the extent. Even this set is somewhat incomplete.
Missing from these features are those intended to assist the user with the intensive cognitive processin in the pre- during and postsearch phases of each sub process of each work task. One can envisage a series of tools or software applications along the lines of those suggested in Table 1. Not unlike the toolbox used to create images, or those used to analyze a bunch of numbers for patterns and relationships, this list identifies a distinct set of specialty tools to support primarily user cognitive limitations at that point in the process. The list includes an extension of potential and existing features (or tools or apps or modes) some of which have been previously identified by Hearst (2009), RussellRose and Tate (2011), Wilson (2011) and White (2011). Such a set would remove some of the existing complexity from how the current search process is implemented.
The set is divided into four grouping with some repetition from
group to group, and with variation in specificity as the type of
action or procedure desired varies with the point in the process.
Prior to searching, a user sets a goal to be achieve; is the
information needed as evidence, to find out how to do something,
i.e., a procedure, or simply to gain an overview of the topic. These
tools clearly would need to relate to relevance and use, targetting
any search output to deliver on the goal, and only on that goal.
The tools to aid query development have perhaps been the most
robust and established to date. At present the user is left to his or
her own devices over the course of a search, relying on
recognition more so that (cognitive) recall, and with an emphasis
on memory and mental storage. Much could be done at this phase
to assist. For example, we spend significant efforts in identifying
similarity with academia, but we fail to supply the same technique
to the user in identifying similarity amongst a set of research
papers. We do little to assist the user in temporary storage such as
the bookbag used in wikiSearch
Figure 1, however, is not intended to be a complete set, and may not be the best set.. It is instead hypothesized as an approach to aiding the user, and thereby reducing the complexity present in work tasks. While these tools are very much about simplifying the search process, they also engage with the work task more directly so that the tool is helping the user to work toward that work task goal. This suggests that we need a systematic approach that builds on the work of Wilson (2011) to augment those operational components with those that support the ‘real’ information work, the work that takes place in head.
Given the conceptual nature of these tools, they will be non-trival to develop, as each will require its own search and analysis algorithms that are tailored to the purpose of the tool. Comparatively and anologically speaking, do we need an Allan wrench or a flathead screwdriver, a simple chopping knife or a mandolin slicer? The challenge we face is how to move beyond the searchbox, and beyond the naysayers who claim that the searchbox is the optimum solution. Part of this challenge is also the user community who have been trained to input a few words and receive some results (regardless of the level of usefulness), and have been reluctant to use additional interface features. Thus a dramatic change may be required to influence human behaviour, a change that may be a disruptive technology.
Monitor Figure 1. A proposed searcher’s toolbox
Word selection