Out of the Box
The Google Search Appliance ships with a full-function — but no thrills — XSL template (XSLT) that we refer to as the ‘out of the box’ user interface. It looks a little bit like google.com did a few years ago – lots of blue and white, and very few graphics. But it does support all of the enterprise features that the GSA includes, such as Dynamic Navigation, Document Preview, Expert Search, and more.
You can think of the XSLT as a skin on top of the XML results that the GSA produces. When you run a search, the GSA generates an XML document with your results, and then optionally applies an XSL template of your choice to that XML. The XSLT converts the XML into HTML, and then the GSA’s web server delivers the HTML to your browser.
So, should I use the XSLT template?
I’m sure everyone just wants to know if they should use the on-board XSLT engine or consume the raw XML in a custom application. Which option is easier or more flexible? This is a complicated question, and I think looking at the advantages of each method is the best way to approach it. I will preface this comparison by saying that about 80% of our customers use either the default XSLT, or a custom XSLT. About 20% consume the XML directly. This surprises a lot of people. But we have found over and over that the simplicity of using the on-board XSLT engine trumps the flexibility of consuming the raw XML. There is very little that we cannot accomplish with an on-board XSLT. It’s an elegant language, and Google’s XSLT engine is powerful.
On to the comparison:
Advantages of using an on-board XSLT:
- No additional infrastructure is necessary, such as application servers or web servers.
- The GSA’s XSLT engine is tuned to perform very well, even under high load.
- Features like Dynamic Result Clusters, Query Suggestions, Document Preview, and Click Tracking require real-time communication back to the GSA. A custom application must broker all of these requests back to the GSA. If you serve the UI directly from the GSA, all of these interactions happen seamlessly.
- Google’s default XSLT is almost 6000 lines line long. Don’t underestimate all of the complexities it handles. If you build your own application, you assume all of these responsibilities.
- The GSA can pass large result sets or large amounts of metadata internally to the XSLT engine, and then output only the final results. This can significantly reduce the total processing and transit time.
Advantages of building an off-box custom application (extracting the raw XML from the GSA):
- Can easily embed data from other sources during server-side execution, such as header/footer components, advertisements, or values for select-lists. The on-board XSLT engine cannot fetch any external data during its execution.
- Can use the programming language and application server of your choice. The GSA only supports XSLT 2.0 and certain XPath 1.0 functions, and you cannot define or include any others. You can do a lot with the available functions and with templates, but some advanced sorting, for example, requires custom functions, which are not allowed.
- Can make and combine several GSA searches into a single response page, without the user seeing all of the individual requests.
- Can export results in any format. The XSLT engine on the GSA will only output XML or HTML mimetypes. A custom application could convert search results into Excel or PDF, for example.
What if I really want to consume the raw XML?
If you choose to fetch XML from the GSA and build a custom search application, you must rebuild all of the features that the default XSLT handles (or at least the ones you are interested in). The following section describes the level of difficulty to rebuild various aspects of a typical GSA search UI:
Easy (minimal work – all information is present in the main XML results):
- Basic search box
- Main results
- OneBox results
- Spelling corrections
Medium (some additional proxy logic or multiple requests required):
- Pagination, sorting
- You must proxy each subsequent query back to the GSA, adjusting the paging or sorting parameters as you go.
- Dynamic Navigation
- When you click on a filter, you must carefully recreate the metadata filter that gets passed to the GSA, including escaping special characters. When the page reloads, you should give a visual indication of which filters have been applied (the GSA template gives an indication in the filters section and as a breadcrumb above the results).
- Dynamic Result Clusters (Related Searches)
- Query Suggestions / Autocomplete
- Click Tracking (Self-Learning Scorer)
- The GSA XSLT can insert a click-tracking event to observe which results the user clicks on and improve the ranking over time. Your custom UI must generate these same kind of click events, and your custom app must proxy the events back to the GSA server-side.
- Expert Search
- Your application must make a second request to the GSA to fetch the Expert Search results (in either XML or HTML) and include them on the results page . You can either do this synchronously or asynchronously, since you have gone the custom route.
Hard (proxy requests, security tokens, and picky HTML, oh my!):
- Document Preview
- Language Translation