Tag Archives: Search

About the Search function.

Some improvements for Task Auto-Numbering

We got feedback from some users after our last big release on how we could improve the user experience for folks who like to use the auto-numbering feature for Task Boards, and we have made these changes:

When you open a task, it’s number is shown (but can’t, of course, be edited)

Screenshot showing the Task Details dialog with numbering turned on
Editing a Numbered Task

You can now search for a numbered task simply by typing “#number” in the Search box

Screenshot showing how search by task number works
Search by Number

Kerika’s New Search Capabilities

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.

Screenshot showing Task results from Search
Search Task Results

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:

Screenshot showing Task Filter options for Search
Task Filter

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.

Screenshot showing Document Results from Search
Search Results for Documents

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:

Screenshot showing Documents Filter options for Search
Documents Filter


Amazon burped a little on the weekend

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.

If we did our job well, no one will notice.

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:


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.


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.


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?


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…




A quick refresh to Kerika, before we take a holiday break

We did a quick refresh to Kerika today, and we will be quiet for a while our development team — which is based in India — takes a well-earned Diwali break for about 2 weeks.

Today’s new refresh includes the following:

  • “Critical” has been added as a status flag for cards; you can also search for Critical cards with Advanced Search.

We will be back after the break with more great stuff rolling off the presses 🙂

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:


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.

Partial searches just got easier in Kerika

Thanks to feedback from users at Washington State’s Department of Fish and Wildlife (hat-tip to Ryan Koval & team!) we improved our Search feature to make it easier to do wild-card searches.

Wildcard searches let you easily find anything, anywhere in Kerika, by just typing in a little bit of text — as little as a single character — and get back results that match on that text.

(Of course, typing in just a single character will return too many results to be useful… 🙂 )

In general, there are two ways to do partial searches:

  • By implementing wildcards in the query that the Kerika user interface delivers to the Solr search engine that we have implemented.
  • By using a NGram Filter or an EdgeNGram filter.

Using filters could result in a huge increase in disk space utilization, and a significant drop in performance, so we opted for the wildcard approach instead.

To implement the wildcard query, we manipulate two variables in Solr: PARTIAL_MATCH_BOOST and EXACT_MATCH_BOOST.

  •  If you search with just one keyword, we show you the exact matches first, and then partial matches: we use PARTIAL_MATCH_BOOST and don’t use EXACT_MATCH_BOOST.
  • If you search with multiple keywords, we show you the results that match across all keywords first, using EXACT_MATCH_BOOST, and don’t use PARTIAL_MATCH_BOOST.

There are more ways of fine-tuning search, of course, but for now we seem to have made enough of an improvement to keep our users happy!

A great new Search feature

We updated Kerika today with a great new Search feature that lets you find anything you want, across every card, canvas and project board, across your entire Kerika world!

There’s a short (1:13) video to our YouTube channel that provides a good overview:

Search works across your entire Kerika world: every project board and template to which you have access. This includes projects where you are part of the team, of course, but it also includes public projects created by other folks, like the Foundation for Common Good in the UK, and the transnational WIKISPEED project.

Basic Search will work for most people, most of the time, but we have also built a very powerful Advanced Search feature that lets you zoom in any card on any board or template, using a variety of criteria.

Here’s an example of Basic Search:

Example of basic search
Example of basic search

The most likely (top-ranked) item is shown at the top of the list, and is automatically selected so that you can quickly go to it if you are feeling lucky 😉

For each item that matched your search, Kerika provides a ton of useful metadata:

  • It tells you the name of the card, project or template that matched. (In the example above, it is Identify key players.)
  • If the match was on a card, it tells you the name of the project (or template) board on which the card is located, and the name of the column where the card is located. (In the example above, it is Kerika pilot at Babson College.)
  • It shows a small snippet of the search match, so you can decide whether it is what you were looking for.
  • It even tells you what attribute (aspect) of the card matched your search. (In the example above, the card matched on some text within a canvas that was attached to the card.)

If you want to really zoom in on a particular piece of information, use the Advanced Search feature:

Accessing Advanced Search
Accessing Advanced Search

The first step towards zooming in is to narrow your search, by focusing on project names, template names, or individual cards:

Accessing Advanced Search
Focusing your Advanced Search
Focusing your Advanced Search

If you are searching for specific cards, you can further narrow your search to focus on titles, descriptions, chat, attachments, people, status, color, and tags:

Options for searching for cards
Options for searching for cards

Searching by different aspects (or facets) can give very different results, as this composite of three searches shows (click on image to enlarge):

Searching by facets
Searching by facets (Click to enlarge)

Other options include searching by people; here, for example, we are trying to find all the cards that are assigned to a specific person:

Searching for People
Searching for People

Any combination of facets is possible: for example, you could search for all cards assigned to someone that are waiting for review.

So, that’s Search in Kerika, the only task board designed specially for distributed teams!