Tag Archives: Dropbox

About Dropbox. See also Google, Box, Microsoft

Why we are integrating with Box; Part 4: The Dropbox Option

Kerika, Technology, ,

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

As we noted in our last post, our initial preference was to add Dropbox as our second cloud platform. We had personal experience of using Dropbox ourselves, mostly to synch files across multiple personal computers and devices, and to a much more limited experience we had tried using it for collaborating with partners, mostly to share large graphics and video files.

(Particularly in the early days of Google Drive, there were limits on file sizes we would bump against, and high-resolution video files can easily be very large.)

By itself Dropbox doesn’t really provide any collaboration features: there is no contextual overlay on it, like Kerika provides on top of Google Drive.  The best use-case for Dropbox is still that envisioned by Drew Houston’s original mockup video: if you use multiple computers a regular basis, e.g. a desktop and a laptop, and you need to make sure your working files are always available on all these machines.

(The key phrase here is “working files”: using Dropbox as a “system of record” — for files that have been finalized, frozen or otherwise are in an archived state — seems less useful.  Archived files can very quickly grow in size to hundreds of gigabytes, making Dropbox a prohibitively expensive solution.)

To learn more about Dropbox, we began by attending their DBX conference in San Francisco last summer.

DBX turned out to be a startlingly extravagant affair — it made us feel quite the country bumpkins since we can’t envision any Seattle-area startup spending so lavishly on a single day’s conference!  But, it was also an excellent opportunity to meet some of their engineers particularly from their Platform Team, and to understand better Dropbox’s API and product direction.

We immediately ran into a major hurdle: it appeared that Dropbox’s API offered no way for third-party apps to create and manage nested folders.

We didn’t get discouraged immediately, since we did have an opportunity to talk to folks from their platform team.

We put together a detailed presentation on why it made sense for Dropbox to extend their API; and we supplemented this with a mockup video showing exactly how this could result in a great integration of Kerika+Dropbox, similar to what we had achieved with Kerika+GoogleDrive.

(This video hasn’t been released publicly.)

Some folks in the Dropbox platform team were clearly interested in what we presented, and felt that it presented an interesting direction for the platform to take, in order to be more competitive in the enterprise space. However, it was clear that the Dropbox API product roadmap was full up for the foreseeable future, and we were unlikely to find the platform capabilities in Dropbox that we were looking for.

It was disappointing, but not a show-stopper for us: while considering the technical strategy for a Kerika+Dropbox integration, we had also been sounding out some of current and prospective customers to see how enthusiastically they would welcome such a product, and we were getting mixed feedback: on a personal level, most folks liked Dropbox, but at an enterprise level there was much less enthusiasm.

Part of the problem may have been simply perception: Dropbox was viewed very much as a consumer product, and enterprise IT may have reflexively dismissed it as lacking in security, enterprise management, etc.

We did, however, find that some of these folks were suggesting we consider a different platform as an alternative to Google Drive: Box…

The full series:

 

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

Kerika, Technology, , ,

(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: