Category Archives: Technology

Posts related to technology in general

Auto-Numbering: a new Kerika feature

We have a new feature in Kerika: a simple way to add numbers to your cards, for both Task Boards and Scrum Boards.

Project Leaders (and, of course, the Account Owner) can access this feature by clicking on the Project Info button, which appears on the top-right area of a Kerika board:

Settings
Settings

Auto-Numbering can be turned ON or OFF at any time.

It is a simple feature, intended primarily to help manage large numbers of cards on a single board, e.g. a Help Desk team using Kerika as a ticket management system.

In ticket management or asset tracking scenarios, the titles of many cards may be similar, e.g. “User has trouble logging in”.

A more useful way of distinguishing between cards might be through the card’s numbers, e.g. “104 User has trouble logging in” and “242 User has trouble logging in.”

When Auto-Numbering is turned ON, Kerika will automatically insert a number as a prefix to new cards that are added to that board.

  • Numbers are sequential: for example, the first card would have “1” added as a prefix, the second card would have “2” added as a prefix, etc.
  • Auto-Numbering can be stopped at any time, and then new cards added to the board won’t have numbers added to the card titles.
  • Auto-Numbering can be resumed after a pause, the numbering will intelligently figure out how many cards are on the board by excluding the Backlog and the Trash, as well as looking at the last number used.
  • The numbers are simple text, added as a prefix: they can be edited by any Team Member, and even removed.

Making projects viewable by the public: a new Kerika feature

Most users work on private projects: i.e. projects that are accessible only to people added to the project team.

But some folks find it useful to have their projects viewable by everyone, typically because they are working on nonprofit causes, like WIKISPEED.

WIKISPEED publicizes its projects because it helps attract new volunteers to their cause, and this is actually a pretty smart way for nonprofits to showcase their work.

Kerika has always had an option for people to have all their projects made viewable by the public, but even nonprofits, for example, may have some Kerika boards that they don’t want to share with the rest of the world.

Well, with our newest release, it is possible for the Project Leader (or Account Owner) to make individual projects open to the public to view.

A project can be easily switched from Private to Public, and back again, using the Project Info button that’s available on the top-right of every Kerika board:

Privacy
Privacy

The privacy choices are as follows:

  • Only the project team can access: this is the default setting, and it means that unless people are added to the project team, they won’t be able to view it — or even find it using the Search function.
  • Anyone, anywhere can view: this means the project is “public” — it can be found through search, and anyone who knows the URL of the project can view it. (But, they still won’t be able to make changes.)

When a project is made Public, all the documents contained within it — on all the cards and canvases that make up that board — are also made viewable to the public.

This means, for example, that if your Kerika+Google Whiteboard or Task Board is made available to the public, all the documents in that board’s Google Docs folder are also made viewable by the public.

(And Google indexes all public Google Docs, the project could be found in more than one way, depending upon who is searching for it.)

One caveat: users of premium Google Apps, e.g. Google Apps for Business, cannot make their projects open to the public, because of limitations imposed by Google.

Switching a board between Kanban and Scrum: a new Kerika feature

When we first started working on Kerika, it seemed to us that everyone who wanted to use an online project board fell into one of two camps that didn’t overlap:

  • Kanban users, who wanted a simple Task Board, perhaps with nothing more than To Do, Doing, and Done columns.
  • Scrum users, who wanted to share Backlogs across multiple Scrum Boards, with each Scrum Board representing a different Scrum iteration (i.e. “Sprint”).

Folks who wanted to work in Kanban-style – typically business users – seemed to have little use for Scrum, and people who wanted to work in Agile-style – typically IT folks – didn’t show much interest in Kanban.

So, we built Kerika with support for Task Boards, for Lean/Kanban users, and Scrum Boards, for Agile users.

What we are seeing more recently, however, is spectrum of usage patterns and styles within organizations:

  • A project that starts off as a Kanban Board might need to become a Scrum Board in the future: as the team works on the project, it may conclude that a series of Sprints/iterations is a better model than a continuous flow/Kanban model, and they may need to transform their Kanban Board to a series of Scrum Boards.
  • A team might start off working with Scrum Boards, thinking that Agile is the ideal model for their work, and then find that a Kanban model of continuous flow is better suited for their needs, in which case they may need to change from a Task Board to a Scrum Board.
  • A Scrum team may need to pull items from multiple Backlogs: there may be items from a Marketing Backlog and from a Product Development Backlog that need to get worked on in the same Sprint, so the team may need to switch from one Backlog to another.

This kind of flexibility wasn’t available in Kerika before — and is certainly not available in Trello, Asana, Basecamp or any other tools that compete with Kerika — and that’s exactly the problem that we have fixed with the new release!

Use the Project Info button, on the top-right of the Kerika menu bar, to switch a board from Kanban to Scrum, or vice versa:

Settings
Settings

If you check the “Use a shared Backlog” box, you can then select the Backlog you want to use for your board: if you had been working in a Kanban board, it automatically switches over to a Scrum Board.

At any time you can switch between any of the Backlogs that exist in the Account, that you have permission to access.

If you want to go back to working in Kanban-style, just uncheck the “Use a shared Backlog” box and the Backlog will disappear from view.

It’s now that simple to choose between Kanban and Scrum!

Adding a Twitter feed to your Kerika canvas

You may know already that Kerika’s patented canvases are a great way to share your ideas and content, like drawing process flow diagrams, flowcharts, etc., and these canvases can also include content from your laptop or the Web.

For example, you can drag-and-drop a file from your desktop, and it will get added to your Kerika canvas, and stored and shared automatically with your team members using Box or Google (depending upon whether you are using Kerika+Box or Kerika+Google).

When you add Web content to a canvas, Kerika is pretty smart about figuring out what that URL is that you just provided.

So, for example, Kerika makes it really easy to add a Twitter feed: all you have to do is click on the “+Web Content” button on your canvas toolbar…

Adding Twitter feeds to a canvas, step 1
Adding Twitter feeds to a canvas, step 1

You can add a Twitter feed simply by using the user’s Twitter handle, e.g. “@kerika” would give you Kerika’s Twitter feed right on your canvas:

Adding a Twitter feed to a canvas, part 2
Adding a Twitter feed to a canvas, part 2

And that’s all it takes!

 

Lunch & Learn Agile, for State Government Employees

Cayzen Technologies organized a Lunch & Learn Agile event at the Harbor House at Percival Landing in Olympia, Washington, featuring Arun Kumar, CEO of Kerika.

Arun’s topic was Implementing Lean across Distributed Teams, and we would like to specially thank Mayra Pena from Cayzen who organized the event:

Arun Kumar & Mayra Pena
Arun Kumar & Mayra Pena

The event was attended by folks from Washington State’s Employment Security Department and Department of Health, among others, and there was a lively discussion.

Here are the slides from that presentation:


If you would like to see the sample Kerika board that featured in the demo, go to https://kerika.com/m/H51M

Thanks for attending!

Arun speaking at Lunch & Learn Agile
Arun speaking at Lunch & Learn Agile

No, not Shellshocked

The announcement by CERT yesterday that there is a vulnerability in the Bourne Shell (more commonly known as “bash”) wasn’t great news for anyone running any variant of Unix, which includes Linux and MacOS.

Linux is very widely used for modern Web servers, particularly those running on Amazon Web Serviceslike Kerika does.

There are a number of variants of Linux out there, which makes things a little harder whenever a vulnerability is announced: you have to make sure your particular variant of Linux is patched quickly.

Luckily, this problem was fixed as fast as the notorious Heartbleed bug: within a couple of hours of the report of Shellshock, Amazon and Google (and, most likely, every other cloud services provider out there) started installing patches, and so the Software-as-a-Service (SaaS) world got back into good shape very quickly.

In our own case, we use Ubuntu Linux, and they were equally swift in issuing a patch for Shellshock which we installed yesterday.

On a side-note, we are less enthusiastic about Apple’s announcement that “the vast majority of users are not at risk“.

That’s true only in a literal sense: the vast majority of Mac users don’t ever use the Terminal program to access the shell, and a lot of permissions on Macs are locked down by default (and most users never bother exploring all their administrative privileges).

But, in a practical sense this bland statement from Apple understates the actual risk faced by Mac users: a significant majority of startups use Mac for their software development, which means a critical set of Mac users are still sitting exposed!

The sooner Apple fixes this bug, the better is will be for the startup world.

How to install Kerika on a Google Apps Domain

Since our last released, when we upgraded our integration with Google Apps Marketplace to use the OAuth 2.0 protocol, a number of folks have written in to ask about how they should install and authorize Kerika for their premium Google domains (i.e. Google Apps for Business, Google Apps for Nonprofits, etc.)

Here’s a step-by-step guide for the Google Apps Administrator in your organization:

First, login to admin.google.com with your Google ID. Your screen will look like this:

Google Admin Console
Google Admin Console

On the right side of the screen, you will see a link for Google Apps Marketplace, in the area marked Tools:

Go to Google Apps Marketplace
Go to Google Apps Marketplace

When you click on the “Google Apps Marketplace” link, you will be presented with a search box that looks like this:

Searching for Kerika
Searching for Kerika

Type in “Kerika” in the search area, and you will find us!

Adding Kerika
Adding Kerika

Once Kerika shows up, click on the blue “Install App” button:

Installing Kerika
Installing Kerika

Click on the blue Continue button, and you will be asked to authorize Kerika for your Google Apps domain:

Authorizing Kerika
Authorizing Kerika

And that’s it! Your final confirmation message will show:

All Done
All Done

And at this point Kerika will have been authorized for your entire Google Apps domain. Individual users will be able to sign up without going through any of this hassle.

If you have any difficulties or questions with this, please email us at support@kerika.com

Google was flaky for 2 hours today!

Between the hours of 9AM and 11AM PST, Google’s authentication service — which we used to sign in users of Kerika+Google — kept having problems that affected people at random.

It was a tough morning for us, dealing with the flood of “504 System Timeout” errors coming back from Google, and feeling helpless that we couldn’t provide the kind of high-quality user experience that is at the core of the Kerika brand.

The problems finally went away by themselves, but a total of 31 Kerika users were affected and we are reaching out to each of them individually to apologize for the inconvenience, and explain what happened.

This is one of those situations where Kerika cannot do anything to fix the problem: if you signed up as a Kerika+Google user, when you try to login to Kerika you are automatically redirected to Google’s authentication service, which then comes back to Kerika to give us your identity information.

Then, we use the identity information to log you into the correct Kerika account.

Normally, all this happens really fast: you click on the Sign In button at Kerika, Kerika redirects your browser to Google, Google responds immediately, and within a couple of seconds you are logged into Kerika.

It all happens so fast and smoothly, 99.999% of the time, that most people are completely unaware that their browser was even redirected to Google in the first place — it’s something you might notice only if you have a very slow WiFi connection, and you are paying close attention to your browser’s status bar.

But every once in a while, Google won’t respond when you get redirected there by Kerika. In that case we retry again several times, and then finally Kerika does a “timeout”: it gives up.

(This problem has happened before, and as software developers ourselves, we are, of course, very sympathetic to other software companies that experience occasional bugs and hiccups, but Google can be irksome in their lack of transparency.)

This happens so infrequently that we didn’t really have any special code in place to tell users why they were not able to login, but that’s going to change starting tomorrow: if Google’s servers are not responding fast enough, we will show a special page to the user explaining what’s happening, so they understand the situation better.