GSA UI: Should I use the on-board XSLT engine?

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.

The GSA’s ‘Out of the Box’ XSL template, with several features enabled.

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.

But the process doesn’t stop there.  The HTML can include JavaScript commands that cause your browser to interact with other asynchronous services on the GSA (like Document Previews and Dynamic Result Clusters) or with Google’s cloud services (like Google Translate).  Expert Search, for example, makes a complete second search request to the GSA, which itself runs through the XSLT process (although a slightly different XSLT, called expertsearch.xsl, handles most of the rending this time around).  The HTML produced for the Expert Search results is appended to the page by the JavaScript.

So, should I use the XSLT template?

A Java application consuming multiple XML queries from the GSA and combining them into a single page.

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.

Good UX Means Good Business

In a world where technology is rapidly advancing and user expectations are rising, it’s no longer enough to have an average user experience; to delight your users and surpass your competition you must strive for the exceptional.

Get the Guide

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?

A fragment of the XML returned by the GSA when you run a search.

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
• KeyMatches
• 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)
  • This data comes from a JSON service on the GSA that is typically invoked asynchronously after the initial results load.  JavaScript on the page must make these requests and format and display the results.  Your custom app must proxy the requests back to the GSA server-side to avoid same-origin policy restrictions.
• Query Suggestions / Autocomplete
  • Autocomplete suggestions come from a JSON service on the GSA that is typically invoked asynchronously as the user types.  JavaScript on the page must make these requests and format and display the suggestions.  Again, your custom app must proxy the requests back to the GSA server-side.
• 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
  • There is a lot of JavaScript and HTML involved in displaying document previews.  You can borrow the GSA’s JavaScript if your HTML closely matches the default HTML.  You must also run the GSA XML through an identity-transformation instead of just retrieving the raw XML, or else the Security Token and other important data needed to retrieve the document previews will not be included.  By running the XML through an identity-transformation, the GSA will insert those dynamic values into the XML.
• Language Translation
  • If you want to borrow Google’s JavaScript for this feature, your search results HTML must very closely match what the GSA generates.  You must also follow the steps mentioned for Document Previews to get the Security Token.