Monthly Archives: July 2017

Bug, fixed: Custom Highlights were getting carried over from one board to another

We fixed a bug that was kind of annoying: if you had a Custom Highlight defined for one board, and then switched to another open board, the Custom Highlight was getting applied automatically to the second board as well.

This happened only if people used the Board Switcher button that appears on the top left of the Kerika app:

Board Switcher
Board Switcher

The Board Switcher keeps track of all your open boards and is a fast way to switch between them if you are working on several different projects at the same time — you don’t have to go back to the Home page to find your boards again and again.

Every of your open boards can have Highlights set, or not, as you like. This bug fix makes that a smoother process.

Tweaking the styling of Tasks inside Cards

We really like the Tasks feature that we introduced recently: this has significantly cut down on the number of cards that we have to track on boards, since many items can be easily captured, assigned and scheduled as tasks rather than independent tasks.

This means we have a better, epic-oriented view of our boards; we don’t get lost in the weeds.

However, the first implementation of the styling could do with some improvement, so that’s what we did:

Improved styling for tasks
Improved styling for tasks

This makes it easier to see the names of people assigned to cards, and the due dates, more easily.

By the way, it took a surprising amount of experimentation before we settled on these colors: in Kerika’s design every color is supposed to have a particular meaning, so that colors appear in a consistent context in every instance.

For example, if we use blue to indicate a clickable link — like we do on the card details left tab, to let you switch between Tasks, Attachments, Chat, etc. — we can’t use blue anywhere else where it wouldn’t be clickable.

So, if blue is clickable in one place, it must always be clickable everywhere else.

This is easy enough, but we also have rules about using colors consistently across actions or displays that seem related, again to minimize the learning effort needed by new users.

Our green is used for Highlights in a consistent way:

What's Assigned to Me
What’s Assigned to Me

The breadcrumbs includes the suffix “What’s Assigned to Me” in green, the Highlights button is green to indicate that it is in use, and a green button is used to indicate that items matching the highlight are out of view.

If we are rigorous about this, there is an internal consistency about the Kerika user experience that makes it easier to learn.  But it takes a lot of discipline.

So if consistency applies a bunch of constraints in our choice of colors, so do legibility and color-blindness: we have to be careful to avoid using color combinations like red and green that are difficult for some people to distinguish.   (About 8 percent of males, and 0.6 percent of females, are red-green color blind in some way or another, whether it is one color, a color combination, or another mutation.)

All of this means that it isn’t easy to pick a new color when we design!

Tweaking the styling of Tasks inside Cards

We really like the Tasks feature that we introduced recently: this has significantly cut down on the number of cards that we have to track on boards, since many items can be easily captured, assigned and scheduled as tasks rather than independent tasks.

This means we have a better, epic-oriented view of our boards; we don’t get lost in the weeds.

However, the first implementation of the styling could do with some improvement, so that’s what we did:

Improved styling for tasks
Improved styling for tasks

This makes it easier to see the names of people assigned to cards, and the due dates, more easily.

By the way, it took a surprising amount of experimentation before we settled on these colors: in Kerika’s design every color is supposed to have a particular meaning, so that colors appear in a consistent context in every instance.

For example, if we use blue to indicate a clickable link — like we do on the card details left tab, to let you switch between Tasks, Attachments, Chat, etc. — we can’t use blue anywhere else where it wouldn’t be clickable.

So, if blue is clickable in one place, it must always be clickable everywhere else.

This is easy enough, but we also have rules about using colors consistently across actions or displays that seem related, again to minimize the learning effort needed by new users.

Our green is used for Highlights in a consistent way:

What's Assigned to Me
What’s Assigned to Me

The breadcrumbs includes the suffix “What’s Assigned to Me” in green, the Highlights button is green to indicate that it is in use, and a green button is used to indicate that items matching the highlight are out of view.

If we are rigorous about this, there is an internal consistency about the Kerika user experience that makes it easier to learn.  But it takes a lot of discipline.

So if consistency applies a bunch of constraints in our choice of colors, so do legibility and color-blindness: we have to be careful to avoid using color combinations like red and green that are difficult for some people to distinguish.   (About 8 percent of males, and 0.6 percent of females, are red-green color blind in some way or another, whether it is one color, a color combination, or another mutation.)

All of this means that it isn’t easy to pick a new color when we design!

What's Assigned to Me

Highlights, a better alternative to old-fashioned Filters

We have replaced the old Filters feature for our Task Boards and Scrum Boards with a new Highlights feature that we think is better in every way!

Click on the Flashlight icon on the top right corner of the Kerika app:

Highlights button
Highlights button

And you will see this menu of actions:

Highlight options
Highlight options

The default is No highlights. We have a couple of built-in highlights that we know you will find useful right away:

  • What’s assigned to me: very useful if you are working on a large board, or with a large team, and you focus on just what you need to get done.
  • What needs attention: this highlights all the cards on the board that we think need to pay attention too — items that are overdue, on hold, or flagged as needing review.

Here’s how the Highlights work:

What's Assigned to Me
What’s Assigned to Me

A shadow effect helps spotlight all the cards that match the highlight, making them literally pop out of the screen!

If you are working on a board with a lot of columns, there’s always a chance that something that is being highlighted is currently out of view — if, for example, it is near the bottom of a long column.

Kerika takes care of that as well: if a card that matches your highlight choice is currently out of view, a green button appears at the top or bottom, as needed, of each column to indicate that there are cards out of view that match your highlight.

Matched cards are below the scroll
When matched cards are below the scroll

The green arrow acts as more than just an indication that you need to scroll: it is also a button that will scroll the column to show you the next card that you need to see.

(Pretty cool, huh?)

We will be adding more smart highlights in the coming weeks, but in the meantime you can also create your own custom highlights:

Custom Highlights
Custom Highlights

A Custom Highlight can include any combination of people assigned to cards, status, due dates and tags.

For the due dates, we have offered several smart options that are a lot easier to use than standard date pickers:

Smart choices for Due Dates
Smart choices for Due Dates

These ways of specifying due dates — like “Due Next Week” or “Next Month” — make it even easier to set up a custom highlight.

Enjoy.

We had a problem today

Kerika was unavailable for about 15-20 minutes this morning; our apologies to everyone who was affected.

It’s back now, and we are still investigating the root cause.  All we know right now is our Amazon Web Services (AWS) Load Balancer, which acts as the immediate front-end to every browser that tries to connect to Kerika, reported a problem.

UPDATE:

It is starting to look like Amazon Web Services was having an internal networking problem; our server’s error logs included entries like

[97207ms] ago, timed out [81830ms] ago, action [cluster:monitor/nodes/liveness], node [{#transport#-1}{thl-D8yeRmGg9N_4GyNNUQ}{elasticsearch}{172.18.0.12:9300}], id [133181]
06-07-2017 16:44:53.077 [ConsumerPrefetchThread-1] ERROR   com.amazon.sqs.javamessaging.AmazonSQSMessagingClientWrapper - AmazonClientException: receiveMessage.
com.amazonaws.AmazonClientException: Unable to execute HTTP request: sqs.us-east-1.amazonaws.com: System error

Restoring service was unexpectedly hard: we couldn’t reboot the AWS EC2 instances from the AWS Console, and couldn’t even login to the machine using ssh.

Eventually we had to power down our EC2 instances and restart them from scratch.  Not good.

We had a problem today

Kerika was unavailable for about 15-20 minutes this morning; our apologies to everyone who was affected.

It’s back now, and we are still investigating the root cause.  All we know right now is our Amazon Web Services (AWS) Load Balancer, which acts as the immediate front-end to every browser that tries to connect to Kerika, reported a problem.

UPDATE:

It is starting to look like Amazon Web Services was having an internal networking problem; our server’s error logs included entries like

[97207ms] ago, timed out [81830ms] ago, action [cluster:monitor/nodes/liveness], node [{#transport#-1}{thl-D8yeRmGg9N_4GyNNUQ}{elasticsearch}{172.18.0.12:9300}], id [133181]
06-07-2017 16:44:53.077 [ConsumerPrefetchThread-1] ERROR   com.amazon.sqs.javamessaging.AmazonSQSMessagingClientWrapper - AmazonClientException: receiveMessage.
com.amazonaws.AmazonClientException: Unable to execute HTTP request: sqs.us-east-1.amazonaws.com: System error

Restoring service was unexpectedly hard: we couldn’t reboot the AWS EC2 instances from the AWS Console, and couldn’t even login to the machine using ssh.

Eventually we had to power down our EC2 instances and restart them from scratch.  Not good.

Expanding our use of Lazy Loading

Our introduction of lazy loading, as part of our recent redesign, was originally limited to just three columns: Backlog (for Scrum Boards), Done, and Trash.

We figured that these columns were most likely to be very long, and would therefore benefit the most from implementing lazy loading.

This worked well; so well, in fact, that we have expanded our use of lazy loading to work with all columns, across all Task Boards and Scrum Boards.

The practical effect of this should be to reduce the time needed by the browser to load large boards, for all users, on all kinds of computers.

Enjoy.

Expanding our use of Lazy Loading

Our introduction of lazy loading, as part of our recent redesign, was originally limited to just three columns: Backlog (for Scrum Boards), Done, and Trash.

We figured that these columns were most likely to be very long, and would therefore benefit the most from implementing lazy loading.

This worked well; so well, in fact, that we have expanded our use of lazy loading to work with all columns, across all Task Boards and Scrum Boards.

The practical effect of this should be to reduce the time needed by the browser to load large boards, for all users, on all kinds of computers.

Enjoy.

Expanding our use of Lazy Loading

Our introduction of lazy loading, as part of our recent redesign, was originally limited to just three columns: Backlog (for Scrum Boards), Done, and Trash.

We figured that these columns were most likely to be very long, and would therefore benefit the most from implementing lazy loading.

This worked well; so well, in fact, that we have expanded our use of lazy loading to work with all columns, across all Task Boards and Scrum Boards.

The practical effect of this should be to reduce the time needed by the browser to load large boards, for all users, on all kinds of computers.

Enjoy.