Since we use OAuth 2.0 to let people sign up (and sign-in) using their Box or Google IDs, Kerika never actually sees any user’s password.
But, a lot of our users don’t quite understand how OAuth works, and they expect that when they go to the My Account screen in Kerika, they should be able to change their password right there.
Well, we aren’t going to move away from OAuth because we believe that’s a far more secure arrangement than having Kerika manage your password, but with our new release we are making it easier for people to figure out where they should go to change their passwords:
If you go to your Kerika account (http://kerika.com/my-account) and click on the Change Password button, it will take you to either Box or Google website where you can change your password.
A small “feature”, but one which we know will help smooth the way for at least some of our users
Kerika is welcoming and friendly for people who are already familiar with online project boards, but what about people who have never used anything like Kerika before?
To make Kerika more welcoming for new users, we have created a new Welcome Experience: a series of simple callouts that can orient new users to the Kerika user interface, within 30 seconds.
We understand only too well that these kinds of callouts have been misused by many apps and websites, and that — when badly implemented — they can be annoying and ineffective, so we have take a good deal of care to design the Kerika Welcome Experience:
It is short. Seriously. We timed it so that it will take well only about 30 seconds of a user’s time.
It is personalized and relevant: it figures out whether someone just signed up fresh at our website, or whether that person joined after accepting an invitation to someone’s else project.
Here’s another new feature: you can create a new Box Note or Google Doc (depending upon whether you are using Kerika+Box or Kerika+Google) from within a card itself, and have that attached automatically to your card.
A single mouse-click is all that it takes to create a new Box Note or Google Doc, add it to your card (on any Task Board or Scrum Board), and open that Box Note / Google Doc and start using it.
When you are done editing your new Box Note / Google Doc, you can come back to Kerika and you will find it is already attached to the card where you were working!
All in one mouse-click!
One small adjustment you might need to do: many browser will automatically block pop-up windows. When you create a new Box Note or Google Doc, Kerika tries to open it immediately in a new browser tab, so that you can start using it.
If your browser gives a warning about a pop-up window, please allow pop-ups from Kerika — this is the only use of pop-ups by Kerika, and it makes a great feature even better!
Secure Internet connections used to be implemented with SSL 3.0, which is actually a pretty old protocol now. (About 18 years old, in fact, which means it dates back to the Netscape era
Over the years, SSL 3.0 was implemented by everyone who produced Web servers: e.g. Microsoft, Netscape, Apache, etc.
SSL 3.0 has since been supplanted with Transport Layer Security (TLS), which also comes in several flavors — TLS v1, v1.1 and v.1.2
And SSL was around for such a long time, everyone knew it worked. With TLS, however, bugs are sometimes found in different Web servers, depending upon who is producing (and maintaining) a particular brand of Web server.
In order to get around potential problems with the way a particular Web server had implemented TLS, browser clients (i.e. software that runs in a browser, like Kerika does) will also, very often, try to connect to the Web server using with SSL 3.0 as a fallback protocol.
Well, the good folks at Google found that SSL has a very fundamental vulnerability in it, that’s inherent in the protocol and cannot be patched: in an example attack called Padding Oracle On Downgraded Legacy Encryption (POODLE), an attacker can steal “secure” HTTP cookies or other bearer tokens such as HTTP Authorization header contents.
This problem is basically unfixable with SSL 3.0 because it uses RC4 ciphers for encryption, and RC4 is pretty darn old: it dates back to 1987!
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:
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.
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:
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+GoogleWhiteboard 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.
Kerika is work management for distributed Lean and Agile teams