Help! Our designer is becoming a hipster…

We are facing a small crisis over here at Kerika… Our designer has turned hipster.  Apparently he has been drinking hand-crafted beer from a Mason jar while watching the sunset from the rooftop.  It might have something to do with the temperature hitting 61 degrees Fahrenheit today, which pretty much qualifies as mid-summer in Seattle.

Beer from a mason jar
Beer from a mason jar

 

Kerika’s UI will probably change real soon. Expect it to get more hip.

How long things stay in the Clipboard

When you copy or cut an item on a Kerika board — a set of cards, or may be some things sitting on a Canvas — these objects are placed in a special Clipboard that sits on the Kerika server, not in your browser.

This is important to note for several reasons:

  • Because the Clipboard is on the server, you won’t lose the items if your network connection breaks before you have a chance to paste whatever you cut.
  • The Clipboard will hold on to the items for 20 minutes, to give you time to think about where you want to put them. (And, to recover from any network problems you may have experienced.)
  • If you don’t paste something that you had previously cut, the Clipboard “releases” it back to where it was originally, after waiting 20 minutes to go by while you ponder. But, if you are impatient, you can reverse your cut action sooner simply by clicking on the cut items, which continue to appear in a faded (greyed-out) appearance on your board.
  • Because the Clipboard is on the Kerika Server, other team members won’t see the change until you actually do the paste. So, for example, if you have cut some cards from a Task Board or Scrum Board and haven’t pasted them yet, your project team members will continue to see the items on the old board until you complete the paste.
  • And, finally, here’s a great feature, thanks to the Server Clipboard: one of your team members can be making changes to a card while you are in the process of cutting-and-pasting it, and those changes aren’t lost. That’s because the object is stored on the server rather than your browser, making it possible for your team members to make changes even as you are in the process of doing a cut-and-paste.

Upgrading our server infrastructure

We had problems occasionally with our servers running reliably, and if you were unlucky you may have noticed this.

Well, it took a very, very long time but we have finally figured out what’s happening.

It turns out that the garbage collection function on the Java Virtual Machine that runs our server software (all on a Linux virtual machine running on Amazon Web Service) was having problems: most of the time the garbage collection runs just fine on an incremental basis, taking up only a fraction of a second of CPU time, and periodically the JVM would do a full garbage collection as well.

The problem we are facing is that sometimes this full garbage collection would fail and immediately restart.

In the worst-case scenario, the garbage collection would start, fail and restart over and over again, until the server basically thrashed.  And each time the full garbage collection ran, it took 5-7 seconds of CPU time (which is a really long time, btw).

We are trying to understand the best long-term solution for this, but in the short-term we can mitigate the problem in a variety of ways, including upgrading our server virtual machines to have more RAM.

One reason it took so long to debug is that we were chasing a red herring: we had noticed network spikes happening frequently, and we wrongly assumed these were correlated to the server’s CPU load spiking, but this turned out to be coincidental rather than causal.

Sorry about all this.

Avoid using these characters when you name your projects

Some characters shouldn’t be used when you name a project — and we are going to make a change in Kerika that will rename any old projects you have to replace these characters with blank spaces — because they cause problems when you need to export the cards on your Task Board or Scrum Board.

Here’s what you need to avoid:

  • Forward slash (“/”)
  • Backward slash (“\”)
  • Colon (“:”)
  • Semi-colon (“;”)

When you do an export, the exported data are stored in a file in your Google Drive (if you are using Kerika+Google) or your Box account (if you are using Kerika+Box) and these characters are used by these cloud services as file separator characters, which means they cannot be part of a file name.

So, your export will fail (and we end up logging an error on our server, which doesn’t make us happy either)

We did make a change in Kerika a month ago that stopped new projects from using these characters in their names, but it looks like there are still a bunch of old projects out there that have these characters in their names, and now we are going to try to clean up these as well.

Search for Retrieval, Exploration and Discovery

We have been giving a lot of thought recently to how we can improve the Search function in Kerika, and in the process found ourselves thrashing between different design approaches — all of which seemed deficient in some respect.

To get a better grip on the problem we decided to put aside all of our designs and step back to think more deeply about the basic uses of Search.

We concluded that there are three trajectories of Search that we need to consider:

SEARCH FOR RETRIEVAL

When you are trying to find something you have seen before: an old card, an old project, and old chat message.

You know for sure that the item exists; you just don’t remember where you last saw it.

The goal for a Search function in this scenario is to minimize user frustration by reducing the number of clicks needed to find and retrieve it.

This assumes, of course, that the object that you are trying to retrieve does really exist: if its your memory that’s faulty, then the goal of the Search function must be to convincingly demonstrate that the target object doesn’t exist.

It’s easy to imagine examples of Search for Retrieval in the context of a Kerika user:

  • “Where’s that contract that Arun signed last week?”
  • “Where’s the card where Arun and I discussed making changes to the contract?”
  • “Where’s the canvas where Arun laid out the product vision?”

Search for Retrieval is not an important use on the Web, when you are using Google or Bing, because important items are more often bookmarked or scrapbooked for faster and more secure retrieval: if there is a Web page you need to return to often, you are going to rely upon your bookmarks more often than a new Google search.

But in a content management system like Kerika, which also integrates conversations, tasks, processes and people, Search for Retrieval is a critical use case.

SEARCH FOR EXPLORATION

Exploration differs from Retrieval in one fundamental way: the user wants to use something that exists as a starting point to discover other items that are related.

Exploration is about attacking a problem area from many different angles: you might not be  certain what content exists that’s relevant, but you are certain that some relevant content does exist.

Examples of Exploration in Kerika might include:

  • “Where are all the bugs we have fixed regarding this feature?”
  • “Where are all the contracts we have signed for this kind of work?”
  • “Who are all the people who have worked on search engine technology?”

For Exploration to succeed, we need to create moments of delight: if a user can easily find related information that they were really hoping does exist, then the experience of quickly finding this information is sheer delight — and delight is a completely different emotion than the absence of frustration.

Exploration is possible on the Web with Bing and Google: the search engines try to help you auto-complete your query, offer suggested searches, and try to cluster results by type: e.g. here are all the images that match you search, and here are all the videos that match your search.

SEARCH FOR DISCOVERY

Discovery is closer to Exploration than Retrieval, but different enough from both that we think it is worth considering as a separate search trajectory in it’s own right.

With Discovery, you are hoping to find something, but have no real certainty that anything exists.

This the crucial difference between Discovery and Exploration: with Exploration you are fairly certain something exists, but are not sure in what form the information exists, or where it can be found. With Discovery on the other hand, you are really venturing into unknown territory, with no assurance that anything might be found.

In the context of a Kerika user, Discovery might take the form of questions like:

  • “Have any bugs every been reported for this feature?”
  • “Has anyone ever looked at this issue?”
  • “Is any work happening with this client?”

With Discovery, we need to combine elements of both Retrieval and Exploration when considering the user interface: if no information exists, then how quickly can we let the user know that there is nothing to be found? In other words, how can we reduce frustration?

On the other hand, if something does exist that is worth discovering, how can we present the search results with good information scent?

CONCLUSION

It’s probably hard to support all three search trajectories equally well: we need to decide which search trajectories are most important in the current context of the user.

We could try to get clues from the user’s current view of Kerika — which project or page she is looking at, and which one she was looking at before — to try to guess which type of search trajectory she has in mind, but these guesses are not likely to be very accurate, and forcing the user to go down the wrong trajectory can be both frustrating and counter-productive.

We are still exploring these ideas, but look for a new Kerika Search in the coming weeks…

 

 

 

Exporting just a subset of a Task Board or Scrum Board

A tiny change in labeling in our latest version will, we hope, make it clear that Kerika’s Export feature is actually pretty smart about managing the amount of data that you export from a board:

Exporting subset of board
Exporting subset of board

What used to say “Export cards” now says “Export the cards shown”.

“Cards shown” means just what it says: if you are hiding some columns from view, or filtering your view of the board to show just those cards that match particular colors or tags, then only the cards currently shown are going to be exported.

This makes it really easy for you to manage what information goes into an export: if you don’t want the Backlog of a Scrum Board to be included, for example, just hide the Backlog from view before clicking on the Export button.

Kerika (not) in China

One of our users, normally resident in Poland, is in China right now on vacation, and found to his disappointment that he couldn’t login to his Kerika+Google account.

Actually, he couldn’t login to his Google Account at all.

This is disappointing to hear, but not entirely surprising: Google has had problems making its services available in China for a long time, and so Kerika+Google becomes collateral damage in this larger conflict…

The only long-term solution would be for Kerika to offer its own signup and file storage mechanism, which is something we have considered in the past but is not high on our priority list right now because we have some other stuff we want to build first that’s going to be simply amazing.

Which is good news or bad news, depending upon whether you are in China right now or not…

Archived cards are not included in your 6AM task summary email

When you archive a project, it’s possible that some cards still had Due Dates set on them: these dates are preserved along with all the other project data at the time you do the archiving.

But, these dates, which will inevitably become overdue dates over time, are not included in your 6AM task summary email, because there’s nothing you can do about them while the project remains in the Archive.

Kerika makes FOIA one-click easy

If you work for a government agency in the United States – at the Federal, State, or Local level – you are subject to various public disclosure requirements, thanks to the Freedom of Information Act and various other federal and state “Sunshine” laws.

(And, if you work for a governmental organization anywhere in the European Union, that’s going to be true for you as well.)

Kerika makes it one-click easy for you to meet you disclosure requirements, thanks to the Archive and Export feature:

Archiving freezes a project, presumably in it’s “done” state: everyone who used to have access to the project still does, but all cards, canvases and documents associated with that project are made read-only.

This means that you now have a pretty good record for what a project looked like when it was completed: what work was done, by whom, and which documents were used and what conversations took place.

And the kind of integrated, comprehensive view of a done project is something that you can get only from Kerika: the old mix of SharePoint and Project and regular email just doesn’t work!

Exporting is the other piece of the disclosure puzzle: with just one mouse click, you can export all (or some) of the cards in a board, in CSV or HTML format.

Exporting in HTML is particularly helpful when meeting disclosure requests because the HTML output can be easily edited, using Microsoft Word for example, to take out items that need to be redacted for security or privacy reasons.

That’s the difference with a modern project management and team collaboration software like Kerika: the worst part of your government job just became one-click easy.