One consistent theme in modern discussions of search is that it is more often than not part of a larger process.

Let’s start with a very general task, that of interacting with a set of search results, and consider a couple of different search modes: exploratory searches, and searches where you want to take some follow-on action.

First, exploratory searches.  As part of doing exploratory searches, users will be presented with a set of search results, which they may want to utilize in progressively richer ways:

• does the result look useful to my exploration
• does it contain anything useful to my exploration
• how does it fit into what I already know.

This is definitely not a waterfall process; all aspects can be happening in parallel.

The large search engines and popular browsers provide almost no support for these beyond bookmarking.  Instead, we find ourselves cutting and pasting links into a word processing document, adding comments, opening the link and capturing snippets of information, all the time reorganizing our document as our exploration proceeds.

Imagine, however, a situation where you could interact with search results the way you interact with rows in a spreadsheet or emails in your in-box.  Some of the following features could be useful

• deleting or hiding search results
• colouring or highlighting them, in all or in part
• categorizing them
• adding comments
• saving your processed search results.

And if we could also expose content snippets without having to open the search result, and further select or bookmark at the snippet level, we have the beginnings of a useful tool to help us with exploratory searches.

There are technology components and tools to help do this, but this type of thinking is not mainstream.  If the exploration is highly patterned, for example in the case of market research or product reviews, it may well be worth building exploration-support systems with some of these capabilities.

Let’s turn now to the notion of taking action from search results. The research question we are asking is, “given a search result, what actions might the user want to take”.

In the post on information scent, we devised a pattern for structuring search results so they have a consistent format, and illustrated it with three examples, a blog post, a job posting, and an employee benefits overview.

What might somebody landing on these search results want to do?  Here are some possibilities:

• for a blog post
  • read the post,
  • reply to the post
• for a job posting
  • read the post
  • find out about the company
  • learn how to apply  Most people say, duh, “apply for the job”; this is not usually a process that would be completed within the set of search results, unlike a quick read of a blog post
• for the employee benefits overview
  • get more information
  • find out who to ask for help.

As part of the business justification of this appraoch, we should consider whether there are underlying repeatable types of action that we can exploit, and/or repeatable information or usage patterns that will lower our cost to delivery.  There are at least two: go somewhere useful, or do something useful.

We are seeing a number or technologies that support this type of thinking.  They differ somewhat based  on the level of structure of the domain.

The corporate clients I consult for are often concerned with overall improvements in findability, in a mix of fairly structured domains.  In these settings, I can cite the SharePoint 2013’s hover panel, a customizable area which appears when you hover over a search result.  This can be programmed to allow the reader to take the type of actions mentioned in the above examples.

In the world wide web at large, there are technologies that allow a webmaster to add interaction to their search results when served up by the large search engines.  A search of “interactive snippets” and “microformats” will open the door to this space, but I have not personally walked far through this door.

On the other hand, I have spent many years developing custom corporate applications for specific domains, tasks and processes. In these cases, we can integrate search into a knowledge worker’s environment so tightly that they do not even know from their surface interactions that they are using search, just that the custom application is pulling in the information that they need, when they need it, and how they need it.  Under the hood, though, the solution will utilize our deep knowledge of the users and their information needs, and deliver using metadata driven search.

For examples of this type of application, see the webinar from Earley & Associates entitled “Driving Knowledge-Worker Performance with Precision Search Results“.   This covered many of the things we have been doing; here is my summary.

Stay tuned.

The Information Artichoke Home Page | Search Table of Contents