How Kerika became zippy

With the new version you will notice that Kerika has become much faster on the desktop than previously: now any board, regardless of size, should load in under 3 seconds if you have a fast Internet connection.

With the old version this wasn’t true: the time to load a board was proportional to the number of cards (tasks) that were on the board, and while most users didn’t notice any lag, people who were using Kerika at a large scale, e.g. with boards of a thousand cards, would have to wait a while for the largest board to full open.

With our old code, every board was loaded sequentially column by column, starting with the leftmost column, and within each column every card was loaded before another column’s loading started.  This approach didn’t scale well, and the flaw of this approach became all to obvious when we built our mobile apps, which used a “lazy loading” approach.

To fix this, we rewrote the desktop app from scratch, an effort that took nearly nine months for our small team to complete, from design, implementation, testing and endless refinement.

With lazy loading the system prioritizes which cards to load, rather than trying to load all of them one by one.  If your board has 15 columns, for example, not all of these can be viewed at the same time: most displays will show just 5-6 columns at a time.  Kerika keeps track of which part of the board you were last viewing, and then intelligently loads the board from that point of view.

All the other columns are loaded only as the system senses you are going to need them: as you scroll to the left or right, for example, the system automatically (and quickly) fetches more columns into view. If the system does this fast enough, the user never realizes that her entire board wasn’t loaded at the very beginning, because no matter where she is looking, everything she needs is always in view.

We took a similar approach to loading columns with a lot of cards (tasks). Instead of loading all the cards that exist within a column — and these can number hundreds, for large boards — the system considers how many can be displayed at a time given the user’s particular device: laptop, desktop, tablet, or phone.

Having calculated how much of a column can be actually viewed by a user, the system loads just those many — and a few more in anticipation of the user scrolling her view of a column. As the user continues scrolling down a column, the system races to fetch more cards from the server so there’s never a gap in the user’s view.

But lazy loading alone wasn’t enough, we also had to deal with the speed at which a browser can display a bunch of cards. This speed varies by browser type, as well as device.  A low-powered computer, perhaps running an older browser, can’t render cards as fast as we need for the user to have a true real-time experience.

A more space-efficient layout for Task Boards

We have redesigned the Task/Card details dialog to provide a more space-efficient layout, so you can see more of what you need without having to scroll:

Screenshot showing the Task Details dialog
Task Details

What used to be vertical tabs for Details, Chat, etc., is now a compact horizontal tab; this frees up a lot of space to see the details of the tags.

The other big change we made is to make the Priority setting separate from other Tags:

Screenshot highlighting position of Task Priority field
Task Priority flag

Clicking on the star will bring up your task priority options:

Screenshot showing possible values for Task Priority
Task Priority

Cards are tasks, so we are renaming cards as Tasks

If you have a engineering background, you will be comfortable calling the items that show up on Task Boards as “cards” — a term that originated with Kanban production lines in Japan, and then found its way to Scrum boards everywhere.

But for everyone else, “card” is a somewhat obscure, even baffling term, and we would often get asked a fundamental question: “what should I put on a card?

To make this clearer to folks, we are renaming cards as Tasks, because that’s what a Task/Card is: something your team needs to get done.

This is really a cosmetic change: wherever you had previously seen the word “card” you will now see either “task” or the more generic “item”.  The ADD A CARD button, for example, is now ADD NEW TASK:

And what had previously been called “tasks within cards” (or sub-tasks), is now more simply called a Checklist:

Screenshot showing a Card's Checklist
Card Checklist

Again, this is a change in terminology, not a change in functionality, but we hope it will make Kerika easier for the wide variety of users we have across the world, ranging from companies and governments all the way down to schoolkids.

Moving entire columns of tasks (cards)

We have added a new function to let Board Admins and Team Members move an entire column of tasks (cards) with a single action, within a single board or across multiple boards in the same account.

The function can be accessed by from the  menu that appears as a pop-up when you click on the dots on the top of each column, as well as when you use the right-click mouse action on any cards:

Screenshot showing the Task Options menu
Move entire column

If you choose the Move to another column action, a pop-up dialog appears that lets you choose the column you want to move these cards to:

Screenshot showing the Move to Another Column dialog
Move to another column

If you choose the Move to another board action, a new dialog appears that lets you choose the board where you want these tasks to go to:

Screenshot showing moving cards from one board to another
Move to another board

After selecting a destination board, you can then pick the exact location of the column you are moving, relative to the columns that are already on that board.

And, as you can see, from the screenshot, you are also able to move columns from boards in one account to another account where you are also an Account Member.

Yes, we have updated our Log4J

We use Log4J mostly in our development environment, where we write new code; less so in our test environment, where we use our new code ourselves to make sure it works well (a philosophy known as “eating your own dogfood”); and only rarely on our production environment, which is where our users are.

That reflects the normal approach to debugging: you want to find problems well before they reach users.

And we are aware of the guidance from the United States Cybersecurity and Infrastructure Agency about a recently discovered critical vulnerability in the Log4J software. Naturally we acted promptly upon getting that news and updated our software on all our environments!

Tablet support

We have added tablet support for iOS and Android devices, as you can see:

The tablet experience is like that of the desktop, not the phone.

For the phone app we had to redesign a lot of the user interface to accommodate the limited screen space, but with most tablets today there is enough screen resolution to support the more extensive desktop experience.