Do More with Your Alfresco Deployment – HPI vs. a Custom Search Interface

In the previous post in this series, we compared searching in HPI vs. out of the box interfaces like Share.  However, we have seen multiple TSG clients attempt build a search interface from scratch.  In this post, we will discuss why it is better and faster to leverage HPI for Alfresco search rather than “rolling your own”.

Roll Your Own?

In software engineering lingo, the phrase “roll your own” refers to purposefully building something that already exists.  For example, let’s say a group software engineers need to build a JavaScript application.  The team looks at Backbone.js, Angular.js, Ember.js, etc. but still decides to start from scratch and “roll their own” framework as part of their application.  The main benefit is that the team can tailor the framework exactly to their needs.  However, the real danger is that the team will likely spend far longer than expected building pieces of their framework that the standard tools already address out of the box.

In the ECM industry, we’ve seen clients attempt to roll their own search interface, deciding that the out of the box search interface (ex: Alfresco Share) doesn’t work for their needs and instead of using another tool, building a new one.  While it may seem like a relatively simple task, many of our clients have found that taking this approach is much more complex than originally thought.  To see how a user may evaluate search in Share and search in HPI, check out this short video:

Leverage 10 years of Client Input into HPI Search

TSG recommends looking at deploying HPI before rolling your own interface.  HPI includes a highly configurable search and view component that has been successful at a variety of Alfresco clients.  TSG only builds features into HPI that are specifically requested by TSG clients who have decided not to roll their own interface.  All features have real-world applicability and meet actual client requirements.  While this can include more abstract requirements around the interface simplicity and usability, it also includes a lot of features that we’ve built into HPI.  For example, if you were going to roll your own search interface, how long would it take you to build out the basic search plumbing and UI as well as any of the following search features that your users may require?  Note – click any of the links below to see a demo of that functionality in HPI!

• Simple Attribute Search – Give users a simple interface to execute searches against a configurable list of attributes.
• Advanced Attribute Search – Give more advanced users additional control over whether fields are search on as a “contains” or “equals” search.  Also, allow users to AND / OR attributes.
• Full Text Search – Allow users to search within the text of documents.
• Saved Searches – Allow the user to save a search and execute it at a later time.  Additionally provide for public saved searches that anyone can execute.
• Date Searches – Date searches can be fairly complex.  HPI supports the following types of date searches:
  • Date Range – Before a certain date, after a certain date, or between two dates
  • Proximity date searching – search in proximity to today.  For example – look for documents that have an Effective Date:
    • in the past X days / weeks / months
    • in the next X days / weeks / months
    • within X days / weeks / months, searching in the past and future
• Search Results Views – Display search results in an easy to use interface where users can quickly tweak the search criteria and rerun the search.
  • Results Table View – Display the results of the search in a tabular format
    • Hidden / Visible columns – Return a configurable set of properties some visible and some hidden by deafult.  Users can individually choose which columns to show or hide and the system remembers his or her settings.
    • Drag and Reorder/Resize columns – Allow the user to reorder and resize the result table columns, remembering settings between sessions.
  • Results Grid/List View – Display the results as a grid or list, showing a small thumbnail preview of the file contents.  While document-centric systems may not need this, Digital Asset Management systems that deal with image and video formats typically require a thumbnail in the search results view.
• Search Result Filtering – once results come back, allow users to filter results.  HPI can do this through a simple text filter or search facets, which allow the user to filter results based on one or more metadata values.  As an example of facets, think of Amazon – if you were to search for “shoes”, you’d be able to filter on one or more brands via checkboxes to quickly narrow the results.
• Actions on Search Results – Allow users to take actions quickly on documents in the search results.  Typical examples include: exporting the search results to excel, viewing the properties of a document, updating properties in bulk, combining PDFs, and many others.

As mentioned above, although we may be biased, whether to replace or augment Alfresco Share, we would definitely recommend that you look into HPI as a search interface rather than “rolling your own”.  Let us know your thoughts below.