The emails you get from Kerika, e.g. when someone assigns you to a card on a Task Board or Scrum Board, have gotten better:
The formatting is better: neater, cleaner, and there’s less verbose junk.
They are all sent from the same Sender Email — notifications@kerikamail.com — so your mail clients (like Gmail) do a better job of clustering them in your Inbox.
They all have better footers, explaining why you are getting the email, and how to contact us. (In other words, they are better at conforming to the CAN-SPAM Act.)
They look better on mobile devices: the subject headers are easier to scan, so if the email is something you expected, it is easier to delete it unread.
We eliminated the use of our logo, which saves (every so slightly) on bandwidth, especially on mobile devices.
We found and fixed a problem that a small number of users were experiencing: if you had a lot of boards open at the same time — say around 40 — and you then used the URL of any of these boards in some context, e.g. by including it in a chat message, you could run up into a “502 Bad Gateway” server error.
This really was an unexpected edge case — we had never considered that people might be working on 40 boards at the same time, nor that they would routinely have so many boards open, but it turns out that for professional services firms that use Kerika to manage their different client engagements, this was actually not that unusual…
The underlying problem was obscure: Kerika uses a cookie to keep track of which boards you currently have open.
This helps us restore your session perfectly if you exit Kerika and then return, e.g. by simply closing your browser or actually logging out and logging back in.
In the scenario where a user might have had 40 boards open, the cookie was becoming really, really large (as far as cookies go), and our Web server wasn’t set up to handle such large cookies.
We found and fixed a minor bug: if you personalized your Kerika account by adding a photo — something which we highly recommend, by the way — we had some unsightly cropping of the photo if the aspect ratio of your photo wasn’t perfectly square.
Some sites like Kerika.com use HTTPS all the time: every URL reference, whether to our website, within our application, or even to any article on this blog is automatically converted to a secure HTTPS session.
(We are not the only ones doing this: type in “facebook.com” in your browser’s address bar, for example, and you will be automatically redirected to “https://www.facebook.com/” even though you didn’t type in “https”.)
Always using HTTPS is good security practice, but it can sometimes lead to problems for users: unless you are very familiar with a particular site, and also the type of person who plays close attention to these things, you might not understand this process.
And even if you did, you would still find it convenient to make short references to “kerika.com” (or “facebook.com”) instead of typing out “https://kerika.com”.
When you include a URL in any part of a Kerika board’s contents, e.g. in a card’s details, it’s chat or its attachments (and the same goes for canvases), Kerika tries to get the title of that Web page so the URL reference is easier to read.
We found and fixed a bug related to this: in situations where the URL, as typed by the user, actually resulted in a redirect from the referenced website (typically a “301 permanent redirect” rather than a “302 temporary redirect”), Kerika wasn’t properly showing the Web site’s page title.
We discovered recently, to our considerable annoyance, that it is possible for AdBlock to mess up our website in a really serious way, even though we don’t serve up any advertisements of any sort (and never have.)
Here’s what was happening: when you use AdBlock, you have the option to add various lists of advertising sources. (You can find them here.)
One of these lists is from someone called fanboy.
If you subscribed to fanboy’s EasyList, for example, Kerika’s sign up page would not display the buttons for Kerika+Google and Kerika+Box:
(The same problem showed upon the Login page as well.)
It turns out that the EasyList filter uses JavaScript classes called social-media-header’ and social-media-button,social-button and soc-button which were also the names of classes that Kerika was using.
The conflict caused Kerika’s signup and login buttons for Kerika+Google and Kerika+Box to not appear for Chrome and Firefox users who had AdBlock installed.
It took a while to figure out this was the cause. We are not fans of fanboy.
A small bug fix we did recently: when you do an Export of data from a Task Board or Scrum Board, you get a notification from Kerika when the export completes: that’s because the export could potentially take a long time, if you had a very large board, i.e. with hundreds of cards on it.
(In practice, most exports take just a few seconds, so the notification comes very quickly after you start the Export.)
The notification comes in two forms:
By email, with a link to open the file containing your exported data.
In your Kerika Inbox, on the top-right of the Kerika application, looking like this:
There was a bug that clicking on the “Dismiss” button on Kerika Inbox didn’t make the notification go away: it would reappear after a page refresh.
Another great new feature: if you upload a file on any card, canvas or board with the same name as a file that’s already attached to that particular card, canvas or board, Kerika will automatically keep track of these as being different versions of the same file. This makes it even easier to organize all your Kerika project files.
There’s no limit to the number of files you add, nor any limit on the size of these files.
When you add a file, to a card, board or canvas, Kerika automatically uploads that file and shares that with everyone who is part of your board’s team. You don’t have to do anything: Kerika makes sure that all the Team Members have read+write permission, and all the Visitors have read-only permission.
These files are stored in your Google Drive, if you are using Kerika+Google, or in your Box account, if you are using Kerika+Box, or with Kerika if you have signed up directly with an email address.
That’s how Kerika has always worked; what we have added is an automatic versioning feature that checks when you add a new file to see if has the same name, and type, as a file that’s already attached to that particular card, canvas or board.
If the file name and file type match something that you have already added, Kerika automatically treats that new file as a new version of the old file, rather than as a completely different file. This makes it really easy to manage your Kerika project files.
Here’s an example: this card has a file attached to it called “Foo.docx”.
If a Team Member adds another file to this same card, also called “Foo.docx”, Kerika will treat that new file as a different version of the same Foo.docx, rather than as a completely different file:
Accessing these older versions is easy: if your Kerika files are in being stored in your Google Drive, you can get the older versions using the Google Docs File menu:
If your files are being stored in your Box account, you can access the older versions from the menu on the right side of Box’s preview window:
If you signed up directly with Kerika, you can access the older versions from within Kerika’s file preview:
Clicking on the Older versions of this file link on the top right of this preview will give you a list of all the old versions of this file that Kerika has:
So, that’s it: simple, easy, automatic tracking of multiple versions of your project files! Brought to you by Kerika, of course.
We quietly released a new feature a couple of weeks ago that we now want to announce to the world: you can have all your Kerika due dates appear automatically on your Mac, Outlook or Google Calendar!
All you have to do is go to https://kerika.com/preferences (or click on the Preferences link that shows up under your photo in the top-right of the Kerika app), and then click on the Start Syncing button on that page:
You can sync to your Apple/Mac calendar, your Microsoft Outlook calendar, or your Google Calendar.
Pick your preference, and Kerika will show you detailed instructions on how to start syncing.
Here, for example, are the instructions for syncing to your Apple/Mac calendar:
And here are the instructions for syncing to your Microsoft Outlook calendar:
And, finally, here are the instructions for syncing to your Google calendar:
You will notice that we have deliberately obfuscated the actual calendar URL for this particular user, in all three images above.
That’s important: your calendar URL is unique and precious — don’t share it with anyone!
As your cards on your Kerika Task Boards and Scrum Boards get new due dates, Kerika will automatically feed these updates to your personal calendar: you don’t need to do anything.
Kerika due dates always appear as “all day” events.
Please note that it’s up to Apple/Microsoft/Google to determine how quickly these updates show up on your calendar.
On your Mac Calendar, for example, you can set the frequency with which these updates appear by doing a right-click with your mouse on the calendar and selecting Get Info:
And then setting the “Refresh time” for that particular calendar. (On Macs, the fastest that iCloud allows is every 5 minutes.)
For folks who sign up directly with Kerika, we store the user password (in an encrypted form, of course), which means that these users can change their passwords directly from within the Kerika application by going to their My Account page at https://kerika.com/my-account:
For people who sign up using their Google or Box IDs, we rely upon Google/Box to manage their passwords: in fact, we never even see anyone’s Google or Box password, even for a second!
So, their My Account page looks a little different, like in this example of a Kerika+Google user:
Thanks to one of our users at Washington State’s Employment Security Department, we found and fixed a bug that was causing problems when users tried to add SharePoint URLs as attachments on cards, for Task Boards and Scrum Boards.
The problem turned out to be in some code we have that tries to check whether a user is entering a valid-looking URL. SharePoint’s URLs are somewhat unusual in that they include the “{” and “}” characters, which most other web servers don’t use.
Our old code was treating these characters as invalid, thereby rejecting URLs coming from SharePoint.
This has been fixed now.
Thanks!
This website uses cookies to improve your experience. We'll assume you're OK with this, but you can opt-out if you wish.AcceptRead More
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.