Tag Archives: Microsoft

About Microsoft Office.

Why we are integrating with Box; Part 5: The OneDrive Option

(The fifth in a series of blog posts on why we are adding integration with Box, as an alternative to our old integration with Google Drive.)

This post is shorter than the others in this series for one simple reason: the OneDrive API has no way for third-party apps to manage permissions on folders, and that’s a show-stopper for us in terms of providing a really good user experience.

This limitation was probably more frustrating for us than the case with Dropbox:

  • We are next door to Microsoft: Issaquah is just 15 minutes away from Redmond, which means its easy for us to find people to talk to at Microsoft.
  • Microsoft has a great history of working with third-party developers and a very robust partner program.
  • Nearly all enterprises who are interested in Kerika are long-standing users of the Microsoft stack (SharePoint/Project/Exchange); a Kerika+OneDrive solution would have been a relatively easy sale in terms of internal IT politics within most enterprises.

We hadn’t taken OneDrive very seriously when it was available only as SkyDrive, i.e., when it was available only as part of the full Microsoft stack, but once Satya Nadella became CEO and (coincidentally?) Microsoft decided to un-bundle their cloud platform and create OneDrive, the platform became much more interesting for us.

(We had seen only lukewarm enthusiasm, at best, for the full SkyDrive package, but OneDrive as a standalone alternative to Google Drive, Dropbox, Box, etc. was more interesting.)

Interestingly, the feedback we got also pointed to why adoption of OneDrive might be slower than Microsoft would like: OneDrive is being marketed as part of the Office 365 solution set, and many of organizations we were talking to seem slow to adopt Office 365.

One big reason for dragging their feet is that few enterprises that we talk to are enthusiastic about the implied upgrade to Windows 8.x.

(Upgrading to Win 8.x isn’t a technical requirement, but the sales push from Microsoft is for the full Win 8.x/O365 deal.)

One cause for this, of course, is that there isn’t any great love out there for the new Win 8.x user interface: few end-users seem enthusiastic, and IT folks are very worried about training and support for a radically different user experience.

Even within Washington State’s government agencies — where one might expect Microsoft to have a home field advantage — we haven’t seen any real enthusiasm for OneDrive; in fact, Box is the only cloud service provider to have a master services contract with Washington!

The full series:

 

Why we are integrating with Box; Part 3: Considering Alternatives

(The third in a series of blog posts on why we are adding integration with Box, as an alternative to our old integration with Google Drive.)

Adding an alternative to Google Drive was never going to be easy; Kerika has a deep integration with Google:

  • Our registration and sign-in process was built entirely to work with Google IDs.; originally implemented using OAuth 1.0, and then upgraded to OAuth 2.0.
  • The product is available on the Chrome Web Store and the Google Apps Marketplace, so enterprise users can sign up and manage users using their Google Dashboard.
  • When users add desktop files to their cards and canvases on Kerika project boards, these get shared using their own Google Drives.
  • Originally, we had an integration with Google Contacts as well, although we dropped that some months ago since it added to the privacy baggage of working with Google.
  • And, until Google killed this service, we used Google Checkout to handle online payment.

Adding another platform would be a ton of work, and it would delay an exciting product roadmap of new features.

Ultimately, the strategic decision for Kerika came down to: should we add more features to our product, while staying within the Google space, or broaden the appeal of the existing product by adding another platform?

We concluded that the core Kerika product, as it exists today, was already very usable: we could see how it had helped users in a variety of industries and organizations, of all sizes, across sectors, and around the world. And, we could reach even more users if we added a cloud storage platform that didn’t have the privacy baggage that was hampering Google Drive.

Having decided on a broad strategy for the company, the next critical question became: which cloud platform would make more sense for our users?

We considered three alternatives:

  • Dropbox
  • OneDrive/SkyDrive
  • Box

We were initially attracted to Dropbox because of its wide popularity, which far outstrips that of Box or OneDrive.  We figured that if we were going to go through all the trouble of adding another cloud platform, we might as well go for the one with the largest user base.

But, first, we needed a plan of attack…

We started our process by first documenting all the functions of Google Drive that Kerika’s user experience relies upon.

These turned out to be a fairly large set, so we whittled it down to a core must-have set, and a larger nice-to-have set.  This gave us rational technical requirements that we could use to evaluate Dropbox, OneDrive and Box.

The most essential requirement we had was that the Kerika application should be able to manage permissions on folders, not just individual files.  Here’s why it’s essential for the Kerika user experience:

A bunch of our competitors offer a superficial level of integration with cloud platforms, generally at the “file picker” level only.

This means they have a button on their UI somewhere that allows users to pick a file from their Dropbox, Google Drive, etc. and add it to a card on a project board.

But this superficial integration offers no real benefit in a team environment: if you add a file to a card using just a file picker, other folks on the project team don’t automatically get access to that file.

Instead, when they try to open files attached to cards, on a board where they are part of the team, they must ask the file owner for permission — each and every time!

Kerika’s user experience is much better: when you add a file to a card or canvas, the software makes sure that every member of the project team gets instant access to that file, and that access is automatically adjusted to reflect their current role: Team Members get read+write access; Visitors get read-only access.

And the critical requirement was that the Kerika app could manage permissions on entire folders, not just individual files.

A typical Kerika board can easily include a hundred or more cards; in fact, some of our users have boards that run to over a thousand cards. Each of these cards could have several files attached to them.

So, if we are going to manage thousands of files for a single project, we really need to be able to create folders — and ideally sub-folders as well — so that we didn’t just spray these thousands of files all over each users’ cloud storage.

We also started informally polling our current users and future prospects about how they would view a Kerika+Dropbox vs. Kerika+OneDrive vs. Kerika+Box solution.  (The feedback we got was surprising…)

And, finally, we tried to get a sense for how transparent each of these companies would be — how easy it would be build a partnership arrangement, to have a dialog with their platform teams.

The full series:

 

It’s now easier to work with Microsoft Office files

Although Kerika is built on top of Google Drive, you can still share files in Microsoft Office format.

Here’s how it works:

  • By default, your files are converted to Google Docs format when you add them to a card or canvas in Kerika, but if you prefer, you can keep them in their original Microsoft Office (or other program, like Adobe) format.
  • Go you personal preferences page, at https://kerika.com/preferences, and you will see this preference switch:
Setting your Kerika preferences
Setting your Kerika preferences

Toggle the “Use Google Docs for projects in my account” to OFF, and your Microsoft Office files will remain in their original format even as they get shared using Google Drive.

To make this preference even more useful, we have added a “smart download” feature: if you are storing your files in Microsoft Office format, clicking on a file attached to that card will automatically download that file for you, so that you can open it in Microsoft Office.

For example, if you have added a Microsoft Word file to a card, and are storing it in the original MS Office format, clicking on the attachment will download the file and launch Microsoft Word so that you can immediately start editing the file.

In some cases you might see a “403 Access Denied” message appear: if you do, there is a simple workaround for this problem – just open docs.google.com in a separate browser tab, and try again. It will work this time.

A very important point to note: if you download and edit a file, make sure you attach the modified document as a new attachment to your card (or canvas); otherwise your team members won’t see the latest version!