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)
You can now search for a numbered task simply by typing “#number” in the Search box
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 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.
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.
We have an updated tutorial video on how real-time Search works in Kerika, across all your projects and templates:
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:
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:
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:
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…
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:
We will be back after the break with more great stuff rolling off the presses 🙂
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:
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.
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:
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.
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!
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:
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:
If you want to really zoom in on a particular piece of information, use the Advanced Search feature:
The first step towards zooming in is to narrow your search, by focusing on project names, template names, or individual cards:
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:
Searching by different aspects (or facets) can give very different results, as this composite of three searches shows (click on image 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:
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!