Getting the job done, QUICKER!
All users know the frustration of opening an online file and then waiting for the app to open, and then waiting some more, and finally some time later... Ready to go!
We thought it would be a cool test to see if using the "Open with Captisium" menu option was quicker to open native Microsoft Office files stored in SharePoint Online or OneDrive for Business than the off-the-shelf "Open in Word", "Open in Excel" or "Open in Powerpoint" options.
Once we had those results, we set up a second test, to see if the "Open with Captisium" process was quicker for Microsoft Office Applications or the free Apache Open Office Applications. I think you will be surprised at the results, I know we were.
We deliberately excluded the "Open in [insert app name here] Online" fly-out menu option, for three main reasons, firstly, it's not the true application, it's a cut-down version. Secondly, it is a web-based rendering of the file, so there is nothing (other than the HTML) to download and finally, it's not really using your desktop or laptop connection or power to process the content of the document that you are opening, it's using the Microsoft servers and only needs to deliver the HTML rendering. Also, anyone that has used it would certainly mark these app as "Need More Work".
We used the same desktop computer for both tests. It was a 4GB RAM, 2 Core, Windows 10 (32 Bit) O/S. It shouldn't matter what the processor is, because both methods get the same access to the RAM, CPU and O/S features.
We selected a number of files in each of the Microsoft Word, Excel and Powerpoint file types and ran the tests on the same files for each method. We made sure that we limited the amount of human intervention in all cases, by turning off check-In and check-out on our SharePoint Online environment and things like that. The Windows 10 O/S was a stock standard installation, and had no customisations or configuration changes beyond the standard (default) installation.
In both tests, we ensured that everything that was needed, was installed and running. We loaded Microsoft Office and the Captisium Universal File Handler client-side Application.
We repeated the tests for two different browsers, just to be fair. The browser that you use doesn't play a huge part because neither the Captisium Universal File Handler or the Microsoft Apps use these items beyond the basic process initialisation. In our case, launch an app.
Results - Initial Observations
We simply used both apps to open the same files and timed how long each took to get to a "Ready To Edit" position, which is mostly the reason why you would open these files. As you can see in the image below, we could have opened our documents using any of the available methods.
We noticed on the back of our blog about using Apache Open Office, if you don't have Microsoft Word installed, then the "Open in Word" menu option doesn't do anything in our current configuration.
Issue using Microsoft Office Apps
The first and most noticeable thing was the number of user interactions required to allow the file to launch in the Microsoft Application when selecting "Open in [App Name]". There are three events where the user needs to do something to continue the process, this was ultimately the down fall of the native process. Now, we know why these are here, but there does appear to be three bites of the same apple, so to speak.
When selecting the the "Open in Word" option from the fly-out item menu, the browser prompts you to launch the app.
When you click the "Open" button, almost immediately, another pop-up from the Operating System is displayed, which warns you that some files could have viruses etc.
A valuable community service announcement. We assume that you are using some form of real-time virus checker. If you aren't; you should get a virus checker program installed immediately. In our environment, the desktop is protected using the Fortigate products, which provide real-time checking, and work really well!
The third and final warning only appears the first time that you open a document using the Microsoft Office Suite application, when the source of the document is online (or any network actually), it's a warning that the file is opened in "Protected View". Again, we have specifically needed our file in edit mode as a test parameter.
Once all of these additional user interactions where completed, the files in the test where considered "Ready To Be Edited" as the benchmark for our test.
First points to Captisium
There was no need for any user interaction when using the "Open with Captisium" menu option, so this meant that the whole process felt more seamless and definite. It also meant that a user who had executed a request to edit an item, was in fact, going to be able to achieve this result without having to continually confirm the request.
Because the Captisium Universal File Handler Client-Side Application is downloading the file, the virus checking was done on the file in realtime. If a virus was indeed present in the file, the virus checker program would have detected it and quarantined the infected file, before we could have opened it.
Second Points to Microsoft
There are a number of collaboration features that are retained by using the "Online" version of a file or document within the Microsoft Office Suite, most notably, are the "Co-Authoring" features.
Allowing the file to remain in a commonly accessible location means that other users (permission pending) can Co-Author the same document that you are working on at the same time.
We understand that there may well be cases when this feature is required, but we have discovered over a very long period of time, that this happens less often that you might think. Assuming that the meeting invite isn't for everyone to open a file and perform updates.
The AutoSave feature has saved my bacon on more than one occasion while working with documents in Microsoft Word. The feature still works when you use "Open with Captisium" however, it works much more quickly, which is a blessing for really large documents, as these are the documents most likely to screw up. This is because the file is now locally stored and not a remote object.
In our speed test we concluded these results.
On average the Captisium Universal File Handler was consistently quicker at getting SharePoint Online files opened and ready to start editing than the dedicated Microsoft Office app.
In this test, we thought it would be useful to know if the "Open with Captisium" was quicker when the target was a Microsoft Office application or the free Apache Open Office application.
It is important to note that the files used where native Office OOXML, that is they are Open Office XML format files, and should therefore, be able to be read by both Microsoft Office and Apache Open Office. But they were created with Microsoft Office.
I think that everyone reading this would not be surprised with the final result. In all but a couple of cases Microsoft Office was the superior load time product, and shaved more than 22% off the load time of files on average than Apache Open Office. One one occasion (PPTX (Medium)) the Apache result was better then the native Microsoft Office result.
People who use the Apache Open Office software can take a huge amount of solace in the knowledge that they are using something that is free, which means that it's probably worth the wait.
All-in-all, an interesting and surprising experiment.
Discover more about the Captisium Universal File Handler for SharePoint Online, OneDrive for Business, Microsoft Teams and Outlook online, and start to save more time.