4.5 Design Seed 1: Exploratory Searching

One of the main vulnerabilities during the simulated analysis task was missing
critical information without being aware of it by prematurely closing the search
process. All of the study participants quickly narrowed in on a set of documents
on which they based their analyses. Although several mentioned that they were
concerned that they did not know how their sample related to what was
potentially available, none of them conducted further searches or explicitly
characterized the database through exploratory searches. Therefore, we have
developed a design seed that instantiates support for exploratory searching in
order to allow analysts to have a better sense of how their samples relate to what
is potentially available to them in a database.

Although there are potentially many ways to implement this design seed in an
actual system, several techniques that promote good usability are likely to be
used in some way. First, the system must somehow allow users to gain a sense
of how the documents they have sampled relate to the space of available
information by allowing visual comparison of sampled sets against each other
and the entire document space. In an interface with good usability, users will get
near-immediate feedback on how changing search parameters and document
attributes affects their sampled set. Visualizations based on mechanisms such as
procedural search constructions where changes are not made sequentially but
can be immediately implemented at any point in the search construction would
support this need in a natural fashion.

In summary, this design seed has the characteristics of:

• helping analysts to characterize the information space by allowing real-time
"what-if" manipulations on search parameters,
• supporting parallel comparisons of sampled documents against each other
and the entire document set, and
• easily manipulable search terms and parameters with immediate feedback on
the sampled set.

One example of how this design seed is expected to impact performance includes
making it easier for analysts to quickly troubleshoot why no results were
returned from a search that added "Aerian" as a search term. The user would see
that the addition of Aerian as a search term reduces the returned set to zero,
realize that the word is misspelled, and replace it with "Ariane". This scenario is
compared with search term constructions that must be completely created and
then "submitted" to a database with results returned some time later in the
format of "688 hits" or "0 hits." Although in both situations it is likely that there
was an erroneous spelling or term in the search construction, in the second case
the entire search term is treated as an integrated unit and no clues are provided
as to where to change aspects of the query.

Another example of how this design seed might impact performance is by
helping an analyst to see how adding the term "1996" to a search construction
affects the document set that is sampled. It is possible that adding the search
term "1996" would eliminate all documents prior to 1996 and greatly reduce
documents after 1996. By experimenting with the interface, the analyst can
visually see that there are fewer documents overall compared with the search
without the added keyword "1996", and that there are in fact changes to the
weightings of the documents in time (Figure 19). Some documents prior to 1996
are still available with the keyword, the documents from 1996 are somewhat
increased (from 52% to 64%), and there are fewer documents after 1996 (40% to
22%).




TABLE OF CONTENTS