Tag Archives: Box

About Box’s cloud storage. See also Cloud.

Box vs. Google: what’s different, if you are a Kerika user?

Technology, Usability,

We got an email this morning from a user that we decided to answer here, because the topic is relevant to many of our old users…

We are wondering what the differences between Box vs Google are going to be. Also, if we move over to a Kerika+Box account, will we have to rebuild what we have set up in Kerika+Google?

To answer the first question: the Kerika user interface is the same, whether you use Kerika+Box or Kerika+Google.

And, we fully intend to keep the user interface the same across these two cloud storage platforms — and any others that we might support in the future.

That said, the Kerika user experience, which is more than just the user interface, is a little different due to the quirks of Box vs. Google.

For example, Box makes it really easy to sign up as a new user, and keep your old email account.  You can do that with Google, too, but it’s a lot more cumbersome.

Box also works really well with Microsoft Office files: Box doesn’t try to convert your files into it’s own proprietary format, i.e. it doesn’t have its version of Google Docs, so if you like working with Microsoft Office, Kerika+Box is probably the better choice.

(Note: it’s possible to use Kerika+Google and not have your files converted to Google Docs, by setting a user preference, but that kind of misses the point of using Kerika+Google in the first place…)

If you like to view and edit your files right in the browser, then Kerika+Google is the better choice because Google Docs is getting better all the time.

For both Kerika+Google and Kerika+Box, we try to make sure all your Kerika-related files are neatly stored within your own cloud platform, but that’s a little better on Kerika+Google than with Kerika+Box:

Google allows Kerika to create as many nested folders as we need, which means that you only see a top-level folder called “Kerika.com” when you view your Google Drive, and all your projects, across all the accounts you work with, are all stored inside here.

Box doesn’t allow us to create nested folders in the same way, so you will see a lot more top-level folders in your Box account as your Kerika collaboration network grows.

So, the same user interface for both Kerika+Google and Kerika+Box, but a slightly different user experience with pros and cons for both Google and Box.

And the user interface will remain the same in the future: we have no intention of adding features that will only work with Google or Box — only features that will work well with both.

Now, for the second question: if you create a new Kerika+Box account, you will need to create new projects in this account because it is not connected in any way to your Kerika+Google account.

This may be a bummer for some of our old users who have a lot of projects built up using their Kerika+Google accounts, and now want to switch over to using Kerika+Box.

The reason this limitation exists is that the underlying cloud platforms are completely different, and come from two companies that are competing with each other rather than collaborating in any way.

This makes is impossible for us to move content from a Kerika+Google account over to a new Kerika+Box account, even if they are owned by the same user, since even if we tried to move over all the cards, boards and canvases, we wouldn’t be able to automatically move over any related files.

Sorry about that 🙁

We released Kerika+Box today!

Kerika

At long last, and with considerable effort, we finished and released Kerika+Box: a seamless integration of Kerika with the Box cloud storage platform.

Kerika+Box works just like Kerika+Google, the old integration of Kerika with Google Drive: both offer a complete work management system that works seamlessly with your cloud storage platform of choice.

We are really excited about this new release; we have found that there are a ton of advantages to using Box as a cloud storage platform:

  • It’s free for personal use, which means it’s easy to get started.
  • You can sign up with an existing email address: you don’t need to get a new ID.
  • It’s got the best security and enterprise management features of any cloud storage platform out there.
  • The company is very accessible and offers great support.

We have also updated our website, to make it more responsive (i.e. display better on mobile devices), and we have included a number of customer profiles to give you an idea of the very broad range of people who are using Kerika.

Check it out!

Signing up for Kerika
Signing up for Kerika

 

Why we are integrating with Box, Part 9: Final QA

Government, Kerika, Usability, , ,

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

We have been doing internal testing (“eating our own dogfood”) of Kerika+Box for the past three weeks, and the results have been much better than we expected!

We have found very few bugs so far, which is great — it’s feels like a huge vindication of our decision to invest several Sprints in improving our internal QA processes, clearing the backlog of old bugs, and generally improving our software development processes with code reviews across the board, for even the smallest changes.

In other words, we didn’t move fast and break things: we moved slowly and broke nothing. Which makes sense when you have paying customers who rely upon your product to run their businesses…

Since Kerika makes it really easy to have multiple backlogs in a single account, we put all the OAuth and infrastructure work in a separate backlog, allowing a part of the team to concentrate on that work somewhat independently of other, more routine work like bug fixes and minor usability updates.

And, as before, put every feature in a separate git branch, making it easy to merge code as individual features get done.

Here’s what our Box QA board looks like, right now:

Box QA board
Box QA board

The user interface for Kerika+Box is essentially the same as for Kerika+Google, with a few quirks:

Box requires more frequent logins: Google provided us with relatively long-lived refresh tokens, so a user could close a Kerika browser tab and reopen it a day later and log right back in.

With Box, you are going to see a login screen much more often, along with a screen asking you to re-authorize Kerika as a third-party app that can access your Box account.

This is kind of irritating, but apparently unavoidable: from what we have found on Stack Overflow, Bug views this as a feature rather than a bug.

The other, really big difference is that files are edited offline rather than in the browser itself: when you click on the Edit button, you will end up downloading a local copy of the file, using Microsoft Office for example, and then when you do a Save of that file, your latest changes are uploaded automatically to the cloud.

Here’s what you see when you open a file attached to a card on a Kerika board, when you use Kerika+Box:

Example of opening a file within Box
Example of opening a file within Box

This works great most of the time, except when two people are making changes simultaneously: in that situation, Google’s in-browser editing seems a lot more convenient.

On the other hand, downloading local copies of files means that you get the full power of Microsoft Office, and we know that’s very important for some of our users, e.g. consultants dealing with complicated RFPs or government users dealing with official documents.

Performance also seems a little less than Google Drive, although we would stress that this is highly variable: while Google Drive files generally open within 1-3 seconds in a new browser tab, they can take much longer if Google’s servers are slow.

Overall, we are very pleased with Kerika+Box: we are planning to do all of our new development with this new platform, to continue eating our delicious dogfood 😉

The full series:

Why we are integrating with Box; Part 8: Our experience with Box (so far)

Kerika, Technology,

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

We have finished our development work on the Kerika+Box integration, and have started internal testing this week!

Our philosophy all along has been to “eat our own dogfood”: every new feature that we have ever built has been used internally, for real, by the Kerika team for its own product development and team collaboration. Since we are ourselves a distributed team, spread out between Seattle and India, it makes perfect sense for us to use Kerika to build Kerika 😉

Here’s what our Box integration testing board looks like:

Box integration testing board
Box integration testing board

We haven’t run into many problems so far: we did find one small bug in the Java Library for the Box Collaboration API, and we have been extremely impressed with the responsiveness of the Box team.

  • We first logged the bug at Github, where we had assumed (incorrectly, as it turns out) Box would want their bugs reported.
  • Having logged the bug, we pinged Indy Sen at Box, by Twitter and by email.
  • Indy responded within 15 minutes, on both Twitter and email.
  • Indy got us in touch with the API team at Box, and asked us to log the bug on Stack Overflow, where Box does its platform support.
  • We did that later in the evening, at 11:04PM.
  • Within 4 minutes a support engineer confirmed that the bug existed.
  • Later in the evening we asked a follow-up question, to confirm that our workaround was sensible.
  • The next day, before noon, their support engineer confirmed that our workaround was fine.
  • A couple of hours later, Peter Rexer told us they had fixed the bug and merged the code onto Github.

Now, admittedly, the bug was very trivial — a single misplaced character — but the responsiveness of Box as an organization just blew us away!

Contrast this with the experience we have had in the past with Google Drive, when problems would mysteriously appear and then disappear just as mysteriously, either the same day or several weeks later…

The full series:

Why we are integrating with Box; Part 7: Disentangling from Google

Kerika, Technology,

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

Having decided to add a second cloud platform, we had to go about the cumbersome, risky process of disentangling Kerika from its close embrace of the Google stack.

This has taken us several months, if we are honest about counting the entire effort and duration.

The first part of this was to create a more layered architecture: wherever there was a direct interface to a Google service, we had to create an intermediate shim that allow us to substitute the Google service with another.

And to be frank, when we first started work on Kerika in 2010, we hadn’t seriously considered the possibility that we would use any other cloud service so our architecture had become, over the years, more Google-focused than we had realized.

Disentangling from Google Contacts was the easiest step, and in fact we had already taken that break some time ago in response to users being fearful about Kerika accessing their Google Contacts.

In terms of login, however, things got much more complicated: we had originally integrated with Google using OAuth 1.0, and then later upgraded to OAuth 2.0 as OAuth 1.0 started to get deprecated.

In theory this meant that we could easily integrate with any other OAuth provider, e.g. Box, Facebook, Yahoo, etc.

But as we developed our long-term strategy and talked to prospective customers, it became clear that sooner or later Kerika would have to provide direct signup/sign-in, in addition to OAuth: a significant contingent of folks wanted to be able to sign up directly at Kerika.com rather than use existing credentials from Google, Box, etc.

(We are not quite sure why this is really advantageous for anyone, but the sentiment is real nonetheless.)

So, we decided to implement our own OAuth server, which would act as a gateway to OAuth servers from Google or Box.

This had to be implemented such that the entire sign-up and sign-in process remains unchanged: someone coming to Kerika.com would get redirected automatically to the correct authentication service, which could then redirect the user’s browser back to the Kerika application server.

And, obviously, the entire process had to be smooth, fast and completely transparent to the end-user: how we implemented multiple OAuth sign-ins wasn’t the user’s concern! This had to work really well for both free users of Google, e.g. folks with just a regular Gmail account, and premium users who had signed up for Google Apps for Business or any of its variants (for Government, Education, and Nonprofits).

Fortunately, we already gained experience in dealing with the complexities of browser redirects in enterprise environments, where any sloppiness in terms of using HTTPS, for example, can trip up security alarms in large organizations.

And, we had learned the hard way to look for various edge cases, like restricted domains — if someone from within a restricted domain tries to add someone from outside that domain, we need to trap that condition so that the user experience remains excellent, rather than landing anyone on some scary error page from Google!

The other major complexity was to normalize the service we provide, so that the user experience is equivalent for both Google and Box users.

An example of a “normalized user experience”: an existing Kerika, who uses Google Drive, decides to invite someone to join a project. At that time, we need to check whether the invitee is already registered as a Kerika user or not. If the invitee is already a Kerika user, we need to see whether that user is also using Google Drive.

If it turns out that the invitee has been using Box, we need to make sure the invitee is correctly prompted to switch from using a Google-based Kerika account to a Box-based account, so that she has all the proper access to the new project’s files. And this switch between accounts needs to be a single-click, to keep the Kerika user experience excellent!

Other examples: exceptions and error conditions as reported by Google and Box are very different, reflecting the peculiarities of each service. We need to make sure we capture all these and try to keep the end-user experience as smooth as possible. Fortunately, we had developed a great deal of experience managing exceptions generated by Google Apps, so we could bring all this to bear on our Box implementation.

To get all this right, we had to carefully plan a series of milestone releases that were done in parallel with our regular development: although the work was going to take several months to finish, we needed to keep supporting our existing users with critical updates, bug fixes and limited new product enhancements.

Fortunately Kerika lets you have multiple Scrum Backlogs in the same account, and that’s what we did: we created a separate, smaller Product Backlog consisting of just the OAuth work, and let that development run in parallel while we continued to draw down on our Main Product Backlog.

The OAuth work finally got done in four Sprints, each of which was organized as a separate Scrum Board.

As we came to our regular release cycles, we would pick up items that were complete, from either the OAuth Backlog or the Main Backlog, and merge these to create a new release package.

To get this right, we used git to the fullest, putting each feature into a separate branch so that we could retain the maximum flexibility in terms of what made it into a particular release.

Without this use of multiple git branches, our release cadence would have been tough to maintain.

The full series:

 

Why we are integrating with Box; Part 6: The Box Option

Kerika, Technology, ,

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

And this brings us to Box…

We first heard of Box through cloudPWR, a Kerika partner and long-time Box reseller: Shadrack White, Dennis Brooke, and Cullen Hower suggested to us (a year ago!) that we consider integrating with Box.

Shad and Dennis were both enthusiastic proponents of Box: they had done several implementations of Box, including a very interesting use-case for Washington State’s Liquor Control Board which found itself in the business of regulating medical marijuana this year.

And Dennis in particular has been a great proponent of Kerika: he had introduced it to some of his clients.

As we looked at Dropbox and OneDrive as possible alternatives to Google Drive, Box came up repeatedly in the conversations we were having with enterprises.

It was clear that Box was treated very seriously by some folks that we considered very smart and knowledgeable — a senior director at Amazon, for example, told us (off the record) that he considered Box to be the most enterprise-ready cloud storage platform — and so we decided to take a closer look at the Box platform.

We attended Boxworks in San Francisco last summer, and were immediately struck by the differences in tone and substance between Boxworks and DBX.

While Dropbox is a consumer-oriented company with a newly developed interest in the enterprise, Box is a very enterprise-focused company (with little or no interest in consumers).

We took a close look at the Box API, and were very pleased with what we found: Box’s API was very close to what we were getting from Google Drive, which meant that a Kerika+Box integration could offer a really good user experience:

  • If you add a file to a card or canvas on a Kerika project board, it will automatically get shared with everyone who is part of the project team.
  • People’s access to project files will be automatically controlled (and updated in real-time) based upon their roles: Team Members will get read+write access; Visitors will get read-only access.
  • There will be no need for users to manually adjust or manage permissions on any files: Kerika will provide a great contextual layer on top of the cloud storage platform.

Box has another great advantage: it doesn’t have its own proprietary format for storing Word, Excel, etc.  This is a big issue for many enterprises who would like to use Kerika, but don’t want to move away from Microsoft Office format.

If we can the great Kerika user experience, with an enterprise-class cloud service, and the convenience of Microsoft Office, we think we will have a winner on our hands!

So, from a technology perspective a Kerika+Box integration makes a lot of sense. But what about from a market perspective?

When we polled some of current and prospective customers, however, the reaction was somewhat mixed:

  • Folks who were knowledgeable about Box were very supportive. (Good!)
  • Folks who were already using Box were very enthusiastic. (Excellent!)
  • Unfortunately, too many people still haven’t heard about Box… (Not so good…)

Box’s biggest challenge at the moment is name-recognition: far too many folks we talked to confuse Box with Dropbox.

The name confusion vis-a-vis Dropbox is a pretty big issue that we are betting that Box can ameliorate on its own, and Box’s pending IPO should certainly help with gaining greater name recognition and a more distinctive personality in the marketplace.

We are also hoping to build good partnerships with Box resellers, like our friends at cloudPWR, who have long-standing relationships with enterprises that would be great candidates for Kerika’s work management tools.

The full series:

 

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

Kerika, Technology, ,

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