Kerika and Box: from small beginnings…

For a major upgrade project at a municipal planning department, a team spread from Washington to Minnesota, used Kerika to successfully manage document reviews, technical questions, issue management, and key tasks.  Dennis Brooke has the story on cloudPWR’s blog.

And this is just the beginning: expect much more in terms of a Kerika+Box integration!





It’s easier now to customize your Account photo & logo

We have always offered all users, including people with the free Standard Accounts, the ability to customize their accounts, and now we are making that a little easier.

For most people, the most convenient way to grab a photo or company logo is from a Web site, and that’s possible now when you customize your account.

Go to your My Account page, and you will see buttons to customize your photo and logo:

My Account

My Account

When you click on the Add Photo or Add Logo buttons, you will now have the option to upload an image from your local computer, or grab it from a website:

Getting image from the Web

Getting image from the Web


Fixing 58 server bugs and warnings (Why so many?)

Along with the hundred styling changes and UI cleanup we are wrapping up, we also took the opportunity to fix around 58 different errors and warnings being reported by our server.

This might sound like a lot, so perhaps a little context is useful:

  • Kerika is built on top of Google Apps (at least, for now): we use Google’s OAuth service to sign up and sign in people, and we use Google Drive to share files within project teams.
  • A lot of errors show up as a result of this Google integration, only a fraction of which are solvable from our perspective:
    • Some errors relate to people from restricted Google Apps domains trying to use Kerika. This happens at least once a week — someone working at a company that has Google Apps for Business tries to sign up for Kerika, but fails because their Google Apps Administrator (typically, someone within their IT department) has prohibited any third-party apps from integrating with their Google Drive.
      This is an example of an unsolvable problem — we can’t override the existing protection that this company has set up (and nor would we want to!) so we are going to redirect users to an explanatory page that helps them understand the problem is not with Kerika.
    • Sometimes Google Apps has outages: when this happens, we can get a cascade of errors on our servers, because these outages are typically intermittent and inconsistent across our user base. Some folks experience problems, others don’t. We are trying to come up with a way to inform people about what’s happening, so they don’t think it’s Kerika that’s busted.
    • Sometimes Google burps: not have an outage, but experience a fleeting problem with uploading a file.  We might get nothing back from Google than a generic “500 error: system not available”.
  • We have also had problems related to our use of Firefox for the Render Server: Firefox’s latest updates are sometimes less stable than previous ones, and in general Firefox is starting to have a really big footprint in terms of memory usage.
  • And, finally, we have had our own bugs, just like any other software developer. Some of these have been tricky to find, but as we find them, we squash them.


Making it faster to create new projects, and to copy/paste them

Kerika is starting to get used in larger organizations more: big global companies, and state and local governments, and as we move into these types of user communities we are finding that people are more likely to create large numbers of projects.

(On average, people create 4-5 projects if they are relatively passive users of Kerika, while more active users — like Project Leaders — might create 30-40 projects over a couple of months.)

To make this smoother, we have been improving the performance of the creation of new projects, as well as the copy-paste function for projects.

It turns out both are closely related, so improving one should help with the other!

Adding URL references got a lot better!

A few weeks ago we introduced a new feature: if you included a URL reference in a card’s details, attachments or chat, we would fetch that Web page’s title and show that, instead of just the “raw URL”.

This turned out to be a really helpful feature, and so we are expanding it in our next version by adding logic to handle a wider variety of URLs: the new logic should make it easier to have smart references to URLs show up in your cards even when these URLs are pointing to obscure Web sites, Intranet sites, etc.


Dropping the “Render Server” feature

One of our oldest features has outlived it’s usefulness…

(No, we didn't shoot this dog. Or any other dog.)

(No, we didn’t actually shoot this dog. Or any other dog.)

We have something we call the “Render Server”: it’s a separate server from the rest of Kerika, and it’s sole purpose has been to create thumbnail images of Whiteboard projects.

This feature was originally built to make it easier for people who created rich, layered Whiteboards — boards where canvases are contained with other canvases, like the amazing Foundation for Common Good Whiteboard project created by Charles Fraser‘s team (in the UK, and worldwide) which looks something like this:

Foundation for Common Good

Foundation for Common Good

This is just a partial view of the top-level of a series of canvases, layered within each other to create a rich, multi-media world.

The Render Server helped people understand that some shapes on a canvas contain other canvases within them: for example, if you hovered your mouse over one of the circles on this canvas, you could see — somewhat dimly — a thumbnail of the canvas that was contained within that page:

Showing layered pages

Showing layered pages

This feature was also used when you added canvases to cards on Task Boards and Scrum Boards: the card details dialog would show a thumbnail of the canvas, like this

Thumbnail image of a canvas attached to a card

Thumbnail image of a canvas attached to a card

This feature was cool, and made for great demos, but it was ultimately not all that useful in a practical sense.

(And that’s true for a lot of cool ideas: things that make for great demos don’t always provide great utility in regular use.)

The thumbnails were too small to be of much use on Whiteboards, and when shown on card details for Task Boards and Scrum Boards they just took up too much space.

So, it’s buh-bye to the Render Server: a cool idea, whose time seems to have passed.

(No, really: we didn’t shoot the dog! We promise!)


Getting rid of UI crud

Our next update to the Kerika software, scheduled for release this weeekend, will have a bunch of minor styling updates — over a hundred styling changes, in fact.

Most of these are fairly subtle; it’s quite likely you will not notice over 90% of them at all, because this new release is really a UI cleanup effort rather than a big feature release.

Over the past couple of years Kerika had acquired some “UI crud”: little inconsistencies in the fonts, colors, and interactions that had build up over time as you release new features, and we have been releasing new functionality every 4-6 weeks for over 3 years now.  It’s like barnacles on an otherwise beautiful wooden boat…

Polishing the boat

(Not us, but somebody else, polishing somebody else’s boat.)

For example, we found there were minor variations in shades of grey throughout the app: a light-grey shading in one place was off by an octect or two from a light-grey shading in another place.  A tooltip was missing from one button here or there, or a tooltip wasn’t phrased as well as it could have been.

Taken individually, these are very trivial indeed — and, unless you examine the entire UI with a magnifying digital color meter, like we did, you wouldn’t have found these tiny inconsistencies, but they can have a cumulative effect that makes the UI seem vaguely fuzzy.  (Just like barnacles, if left un-scrapped, can slow down even the most beautiful boat.)

The most visible change we made is the card details display: what you see when you open up a card on a Task Board or Scrum Board

New Card Details dialog

New Card Details dialog

This display is cleaner than what we used to have: it has a more consistent appearance with the rest of the Kerika user interface, and gives equal prominence to all the user interface elements within this dialog — because all of these elements are, in face, equally important to users. Our previous design gave undue prominence to Details, Attachments and Chat, which reflected nothing more than the historical evolution of the Kerika software; now, everything about a card is equally accessible.

The layout is also a lot cleaner: unnecessary decoration has been eliminated, and the overall style is more “flat” (i.e. in keeping with Microsoft’s Metro/Modern design styling, which even Apple has now adopted for iOS 7).

14 Kerika users affected by Google Docs outage today

Since Kerika is built on top of Google Docs and Google Drive, any problems with Google Apps can affect Kerika.

This doesn’t happen very often, but today Google Apps did suffer an outages, and a total of 14 Kerika users were affected.  (We have written to each person affected to apologize!)

This dashboard is a handy way to keep track of the health of Google Apps.

A shift towards short-lived cookies

In an earlier blog post we noted that Google is making it increasingly hard for people to create and maintain distinct Google IDs, and this is creating more problems for Kerika users, forcing us to rethink our “cookie strategy”.  Here’s the background:

Long-lived and short-lived cookies

When you sign in to Kerika, you do so using your Google ID: the Kerika server gets an authorization token from Google and places a cookie on your local computer so that you don’t have to sign in again, if you close and then reopen your browser.

We had been using what’s known as a “long-lived cookie”: one that doesn’t automatically expire when you close your browser. That made Kerika more like a news site than a banking site: when you login to a news site as a registered user, you get a long-lived cookie so that you don’t have to login again, even after you have closed your browser (or even restarted your computer).

Banking sites, on the other hand, use “short-lived cookies”: if you close your browser tab, open a new one and try to access your bank account again, you will be asked to re-login.

Short-lived cookies are generally used for more sensitive websites, like banking, because there is a big tradeoff in terms of user convenience. Kerika had previously opted for long-lived cookies because we wanted to make it really convenient for people to get back to their Kerika boards after having closed their browser.

The problem we face

The problem we are facing now is that it is increasingly more likely that your Kerika login is out of sync with your Google login. There are at least two ways in which this could happen, one of which was always a risk, and the other a new risk resulting in the shift in Google’s approach to user IDs:

  • The old problem: people with multiple Google IDs would frequently switch between them, without logging out of Kerika. For example, someone has two Google IDs: A and B. She may have signed up with Kerika while she was logged in as User A. Since we were using long-lived cookies, a Kerika cookie identifying her as “User A” will stay on her machine until she logs out of Kerika.
    But, in the interim she may have separately logged out of Google as User A and logged in as User B (perhaps to check her Gmail on a different ID). This would result in a situation where she is known to Kerika as User A, and currently logged into Google as User B. In this scenario, she would be unable to open any files attached to her projects because of the mismatch in IDs.
  • The new problem: Google is making it easier for people to be logged in as two different IDs, using the same Chrome browser. (Note: this is true only with the Chrome browser; not true with Safari, Firefox or IE as far as we know.)  This considerably increases the odds that a user is currently logged into Kerika as User A, and simultaneously logged into Google as User B.
    Because the user never consciously logged out from Google – just switched IDs while on YouTube or Gmail or somewhere – she may be unaware that she isn’t who she thinks she is…

The short-term solution

We can mitigate this problem by switching over to short-lived cookies. This makes the user experience a little more annoying, in our opinion (because you have to login more frequently to Kerika, or remember to keep your browser alive), but it should help reduce the odds that your Kerika ID is out of sync with your Google ID.

The long-term solution

Allow users to sign up directly at Kerika, without using their Google IDs!

Teams distributed by time, not location

We are often asked to advise our users on workflow: it isn’t a primary business of ours – we prefer to build partnerships with process consultants who can provide great services – but the insights we garner from these brief, often unofficial engagements do heavily influence our product design and roadmap planning.

Recently, we have been helping a large industrial company rethink it how it processes requests that come into its various engineering teams, and as a result reorganize its workflow so that there is optimal flow of work across its various design and engineering teams.


The company is based in North America, and operates on a 24×7 basis all year around, which isn’t unusual in industries that need continual production in order to fully utilize their very expensive equipment. As a result, their “distributed team challenge” was a little unusual: the teams weren’t distributed by location, but by time.

Every aspect of the companies design and engineering functions – which involved highly specialized teams – needed to be replicated in a day shift and a night shift so that work could be handed off continuously throughout the 24-hour cycle. And, that extended to weekends as well: some folks got a “regular weekend” (i.e. Saturday and Sunday off), while others got “staggered weekends” (e.g. Monday and Tuesday off).


In many respects, these teams had collaboration challenges that match those of a US-India distributed team, e.g. a team based on the US West Coast trying to collaborate with a team based in India, and having to deal with a 12.5-13.5 timezone difference (the variation comes from Daylight Savings Time, which isn’t observed in India.)

This 24×7 challenge was relatively straightforward: we have a lot of experience with helping US-India distributed teams work efficiently – based on our own experience, of course.

A different challenge had to do with streamlining the work of the multiple design and engineering teams involved: work requests were coming in from all directions, some through official channels like project planning meetings, and others through unofficial channels like hallway conversations, and in the absence of a clearly defined process to triage new requests, the various teams were feeling randomized.

All these requests were coming in, unfiltered and without any prior review, into a combined backlog that was being used by multiple teams, each of which would normally work independently, often in parallel with each other, and sometimes sequentially (serially) with each other.


The solution we proposed was to create another Kerika board that sat upstream of the main engineering board.

This board was used to capture ideas and triage them, and ensure that only complete, appropriate requests made it to the main board’s backlog. This upstream board also helped divert single-team requests to other boards that were created for handling work items that were not cross-team or cross-functional.

The entire process was captured as a Kerika Whiteboard, as illustrated below:

Workflow for a multi-team industrial company

Workflow for a multi-team industrial company

Let’s take a look at this entire flow, piece by-piece:

At the top, we have requests coming in: formal requests initiated at project planning requests, and informal requests that originated in stray emails, unexpected hallway conversations, etc.  All of these are captured as cards on a Planning Board organized with these columns:

New items :: Under Review :: Accepted by Business :: Accepted by Project :: Needs Rework :: Rejected

We recommended that a single person be designated as Business Owner, and tasked with doing the initial Business Triage of new cards:

Initial Business Triage

Initial Business Triage

The scope of Initial Business Triage is fairly limited: the Business Owner was asked to examine each new card, on a daily basis, and determine whether it qualified as Accepted by Business, Needs Rework, or Rejected.

Enough new ideas came into the organization that a daily review was recommended, and, importantly, the Business Owner was asked to move cards from New Items to Under Review so that people visiting the board at any time (of the day or night!) could see that their requests were in fact being worked on.

And, equally importantly, people could see  the overall volume of requests coming into the organization, and adjust their expectations accordingly as to how promptly their own requests might be processed.

To further emphasize transparency and build support for the engineering teams, we recommended that the Planning Board include as many stakeholders as possible, added to the board as Visitors.

As noted above, the goal was to determine whether a card could be Accepted by Business or not, and for this the card needed:

  • A sufficiently complete description for the work to be handed off to the engineering teams;
  • To be within the plant’s overall scope and mission (as with most industrial companies, there were several large plants, each with a distinct mission);
  • Have budget clearance.

This arrangement helped us achieve two important goals

  • Encourage the promiscuous sharing of ideas, while simultaneously
  • Ensuring new ideas met a minimum standard of completeness and relevance.

If an idea was within the organization’s scope/mission, but lacked sufficient detail or the appropriate budget approval, it was marked as Needs Rework.  And if an idea was clearly outside scope, or had no chance of being funded, it was Rejected.

Another key consideration was to discourage people from setting Due Dates on cards early in the process: delaying the setting of deadlines, until the work reached the teams that would actually commit to delivery, helped preserve flexibility in scheduling and allocating resources.

Once the Business Owner did her initial triage of new work, cards were picked up by the designated Project Manager:

Initial PM Triage

Initial PM Triage

The Project Manager worked off the same Planning Board as the Business Owner; she picked up cards that were Accepted for Business.  Her goal was to determine the likely impact of each work item, and, critically, to channel the work to either one of the single-team boards, or to the Joint Production board:

Channeling work to the appropriate boards

Channeling work to the appropriate boards

The Project Manager’s review focused not on business utility (since that was handled earlier by the Business Owner), but rather on identifying whether the work request was likely to affect a single team, or multiple teams.

If the work was likely to affect only a single team, the card was moved to that team’s Kerika board using a simple Cut-Paste operation.

If the work was likely to affect multiple teams, it was moved to the Joint Production Board, which was organized with these columns:

Backlog :: In Progress :: This Week :: Today :: Commission

Tags were used to identify the team involved; since the Joint Production Board typically had hundreds of cards at any point in time, and dozens of team members, this was essential for quick reviews by individual Team Members who wanted to filter out their team’s work items.

  • As team members became available, they looked first to the Today column to see if anything was marked as Ready to Pull.
  • If there was nothing in the Today column that was appropriate for the individual person’s skill sets, the person then looked to the This Week column for items that were Ready to Pull.
  • As an item was taken up by an individual Team Member, she would put her face on the card, to signal to the rest of the team that she had taken ownership of the work.
  • As work got done, the work product (design documents, engineering plans, etc.) were attached to the cards.
  • As questions arose, or handoffs were made between team members or entire teams, Kerika’s integrated chat was used to communicate on the cards themselves. (And this is where the 24×7 operation really started to hum!)

Where appropriate Due Dates were set.  We had noted earlier that we discouraged people from setting Due Dates at the time they requested new work, to preserve flexibility for the production teams; at this stage it was now appropriate for the teams to make date commitments.

Since all the work that reached the Joint Production Board involved multiple teams (by definition), the card details were updated to reflect the interim deadlines, e.g. the deadline for the Design Team to hand-off something to the Electrical Engineering team.

Once work was completed on a card, it was moved to the Commission column where the final deployment was handled. After that, the card would be moved to Done, and periodically (once a week) the Done column was swept off to another Project Archive board.

Occasionally, work would be shunted off to Reserve Backlog: this contained ideas and requests that were plausible or desirable in general terms, but had no realistic chance of being implemented in the short-term.

Workflow for a multi-team industrial company

Workflow for a multi-team industrial company

Key Lessons Learned

Some aspects of this workflow design should be of interest to teams in other industries and sectors:

  • The use of a Planning Board to act as a way station for ideas and work requests, so that the main boards of the individual teams, as well as the Joint Production Board were not disrupted.
    • The way station helped ensure that only complete work requests went on to the engineering boards.
    • The way station encouraged people to contribute ideas and improve them before they were sent to engineering.
  • Encouraging people to contribute ideas, by making the Planning Board open to a wide group of people who were given Team Member rights (i.e. the ability to add and modify cards).
  • Separating  the roles of Business Owner and Project Manager, so that the business evaluation was distinct from the implementation evaluation.
  • Separation of individual team boards from the joint production board, so that single-team requests could get processed faster than they would have, if everything had gone through a single pipeline, on a single joint production board.
  • The user of a Reserve Backlog, to hold on to ideas that the teams might wish to revisit in the future.

What do you think?

We would love to hear your thoughts on this case study!