Tag Archives: Google Apps

Google Drive, Gmail, Google Docs, Google Contacts.

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:

 

Why we are integrating with Box; Part 2: Transparency

Kerika, Technology,

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

In our last post we talked about the privacy overhang that Google Drive faces with many of our prospective customers.

In this post we talk about some frustrations we have experienced as a Google Drive developer, which we would characterize as generally flowing from a lack of transparency on Google’s part.

Sometimes things break within Google Docs or Google Drive, and if the outage is not very widespread, it isn’t acknowledged very well. Google has an App Status Dashboard that is useful when there are major problems, but we have seen minor issues persist for days at a time without being reflected on this Dashboard.

On one occasion there was a problem with Google’s OAuth infrastructure: people trying to sign into their Kerika accounts were getting bounced with mysterious error messages. There was no easy way for us to figure this out because OAuth is simply an underpinning service for Google Apps: it doesn’t have its own status indicator on the App Status Dashboard.

We spent a day sifting through error messages and exceptions logged by our server (in increasing desperation!), before the problem went away as mysteriously as it had appeared.

More recently, our users faced a problem with opening PDFs and image files (PNG, JPG, etc.) that were attached to cards or canvases.

Kerika was correctly getting the thumbnails of these images from Google Docs — so we knew the files were there and were accessible by the user (i.e. it wasn’t a permissions problem), but when users clicked on the thumbnails they got a “503 System Error”.

This particular problem hit close to home for us: we use screenshots and mockups very extensively to communicate between our Seattle and India-based teams.  Not having an easy way to download images that were attached to cards and canvases was a serious inconvenience for us, and we even resorted to using email! (We had given up using email over 18 months ago…)

Being able to seamlessly manage your cloud storage files is a critical element of the Kerika user experience, so from our perspective this was a major problem. Every attempt at debugging failed: old files were opening correctly, but new files weren’t. And while documents and spreadsheets were opening correctly, images and PDFs wouldn’t open…

We even combed through our git branches to see where the bug might be hiding.

There as no bug on our end: our code dealing with thumbnails and Google Drive hadn’t changed in the past 6 weeks.

At this point we knew the problem wasn’t on our end, but that still left us with frustrated users. Our users have very high expectations of Kerika’s product quality and customer service, and we couldn’t explain the problem or manage expectations.

As software professionals ourselves, we are entirely sympathetic to others facing bugs or outages: we suffer these too, all the time, and take no pleasure in casting stones. But we do think Google could have done a better job of notifying people that there was a problem, so we could manage our users’ expectations accordingly.

This is what we try to do ourselves: when we find a bug, we reach out, proactively, to our users to let them know they were affected. We try to provide an honest description of what happened (if it’s a bug in Kerika, we are candid about it), and we provide updates while we work to fix the bug, and then we reach out to them later to make sure our fix works.

Here’s how our users react to our outreach:

“AWESOME! thanks! I’m recommending you to all my friends.” — a church pastor in Florida

“Woo! Yes. Thanks very much!” — marketing manager in Colorado

“WOW!  So impressed with your response time and thoughtfulness.” — small business owner in California

We concluded that any alternative cloud platform we chose had to come from a company that was more transparent and accessible: we wanted to be able to able to report problems and get them fixed, and most importantly, we wanted reliable channels of communication. If we know what’s going on with the cloud platform, it becomes much easier to manage our user’s expectations and keep them happy.

The full series:

 

 

Why we are integrating with Box; Part 1: Privacy Overhang

Kerika, Technology,

(The first in a series of blog posts explaining why, and how, we are adding Box as a cloud service in addition to our long-standing integration with Google Drive.)

When we first started working on Kerika, back in 2010, Google Docs was an obvious choice for us to integrate with: it was pretty much the only browser-based office suite available (Microsoft Office 365 wasn’t around and Zoho was, and remains, somewhat obscure), and we were quite sure we didn’t want to get in the business of storing people’s desktop files in the cloud.

Google Docs (not yet renamed Google Drive) did have various limitations in terms of the file types it would support, and further limitations on the maximum size permitted of different types of files — the largest spreadsheet that they would support, for example, wasn’t the same size as the largest Word document — but the idea of building Kerika as a pure-browser app was a very appealing one.

So we integrated with Google Docs at a low level, fully embracing their API, to provide a seamless experience unlike anything that you might find from competing products:

  • When you add a document to a card or canvas in a Kerika board, it is automatically uploaded to your Google Drive, where it is stored in a set of nested folders.
  • When you add people to a Kerika board, their Google Drives automatically get dynamic links to your Google Drive, giving them just the right access, to just the right files.
  • When people’s roles change on a project team, their Google Docs access is automatically and instantly changed.
  • When a document is renamed in Kerika, the new name is reflected back in Google Drive.

Many of our users who are already using Google Docs loved our integration: one user went so far as to say “Kerika makes Google Docs sing!”

The Google integration was not easy, particularly in the early days when there were wide gaps between the documentation and the reality of the API: we had to frequently resort to the wonderful Seattle Tech Startups mailing list to cast about for help.

But it seemed worth while: our Google integration has definitely helped us get paying customers — organizations moving off the traditional Microsoft Office/Exchange/SharePoint/Project stack were looking for a tool just like Kerika, particularly if they were also grappling with the challenges of becoming a Lean/Agile organization and managing an increasingly distributed workforce.

We even signed up organizations, like the Washington State Auditor’s Office who started using Google Apps for Government just because they wanted to use Kerika!

But, there are other folks we encounter all the time who say to us: “We love everything about Kerika except for the Google integration”

Some folks want to work with Microsoft Office file format all the time (although that’s possible even with our Google Drive integration, by setting a personal preference, and will be even easier in the future with new edit functions announced at Google I/O), but, more commonly, we came up against a more basic concern — people simply distrusted Google on privacy grounds.

It’s debatable as to whether it’s a well-grounded fear or not, but it is certainly a widespread fear, and it is not showing any signs of diminishing as we continue to talk to our users and prospects.

Some of this is due to a lack of understanding: users frequently confuse “security” and “privacy”, and tell us that they don’t want to use Google Apps because it isn’t secure. This is really far off the mark, for anyone who knows how Google operates, and understands the difference between security and privacy.

Google is very secure: more secure than any enterprise is likely to be on its own. They have a lot of software and a lot of people constantly looking for and successfully thwarting attackers. It’s always possible for someone to hack into your Google account, but it will be through carelessness or incompetence on your end, rather than a failure on Google’s part.

Privacy, however, is a different matter altogether, and here Google does itself no favors:

  • It’s Terms of Use are confusing: their general terms of use, for all Google services, contains this gem which drives lawyers crazy: “When you upload, submit, store, send or receive content to or through our Services, you give Google (and those we work with) a worldwide license to use, host, store, reproduce, modify, create derivative works (such as those resulting from translations, adaptations or other changes we make so that your content works better with our Services), communicate, publish, publicly perform, publicly display and distribute such content.”
    The Google Apps for Business Terms are much more specific: “this Agreement does not grant either party any rights, implied or otherwise, to the other’s content or any of the other’s intellectual property.”
    But most people derive a first, and lasting, impression from Google general terms, and few get around to investigating the GAB specific terms.
  • Google finds it hard to acknowledge people’s privacy concerns. This is somewhat puzzling, and can perhaps be best explained as a cultural problem. Google genuinely thinks itself of a company that “does no evil”, and therefore finds itself reflexively offended when people question its commitment to privacy. It’s hard to address a problem that challenges your self-identity: the Ego acts to protect the Id.

Entire sectors seem closed to Google Drive: lawyers, who could certainly benefit from Kerika’s workflow management, and healthcare, which is already adopting Lean techniques (pioneered locally by the Virginia Mason hospitals.)

In the small-medium business (SMB) market in particular, there isn’t any meaningful outreach by Google to address the privacy/security concern.  (Google does reach out to large enterprises, but in the SMB market it relies entirely on resellers.)

For our part, we have done a ton of work persuading people that it’s OK to use Google Drive, but we don’t get paid for this (we are not a Google Apps reseller), and this is, at best, a distraction from our core mission of building the very best work management software for distributed, lean and agile teams.

We need an alternative cloud storage platform: one that has robust capabilities, is enterprise-friendly, and doesn’t come with any privacy baggage.

The full series:

 

Fixing 58 server bugs and warnings (Why so many?)

Usability, ,

Along with the hundred styling changes and UI cleanup we are wrapping up, we also took the opportunity to fix around 58 different errors and warnings being reported by our server.

This might sound like a lot, so perhaps a little context is useful:

  • Kerika is built on top of Google Apps (at least, for now): we use Google’s OAuth service to sign up and sign in people, and we use Google Drive to share files within project teams.
  • A lot of errors show up as a result of this Google integration, only a fraction of which are solvable from our perspective:
    • Some errors relate to people from restricted Google Apps domains trying to use Kerika. This happens at least once a week — someone working at a company that has Google Apps for Business tries to sign up for Kerika, but fails because their Google Apps Administrator (typically, someone within their IT department) has prohibited any third-party apps from integrating with their Google Drive.
      This is an example of an unsolvable problem — we can’t override the existing protection that this company has set up (and nor would we want to!) so we are going to redirect users to an explanatory page that helps them understand the problem is not with Kerika.
    • Sometimes Google Apps has outages: when this happens, we can get a cascade of errors on our servers, because these outages are typically intermittent and inconsistent across our user base. Some folks experience problems, others don’t. We are trying to come up with a way to inform people about what’s happening, so they don’t think it’s Kerika that’s busted.
    • Sometimes Google burps: not have an outage, but experience a fleeting problem with uploading a file. We might get nothing back from Google than a generic “500 error: system not available”.
  • We have also had problems related to our use of Firefox for the Render Server: Firefox’s latest updates are sometimes less stable than previous ones, and in general Firefox is starting to have a really big footprint in terms of memory usage.
  • And, finally, we have had our own bugs, just like any other software developer. Some of these have been tricky to find, but as we find them, we squash them.

 

A shift towards short-lived cookies

Technology, Usability

In an earlier blog post we noted that Google is making it increasingly hard for people to create and maintain distinct Google IDs, and this is creating more problems for Kerika users, forcing us to rethink our “cookie strategy”. Here’s the background:

Long-lived and short-lived cookies

When you sign in to Kerika, you do so using your Google ID: the Kerika server gets an authorization token from Google and places a cookie on your local computer so that you don’t have to sign in again, if you close and then reopen your browser.

We had been using what’s known as a “long-lived cookie”: one that doesn’t automatically expire when you close your browser. That made Kerika more like a news site than a banking site: when you login to a news site as a registered user, you get a long-lived cookie so that you don’t have to login again, even after you have closed your browser (or even restarted your computer).

Banking sites, on the other hand, use “short-lived cookies”: if you close your browser tab, open a new one and try to access your bank account again, you will be asked to re-login.

Short-lived cookies are generally used for more sensitive websites, like banking, because there is a big tradeoff in terms of user convenience. Kerika had previously opted for long-lived cookies because we wanted to make it really convenient for people to get back to their Kerika boards after having closed their browser.

The problem we face

The problem we are facing now is that it is increasingly more likely that your Kerika login is out of sync with your Google login. There are at least two ways in which this could happen, one of which was always a risk, and the other a new risk resulting in the shift in Google’s approach to user IDs:

  • The old problem: people with multiple Google IDs would frequently switch between them, without logging out of Kerika. For example, someone has two Google IDs: A and B. She may have signed up with Kerika while she was logged in as User A. Since we were using long-lived cookies, a Kerika cookie identifying her as “User A” will stay on her machine until she logs out of Kerika.
    But, in the interim she may have separately logged out of Google as User A and logged in as User B (perhaps to check her Gmail on a different ID). This would result in a situation where she is known to Kerika as User A, and currently logged into Google as User B. In this scenario, she would be unable to open any files attached to her projects because of the mismatch in IDs.
  • The new problem: Google is making it easier for people to be logged in as two different IDs, using the same Chrome browser. (Note: this is true only with the Chrome browser; not true with Safari, Firefox or IE as far as we know.) This considerably increases the odds that a user is currently logged into Kerika as User A, and simultaneously logged into Google as User B.
    Because the user never consciously logged out from Google – just switched IDs while on YouTube or Gmail or somewhere – she may be unaware that she isn’t who she thinks she is…

The short-term solution

We can mitigate this problem by switching over to short-lived cookies. This makes the user experience a little more annoying, in our opinion (because you have to login more frequently to Kerika, or remember to keep your browser alive), but it should help reduce the odds that your Kerika ID is out of sync with your Google ID.

The long-term solution

Allow users to sign up directly at Kerika, without using their Google IDs!

It’s now easier to work with Microsoft Office files

Usability, ,

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!

Choosing between Google’s App Engine and Amazon’s EC2

Kerika, Technology,

Back in the summer, when we were making our technology choices, we had to decide which company was going to provide our “cloud”. It really boiled down to a decision between Google’s App Engine and Amazon’s EC2. Microsoft’s Azure service was still relatively new, and in talking to one of their product evangelists we got the distinct impression that Microsoft was targeting Azure for their biggest customers. (That was nice of their product evangelist: not taking us down the garden path if there was a mismatch between our needs and Microsoft’s goals!)

Here’s why we chose EC2 over App Engine:

  • Amazon is accessible: both Amazon and Google have engineering centers in our neighborhood, and Amazon’s is, of course, the much larger presence, but the real issue was which company was more accessible? Amazon does a lot of outreach to the startup community in the Seattle area – Jeff Barr is everywhere! – whereas Google is a lot more aloof. It’s much easier to find an engineer or product manager at Amazon who will talk to you, and that really makes a difference for a startup. Real people matter.
  • There was negative buzz about App Engine, at least back in August. People in the startup community were talking about suffering outages, and not getting very good explanations about what had gone wrong. Google’s aloofness didn’t help: there wasn’t anyone reaching out to the community to explain what was happening and there was little acknowledgment of problems coming through on Google’s official channels.
  • To beta or not to beta? Google’s rather lavish use of the “beta” label (remember the many years that Gmail was in beta?), and their recent decision to pull the plug on Wave added to our nervousness. Were they serious about App Engine, or was this another science experiment?
  • An infinite loop of web pages: in the absence of any physical contact with Google, we tried to learn about their service through their web pages – well, duh, of course, dude! The problem was that much of the information is presented in a series of rather small pages, with links to more small pages. As an approach to information architecture – particularly one that’s biased towards being “discoverable” by a search engine – this makes a lot of sense, and the Kerika website takes as similar approach. The risk with this approach is that you can very easily find that you are following links that take you right back to where you started. (And our website runs the same risk; we look forward to your comments detailing our failings in this regard!)

While we were pondering this choice, Google came out with a rather interesting offer: unlimited free storage for a select handful of developers. (How select? Probably as select as one of Toyota’s Limited Edition cars, production of which is strictly limited to the number they can sell.) The offer was presented in the usual mysterious way: you went to an unadvertised website and made an application. Someone would let you know “soon” whether you would get past the velvet rope.

We thought we had a good chance of getting included in the program: after all, Kerika was designed to add value to Google Docs, and we were using a number of Google’s services, including their Open ID for registration. And, indeed, we were selected!

The only problem was that the reply came about 4 weeks later: an eon in startup time. By that time, we had already decided to go with EC2…

(Is EC2 perfect? No, not by a long shot, and we were particularly annoyed to find a rather fatal flaw – from our perspective – in the way their Elastic Load Balancer can be configured with canonical web addresses: a problem that’s been noted for 2 years already. Not cool to sit on a problem for 2 years, guys. Not cool at all.)