All posts by user

Getting psyched for 2016!

Kerika

We have big plans for the next year, and, in fact, have been very busy through the holiday season as well working on our product roadmap.

2016 will involve a major rewrite of our software: first the back-end, to improve scalability and to also use newer technologies like containers that make for easier deployment, and then the front-end, which will make Kerika even easier to use — especially for people new to Kanban and Scrum.

2015 has been a great year for us: our registered users doubled, and so did the number of paying customers.

It has also been a great learning opportunity for us: we met in person or had long telephone conversations with a wide range of users and got an even better understanding of the problems we can address with our software.

What we have heard consistently from folks about why they like Kerika: “it provides really great functionality in a really simple system”.

Our focus on providing a simple, intuitive user interface rather than delivering raw power is winning people over.

As we plan our future roadmap, the key goals we want to achieve are:

  • Make Kerika easier for new users. “Power users” already love us, but we need to make Kerika even more accessible for people who are completely new to visual task management.
  • Avoid religion.  Too many of our competitors are dogmatic about how to implement Kanban or Scrum; we will continue to remain pragmatic and let people work the way they want, rather than insist that we know the only true path to project success.
  • Build solutions rather than tools. Some of our competitors focus on building as many buttons, “power-ups” and other bells and whistles. You know, because “if less is more, think how much more more could be…”  Our view is different: the smarter the system, the fewer the controls that need to be exposed and manipulated by the user.
  • First class mobile experience. We have not delivered this in the past.  To do this, we need to change our back-end and front-end infrastructure very signfiicantly, and we have made that financial commitment. Look for good stuff in 2016.
  • First class support, for all users. We get at least one unsolicited email every week from a user who is surprised by the level of support we provide, even to free or trial users.  We need to keep this up. (OK, so this has nothing to do with our product roadmap but we feel strongly about it so we thought we would emphasize this point…)

Thanks to all our users who have helped us grow so far. In a reversal of cards and gifts going from vendors to customers, here’s a lovely calendar and card we just got from one of our happy customers:

Calendar and card
Calendar and card

Bug, fixed: Confirmation emails were not working correctly

Kerika, Technology,

Our thanks to Larry Smith from EduTone who initially alerted us to a bug in the process of signing up as a Kerika user: the confirmation email sent by Kerika wasn’t working well, particularly if the user used any browser other than Chrome.

For example, clicking on the confirmation email and having Kerika open that link using Firefox or Chrome produced this kind of behavior:

Safari problem

The problem was related to a recent decision we made to use Polymer for parts of our website.

It turns out that Chrome had a different sequence for loading the Polymer components than other browsers.

In Chrome the sequence is

  1. webcomponent-lite.js
  2. element.vulcanized.html
  3. build.min.js
While in browsers like Firefox the sequence is
  1. webcomponent-lite.js
  2. build.min.js
  3. element.vulcanized.html

Our build.min.js file needed components that were loaded only when element.vulcanized.html was loaded, which meant that the sequence in which these files were loaded by the browser was important, and  different browsers were loading these files in different sequences.

We fixed this bug: Polymer has a method to ensure that all imports are ready before the page is rendered.

This has been part of the learning process for us as we adopt Polymer more for our website redesign (which is underway, and should be unveiled by Christmas), and also consider using Polymer to rebuild the Kerika app itself!

Timing is everything when you send email

Kerika,

We occasionally email all of our users, when we have released something significant in terms of functionality or usability improvements.

On average, we probably send these emails 2-3 times a year, although we release software updates much more often.

Not every software update is announced in a mass email, although all the improvements and changes are always noted on this blog: unless the changes were big enough to require some additional explanation, we prefer to let users discover the new features on our own.

What we have noticed with the last couple of announcements is that the timing of the email makes a very big difference in terms of how many people actually open and read the emails.

Here are the last two emails we sent:

Timing is everything
Timing is everything

 

The “Release 62” announcement was actually far more significant, in our opinion, than the more recent “Release 66” version, at least in terms of UI changes and new features.

But, the Release 62 announcement went out mid-day on a Monday, and it was largely ignored as a result: only 9.7% of people opened that email.

The Release 66 announcement, on the other hand, went out on a Saturday afternoon, and had nearly double the open rate.

We think the simple explanation is that there was less competition for our emails on Saturday afternoon: fewer emails from colleagues and fewer crises to attend to.

We had long suspected this to be the case, but never had such clear proof that timing is everything when you send email :-)

Google Apps last Friday

Kerika, Technology

It looks like we were on the bleeding edge of Google’s problems last Friday (Oct 9): fairly early in the day, Pacific Time, we started seeing authentication failures from Google related to our Kerika+Google users.

The exceptions shown in the Kerika server logs were clearly pointing to problems on Google’s end:

Google Errors
Google Errors

 

What was a little frustrating for us — and our beloved users — was that Google itself didn’t seem to be acknowledging any problems until fairly late in the day:

Oct 9 Google Apps status
Oct 9 Google Apps status

By this time — almost noon, Pacific Time — dozens of Kerika users had been affected. We tried to let folks know via Twitter that there was a problem, and continued to monitor the situation through the day:

Google eventually acknowledged the problem as it became clear that it was widespread.

By mid-afternoon, the issue was largely cleared up, at least as far as Kerika was concerned, although it is possible that other apps, which also use Google for authentication or Google Drive for storage, were affected for much longer.

Once again, our apologies for everyone who was affected.

Leaving chat, and then returning

Agile & Scrum, Kanban & Lean, Technology, Usability, , , ,

When you are writing a chat message, on a card or canvas on any Kerika Task Board, Scrum Board or Whiteboard, what happens if you need to leave that message in the middle and go look at something else in Kerika?

For example, suppose you are in the middle of writing a chat message, but in order to complete it, you need to go off and look at another card’s details, or maybe a file attached somewhere else on the board?

You can leave aside a chat in mid-stream, go somewhere else in Kerika, return to the chat, and pick up where you left off!

That’s because Kerika uses your browser’s local cache storage to keep your unsent message: it means your changes aren’t lost while you go look at something else in Kerika.

This is a handy usability fix we have always had in Kerika, but it may be one that folks didn’t realize existed…

Well, now you know :-)

Kerika is now a Box Pro Partner

Kerika,

We are pleased to announce that our technical collaboration with Box continues, and Kerika has now been named a “Box Pro Partner” reflecting the strong ties we have built between the two companies as we continue to integrate with Box’s cloud services :-)

Box Pro Partner
Box Pro Partner

Amazon burped a little on the weekend

Kerika, Technology,

We use a number of Amazon Web Services, including one called Simple Queue Service which Kerika uses to handle communications between our main project database server and a separate server that handles the Search function.

  • As with all search engines, Kerika’s Solr engine does a full indexing of the database only once: when the database is rebuilt for any reason (which happens very rarely), and after that it does incremental indexing which means that it only looks at changes made to individual boards, cards, and canvases.
  • Using a queue helps us manage the load of traffic going to the search engine server: in the unlikely event that a lot of people make a lot of updates to their Kerika boards at the same time, Solr won’t get overwhelmed with a sudden burst of new indexing.
  • There are lots of ways to implement queues in software — in fact, studying queuing theory is a standard course in all computer science programs — and at this point most apps, like Kerika, prefer not re-invent that particular wheel: instead, it is more cost-effective to use some standard queuing facility that’s available as part of the underlying platform.

AWS works very well in our opinion — it has very high reliability across most of its services — but like all software, it isn’t entirely infallible.

Over the weekend we observed a small handful of errors in our services logs where it looked like SQS had a temporary problem.

We cross-checked this time period with other activity on Kerika, and determined that about 7 Kerika boards may have been affected: not in terms of any data loss or corruption on the board itself, but in terms of some changes not being updated in the search index.

Now, 7 boards is a tiny portion of the entire Kerika project database, which numbers in the hundreds of thousands of boards, but we are glad to have spotted the potential for trouble and have re-indexed the data on these particular boards.

If we did our job well, no one will notice.

From Projects to Boards: a clarification

Agile & Scrum, Usability, , , , ,

We used to refer to “Projects” and “Boards” somewhat interchangeably on our website, our blog and in the Kerika app itself.

There was no special reason for this: in our mind, a Project was clearly a Board, and vice-versa, and it never occurred to us that this might prove a source of confusion to anyone.

Well, we were wrong about that.

In the real world, people are very cautious about “starting a new project”, because this might involve getting formal administrative approval, budget allocation, staff changes, etc.

In other words, in the real world a “project” is a big deal.

But, in Kerika, starting a new Task Board, Scrum Board or Whiteboard is not a big deal — and that is very much by design.

Unlike so many other collaboration tools that make it difficult for you to create as many boards as you like, Kerika was always designed to make it very easy for you to redesign your work as needed: start new boards, move cards or canvases from one board to another (using Cut, Copy and Paste), and to move ideas and content from one context to another.

Many of our competitors don’t offer this kind of flexibility: either the software makes it hard, or their billing model actively discourages you from creating multiple boards.

That will never be the case with Kerika: we will always support flexibility in how you organize and manage your boards.

Still, our interchangeable use of “projects” and “boards” was definitely causing some confusion, which we have fixed with our latest release by using the term “Board” consistently and avoiding use of the term “Project”.

So, if you were a Project Leader previously, you are now a Board Admin on that board. Your rights and privileges remain the same, it’s just your title that changed.

Board Admin
Board Admin

When you start a new board, what used to be called “New Project” is now labeled “New Board” to make it clear what you are doing:

New Board dialog
New Board dialog

We hope this makes for better usability: let us know what you think.