Today, users are searching for an answer when stuck in product usage. Nobody is reading the manual methodically. If your users are having trouble in finding information in your manuals, your business may be facing a risk of losing its customers. This risk is increasing since the time users have to spend on searching is limited or even decreasing and the amount of information to search in is constantly increasing. In future, users will not accept bad findability, thus you need to design for findability already now.  It all comes down to understand what type of information your users need and are searching for. One of the crucial parts of an effective user assistance is the search interface.

Lets image you have made an information and user analysis (maybe using SeSAM) where you have identified what type of content - amount of DITA topics – your users are needing and are searching for. All topics can be put in one (1) basket, making up a topic pool. The topic pool is not making the user happy; the user must somehow be able to find the specific topic, among maybe thousands, sought for in a search situation. It is like finding that particular LEGO brick in a box full of thousands of different types of bricks.

The DITA way is to build one/several maps and reference topics in a logical order (what is logical to you maybe unlogical for a user). Each map can, for example, reassemble a user manual. The final deliverable, such as a PDF or help file, gets a static TOC which show how topics are organized within the map. Is the static TOC a good example of a search interface? In my opinion, no.

Let us first take a step back and conclude on the information seeking behaviours among users before digging into how a search interface should be built to allow findability. Users behave differently that’s for sure; there is not one single user that follows the same search behaviour pattern as someone else. Some users are methodical broad scanners, following a top-to-bottom search behaviour whereas others are irrational deep divers and start from the bottom. Some users formulates keywords that are task oriented (“build”, “stop”, “export”) where others formulates keywords that are product centric (“communication interface X”, “current protection function Y”) etc. User comes to documentation with different mind sets, starting points and search vocabularies. Users have different domain knowledge, search experiences and reading skills. That’s why the search interface must have multiple points of entry, such as a faceted search environment can provide. There is not a one-size-fits-all kind of a search interface.

A search interface must be available as a layer on top of the topics. To just provide a big search box in your manual (like Google.com) and then let the user enter keywords is not providing the level of findability users may expect. This is of course due to that the technical communicators design vocabulary is sometimes not the same as the search vocabulary among users, meaning that a user might not find information since they are expressing keywords which the technical communicator never used. Also, the user might not be aware of that there exists information they might need, and accordingly they will not enter keywords for it. So some kind of navigation map is needed in addition to full text search.

The search interface is like a map over a city. A specific address reassembles a DITA topic. The user knows there is an address and wants to know how to get there. A user is never going to two or more addresses at the same time. The map allows the user to find out where s/he is located currently and how to proceed to reach the specific address (from A to B). The map can also be used to explore the city to learn about things that the user was unaware of existed, such as shops, hospital etc. The search interface in end user assistance must be built on the same principles.

To build an effective search interface you need a user centric metadata strategy. SeSAM provides such a strategy. SeSAM lets you identify different search situations and the result is several taxonomies, used to classify topics. A search interface built according to SeSAM, allows the user to select and narrow down the search situation the user is currently in. When the user has selected the facets that correspond to the search situation, the appropriate topics are displayed. Remember that the user does not want to wade through information that does not apply to the current situation. The search interface is not built up from the topic titles, as is the usual way of making static TOCs. Instead the facet values from the various taxonomies are used to build the search interface. That’s why a faceted search approach is very suitable for building a search interface for SeSAM content. A faceted search environment provides instant feedback on a selection which motivates the user to continue the selection. The search interface should be guiding in a sense where it asks the user to narrow down the search situation, for example “What do you want to do? Then a list of options such as the user goals is presented. The search interface could also recommend which search situation facets to start the selection from.

A user might start off from the user goal to narrow down a search situation, thus the user selects the user goal from a list of goals, for example “Understand, learn and evaluate what the product can help me do”. Then the user might continue to select the particular outcome, the result (MRS), the user wants to achieve using the product, for example “Write and send an email”. Another user might start off from a particular interface element and from there find all information types that are associated with the interface element to further refine the search situation.

The search interface helps the user understand what type of information a topic includes. When the user is traversing and selecting different facet values, the user is also picking up the classification which helps to understand the type of content a topic includes.

Facets (metadata) can be divided into two groups; “user evaluateable facets” and “user non-evaluateable facets”. User non-evaluateable facets are ambiguous since it is difficult for the user to evaluate which value is appropriate. User non-evaluateable facets are for example “role: sys admin, technical engineer, operator”, “knowledge level: novice, intermediate, advanced” or “Manual: reference manual, user manual etc”. The user may have problems in knowing what to select: “I’m I a sys admin or technical engineer?” “Do I have novice or intermediate knowledge level?”.

User evaluateable facets make sense to the user and are such where the user can evaluate the values in the context where information is consumed without having to “get into the head of the designer” to understand the values. For example “Location: Paris, Rome, Stockholm” or “Part-on-product: Front, Rear”. User non-evaluateable facets should be avoided, especially company made up terms, or be complemented with a definition (which nobody reads).

Whether a facet is user evaluateable or not depends on many factors, but some facet terms seems to be more common and the semantic meaning is better known than for example company made up terms. The taxonomies in SeSAM are user evaluateable. Examples of SeSAM facet taxonomies are user goal, life cycle, part-on-product, operating environment etc. Guiding the user in selecting user evaluateable facets provides findability over a non guiding search interface containing non user evaluateable facets.

Also consider providing an alternative synonym for a facet, such as an interface element. A task, or interface element can be called different things in different countries, markets etc. And a search interface can be localized; provide different search interfaces for different markets etc where the facet values in the taxonomies are translated to target what is custom on a specific market.

One problem today is that many information viewers can only be equipped with one (1) static TOC, such as in a PDF, help file or Eclipse library. The search interface can be made as a wiki, providing a single point of entry for all type of users where there are multiple points of entries to select and narrow down a search situation. A software interface can be seen as the search interface, when help is embedded. Integrating context sensitive help and faceted search browsing capabilities is interesting; when the user selects help from an interface element the corresponding interface facet should be pre-selected in the browser.

A search interface must furthermore be possible to print on paper. Then you could provide a map covering a particular technical product that guides the user in selecting a certain manual. How do you help the user in selecting the appropriate manual if you are developing several types of manuals for your products? A search guide may furthermore cater for one or several sibling product configurations. If it covers several product configurations, then the different configurations must be a taxonomy of its own.

Many electronic devices, such as phones, GPS navigators and even refrigerators, are equipped with a display that gets bigger and bigger. A search guide, can be visualized as an graphical image, which makes it suitable for small displays. A search interface can be built and managed using for example the DITA subject scheme or a topicmap.

A search interface mock-up, as a guided faceted search browser, will in a couple of months be available on www.sesam-info.net. Until then, check out www.youtube.com/user/jonatanlundin to learn more about SeSAM.