• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer
TSB Alfresco Cobrand White tagline

Technology Services Group

  • Home
  • Products
    • Alfresco Enterprise Viewer
    • OpenContent Search
    • OpenContent Case
    • OpenContent Forms
    • OpenMigrate
    • OpenContent Web Services
    • OpenCapture
    • OpenOverlay
  • Solutions
    • Alfresco Content Accelerator for Claims Management
      • Claims Demo Series
    • Alfresco Content Accelerator for Policy & Procedure Management
      • Compliance Demo Series
    • OpenContent Accounts Payable
    • OpenContent Contract Management
    • OpenContent Batch Records
    • OpenContent Government
    • OpenContent Corporate Forms
    • OpenContent Construction Management
    • OpenContent Digital Archive
    • OpenContent Human Resources
    • OpenContent Patient Records
  • Platforms
    • Alfresco Consulting
      • Alfresco Case Study – Canadian Museum of Human Rights
      • Alfresco Case Study – New York Philharmonic
      • Alfresco Case Study – New York Property Insurance Underwriting Association
      • Alfresco Case Study – American Society for Clinical Pathology
      • Alfresco Case Study – American Association of Insurance Services
      • Alfresco Case Study – United Cerebral Palsy
    • HBase
    • DynamoDB
    • OpenText & Documentum Consulting
      • Upgrades – A Well Documented Approach
      • Life Science Solutions
        • Life Sciences Project Sampling
    • Veeva Consulting
    • Ephesoft
    • Workshare
  • Case Studies
    • White Papers
    • 11 Billion Document Migration
    • Learning Zone
    • Digital Asset Collection – Canadian Museum of Human Rights
    • Digital Archive and Retrieval – ASCP
    • Digital Archives – New York Philharmonic
    • Insurance Claim Processing – New York Property Insurance
    • Policy Forms Management with Machine Learning – AAIS
    • Liferay and Alfresco Portal – United Cerebral Palsy of Greater Chicago
  • About
    • Contact Us
  • Blog

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

You are here: Home / Documentum / D6 / Documentum Search – How to get around the user request of “I just want a search like Google”

February 22, 2011

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.

Filed Under: D6, D6.5, Documentum, ECM Landscape, Search, Webtop, xCP, xPlore

Reader Interactions

Comments

  1. Jim Tarpey says

    May 6, 2011 at 1:58 pm

    If users want the Google experience, you should check the Google Search Appliance. This is a one box solution, which can be integrated very easily with Documentum, Websites, and File Shares. This allows to google like experience, and a wider variety of repositories.

    Reply
    • TSG Dave says

      May 6, 2011 at 2:23 pm

      Jim,

      Thanks for your comment. I am not sure you understood my point. The point was that users don’t really want a Google Search, they really want a better Documentum search and incorrectly describe it as “a Google search”….example from the post was.

      * 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.

      We have had a couple of Documentum clients use the Google Search Appliance that have struggled. Price point was a major stumbling point (was it 100K entry a couple of years ago) although that might have changed. I think the Google Search Appliance would work well in an R&D and other environment where text of the document and frequency of other retrievals was important for search results and would lent itself to the Google Appliance – for many of the Documentum users we work with, the taxonomy (attributes, folders…) are often more important that the content. The post focused on getting users to pick from that taxomony quickly for a better search.

      Reply

Trackbacks

  1. Documentum Searching – D2, Webtop, HPI, and xCP « TSG Blog says:
    February 20, 2012 at 7:11 am

    […] there needs to be some education as to why, despite asking for it, users need more than just “A Search just like Google” as we highlighted in an earlier post.   A quick […]

    Reply
  2. Documentum Performance – Search, Retrieval and Inbox « TSG Blog says:
    May 9, 2012 at 12:26 pm

    […] ask for a “Google” free form search, we have pointed out in a previous article, that often ECM searches are not like a Google search and users are just concerned […]

    Reply
  3. Documentum, SharePoint, Alfresco – Document Control for Life Sciences | TSG Blog says:
    April 22, 2013 at 8:54 am

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

    Reply
  4. Documentum Search – Why the Google appliance just doesn’t cut it | TSG Blog says:
    November 26, 2013 at 1:02 pm

    […] of our most popular posts regarding Documentum Search has been “What to do when users just want a Google Search”.  As we pointed out in the post, it isn’t so much that clients want a Google search as […]

    Reply
  5. Documentum Search – Why the Google appliance just doesn’t cut it says:
    October 7, 2016 at 4:30 pm

    […] of our most popular posts regarding Documentum Search has been “What to do when users just want a Google Search”.  As we pointed out in the post, it isn’t so much that clients want a Google search as […]

    Reply
  6. Alfresco Share – Search Comparison with OpenContent Management Suite says:
    June 13, 2018 at 2:14 pm

    […] “Google” search interface.  While Google works great for a consumer searching the web, it isn’t very practical for most ECM use cases.  While the blog linked here was written with Documentum’s Webtop user interface as the […]

    Reply
  7. Documentum Searching – D2, Webtop, HPI, and xCP says:
    July 25, 2018 at 3:26 pm

    […] there needs to be some education as to why, despite asking for it, users need more than just “A Search just like Google” as we highlighted in an earlier post.   A quick […]

    Reply
  8. Alfresco Deployment – No Code vs Low Code says:
    April 18, 2019 at 9:55 am

    […] GitHub. To date, this application provides a different approach to searching where the search is a “Google” style search that scans the entire repository. After results are returned, filters can be used to narrow down […]

    Reply
  9. DynamoDB and AWS – How to build your own ECM capabilities for massive scale and performance says:
    May 30, 2019 at 6:28 am

    […] have a “Search the Repository” for X mentality.  See our thoughts from 2011 on “what to do if a user asks for a Google Search”.  Similar to the failures of Enterprise Search, most content services clients are looking […]

    Reply

Leave a Reply Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

Search

Related Posts

  • Documentum Webtop 5.3 running on Documentum Content Server 6.x
  • EMC World – 2011 – Day Three – ECM Strategy and Roadmap – 2011/2012 – Mark Arbour – Head of Product Management – ECM Applications
  • Documentum Search – Lucene, FAST, Verity, Google and upcoming DSS
  • Documentum Upgrade to 6.7 – a simple approach
  • Documentum 6.5 to 6.7 Upgrade Lessons Learned
  • Documentum Performance – Search, Retrieval and Inbox
  • Documentum and Momentum EMC World 2011 – Recap
  • Documentum/Momentum EMC World Prep
  • Documentum and Momentum EMC World 2010 Recap
  • Documentum Full Text Search with Lucene – Honoring ACL Security

Recent Posts

  • Alfresco Content Accelerator and Alfresco Enterprise Viewer – Improving User Collaboration Efficiency
  • Alfresco Content Accelerator – Document Notification Distribution Lists
  • Alfresco Webinar – Productivity Anywhere: How modern claim and policy document processing can help the new work-from-home normal succeed
  • Alfresco – Viewing Annotations on Versions
  • Alfresco Content Accelerator – Collaboration Enhancements
stacks-of-paper

11 BILLION DOCUMENT
BENCHMARK
OVERVIEW

Learn how TSG was able to leverage DynamoDB, S3, ElasticSearch & AWS to successfully migrate 11 Billion documents.

Download White Paper

Footer

Search

Contact

22 West Washington St
5th Floor
Chicago, IL 60602

inquiry@tsgrp.com

312.372.7777

Copyright © 2023 · Technology Services Group, Inc. · Log in

This website uses cookies to improve your experience. Please accept this site's cookies, but you can opt-out if you wish. Privacy Policy ACCEPT | Cookie settings
Privacy & Cookies Policy

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary
Always Enabled
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Non-necessary
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
SAVE & ACCEPT