Tag Archives: History

The Card History feature in Kerika.

An improvement to Card History

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

Every card, on every Kerika Task Board or Scrum Board, contains within it a full history: a log of all the changes that have been made to it.

(A few actions are ignored because they can occur so often, and are often inconsequential, e.g. moving a card up/down within the same column. In contrast, moving a card across columns is considered consequential, and is therefore logged in the card history.)

We recently made a usability improvement in the way the Card History appears: the log of changes is now shown in chronological order, rather than reverse chronological as was the case before.

This makes history look more like chat, and should make it more usable!

Keeping track of status changes in Card History

Agile & Scrum, Technology, , , , ,

We are starting to realize that a card’s status, e.g. “Ready for Review,” “Needs rework,” etc. is pretty important not just in terms of what they show about a card’s current state, but also in terms of its history.

Previously, we weren’t tracking changes to a card’s status as part of the card’s history; without our latest release, that’s now a feature, so if you are wondering who put a card “On Hold”, you can just open the card’s History and Kerika will tell you:

Card status in history
Card status in history

 

Card history on project boards in Kerika

Technology, Usability,

The next release of Kerika will include a bunch of bug fixes and usability improvements, as usual, but a big new feature that we hope you will find useful is Card History: every card will contain a succinct history of everything that’s happened to it, since it was created.

Here’s an example:

Card history
Card history

Our implementation of this new feature is actually kind of clever, under the covers (of course!): rather than log every action immediately we wait a little to see if the user changes her mind about the action.

So, for example, if a user moves a card to Done, and then moves it back to another column soon afterwards, the Card History doesn’t show the intermediate action since the user clearly changed her mind about whether that work item was actually done or not. In other words, the system is forgiving of user errors: an important design principle that we have tried to adopt elsewhere as well.

Because the Kerika user interface makes it so easy to make changes to your task board, a built-in delay in the history is necessary to avoid creating a “noisy” or “spammy” history.

From a technical perspective, the most interesting aspect of creating this new feature was that we expanded our infrastructure to include Amazon’s DynamoDB.

DynamoDB is a fast, fully managed NoSQL database service that makes it simple and cost-effective to store and retrieve any amount of data, and serve any level of request traffic. This is our first foray into using NoSQL databases; up to now we had been exclusively using MySQL.