Comment 24 for bug 402767

Revision history for this message
Rick Spencer (rick-rickspencer3) wrote : Re: multisearch add on blocks the functionality of firefox location bar

Thanks all for your comments on this bug. Thanks to all for testing the alpha and for contributing to making Karmic as great as it can be. I appreciate the measured and respectful tone of the reporting.

I take these concerns very seriously. Please allow me to summarize the issues raised here, and provide some facts and responses:

We've made some changes in the Alpha 3 version of Firefox related to how and where search queries are processed. We've introduced the changes at this time in an experimental vein in order to explore and understand the user experience and usage patterns. We plan to use this experimental code at least until Alpha 4.

Note that we did not necessarily foresee Multisearch as code that we would ship in a stable release. Whatever actions we take in response to the information and feedback will depend on the information and feedback that we collect from this effort.

Essentially, we implemented two changes in order to collect this usage data:
1. When users ask for a new tab, they see a default search page.
2. All searches use the custom search results page. Previously this search results page was only used when users did a search from the default Ubuntu home page.

Change #1 was an effort to explore a better user experience. Generally, it seems odd when users get a blank page, especially when they are using ff on a netbook in full screen mode. New tab simply makes the screen go white. Note that Mozilla is exploring "new tab" behaviour as well (http://labs.mozilla.com/2009/03/new-tab-page-proposed-design-principles-and-prototype/)

Change #2 is just an artefact of collecting the usage data. We could only see what parts of the FF UI people were using to do searches if we sent them to our custom page. This usage data is important because it helps us channel design and development resources to useful features, and is also important because it can be tied to revenue generation.

Generating revenue that supports the project is a feature, not a bug. However, we are mindful of not throwing the baby out with the bath water. In other words, we must strike the balance of continuing to deliver a top notch user experience while taking advantage of revenue opportunities.

In terms of "what kind of usage data" are we collecting, it's simply the same data that is already sent to Google and Mozilla: the requested search, and the channel for the search. This is the data that are already provided and collected every time a user performs a search with a search engine anywhere on the web, and we are simply using stock Google tools to see the aggregated results.

This bug started out with a specific issue, but some bug reporters have added issues. I believe the following issues raised are concerns that should be treated as bugs:
1. Awesome bar does not do "feeling lucky" type search
2. The custom search results page is not aesthetically pleasing
3. The custom search page lacks useful functionality (images, videos, maps, etc...)
4. "Multisearch" is not a descriptive name
5. Search UI on New Tab pages is visual clutter, not useful
6. Currency conversions don't work

We will take these considerations strongly into account as we consider whether to move forward with any changes to the default search experience.