Kerika+Google, our integration with Google Drive, and Kerika+Box, our integration with Box, are very similar in terms of user interface, but the underlying cloud storage platforms are different in some subtle ways.
One of these has to do with the way images that are added to a canvas are named: when you add an image to a canvas, either by using the Upload button or simply by dragging and dropping the image from your desktop onto the canvas, Kerika will show a small thumbnail of the image on your canvas.
The thumbnails provided to Kerika by Google are better than those provided by Box in a couple of ways:
Box’s thumbnails are square, which can result in a cropped view of the image; Google’s thumbnails show the entire image.
Google’s thumbnails can be resized nicely on the Kerika canvas, simply by selecting it and then dragging on one of the corners; Box’s can’t.
If you rename a Google thumbnail and take off the original file extension, e.g. you rename “picture.jpg” to be just “picture”, the thumbnail still renders correctly, but Box’s doesn’t. (Because Box relies on the file extensions to detect the file’s MIME-type.)
There are some other quirks with the way Box and Google work, but most of them are going to be invisible to most Kerika users.
We have been trying out Google’s new domain management service for the past month, and we are impressed.
(Caveats: this service is in “beta”, whatever that means in Google-speak; it is available only to people in the U.S.; it doesn’t handle every one of the new top-level gLTDs — yet.)
But for all that, Google’s simplicity of UI and the overall user experience is way betterthan what we have seen from Register.com, GoDaddy, NameCheap, and a bunch of others.
In many ways this reminds us of Google in 1999, when it’s very simple search engine was a welcome contrast to the muddled portals offered by companies like HotBot, Lycos, and AltaVista.
Everything extraneous has been stripped out, and the process of transferring and managing domains has been made very clear even for non-technical people.
Folks like GoDaddy have a very short window of time to, literally, clean up their act before Google mows them down.
Google Apps has created a Bizarro World for some of its premium customers, and in the process is doing really bad things to its ecosystem of independent software vendors (ISVs) like Kerika.
Two questions come to mind:
Do they know?
Do they care?
First, an explanation of how this Bizarro World came about…
Google Apps has a lot of free users — anyone with a Gmail or YouTube account, for example — but they also have several million business users who pay around $5 per user, per month, to get “Google Apps for Business” (which is also variously rebranded as Google Apps for Government/Education/Nonprofits…)
It used to be that any Google user could easily try out an app like Kerika that uses a Google ID for sign-in, and Google Drive to store files.
This was a pretty good arrangement, and among other things it encouraged ISVs to integrate with Google Apps — which helped Google in it’s “all your base are belong to us” goal of world domination.
Last year, however, they made a significant change: premium users of Google Apps can now only try out new apps like Kerika if their Google Apps Admin permits it.
In other words, no more experimentation, exploration, discovery…
Instead, we have the quite deliberate creation of a bureaucratic bottleneck (justified by the always useful umbrella excuse of “this is better security”?) where every user in every organization that wants to try out Kerika must first find out who their Google Apps Admin is — which is no easy task, if your organization consists of several tens of thousands of employees! — and then get them to approve the use of Kerika by everyone within the organization.
This is simple enough if your organization is small — you can easily contact your Google Apps Admin — but what happens if, say, you work in a university with 30,000 other people in that Google domain?
We have been finding out the hard way that Bizarro World hurts: the Google Apps Admin at one university has been working for over 6 months to reconcile Google’s demands with the university’s own policies.
Because…
Only the Google Apps Admin can approve use of Kerika.
The university prohibits system administrators from entering into any agreements — all licenses and agreements can be accepted only by the Purchasing Department.
No one in the Purchasing Dept is a Google Apps Admin, since this is an IT function that has nothing to do with purchasing.
Does Google know this is happening? Yes, they know.
It actually affects two large universities right now that are interested in trying out Kerika — each university has a population of about 30,000 people, so, yes, Google does know this is a problem.
And, we have
Does Google care? Apparently not.
The Google Apps Admins at these universities cannot get any kind of help from Google, and we at Kerika have directly brought this to the Google folks and not heard anything either.
When you first use Kerika, your browser has a reassuring sign that your connection to our servers is being encrypted:
No warning when you first use Kerika
But as soon as you open a card that contains any attachments, e.g. files stored in your Box account if you are using Kerika+Box, this reassurance would disappear, and instead you would see a warning about “Mixed Content”, which basically means that some of the data shown on your Kerika page was coming from a source that wasn’t using HTTPS.
Why there is a mixed content warning
This was because of a small bug in how we were dealing with the thumbnails we got for files stored in your Google or Box account: for faster performance we were caching these on our own Amazon S3 cloud storage (so we wouldn’t have to keep getting them from Google/Box every time you open the same card.)
It turns out that we weren’t fetching the thumbnails from S3 using HTTPS, which meant that as soon as you switched to the Attachment view of a card, your browser’s address bar would show the “mixed content” warning.
There was no real vulnerability resulting from this, but it did interfere with the user experience for that minority of users who like to keep a sharp eye on their browser’s address bar so we have fixed that with our latest release.
Now you should always have the warm reassurance of seeing the green secure site symbol on your browser when you open a card!
One of our users in Massachusetts alerted us to a bug in the export function that we have fixed with our latest release: it turns out the export function wasn’t correctly preserving the sort order of cards within the column, which was a nuisance.
Bug fixed, and as always, our thanks to our users for providing valuable feedback!
Here’s one of the weirder bugs we ever fixed: it turns out that there is a tiny grey dot in the middle of every canvas on a Whiteboard.
Grey dot in the middle of the canvas
It’s been there for a while, ever since we introduced some animation to make it easier for people to understand that canvases can be embedded inside cards on Task Boards and Scrum Boards, as well as being used independently on Whiteboards.
But the funny thing is that none of our users, nor anyone on our team, noticed it because too many of us, it seems, eat in front of our computers all too often, so our screens are flecked with little bits of food debris most of the time :-)
One of our team members finally noticed it after assiduously cleaning his computer screen, and that’s how we discovered there was an HTML element there, with a zero size and absolute position at the center of the canvas (to help with the “exploding” animation effect when a canvas is opened).
Although this element has a height and width of zero, it also has a 1 pixel wide solid grey border, which is used in the animation.
And that’s what appeared as the tiny grey dot in the middle of the screen: one pixel of grey border, not any debris from our lunch.
We have enhanced our recently introduced Archive feature, so that you can now copy a current project and paste a copy directly into your Archives:
Go to your Home Page
Select the project you want to backup
Click on the Copy button that appears on the top of the Projects column (or use the right-mouse-button)
Go over to the Archive column, also on the Home Page
Click on the Paste button that appears on top of the Archive column.
Copying a project
One possible use-case for this, that some of our users have asked for, is to do quick backups that “capture current state” of important projects.
As with anything else that’s in the Archive, the copies you paste there are frozen, and can’t be changed unless and until you drag them out of the Archive and into your Projects list.
Did you know that any Kerika canvas, whether on a standalone Whiteboard or attached to a card on a Task Board or Scrum Board, can be viewed as a regular Web page by folks who have been given access to the board?
Kerika automatically creates a version of your canvas that can be viewed without the Kerika application: you can get this version by using the Project Info dialog, or, more simply, by just changing the “m” in the canvas’s URL to a “c”:
Web page version of Canvas
Every Kerika page has a URL of the form “https://kerika.com/m/…”
The URLs are randomly generated and unique: every card, every canvas, every board has a unique URL.
The first part of the URL is always of the form kerika.com/m/… There’s no special reason for using the “m”; it’s just part of Kerika’s history.
But if you change the “m” to a “c”, like in the example above where “https://kerika.com/m/SRXk” becomes “https://kerika.com/c/SRXk”, then you can view the Web page version of the canvas.
In the Web page version there are no buttons or other indications of the Kerika software: it looks and works just like a regular Web page.
Of course, security is not compromised: you cannot view the Web page version of a canvas if you aren’t permitted to access the Kerika canvas itself.
When you copy or cut an item on a Kerika board — a set of cards, or may be some things sitting on a Canvas — these objects are placed in a special Clipboard that sits on the Kerika server, not in your browser.
This is important to note for several reasons:
Because the Clipboard is on the server, you won’t lose the items if your network connection breaks before you have a chance to paste whatever you cut.
The Clipboard will hold on to the items for 20 minutes, to give you time to think about where you want to put them. (And, to recover from any network problems you may have experienced.)
If you don’t paste something that you had previously cut, the Clipboard “releases” it back to where it was originally, after waiting 20 minutes to go by while you ponder. But, if you are impatient, you can reverse your cut action sooner simply by clicking on the cut items, which continue to appear in a faded (greyed-out) appearance on your board.
Because the Clipboard is on the Kerika Server, other team members won’t see the change until you actually do the paste. So, for example, if you have cut some cards from a Task Board or Scrum Board and haven’t pasted them yet, your project team members will continue to see the items on the old board until you complete the paste.
And, finally, here’s a great feature, thanks to the Server Clipboard: one of your team members can be making changes to a card while you are in the process of cutting-and-pasting it, and those changes aren’t lost. That’s because the object is stored on the server rather than your browser, making it possible for your team members to make changes even as you are in the process of doing a cut-and-paste.
We had problems occasionally with our servers running reliably, and if you were unlucky you may have noticed this.
Well, it took a very, very long time but we have finally figured out what’s happening.
It turns out that the garbage collection function on the Java Virtual Machine that runs our server software (all on a Linux virtual machine running on Amazon Web Service) was having problems: most of the time the garbage collection runs just fine on an incremental basis, taking up only a fraction of a second of CPU time, and periodically the JVM would do a full garbage collection as well.
The problem we are facing is that sometimes this full garbage collection would fail and immediately restart.
In the worst-case scenario, the garbage collection would start, fail and restart over and over again, until the server basically thrashed. And each time the full garbage collection ran, it took 5-7 seconds of CPU time (which is a really long time, btw).
We are trying to understand the best long-term solution for this, but in the short-term we can mitigate the problem in a variety of ways, including upgrading our server virtual machines to have more RAM.
One reason it took so long to debug is that we were chasing a red herring: we had noticed network spikes happening frequently, and we wrongly assumed these were correlated to the server’s CPU load spiking, but this turned out to be coincidental rather than causal.
