If you use the “file picker” that’s built into Kerika to add an existing Google Drive or Box file to a card, canvas or board — for a Task Board, Scrum Board or Whiteboard — you will see a message that says the file is being copied.
This is the file picker:
Clicking on the File Picker button brings up the File Picker dialog:
And this is the “copying…” message that’s shown.
So, what’s happening?
Well, Kerika stores all your Kerika-related files in a set of special folders within your Google Drive or Box account, if you are using Kerika+Google or Kerika+Box, and these are organized neatly into folders corresponding to each of your boards.
It’s a similar structure if you are using Kerika with Google:
Keeping all the Kerika files together in a set of related folders makes things cleaner for you: when you look at your Google Drive or Box Account, you know exactly what’s being used by Kerika, and what’s other stuff.
And this is why we make a copy of your existing Google Drive or Box file when you use the File Picker: it enables us to put a copy into your Kerika-specific folders, where it is easier to share with the rest of your project team.
For example, suppose you are in the middle of writing a chat message, but in order to complete it, you need to go off and look at another card’s details, or maybe a file attached somewhere else on the board?
You can leave aside a chat in mid-stream, go somewhere else in Kerika, return to the chat, and pick up where you left off!
That’s because Kerika uses your browser’s local cache storage to keep your unsent message: it means your changes aren’t lost while you go look at something else in Kerika.
This is a handy usability fix we have always had in Kerika, but it may be one that folks didn’t realize existed…
We are pleased to announce that our technical collaboration with Box continues, and Kerika has now been named a “Box Pro Partner” reflecting the strong ties we have built between the two companies as we continue to integrate with Box’s cloud services
We use a number of Amazon Web Services, including one called Simple Queue Service which Kerika uses to handle communications between our main project database server and a separate server that handles the Search function.
As with all search engines, Kerika’s Solr engine does a full indexing of the database only once: when the database is rebuilt for any reason (which happens very rarely), and after that it does incremental indexing which means that it only looks at changes made to individual boards, cards, and canvases.
Using a queue helps us manage the load of traffic going to the search engine server: in the unlikely event that a lot of people make a lot of updates to their Kerika boards at the same time, Solr won’t get overwhelmed with a sudden burst of new indexing.
There are lots of ways to implement queues in software — in fact, studying queuing theory is a standard course in all computer science programs — and at this point most apps, like Kerika, prefer not re-invent that particular wheel: instead, it is more cost-effective to use some standard queuing facility that’s available as part of the underlying platform.
AWS works very well in our opinion — it has very high reliability across most of its services — but like all software, it isn’t entirely infallible.
Over the weekend we observed a small handful of errors in our services logs where it looked like SQS had a temporary problem.
We cross-checked this time period with other activity on Kerika, and determined that about 7 Kerika boards may have been affected: not in terms of any data loss or corruption on the board itself, but in terms of some changes not being updated in the search index.
Now, 7 boards is a tiny portion of the entire Kerika project database, which numbers in the hundreds of thousands of boards, but we are glad to have spotted the potential for trouble and have re-indexed the data on these particular boards.
It turned out we had an internal problem with routing requests for such accounts, when they were made from within the Kerika app itself, as a results of which we must have seemed very unresponsive to some folks who never heard back from us. Our apologies for this!
Anyway, if you would like to get a free Academic & Nonprofit Account, which lets you have an account team size of up to 10 people, please let us know by emailing firstname.lastname@example.org. That might be the most reliable way of getting in touch with us…
Unlike so many other collaboration tools that make it difficult for you to create as many boards as you like, Kerika was always designed to make it very easy for you to redesign your work as needed: start new boards, move cards or canvases from one board to another (using Cut, Copy and Paste), and to move ideas and content from one context to another.
Many of our competitors don’t offer this kind of flexibility: either the software makes it hard, or their billing model actively discourages you from creating multiple boards.
That will never be the case with Kerika: we will always support flexibility in how you organize and manage your boards.
Still, our interchangeable use of “projects” and “boards” was definitely causing some confusion, which we have fixed with our latest release by using the term “Board” consistently and avoiding use of the term “Project”.
So, if you were a Project Leader previously, you are now a Board Admin on that board. Your rights and privileges remain the same, it’s just your title that changed.
When you start a new board, what used to be called “New Project” is now labeled “New Board” to make it clear what you are doing:
We post our tutorial videos on both YouTube and Vimeo, and get far more traffic on YouTube than we do on Vimeo.
But, as we go through a review/refresh of our website, we are switching over to Vimeo for embedding these tutorials, because Vimeo provides a cleaner look that seems to be less intrusive within our own design.
Here’s the same video, embedded from YouTube (on top) and Vimeo (on bottom):
The YouTube video has a weird grey shadow on the top part of the thumbnail, like it was deliberately trying to provide a retro, cathode-ray-tube (CRT) look.
(We are not fans of CRTs; don’t own vinyl any more…)
But, if there are several Project Leaders for a board, it might be one of the others who added somebody to your board, and they might not have discussed this with you…
So, Kerika makes sure you know whenever the project team on any board has changed in any way:
If someone has joined,
If someone’s role has changed,
If someone has left.
(After all, someone could have left the team on their own, without telling you!)
Whenever there is a change in the project team, the Board Settings button on the top-right of the board will appear in orange.
Click on the Board Settings button, and you will see the Team tab is highlighted: this is Kerika’s way of drawing your attention to this particular tab within the Board Settings display.
When you go over to the Team tab, you will see that the new person’s name is highlighted in orange, for a few seconds. It’s a discrete yet very effective notification from Kerika, drawing your attention to the presence of someone new on the team.
The same kind of notification is used when someone’s role on the team is changed, e.g. from Team Member to Visitor.
Kerika also tries to let you know when someone has left the team, by highlighting the Project Settings button in orange, and the Team tab within the Project Settings in orange as well.
Smart notifications, from Kerika — the only work management system that’s designed specially for distributed Lean and Agile teams