Documentum Search Application Performance Tuning – Part 1

Typically Documentum users will have heard Ed speak at Momentum or EMC World in the past in regards to system performance and Documentum.  For this post, we are going to take a different approach and talk about Documentum Search APPLICATION Tuning for system and USER performance.  All of the concepts relate to our Alfresco and SharePoint clients as well as the Documentum users.  The experience is based on a recent client but we will try to bring in best practices from other clients as well.  This is part 1, look for part 2 next week to focus more on specific technical application tuning best practices.

Application Performance Tuning – it is all about Search

While there are many other things we can tune in regards to other functions (creating documents, folder browsing…), the number one concern of users has always been search.  Users will notice if it is slow and the amount of resources consumed by some searches are expensive and can slow down other users.  Some important points:

• Separate Consumers versus Contributors – readers of this site will have heard this before but the ability to separate consumers who are just searching for unsecured documents from contributors who are adding content has the biggest effect on application performance.  We recommend a cached approach (Documentum users – see our detailed whitepaper) as the best way to isolate expensive consumer searches and improve search and creation performance for contributors.
• Reduce the number of searches – Typically users will say “I just want a Google Search” but not really understand it.  For example, if a user only adds a one-word product name in the full-text search field, the user might get back 5,000 documents depending on the product name and usage in other documents.  The user realizes that they should reduce the search to a certain document type, selects a document type search field and might get back 200 documents.  In two subsequent searches, the user next limits the query to include site and only effective documents and and the search results are finally down to a managable 10 documents.  In the scenario above, it might have taken 4 queries to get to the right query.  Interface design will be discussed next but getting the user to do 1 search instead of 4 obviously improves both the user performance (and reduced frustration) as well as the system performance.

Search Interface Design

Key to better system and user performance is search interface design.  Webtop users are pretty much stuck with what comes out of the box and training, but for either custom application or xCP developers, there are more choices.  Some points to consider:

• Make it hard for a just a “Google” search – we like to put the full-text search component on the bottom of the search criteria options forcing the users to leverage the attributes first before just typing in a word.  For the previous example, the interface would allow for document type, site and maybe default to effective document types pushing our user to select those first before typing in the product name.
• Leverage Drop-Downs and Pick Lists – Free form entry is fraught with errors for search.  In the example above, letting the user type in the site name can lead to misspellings, caps and other issues that cause bad searches and user frustration.  Good search design can help user quickly pick the site from a drop-down or pick-list rather than have to type it in themselves.
• Leverage Defaults – Adding defaults can help users with more efficient searches.  For our example above, if a user typically only looks for effective documents, the interface should default that choice to effective.  The user has the ability to change it but defaulting helps them with a more efficient search.
• Leverage “last use” – Good point comes from client Mike, leverage “what the user did last time” for populating fields – could be either last document type or other fields.  Typically users do more of the same searching rather than something completely new.
• Saved Search – Just like “last use” – saved searches – even shared between groups are ways to increase user performance and more efficient searches.
• Search Results – User performance is better if they are not jumping from window to window in regards to seeing search criteria along with search results.  Interface should be designed to allow users to quickly see results and add additional search criteria to trim their search results.  Search results should allow for a variety of column viewing and sorting options to allow users to manipulate the results in the way they need.
• Export Results – Giving the users the ability to export the results to Excel or Comma-Delimited files saves on reporting and is a common add-on.

All of the above principles are employed for our typical search add-on, the High Performance Interface and can be a custom application or add-on to Webtop.  Look for examples in the learning zone.  If you have others thoughts on best practices for search, please comment below and look for Part 2 next week…..