Reaching Findability #3

Findability is surprisingly complex due to the large number of measures needed to be understood and undertaken. I believe that one of the principal challenges lies within the pedagogical domain. This is my third post in a series of simple tips for reaching Findability.

Link your information assets!

Often, the information needed to efficiently perform a certain task is spread out in different locations. Just imagine the amount of applications, web pages and windows you need to open on an average workday! These systems all have their own interfaces and sets of content and rules, which often leads to cognitive stress on the individuals using them. A lower overall efficiency than one might expect follows.

A search platform is one way of simplifying everyday work for these individuals, by making information in several systems available from one single location. And in one interface, that acts the same regardless of what information I am looking for.  This can be achieved by linking several data sources using a search platform, effectively creating an Enterprise Search solution. The benefit for certain processes and individuals can be dramatic.

The foundation for an Enterprise Search solution is a well-planned architecture and control of the most important and strategic information assets. One of the success factors is planning big but starting out small. While the long-term goal might be a common search platform, the first project could very well aim for connecting only one or a few data sources. That way, the platform is realized in small, manageable steps, all leading toward the same goal. With the right prioritizations, business value is created every step of the way. New ideas can be tested and problems mitigated before the consequences become difficult to handle.

What types of systems and data sources can be linked together in your Enterprise Search platform? All that we have come across in some hundreds of projects; intranets, web sites, ERPs, document management systems, file shares and databases. To mention a few.

Reaching Findability #2

Findability is surprisingly complex due to the large number of measures needed to be understood and undertaken. I believe that one of the principal challenges lies within the pedagogical domain. This is my second post in a series of simple tips for reaching Findability. You can also sign up here for a subscription to a free email course on this topic!

Take control of the technology!

The right search technology is an important foundation for making your information findable. There is a plethora of good search products on the market, all of them with different properties and strengths. The right products are those that fulfill your needs at the lowest cost. Therefore, to make the right choice, you must have a good understanding of your requirements.

A good search engine is specialized in figuring out what you’re actually intending to find, even if you only type a single word with ambiguous meaning. The search engine can make the difference when the exact term or spelling is not obvious, or a word is simply misspelled. It can also increase the relevance of search hits by only displaying results in languages you understand, and prioritizing results that are relevant in your current context.

With the right search platform in place, making a correct set-up and configuration is vital. While the initial installation may seem simple, taking advantage of the more powerful functions is complex and requires deep knowledge of search and information management.

If you lack access to a search platform, think again! Maybe your organization is using SharePoint, which in many versions contain a powerful search engine. Maybe you are using a search engine on the web site, which can also be used for other purposes or vice versa. Sometimes it pays off to investigate what technologies are already employed by the organization and look for new applications.

Feel free to contact me if you wish to discuss this further, anders.nilsson@findwise.com or sign up here to get our free email course.

Presentation: Enterprise Search in SharePoint 2013

Presented by Paula Petcu and Ludvig Aldrin at Microsoft Campus Days, #cddk12, 31 October 2012, in Copenhagen Denmark.

Learn how easy it is to build powerful search experiences using SharePoint 2013.
The presentation will showcase the Search in SharePoint 2013 and provide a technical and functional walkthrough of what is new.  The presentation will take you through the out-of-box search experience, and you will get tips and tricks on how to extend the search platform to create a great custom experience for your users. Also discussed is the new search architecture and how search plays a central role in the new SharePoint 2013.

The presentation is divided into three parts. The first part will include an overview of search and will walk you through the out-of-the-box search experience, showcasing the new or improved functionalities and discussing how this affects the search experience. This part is all about finding what the users are looking for and getting answers to their questions. The new product revolves around the user more than ever, and you will be able to see this in the new search experience.

Then information about about the new search architecture, and this will make the transition to the second part of the presentation, which is all about extending. And a bit about executing queries under the new architecture and more specifically on how to extend the way they are executed.

Prior to SharePoint 2013, the only way to inspect and manipulate managed property values for items before being added to the search index was by extending the item processing pipeline in FAST Search for SharePoint. Clients using SharePoint search were out of luck as the functionality was not available to them. Now, MS has introduced three new items for content processing and enrichment: parsers, custom entity extractors, and web service callouts. These new features will be featured and one of the demoed.

But what happens next to the search engine? The third part of the presentation will be about the governance of your search solution. More specifically, it will focus on search analytics.

OmniFind Enterprise Edition 9.1 – New Capabilities Discussed Over Breakfast

During the last year a number of interesting things has happened to IBM’s search platform and the new version, OmniFind 9.1, was released this summer. Apart from a large number of improvements in the interface, the change to basing the new solution on open source (Lucene) has proven to be a genius by-pass of some of OmniFinds previous shortcomings.

The licensing model is still quite complicated, something Stephen E Arnold highlighted earlier this year. Since a number of our customers have chosen to take a closer look at OmniFind as a search solution we decided to host a breakfast seminar together with IBM last Thursday, in order to discuss the new features and show how some of our customer are working with it.

Without a doubt, the most interesting part is always to discuss how the solution can be utilized for intranets, extranets, external sites and e-business purposes.

Apart from this, we also took a look at some of the new features:
Type ahead (query suggestion), based on either search statistics or indexed content

Type ahead

Faceted search i.e. the ability to filter on dates, locations, format etc as well as numeric and date range. The later is of course widely used within e-business.

Facets for e-business

Thumbnail views of documents (yes, exactly what it sounds like: a thumbnail view for first page of documents in results page)

Thumbnail of a document

Search analytics in OmniFind 9.1 holds a number of interesting statistic capabilities. Some things worth mentioning is number of queries, query popularity, number of users, average response time (ms) and worst response time (ms).

Save searches (to be able to go back and see if new information has been included), search within result sets (to further narrow your result set within a given result set) and did-you-mean functionality (spell checking) are also included.

..and improvements on the administrator side, just to mention a few:

  • Ability to change the relevancy i.e. to adjust and give certain types of information higher ranking
  • Support for incremental indexing i.e. to only re-index the information that is new or changed since the last time you made it searchable

To conclude: IBM is making a whole lot of improvements in the new version, which are worth taking a closer look at. During the spring we are running upgrading projects for some of our customers, and we will keep you up-to-date with the different application areas OmniFind Enterprise Edition 9.1 is being used for. Please let us know if you have any particular questions or have areas that you are interested in.

Real Time Search in the Enterprise

Real time search is a big fuzz in the global network called Internet. Major search engines like Google and Bing are now providing users with real time search results from Facebook, Twitter, Blogs and other social media sites. Real time search means that as soon as content are created or updated, it is immediately searchable. This might be obvious and seems like a basic requirement, but working with search you know that this is not the case most of the time. Looking inside the firewall, in the enterprise, I dare to say that real time search is far from common. Sometimes content is not changed very frequently so it is not necessary to make it instantly searchable. Though, in many cases it’s the technical architecture that limits a real time search implementation.

The most common way of indexing content is by using a web crawler or a connector. Either way, you schedule them to go out and fetch new/updated/deleted content at specific interval during the day. This is the basic architecture for search platforms these days. The advantage of this approach is that the content systems does not need to adapt to the search platform, they just deliver content through their ordinary API:s during indexing. The drawback is that new or updated content is not available until next scheduled indexing. Depending on the system this might take several hours. Due to several reasons, mostly performance, you do not want to schedule connectors or web crawlers to fetch content too often. Instead, to provide real time search you have to do the other way around; let the content system push content to the search platform.

Most systems have some sort of event system that triggers an event when content is created/updated/deleted. Listening for these events, the system can send the content to the search platform at the same time it’s stored in the content system. The search platform can immediately index the pushed content and make it searchable. This requires adaptation of the content system towards the search platform. In this case though, I think the advantages outweighs the disadvantages. Modern content systems of today are (or should be) providing a plug-in architecture so you should fairly easy be able to plug in this kind of code. These plug-ins could also be provided by the search platform vendors just as ordinary connectors are provided today.

Do you agree, or have I been living in a cave for the past years? I’d love to hear you comments on this subject!

High Expectations to Googlify the Company = Findability Problem?

It is not a coincidence that the verb “to google” has been added to several renowned dictionaries, such as those from Oxford and Merriam-Webster. Search has been the de facto gateway to the Web for some years now. But when employees turn to Google on the Web to find information about the company they work for, your alarm bells should be ringing. Do you have a Findability problem within the firewall?

The Google Effect on User Expectations

“Give us something like Google or better.”

 

“Compared to Google, our Intranet search is almost unusable.”

 

“Most of the time it is easier to find enterprise information by using Google.”

The citations above come from a study Findwise conducted during 2008-2009 for a customer, who was on the verge of taking the first steps towards a real Enterprise Search application. The old Intranet search tool had become obsolete, providing access to a limited set of information sources only and ranking outdated information over the relevant documents that were in fact available. To put it short, search was causing frustration and lots of it.

However, the executives at this company were wise enough to act on the problem. The goal was set pretty high: Everybody should be able to find the corporate information they need faster and more accurately than before. To accomplish this, an extensive Enterprise Search project was launched.

This is where the contradiction comes into play. Today users are so accustomed to using search as the main gateway to the Web, that the look and feel of Google is often seen as equal to the type of information access solution you need behind the firewall as well. The reasons are obvious; on the Web, Google is fast and it is relevant. But can you—and more importantly should you—without question adopt a solution from the Web within the firewall as well?

Enterprise Search and Web Search are different

  1. Within the firewall, information is stored in various proprietary information systems, databases and applications, on various file shares, in a myriad of formats and with sophisticated security and version control issues to take into account. On the Web, what your web crawler can find is what it indexes.
  2. Within the firewall, you know every single logged in user, the main information access needs she has, the people she knows, the projects she is taking part in and the documents she has written. On the Web, you have less precise knowledge about the context the user is in.
  3. Within the firewall, you have less links and other clear inter-document dependencies that you can use for ranking search results. On the Web, everything is linked together providing an excellent starting point for algorithms such as Google’s PageRank.

Clearly, the settings differ as do user needs. Therefore, the internal search application will be different from a search service on the web; at least if you want it to really work as intended.

Start by Setting up a Findability Strategy

When you know where you are and where you want to be in terms of Findability—i.e. when you have a Findability strategy—you can design and implement your search solution using the search platform that best fits the needs of your company. It might well be Google’s Search Appliance. Just do not forget, the GSA is a totally different beast compared to the Google your users are accustomed to on the Web!

References

http://en.wikipedia.org/wiki/Googling

Six Simple Steps to Superior Search

Do you have your search application up and running but it still doesn’t quite seem to do the trick? Here are six simple steps to boost the search experience.

Avoid the Garbage in-Garbage out Syndrome

Fact 1: A search application is only as good as the content it makes findable

If you have a news search service that only provides yesterday’s news, the search bit does not add any value to your offering.

If your Intranet search service provides access to a catalog of employee competencies, but this catalog does not cover all co-workers or contain updated contact details, then search is not the means it should be to help users get in touch with the right people.

If your search service gives access to a lot of different versions of the same document and there is no metadata available as to single out which copy is the official one, then users might end up spending unnecessary time reviewing irrelevant search results. And still you cannot rule out the risk that they end up using old or even flawed versions of documents.

The key learning here is that there is no plug and play when it comes to accurate and well thought out information access. Sure, you can make everything findable by default. But you will annoy your users while doing so unless you take a moment and review your data.

Focus on Frequent Queries

Fact 2: Users tend to search for the same things over and over again.

It is not unusual that 20 % of the full query volume is made up of less than 1 % of all query strings. In other words, people tend to use search for a rather fixed set of simple information access tasks over and over again. Typical tasks include finding the front page of a site or application on the Intranet, finding the lunch menu at the company canteen or finding the telephone number to the company helpdesk.

In other words, you will be much advised to make sure your search application works for these highly frequent (often naïve) information access tasks. An efficient way of doing so is to keep an analytic eye on the log file of your search application and take appropriate action on frequent queries that do not return any results whatsoever or return weird or unexpected results.

The key learning here is that you should focus on providing relevant results for frequent queries. This is the least expensive way to get boosted benefit from your search application.

Make the Information People Often Need Searchable

Fact 3: Users do not know what information is available through search.

Users often believe that a search application gives them access to information that really isn’t available through search. Say your users are frequently searching for ”lunch menu”, ”canteen” and ”today’s lunch”, what do you do if you do not have the menu available at all on your Intranet or Web site?

In the best of worlds, you will make frequently requested information available through search. In other words, you would add the lunch menu to your site and make it searchable. If that is not an option, you might consider informing your users that the lunch menu—or some other popular information people tend to request—is not available in the search application and provide them with a hard-coded link to the canteen contractor or some other related service as a so called “best bet” (or sponsored link as in Google web search).

The key learning here is to monitor what users frequently search for and make sure the search application can tackle user expectations properly.

Adapt to the User’s Language

Fact 4: Users do not know your company jargon.

People describe things using different words. Users are regularly searching for terms which are synonymous to—but not the same as—the terms used in the content being searched. Say your users are frequently looking for a ”travel expense form” on your Intranet search service, but the term used in your official company jargon  is ”travel expenses template”. In cases like this you can build a glossary of synonyms mapping those common language terms people tend to search for frequently to official company terms in order to satisfy your users’ frequent information needs better without having to deviate from company terminology. Another way of handling the problem is to provide hand-crafted best bets (or sponsored links as in Google web search) that are triggered by certain common search terms.

Furthermore, research suggests that Intranet searches often contain company-specific abbreviations. A study of the query log of a search installation at one of Findwise’s customers showed that abbreviations—query strings consisting of two, three or four letters—stood for as much as 18 % of all queries. In other words, it might be worthwhile for the search application to add the spelled-out form to a query for a frequently used abbreviation. Users searching for “cp” on the Intranet would for example in effect see the results of the query “cp OR collaboration portal”

The lesson to learn here is that you should use your query log to learn the terminology the users are using and adapt the search application accordingly, not the other way around!

Help Users With Spelling

Fact 5: Users do not know how to spell.

Users make spelling mistakes—lots of them. Research suggests that 10—25 % of all queries sent to a search engine contain spelling mistakes. So turn on spellchecking in your search platform if you haven’t already! And while you are at it, make sure your search platform can handle queries containing inflected forms (e.g. “menu”, “menus”, “menu’s”, “menus’”). There’s your quick wins to boost the search experience.

Keep Your Search Solution Up-To-Date

Fact 6: Your search application requires maintenance.

Information sources change, so should your search application. There is a fairly widespread misconception that a search application will maintain itself once you’ve got it up and running. The truth is you need to monitor and maintain your search solution as any other business-critical IT application.

A real-life example is a fairly large enterprise that decided to perform a total makeover of its internal communication process, shifting focus from the old Intranet, which was built on a web content management system, in favor of a more “Enterprise 2.0 approach” using a collaboration platform for active projects and daily communication and a document management system for closed projects and archived information.

The shift had many advantages, but it was a disaster for the Enterprise Search application that was only monitoring the old Intranet being phased out. Employees looking for information using the search tool would in other words only find outdated information.

The lesson to learn here is that the fairly large investment in efficient Findability requires maintenance in order for the search application to meet the requirements posed on it now and in the future.

References

100 Most Often Mispelled Misspelled Words in English – http://www.yourdictionary.com/library/misspelled.html

Definition of “sponsored link” – http://encyclopedia2.thefreedictionary.com/Sponsored+link

Customer Service Powered by Search Technology

I was on the train, on my way to Copenhagen and UX intensive a four day seminar hosted by Adaptive Path. Looking forward to this week I was also contemplating the past year and the projects we’ve been working on. I recently finished a project at a customer service organization at a large company. The objective was to see if the agents (employees) helping customers could benefit from having a search platform. Would the search engine help the users in finding the right content to help their customers?

Our point was off course that it would, but it was up to us to prove it. And we did. The usages tests showed results better than I would have dared to hope for.

  • All users found it to be easier to search for information than browsing for it.
  • Searching helped the users not only in finding information faster, but finding information they didn’t know where to find or didn’t even know existed.
  • All users preferred using the search functionality instead of navigation for information.
  • The search functionality helped new employees learn the information they needed to know in order to help the customers, hence they were productive faster.Less time was spent asking for help from colleagues and support since users found the information they needed by searching for it.

These results are all very positive, but the most overwhelming thing for me in this project was the level of engagement from the users. They really enjoyed being a part of the evaluations, bringing feedback to the project team. They felt that they were a part of the process and this made them very positive to the change this project meant.

Change is often a hard thing in development projects. Even if the change is better for the end users of the system, the change in itself can still be problematic making people hostile to the idea, even though it is improving their situation. Involving users not only helps in creating a good product, but also in creating a good spirit around the project. I have experienced this in other projects as well. By setting up reference groups for the development process we have not only managed to get good feedback to the project but have also created a buzz about what’s happening. People are volunteering for being participants in our reference groups. This buzz spreads and creates a positive feeling about the change the project is bringing. Instead of dreading the users are welcoming the change. It’s user research at its best.

So the next time you are asking yourself why you should involve users in your project and not only business stakeholders – think about how not only the end product, but the project and the process as a whole, could benefit from this.

Search Driven Process to Increase Content Quality

Experience from recent and ongoing search and retrieval projects have shown that enterprises have got a better and deeper insight in their content when deploying a new search platform and search driven solutions. Not only in unstructured content repositories, but also in structured sources. As information is indexed and is visualized in a more user friendly way it doesn’t take much time before the people responsible find content issues that are brought out in the light. Content that e.g. is misplaced, tagged wrongly, documents with poorly defined security information etc. Issues that earlier were hidden due to lack of a holistic view of content. This leads to setting up search driven processes to increase the content quality.

It has been said that before enterprises should think of deploying an enterprise search solution one is recommended to get a completely clear picture of all it’s content; but maybe one should reformulate this and also think of an enterprise search solution as a supporting tool in the process when improving the content as well.

Taking it a step further would be to allow write-backs from the search engine to content sources to enrich and improve quality and completeness of stored information. Tune search quality and content quality at the same time! Make the content quality assurance process search driven!