Tag Archives: OmniFind

May 16 2011

I’ve believed in Web Experience Factory (aka Portlet Factory)!

by Dave Jacob, Managing Partner

Exciting opening session with lots of applause around using Web Experience Factory (Portlet Factory) to enable mobile displays for web pages with a simple theme builder. The shift for WEF from a portlet development tool to a total web development tool has been a dramatic shift in positioning for the product by IBM.

I’ve believed in this product for the last five years and am glad to see this product succeed in the marketplace.

On a related front, an area that I see in Davalen’s future is an emphasis on search refinements for presenting relevant data on mobile devices. While we have made great strides in the use of roles and profiling to show a user only relevant information that they are authorized to see, we haven’t put the same emphasis on arranging the relevant content in a meaningful order or context. With limited real estate on the mobile device, we have to get much smarter about showing specific content to the user thru making educated guesses as to the relevancy of the content based on this person’s persona and buying habits.

IBM has a robust product in this space – OmniFind® Enterprise Edition , which fills this space. We’ve all got to learn more about this product and how it can help us more closely generate that elusive Exceptional Web Experience.

May 11 2011

Purchased WebSphere Portal? Don’t forget to claim your OmniFind Enterprise Edition license.

Did you know that when you purchase Portal you also receive licenses for the OmniFind Enterprise Edition (OEE) Search Platform?


 So, why is the important to you? 

Within your WebSphere Portal environment, OEE enables you to

  • Implement document-level security,
  • Index multiple data-sources
  • and more…

IBM® OmniFind Enterprise Edition drives users to the information that matters through knowledge driven search.

IBM OmniFind Enterprise Edition (OEE) is designed to integrate with IBM WebSphere Portal to provide robust, scalable and secure search directly from within the portal.

Did you know that with your purchase of IBM WebSphere Portal you are entitled to a single server license for OmniFind.

Why utilize these licenses?

  • Are you focused on document level security to limit who can access documents in your portals?

The WebSphere Portal Search Engine does not provide this level of security.

  • Looking to extend your portals into an Exceptional Web Experience beyond content in your portal?

You need OEE for a more robust search.  OEE can index multiple data sources such as  the internet, Lotus® Connections®,  Lotus® Notes®/Domino®
, Quickr®, QuickPlace®, Lotus Domino Document Manager,  and Windows and UNIX file systems.

Don’t miss the opportunity to explore, experiment, and test for your solution, software, and information integration with OEE in your Portal environment.

*Stop by Davalen’s Gold Sponsor Booth #112 at the IBM Exceptional Web Experience Conference May 16-18, 2011, to discuss this opportunity to integrate OmniFind Enterprise Edition into your WebSphere Portal environment. Click here for more details about Davalen’s sponsorship and expo hours.

Mar 16 2011

Making a Business Case for Effective Search

Peter Wilkerson

by Peter Wilkerson, Search & Discovery Practice Area Manager

In any information-sharing system, one of the hardest pieces to effectively complete is the way users navigate and discover the information they need.  Currently, you cannot simply install a program and expect them to automatically know where and how to complete a search query successfully and efficiently.

Recently I was approached by one of our clients, an online retailer, who was struggling to find a solution to connecting their customers to the right information. They were finding high amounts of clients abandoning their site before even viewing their products. Their current program consisted of using a traditional retail website pattern of building a hierarchical product catalog.  After evaluating their current system, we found the customers were frustrated with the excessive amount of navigation time through the traditional catalog hierarchy they had in place.

Working with the client, we developed a solution that made it possible for customers to navigate to a manageable set of products within two to three mouse clicks.  This particular solution required IBM OmniFind Discovery Edition (ODE). ODE makes heavy use of its ability for faceted searching which has the ability to focus searching based on product attributes provided by the retailer.  You may have seen some basic examples on the Internet where you can choose to breakdown results or products by smaller components such as brand or color. Our client went even farther and identified key attributes that were of most interest to their customers.  This was a very important step as it determined what order customers needed to see the attributes in order to quickly see the product they wanted to buy.

95% of their customers have given the updated navigation an overwhelming approval.

The end result for our client is the increased product conversion rates. Their new rate ties directly into the ability to see a broader results set based on the attributes chosen and no longer relying on the traditional time-consuming catalog hierarchy to find products.

Jan 18 2011

Consuming RESTful Web Services…Why Worry?

Peter Wilkerson

Peter Wilkerson

by Peter Wilkerson, Search & Discovery Practice Area Manager

The recent release of OmniFind Enterprise Edition (OEE v9.1) makes it clear that if you want to create your own user interface for the OEE server, you need to do so as a REST client.   This is part of a larger trend within IBM to make remotely hosted resources available via RESTful services.

SIAPI (Search & Index API), the IBM work horse API used in the past to interact with OEE, now only works with what are called “classic search collections” (basically pre-v9.1 collections which have been imported into v.9.1). There is also the limitation that the SIAPI jars can be used only on a server on which OEE is installed.  Additionally, I read in OEE’s sister product, IBM Content Analytics, that the SIAPI is deprecated with release v2.2 and will not be supported in future releases.

While I have not seen any news on SIAPI being deprecated within OEE, I believe the trend is that it will be deprecated sooner rather than later.

Bottom Line: Design OEE search interface using REST and not SIAPI

Designing a New Search Interface using REST

The exciting part about IBM increasing the number of products providing  RESTful service is that we can build more powerful, customized tooling for our clients.

Take OEE for instance.  With OEE v9.1  we can build a search tool which goes considerably beyond a Google-esque listing of pages-and-pages of search results (which often is not helpful if you don’t find what you want at the top of the list).  We can unleash OEE’s power as a search platform by separating it from its user interface through the  REST service and extend the search interface.

As a result of this uncoupling we have an opportunity to build a powerful, intelligent enterprise search interface when using OEE with WebSphere Portal.  Since we would be building a query object within a portlet and receiving the result object within a portlet we have an opportunity to interact with both objects and  trigger different actions within Portal based on their contents.

For example, we could populate two portlets with search results.  The first would be results based on the search entered.  The second portlet could contain results based on a query augmented by search filters optimized based on a person’s user group credentials.

This means that a person in HR searching would see results in a secondary “HR Search Portlet” more relevant to them. A person in the Marketing would see results in a “Marketing Search Portlet” with documents more relevant to their needs.  In essence, we are making search more relevant to each user by developing different search profiles optimized for each group.

The interface would help users focus on the real purpose of search – finding information they need as quickly as possible to complete the task at hand.

With the ability to build such a powerful and intelligent search interface, this is an incredible business opportunity for the enterprise to take advantage of.

Selected Resources:

Jun 30 2010

Thinking About Search: Using Custom Facets to Improve the Intranet Search Experience

From Peter Wilkerson, Search & Discovery Practice Area Manager

In May, IBM announced the next version of OmniFind Enterprise Edition. When you read through the announcement you will see a number of enhancements and new features. The feature that is of particular interest is “Facets” and how they can be created. This article considers the new combination of functionality and exactly what that means for Enterprise search. If you get complaints that your enterprise search “just doesn’t work,” this article will help you understand how you can help and give you some new solutions to the problem.

Facets can be used in many ways. A common use is to let users filter large result sets based on the attributes of documents in the result set. In the Enterprise, some common facets are document type, department, project code and the like. These are all very useful when searching but, it doesn’t always help people find what they are looking for.

Let’s think outside the box for a moment. How else might we guide our users to documents that they want and need?

What if…
What if we looked beyond attributes commonalty such as a document’s digital attributes and the business context in which it was created or used (document type, department, author, project code, etc.) and add a different set of facets based on a different kind of characteristic – a customer-interest facet? (Sidebar: I describe all individuals using search as customers whether they are searching as members of the Enterprise or B2B/Retail customers).

Here is how I get people to think about customer-interest facets:
If you knew someone from HR was searching your content, what kind of documents would they most likely want to see? How about people from your Marketing Department? Customer Service? People in each of these departments are likely to have a very different idea of the “ideal search result set” – even if they all entered the same search keywords (which is why it seems that you “just can’t win” when you are tuning search).

What can you do?
You need to identify characteristics in these documents that you can use to identify and differentiate how the “ideal document result set” for any given customer group is different than the less useful documents returned. You also need to consider how these differentiators might help you identify the ideal result set for your other user groups. Once you’ve identified these differentiating characteristics, we need a way to “automatically” assign a facet that identifies a document as relevant to a given group. For our HR scenario, let’s say that we assigned a facet value of “HR-relevant” to documents in the ideal result set for HR.

How can you implement this?
There are two pieces of this puzzle. First, you need the ability to influence the sequence of documents in a result set based on facet values and second, you need a way to assign these values to individual documents in a cost-effective way.

In OmniFind EE v9.1, you are able to influence how important any given document is for a given search. Any document can be made to appear higher in a result set than it would have otherwise ummappeared based on the value contained in fields (sometimes called features). In our HR example, if a person is signed in and is identified as an HR worker, then we can “boost” any documents that have a facet (or feature) value of “HR-relevant.”

Next, there is the problem of how to identify which documents out of hundreds of thousands of documents should be marked as “HR-relevant.” It is not cost-effective to have an individual go through all the documents and make that determination. You could assign codes when a document is created but that approach has it’s drawbacks as well. What we need is a way to also assign facet values (and other document metadata) based on patterns.

A pattern can be defined in terms of the intersection of words found in the content, author, document type and other attributes. (There are software packages that can help you identify these patterns.) Once a pattern has been identified and defined, you need the ability to assign a new facet value whenever that pattern occurs. This is where one of my favorite tools comes into play – UIMA.

UIMA stands for “Unstructured Information Management Architecture.” It is a way to extract information based on patterns, presence of keywords/synonyms, proximity of words, parts of speech – all based on unstructured data found in documents being indexed. With Omnifind v9.1, it is possible to assign a new value to a facet field based on the UIMA pattern.

As a result we have a tremendous amount of flexibility when we need to update or refine what documents should be assigned a facet value (say “HR-relevant” for our earlier HR scenario) – all without having to change the content sources themselves.

Bottom Line
Companies who use this approach will find they are able to customize/personalize results sets based on who is searching (probably based on user login and profile information). This capability will lead to higher satisfaction with search in general. An added benefit is that you will also be able to update your search “schema” of how to weight documents and respond to changing needs and new challenges more easily.

Are you interested in learning more about the new version of OmniFind Enterprise Edition? Send me an email to continue the conversation.

Mar 23 2010

Current Project: OmniFind as Preferred Choice

From Peter Wilkerson, Search & Discovery Practice Area Manager

The Search & Discovery practice is working with clients on several different kinds of search-driven projects. Currently, the most interesting of these is for an enterprise that is using OmniFind to drive navigation for a retail site with an extremely diverse set of products. OmniFind is the software of choice to drive the navigation to this website because of it’s capability to filter by using a rich set of descriptive attributes. This approach enables Davalen’s client to provide a more dynamic, responsive user experience in the retail environment, a successful dynamic and responsive interface, which results in a higher revenue as people find exactly what they are seeking to purchase.

Read more articles from author, Peter Wilkerson

Feb 17 2010

Managing Search Complexity through Simplicity

by Peter Wilkerson, Search & Discovery Practice Manager

At the heart of any search solution is a good understanding of the business problem to be solved as well as knowledge of the available content and metadata. You have to work within the confines of the content you have (or can add with content enhancement). You have to analyze that content and be able to describe how you can identify some documents as being relevant for solving a business problem and why other documents are not relevant. That is just the beginning.

Developing an effective search solution is a complex space by it’s very nature. It brings many different pieces together to accomplish specific business objectives. Managing the complexity of search is no simple matter. One of the top challenges faced by businesses is managing this complexity. The key is managing solution complexity and providing an effective solution to simplify the scope of the solution by dividing the space into meaningful layers:

Business Problem to Solve
The end goal is to provide a space where employees, customers and contractors can search for and find accurate and timely information. After all, their job is not to search but to complete some other business process or transaction. Search is a tool for helping people complete their tasks successfully. Understanding the business problem to be solved and how it relates to the larger strategic plan of the business is vital for creating a successful search space.

User Environment
Understanding how many people will be using the system, how they will access it (web, intranet, internet, mobile devices, embedded applications, etc.), and the business processes to be supported.

Search Application
Consists of the Query and Results sub-layers. It is a user interface which consists of various search tooling functionalities. People’s impression of the effectiveness of a search solution is often based on the search interface alone. After all, that is what people see and use. Too often businesses use an out-of-the-box interface without evaluating whether it is designed to solve the business problems driving the need to update search.

Search Tooling
Search tooling is the tool set that a search platform provides to build search applications. Tooling may include search word boosting, relevance tuning, thesaurus, synonyms, stopword lists, facets, taxonomies, search analytics, knowledge extraction tooling, and more. Also included are how content sources are crawled, parsed and indexed. Different search platforms provide different tool sets. Understanding what tooling is available and how they work is key to being able to architect an effective search solution.

Search Platform/Engine
The software that provides the search tooling; whether it is IBM OmniFind Enterprise Edition, Endeca, Autonomy, FAST, Lucene/SOLR or some proprietary solution. In addition to search tooling you also want to pay attention to a platform’s scalability, fail-over, disaster recovery, system management, configuration management, system security and availability.

Content Enhancement
Content enhancement or enrichment is sometimes required in order to develop a search solution that will solve a specific business need. This may mean that third-party data needs to be added to existing data. It may mean that knowledge extraction tools need to be used for unstructured (that is, non-fielded data) data like that found in emails, reports and memo fields in databases.

Content & Metadata
It is important to know the number of documents, content types (email, reports, database records, etc.), average size of documents, annual growth of your data stores, multi-lingual requirements, governance strategy. It is also important to know the types of information that is explicitly available or can be extrapolated via content enhancement. This information will be the basis for building an effective search solution.

Security
Security is a vital piece of any enterprise project. In the case of search, there is user authentication & authorization for accessing the search application and for the data that will be displayed in search results lists. (You don’t want just anybody to view HR data.) Search engine crawlers also require authentication and authorization for access to different data stores at the collection level. And then there is security digital rights management at the individual document level within a given data store. In many cases this is the most complex IT piece of the search puzzle. However, solving this layer alone does not guarantee an effective search solution.

Storage Environment
Knowing the number and types of data stores (portal, file system, FileNet8, Domino, Quickr, Documentum, etc.) is vital. Knowing how frequently the stores are updated and will need to be searched is another key piece of information. It is also know the format that data is stored in (PDF, database, flat files, etc.).

IT Infrastructure
All of the above occurs within an IT framework of many layers in its own right and can include the following layers: network, hardware, operating system, system software and more depending on the environment.

Contact Peter with any thoughts, comments or questions.

———————————————————————————————————————————————————————————————-
This article is from our monthly resource E-Newsletter. Did you miss our monthly eNewsletter? Click here for a full version (only live for 30 days prior to original date) and if you want to begin receiving our monthly newsletter write to Ruth Jarvis and request to be added to our E-Newsletter list.

Feb 2 2010

Search and WorkForce Integration Initiatives: Two Paths

by Peter Wilkerson, Practice Area Manager, Search & Discovery

Increasingly I see more projects focusing on “Search and WorkForce Integration”. Search plays a key part in WorkForce Integration. Search provides accurate and timely information such that:

Workers find the information needed, else they have to reinvent it or decide without it.

During a typical business cycle, a company may find itself at a point where people rely on stale data because search “just doesn’t work right.”

Companies respond to this by taking one of two paths. One path leads them deeper into the forest where relevant data continues to elude workers; Another path leads them out of the woods where search is intuitive and data is easily consumed.

Path 1 . A common IT response is to increase hardware capacity and software complexity. This response can be valid if search is slow and unable to handle indexing multiple file formats, meeting security needs, and similar issues. However, the problem is often not an IT problem but a business problem. If you treat search as an IT problem, then search is unlikely ever to work well. This path only leads deeper into the forest.

Path 2 .Another path understands that a worker’s job is NOT to search for information. Their job is to complete tasks such as analysis, evaluation, support, processing, etc. Workers search for information to find current information, identify reusable resources, solve problems, and make decisions. If you want to know why workers aren’t using intranet resources, data silos, etc., the search related answer is straight-forward:

An information retrieval system will tend not to be used whenever it is more painful and troublesome for a customer to have information than for him not to have it.” Calvin Mooers (aka Mooers’ Law, 1959)

To resolve search problems, decision makers must understand the business problem and design search implementations to meet those needs – to make it easy for people to use their search tool as a means to an end.

This is the area in which Davalen shines. Our experience goes much farther than the ability to install, configure and manage the OmniFind Enterprise Edition search application. We know how to adapt the tooling to solve business problems.

Learn more about our Retail and Enterprise Search & Discovery expertise.

———————————————————————————————————————————————————————————————-
This article is from our monthly resource E-Newsletter. Did you miss our monthly eNewsletter? Click here for a full version (only live for 30 days prior to original date) and if you want to begin receiving our monthly newsletter write to Ruth Jarvis and request to be added to our E-Newsletter list.

Aug 18 2009

Basic Search: It’s like Opening a Store with No Employees

by Chris Barker, OmniFind Practice Area Researcher 

After a few minutes of combing through the store looking for a book, a customer gets frustrated and goes to speak to an employee.

“Hi, I’m looking for a synonym finder…”

After being led straight to the pile of thesauruses he picks one up, thanks the worker, and heads for the check-out as a satisfied (but slightly embarrassed) customer.

This mildly unfortunate brain lapse turned out just fine in the store with a fellow human there to understand and interpret his request. But what happens when this all happens online? Another customer with the same misfortune is using the store’s eCommerce site with the hope of finding a shiny new thesaurus. He clicks on the search bar and types

“SYNONYM FINDER.”

“0 ITEMS match your search.” Frustrated, he moves to the next online store as an unsatisfied (but completely unembarrassed) customer.

The customers business was lost because the online store was using basic search. Leaving customers with basic search is like opening a store with no employees. The average customer feels pretty much stranded after a failed search. So, what’s the alternative? Advanced search.

Advanced search comes in many shapes and sizes, but in general it has more human-like qualities than it’s basic brother. It can range from a message saying, “Did you mean thesaurus?” or automatically correcting to “thesaurus” and pulling up a results page displaying the stores’ wide range of synonym finding books.

I’ll admit that the example I’ve just given sounds a little silly. A more common occurrence is a typographical error in the search bar. For example, searching “backpck” instead of “backpack.” 

Davalen recently researched 267 online retailers using WebSphere Commerce to see who is (and who isn’t) using advanced search. One might believe that it would be impossible to have basic search while companies like Google improve their sites so that even “ejduiy” returns several “Did you mean…” entries. As the results of this research show, that’s not the case.

This study was done simply by testing search capabilities. When each site was visited, a search term to conduct the test was determined. For example, at an online jewelry retailer the search term was established as “bracelet.” To begin the actual test, the search term was entered into the search bar and a search was run. The nature and number of results was noted and the search was cleared. Another search was then completed, this time with the search term spelled incorrectly. In the case of the jeweler, “bracelet” was then spelled “bracelt,” an easily recognized and fairly common typo.

The results of these simple tests shows who is leaving their customers in the dark with basic search and who is offering the most help they can with advanced search.

Out of the 267 sites tested, 140 sites are using basic search. That’s 52%. Over half of the companies surveyed are not doing all they can to help their customers find what they’re looking for. Are you?

———————————————————————————————–

This article is from our monthly resource E-Newsletter. Did you miss our monthly newsletter? Click here for a full version (only live for 30 days prior to original date) and if you want to begin receiving our monthly newsletter write to rjarvis@davalen.com and request to be added to our E-Newsletter list!

Jul 14 2009

Search: Pay Me Now or Pay Me Later

Peter Wilkerson

 by Peter Wilkerson, OmniFind Practice Area Manager

It’s a simple, straight-forward question.

Ignore it during the design phase and your costs will be greater, much greater.

Ignore it until after you build forms and a presentation interface, then you will pay even more.

The question? How will someone else find what I just created?

If a database is involved, some tech folk will say, “The data is in a structured database, simply use SQL.” That answer is the right answer under some circumstances but increasingly it is not.

If there is a keyword search functionality, then some might say to use it. Again, that answer is right under some circumstances but it may not be depending on the need.

If the data created through Lotus Forms, Liquid Office, or any other application is of value to the company, then you had better answer “How will somebody find this?” before you write your first line of code or model your first database.

Otherwise, you will be facing some very unhappy customers and it is very possible that you will be forced to make significant and costly changes to your application – changes which could have been implemented more cheaply if a search and discovery strategy and architecture was part of the original plan.

So, either pay now or pay (more) later but at some point you must ask and answer the question: “How will I find what my application is creating?”

———————————————————————————————

This article is from our monthly resource E-Newsletter. Did you miss our monthly newsletter? Click here for a full version (only live for 30 days prior to original date) and if you want to begin receiving our monthly newsletter write to rjarvis@davalen.com and request to be added to our E-Newsletter list!