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
This will bring up a small menu of actions that are available to us as the board’s current owner:
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
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
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.
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.
The Box Platform has some limitations that you may bump into:
Certain characters are not allowed in file names, e.g. “/”. We noticed people were running into this problem, most probably because they were hitting the wrong keys inadvertently when renaming files.
Kerika is going to take of this silently from now on: if you try to rename a file using a character like “/” that Box can’t handle, Kerika will silently ignore that character in your renaming action.
File names can’t be more than 260 bytes. For people using English and similar languages, this generally means a file name cannot be more than 260 characters (with each character requiring one byte of storage). But for most Asian languages, e.g. Thai or Japanese, one character may require two bytes of storage, because the size of the alphabet is much larger than the Roman alphabet used by English.
This means that in some languages, file names may have to be much shorter, depending upon how many bytes are needed for storing each character, which in turn depends upon the size of their alphabets.
Some folks from Thailand were running into this problem: Kerika will start detecting this better, and provide more useful error messages
We fixed a bug recently that affected the Views feature: when a board was moved from one account (owner) to another, it wasn’t getting included properly in the Views for the new owner.
We recently got hit by spammers signing up as Kerika users, using fake emails from domains like mailinator.com, which seems to exist principally to help people do bad things on the Internet.
After signing up, these spammers (who seemed to be based in the Philippines) would invite hundreds of people with accounts on Tencent’s qq.com service in China. This would result in invitations being sent to these qq.com people to join the spammers on their Kerika boards.
To avoid a repeat of this problem, we are using Google’s reCAPTCHA in “silent” mode, on our signup and login pages — for people who sign up directly with Kerika using their email addresses.
This doesn’t affect the majority of our users, since most people sign up using their Google or Box accounts. And because the reCAPTCHA works silently, it shows up only when Google has reason to doubt that the person at the keyboard isn’t human.
Thanks to a longtime user from Poland, we discovered — and fixed — a bug that crept into one of our recent feature enhancements, where items couldn’t be permanently deleted from the Trash column on Task Boards and Scrum Boards.
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 zeroknown 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.
Kerika offers a great deal of control over how each board is shared:
A board can be made public to everyone. This makes sense for open-source projects and many nonprofit and advocacy groups, where the goal is to get maximum visibility and publicity rather than to hide the details of what the project is about.
Making a board public means that anyone who has the URL of the board can view it, even people who are not Kerika users. Note: we are talking about viewing the board; viewing doesn’t mean anyone who isn’t part of the board team can make changes.
If a board is viewable by the public, it can be found by anyone using Kerika’s search function.
A board can be viewable by everyone who is part of the account team. This is the default setting, and it makes a lot of sense for most organizations: you want your coworkers to be aware of what your team is doing, unless the project is particularly sensitive.
As people get added to individual boards, they are also automatically added to the account team. When someone is removed from every board owned by an account, they are automatically removed from the account team as well.
As with public boards, described above, we are talking only about viewing, not changing: only people who are Board Admins or Team Members on a particular board’s team can make any changes to that board. (And, of course, the Account Owner who owns the board.)
If you use Kerika’s search function, you can find boards that are being shared with the account team, provided you are part of that particular account team.
A board can be kept private. This means that only the people who are listed on the board’s team — as a Board Admin, Team Member or Visitor — can view the board. (And, of course, the Account Owner who owns the board.)
This is appropriate for any sensitive projects, e.g. stuff related to personnel matters or confidential contracts.
Private boards can’t be found by Kerika’s search function either, and it doesn’t matter if you know the URL for the board: only the specific people listed on the board team can see anything related to that board.
For each board owned by an account, the Account Owner or Board Admins can manage the board’s team: decide who is part of the team, and what sort of role (Board Admin, Team Member, or Visitor) each person has.
Board Admins and Team Members can make changes to all the items on the board, including any documents attached to the board.
Visitors have read-only access to the board and all its documents.
A person’s role can be changed at any time by the Board Admin or Account Owner: the effect is immediate, and extends to all the documents associated with the board as well regardless of whether you are using Google or Box for your file storage, or whether you are storing your files with Kerika.
A board’s team and current privacy settings can be viewed by clicking on the Team button that appears on the top-right of the Kerika app, when viewing a board:
Board Team button
Clicking on this button brings up the Board Team dialog:
Board Team dialog
Each person who is part of the Board Team is listed in this dialog, in alphabetical order along with their role.
At the bottom of the dialog is the board’s current privacy setting: in the example shown above, the board is being shared with everyone who is part of this user’s account team. (We have obscured the URL in the screenshot for security reasons.)
If you are a Board Admin or the Account Owner, you can change the privacy of the board using the Change Privacy link that’s shown on the bottom of the dialog:
Board Privacy options
So, every board can have it’s own privacy settings: private, shared with account team, or public.
When you are viewing the boards in an account, Kerika shows clearly what the privacy setting is for each board:
Privacy settings, at a glance
If you are part of someone’s account, you will be able to create new boards in that account: you will automatically be a Board Admin on those new boards, but the owner will always be the account you are working in.
You can set your privacy preferences for each account; this will determine whether new boards you create are automatically shared with your coworkers or not:
Privacy preferences
All your preferences can be set at https://kerika.com/preferences. The default setting is Share with Account Team, which works well for most people, most of the time.
We did an update yesterday that included a bunch of minor bug fixes and usability tweaks. (It also included a ton of behind-the-scenes improvements to our architecture and product development processes, but if we did our job well you shouldn’t see any of that change…)
When the Kerika server is being updated (to a newer version), your browser will no longer keep trying to reconnect while this is underway.
We have some code in place to help fix broken network connections: if your browser can detect that it’s connection to the Kerika server is broken for any reason (usually a network error), the browser will automatically attempt to reconnect.
This doesn’t make sense if the server is down for planned maintenance.
If you are working in multiple accounts and you decide to switch between them, we offer your choices in a more logical way: all the account owners you are connected to are listed alphabetically, and then each account owned is listed alphabetically.
Our previous display was kind of random making it hard to scroll through a long list of accounts. This affected only a very small number of users who were working on many different accounts, but still…
Now that we are encouraging our customers to converge around service accounts, we are trying to make sure these service accounts don’t get too crowded from the perspective of any single user.
We have always had the ability to “favorite” some boards (and templates) so you can have your own personal, curated list of boards that you care about — and so you can ignore the rest — but now we have made it easier for Board Admins to move their boards to the trash or archive (or to restore them later) so they can help keep the commonly-shared service account in a more useful and relevant state for all the users within that account.
A really small thing, but we decided to change the Sort by Status feature on our Task Boards and Scrum Boards so that On Hold cards appear at the bottom of the column, below all the others.
Bug fix: if you changed the name of a board using the Board Settings dialog (assuming you are one of the Board Admins), the new name is now reflected immediately in the breadcrumbs.
If someone who is currently a Team Member on your Task Board or Scrum Board is made a Visitor, he/she will not be removed from the current card assignments. This makes it easier to change your mind if you decide you want that person to be a Team Member after all: just change this person’s role in the Board Team dialog, back to Team Member, and all the old card assignments will be there.
We are adding a new feature for cards on Task Boards and Scrum Boards: in addition to sorting by date, person, status, and alphabetic order, you can sort by priority as well:
