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
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.
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.
Contributor Interface – OpenContent Management Suite
The following sections will overview how OCMS allows the user to add documents, edit documents, and edit properties.
When looking at how documents are added to Alfresco OCMS supports document import via drag and drop and the normal “browse” button, much like Share:
The real difference between contributing content in OCMS vs. Share happens right after the user drops the files. Rather than starting the upload immediately, OCMS allows the user to interact with the content. After adding documents to the upload, the user is presented with the bulk indexing screen:
Some items to note on the screen above:
- Document Type – an Administrator can easily configure what document type the user can import based on the user’s context. In the screen above, the user is importing to a Policy folder so the system smartly chooses the only document type configured, Underwriting Document. If needed, OCMS also supports configuring multiple document types and allowing the user to choose which to import.
- Common Properties and Bulk Import – while importing multiple documents at once, OpenContent allows the user to set some properties once that apply across all documents. This alleviates the need for the user to set the same property value across each document one by one.
- Metadata Inheritance – in case management scenarios, documents often share metadata with the case folder. In the example above, the underwriting document type contains a policy number attribute that’s also populated on the policy case folder. With OpenContent, these attributes can be pre-populated and optionally locked down when importing a document. So in this case, the user would not not need to re-key the policy number attribute, or any other common metadata fields.
Whether importing one document or multiple, the next step allows the user to edit metadata of the document during the import:
- Required Metadata – When a user imports a document in OCMS, the user is presented with a form for document properties. Based on administrator config, certain properties can be configured as mandatory. This prevents documents from being added to the system with incorrect or incomplete metadata.
- Heads Up Indexing – when adding a document to the repository, OpenContent can display a preview of the document in the browser to aid in setting document properties. The user can also select text in the document to populate attributes. This is often used, for example, in cases like importing an Invoice and setting an invoice_number attribute. Rather than typing the value in, the user can simply highlight the value on the invoice, which will populate the metadata field automatically.
In addition to the points made above, there’s a number of other features that set OCMS apart from Share:
- Smart Processing of Emails – when OpenContent detects that the user is uploading an MSG file, it smartly pulls off any attachments and adds them to the list of documents queued for upload. After the import, the email and attachments are related using a parent/child relationship so the user can easily see attachments when looking at the email.
- Scanning with OpenCapture – OpenContent Management Suite integrates seamlessly with OpenCapture to allow users to scan documents directly into the repository from a desktop scanner.
- Other Integrations – documents can also be pulled in via integrations with Box as well as GMail.
As mentioned above, 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:
As noted above, some clients have business controls that major versions are approved content, while minor versions are in process. For these clients, it’s a simple change in the OCMS admin to disable the ‘Same’ and ‘Major’ version options. No system downtime is needed, unlike XML changes in Share.
Also like Share, OCMS supports editing documents seamlessly as well. OCMS supports editing documents directly in the browser using Google Docs or Microsoft Office Online. See the screencam in this post to see it in action.
Editing Document Properties
Like Share, OCMS displays the document in the browser whenever possible to allow the user to preview the contents. However, unlike Share, OCMS allows the user to continue to view the contents of the document while editing properties:
This allows the user to ensure that the property edits are made properly based on the document contents.
Share has garnered some concerned attention from Alfresco customers this year when Alfresco announced that they would be deprecating Share in future. Many Alfresco clients that are still on Share face the question – is it better to stick with a deprecated interface or move to something else? We would say that since Alfresco is no longer investing in Share and has turned it’s attention to the developer focused Application Development Framework (ADF), it makes sense to switch to a modern interface. For many of today’s business application users that are accustomed to working in streamlined web applications, the OpenContent Management Suite provides a better long-term direction and a large jump-start on any ‘from scratch’ development effort.
Let us know your thoughts below:
[…] Edit: Read our contributor interface comparison post here. […]