In the last post of our ADF and OpenContent Management Suite (OCMS) comparison series, we compared how Search works in ADF vs. OCMS. As we’ve done previously with our comparison series blog posts, (Alfresco Share and Documentum) for this next post we’ll turn our attention to the contributor interface. Specifically for contributors and authors, we’ll look at how users can add documents, version documents, and modify properties.
Common Alfresco Contributor Requirements
The common requirements that we often see for Alfresco 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 ADF and OpenContent Management Suite.
ADF Demo Application
As with our Search comparison post, our comparison is based on Alfresco’s “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. For more examples of ADF components, check out the component catalog.
ADF Contributor Components
When working with a Contributor interface, we will explore three areas – how the user can import documents into the system, edit documents, and edit properties
Adding documents is demonstrated in the ‘Content Services’ section of the demo shell application. When navigating there, the user is presented with a folder browser component that defaults to the user’s home folder:
At the bottom, there’s an option to upload documents with a traditional browse button, but drag and drop is available as well directly on top of the document 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, the 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, ADF will simply add the document with the base object type. But what if you want to use a subtype that includes additional metadata fields? Administrators can define rules in the Share interface that will specialize the type when dropping a document into a folder, but the user does not have control over this behavior. The behavior 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 out of the box ADF process does not account for required metadata. The user adds documents, but then must know to edit properties to set metadata after the upload is finished. Most clients require an interface where the user must enter required metadata fields while adding the document to the repository.
Interestingly, ADF does not have a component for traditional checkout or checkin. Instead, there’s a component to download a document, and a “Manage Versions” action to upload a new version. There is a component to lock a document, but this is different than a traditional checkout in that a locked document must be unlocked prior to uploading a new version. All of this being said, an ADF application developer could choose to build a more traditional checkout and checkin – it’s just not part of the out of the box components.
One item to note: currently, in the demo shell application the user must browse to the document when selecting a new version. There’s no drag and drop capabilities. We’d imagine this will be added at a future point in time. Currently, the ‘Upload new version’ button simply opens up a browse dialog:
Aside from a typical checkout and checkin, Alfresco does support more seamless editing of documents in Microsoft Office via the SharePoint protocol as well as online in the browser using Google drive. We do not see these actions exposed in ADF, but would expect that Alfresco will add them in the future.
Editing Document Properties
Property editing in the demo shell application is performed through the info icon. This can be displayed as a modal over the folder browser component:
Additionally, properties can be displayed next to the document:
One benefit of this component over Alfresco Share is that inline property editing is possible (vs. Share taking the user to a separate page). This allows the user to edit properties while also viewing the document, something that we’ve always done in OCMS.
One improvement we’d suggest for the demo shell as well as any production ADF application is around how properties are saved. Currently when editing properties, the ADF interface changes each property line to include a check to save and a X to cancel. If the user changes multiple properties, the user must click each check icon to save each property individually. There’s currently no way to save all properties with one click after making updates to multiple properties.
OpenContent Alfresco Contributor Components
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 ADF’s folder browser component:
The real difference between contributing content in OCMS vs. ADF 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.
- Indexing Mode – Additionally, OCMS can handle working through a queue of documents added by users or other processes. In this case, the final folder for each document is unknown at the time it is added to the repository. During indexing, the user can add metadata to each document in the queue, which not only sets the properties, but will correctly file the documents into the proper folders. Check out this video in the TSG Learning Zone to see the Indexer in action.
In addition to the points made above, there’s a number of other features that set OCMS apart from out of the box ADF components:
- 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.
The basic checkout action in OCMS will 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 ‘Minor’ and ‘Major’ version options. No system downtime is needed, unlike code updates changes with the Manage Versions ADF component.
OCMS supports editing documents seamlessly as well. OCMS supports editing documents directly in the browser using Google Docs or Microsoft Office Online. See this video to see it in action.
Editing Document Properties
Like ADF, OCMS displays the document in the browser whenever possible to allow the user to preview the contents. 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.
As ADF continues to evolve, we would expect that additional components will be added and existing components will be enhanced. Readers should understand that 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 contributor best practices in these implementations.