We have been working for months now on our new mobile app, and it has been a tough slog! We are building it entirely using React (a Javascript framework) to make it possible to have a single code base across both desktop and mobile devices, and across all operating systems.
We took some time learning to be good with React: previously we had used Polymer, and before that we used JQuery, so there was some learning curve to traverse while we figured out the right way to code in React. But we are beyond that now.
For the past couple of months, it is really performance that has been our bugbear. In the spirit of “eat your own dogfood before trying to sell it”, we are using the emerging mobile app for our own work on a daily basis.
The trouble is: our main Kerika board is huge: it has usually around 600 cards, and 26 columns. This isn’t best practice, by the way, and we are not recommending you create boards like this, but we are talking here about our main board that tracks many different ideas and initiatives, not just product development.
So, when using our mobile app for our own board, we hit performance problems that few of our users are likely to encounter. We could, of course, have written us off as an edge case and ignored the performance issues, because for smaller boards (e.g. with around 20-30 cards), these performance problems completely disappear.
But, we decided to bite the bullet and get our mobile app to be good even with boards that are as wide and deep as our main board. And we have learned a lot from that experience: for example, it wasn’t the number of cards, but the number of columns that had the bigger performance impact.
We have another board with over 2,500 cards in just 2 columns (essentially a historical record of old work items) and we didn’t experience performance problems in the same way as we did with 500-600 cards over 26 columns. In fact, we found that 2,500 cards in 2 columns was much easier to handle than the latter case!
So, a lot of our efforts over the past few months have been trying to handle performance for scenarios that are out of the norm.
We are doing our testing on both iOS and Android at the same time, to catch browser-specific issues early. (We have been less diligent about Firefox testing, to be frank, but we expect clearing iOS and Android issues will effectively cover Firefox as well, making our final testing easier.)
Our end goal is a single code base that runs on any device. Right now that’s not true: our desktop experience is still using (mostly) Polymer, while our mobile is entirely in React, but we are trying to make sure we design all of the new code to work well on the desktop as well, so that we can slowly replace parts of the desktop code as we build the new mobile app.
(It’s not that our desktop code has any problems today — we are very confident about the quality of our desktop user experience — it’s just that we are too small a team to be able to split ourselves into multiple sub-teams to support every platform.)
Here’s a composite view of what our mobile app looks like now: in “zoomed-in” view, in “zoomed-out” view, and card details:
It’s possible to copy-paste text into a Kerika Chat message, and there are legitimate use-cases for this: for example, a developer may ask a question to a coworker who replies with a code snippet.
Kerika handles code in chat messages by storing two versions of the message: as plain-text, and as the original format. When a chat message is displayed, the original format is used but not executed, which means the embedded code is visible, but doesn’t run in the browser. This makes it easy and safe to share code snippets through chat messages.
While making this improvement, we went through all the places where a user can type in text, Card Title and Description, Board Name and Description, Tag, Attachment Name, etc. to make sure we are guarding against malicious code injection.
With our latest release we have introduced a new way to have your Task Board and Scrum Board cards numbered automatically.
Our original implementation was rather rudimentary: if you turned on Auto-Numbering (which you can access from the Board Settings dialog, by clicking on the gear icon/button on the top-right of the Kerika app), Kerika would automatically insert a card number as part of each new card’s title.
Turning on Auto-Numbering of Cards
The card numbers inserted by Kerika were pure text that was prefixed to whatever you typed in as a card title. This meant that they could easily be changed by any Team Member (or Board Admin), and this, in turn, meant that what you saw as a card number couldn’t be completely relied upon as the real/original number of that card. A coworker could have easily edited that number to something quite different.
An example of card numbering.
To make these numbers more reliable and trustworthy, Kerika now keeps the card number as a separate attribute (field) of each card: it is shown, when Auto-Numbering has been turned on for a board by it’s Board Admin, but it cannot be edited by anyone.
With card numbers being stored as a separate attribute of each card, we are also adding an improved way to search for cards by their numbers: if you type in a number in the Search box inside Kerika, the system will first look for a card with that number before showing any other results.
Card Numbering in Scrum Boards
Card numbers are always unique to each board: a card with number 100 on Board A will have no relation with a card numbered 100 on Board B. Each board will keep track of its own numbering, starting with “1”.
So what happens with Scrum Boards? Scrum Boards are different from regular Task Boards in that they let you share a backlog across multiple Scrum Boards. This lets you run several Sprints one after another, with each Sprint drawing from the same shared Backlog.
(And, of course, this also makes it possible to run several projects at the same time that draw from the same shared backlog.)
Since each board keeps track of its own sequence of card numbers, if you move a card from a Scrum Board back to the Backlog column it will lose the number it previously had.
That’s because once a card goes back into a shared backlog, we can’t be sure which board it will get pulled into the future: the card may return to the same board where it was originally located, or it may get pulled into a different Scrum Board.
The smart approach in this situation is to reset card numbers when cards go back to a backlog.
We have started purging defunct accounts: users whose email addresses don’t seem to be valid anymore.
We are not doing this in a hurry, but instead are trying to be methodological about it: if someone’s email bounces, and we see they haven’t logged in during the past 6 months, we are going to assume this user doesn’t exist within that organization anymore, i.e. has probably left the company where they were previously working.
(The 6 months of no-activity helps us avoid temporary email problems, such as when someone’s email server is down for a day.)
Also getting purged are new users with invalid emails: this can happen when an existing user mistypes a coworker’s email address at the time they invite people to join their teams.
An account is created at the time someone initiates the invitation, but if we find the email associated with that account is bouncing, we will delete that account.
Kerika works well on modern browsers, but we still occasionally get folks trying to sign up using an obsolete or very old browser. (For example, Internet Explorer is obsolete; you need to use Microsoft Edge.)
To handle this, Kerika checks the browser information returned by your computer when you try to sign up or login, to weed out the unsupported old browsers.
We have expanded this now to make sure organizations that are using Mozilla’s Extended Support Release (ESR) program to manage their Firefox deployments are not hindered. Based upon this chart from Mozilla:
It looks like ESR 60.3.0 is equivalent to regular Firefox 63, so we now let people using this ESR (or newer) to use Kerika.
We have disappeared again from the Google App Marketplace: this is the third time in the last two weeks, and Google is trying to find the bug that’s causing this to happen.
The sequence that triggers it seems to be as follows:
1. We make an update to the Kerika product description on the Marketplace, to reflect some significant new improvement or feature.
2. The update shows up correctly, for a day or two.
3. Then the entire Kerika product listing disappears, without any warning or notification!
4. We contact Google, and they try to to restore the Kerika product listing. Unfortunately they find a really old set of screenshots and text, at least 3 years out of date if not more, and it’s a mystery where they even dredge this up from.
5. So, we try to update our Marketplace listing, and the cycle begins anew…
All of Microsoft’s browser focus is on their Edge browser, which means that as newer HTML5 features and standards get adopted by the browsers, these are going to show up in Edge, not IE 11.
And since Kerika is a pure Web app, one that requires you to download no software of any kind, including browser add-ons and plug-ins, we really need to make use of the latest HTML5 goodies that the browser vendors provide.
These goodies are going to be available only on Chrome, Firefox, Safari and Edge, and that’s where Kerika is gong to work best.
As you know, Kerika is a Web Application: everything runs inside a browser, without the need for any plug-ins or add-ons.
We achieve all this with a ton of JavaScript code (and a sprinkle of SVG, for our Whiteboards.)
One, significant, disadvantage of JavaScript is that it is “single threaded”: two bits of script cannot run at the same time; they have to run one after another.
So while Kerika is running inside a browser on your laptop, our JavaScript has to share a thread with lots of other stuff that’s going on, such as painting, updating styles, and handling user actions. All of this has the potential to slow down Kerika, while the JavaScript code waits for something else to finish.
To get around this, we used JavaScript’s Promise function: this let Kerika’s code get going with its normal business while waiting for other browser functions to finish. What we didn’t expect, however, was that the Promise function isn’t supported by Internet Explorer 11. (Although it is supported in Microsoft’s Edge browser.)
This caused problems for all of our Internet Explorer 11 users — people using Chrome, Safari, Firefox or Edge were unaffected. We finally figured out what the underlying problem was, and did a workaround using a polyfill, which is a way to provide new functionality in older browsers that don’t support it natively.
