Office 365 – Seamless Document Editing in OpenContent

One major issues we often hear from author users of ECM systems is the difficulty of a web-based interfaces to edit documents. Since the editing application, typically Microsoft Word, lives on the user’s PC, the file must be downloaded to lock the document, edited locally, and then uploaded back to the system to finalize the check in process. TSG’s OpenContent Management Suite (OCMS) has streamlined this process by providing the ability to edit documents in Office 365 as well as Google Docs. For this post, we will look at some of the recent updates TSG has made to the Office 365 integration.

Document Editing – What are the issues with a browser based approach?

Browser based document editing solutions have always struggled with accessing files on the device.  While launching a file during checkout is a simple, allowing the user to edit/change the content requires the file to be saved on the local PC. During checkin, the web browser has to be directed to where the file is located to begin the upload process for the new version.  A couple of ways this has been accomplished:

• Normal Browser Functionality – Sticking to web standards, the user would have to either click an “Upload” button to pick out the file on their desktop or drag and drop the file into a drop zone. See a demonstration of the drag and drop option here.  While this is the simplest approach and is easiest for IT to support, users don’t like the multi-step process and would like a simpler approach.  Since webapps natively can’t access the file system (that would be a security breach), other approaches have been offered by different solutions.
• Java Applet/Flash/ActiveX – Embedding a Java Applet in the browser (or Flash/ActiveX) allows the browser application to see the file system. The file is copied to a specific location to allow for one click check-in.  While this approach works well in a demonstration, IT organizations struggle with it as implementing client-based tools and keeping Java/Flash/IE up to date is an issue.  Also, given that users often want choice of browsers (Chrome, Edge, IE and Firefox), often this approach doesn’t work on different browsers.  We have also seen clients struggle with having to keep around older legacy versions of Internet Explorer just to support some legacy application that needed that “magical” combination of browser plugins and versions. Lastly, the applet approach would often continuously prompt users to update Java on their machine. The industry has gotten away from Java in the browser as it has a terrible history of security holes, so many of our clients aren’t even installing Java on users’ PCs.

TSG has always pushed for the normal browser upload or drag and drop option as it is the easiest to support and only involves minimal time from the user check-in perspective.  Also, we have seen issues with the Applet approach if the user copies the document to a new location or wants to check-in a document from another source.

Office 365 – What are the possibilities?

Office 365, like Google Docs, allows for the document to be launched for Word editing in the browser, eliminating the need to have the document exist on the desktop or device.  In this manner, OCMS supports both a one click check-out (no need to save) as well as a one click check-in. 

This functionality has existed in OCMS for the past few years. Recently we have upgraded the integration to use use to the latest Microsoft Graph API. This allows OCMS to support both personal Live.com accounts as well as enterprise Microsoft accounts. This gives enterprise customers the option of checking out the document to a central SharePoint team site, or to utilize each user’s personal OneDrive.

Checkout the Office 365 integration demo below and let us know your thoughts.