Monthly Archives: August 2016

Snacking on our cookies

Ever wonder how many cookies Kerika sets when you are logged in, and why?

Here’s the answer:

Kerika's cookies
Kerika’s cookies

The first cookie, called “BAYEUX_BROWSER”, relates to our use of the CometD communications protocol for ensuring that you always get real-time updates whenever you are looking at any Kerika board, no matter which browser you are using.

CometD leverages WebSocket when it can (because it’s the most efficient web messaging protocol), and makes use of an Ajax push technology pattern known as Comet when using HTTP.  Most modern browsers support WebSocket, but we still have some older versions of Internet Explorer out there that don’t support WebSocket.  This cookie helps us track whether your browser supports WebSocket or not.

The next couple of cookies are used simply to keep track of your Kerika session.

The fourth cookie, “i18next”, is really not used much right now, but we hope to make greater use of it in the future.

Right now Kerika is available only in English, but the code was always written to make it easy for us to create versions in other languages, e.g. Spanish, Chinese, etc.  This process is called “internationalization”, and is usually abbreviated as “i18n” by us nerds.

The last two cookies, “last-selected-auth-service” and “tabs”, are used to remember what you were last doing when you were logged into Kerika on that computer: when you log back in, after having logged out, these two cookies help us restore your view of Kerika to exactly where you left off.

As it says on our website, we are committed to transparency, so now you know everything about our cookies.

Want to learn more? Check out our privacy policy.

Kerika+Google users can decide whether to use Google Docs, or stay with Microsoft Office

If you are a Kerika+Google user — you signed up for Kerika using your Google ID (like a Gmail address) — your Kerika files will be stored in your own Google Drive.

Most Kerika+Google users prefer to have their files converted to the Google Docs format when they upload them their Kerika cards, canvases or boards: this makes it easy for them to edit these files from inside a browser.

A small minority of our Kerika+Google users, however, prefer to keep their files in their original Microsoft Office format.

(The most common reason for this is if you are working with complex spreadsheets: Microsoft Excel is still far better than Google’s Spreadsheets!)

If you are a Kerika+Google user, you have a choice of using Google Docs or not: just go https://kerika.com/preferences and select this option:

Google Docs format
Google Docs format

Either way your files will still be stored in your Google Drive; the only difference is whether they are stored in the Google Docs format or kept in their original Microsoft Office format.

Kerika+Google users can decide whether to use Google Docs, or stay with Microsoft Office

If you are a Kerika+Google user — you signed up for Kerika using your Google ID (like a Gmail address) — your Kerika files will be stored in your own Google Drive.

Most Kerika+Google users prefer to have their files converted to the Google Docs format when they upload them their Kerika cards, canvases or boards: this makes it easy for them to edit these files from inside a browser.

A small minority of our Kerika+Google users, however, prefer to keep their files in their original Microsoft Office format.

(The most common reason for this is if you are working with complex spreadsheets: Microsoft Excel is still far better than Google’s Spreadsheets!)

If you are a Kerika+Google user, you have a choice of using Google Docs or not: just go https://kerika.com/preferences and select this option:

Google Docs format
Google Docs format

Either way your files will still be stored in your Google Drive; the only difference is whether they are stored in the Google Docs format or kept in their original Microsoft Office format.

Better looking emails

The emails you get from Kerika, e.g. when someone assigns you to a card on a Task Board or Scrum Board, have gotten better:

  • The formatting is better: neater, cleaner, and there’s less verbose junk.
  • They are all sent from the same Sender Email — notifications@kerikamail.com — so your mail clients (like Gmail) do a better job of clustering them in your Inbox.
  • They all have better footers, explaining why you are getting the email, and how to contact us. (In other words, they are better at conforming to the CAN-SPAM Act.)
  • They look better on mobile devices: the subject headers are easier to scan, so if the email is something you expected, it is easier to delete it unread.
  • We eliminated the use of our logo, which saves (every so slightly) on bandwidth, especially on mobile devices.

 

Better looking emails

The emails you get from Kerika, e.g. when someone assigns you to a card on a Task Board or Scrum Board, have gotten better:

  • The formatting is better: neater, cleaner, and there’s less verbose junk.
  • They are all sent from the same Sender Email — notifications@kerikamail.com — so your mail clients (like Gmail) do a better job of clustering them in your Inbox.
  • They all have better footers, explaining why you are getting the email, and how to contact us. (In other words, they are better at conforming to the CAN-SPAM Act.)
  • They look better on mobile devices: the subject headers are easier to scan, so if the email is something you expected, it is easier to delete it unread.
  • We eliminated the use of our logo, which saves (every so slightly) on bandwidth, especially on mobile devices.

 

Bug, fixed: when you have a lot of boards open, you could run into problems

We found and fixed a problem that a small number of users were experiencing: if you had a lot of boards open at the same time — say around 40 — and you then used the URL of any of these boards in some context, e.g. by including it in a chat message, you could run up into a “502 Bad Gateway” server error.

This really was an unexpected edge case — we had never considered that people might be working on 40 boards at the same time, nor that they would routinely have so many boards open, but it turns out that for professional services firms that use Kerika to manage their different client engagements, this was actually not that unusual…

The underlying problem was obscure: Kerika uses a cookie to keep track of which boards you currently have open.

This helps us restore your session perfectly if you exit Kerika and then return, e.g. by simply closing your browser or actually logging out and logging back in.

In the scenario where a user might have had 40 boards open, the cookie was becoming really, really large (as far as cookies go), and our Web server wasn’t set up to handle such large cookies.

Fixed.

Bug, fixed: when you have a lot of boards open, you could run into problems

We found and fixed a problem that a small number of users were experiencing: if you had a lot of boards open at the same time — say around 40 — and you then used the URL of any of these boards in some context, e.g. by including it in a chat message, you could run up into a “502 Bad Gateway” server error.

This really was an unexpected edge case — we had never considered that people might be working on 40 boards at the same time, nor that they would routinely have so many boards open, but it turns out that for professional services firms that use Kerika to manage their different client engagements, this was actually not that unusual…

The underlying problem was obscure: Kerika uses a cookie to keep track of which boards you currently have open.

This helps us restore your session perfectly if you exit Kerika and then return, e.g. by simply closing your browser or actually logging out and logging back in.

In the scenario where a user might have had 40 boards open, the cookie was becoming really, really large (as far as cookies go), and our Web server wasn’t set up to handle such large cookies.

Fixed.

Bug, fixed: handling references to websites that redirect to HTTPS

Some sites like Kerika.com use HTTPS all the time: every URL reference, whether to our website, within our application, or even to any article on this blog is automatically converted to a secure HTTPS session.

(We are not the only ones doing this: type in “facebook.com” in your browser’s address bar, for example, and you will be automatically redirected to “https://www.facebook.com/” even though you didn’t type in “https”.)

Always using HTTPS is good security practice, but it can sometimes lead to problems for users: unless you are very familiar with a particular site, and also the type of person who plays close attention to these things, you might not understand this process.

And even if you did, you would still find it convenient to make short references to “kerika.com” (or “facebook.com”) instead of typing out “https://kerika.com”.

When you include a URL in any part of a Kerika board’s contents, e.g. in a card’s details, it’s chat or its attachments (and the same goes for canvases), Kerika tries to get the title of that Web page so the URL reference is easier to read.

We found and fixed a bug related to this: in situations where the URL, as typed by the user, actually resulted in a redirect from the referenced website (typically a “301 permanent redirect” rather than a “302 temporary redirect”), Kerika wasn’t properly showing the Web site’s page title.

All fixed now.