All posts by Kerika

About Kerika

Kerika is the only task management tool that's designed specially for global, remote teams.

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

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

 

More fonts for Whiteboards

Technology, Usability

We have expanded the selection of fonts that are available for Whiteboards and canvases:

New fonts
New fonts

The list of available fonts now includes:

  • Arial
  • Armata
  • Audiowide
  • Calligraffiti Regular
  • Cinzel
  • Dancing Script
  • Indie Flower
  • Josefin Sans
  • Kaushan Script
  • Lato
  • Lobster
  • Montserrat
  • Nothing you could do
  • Oswald
  • Pacifico
  • Permanent Marker
  • Pinyon Script
  • Raleway
  • Rock Salt
  • Shadows into light
  • Times New Roman
  • Verdana

 

Heartbleed: no heartache, but it did prompt a complete security review

Kerika,

So, here’s how we dealt with the Heartbleed bug…

We learned about the bug just like you did: through news reports early on April 7th. Heartbleed was a “zero-day” bug, and the OpenSSL team put out an updated (patched) version of the OpenSSL protocol the same day, which meant that everyone, everywhere, had to scramble to get their systems patched as quickly as possible.

(And the bad guys, meanwhile, scrambled to grab sensitive information, with the Canadian tax authorities being among the first to report that they had been hacked. Of course, “first to report” isn’t the same as “first to actually get hacked”. Most people who got hacked either never found out, or never said anything…)

Kerika uses OpenSSL too, and our immediate concern was updating the Elastic Load Balancer that we use to manage access to our main Amazon Web Services (AWS) servers: the load balancers are where OpenSSL is installed; not on the Web servers that sit behind the load balancer.

Using Amazon Web Services turned out to be a really smart decision in this respect: Amazon just went ahead and patched all their load balancers one by one, without waiting for their customers to take any action. In fact, they patched our load balancer faster than we expected!

Patching the load balancer provided critical immediate protection, and gave us the time to do a more leisurely security review of all our operations. This was long overdue, it turned out, and so we went into “housecleaning mode” for over a week.

One part of this, of course, was updating all our Ubuntu Linux machines: Canonical Software was also very prompt in releasing a patched version of Ubuntu which we loaded onto all of our development, test, and production services. So, even though the OpenSSL vulnerability had been patched at the load balancer, we also applied patches on all our development, test and production servers even though these couldn’t be directly accessed from the Internet.

Next, we decided to clean up various online services that we weren’t actively using: like many other startups, we frequently try out various libraries and third-party services that look promising. We stick with some; others get abandoned. We had accumulated some API keys for services that we weren’t using any more (e.g. we had a YouTube API key that no one could even remember why we had gotten in the first place!), and we deactivated everything that wasn’t actively been used.

Closing unneeded online accounts helped reduce our “attack surface”, which adds to our overall security.

And, of course, we changed all our passwords, everywhere. All of our email passwords, all of our third-party passwords. All of our online passwords and all of our local desktop passwords. (On a personal level, our staff also took the opportunity to change all their banking and other online passwords, and to close unneeded online accounts, to reduce our personal attack surfaces as well.)

We got new SSL certificates: from Verisign for our production load balancer, and from GoDaddy for our test load balancer. Getting a new SSL certificate from Verisign took much longer than we would have liked; getting one from GoDaddy took just seconds, but on the other hand, Verisign does have a better reputation…

We reviewed our internal security policies and procedures, and found a few places where we could tighten things up. This mostly involved increased use of two-party authentication and — most importantly — further tightening up access to various services and servers within the Kerika team. Access to our production servers is highly restricted even within the Kerika team: we use AWS’s Identity & Access Management service to restrict access using roles and permissions, even within the small subset of people who have any access to the production server.

Finally, we are adding more monitoring, looking out for malicious activity by any user, such as the use of automated scripts. We have seen a couple of isolated examples in the past: not malicious users, but compromised users who had malware on their machines. Fortunately these attempts were foiled thanks to our robust access control mechanisms which manage permissions at the individual object level in Kerika — but, like every other SaaS company, we need to be vigilant on this front.

All of this was good housekeeping. It disrupted our normal product development by over a week as we took an “all hands on deck” approach, but well worth it.