Category Archives: Kerika

Posts about Kerika, the company and its people

Whitelisting Kerika’s email notifications

In an effort to reduce the possibility of Kerika’s notifications ending up in your spam folder, we are making a bunch of changes: one that’s already gone into effect is that all notifications generated by Kerika — for example, when someone sends you a chat message, or you get your 6AM Task Summary email — will come from the same sender: notifications@mailer.kerika.com.

It would help us a lot if you whitelisted this sender email, either for your own personal email, or ideally for your organization’s entire domain.

Thanks.

 

We have improved our internal systems for managing users and accounts

This isn’t something that you will see, as a customer, but we have spent several months improving our internal systems for managing users, accounts, payments and invoices.

We used to do things in a very ad hoc way before, as we concentrated all our efforts on improving the Kerika app, but we realized earlier this year that we had reached the limits of ad hoc approaches and needed a lot more automation to handle growth.

Everything, pretty much, is now automated: our admin staff can quickly look up any any user or account, see which payments have been made (online or offline), and manage changes to accounts.

An improved way of moving boards from one Account to another

As part of our next release, which will include a new billing system, we will make it easier for you to move boards that you own to another account.

This can help in several scenarios:

  • If someone is leaving a team, it’s good practice to have their boards transferred to someone who will remain, so that ownership of project assets — the boards and all the content in the boards, including documents — remains with the team.
  • More importantly, it is good practice to stay away from having individuals own boards, and instead use service accounts to be the single Account Owner in your organization.

A service account is an omnibus account, typically set up with an email address like kerika@example.org, that isn’t associated with a single individual.  A service account will never quit, never get fired, or take a vacation because a service account is not a real person — it is simply an account/ID used to be the permanent, omnipresent, owner of project assets so that team turnover doesn’t disrupt anyone.

If you own a board, you can move it to another account, i.e. effective change its ownership, by selecting the board on your Account’s Home, and clicking on the Board Actions button which appears on the top-right corner of the board card:

Board Actions Menu
Board Actions Menu

This will bring up a small menu of actions that are available to us as the board’s current owner:

Board Actions
Board Actions

(Note: this menu can also be accessed using the right mouse button.)

When you select the Move to another Account action from this menu, we will present you with this new dialog box:

Move Board dialog
Move Board dialog

A list of “known collaborators” is presented to you by Kerika to make it easy to select a coworker with a single mouse click, but you can also move the board to someone else, who isn’t part of your current Kerika collaboration network.

If you type in an email address, Kerika will immediately check to see whether this email address is that of a known Kerika user, before letting you proceed further:

Checking if new owner is a Kerika user
Checking if new owner is a Kerika user

We think these improvements will make it easier for our users to manage their organizations boards, and move towards consolidated ownership for easier asset management.

Tripped up by an unkept Promise

As you know, Kerika is a Web Application: everything runs inside a browser, without the need for any plug-ins or add-ons.

We achieve all this with a ton of JavaScript code (and a sprinkle of SVG, for our Whiteboards.)

One, significant, disadvantage of JavaScript is that it is “single threaded”: two bits of script cannot run at the same time; they have to run one after another.

So while Kerika is running inside a browser on your laptop, our JavaScript has to share a thread with lots of other stuff that’s going on, such as painting, updating styles, and handling user actions.  All of this has the potential to slow down Kerika, while the JavaScript code waits for something else to finish.

To get around this, we used JavaScript’s Promise function: this let Kerika’s code get going with its normal business while waiting for other browser functions to finish.  What we didn’t expect, however, was that the Promise function isn’t supported by Internet Explorer 11. (Although it is supported in Microsoft’s Edge browser.)

This caused problems for all of our Internet Explorer 11 users — people using Chrome, Safari, Firefox or Edge were unaffected.  We finally figured out what the underlying problem was, and did a workaround using a polyfill, which is a way to provide new functionality in older browsers that don’t support it natively.

Making it easier to know when Kerika has a new version

The Kerika team works in 2-week Sprints, but not every Sprint results in a feature being deployed to production: sometimes we have to wait for enough pieces to be built before we can release an entire feature.

(Bug fixes always get deployed at the end of each Sprint, and we we aim to have zero known bugs at all times.)

If you left Kerika running overnight in your browser while we rolled out a new version, it’s important to make sure your browser updates itself to get the latest software from our server.

To make this easier, we are introducing a notification inside the app that will let you know that you need to reload/refresh Kerika to make sure you are working with the latest version. This notification appears only when we have a new version deployed, and we can detect (or suspect) that your browser is running outdated code.

This is what the notification looks like:

New version notification
New version notification