In this chapter we will focus on understanding how a search experience can be more user-oriented: the focus will be on user experience for search, we can call it "user search experience". We are not prototyping any real front end; there will not be any HTML here, but we simply start considering on one hand how a common, non-advanced user will perform a query and on the other hand how to construct a result structure suitable for the front-end process.
We will briefly introduce some examples with a real approach, implementing patterns such as autosuggestion and giving, for example, an idea on how a geolocalized search would perform.
We also have a chance to get an idea on how to use Solr again for prototyping, by introducing a concept such as editorial boosting of results and augmenting data from external data sources during the update process.
It does not matter whether you use it as a standalone application or as an embedded framework, the main aim of an Apache Solr application is generally to index over a wide mix of structured and unstructured data, and provide powerful search capabilities to the users of an enterprise application.
In order for this to work, it's important to remember that all the data indexed in a Solr application needs to be denormalized as they are actually stored in the form of vectors of terms, in the same way Apache Lucene does. But if Lucene was designed to offer advanced and fast search to experienced users, and it is a component designed to be plugged into the development of an application, a Solr application should be able to take care of a common user's needs and real-world enterprise tasks.
Solr applications are also designed for searching on specific domains and more specialized data than the whole Web. From a mathematical point of view, this reduces the space represented by our vectors to a great extent, so that we cannot simply use them without further small corrections. From the domain point of view, a user doesn't need to take care of things such as synonyms or misspelled words, or the misuse of some basic operators. Sometimes we need to be less precise and yet to provide results that the users can find useful, thus matching their needs.
For all these reasons, I like to think that the main aim of a Solr application is providing support for some kind of search experience.
We can use a copy of the core definitions seen earlier in Chapter 3, Indexing Example Data from DBpedia – Paintings: we can copy them to define our new core in /SolrStarterBook/solr-app/chp05/paintings/core. For starting with the example of the multicore definition for this chapter, you can use the following script again in /SolrStarterBook/test/:
>> ./start.sh chp05
In order to populate this index for the examples, you can proceed with the steps seen in Chapter 3, Indexing Example Data from DBpedia – Paintings or use the scripts you'll find in the corresponding /SolrStarterBook/test/chp05/paintings/ folder.