Why we need your Billing Information (and what we do with it)

If you purchase subscriptions, or do other actions like request a refund, Kerika prompts you to update your Billing Information:

Updating Billing Information
Updating Billing Information

This information is needed to complete a transaction:

  • Your name or organization (school, college, nonprofit, company, government agency…) are used to ensure invoices and receipts are addressed to the correct person (the purchaser).
  • Your phone number is needed to handle any problems we face processing your invoices or purchases.
  • Your address is used to create invoices and receipts, and to check whether we need to charge you Washington State sales tax.

At the bottom of this screen you can optionally include Billing Contacts: people who need to get copies of all your transactions, such as your organization’s Purchasing Department or outside accountants/bookkeepers.

We store this information securely: as you may have already noticed, all access to Kerika servers is done using SSL/HTTPS, and within the Kerika virtual network, our servers communicate with each other using SSL as well.

We never ask for your credit card information: we use Stripe to handle all online payments, and we never see your credit card at any time.

If you pay by bank check or electronic funds transfer, this information is handled by Bank of America:  details of these transactions, such as your bank information, are stored only at Bank of America and not stored on the Kerika servers.

A reminder: you don’t have to pay for Visitors

The rollout of our new billing system seems to have been smooth — so far, fingers crossed! — and with this you now get better controls over who is part of your Account Team:

Manage Users
Manage Users

Please note that you don’t get charged for Visitors: if someone is only a Visitor on your boards — i.e. is not a Team Member or Board Admin on any board you own — you don’t need to pay for this person.

It doesn’t matter how many boards this person “visits”.

Visitors do show up on your Manage My Team list in the Manage Users tab, so you are reminded that they have access to some, possibly all, of your boards, and you can remove a Visitor entirely from your Account in the same way that you might remove a Team Member or Board Admin.

 

So long, Internet Explorer 11

We cannot continue to support Internet Explorer 11 any more, for the simple reason that Microsoft itself doesn’t want to support IE 11 any more.

All of Microsoft’s browser focus is on their Edge browser, which means that as newer HTML5 features and standards get adopted by the browsers, these are going to show up in Edge, not IE 11.

And since Kerika is a pure Web app, one that requires you to download no software of any kind, including browser add-ons and plug-ins, we really need to make use of the latest HTML5 goodies that the browser vendors provide.

These goodies are going to be available only on Chrome, Firefox, Safari and Edge, and that’s where Kerika is gong to work best.

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.