Documentum Search – How to get around the user request of “I just want a search like Google”

Often times Documentum users, frustrated with Webtop Search or Advanced Search will request “Can we just have a Google Search?”.   This post will provide input to Documentum developers on how to best address this ongoing request.  While this post is specifically focused on Documentum developers, lessons learned about interface design apply to our Alfresco and SharePoint readers as well. 

Wanting a Google Search versus hating Webtop Advanced Search

 A key point to understanding users is the need to truly understand what they are requesting.  Often times it is not so much that they want a Google Search but just an easier search.  It is worth reminding users that:

• Google Searches are different than typical document searches.  The “Show me all the SOPs for this product at this location” is not a Google Search.
• Google uses much more than just full-text to return relevant results.  Estimates are over 200+ factors including location, usage and clicks from similar queries, personal information as well as many other variables

Developers should probe deeper into the initial request for a “Google Search” with deep open-ended questions about the current search.   Typical feedback can include:

• Front-Page “Google  Like” search is slow and inaccurate.
• Advanced Search makes me select a lot of items including:
  • document type (from a large and difficult looking list)
  • attribute (from another large and difficult looking list)
  • operator
  • type in value (sometimes accurate)

In working with clients, TSG routinely offers search alternatives or customizations to address the above issues.

Webtop Search Interface

Typical front page Webtop screens look like the below:

Users looking for a “Google Search” would type in the product name and simply hit the search button.  A couple of points for users to consider:

• If you haven’t enabled full-text search (FAST or new xPlore/Lucene) this query executes a “contains” search on all attributes in the docbase.  This is a very time consuming and expensive query (full table scan for the DBA’s out there) and should be avoided at all costs.  (could affect performance of other Documentum users)
• With full-text enabled, the same search is performed against the FAST or xPlore index but includes both the text of the document as well as the attributes.

Clicking on the down arrow reveals a screen like below:

We typically advice clients that Advanced Search is a “do everything” interface that will be to much for the casual search and retrieval user.  Common customizations to this screen based on user feedback include:

• Trimming the list of available doc-types to search (users don’t need to select from every type of object in the docbase).
• Triming of attributes based on doc-types
• Addition of drop downs and other defaults to keep users from having to type in common values (product names) to avoid keystrokes and spelling errors

An Easier Search Interface

Many of our “lessons learned” in regards to search come from our HPI Search product but would apply to other search development including xCP.   Common themes include:

• Start at Search  – rather than having to see cabinets or click Advanced Search, many users just want the default Webtop or other interface to start on the Search selection to improve performance and remove an additional click.
• Document Types – first selection will require to pick a document type (or grouping – ex: SOP) before selecting any attributes.  Specific attributes available should be based on the selected document type.
• Drop Downs  rather than free form text – Many attributes are defined in the data dictionary or have a limited set of values – users should be able to easily select from this list rather than taking the time to key in text while risking a spelling error and having to do another search.
• Equals when possible  – tied to drop-downs,most selections should be equals for the operator for performance.  Contains for the title attribute is probably a best practice.
• Eliminate “Ors” – When pushed, users rarely need “Show me all the SOPs for this product or this product” search.  Best practices would just use two different searches to simplify interface and training.
• Search Results should allow for:
  • Allow for sorting by columns (typically the header)
  • Allow for display or removal of certain columns
  • Allow for export to Excel/CSV

Conclusion

There are many options for addressing user interface search concerns.    TSG best practices can be seen with HPI Search in the learning zone but interface discussion with WDK and Webtop or xCP can also leverage these best practices.    Other helpful links from this blog on Consumer Search include:

• Documentum Search Application Performance Tuning
• Documentum Search Services (now xPlore) the Real Deal
• Documentum Search – Lucene versus FAST
• HPI and Webtop Comparison – Detailed Whitepaper

If you have any other relevant best practices – please share below with a comment.