When you first use Kerika, your browser has a reassuring sign that your connection to our servers is being encrypted:
No warning when you first use Kerika
But as soon as you open a card that contains any attachments, e.g. files stored in your Box account if you are using Kerika+Box, this reassurance would disappear, and instead you would see a warning about “Mixed Content”, which basically means that some of the data shown on your Kerika page was coming from a source that wasn’t using HTTPS.
Why there is a mixed content warning
This was because of a small bug in how we were dealing with the thumbnails we got for files stored in your Google or Box account: for faster performance we were caching these on our own Amazon S3 cloud storage (so we wouldn’t have to keep getting them from Google/Box every time you open the same card.)
It turns out that we weren’t fetching the thumbnails from S3 using HTTPS, which meant that as soon as you switched to the Attachment view of a card, your browser’s address bar would show the “mixed content” warning.
There was no real vulnerability resulting from this, but it did interfere with the user experience for that minority of users who like to keep a sharp eye on their browser’s address bar so we have fixed that with our latest release.
Now you should always have the warm reassurance of seeing the green secure site symbol on your browser when you open a card!
Where dates are shown on Kerika’s boards and cards, we try to show them in relative terms rather than absolute terms.
For example, if something was updated today, we use the word “Today” instead of the actual date.
There’s a simple reason for that: relative times and dates are much easier for people to comprehend than absolute values. In other words, it’s much easier for someone to comprehend “5 minutes ago” than “Dec 30 2014 3:58PM PST”.
Absolute dates and times may be more accurate, but relative values are a whole lot easier to process for regular humans.
One problem we had with our display of relative times, however, was that they were not continuously updating — instead, they relied upon the page being refreshed in order to show the most accurate relative time description.
For example, if something was updated “2 minutes ago”, the phrase would remain displayed on the screen for a long time, if the page was never refreshed. This obviously can lead to confusion, since users are not going to be aware of when they last refreshed a page.
With our newest release, we have fixed that problem: relative times will still be in use, but they will update themselves automatically, so that “5 minutes ago” will soon become “10 minutes ago” and then “1 hour ago” without the user having to do anything.
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):
Tags button
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 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.
A tiny change in labeling in our latest version will, we hope, make it clear that Kerika’s Export feature is actually pretty smart about managing the amount of data that you export from a board:
Exporting subset of board
What used to say “Export cards” now says “Export the cards shown”.
“Cards shown” means just what it says: if you are hiding some columns from view, or filtering your view of the board to show just those cards that match particular colors or tags, then only the cards currently shown are going to be exported.
This makes it really easy for you to manage what information goes into an export: if you don’t want the Backlog of a Scrum Board to be included, for example, just hide the Backlog from view before clicking on the Export button.
If you are working off a long Backlog (like we do at Kerika!), then you will have many Scrum Boards that pull items off this shared Backlog over time, and with our new Archive feature you will want to freeze old Scrum Boards as you get done with Sprints.
(Each Sprint should be done as a separate Scrum Board, that connects to the same Backlog.)
When you archive one particular Scrum Board, you only freeze that board: the Backlog remains available for use — and modification — by other Scrum Boards, now and in the future.
Which means that when you open an Archived Scrum Board, the view you will get of the Backlog will show the Backlog as it exists today, not as it existed when you archived the Scrum Board.
Cards in the Done or Trash column, of a Task Board or Scrum Board, cannot be modified without first moving them out of Done or Trash: this is different from how boards worked before, and we made this change as part of our recent update where we introduced the concept of Archives.
Done cards
There are a couple of reasons why we did this:
It seems like common-sense: if you have deleted a card, or marked it as Done, why would you be making changes to it? If the card needs changes, or someone wants to do chat or any other updates, that card isn’t really deleted or done, is it?
It matches the behavior of Archived Projects: when you move a project into the Archive in your account, that project is frozen in its current state, and remains frozen while it is in the Archive.For symmetry and ease of understanding of the concepts of “Done” and “Archive”, it made sense that Done cards should also be frozen.
Here’s another new feature with our latest update: when a project is done, you can drag it to the Archive column on your Home page.
Archiving Projects
Archiving a project freezes it: no one can make any changes to it while it is in the Archive, so if you change your mind and want to make some changes to an archived project, you need to drag it back out of the Archive and into your Projects column.
All the documents attached to an Archived Project are frozen: the goal here is to preserve the final/completed state of a project and all its assets, so that later on if you need to investigate a problem — or deal with a FOIA request or some other legal disclosure requirement — you can do so with confidence.
All dates, status, chat and teams are also frozen: if someone was part of an Archived Project’s team at the time the project was moved to the Archive, they will continue to show up on that project team.
If a task had a due date and hadn’t yet been completed (i.e. the card hadn’t yet been moved to the Done column), that due date stays intact.
If the project was a Scrum Board, it will continue to stay attached to the Backlog it was using at the time the board got archived: when you view an archived Scrum Board, it will show that Backlog in it’s current state. This makes it easy to archive Scrum Boards that represent different Sprints that work off the same shared Backlog!
You can change your mind: If you need to work again on a previously archived project, just drag it out of the Archive column and drop it into the Projects column on your Home Page, and that will “un-archive” (restore) your project.
You can create templates from archived projects: if you drag an archived project and drop it into the Templates column on your Home Page, that will create a template based upon that project, while leaving the project in your Archive.
This website uses cookies to improve your experience. We'll assume you're OK with this, but you can opt-out if you wish.AcceptRead More
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
