We discovered recently, to our considerable annoyance, that it is possible for AdBlock to mess up our website in a really serious way, even though we don’t serve up any advertisements of any sort (and never have.)
Here’s what was happening: when you use AdBlock, you have the option to add various lists of advertising sources. (You can find them here.)
One of these lists is from someone called fanboy.
If you subscribed to fanboy’s EasyList, for example, Kerika’s sign up page would not display the buttons for Kerika+Google and Kerika+Box:
AdBlock problems
(The same problem showed upon the Login page as well.)
It turns out that the EasyList filter uses JavaScript classes called social-media-header’ and social-media-button,social-button and soc-button which were also the names of classes that Kerika was using.
The conflict caused Kerika’s signup and login buttons for Kerika+Google and Kerika+Box to not appear for Chrome and Firefox users who had AdBlock installed.
It took a while to figure out this was the cause. We are not fans of fanboy.
A small bug fix we did recently: when you do an Export of data from a Task Board or Scrum Board, you get a notification from Kerika when the export completes: that’s because the export could potentially take a long time, if you had a very large board, i.e. with hundreds of cards on it.
(In practice, most exports take just a few seconds, so the notification comes very quickly after you start the Export.)
The notification comes in two forms:
By email, with a link to open the file containing your exported data.
In your Kerika Inbox, on the top-right of the Kerika application, looking like this:
Export Notification in Kerika Inbox
There was a bug that clicking on the “Dismiss” button on Kerika Inbox didn’t make the notification go away: it would reappear after a page refresh.
Another great new feature: if you upload a file on any card, canvas or board with the same name as a file that’s already attached to that particular card, canvas or board, Kerika will automatically keep track of these as being different versions of the same file. This makes it even easier to organize all your Kerika project files.
There’s no limit to the number of files you add, nor any limit on the size of these files.
When you add a file, to a card, board or canvas, Kerika automatically uploads that file and shares that with everyone who is part of your board’s team. You don’t have to do anything: Kerika makes sure that all the Team Members have read+write permission, and all the Visitors have read-only permission.
These files are stored in your Google Drive, if you are using Kerika+Google, or in your Box account, if you are using Kerika+Box, or with Kerika if you have signed up directly with an email address.
That’s how Kerika has always worked; what we have added is an automatic versioning feature that checks when you add a new file to see if has the same name, and type, as a file that’s already attached to that particular card, canvas or board.
If the file name and file type match something that you have already added, Kerika automatically treats that new file as a new version of the old file, rather than as a completely different file. This makes it really easy to manage your Kerika project files.
Here’s an example: this card has a file attached to it called “Foo.docx”.
File attached to a card
If a Team Member adds another file to this same card, also called “Foo.docx”, Kerika will treat that new file as a different version of the same Foo.docx, rather than as a completely different file:
Uploading a new version
Accessing these older versions is easy: if your Kerika files are in being stored in your Google Drive, you can get the older versions using the Google Docs File menu:
Google revision history
If your files are being stored in your Box account, you can access the older versions from the menu on the right side of Box’s preview window:
Box version history
If you signed up directly with Kerika, you can access the older versions from within Kerika’s file preview:
File preview
Clicking on the Older versions of this file link on the top right of this preview will give you a list of all the old versions of this file that Kerika has:
Older versions
So, that’s it: simple, easy, automatic tracking of multiple versions of your project files! Brought to you by Kerika, of course.
We quietly released a new feature a couple of weeks ago that we now want to announce to the world: you can have all your Kerika due dates appear automatically on your Mac, Outlook or Google Calendar!
All you have to do is go to https://kerika.com/preferences (or click on the Preferences link that shows up under your photo in the top-right of the Kerika app), and then click on the Start Syncing button on that page:
Calendar syncing
You can sync to your Apple/Mac calendar, your Microsoft Outlook calendar, or your Google Calendar.
Pick your preference, and Kerika will show you detailed instructions on how to start syncing.
Here, for example, are the instructions for syncing to your Apple/Mac calendar:
Apple Mac Calendar syncing instructions
And here are the instructions for syncing to your Microsoft Outlook calendar:
Microsoft Outlook syncing instructions
And, finally, here are the instructions for syncing to your Google calendar:
Google Calendar syncing instructions
You will notice that we have deliberately obfuscated the actual calendar URL for this particular user, in all three images above.
That’s important: your calendar URL is unique and precious — don’t share it with anyone!
As your cards on your Kerika Task Boards and Scrum Boards get new due dates, Kerika will automatically feed these updates to your personal calendar: you don’t need to do anything.
Kerika due dates always appear as “all day” events.
Please note that it’s up to Apple/Microsoft/Google to determine how quickly these updates show up on your calendar.
On your Mac Calendar, for example, you can set the frequency with which these updates appear by doing a right-click with your mouse on the calendar and selecting Get Info:
Mac Calendar Info
And then setting the “Refresh time” for that particular calendar. (On Macs, the fastest that iCloud allows is every 5 minutes.)
For folks who sign up directly with Kerika, we store the user password (in an encrypted form, of course), which means that these users can change their passwords directly from within the Kerika application by going to their My Account page at https://kerika.com/my-account:
Changing password for Google sign up
For people who sign up using their Google or Box IDs, we rely upon Google/Box to manage their passwords: in fact, we never even see anyone’s Google or Box password, even for a second!
So, their My Account page looks a little different, like in this example of a Kerika+Google user:
Thanks to one of our users at Washington State’s Employment Security Department, we found and fixed a bug that was causing problems when users tried to add SharePoint URLs as attachments on cards, for Task Boards and Scrum Boards.
The problem turned out to be in some code we have that tries to check whether a user is entering a valid-looking URL. SharePoint’s URLs are somewhat unusual in that they include the “{” and “}” characters, which most other web servers don’t use.
Our old code was treating these characters as invalid, thereby rejecting URLs coming from SharePoint.
We now allow users to sign up for Kerika directly, by using any email address. This version is powered by the Box Platform, which allows us to make good use of Box’s cloud storage technology while presenting a simple user interface for our own users.
Another cool feature from Box that we had integrated, as part of this new service, was to use their browser-based preview functionality — which came to Box as a result of their 2014 purchase of Crocodoc.
We use this preview feature with a simple IFRAME integration, which means we don’t add anything to it ourselves, but one downside of this approach is that if Box removes something from their preview capability, it can disappear from Kerika also.
This happened recently when they took away a button that allowed for a quick download of a file that was being previewed.
We have fixed this by adding our own “Download file” link within the Box Preview:
A user from Mexico recently wrote to us asking which technologies we currently use for the Kerika software, since he was in the early days of planning his own ERP product and was impressed with the overall speed and responsiveness of Kerika.
The question was hard to answer with a simple email in part because we use several technologies, and because we are in the middle of considering some significant changes for 2016.
So, here’s an overview of the current state, with a future blog post to talk about what we are planning to change in 2016…
Our own server software:
All of our server software is written in Java. That’s has worked well for us:
We have a lot of in-house expertise with Java (and none with PHP, Ruby, etc.).
Java is usually one of the first languages to be supported by other platform companies that decide to publish their APIs.
There is a rich ecosystem of open-source code, well-written blog posts and other knowledge sources that help us get our work done.
Open-source server software:
We use a few, well-established open source technologies on the back-end of Kerika:
We use the CometD protocol to provide real-time updates from the server to the browser client. CometD essentially works like a long-poll method, allowing for real-time updates to be pushed continuously from the server to the client without the client having to make new requests. We could, and probably should, switch over entirely to Web Sockets but there are still older browsers out there that don’t support Web Sockets. Hence, CometD.
We use SOLR for our search engine. SOLR is an implementation of the Lucene search technology pioneered over a decade ago by Doug Cutting who has since gone on to do other great work in the software industry. SOLR is widely used by some very large SaaS services like Salesforce.
We use Jetty for our web servers. Jetty is part of the Apache open-source projects, and is a well-established, robust web server that hasn’t given us any trouble in a long while. :-)
We use open-source OAuth for our direct signup.
We use the Java Spring and JBoss libraries for various features.
We use Log4J for error logging.
We use MySQL for our databases.
Platform Libraries
Given our close integration with Google and Box, we naturally use their Java SDK Libraries for authentication and file management.
We used to use Google Checkout, until Google yanked that service from the market (leaving us high-and-dry and more than a little pissed off…) as well as Google Contacts, until we realized this particular integration was scaring away potential users.
Client Software
All of our browser software is written in HTML5, which means a mix of (mostly) Javascript and (a little) SVG.
(Actually, the SVG is only used for the Whiteboards feature of Kerika. The rest is all Javascript and plain HTML.)
Open-source client software
The Javascript ecosystem is quite rich and well established, so there are a bunch of open source libraries we can make good use of:
JQuery is used a lot. A lot.
More recently, Backbone and Marionette have helped fill in the blanks left by JQuery.
The i18n.js library helps with internationalization, although we haven’t actually offered any language other than English so far, for the user interface.
Log4Javascript helps with error logging and debugging.
Bootstrap is used mainly for our website, to make it responsive on tablets and phones.
What changes in 2016?
Quite a lot, probably, but we haven’t finished doing our re-architecture planning.
For one thing, we are planning to use microservices a lot more to make our overall system architecture less monolithic, and we are also planning to use container technology to make deployments faster.
We might consider switching away from SOLR, which we never really mastered, to another search engine which we have more familiarity with, but haven’t made a decision on that either.
This gave our users more choices in terms of how they signed up for Kerika, and which cloud service they used to store their project files, but we continued to resist offering a direct sign up mechanism:
We remained convinced that third-party signup and login, using OAuth, would dominate user preferences — under the theory that no one really wanted to remember yet another password for yet another web service.
Our technical architecture also restricted us from offering a direct sign up choice because we had tied together the issues of authentication and file storage: it was how our original integration with Google had been done, and we had simply duplicated that model when we added Kerika+Box.
This changed in 2015, when Box announced the Box Platform as a new service — although originally it was called the “Box Developer Edition” when it was unveiled at the BoxDev conference in April 2015.
Kerika was probably the first task management app to sign up to use the Box Platform; in fact, we were in the very first batch of beta users for the service.
This new integration with Box allowed us to finally offer a direct sign up mechanism for new users:
Signing up directly with Kerika
Now, you can sign up with any email address: it could be a company email, a Yahoo email, a Microsoft Live email… even a Gmail address.
When you sign up directly with Kerika, we use the Box Platform to securely store your project files:
We create an account at Box that’s dedicated to storing your Kerika files.
We do this automatically and behind the scenes: you might never know that your files are actually being stored at Box, rather than on a Kerika-operated server.
While this seamless integration is great from a user experience perspective, it doesn’t mean that we want to hide our Box links: in fact, we would actually like to boast about our use of the Box platform because Box is so well regarded for the robustness, security and privacy of their cloud storage service.
So, now you know where your files are stored when you sign up directly as a Kerika user: inside the Box Platform!
