If you are still using Windows 7, please use Chrome or Firefox instead of Internet Explorer 11 (or, worse yet, an even older version of Internet Explorer).
We are not in a position to support Internet Explorer on Windows 7 anymore: for one thing, we don’t have any PCs running Windows 7 anymore. And Microsoft itself has stopped selling Windows 7 several years ago, and mainstream support ended two years ago.
We realize that some of our enterprise customers are forced to stay with Windows 7 because of legacy systems that don’t work well with newer versions of Windows, but supporting Windows 7 is not something we are in a position do, or have any interest in pursuing.
With our big UI redesign, launched a couple of weeks ago, we have started using lazy loading of cards in an effort to improve performance, particularly with very large boards.
Background:
Most Kerika boards tend to be small, or moderate: up to 100-200 cards in size. A few users, however, have very large boards: several thousand cards in size!
And this is not because we have users who are tracking thousands of work items simultaneously; it’s just that some users have been continuously using the same board for years to track all their work.
For people who use the same board over several years, the number of items in the Done or Trash columns can eventually number in the thousands. Displaying such large boards was already difficult in our old architecture: we had underestimated how many cards some boards might contain, so our old design downloaded all the cards on a board every time it was opened, and then created a DOM for each card!
This meant that, for very large boards, the browser had to create thousands of DOMs before it could even display the board. This was obviously not a sustainable model.
What we did:
With our redesign, we have laid the groundwork for a better architecture using two related concepts in lazy loading:
For columns that we anticipate being very large — the Done, Trash and Backlog columns for Task Boards and Scrum Boards — the browser now fetches only a small number of cards, say 10-20, from the server. (With our old design the browser would fetch every card, for every column.)
Fetching fewer cards means the amount of traffic between the browser and the server decreased dramatically, but it didn’t solve the performance problem by itself. We also changed our browser code to reuse DOMs instead of creating new DOMs. By reducing the total number of DOMs created and maintained within the browser by the Kerika app, we are able to reduce Kerika’s overall browser footprint while significantly improving performance.
Here’s an example of lazy loading of the Done column:
Lazy loading of Done column
On this board, the Done column contains 163 cards, but when the board is opened only 10 are shown. Since these are the 10 most recently done cards, this works great for most users, most of the time.
If the user really wanted to see something that was done a long time ago, they can simply scroll down the Done column, as they would have with our old design as well.
As a user scrolls down, more cards are fetched automatically from the server. Slightly more cards are fetched from the server than are likely to be displayed, e.g. the browser may fetch 15 cards from the server even when it expects to display only 10.
This helps avoid the perception of delay when the browser needs to fetch more cards, since it will already have 5 more cards stored in memory to show as the user begins scrolling, giving it time to fetch another 15 before the user has finished scrolling.
We also decided to use lazy loading on the Home page: with our new design we display more information about the state of each board than we did previously, and the cards themselves are much larger than before. This means we are unlikely to show the full set of boards to any user at any time, so lazy loading is a natural choice for this view.
Lazy loading of Home
Finally, with our most recent update (launched two days ago), we have extended our use of lazy loading to include the Not Scheduled column in the Planning Views, where you can pivot your view of a Task Board or Scrum Board to see all the cards organized in terms of due dates.
Here’s an example of a board where there are a very large number of unscheduled cards:
Lazy loading of Not Scheduled
The Not Scheduled column only fetches and displays 10 cards at a time even though there are over 200 cards that are not scheduled. Since the browser (on this laptop) can only show 3-4 cards at a time, there isn’t any point in fetching all 200 cards: just fetching and displaying 10-15 at a time does the trick!
Arun Kumar, CEO of Kerika, and Joy Paulus, Senior Policy and Program Manager for the Washington State Office of the CIO, delivered a joint presentation at the Lean Transformation 2016 Conference.
The subject of the talk was “Collaboration Across Organizations: Big Results with Small Teams”. Here are the slides from the talk:
Every couple of weeks I get email from Facebook along these lines:
Yup, Facebook is stalking me.
In its remorseless scanning of everyone’s private information, Facebook has figured out a personal phone number for me, and now it is “helpfully” trying to make that a public piece of information by associating it with my company instead.
And it’s not just phone numbers: Facebook tries repeatedly to associate my home address with my company’s page as well, because, you know, it would suck if any part of the Internet were “inaccurate or out of date.”
I guess I should feel flattered that I am as worthy of stalking as the best B-list celebrity, but there’s also the incompetence common to any creep who thinks he can safely hide in the bushes.
Clicking through on the “Review Page Info” link always lands me on an dead-end page:
Let’s all sing along…
If there’s a bustle in your hedgerow, don’t be alarmed now,
It’s just a spring clean for the May queen.
Yes, there are two paths you can go by, but in the long run
There’s still time to change the road you’re on.
And it makes me wonder.
By the way, I learned to program in 1978, so I can tell by now when someone writes crappy code. Facebook does.
We switched over to Google as the registrar for a number of our domains yesterday (we used to use a mix of GoDaddy and Register.com previously), and in the process our DNS got screwed up.
We didn’t realize this right away because it affected one of our subdomains (which meant the website itself was up and running, but one of the ways in which you can sign into Kerika was messed up.)
The basic problem was with Google’s way of handling incoming transfers of domains that have already been set up: even if you use the setting for keeping your current domains, Google doesn’t keep your current DNS settings for all the subdomains as well.
Our apologies for everyone affected by this!
Update on 10:15AM PST Oct 6:
We are still waiting for Google’s bazillion DNS servers to all get the new DNS entries. It’s a bit hit-or-miss for individual users, depending upon which Google server they get routed to when they try to login.
Here in the Seattle area, for example, we can login consistently, but we know some of our users can’t. In India it is literally a 50:50 chance that your Kerika session will connect to an updated DNS server or not. In the UK the problem seems mostly fixed now.
Kerika helps you (and your team) manage multiple versions of a document, and it does this so smoothly that you might not even have noticed…
Here’s how it works: when you add a file to a Kerika card or canvas, it shows up in the list of attachments, like this:
File attached to a card
If you then attach another file to the same card or canvas that has the same name and file type, Kerika automatically treats it as a new version of the same file, rather than a completely different file:
Uploading a new version
In the example above, when a Team Member adds another document called Foo.docx to a card that already has a file attached to it with the same name and file type, Kerika treats the new document as a new version of the old Foo.docx rather than as two documents called Foo.docx.
How you access all these old versions depends upon how you set up your Kerika account:
If you are using Kerika+Google, these files are being stored in your Google Drive, and Google will manage the versions for you: you can find this under the File menu in Google Docs
Google Docs versions
And pretty much the same thing is true if you are using Kerika+Box: Box will take care of the older versions automatically, although their user interface is slightly different
Box version history
And what if you signed up directly with Kerika, without using a Google or Box ID?
We provide an easy way to get to older versions of a file for users who signed up directly: when you are previewing a file, click on the Older versions of this file link on the top-right.
File preview
Kerika will show you a list of all the old versions that are available for that file, along with details on who uploaded those versions, and when:
If you are using Kerika+Box, we store your Kerika files in your Box account: you can always go to Box.com, login using your Box ID, and see for yourself.
(But, please, don’t move them around!)
What you might notice is that the filenames in Box have some random characters appended to them. For example, a file that you might see listed inside Kerika as “Alternative Home Page” actually shows up with some random characters appended, like this:
URL appended to file names
The reason we do this with files we store in Box — and not for files we store in Google Drive, for our Kerika+Google users, is that Box doesn’t allow for several files within a single folder to have the same name.
(Google does, which is why we don’t need to append any random characters to the files we store in Google Drive.)
It’s very common for our users to have several files within the same board that have the same name: for example, our developers always attach an analysis document to each card that describes exactly what they are doing. (Yes, we are fairly fanatical about documenting our software!)
These documents are often the same for many cards: Analysis.docx or Results.xlsx or Mockup.png might show up hundreds of times within a single board.
Since all the files related to a single Kerika board are stored in the same folder in your Box account, this presents a problem: Box won’t allow for more than one file called Analysis.docx within a folder.
We get around this limitation by appending these random characters, so that effectively every Analysis.docx file has a unique name.
But, we also try to avoid confusing our users, so when we show a list of files attached to a card, we strip out the random characters:
Displaying files as attachments
And the same goes for downloading files: we strip out the random characters and give you a clean-looking file.
It’s not that we have sensitive stuff on the blog: quite the contrary. It’s just that we have implemented HTTP Strict Transport Security (HSTS) across the entire kerika.com domain.
It allows web servers to declare that web browsers should only interact with it using secure HTTPS connections, and never via the insecure HTTP protocol.
Since our blog is on a sub-domain of kerika (blog.kerika.com, to be precise), we needed to implement SSL and HTTPS for the blog as well.
Some advice to fellow developers: don’t be tempted to use a local snapshot of a rapidly evolving library, like Polymer.
One of our team members was doing this because he thought it would hasten his compilation when he needed to do new builds of Kerika (he is located in an area with somewhat slow Internet connections).
This might, sort of, work with a very stable library, but with something that is evolving fairly rapidly (like Polymer), you run the far greater risk that you snapshot’ed a somewhat buggy version.
That’s what happened to us, leading to a perplexing day of debugging: we had a version of Polymer that didn’t work well with Internet Explorer 11.
Just our luck that our developer took a snapshot of that particular build and then kept it on his local machine…
The easiest way to attach files to a Kerika card, canvas or board is to simply drag and drop it onto Kerika, like this:
Dragging and dropping files onto cards
This works with nearly all kinds of files, but we sometimes hit a limitation, like we discovered when a user tried dragging and dropping an email directly from his Outlook onto Kerika.
This operation used to fail, but in a confusing way: Kerika made it look like it was possible to drop the email onto a card, but the email never showed up.
We have fixed this by checking the kind of content that someone is trying to drop onto Kerika, and if the content isn’t something that can be directly dropped, we don’t show the “drop zone”: the yellow area in the image above that encourages you to drop something onto a card.
And, by the way, if you need to attach an email to a Kerika file, here’s a good workaround: first drag and drop the file onto your computer’s desktop. That will create a regular file out of the email, which you can then drop onto Kerika.
