Category Archives: Kerika

Posts about Kerika, the company and its people

Designed for, and built by remote teams

Our development team in India is under a national lock-down due to Covid-19, and we had been worried about a loss of productivity.

After a week of lock-down we have been checking with each person, and it turns out there was no cause for worry, especially from those who had the foresight to grab an extra monitor before leaving their office.

In fact, we expect that our team will ask for work-from-home as a regular work model even after the virus is gone.

Kerika is designed for, and built by remote teams!

Try to help the Government, get slapped.

Kerika has been a sponsor of the Lean Transformation Conference every year, since the very first conference. In addition to contributing sponsor fees, our founder and CEO, Arun Kumar, has given a presentation each year, on different topics related to the conference.

At the last conference (in October 2019), Arun gave a talk on Virtual Teams: what’s different about a virtual team vs. a traditional collocated team, and how a virtual team can be very successful if it adopts the right processes and tools. A total of 117 people attended, and 55% of them rated the presentation as “Very Useful” or “Extremely Useful”.

Kerika also paid for a professional videographer to film the presentation so it could be made available online for others.

The topic of Virtual Teams is particularly important today because the Covid-19 virus has hit the state of Washington hardest (in the US), and everyone, including the government employees are scrambling to adjust to telework.

You might think that the video would be particularly helpful to the state right now, since it covered precisely those topics that the state (and much of the world) is grappling with today:

The video that was…

Imagine our surprise then to receive, out of the blue, this takedown notice:

The video that wasn’t…

So the video is gone. A small business tried to help the state of Washington, but won’t try again.

Guarding against XSS code injection

We had posted earlier about making sure that (malicious) users cannot inject code into Kerika, in any of the areas where user input is possible.

Here’s the complete list of user actions that we are checking for XSS injecton now:

  1. Board Name
  2. Board Description
  3. Template Name
  4. Template Description
  5. Tag Name
  6. Card Attachment Name
  7. Board Attachment Name
  8. Card Chat
  9. Board Chat
  10. Column Name
  11. Task Name/Detail
  12. Canvas Text
  13. Canvas Attachment Name
  14. Canvas Shape/Object Name
  15. Account Name
  16. Account Billing Information
  17. User’s Name

Fixed: issue with showing thumbnails of pictures

With our most recent update (which was yesterday), we have fixed a problem with thumbnails of attached images not showing correctly. (Not always, but sometimes.)

Here’s what the problem used to look like:

Example of a missing update

As you can see, this card has two images attached. The first one doesn’t show a thumbnail properly (it has a standard “missing image” icon instead) while the second one works fine.

The underlying cause for this was a mismatch in the duration for which Kerika was caching the thumbnail of an attachment after it had first been retrieved from Google Drive, and how long Google Drive was keeping the thumbnail around.

So you never saw the problem when you first attached an image, but if you went back to the card after 30 days you would see the “missing image” icon instead.

We have fixed this. You may still see this if your browser is caching old thumbnails; you can completely eliminate the problem by clearing your browser’s cache, which would force Kerika to request new thumbnails from Google.

Why our new mobile app is taking so long to build

We have been working for months now on our new mobile app, and it has been a tough slog! We are building it entirely using React (a Javascript framework) to make it possible to have a single code base across both desktop and mobile devices, and across all operating systems.

We took some time learning to be good with React: previously we had used Polymer, and before that we used JQuery, so there was some learning curve to traverse while we figured out the right way to code in React. But we are beyond that now.

For the past couple of months, it is really performance that has been our bugbear. In the spirit of “eat your own dogfood before trying to sell it”, we are using the emerging mobile app for our own work on a daily basis.

The trouble is: our main Kerika board is huge: it has usually around 600 cards, and 26 columns. This isn’t best practice, by the way, and we are not recommending you create boards like this, but we are talking here about our main board that tracks many different ideas and initiatives, not just product development.

So, when using our mobile app for our own board, we hit performance problems that few of our users are likely to encounter. We could, of course, have written us off as an edge case and ignored the performance issues, because for smaller boards (e.g. with around 20-30 cards), these performance problems completely disappear.

But, we decided to bite the bullet and get our mobile app to be good even with boards that are as wide and deep as our main board. And we have learned a lot from that experience: for example, it wasn’t the number of cards, but the number of columns that had the bigger performance impact.

We have another board with over 2,500 cards in just 2 columns (essentially a historical record of old work items) and we didn’t experience performance problems in the same way as we did with 500-600 cards over 26 columns. In fact, we found that 2,500 cards in 2 columns was much easier to handle than the latter case!

So, a lot of our efforts over the past few months have been trying to handle performance for scenarios that are out of the norm.

We are doing our testing on both iOS and Android at the same time, to catch browser-specific issues early. (We have been less diligent about Firefox testing, to be frank, but we expect clearing iOS and Android issues will effectively cover Firefox as well, making our final testing easier.)

Our end goal is a single code base that runs on any device. Right now that’s not true: our desktop experience is still using (mostly) Polymer, while our mobile is entirely in React, but we are trying to make sure we design all of the new code to work well on the desktop as well, so that we can slowly replace parts of the desktop code as we build the new mobile app.

(It’s not that our desktop code has any problems today — we are very confident about the quality of our desktop user experience — it’s just that we are too small a team to be able to split ourselves into multiple sub-teams to support every platform.)

Here’s a composite view of what our mobile app looks like now: in “zoomed-in” view, in “zoomed-out” view, and card details:

Kerika's upcoming mobile app

Onwards!