Friday, 29 March 2013

Designing the Search Interface

Concept of Searching system
There are two models of searching systems:
1).In the first and older model user express their information need as query that they enter in a search interface. They may do so using a specialized search language.
2).In the second model users express the information need information the natural language like English.
After this step Queries are matched against an index that represent the site's content and a set of matching documents is identified.

Designing the Search Interface
With so much variation among users to account for, there can be no single ideal search interface. Following factors affect choice of search interface:
The levels of searching expertise users have: Are they comfortable with Boolean operators. Or do they prefer natural language? Do they need simple or high powered interface? What about a help page?
The kind of information the user wants: Do they want just a taste or are they doing comprehensive research? Should the results be brief, or should they provide extensive detail for each document?
The type of information being searched is it made up of structured fields or full texts? Is it navigation pages, destination pages, or both? HTML or other formats?
How much information is being searched: will users be overwhelmed by the number of documents retrieved?

Support Different Modes of Searching
Use the same interface to allow users to search the product catalog, or the staff directory, or other content areas. Are non-English speakers important to your site? Then provide them with search interfaces in their native languages. Including language specific directions, search commands and operators, and help information. Does your site need to satisfy users with different levels of sophistication with online searching? Then consider making available both a basic search interface and an advanced one.
Simple / Basic search interface
A simple search interface was required; because at limes users wouldn't need all the firepower of an advanced search interface. Especially when conducting simple known item searches. A simple search box is ideal for the novice or for a user with a pretty good sense of what he or she is looking for. Mammal filtering options are provided including searching for keywords within little and abstract fields, searching within the author field or searching within the publication number field. These filtering options provide the user with more power by allowing more specific searching. But because the labels keyword, Author, And publication Number are fairly self explanatory. They don't force the user to think too much about these options.
Advanced search Interface
We needed interface that would accommodate this important expert audience who were used to complex Boolean and proximity operators and who where already very used to the arcane search languages of other commercial information services. This interface supports the following types of searching:
Fielded Searching
Author, keyword, Title, Subject and ten other fields are reachable. A researcher could, for example find a dissertation related to his or her area of interest by searching the subject field, and learn who that doctoral student's advisor was by reading the abstract. To find other related dissertations, the researcher could then search the advisor field to learn about other doctoral students who shared the same advisor.
Familiar Query Language
Because many different query language conventions are supported by traditional on line products, users may be used to an established convention. The effort to support these users is made by allowing variant terms. For the field Degree Date the user can enter either ‘‘ddt’’, ''da'', ''date'', ''Yr '' or year.
Longer Queries
More complex queries often require more space than the single line entry box found in the simple search interface. The more complex interface supports a much longer query.
Reusable Result Sets
Many traditional online information products allow searchers to build sets of results that can be reused. In this example, we've ANDed together the two sets that we've already found and could in turn combine this result with other sets during the iterative process of searching. Because this advanced interface supports so many different types of searching we provided a substantial help page to assist users. For users of common browsers, the help page is launched if a separate browser window so that users don't need to exit the search interface to get help.

Searching and browsing systems should be closely integrated
As we mentioned earlier, users typically need to switch back and forth between searching and browsing. In fact users often don't know if they need to search or browse in the first place. Therefore, these respective systems shouldn't live in isolation from one another. The search/browse approach can be extended by making search and browse options available on the search result page as well, especially on null results pages when a user might be at a dead end and needs to be gently led back to the process of iterative searching and browsing before frustration sets in.
Searching should conform to the site's Look and feel
Search engine interfaces and more importantly, retrieval results, should look and behave like the rest of your site.
Search Options Should Be Clear
We all pay lip service to the need for user documentation, but with searching it's really a must Because, so many different variables are involved with searching there are many opportunities for things to go wrong on a help or Documentation page consider letting the user know the fallowing:
What is being searched?
Users often assume that their search query is being run against the full test of every page in your site Instead your site may support fielded searching or another type of selective searching. If they're curious users should be able to find out exactly what they are searching.
How they can formulate search queries
What good is it to build in advanced querying capabilities if the user never knows about them? Shows off the power of your search engine with excellent real life examples. In other words make sure your examples actually work and retrieve relevant documents if the user decides to test them.
User options
Can the user do other neat things much as changing the sorting order of retrieval results? Show them off as well!
What to do if the user can’t find the right information
It is important to provide the user with some tricks to handle the following three situations:
  • I'm getting too much stuff
  • I'm not getting anything
  • I'm getting the wrong stuff
For case (a), you might suggest approaches that narrow the retrieval results. For example if your system suppers the Boolean operator AND, suggest that users combine multiple search terms with an AND between them (ANDing together terms reduces retrieval size).
If they are retrieving zero 'results as in case (b), suggest the operator OR the use of multiple search terms the use of truncation (which wife retrieve a term's use o variants), and so on.
If they are completely dissatisfied with their searches, case(c), you might suggest that they contact someone who knows the site’s content directly for custom assistance, it may be a resource intensive approach, but it’s a far superior last resort to ditching the user without helping them at all.

Choose a search Engine That Fits Users' Needs
At this point, you ideally will know something about the sorts of searching capabilities that your site’s users will require. So select a search engine that satisfies those needs as much as possible for example, if you know that your site’s users already very familiar with a particular way of specifying a query such as the use of operators, then the search engine you choose should also support using Boolean operators. Does the size of your site suggest that users will get huge retrieval results? Be sure that your engine be supports techniques for whittling down retrieval sizes, such as the AND & NOT operators , or that it supports relevance ranked results that list the most relevant results at the top will users have a problem with findings the right terms to use in their search queries?

Display search Results sensibly
You can configure how your search engine displays search results information many ways. How you configure your search engine results depends on two factors.
The first factor is the degree of structure your content has. What will your search engine be able to display besides just the titles of retrieved documents? Is your site's content sufficiently structured so that the engine can parse out and display such information as an author, a date an abstract, and so on?
The other factor is what your site's users really want. What sorts of information do they need and expect to be provided as they review search results?
When you are configuring the way your search engine displays results you should consider these issues:
1) How much information should be displayed for each retrieved document?
To display less information per result when you anticipate large result sets. This will shorten the length of the results page making it easier to read. To display less information to users who know what they're looking for, and more information to users who aren't sure what they want.
2).What Information should be displayed for each retrieved document?
Which fields you show for each document obviously depends on which fields are available in each document, what your engine displays also depends on how the content is to be used. Users of phone directories for example want phone numbers first and foremost. So it makes sense to show them the information from the phone number field on the results page. Lastly, the amount of space available on a page is limited: You can't have each field displayed, so you should choose carefully and use the space that is available wisely.
3).How many retrieved documents should be displayed?
How many documents are displayed depends on the preceding two factors: If your engine displays a lot of Information for each retrieved document, you'll want to consider a smaller size for the retrieval set, and vice versa. Additionally the user's monitor resolution and browser settings will affects the amount of information that can be displayed individually.
4).How should retrieved document be sorted?
Common options or sorting retrieval results include:
  • In chronological order.
  • Alphabetically by title, author, or other fiends.
  • By an odd thing called relevance.
Certainly, if your site is providing access to press releases or other news- oriented information, sorting by reverse chronological order makes good sense. Chronological order is less common, and can be useful for presenting historical data.
Alphabetical sorts are a good general purpose sorting approach (most users are familiar with the order of the alphabet). Alphabetical sorting works best if initial articles such as a and the are omitted from the sort order (certain search engines provide this option).
Relevance is an interesting concept; when a search engine retrieves 2000 documents, is not it great to have them sorted with the most relevant at the top, and the least relevant at the bottom? Relevance ranking algorithms are typically determined by some combination of the following; how many of the query's terms occur in the retrieved document; how many times terms occur in that document; how close to each other those terms occur and where the terms occur.

Always provide the user with feedback
When a user executes a search, he or she expects result. Usually a query with retrieves at least one document, so the user's expectation is fulfilled. But sometimes a search retrieves zero results. Let the user know by creating a different results page especially for these cases. This page should make it painfully clear that nothing was retrieved, and give an explation as to why, tips for improving retrieval results and links to both the help area and to a new search interface so the user can try again.

Other Considerations
You might also consider including a few easy to implement but very useful things in your engine's search results:
Repeat back the original search query prominently on the results Page
As users browse through search results, they may forget what they searched for in the first place remind them. Also include the query in the page titles; this will make it easier for users to find it in their browser's history lists.
Let the user know how many document in total were retrieved.
Users want to know how many documents have been retrieved before they begin reviewing the results. Let them know: if the number is too large, they should have the option to refine their search.
Let the user know where he or she is in the current retrieved set.
It's helpful to let users know that they're viewing documents 31-40 of the 83 total that they've retrieved.
Always make it easy for the user to revise a search or sort a new One.
Give them these options on every results page and display the current search query on the revise search page so they can modify it without reentering it.

No comments:

Post a Comment