Feeds:
Posts
Comments

Say you are indexing a database or XML file and you want a specific column or XML node element displayed on the search results page but you don’t want to that column to be searchable.

 

The first step is to make sure the column or XML element is included in your features.txt file.  This tells ODE to include that particular data element when it ingests the database row or XML item.  ODE calls that data element a feature

 

The next step is to tell ODE that you do not want that feature included in the index.  

 

Go to your features.txt file and locate the feature name.   

 

Add the following line to the feature definition block:

 

  build_ir: no

 

Because ODE is updated periodically be sure to check the ODE InfoCenter at IBM InfoCenter Link for the latest info.

 

 

 

 

 

If you are just getting started with ODE, then you may not have run into this:

 

The changes you made to key files such as default.prp may be overwritten when you apply fixpacks. 

 

This isn’t really a problem if you know about it ahead of time.   Just create a separate file with your settings for each of the key files and include the in the appropriate file using the %include statement.

 

And mischief managed!

 

 

 

 

 

 

 

 

Next week I’m starting a series on tidbits and tips for OmniFind Discovery Edition that I have found helpful.   It’s not always easy to locate information you need when looking in the ODE InfoCenter.  It’s often there but unless you know what you are looking for it takes some sleuthing.   To make it easier I’ve included links into the InfoCenter in some of the upcoming blog entries.  Let me know how that works for you.

 

The first tip I’ll pass on is this:

 

If you visit the ODE InfoCenter be sure to limit your search scope to OmniFind Discovery Edition.  Otherwise you are likely to find yourself on pages that won’t help you … and may even do more harm than cause “mere” confusion.

 

If you have questions, alternate solutions, or tips, please send them on!

Symptom: Your users have no clue why certain items were returned

 

Ever get a search result set and not be sure if you’ve gotten what you were expecting?  That can happen no matter how hard you work on your site’s data and metadata – but you can reduce the times it happens.   You have to give enough information so they know whether a link is relevant to their search.

 

Your first line of defense (offense maybe) is your document and product titles.   Brief, meaningful, descriptive titles go a long, long way in helping your customers know whether they ought to click on a link in a result set or not.  

 

Another possibility is to write descriptions in such a way that the first sentences both identify the product and differentiate it from other products.  

 

A more recent trend is the use of roll-overs that actually give a small snapshot preview of the page that you about to click on.  Not only is that “cool,” It gives users more information to make a decision without making them leave the current search page.  

 

Read other ways to know if your internal site search engine has a problem…

Your search engine makes non-relevant results appear at the top of your list

 

I went to one site looking for screw drivers.   Guess what came up?  Knives!   Now I have thought about using a knife on a screw before – but it’s not usually my first choice.  (BTW, just in case you haven’t tried that, don’t.  I won’t go into details why – but if you do, keep a first aid kit handy.)

 

Now back to the site search for screw drivers.  What had happened is that the knives were special commando-type knives that had everything but the kitchen sink attached – including a variety of screwdrivers.  The company did indeed have screwdrivers but they didn’t appear until page two of the search result set.   I wish that somebody had taken some time to adjust the weighting of search result sets so products that were either in the “screwdriver” category or actually had the word “screwdriver” in the title would appear at the top of the list. 

 

Read other ways to know if your internal site search engine has a problem…

Symptom: Your search engine makes the user guess at the right term — without feedback

 

Listen, I actually like playing the game 20 Questions.  I find that I do that a lot with the Internet Search engines (Google, Yahoo, Microsoft, etc.)  I really don’t mind.  I think that’s because I realize that the universe of information that these search utilities bring together and make accessible via a search interface is so diverse.  It’s a marvel that it works really and testament to the companies making it work.  .Well, I suppose I did get irritated a little with the “faucet” search I wrote about earlier … but it wasn’t too bad.

 

What really gets me is when I go to a company’s website and find that I have to know THEIR wording in order to find anything via their site search.   This isn’t just a matter of using synonyms.  Sometimes there are idioms and phrases that need to be linked together.  I wonder how many customers leave a site and go to a competitor’s website when they don’t find anything because they used the “wrong” search terms.   I want to write them and say, “Guys, how often do you check your search logs and see what search statements aren’t returning many or any hits?”    There are search engines that will “translate,” if you will, search terms from what a user enters into terms that you use on your site.   Sometimes this is done automatically – especially with common misspellings.   Sometimes it requires manual intervention based on examination of the log files.

 

Read other ways to know if your internal site search engine has a problem…

 

 

 

 

Symptom: Your search engine gives the user different results when they enter plural and singular forms of the same word

 

There’s nothing worse than making a customer guess when they don’t have to.  The other day I was looking for some information on repairing a leaky faucet.  I went to Google and entered “faucet.”   A wonderful thing happened.   I expected a long list of entries and was prepared to slog through them.  What I didn’t expect was that there as a search tip for “faucet repair” right there at the top of the page.  I clicked on it and Wow!  I found what I needed.   I called my wife to show off my new-found resource.   I had closed the window so the impact of my knowledge would be even more impressive.   Imagine my surprise (and my wife’s amusement) when I entered the search term “faucets” yet again . . . and came up with a long list AND no search assist for faucet repair!   What went wrong?   I had entered the singular form the first time and the plural form the second time.   (BTW, that’s when she told me -again- “Just call the plumber.”)

 

Read other ways to know if your internal site search engine has a problem…

 

One of the decisions that you need to make is how will you build your user interface for your search results page.  You have two basic options: Use the Out-of-the-Box version or build your own.

 

 

Out-of-the-Box User Interface – ODE’s Layout Editor

 

In one situation, a client decided to enhance the out-of-the-box (OOTB) search functionality by using OmniFind … very late in the implementation process   The deal was that we could include it if we used ODE’s layout editor to rapidly prototype and implement a search results page.  The trade off is that we would have limited ability to customize the look and feel.   The good news is that the OOTB user interface is quite good and ODE’s management console provides a good interface for adding and placing various WebSphere Commerce related widgets.   To give the briefest of overviews, the layout editor uses a grid layout.  You can add widgets and “sub-grids,” if you will, to the master layout grid.  There are a number of widgets that can be included.  I especially appreciate the WebSphere Commerce-specific widgets.  Overall, pretty nifty.   

 

 

Custom User Interface: Two Approaches

 

Another client (with more lead time) wanted a more customized search results page than is available.   One thing about the OOTB layout editor is that while there is some room for modification, it is difficult to do wholesale customizations.   It’s not that you can’t modify the layout.  It’s just not easy.   If time is a factor, you are likely to find yourself in a crunch.  

 

If you want a customized interface, you will probably want to build your them using the available JARs:

 

OneStepRuntimeJspLib

 

OneStepRuntimeAPI

 

Obviously, one JAR has a JSP component and one doesn’t.  The easiest way to describe the difference between these two JARs is to have a high-level understanding of the basic flow of an ODE application:

 

-          Pre-Query execution

-          Query execution

-          Post-Query execution

 

A differentiator between these two JARs occurs in the Query execution step. 

 

JSP API

If you are using the OneStepRuntimeJspLib JAR, query result objects are placed in a JSP’s PageContext and objects can be accessed and manipulate from the JSP.  ODE comes with a tabbed navigation sample application that you can study to see how this approach works.   The sample uses JSP fragments.  Be forewarned.  This approach requires considerable JAVA coding on the page.   Some WebSphere Commerce developers do not like this (or the Layout Editor’s JSP fragments) because they feel it is inconsistent with the approach used in WebSphere Commerce.

 

Non-JSP API

If you want a cleaner separation between the search layer and the presentation layer, you will probably want to build a JavaBean using the OneStepRuntimeAPI JAR and encapsulate the data generated by the various result objects.  Since there is not a sample application, you’ll need to start from scratch.  It’s not hard.  It just takes time.

 

 

There are times when using the JSP API will work for you and you will never look back.   If you plan to or think you are very likely to use ODE to power many different functions within your site, you may want to look seriously at using the non-JSP API.   While it requires more effort up front, you are likely to find that you have more flexibility to make changes later.  Personally, I prefer having a cleaner separation between the search data layer and the JSP presentation layer.

 

 

When I look at an ODE application at a high level, I divide the process into three parts:

 

Pre-Query Execution

This is where you can set ODE parameters for a given search. 

 

Some possible parameters include: search string entered by the user, store to be searched, price range and other search constraints.

 

Query Execution

This part is really easy.  It’s simply a line of code that reads something like Query.execute().   This step creates a number of objects used in Post-Query execution.  An important consideration is where you access these objects when building a user interface

 

Post-Query Execution

This is where you access a variety of query result objects such as the main result set, drill down information for faceted results, business rules activated by the search query and results, feedback on any special search statement manipulations performed by ODE, etc.  How you access the objects depend on which JAR you decided to use.

 

I like OmniFind Discovery Edition.   It has a lot to recommend it.  I’m not going to go into all its benefits here but suffice it to say that I’m impressed by its versatility

 

Yes, there are other search engines that you may want to consider depending on your need and budget.  Some options to consider are: Lucene, Solr, Endecca.   I have used the first two.  I haven’t had the opportunity (yet) to work with the third but I hope to at some point. 

 

In this thread of my blog, I’ll share different tidbits and experiences about how I’ve used OmniFind Discovery Edition and observations about possible gotchas and things that worked out well.

 

If you use OmniFind Discovery Edition, I invite you to share your experiences or point me to your blogs on the topic.

« Newer Posts - Older Posts »