Lately I have been working quite a bit with search, and have two customers going live with new sites in the comming months. Along with doing the actual implementations I wrote a (danish) whitepaper on search back in september, and I have read a couple of books to really get into the topic. Search patterns from O’Reilly is a really good book, if you need non-technical inspiration on how search can be done. Having spent some time on the subject, I have of course developed some opinions on both the uability and technical aspects, which is the reason I am writing this post.
UX and business aspects of search
The thing that makes search interesting to me is that no two solutions are or should be the same. It is a chance to work closely with the customer, and build something unique with the knowledge that can be gathered about the users - with the data available.
Good search is tailored to the domain, and it is worked on continuously by evaluating usage statistics, handeling usecases as they arise and thinking about accessibility for new features through search. Depending on the domain and the types of users, search should be built for the specific needs with reguard to precision and discoverability. How exact shoud matches be? To what degree should results mostly be correct or mostly provide discoverability and inspiration for the users? These are some of the things we need to know and they are key questions, in order to provide a good expericende. In some cases users may even be sufficiently different and important to warrent a very personalized approach taking prior knowledge of the individual user into consideration.
To get the most value out of search, data should be collected about what users search for, if they find results that they find interesting enough to click on them and if they get users to take action – which in our eCommerce scenarios mostly means if they end up buying something. Armed with this information we get the chance to continuously improve search, provide a better experience and in the end get more sales and make more money.
Another challenge that search helps tackle is how to provide effecient navigation on mobile devices. This is extremely important, with close to half of your users probably already using either a phone or tablet to surf your site. Unfortunately this is one of the most neglected areas of the web today, with way too many sites failing to provide a good experience on mobile devices. When designing for mobile it often makes sense to take a look at search as well.
Technology needed to make a great experience
On the technical side of things we mostly need to decide on two things. For the backend we need a specialized database or search engine, and on the frontend we use a javascript framework or library for structuring the search page as a Single Page Application – at least as soon as facets are introduced.
There are lots of good choices for a search database, with this being one of the hip subjects as part of the NoSQL movement. At the moment I personally tend to favor RavenDB, because it does text search, suggestions and facets out of the box, all while being .NET and providing nice and easy to use API’s. Solar has the same features and is more battle-hardened, but having had no problems using RavenDB the more native .NET feel makes it win out for me. When all is said and done both are based on Lucene, so I would feel confident that they are pretty much equally good choices.
There are a number of online services that provide search, and this can be fine when adding a standardised kind of search to an existing site, but I am really an advocate of building your site around a search engine, rather than strapping it on using external services. When this is not possible the services are fine, and provide lots of value, but often I feel so much more can be acheived baking search in to the solution.
On the frontend a war is rageing between a bunch of different frameworks and libraries, that aspire to be the tool of choice for building Single Page Applications. I have mostly looked at KnockoutJS, EmberJS and AngularJS, which are very similar. I honestly like all three, but for the time being AngularJS comes out slightly on top. It is really down to nitpicking, but being able to work with Plain Old Javascript objects and the nice tooling for Chrome just tips it in the favor of Angular. Backbone is also a popular choice, that I left out, but my slightly controversial opinion is that it simply does not bring enough with reguard to removing “plumbing code” – I needz my two-way binding!
In one case I actually opted out of using any of these frameworks. The reason was some special requirements reguarding templateing, so I chose to go with the basic templateing in UnderscoreJS and the functional features it provides to build custom rendering. For this scenario UnderscoreJS was a pleasure to work with, and we ended up building a solution that I am really proud of.
Subscribe