Alfresco Share – Contributor Comparison with OpenContent Management Suite

In the last post of our 2018 Share and OpenContent Management Suite comparison series, we compared Search features between Share and OpenContent Management Suite. For this post, we’re going to compare the the contributor functionality available in Share and compare that to OpenContent Management Suite (OCMS). Our evaluation is based on what is configurable using the out-of-the-box products without any coding or customization. This post focuses on some of the highlights of document creation, property editing, checkout, and checkin. Our next post in the series will focus on working with folders and documents beyond import and editing.

Common Contributor Requirements

The common requirements that we often see for contributors include:

Ability to add multiple documents at once via drag and drop.
Ability to add a document from a template rather than uploading a document from the user’s machine.
Ability for the system to smartly suggest available document types, or auto-select the type if only one is possible.
Ability for the user to set metadata on the documents, both during import and after. Additional related requirements include:
- Enforce required attributes to be set.
- Allow the user to choose from a picklist for certain attributes.
- When uploading more than one document, allow the user to set attributes in bulk.

Keeping the above requirements in mind, the remainder of this post will compare Share and OpenContent Management Suite.

Contributor Interface – Share

When talking about the Contributor interface, we will explore three areas – how the user can import documents into the system, edit documents, and edit properties

Adding Documents

Most Share implementations segment users in the repository based on the concept of a ‘site’, which is very similar to the site concept in Microsoft SharePoint. Inside the site, documents are found in the Document Library. This section displays a traditional folder hierarchy on the left and documents on the right. Users have two options for adding documents to a folder. The first is an upload button that displays a dialog where the user can select the documents:

Note that in the dialog box, the user must select the file(s) using the button. Drag and drop will not work here. The second method for uploading allows the user to simply drag and drop one or more documents onto the file list:

In either case, immediately after selecting or dropping the files, the documents are added to the repository and placed in the target folder. 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. The Share process does not account for this. The user adds documents, but then must know to edit properties to set metadata after the upload is finished. Most clients want an interface where the user must enter required metadata fields while adding the document to the repository.

Editing Documents

The user interface for editing documents is similar in Share and OCMS. Both systems allow the user to checkout the document and download a local copy. After making the updates, the user can checkin the new content and upload the file from the local copy:

One item to note – unless Share’s XML configurations are updated, the interface will always allow the user to choose whether or not the next version is a major or a minor change. This may be a problem for certain scenarios where the business controls that major versions are approved content, while minor versions are in process.

Aside from a typical checkout and checkin, Share also supports more seamless editing of documents in Microsoft Office via the SharePoint protocol as well as online in the browser using Google drive.

Editing Document Properties

Share’s document viewer displays the document on the left side if it is, or can be transformed into, a format that is web preview-able (ex: PDF, images, etc). The right side lists a number of sections including one that views the properties:

While it’s nice to be able to view the properties with the content, if the user wants to edit properties, this screen takes up the entire page:

There are two main issues that clients bring up with the Share interface for editing properties:

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.
As in the example above, often times a client has a custom object model with custom metadata. By default, Share displays many of the out of the box metadata that should be hidden from the user. For example, in the screenshot above, clients typically want to hide properties like the thumbnail modification data, initial version checkbox, native mimetype and others. While Share does allow this to be configured, it’s XML configuration that requires a server restart to make updates.