Alfresco Share – Comparison with OpenContent Management Suite Series

Alfresco’s out of the box user interface, Share, is typically the collaboration interface most Alfresco clients leverage for their initial development efforts.  Alfresco Share has garnered some concerned attention from Alfresco customers this year when Alfresco announced that Alfresco would be deprecating Share in future.  To help readers understand the difference between Share and the OpenContent Management Suite, TSG will be posting a blog series on major feature differences over the upcoming weeks.

Alfresco Share and OpenContent Management Suite – Where did they come from?

Alfresco, like any other ECM vendors, leverages Share as the “do all” interface to be able to address a variety of different scenarios and show off the features of the product.  Typically these products are developed from a combination of vision of the product team as well as benchmarking against similar tools from competitors.  Alfresco Share, just by the name but also by some of the functions, was initially aimed at the collaboration space which, at the time, was dominated by SharePoint.  Like many ECM vendors, the default “do all” interface provided by Share can check a lot of boxes during an RFP for ECM capabilities, but, due to a generic nature, isn’t shipped or typically streamlined for a certain business scenario.  Back before TSG had the OpenContent Management Suite (OCMS), much of our work for generic interfaces was spent removing and streamlining these types of interfaces for our clients to prevent users from accessing features that they shouldn’t be using.  Share isn’t too different in this regard in that it’s built for a more generic use case to cover the basic document management features and scenarios.  Share was also built with a lot of collaboration style features such as wikis, blogs, discussion forums and calendars that aren’t always utilized for every deployment.

TSG started working on many components of the OpenContent Management Suite back for Documentum clients in 2005 after the success of OpenMigrate.  Initial names for the products were Active Wizard for forms and workflow as well as High Performance Interface, or HPI, for Search and Case.  Like OpenMigrate, our clients wanted the capability deploy tailored solution but avoid complete customization with a configured software product that TSG could support.  Just like Alfresco Share, back then our clients were struggling with Documentum Webtop (see our blog series here) and wanted a cleaner solution.  Gradually, between different client development efforts, we were able to build out the core of the OCMS for better search and case based on client projects and feedback.  One of our first development efforts was to support both Alfresco and Documentum.  Back in 2006, our Documentum practice was considerably larger than our Alfresco practice yet clients were able to get the benefits of the Documentum customers and install base with Alfresco.  We continue to develop features and capabilities that come into OCMS from Alfresco, Documentum and our Hadoop practices to the benefit of all of our clients.

Search Features

Performance and ease of use in a search interface is often one differences between Alfresco Share and OCMS.  A future post will go into more detail, but significant difference between Share search and OCMS include:

• Searches can be too broad –  The default search within Share is across a types (documents and folders) and includes all attributes and full text metadata.  While that may seem nice in a “google style” search world, it can be very resource intensive and slow for large repositories.  Also, performance aside, users typically want to find documents in a more targeted manner.  For example, find all claim documents with a given claim number and assigned to a given claims adjuster.
• Advanced Search – Share’s advanced search only allows the user a marginal amount of additional control over the search.  See the video above for more detail.
• Search Results View – The share search results displays results in a list-based view which gives the users fewer options for sorting, filtering and paging results.  Results are paginated via “infinite scroll” where more results appear as the user scrolls down on the page.  This can be problematic when returning many results and attempting to filter the set down to the 5-10 documents that the user is interested in.  Sorting is only possible via a single drop down and users cannot sort based on custom metadata without a customization.

Edit: Read our search interface comparison post here.

Contributor Interface

Like the search interface of an ECM system, the contributor interface is often in the spotlight when it comes to choosing the best interface for an ECM team.  A future post will focus on this aspect of Share, but our high level concerns with Share’s contributor interface are:

• Specifying Document Type and Required Metadata – at first glance, Share’s interface to add documents to the repository seems really smooth.  Simply drag and drop documents where you’d like to put them, and the documents are uploaded immediately.  However, this process skips a couple very important steps:
  • Document Type – if you do nothing, Share will simply add the document with the base object type.  But what if you want to use a subtype that includes additional metadata fields?  Share provides the option to have rules that will specialize the type when dropping a document into a folder, but the user does not have control over this behavior.  This also doesn’t handle the case where more than one type can exist within a folder.
  • Required Metadata – many clients want certain document metadata fields required upon creation or document checkin.  The Share process does not account for this.  The user adds documents, but then must know to edit properties to set metadata.  Most clients want an interface where the user must enter required metadata fields while adding the document to the repository.
• Property Edit – when editing properties, one common request from clients is to be able to see the document contents while editing the properties.  However, in Share’s interface property editing takes up the entire screen.

Edit: Read our contributor interface comparison post here.

Folder Interface

Share’s interface for browsing folders is very typical for an ECM vendor’s default interface.  The user has the ability to view a folder browser tree on the left hand side, similar to Windows Explorer, to navigate through the folder hierarchy in the repository or site depending on configuration and security settings.  Once the user finds a folder to view, a document list appears in the right pane to allow the user to work with the documents.   We’ve discussed before on this blog about how we do not recommend folder-based repository navigation for large and/or complex ECM systems.  Prior discussions on this topic have centered around our comparisons to Documentum interfaces, but Share falls in the same realm here.  Our concerns around Share’s folder interface include:

• Filtering documents in Share’s folder interface is not possible.  You can change how the document list is sorted, but you cannot facet or filter on document metadata.
• Sorting and ordering columns is limited in the same way as the search results view discussed above.  The user cannot choose to display or sort on custom metadata fields without a customization to the interface.
• Folder and Document actions (ex: view properties, checkout, etc) are accessed via a column in the results view that includes a hidden “more” button.  From looking at the results, it’s hard to know where document actions are available.  Folder actions can only be accessed by going up a level to view the folder in the right side of the display.  In this manner, it’s not possible to execute actions on a folder while working with the documents within that folder.  This poses a large issue for many clients that have case management scenarios.
• Viewing documents is accessed by clicking on the document, and the page reloads to display the document in PDF.js.  If the document cannot be rendered to PDF, Share simply displays a download link.  While this works fine for viewing a single document, it can be cumbersome to flip through many documents in a folder since each time, the user must navigate back to the folder to select the next document.

Edit: Read our folder interface comparison post here.

Configurability

Share allows users to configure certain items, mostly around the Sites feature.  Administrators can configure what features like discussion forums, wikis, calendars, etc are available for the Site.  Users can configure their dashboard looks and what dashlets are displayed.  However, for more ECM centric features, share is only configurable via XML and custom code.  For example, all of the following bullet points require custom XML to update, which requires a restart of the Alfresco server when changed:

• Configuring Advanced search to allow the user to search on custom types and custom metadata fields with picklists
• Configuring properties pages for custom types and which fields are visible as well as required
• Configuring fields on a type’s properties page to utilize a picklist for value assistance
• Configuring which document and folder actions are available to the user

With OCMS, all of the above are configurable in our admin user interface and take effect right away without the need for a server restart.

Missing Advanced Features

More and more, we see many of our clients require advanced features that just aren’t present in Share.  Examples include:

• Combine PDF – combine multiple documents into one PDF
• Split PDF – split a single document into multiple
• Folder Notes – allow users to comment on a case folder
• Bulk Property Edit – Allow users to apply property updates to multiple documents at once
• PDF annotations – allow users to add annotation comments on any document’s PDF rendition

Summary

Overall, Share is a good collaboration interface for Alfresco with Sites to handle security and user group separation similar to SharePoint.  However, as the amount of ECM complexity and governance increases, many clients start to look at alternative or custom interfaces including solutions like OpenContent Management Suite.  Look for follow up posts that compare Share to OCMS to see how these two interfaces handle complex ECM requirements around searching, adding and modifying documents, as well as working with documents within a folder.