West announced that they are now integrating with Recommind’s Mindserver search platform: West km Integration with Recommind Delivers Knowledge Management Capabilities in New Ways
Peter Fleischer, global privacy counsel for Google, wrote an opinion piece in the Financial Times: Google’s search policy puts the user in charge.
He points out how personalization can help make a better search for the user. Using his example of Paris, you can see the disparate results in the Google [Google Results]. I find is useful to run the same search on Clusty.com, where the search results are organized by topic [Clusty Results]. Are you searching for Paris Hilton or Paris France?
The question that arises is whether personalized search belongs should be used in the enterprise?
Google’s method of personalizing the search is based on prior searches that you run (once you have elected to have them track your searches). Presumably, they could also customize the search based on user profile information that you provide. For example, if I search for Toyota, the search results should have more websites from Boston (where I am) than Kansas.
Of course personalized search on the internet raises privacy concerns. And since many user profiles are fictitious, leveraging the user profile may be of less value than tracking search results.
The same concerns are not as true for a search inside the enterprise. User profile information is generally detailed and verified. However the search history is generally much more scarce. (I find users much prefer to browse on the intranet and search on the internet).
A typical user would not be as shocked by the intranet recognizing who they were and displaying information personalized for them. I actually think it is good intranet design to have some of the content, especially the starting page, personalized for the user.
That personalized content is easy to explain why they may see different content (You are in the Boston office so you see the Boston weather, while someone in the San Diego office sees the San Diego weather).
With the search results personalized, it is harder to explain to a user why they may see one set of results and someone else sees a different set of results.
I prefer the clustering of results around topics over personalization of the search. Putting the extra context around the results makes it easier to focus on what you are looking for. You can then replicate the findings from user to user making it easy to share content across the enterprise.
The question in filing or storing material is not, “Where do I put it?”
It should be “Where do I find it?”
You can have the most sophisticated storage systems available, but if you don’t know where to find what’s inside, you’re no better off than having stacks of stuff all over the place.
One of the underlying principles of knowledge management is the sharing of material (i.e. information). As we break down the barriers to sharing, we need to break down the barriers to finding. We need to avoid replacing silos of information with silos of searching.
My colleague, David Hobbie, thought I should supplement my earlier posts on searching for precedents and research with what makes a good precedent.
Research is about content.
Precedent is about context.
When conducting research the search is focused around the words in the document. When searching for a precedent the context around the document is generally more important than the words in the documents itself.
Here are some factors in a document’s context that make a good precedent:
Looking at this list, few if these factors will be evident merely from the words in the document. And to the extent the words are in the document, they probably appear very few times. For example, in a mortgage, the state of the property may only appear once in the jurisdiction section of the document.
We have successfully been using WestKM for substantive legal conduct. It is a successful tool for conducting research on our internal documents.
For precedent searches, we are looking at West KM Transactional and Real Practice. They both use some intelligent indexing to identify some of the good precedent factors mentioned above and control your search using these factors.
The problem with these tools is they move away from users request for a single text box search, like Google. Although, the tools improve a particular type of search they start creating silos of searches on top of our silos of documents.
Lucas McDonnell updated his list of essential knowledge mangagement sites and blogs.
I updated my KM Sites Search, based on the Google Custom Search to add his updates, and a few of my own.
Using my KM Sites Search, you can search all of those blogs and sites at the same time, and just those sites. The box below will run the search. You can go to full page to see the list of sites an blogs being searched.
A “precedent” search is a search for a model document.
Generally, the key to finding a good precedent is knowing the context in which a document was previously used, rather than text in the document itself.
An example is: ” a purchase and sale agreement for a retail shopping center in Florida”. “Purchase and Sale Agreement” will be in the text of the document and the name of the document. But “Florida” and “retail shopping center” may not appear in the text of the document. If they do appear, they would appear infrequently.
They key to making a precedent search working is leveraging the document metadata against other systems. For instance, we require users to assign a document to a particular matter. We plan to use that matter identification to pull information from other sources and impute that information on the document.
The other key to a precedent search is using a faceted search to narrow the search results using the additional metadata.
A “research” search is when the user is looking for documents on a topic. The user may not know if any documents on the topic even exist. The search is typically for keywords in the document.
An example is: information on “arms-dealing”.
A user will expect a list of documents displayed by relevancy.
An enterprise search tool excels at this type of search. The user is looking for terms in the document. The enterprise search tool can use its algorithm to identify which documents have the most treatment of the search terms.
A typical DMS will fall short on a “research” search. A typical DMS does not rank searches based on relevancy. If a search yielded dozens or more results, the user would have no reference as to where to start a review of search results. A typical DMS also has an inferior text search engine.
It is the frustration when running a “research” search that users cry out for an enterprise search tool.
A “recall” search is when the user knows the document exists and has some specific information about the document that the user can distinguish it from other documents.
Examples are: documents edited in the last five days, all the documents for a particular matter, all of the purchase agreement for a client.
The user will expect a a list of documents that will be over-inclusive, but the list will have information to distinguish the particular document the user is looking for from the rest of the documents.
A DMS excels at this type of search and is core functionality for a DMS. The enterprise search will generally not perform well at this type of search. For the DMS search to be successful, user input is required to make sure the metadata/profile of the document is accurate.
A “fetch” search is when the user has a document ID (with a Document Management System) or a file name (with a file server system).
The user would expect the single document to be returned. There should be no need for relevancy rankings.
The “fetch” search is the most basic of the four types of searches. It is such a basic part of a DMS and works so well in a DMS that most users do not even think of it as a search. Nonetheless, it is the most common search and the most important. A user expects to be able to get a specific document back instantly for editing or reuse, without having to interpret search results.
A “fetch” is core functionality of a DMS. An enterprise search tool would fall short in this type of search. The DMS is keyed to find specific metadata from the document profile. The enterprise search tool typically uses the metadata to influence the relevancy rankings of a particular document.
In reviewing user behavior, I have identified four different types of searches for documents:
Separate posts will follow with more information on each type of search and user expectations for search results. The posts will also discuss how well a document management system (DMS) or enterprise search tool will handle the different types of searches
© 2012 Doug Cornelius .com. All Rights Reserved.
Powered by WordPress. Designed by 
