Search in Topic Maps portals

<< 2007-08-21 11:23 >>

Ceiling, Sevastopol

One of the features that sets Topic Maps-based portals apart is their support for search, which is generally better than in ordinary portals. However, implementing search in any given portal generally requires lots of discussion with the customer and interaction designers, and it's not always clear what is the best approach.

As part of my work on semantic searching (about which more later) I looked at how various Topic Maps-based portals have approached search so far. This informal survey doesn't actually fit anywhere, so I thought it might be just as well to make a blog entry out of it, rather than throw it away. I've also added some recommendations based on the experiences I've had so far.

The survey

I looked at the following aspects of the search implementations in a number of Topic Maps-based portals:

Pre-filtering

Whether users are given the chance to apply some kind of structured filter before they search, using a drop-down list of categories or by other means.

Post-filtering

Whether users are able to filter search results after they have been displayed.

Grouping

Whether or not search results are displayed grouped by type. Here I don't mean whether the type is displayed, but whether the entire layout of the results is organized so that topics of the same (or similar) types are displayed together as a group.

Categories

Whether or not categories can be found in search.

Topic types

Whether or not topic types can be found in search.

Description

Whether or not statements about the topics (beyond just the name and type) are used to provide more information about the topics found.

Ranking

The quality of the relevance ranking of search results.

The results were as follows:

I've put "Y-" in some cases where sites have a feature, but only in a rather limited way.

Some observations

Pre-filtering is quite rare, and in general it does not appear to work very well. The main problem is that people are reluctant to filter before they search because they have less of an idea what the filters mean before they have searched. And in any case they don't know if they need to filter until afterwards, and it's just as easy to do it then.

Post-filtering is quite widely supported, and is very powerful, and is definitely one of the aspects of Topic Maps-based portals that have worked very well. However, it's easy to make the filtering interface too crowded and complex for users. So the main challenge here seems to be to make this rather complex feature intuitive to use for non-technical people. In other words, at least with Topic Maps this is more of a design challenge than a technical challenge.

Grouping is not very common, and my experience with it has been very negative. It can seem attractive at first, but users don't expect it, it makes it more complicated for them to "parse" the results page, and it makes it harder to scan the list of results. The worst thing, however, is that it breaks the relevance ranking, since the ordering of results is determined by the order of the groups.

In the City of Bergen portal there are four groups, which means that on average in 3 out of 4 cases the best hit will not be listed at the top. This is not because of some limitation in the ranking of results, but because the order of the groups is fixed. In other words: vertical grouping defeats ranking of results. Fuzzzy.com also has grouping, but only into two groups, and as it does this horizontally it works better. (I'm still not sure this is a good idea, though.)

Nearly all sites allow you to find categories when searching, but in several cases I've been involved with getting the customer to agree to allow this has been a real uphill struggle. I don't know why, but to customers it often seems wrong that categories should be findable through search. The winning argument for making them findable has been that the customer typically spends considerable effort on collecting the most relevant set of content possible under each category. If the user then types the name of a category, why not offer what is in effect a hand-made page of search results to the user among the other search results? Nobody has been able to formulate a good reason not to that I've heard.

Topic types cannot be found via search in any portal that I've seen, and this is probably because the portals tend not to have any pages for the topic types. This makes sense given that a list of all persons or articles in a portal is rarely very useful. Still, this is a search that people perform, and it's not really clear that this might not be useful.

The descriptions of search hits are very limited in most portals, but some Topic Maps portals go much further in this regard. In the Kulturnett portal, for example, search hits for "Ibsen" are described as "book by Atle Næss," "museum in Oslo", "author", etc, and these descriptions are structured. This is a very useful feature for users, since it tells them much more about what they've found without taking up much visual real estate. I think many of the portals which left this out did so because their ontologies are so weak that they cannot really describe the topics much.

Similar posts

Comments

Add a comment