Maybe this isn’t obvious after all… We just realized that a long-time Kerika user (over 3 years of using Kerika on a daily basis!) didn’t know that there is a right-click menu available in Kerika!
If you move your mouse over a card on Task Board or Scrum Board and press the right mouse button, this is what you will see:
Right mouse menu
This menu is handy for selecting all the cards in a column, which you can then grab and drag over to another column or even mark as Done.
We have been working on some designs and ideas for a “Dashboard” feature in Kerika for many months now. Actually, a couple of years now.
Along the way we convinced ourselves many times that we had solved the problem in an ideal way.
At other times, we convinced ourselves that there was no way to solve a particular aspect of the problem, so our obviously ugly solution was the best possible solution.
Looking back on all these iterations, it’s very humbling to think about how easy it is to think something is perfect, until something better comes along — at which point the old thing is suddenly, unbearably ugly.
In other words, the ugliness of each design is obvious, in retrospect.
So everything we are proud of today: we will be ashamed of in a couple of years…
When you add files to your Kerika+Box projects, either as attachments to cards on Task Boards or Scrum Boards, or on canvases and Whiteboards, these get stored in your Box account.
If you have a premium (enterprise) version of Box, you can directly download these attachments, instead of having to go through Box’s preview display first: just hover over an attached file, and you will see a “download” button appear:
Directly downloading files from Box
This works fine for enterprise users of Box, but if you are using the free version of Box, you will see a Box error page, like this:
The news that Lenovo pre-installed adware on all consumer laptops sold in the US for the last three months of 2014 (yup, that would be the Thanksgiving through Christmas prime shopping season of the year) is being sadly under-reported by the mainstream press, although the tech press has a better idea of just how much mischief Lenovo did.
The really outrageous point here isn’t that adware came along with the other bloatware that all Windows users suffer from: it’s the fact that this adware was deliberately designed to undermine SSL, which underpins all security on the Internet.
Here’s how SSL is supposed to work: if you connect to Kerika, you are using a secure, encrypted connection to somebody that you genuinely believe is Kerika, Inc. of Issaquah, Washington, United States.
But how do you really know that it’s Kerika on the other end, and not someone pretending to be Kerika?
The only reliable way is to click on the lock icon shown in your browser (whenever you are on a secure SSL connection to any website), and your browser will then tell you who you are connected to, and more importantly, why the browser believes you are actually connected to Kerika and not somebody pretending to be Kerika.
Kerika SSL certificate
The image above is the actual SSL certificate shown when you connect to Kerika, and then click on the lock icon in your browser.
It says, in effect, that a company called Symantec Corporation is the one that vouches for Kerika’s identity: in other words, it is Symantec Corp. that is assuring you that it really is Kerika that you are connected to, and not somebody pretending to be Kerika.
These SSL certificates could be issued by anyone, for example Facebook relies upon a company called DigiCert:
Facebook SSL
And Bank of America relies upon a company called Verisign:
Bank of America SSL
Unless you happen to be using a Lenovo computer that you bought last Christmas, in which case there is a “man-in-the-middle” that you weren’t aware of:
Lennovo’s fake SSL
(Above image captured by security researcher Kenn White, @kennwhite)
On this Lenovo computer, an adware company called “Superfish” is the one that’s vouching for Bank of America, which isn’t right at all!
This is a classic “man-in-the-middle” attack scenario: most people would see the lock appear on the browser when connecting to a secure website, like Bank of America’s, and assume that they are safe. Instead, their communications is actually being intercepted by Superfish before it gets to Bank of America.
(And, by the way, this is pretty much how most Windows PC manufacturers make money: there is so much price competition in the Windows market that they all resort to bloatware and adware to juice up their profit margins…)
And because the same piece of adware was distributed on literally thousands of machines, the same private encryption key is being used on all of these machines, which makes it easy for people to use these bogus SSL certificates to create man-in-the-middle attacks on any number of banks and other secure websites.
We are starting to realize that a card’s status, e.g. “Ready for Review,” “Needs rework,” etc. is pretty important not just in terms of what they show about a card’s current state, but also in terms of its history.
Previously, we weren’t tracking changes to a card’s status as part of the card’s history; without our latest release, that’s now a feature, so if you are wondering who put a card “On Hold”, you can just open the card’s History and Kerika will tell you:
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!