Performance and ease of use in a search interface is often one of the highest concerns our clients have when building an ECM system.  Back in 2012, we did a Search comparison between Webtop and OpenContent Search (then called HPI).  As part of our 2018 Making Documentum Better blog series, we thought we’d update the comparison to reflect the latest Webtop and OpenContent Search interfaces.  In both cases, we’ll only consider features and functionality that can be configured in the respective system and not anything that relies on customized code.

For consumers, quick and accurate search access to documents is the most critical component for user satisfaction, often times making up for some of the laborious items users don’t necessarily like to do (check-in/check-out, add attributes, security, etc.).  Alternatively, users who are unable to perform the simple function of quickly finding a document or reviewing a group of documents can be very vocal in their complaints.

Webtop Search

Since our 2012 comparison, not much has changed in Webtop.  Some features have been added and improved upon, but the overall experience and user flow through search is the same.  Webtop has two main methods for searching, quick search and advanced search.

Quick Search

Webtop’s Quick search interface has not changed since 2012.  There’s a single textbox in the top left of the Webtop interface that allows a user to type the search term and hit [Enter] or click the magnifying glass to start the search.  We typically point out a few concerns to clients around the Webtop Quick search feature:

• Quick Search is too broad – since there’s no way to narrow down the search based on document type, all searches will go against all documents in the repository.  For clients with large repositories, this can be a performance concern.
  • If xPlore is not enabled in the repository, this search executes a CONTAINS search across all document types and metadata in the repository.  This is a very time consuming operation and should be avoided at all costs.
  • If xPlore is enabled in the repository, the search will be faster as it will rely on the xPlore index, however it will also execute a full text search of all document contents as well as attributes, which could be time consuming in large repositories.
• Quick Search is too nebulous – For a typical search user, it’s hard to tell what is actually being searched other than ‘Documentum’.  As we’ve mentioned before on this blog, users may say “I just want a search like Google”, but that’s often not what they really want in real world scenarios.

Advanced Search

Navigating to the advanced search is done with a submenu option as part of the quick search interface:

This option takes the user to the advanced search page, which takes over the entire screen:

Webtop’s Advanced Search screen has not changed much since 2012 as well.  It’s still very much geared toward the “build a search” scenario that we’ve discussed here many times.  Overall, the advanced search interface is seen as too complex for most users.  Common configurations and customizations that we see our clients implement include:

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

Search Results

In either the quick or advanced search case, search results are displayed in the same way.   The main Webtop content pane displays search results:

Concerns we have with the Webtop search results view include:

• When viewing results after running from Advanced Search, it’s not possible for the user to see the results and the search criteria together.  To get back to the Advanced Search screen, the user must click the ‘Edit’ icon in the top right, which takes the user back to the Advanced Search screen that takes over the entire window.  This limitation makes it very hard for the user to tweak search criteria since the user’s context of the previous search results is lost.
• Limited ability for the user to choose result columns – While Webtop does allow the user to configure personalized list of columns and their order in the search results view, the interface to do so is clunky and not intuitive.  Additionally, column visibility and order is limited to just Document and Folder by default, meaning that the user cannot have different columns or custom attributes visible for subtypes of the base Document and Folder types.
• While users do have the ability to view custom document type attributes in the search results, these attributes cannot be columns in the search results table.  This means users cannot sort on custom attributes.
• No quick filtering – Webtop does not provide a way for the user to quickly filter the search results based via filtering.  Webtop 6.8 introduces the concept of “Smart Navigation”, which is similar to OCMS search facets.  However, Smart Navigation is limited to three sections – topic, owner, and modified date.  It’s not possible to use Smart Navigation on other attributes.

OpenContent Search

We have designed the OpenContent Search based on the search requirements and best practices we’ve seen in client implementations over the last 20+ years.  Rather than the “build a search” paradigm that Webtop utilizes, OpenContent Search follows a much more configured and tailored search experience.

Search Criteria

Some of the OpenContent Search concepts to highlight include:

• Configure document and folder types that the user can search.  Users do not choose from a giant list of types present in the repository.  Instead, the administrator configures ‘tracks’ and sets up search on certain types based on each track.  So, for example, a user in Accounting may search on Vendor folders and Invoice documents.  A user in the Quality Documentation department may search on SOP and Work Instruction documents and not have access to search any folders.  In either case, the interface flexes around the administrator’s configured types rather than the user needing to choose from a giant list.
• Configure the attributes that the user can search for each type.  Similar to the types discussed above, the administrator chooses which attributes are available as well.  This again prevents the user from selecting from a giant list and streamlines the overall process based on the user’s business function.
• Utilize “and” logic when searching on multiple attributes.  From working with clients on search interfaces for over 20 years, we’ve found that the vast majority of users only need “and” searching.  Instead of building a complex interface that allows for “and” as well as “or” searching, users are typically ok with simply executing multiple searches to “or” two attributes together.  For the amount of searches that actually require “or” functionality, the trade-off of a drastically simplified interface is well worth it.
• Do not make the user choose the search operator, use sensible defaults.  In Webtop, all searches default to “contains”, but the user can choose from 14 total options (equal, less than, greater than, is null, is not null, etc.).  Instead, in OpenContent Search, the interface simply defaults to what the user would expect.  An attribute that utilizes a picklist dropdown for values will default to an “equals” search.  An attribute that allows the user to type in free text will default to a “contains” or “starts with” search based on configuration.

Search Results

Search results concepts to highlight include:

• Search Results are displayed along side search criteria – contrasting with Webtop, OpenContent Search displays search results with the original criteria used to execute the search viewable on the same screen.
• Result View defaulted based on admin settings – the administrator set sup a sensible default for the columns that are returned in the search, what order the columns appear in, and which columns are visible vs. hidden.  This is set up per document and folder type, rather than the Webtop which is limited only to the base Document and Folder types.
• Intuitive controls for customizing results – the user can simply drag and drop columns to change attribute order and can use checkboxes to choose which attributes should appear in the table.  These settings are preserved per document/folder type for the individual user when running future searches.
• Quick Filtering – OpenContent Search provides for immediate filtering of search results without the system needing to re-execute the search against the server.  Users can simply start typing in the quick filter textbox to filter on any value in the results table.  Another option is to utilize admin-configured search facets, which can operate on attributes that are not necessarily visible in the results table.

Document Viewing

A future blog post will explore viewing folders in each system, but we should touch on viewing documents from search results here.  Some observations between Webtop and OpenContent Search:

• PDF Rendition – Webtop streams the native document type (ex: MS Word) rather than the PDF rendition if one exists.  We have found that, for most searches, users really want to quickly preview the contents in the browser (and maybe print), and do not want to wait to launch the native authoring application.  OpenContent Search defaults to displaying the PDF directly in the browser if a PDF rendition exists.
• Separate Screen – both Webtop and OpenContent Search provide the ability to view content from the search results screen without taking the user away from their search results.  Prior to version 6.8.2, Webtop requires a Java Applet.  Webtop 6.8.2 relies on a browser extension and a native client based on Java.  In either case, the document automatically downloads in its native format and the native client launches the document editor (ex: Word, Acrobat) to display the content.  OpenContent Search launches the content in a new browser window, displaying PDF files (when available) in either OpenAnnotate or PDF.js.  OpenAnnotate can display PDFs, images, as well as video content as well.

Summary

Given that Webtop has not been a target for investment over the years by EMC, then Dell, and then OpenText, it’s not surprising that not much has changed in the overall interface over the past 10 years.  On the other hand, the OpenContent Management Suite is being continually updated by TSG’s community of clients.  We feel for multiple reasons that our OpenContent Search interface is better to Webtop in many ways described including features, functionality and overall ease of use.  Specifically:

• OpenContent Search is much easier to use an more intuitive for most search users
• OpenContent Search is configurable and can be tailored to exactly what users would expect
• OpenContent Search provides a better interface for users to sort and filter search results, as well as tailor the search criteria to re-execute a new search

Removing search user access from Webtop  is typically one of the first recommendations we make to our clients to make Documentum better within the organization.  Additionally, as discussed in the Documentum  – Improving the Webtop Experience post, it is possible to run OpenContent Search along side your Webtop implementation.  This option allows your users to continue using existing Webtop customizations that you may have in place while also providing for a more advanced, configurable search interface.  Let us know your thoughts below.