| <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN2"> |
| <html> |
| <head> |
| |
| |
| <title>Search Enhancements Proposal</title> |
| <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> |
| <meta http-equiv="Content-Style-Type" content="text/css"> |
| <link href="http://dev.eclipse.org/default_style.css" rel="stylesheet" type="text/css"> |
| </head> |
| <body bgcolor="#ffffff"> |
| |
| <table width="100%"> |
| <tr><td style="background:#0080C0"> </td></tr> |
| |
| </table> |
| |
| <h1>Search Enhancements Proposal</h1> |
| |
| <blockquote> <b>Summary</b><br> |
| This document highlights the need for better search integration for local online |
| help, web, and workbench UI artifacts, and proposes a solution to provide such |
| enhancements.<p> |
| <font size="-1">Last modified: December 13, 2004 - revision 1</font></blockquote> |
| <p> |
| <h3>Background</h3> |
| <p> |
| As products scale to enterprise level scope, search is becoming increasingly |
| important in finding documentation and various tool artifacts. <ul> |
| <li>the locally installed documentation is usually not sufficient, not the |
| latest, and does not benefit from other contributions. Many times eclipse |
| users search the web using their favourite search engines, or search related |
| mailing lists and newsgroups.</li> |
| <li>as the number of plug-ins increases, so does the complexity of the UI. It |
| is possible to run products that contain over a hundred plug-ins, tens of views |
| and perspectives, etc. It should be possible to easily discover new contexts |
| (perspectives, view) or new actions (wizards, menu actions, etc.) without |
| having the navigate the highly structured graphical interface.</li> |
| </ul> |
| <p> |
| |
| <h3>Proposed enhancements</h3> |
| <p>Eclipse search support should be enhanced by adding new search types and by |
| providing for federated (instead of exclusive) search. The following two new |
| types are needed:</p> |
| <ul> |
| <li><b>Search the Web </b>- right now, searching the help only gives local |
| hits (in the help documentation). The user should be able to expand the |
| search to the web using the same keywords and collate results from the |
| multiple search engines queried in parallel. At a minimum, the results |
| should be categorized by their source. Overall ranking of results is |
| difficult, because of the potential search delays on the web, and the need |
| to have access to the document contents. </li> |
| <li><b>Search the UI </b>- the result of the search are user interface |
| artifacts (actions, views, editors, wizards) registered in the extension |
| point registry. This search would be beneficial to users of very complex |
| programs. The search results could be immediately executed. For example, an |
| action can run, a view, editor or a wizard can be opened etc. </li> |
| <li>For ease of use, we also propose having a search entry field somewhere |
| in the UI, likely in the toolbar area, similar to what is currently done in |
| the help browser. Users should be able to enter keywords directly from the |
| workbench, and get results, without having to open the search dialog from |
| the menu.</li> |
| </ul> |
| |
| <p> </p> |
| <h3>Implementation considerations</h3> |
| <h4>Searching the UI:</h4> |
| <p>There are two technical problems to solve: finding the UI elements that |
| match the search criteria, and running/executing the associated action when a |
| hit is double clicked.</p> |
| <p>UI searches should start with the plugin registry. Depending on the element |
| to lookup, the text data to search could be:</p> |
| <ul> |
| <li>for wizards: the <<b>description</b>> element, the <b>name</b> |
| attribute, and the content of topic pointed at by the <b>helpHref</b> |
| attribute. Optionally, one can search the <b>category</b> <b>name</b>, the |
| final and preferred perspectives.</li> |
| <li>for views: the <b>name</b> attribute. Optionally, the <b>category name</b>.</li> |
| <li>for perspective: the <b>name</b> attribute.</li> |
| <li>actions/action sets: the <b>label</b> and <b>tooltipLabel</b>. |
| Optionally, the text obtained from the <b>helpContextId</b></li> |
| <li><b>etc.</b></li> |
| </ul> |
| <p> To provide the most benefit, the lookup can use the Lucene |
| search framework used by the help system (but implement its own index/search), or, for a simpler |
| solution, dynamically doing regular expression matching on various strings in |
| the plugin registry. </p> |
| <p>Running the associated action when double clicking on a result will need to |
| take into account various input parameters defined in the extension |
| declaration. The challenge is for running actions that require a resource |
| selection, or something that may not even be available in the current |
| perspective. In this case, perhaps more context can be brought in (for |
| example, a new perspective opened, etc.), based on the hierarchical |
| containment of UI parts.</p> |
| <p>Here what results would look like: </p> |
| <p><img border="0" src="UIsearch.GIF" width="934" height="684"></p> |
| <h4>Searching the Web</h4> |
| <p>This should really be called federated search: both local online help |
| searches and remote web searches should be possible as one action. One must be |
| able to plug-in the desired places to search (google, yahoo.com, eclipse |
| search for newsgroup, mailing lists and eclipse.org, developerWorks, etc.).</p> |
| |
| <p>To plug-in a new web search engine, help can provide an extension point, |
| org.eclipse.help.base.webSearchEngine, that requires implementing the |
| following interface:</p> |
| |
| <p> <code> <br> |
| interface IWebSearchEngine {<br> |
| /** Returns the localized label for the search engine */ |
| <br> |
| String getName();<br> |
| /** Returns the search engine query URL for the user input query string */<br> |
| URL getSearchURL(String searchQuery);<br> |
| }<br> |
| <br> |
| /** If hits from the search engine can be parsed out or the engine exposes API's, |
| <br> |
| * then implement this interface instead <br> |
| */<br> |
| interface IAdvancedSearchEngine extends IWebSearchEngine {<br> |
| /** Returns the search hits. Returns null if the search hits |
| <br> |
| * cannot be obtained from the search engine. <br> |
| * In this case, the results will be displayed by using the getSearchURL(). |
| <br> |
| * This method may block and needs to be cancelled. <br> |
| */<br> |
| IHelpSearchHit[] getSearchHits(String searchQuery, IProgressMonitor monitor);<br> |
| }<br> |
| <br> |
| interface IHelpSearchHit {<br> |
| String getLabel();<br> |
| String getHref();<br> |
| int getScore();<br> |
| }<br> |
| </code><br> |
| Unlike the current displaying of local hits as a flat list, the new search page |
| for help will display hits hierarchically, with each search engine, including |
| the local one, as roots. Hits will be collected under each such root. |
| Additionally, double clicking on a result will display the topic in the editor |
| area, using the SWT browser widget. At the top of the topic there will be a link |
| to launch the topic into the external help browser or into the system browser if |
| the topic is not from the local help.</p> |
| |
| |
| <p>If the extension point provider implements the IWebSearchEngine interface, |
| but not IAdvancedSearchEngine, then no hits will be shown under that particular |
| engine, but the root will receive a different icon to indicate you need to |
| double click it. In this case, the browser (shown in the editor area) will be |
| displaying the actual web page of that engine, with the given query, as shown |
| below:</p> |
| |
| |
| <p><img border="0" src="search.GIF" width="1024" height="768"></p> |
| |
| |
| </body> |
| </html> |
