One of the most important components to focus on in a content services application is Search. Storing content properly typically takes more effort than saving a file to a shared directory. This extra effort pays dividends only if Search is fast, easy to use, and accurate. Over many years and many customer implementations, we at Docuvela have seen well-implemented search interfaces as well as poorly implemented search interfaces. These have run across the spectrum of fully-custom coded interfaces as well as out of the box interfaces provided by content services vendors.

In this post, we will discuss six of the most common best practices we recommend for search interfaces, as well as the mistakes to avoid to create the most efficient and user-friendly search interfaces possible.

Best Practice 1: Avoid the “Google” Search Approach

When searching for documents, records, or videos, users typically know what they are looking for based on certain aspects of the data such as the object type, name, or other metadata. However, the basic search available in a content services application is often simply a search bar in the header that will search the entire repository. This approach can be unwieldy and cause the user to lose cycles when trying to sift through a large number of results, many which may be irrelevant or inaccurate. Additionally, content repositories can grow quite large, turning up hundreds of millions, or even billions, of documents, images, and video. If the search UI defaults to searching the entire repository, considerable effort and resources must be in place to ensure that the search will even function in a usable manner. In practice, we have seen all customers at scale turn off this global “Google-like” search in their repositories.

We recommend that the user interface target certain areas of the repository prior to the search even being executed, usually by implementing a combination of:

1. Search by Type or Aspect – Typically the user knows what type of content he/she is looking for. For example, a claims adjuster would be searching for Claim folders or Claim documents. A quality document author would search for Standard Operating Procedures (SOPs) or Change Requests.
2. Search by Metadata – Once a type is selected, the user should be able to search based on respective metadata. For example, when searching for Claim folders the claims adjuster should be able to narrow the results down by limiting the loss date attribute to a certain date range. When searching for SOPs, the quality document author should be able to search by Department, Approved Date, Effective Date, Periodic Review Date, etc.

This approach narrows the possible search results considerably, resulting in much more efficient searching – especially in large repositories.

In this post, we will be using the Alfresco Content Accelerator (ACA) to demonstrate these best practices. ACA is the backing application for Hyland’s Claims Management and Policy and Procedure Management accelerators, and demonstrates these best practices nicely. ACA’s search screen is set up to allow administrators to configure searches by type and metadata, rather than searching across the entire repository:

Using this approach, it’s easy for the user to see that they are searching for Quality Documents in the above search form. Application configuration and user role would allow the user to choose different types and metadata to search against.

Best Practice 2: Streamline and Simplify the Search Form

Unfortunately, when it comes to the search criteria form displayed to the user, the UI is overly complex and confusing to most users. The intent and supposed value of this UI decision is that it can do any complex query such as AND/ORs and grouping, like, and exact match, among other operations.

We recommend an approach that will streamline and simplify the search form. This approach makes the UI much easier to use and understand in addition to satisfying the majority of real-world user requirements. Here’s an example search form from ACA:

Some examples of best practices utilized are:

1. Streamlined Criteria – The application should display relevant metadata for criteria automatically based on the user’s context. When searching for Claims Documents, the metadata available for search should display in this context vs. when a user searches for a Procedure Document.
2. All criteria ANDed – Avoid the confusion and complexity of AND/OR grouping and simply make all criteria AND. We have found that this approach satisfies most real-world queries. Power users that need to create more complex queries typically have access to more powerful tools and back end services.
3. Dropdowns – where possible, a list of possible options should be displayed in a dropdown select box to give the user a list of options to choose from. We also recommend that the dropdown control allows for type-ahead functionality.
   • This type-ahead functionality can power advanced features as well. For example, the control can real-time query for large dropdown sets (ex: vendor or parts list) as well as cascade information to other fields (ex: Category, Subcategory).
4. Text boxes – when searching based on freeform text, the search should execute a case-insensitive ‘contains’ search. This approach allows for all documents containing the given text in the field to be returned, limiting documents missed in the search results. Note that in very large repositories, the application configuration should change to force a case-sensitive “starts with” search for performance.

Best Practice 3: Display Search Results Alongside Criteria

This best practice should be a simple one but it is often overlooked. When designing the search results UI, we often see that the search results take over the entire screen. While taking over the entire screen may provide more real estate to display the search results, it misses a critical component in that the user will lose their search context when viewing the results. Instead, we recommend displaying the search results along with the criteria entered.

ACA’s interface allows the user to view the results within the context of their search criteria, as well as further narrow down the results based on facet-style or text-based filters.

Best Practice 4: Allow Users to Personalize Search Results View

After search results are displayed, the results screen should not utilize a one-size-fits-all approach. Instead, users should be able to personalize the search results screen to allow for efficiency in targeting the results the user is looking for. Here are some examples of the personalization options we recommend:

1. Metadata:
   • When displaying metadata in a search results table, the application should smartly display columns with relevant metadata based on the document types searched. This way, when viewing Claim folder results, the table will display columns for Claims metadata and when viewing SOPs, the table will display columns for SOP metadata. While seemingly simple, we’ve seen many applications where the same generic metadata columns (name, title, modified date) are displayed no matter what.
   • Users should be able to further personalize the results table. This personalized view can be accomplished by allowing the user to control which fields are visible/hidden, column order, and column size.
2. Results view – many document-driven applications only need a results table. However, this view may not be sufficient for digital asset applications that store images and video. For these use cases, an additional thumbnail view should be available – and users should be able to personalize which view is the default.

In the example below, the user has taken a number of steps to personalize the results table: the document title and version label fields are flipped, the version label has a narrow column, and the user has chosen to show the Approved Date:

Best Practice 5: Lightweight Reporting: Combine Proximity Date Searching and Saved Search with Export to Excel

Most modern search results screens give the user advanced search features:

1. Saved Search – allow the user to set up a query by filling in metadata and then save it. The saved search can be rerun in the future to avoid re-keying the metadata fields. This feature is very useful for users who often need to run the same search periodically.
2. Export to Excel – once the user has executed their search, allow them to export the search results metadata to an Excel spreadsheet.

Of course, if either of these features are missing, we would recommend adding them. However, even with these features, what many interfaces miss out on is combining them with advanced search criteria fields to enable lightweight reporting. Consider a search control like the following from the Alfresco Content Accelerator:

This is what we would call a “proximity date” search control. In other words, it’s not searching on a static date range; the date range is calculated in proximity to today – as in, the date the user is executing the search. This method opens up many lightweight reporting options that can be obtained for free without building a complex reporting interface. Some examples:

1. List the claims opened in the last 30 days.
2. List the SOP documents that have been approved in the last 30 days.
3. List the SOP documents that have their periodic review date coming in the next 90 days.

Best Practice 6: Surface Search Results Automatically

Finally, it’s important to realize that search functionality shouldn’t simply be limited to the search screen. Instead, modern content services applications should be automatically surfacing content to the user based on context. Many times, finding relevant data can be accomplished via an automated search. Some examples:

1. Create a configurable search dashlet that will show content dynamically. Many of the examples above around lightweight reporting are obvious candidates for a saved search dashlet. Others can be imagined as well – ‘Documents checked out to me’, ‘documents modified by my team in the last 30 days’, etc. Dashlets configured should be scoped to certain users based on role or group membership to keep the dashboard interface from becoming cluttered.
2. When viewing a folder or document, it may be possible to surface related information quickly and easily via an automatic search. Some examples:
   • When viewing a Claim folder, provide a link to the associated Policy folder by matching on the policyID attribute on the claim.
   • When viewing a Claim folder, provide a list of prior Claims opened by the same Policy Holder.
   • When viewing a Procedure document, display related policies, procedures, or forms. What is “related” could be based on any number of factors depending on the repository metadata configuration or full-text search.

Summary

Search is a very important component of a content services application. When users can efficiently search and find the documents and content they need, they will have more time to focus on doing their work rather than finding their work. At Docuvela, we recommend these six best practices to accomplish this goal.

Comment your thoughts below or on LinkedIn. Do you have any search best practices to share? Let us know!