100945 - prepending search results for usability

Status: RESOLVED INVALID

(SeaMonkey :: Search, defect)

Description

[matt]

To better understand the usibility of the search results tab we need to add a
mechanism to prepend the urls.   This is critical to understand how people us
the panel.

Jud, can you please diff the x:/matt/mozilla/xpfe/componenets/search directory
on the PC that I used and add the diff to this bug.

thanks

Comment 1

[Peter Trudelle]

I don't understand this.

Comment 2

[Judson Valeski]

Attachment: appending patch for matt.

Comment 3

[matt]

Attachment: adding patch

Comment 4

[matt]

Need r and rs
This is for usibility to see how people use the panel.
Tested both with url in properities file and w/o

Comment 5

[Samir Gehani]

Comment on attachment 51482 [details] [diff] [review]
adding patch

Can we change the 'searchPrependUrl' term to something more meaningful?  Maybe searchTrackingRedirect or searchUsabilityRedirect?

Comment 6

[Samir Gehani]

Todd, is this a high priority?  If so, we need a redirect from website.

Comment 7

[Peter Trudelle]

I'd like to understand better what metrics we have now, and how this patch would
give us better metrics.  It sounds important, but I need to understand it much
better than I do from Matt's quick response here.  

Comment 8

[Todd Pringle]

I am guessing that what we are trying to do here is modify the search results
urls in the search sidebar tab so that we can get some data on how often users
are using them to navigate their search results.  This would be great data to
have obviously.  Currently the only data we have is the raw number of search
conducted from the Search sidebar tab.  While great as well, it doesn't give us
an idea about whether or not the feature of results in the tab is regularly
used.  Samir, correct me if I'm wrong here about what this is tracking.

Comment 9

[Samir Gehani]

Your interpretation is accurate Todd.  If you see the need for tracking the
results let's talk about what our goals are.  Tracking each result does come
with an associated cost:

(*) redirect slows every result
(*) when redirect server is down result appears broken I believe(*) redirect
server (or server farm) is a potential bottleneck

Assuming this bug in its original form shall remain futured.  If you concur I
would like to completely eliminate it from the radar by marking it invalid.  Thanks.

Comment 10

[Peter Trudelle]

How much delay does redirection add?  What is the downtime percentage for those
servers?

Comment 11

[Samir Gehani]

Delay is variable: folks on "slow" connections will be affected by this most.  I
guess, the question that follows is what sort of bandwidth does our target
audience have?  Todd?

Also, I don't think the actual delay will be much even on a slow connection:
potentially the user experience might become annoying though for users on "slow"
connections when they see a redirect for each result.  This may steer them away
to the alternative of using a webpage with the search results rather than the
sidebar search tab.  

Admittedly this is all mere speculation.  It's easy to argue for the original
bug.  However, if we do put this in I feel that we should add code to make the
experience more ruobust: detect when a  redirect server didn't respond and then
use the direct URL to the search result.

Todd, who can give us historical data on server downtime?  Myron?

Comment 12

[Peter Trudelle]

Are you sure that connection bandwidth has any bearing here?  Is this tied to
the amount of data transferred, or are you talking about the latency? 

Comment 13

[Todd Pringle]

Myron may be able to give you some data about the servers, yes.  In general I am
of the opinion that the more data we have in the area of search the better,
based on past experience.  That said, I would be hesitant to implement anything
that significantly degrades performance.  Is this something that would both a)
slow population of results in the Search Sidebar tab (already relatively slow)
and b) slow the load of each search result URL because of the delay of the
redirect (which isn't typically too bad based on other places in the product
that we do this)?

Comment 14

[Samir Gehani]

It would result in (b).  I've seen this on occasion: the redirect server
(into.netscape.com) is apparently heavily loaded and takes a little while to
respond before pointing to the destination search engine URL with the relevant
query string.