Introduction
For all but the smallest of sites it is useful to provide visitors with the means to search for content within your site.
The system has several components to provide this functionality, to handle different types of site.
External search systems
You can, of course, use external 'plug-in' search tools, such as Google Site Search, however external systems have several weaknesses compared to using the built-in components:
- They aren't up to date: they are based on regular crawls of the site
- They don't understand the semantics of the pages: they don't know which information is most important
- They either cost more, or come with advertising
- They won't give you logs of the searches
- They can't easily handle intranets or secure sections of sites
Structured and unstructured data
The first stage in building a search system is to understand the nature of the information being searched.
If the site is simple a set of pages, with text on them, then this is what we call 'unstructured' data.
Here 'unstructured' refers to the fact that the text is placed directly on the pages, and does not originate from database Tables, it's isn't a comment on the visual layout of the information.
If the data to be searched is stored in Tables, then it is structured data. This is commonly the case for product catalogues or directories.
Generally we use different components for structured and unstructured data, and either search one, or the other, although it is possible to provide a combined search that will do both.
Searching unstructured data
To search unstructured data on the site, we use the Search component.
Add the Search component to the site.
In its Behavior Editor, Settings, Options you can configure what gets searched, and how the results are displayed.
For example, you can:
- select which parts of the site are searched
- choose whether searches should ingnore word fragments (matching bits of words, or complete words)
- choose whether the searches should be logged (for later marketing analysis)
- select how many results are shown per page
- select how long the snippets of the matching pages are shown in the results
- choose whether to highlight the matches when the user then visits a page from the results
The search page provides a form for entering the words to be found, however it also provides a 'satellite search box' which can be embedded on other pages.
Typically this can be embedded in a Layout Element to provide a simple search box on every page of the site.
It can also be embedded on external sites, even sites built with other technologies, as it is provided as a simple link to a javascript file.
Searching structured data
Searching data that is stored in Tables provides more control, both over the way the information is searched, and the way the results are presented.
When we search unstructured data, the unit searched is the page – whereas with structured data the unit searched is the record. This means with structured data the results can be more meaningful, and there is no 'contamination' from situations where several records are displayed on the same page.
With structured data we are searching Fields – for example in a product database we could be searching on the “Title” and “Description” fields – and for the best ranking of the results we can specify that matches in say the Title field are more significant than matches in the Description field.
To implement a structured search page:
First build your database within the system (for ease of description we'll assume it's a product catalog, but it could be anything).
For that you'll use a Table to store the data, a 'List products' Query to show a list of products, with a Custom View to show how that is displayed, another Query to retrieve the full product details, and a Custom View (or Sale View, if it's ecommerce) to display the full individual product details.
Now in this simple example the 'List products' Query will be embedded on a page, and will be listing all the products in the catalog.
To build a search system, we embed that same Query on another page (named, say ' Search products'). However when we embed it we choose to use a Search View. Then when the page is visited, instead of showing the list of products, it will show a search interface, in which the user can type what they are looking for. When they submit that, they are then shown the records from the Query, but only those records that match the search request.
So, before embedding the Query on the 'Search products' page we need to add a Search View component, and configure it.
The essential configuration here is to to choose which Fields the search should examine for matches.
The Weight that can be entered against each such field allows greater significance to be placed on matches in some fields than on others.
Typically shorter fields - headings or title fields – will want to have a higher value than longer descriptive fields. You will need to experiment with your particular dataset and some sample searches to determine the best values for your site. A weight of 1 for long fields and 1.2 for short ones is a good starting point. You can leave all the weights at 1 if you don't need this aspect.
The Search View's Behavior Editor, settings, Options provides additional configuration, including the ability to specify a list of common 'Stop words' that should be ignored by the search.
