We have completely rebuilt Kerika’s search capabilities, both on the back end and on the user interface, to make it much easier to find tasks (cards) and documents across all your Kerika boards.
Search results are organized into two tabs at the top: Tasks and Documents.
Within each tab, results are further segmented into two tabs: This Board, and Other Boards. This makes the most common use of Search even easier: most people want to find something that’s on a large board that they are viewing.
For each search result Kerika shows you what part of the task/card matched the query; in the example above, the search term showed up in 8 Board Chat messages.
Clicking on a search result gives you two action buttons: Open the task/card, or get a link to that task.
The search results are ranked by relevance; we spent weeks fine-tuning the algorithm based upon real-world usage and we think we have got it right now! But we know there will be times when you really need to narrow your search very specifically, and that’s handled by the Filter Results button which gives you so many options:
The Documents tab shows you all the content that matches your search results: we get this from Google, if you signed up using your Google ID or email, or from Box, if you signed up using your Box ID.
Selecting a document result gives you two buttons: OPEN, which will open the document for you in a new browser tab (or in Google Apps or Box on a mobile device), and DOWNLOAD.
As with Tasks, there are numerous options to filter and narrow your search for documents:
We are making a significant change to how we store and manage project files for users who sign up directly (using an email), and we are getting close to finishing our internal testing. Here’s what’s coming, and why.
Previously, when someone signed up directly (with an email address) Kerika would automatically create a new Box account linked to that user, and use this account to store the user’s project files.
This was done by Kerika’s servers: our end-users didn’t have to do anything and, in fact, had no direct access to these Box accounts.
The trouble with this approach is that we ended up with three islands of users: people who had signed up with their Box IDs (Kerika+Box); people who had signed up with their Google IDs (Kerika+Google); and people who had signed up directly.
These islands were isolated: you could collaborate only with users who had signed up the same way as you had. In other words, someone who had signed up using a Google ID could not collaborate with someone who had signed up using their email, because the first user’s project files were getting stored in her Google Drive, while the second user’s files were getting stored in a Box account.
(And over time the ratio of people who preferred Google over Box became increasingly lopsided.)
We are now implementing a new storage model that will deliver four important benefits:
You will be able to collaborate with any other Kerika user, regardless of how the other person signed up. You can invite anyone using their email, and not worry about whether the other person has a Google or Box ID. If you accept an invitation to join a team, it won’t matter how you sign up. No more isolated islands.
Previously we would ask for access to your entire Google Drive if you signed up using a Google ID; now, we can limit our access to only those folders that Kerika itself creates and manages.
Folks coming via the Google Apps Marketplace can try Kerika without first having to get authorization from your Google Apps Admin. Authorization is actually needed only when you want to upload files to your Kerika boards.
Our direct signup users can benefit from Google Apps (Sheets, Slides, Forms, etc.) even if they had previously not used these apps. Direct signup users will be able to create new Google Docs; something that previously was limited to people using Kerika+Google.
How this will work:
Kerika will have a master Google Drive account, and inside this we will create separate, access-controlled folders for each (direct sign up) user. This will bring all the Google Docs functionality to our direct sign up users.
From a security perspective, we believe this will be good: each user’s project files are stored in a separate folder within Kerika’s Google Drive, and each user has access only to their own folders.
We believe this is good in terms of privacy, too: because Kerika has an enterprise Google Drive account, we get the additional privacy protection afforded to paid/business users of Google Apps. (Your files won’t get scanned by Google for any advertising purpose.)
We will do all the work needed to move our direct signup users from Box to Google Drive; no one should be inconvenienced!
OK, another tutorial video done: this time on how to use Kerika with Box.
Kerika works seamlessly with Box for secure storage of all your project files: just sign up as a Kerika user with your Box ID, and all your Kerika files will be stored in your own Box Account, where they will always be under your control.
This tutorial video shows you how.
Intended audience for this video: new Kerika users who want to leverage Box.
The Box Platform has some limitations that you may bump into:
Certain characters are not allowed in file names, e.g. “/”. We noticed people were running into this problem, most probably because they were hitting the wrong keys inadvertently when renaming files.
Kerika is going to take of this silently from now on: if you try to rename a file using a character like “/” that Box can’t handle, Kerika will silently ignore that character in your renaming action.
File names can’t be more than 260 bytes. For people using English and similar languages, this generally means a file name cannot be more than 260 characters (with each character requiring one byte of storage). But for most Asian languages, e.g. Thai or Japanese, one character may require two bytes of storage, because the size of the alphabet is much larger than the Roman alphabet used by English.
This means that in some languages, file names may have to be much shorter, depending upon how many bytes are needed for storing each character, which in turn depends upon the size of their alphabets.
Some folks from Thailand were running into this problem: Kerika will start detecting this better, and provide more useful error messages
People usually don’t pay attention to the question of who owns a particular board, but it is an important question to consider when you create a new board: the Account Owner owns not just the board, but also all the files attached to cards and canvases on that board.
This is not always important (and often not important in day-to-day use of Kerika): our deep integration with Google and Box ensures that everyone who is part of the board team has automatic access to all the files needed for that board, with access permissions managed according to each individual’s role on the board: Board Admins and Team Members get read+write access; Visitors get read-only access.
(And, as people join or leave board teams, or their roles on a particular board’s team changes, Kerika automatically manages their access to the underlying project files, regardless of whether these are being stored in Google or Box.)
But when someone is planning to leave an organization, the question of ownership can suddenly become important: you don’t want an ex-employee to continue to own critical project files.
Changing ownership of boards was not something that was easily done in the past — there were workarounds, but they were fairly cumbersome and obscure — and we mostly handled these as special requests, on a case-by-case basis.
With our newest update to Kerika, this is no longer the case: changing the ownership of a board is a simple process that can be initiated at any time by the current owner of a board:
You can ask any other Kerika user, who has signed up the same way as you did (i.e. either as Kerika+Google, Kerika+Box, or by directly signing up) to take ownership of a board. Because this is a consequential action, not something you should rush into, you are asked to confirm your intention by typing the word “YES”:
Once your request is sent off to the other user, the board is in a frozen state: existing members of the board team can continue to view the board, but no one can make any changes:
If you change your mind, you can cancel the request before it has been accepted. This can be done by selecting the board from your Home Page:
You can also find your pending request in your Sentbox, and cancel it from there:
Note: once a board’s transfer is complete, it can’t be undone by you. If you really need to get ownership back of a board, you will need to ask the new owner to transfer the board to you.
An important caveat for Kerika+Google users
We try to ensure that files attached to a Kerika+Google board have their ownership changed at the same time as the board itself is transferred, but there are some limits to how Google will allow for a change in ownership:
All Kerika-related files are stored in a set of folders in a user’s Google Drive, organized by account and board.
Google let’s us change the owner of a folder, so we can make sure that when a board is transferred the ownership of the associated Google Drive folder is also changed.
However, for the individual files contained within the folder, Google only allows for a change of ownership of files that are part of Google Docs: documents, spreadsheets, presentations, forms, etc.
Files like images (.jpg, .png, .gif), zip files, and PDFs, for example, retain their old ownership between the Google API doesn’t let Kerika change the ownership of these “non-Google-formatted” file types.
Updating your photo is easy: you can either upload something from your laptop, or get something that’s already online, e.g. your LinkedIn profile photo:
If you are a Kerika+Google or Kerika+Box user, it will look a little different, since we never see your Google or Box password (and hence are in no position to help you change it), and we also rely upon Google/Box to give us your name and photo:
If you have signed up directly with Kerika, we use the Box Platform to store your files for you — Box is a secure, reliable cloud service and we have been a partner with them for several years.
But we do all this for you: efficiently, quietly and behind the scenes.
Which means you may never notice (and, really, you shouldn’t have to…)
However, we found that some users automatically block third-party cookies (this is a browser setting available in all types of browsers).
This was causing problems for the preview function for these users: when a user clicks on a file attached to a card or canvas, that’s getting stored in Box by Kerika for that user, we use Box’s Preview function in the form of an IFRAME.
Using an IFRAME enables us to add some Kerika-specific features, like automatic version tracking, to the standard Box Preview function.
This, however, requires users to allow Box.com to set a cookie, and this can fail if the user has never permitted Box.com to set cookies, or is automatically blocking all third-party cookies in their browser: when you are using Kerika.com, Box.com is effectively a third-party to the connection.
We want to make sure people understand this can be a problem, so we have added some smarts to Kerika to detect when people who have signed up directly are blocking Box.com.
If this is the case, a pop-up dialog box will appear explaining why the Preview function won’t work correctly without allowing Box.com’s cookies to be stored in the browser.
Privacy & Cookies Policy
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.