Alfresco – ADF and OpenContent Search Comparison

As we’ve mentioned previously when comparing search in Alfresco Share to the OpenContent Management Suite (OCMS), performance and ease of use in a search interface is often one of the highest concerns clients have when deploying Alfresco.  As we’ve recently started comparing the new Alfresco Development Framework (ADF) with OCMS, naturally our first inclination it to look at the search components that ADF provides.  This post will overview the ADF search components and compare them with what OCMS provides.

ADF Demo Application

While Alfresco does provide an ADF component catalog, it is structured as developer documentation.  For this and future ADF posts, we will be using the “demo shell” application that is packaged with the ADF components on GitHub.  As a development framework, comparing ADF to OCMS is not completely an apples-to-apples comparison.  However, by using the demo shell application, we can at least compare the current components that ADF provides.

ADF Search Components

ADF provides a number of search related components.  Some highlights from the demo shell application:

“Google” style header search

Like Alfresco Share, the ADF demo application places a Google-style search box in the header.  As previously mentioned in our Share search comparison post, this type of search isn’t very practical for most ECM use cases.

Search Filter Components

ADF provides a number of search filter components.  The demo shell application presents these filters after the search is executed in the header, but as a development framework, a developer could structure the application to display these filters as part of the search query.  Some examples of search filter components:

Text Filter:

Date Range Filter:

Checkbox Filter:

Radio Filter:

From looking through the available filters, we do not see a filter that would display a select box or autocomplete to select from a list of values.  Radio button or checkbox will work for a small amount of select-able items, but will not as the list grows above a handful.  The component catalog does provide a DropdownWidgetComponent, but it appears this is for use in any form and is not specific to the related search filter components.

Search Results Components

The only dedicated component related to search results is the EmptySearchResultsComponent.  This means that it’s up to the developer to use the DataTable component to lay out the search results view.

Some items to keep in mind when reviewing the demo shell search results:

• Curiously, the DataTable component has the ability to sort by clicking column headers, but the developer(s) of the demo shell application chose to hide column headers entirely and implement the same style of sorting that’s present in Alfresco Share.  It’s tough to tell without more research, but this could be due to the pagination and “infinite scroll” options in the implementation.  It’s not apparent why the column headers were omitted.
• Similar to share, document actions are in a sub-menu on the right side of each row.  The vertical dots icon gives actions better visibility vs. share’s mouse-over, so that is definitely an improvement.
• The demo shell application only displays and searches on the base type and attributes from cm:content and cm:folder.  While this is expected for a demo application, most clients expect to see their particular custom types and attributes.  For clients that have more than one type and associated attributes, this equates to additional development time to handle these cases.

See the screencam below for more.

OpenContent Management Suite Search Components

OpenContent Search defaults to displaying search results in an admin-configurable table along side the search criteria:

Check out the Share and OpenContent Search comparison post for more information, but in looking at the available ADF components there are a number of features that are often requested by clients that would need to be developed.  These features are present in OpenContent Search as part of OCMS:

• Configurable Types and Attributes – The administrator configures which metadata columns are available for a given search type and defines which columns are visible vs. hidden.  However the user can tweak these settings and OCMS will save the user’s preferences.  This is a very common requirement.  See the video embedded in this post to see how OCMS allows the user to configure search result columns.
• Proximity Date Search – Currently, the date filter presents the user with two date boxes to create a date range to filter on.  However, many clients prefer the OpenContent Search proximity date control that allows the user to search on dates in proximity to today.  In other words, the user could execute a search such as: “find documents with an expiration date in the next 3 months.”  See the screencam below for an example of proximity dates in action.
• Export to Excel  – Exporting the search results to Excel is another common requirement.  This is easily done in OpenContent Search by choosing the results to export (or simply selecting all) and executing the Export to Excel action
• Results Filtering – The demo shell application does show result filtering, but each filter causes a re-execution of the search on the server side.  OpenContent Search allows for facet-based filtering as well as quick filtering that will narrow down results based on anything displayed in the search results.  Results are filtered immediately without re-executing the search on the server side.

Summary

As ADF continues to evolve, we would expect that additional components will be added and existing components will be enhanced.  But still, at the end of the day, ADF is a development framework not an out of the box application.  OpenContent Management Suite is, on the other hand, a configurable application that TSG has been improving over the years at many of our clients.  The best practices we’ve implemented have all come from client implementations.  For clients that choose to develop an application from scratch using ADF, we would encourage the implementation of our search best practices in these implementations.