One of our users in Massachusetts alerted us to a bug in the export function that we have fixed with our latest release: it turns out the export function wasn’t correctly preserving the sort order of cards within the column, which was a nuisance.
Bug fixed, and as always, our thanks to our users for providing valuable feedback!
Here’s one of the weirder bugs we ever fixed: it turns out that there is a tiny grey dot in the middle of every canvas on a Whiteboard.
It’s been there for a while, ever since we introduced some animation to make it easier for people to understand that canvases can be embedded inside cards on Task Boards and Scrum Boards, as well as being used independently on Whiteboards.
But the funny thing is that none of our users, nor anyone on our team, noticed it because too many of us, it seems, eat in front of our computers all too often, so our screens are flecked with little bits of food debris most of the time :-)
One of our team members finally noticed it after assiduously cleaning his computer screen, and that’s how we discovered there was an HTML element there, with a zero size and absolute position at the center of the canvas (to help with the “exploding” animation effect when a canvas is opened).
Although this element has a height and width of zero, it also has a 1 pixel wide solid grey border, which is used in the animation.
And that’s what appeared as the tiny grey dot in the middle of the screen: one pixel of grey border, not any debris from our lunch.
We have enhanced our recently introduced Archive feature, so that you can now copy a current project and paste a copy directly into your Archives:
One possible use-case for this, that some of our users have asked for, is to do quick backups that “capture current state” of important projects.
As with anything else that’s in the Archive, the copies you paste there are frozen, and can’t be changed unless and until you drag them out of the Archive and into your Projects list.
The Tags filter button, which appears on the top-right corner of your Task Boards and Scrum Boards, lets you filter your view of a crowded board by showing just those cards that match a particular tag that you are using (or a particular color coding):
It used to be that when you were filtering your view of the board, you couldn’t add any new cards.
The reason made sense from a technical, geeky perspective, but it proved confusing and frustrating for our users, so we have added more flexibility by letting you add new cards even while you are using filtering.
The new cards will appear as you add them to the board, and stay there until you refresh your view of the board. At that point, whether the new cards continue to appear or not will depend upon whether they meet your tags filtering criteria or not.
That sounds complicated, we know, so let’s take a look at the original logic behind not letting users add cards while using tags filtering…
In the example screen shown above, the board has a bunch of tags defined, like admin, box, bug, canvas, and cleanup.
Suppose we were using filtering, to only show those cards that are tagged bug and box. With this filtering in effect, you are going to see only a small subset of all the cards that exist on the board — only those cards that have either bug or box as a tag. (Or both.)
So, what should happen if you add a new card to the board, which isn’t tagged bug or box?
From a strictly logical perspective, this new card shouldn’t be displayed, because it doesn’t match the filter criteria you are currently using — it should be displayed only if the new card had bug or box as one of its tags.
We originally dealt with this problem by saying that you couldn’t add new cards while using tags filtering, because the new cards would disappear immediately after you had added them, which we felt would make for a very confusing user experience.
(People would likely think they failed in their attempt to add a new card, and keep trying. Eventually they might turn off tags filtering, and then find they had added many copies of the same new card.)
So, that was one solution to the problem, but it still presented a user experience challenge because many folks would forget that they had turned on tags filtering, especially if they were bouncing around between multiple boards. (Yes, Barb, we are looking at you!)
If a user returned to a board and didn’t realize that they had tags filtering turned on, they would get confused as to why they were unable to add new cards.
We thought of a couple of different solutions to this problem, including the use of callouts (those balloon-like bubbles that appear to give you hints about how a page works) but we aren’t generally a fan of callouts — too many apps misuse them to excess these days.
So we have come up with what we think is a better solution: if you are using tags filtering, go ahead and add new cards. They will show up, but if you refresh your page, your tags filtering will be re-applied, and the new cards will be displayed only if they match the tags you want to show.
We have been hacking away at the application chrome within Kerika, removing some of the purely decorative elements that were starting to crowd out the user’s critical view of data.
Application chrome is like Kudzu: if you are not careful, what seemed like a nice-looking decoration on one part of the screen can quickly grow to overwhelm the application.
Here’s a before-and-after view of Kerika:
And here’s the same board, viewed with less application chrome, which allows the cards on the boards to stand out more:
This wasn’t just an aesthetic decision, although we are pleased with the new, cleaner appearance of Kerika: it was actually essential for our development of the new Planning View in Kerika, which lets you easily view a Task Board or Scrum Board from the perspective of Due Dates.
For the Planning View to work with workdays, it became essential to show more columns at a time, more of the time: showing at least 5 columns on most laptops became an essential requirement, and we could not achieve that solely by shrinking the width of cards — we also needed to remove the column chrome so that the board would not appear so crowded.
At the Jan 12, 2015 meeting of the Washington State Lean Practitioners Community of Practice meeting, organized by Results Washington at the Department of Labor & Industries in Tumwater, Arun Kumar presented Kanban in a Can: Capture, Visualize and Optimize your Everyday Processes.
Here’s the presentation on Slideshare (although most of it was actually a demo!):
The meeting was attended by dozens of Lean experts representing a huge variety of state agencies in Washington!
Did you know that any Kerika canvas, whether on a standalone Whiteboard or attached to a card on a Task Board or Scrum Board, can be viewed as a regular Web page by folks who have been given access to the board?
Kerika automatically creates a version of your canvas that can be viewed without the Kerika application: you can get this version by using the Project Info dialog, or, more simply, by just changing the “m” in the canvas’s URL to a “c”:
Every Kerika page has a URL of the form “https://kerika.com/m/…”
The URLs are randomly generated and unique: every card, every canvas, every board has a unique URL.
The first part of the URL is always of the form kerika.com/m/… There’s no special reason for using the “m”; it’s just part of Kerika’s history.
But if you change the “m” to a “c”, like in the example above where “https://kerika.com/m/SRXk” becomes “https://kerika.com/c/SRXk”, then you can view the Web page version of the canvas.
In the Web page version there are no buttons or other indications of the Kerika software: it looks and works just like a regular Web page.
Of course, security is not compromised: you cannot view the Web page version of a canvas if you aren’t permitted to access the Kerika canvas itself.
We are facing a small crisis over here at Kerika… Our designer has turned hipster. Apparently he has been drinking hand-crafted beer from a Mason jar while watching the sunset from the rooftop. It might have something to do with the temperature hitting 61 degrees Fahrenheit today, which pretty much qualifies as mid-summer in Seattle.
Kerika’s UI will probably change real soon. Expect it to get more hip.
When you copy or cut an item on a Kerika board — a set of cards, or may be some things sitting on a Canvas — these objects are placed in a special Clipboard that sits on the Kerika server, not in your browser.
This is important to note for several reasons:
We had problems occasionally with our servers running reliably, and if you were unlucky you may have noticed this.
Well, it took a very, very long time but we have finally figured out what’s happening.
It turns out that the garbage collection function on the Java Virtual Machine that runs our server software (all on a Linux virtual machine running on Amazon Web Service) was having problems: most of the time the garbage collection runs just fine on an incremental basis, taking up only a fraction of a second of CPU time, and periodically the JVM would do a full garbage collection as well.
The problem we are facing is that sometimes this full garbage collection would fail and immediately restart.
In the worst-case scenario, the garbage collection would start, fail and restart over and over again, until the server basically thrashed. And each time the full garbage collection ran, it took 5-7 seconds of CPU time (which is a really long time, btw).
We are trying to understand the best long-term solution for this, but in the short-term we can mitigate the problem in a variety of ways, including upgrading our server virtual machines to have more RAM.
One reason it took so long to debug is that we were chasing a red herring: we had noticed network spikes happening frequently, and we wrongly assumed these were correlated to the server’s CPU load spiking, but this turned out to be coincidental rather than causal.
Sorry about all this.