Taking the 'Ooh' out of Google: Getting site search right - Part 11
During the course of this series of articles, I've looked at various elements of interface design which have been employed, for better or for worse, across a wide range of European newspaper websites. Today I'm going to wrap up the series by laying out a step-by-step transformation of Google's search results listing into something that presents users who opt for 'site search' with a richer UI experience.
In part 2 of this series, I looked at how Google's default search results layout give us a clue to the 'map' of information that Google holds about our articles. Everything Google knows has to be gleaned directly from the HTML, so there is no additional metadata or structured information displayed to the searcher.
Instead of sticking with the HTML title for the page, which is likely to include extraneous information like the global site branding, present the exact and full title of your article. Don't truncate it like Google does.
Think about transforming the snippet of text that you display underneath the article headline.
Google dynamically selects a chunk of text from your page, because it is near to, or involves the first use or most dense use of the search terms. However, since you have access to the data from your CMS, you know exactly where the start of the article is. That means you can opt to show an editorially selected description or snippet, using the opening paragraph, stand-first or tag-line from an article. For a news site, this can give users a search results page with a much easier to understand overview of the topics of the articles that have been returned.
As an example, if you are searching for 'Cuba' on a newspaper site, the first paragraph will give you a much better indication of whether an article is about Cuba or just mentions Cuba. You can't immediately glean this understanding if the snippet displayed features the sole mention of Cuba in an article, which is how Google would display it.
You certainly should always display some type of snippet however, unlike La Dernière Heure in Belgium. Their results display is compact, but lacks vital information which can help the user decide if a result is relevant.
Again, because Google has obtained their information from scraping the HTML of your published article, they don't know who the author is. On this page, for example, they can see some HTML that says 'Written by Martin Belam'. However, if in the course of a post, I mention that I've enjoyed a piece written by Dan Taylor, and another recent blog entry written by Karen Loasby, then Google can't definitively pin me down as the author from the HTML alone.
By contrast, if your CMS and site search are working in tandem, then you know exactly who wrote every article, and you can feed that back to searchers in the results.
This is another case where your CMS information is vastly superior to that belonging to Google. Google knows the date that it first crawled your webpage, and it knows the timestamp of the HTML page you published, and it knows the last time it successfully accessed the page. But you know the exact moment it was published. So again, let users and searchers know in the search results page.
Google also offers a limited ability to time-slice web results - so you can consider offering users a way to narrow down their results to a specific date range. This allows for a more accurate refinement of results than can be achieved on Google's regular web search.
In tomorrow's final part of this series, I'll be looking at further transformations you can make to the standard search results listing, by including images, structured data, and providing additional search related services.