<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Specific Database Search: Old search UI vs New Search UI</title>
	<atom:link href="http://blogs.ancestry.com/ancestry/2008/08/18/specific-database-search-old-search-ui-vs-new-search-ui/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.ancestry.com/ancestry/2008/08/18/specific-database-search-old-search-ui-vs-new-search-ui/?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=specific-database-search-old-search-ui-vs-new-search-ui</link>
	<description>The official blog of Ancestry.com</description>
	<lastBuildDate>Thu, 23 May 2013 03:10:33 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.4.2</generator>
	<item>
		<title>By: Anne Mitchell</title>
		<link>http://blogs.ancestry.com/ancestry/2008/08/18/specific-database-search-old-search-ui-vs-new-search-ui/#comment-17874</link>
		<dc:creator>Anne Mitchell</dc:creator>
		<pubDate>Mon, 25 Aug 2008 22:28:53 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.ancestry.com/ancestry/2008/08/18/specific-database-search-old-search-ui-vs-new-search-ui/#comment-17874</guid>
		<description>I&#039;m closing this post down so I can focus on my most recent post.  You can find a list of all of my posts at:

&lt;a href=&quot;http://blogs.ancestry.com/ancestry/author/amitchell/&quot; rel=&quot;nofollow&quot;&gt;Anne Mitchell&#039;s ancestry blog posts&lt;/a&gt;</description>
		<content:encoded><![CDATA[<p>I&#8217;m closing this post down so I can focus on my most recent post.  You can find a list of all of my posts at:</p>
<p><a href="http://blogs.ancestry.com/ancestry/author/amitchell/" rel="nofollow">Anne Mitchell&#8217;s ancestry blog posts</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jerry Bryan</title>
		<link>http://blogs.ancestry.com/ancestry/2008/08/18/specific-database-search-old-search-ui-vs-new-search-ui/#comment-17704</link>
		<dc:creator>Jerry Bryan</dc:creator>
		<pubDate>Sun, 24 Aug 2008 05:00:18 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.ancestry.com/ancestry/2008/08/18/specific-database-search-old-search-ui-vs-new-search-ui/#comment-17704</guid>
		<description>I&#039;m going to have to disagree with Mike&#039;s #82 just a little bit.

The part we agree on is that exact search should &lt;b&gt;never&lt;/b&gt; produce a  list of hits that is ranked by the star system, or that even says Sorted by Relevance.  Such a ranked list is nonsensical on its face because ranking the list is trying to rank items that by definition are equal.

The part we would have to disagree on is semi-exact searches.  Semi-exact searches really aren&#039;t exact searches at all.  They really are fuzzy searches.  And about the only way to order a list of hits from a fuzzy search that makes any sense is to order the list by rank.

I have the great good fortune of having an example I can use that actually works to illustrate these ideas.  For the example I have chosen, New Search does not go into its funky mode where it gives thousands of hits when it shouldn&#039;t.


Search #A.  Let&#039;s use as an example the search from my #20: go to the 1850 census and do an exact search for surname Smith, born in Tennessee, USA, resides in Anderson County, Tennessee, USA.  On Old Search, there are 75 hits.  On New Search, there are also 75 hits.  So whatever the bug is in New Search that frequently causes it to return thousands of hits apparently does not apply in this situation.

Search #B.  Same as search #A except add the condition born in 1830+-10, essentially the range for birth dates is 1820-1840.  On Old Search, there are 44 hits.  On New Search, there are also 44 hits.  The number of hits has been reduced from 75 to 44 because we have filtered out anybody born after 1840 or before 1820.  And once again, New Search is behaving itself and is not suffering from the bug that causes it to return thousands of hits.  I can&#039;t emphasize enough that including a range such as 1840+-10 does not make this search into a fuzzy search.  The search is still very much exact.

Search #C.  Same as search #A except add the condition born in 1830 not exact.  The birth date is the only fuzzy condition in the search and the search is therefore semi-exact.  Nevertheless, the search has to be treated as fuzzy.  I can&#039;t run this search on Old Search because Old Search does not support semi-exact searches.  When I run this search on New Search, I get 75 hits.  Wonder of wonders, New Searched pretty much worked correctly and it didn&#039;t go into its funky mode where it gives thousands of hits!

With Search #C, some of the hits were ranked at 3.5 stars and some of the hits were ranked at 3 stars.  The 3.5 star hits were basically those hits for which the birth date was 1830+-2, and the 3 star hits were all the rest.  All the 3.5 star hits were listed ahead of all the 3 star hits.  I think the idea here is fine, but the implementation is pretty sloppy.  Somebody who was only 3 years removed from the search target of 1830 received the same ranking as somebody who was 30 years removed from the search target of 1830.  Surely, ancestry can do better than this.  But the concept is fine.

With search #B, all the hits were listed as 3.5 star hits.  Because all the hits were the same number of stars, it is nonsensical to rank them by the number of stars.  Fortunately, the UI had the good sense to list the 44 hits sorted by name.  That&#039;s not as good as letting me pick the sort order, but it&#039;s at least as good as the way Old Search did it.  And it shouldn&#039;t say Sorted by Relevance when its really sorted by name.

With search #A, all the hits were listed as 3 star hits.  Because all the hits were the same number of stars, it is nonsensical to rank them by the number of stars.  Fortunately, the UI had the good sense to list the 75 hits sorted by name.  That&#039;s not as good as letting me pick the sort order, but it&#039;s at least as good as the way Old Search did it. And it shouldn&#039;t say Sorted by Relevance when its really sorted by name.</description>
		<content:encoded><![CDATA[<p>I&#8217;m going to have to disagree with Mike&#8217;s #82 just a little bit.</p>
<p>The part we agree on is that exact search should <b>never</b> produce a  list of hits that is ranked by the star system, or that even says Sorted by Relevance.  Such a ranked list is nonsensical on its face because ranking the list is trying to rank items that by definition are equal.</p>
<p>The part we would have to disagree on is semi-exact searches.  Semi-exact searches really aren&#8217;t exact searches at all.  They really are fuzzy searches.  And about the only way to order a list of hits from a fuzzy search that makes any sense is to order the list by rank.</p>
<p>I have the great good fortune of having an example I can use that actually works to illustrate these ideas.  For the example I have chosen, New Search does not go into its funky mode where it gives thousands of hits when it shouldn&#8217;t.</p>
<p>Search #A.  Let&#8217;s use as an example the search from my #20: go to the 1850 census and do an exact search for surname Smith, born in Tennessee, USA, resides in Anderson County, Tennessee, USA.  On Old Search, there are 75 hits.  On New Search, there are also 75 hits.  So whatever the bug is in New Search that frequently causes it to return thousands of hits apparently does not apply in this situation.</p>
<p>Search #B.  Same as search #A except add the condition born in 1830+-10, essentially the range for birth dates is 1820-1840.  On Old Search, there are 44 hits.  On New Search, there are also 44 hits.  The number of hits has been reduced from 75 to 44 because we have filtered out anybody born after 1840 or before 1820.  And once again, New Search is behaving itself and is not suffering from the bug that causes it to return thousands of hits.  I can&#8217;t emphasize enough that including a range such as 1840+-10 does not make this search into a fuzzy search.  The search is still very much exact.</p>
<p>Search #C.  Same as search #A except add the condition born in 1830 not exact.  The birth date is the only fuzzy condition in the search and the search is therefore semi-exact.  Nevertheless, the search has to be treated as fuzzy.  I can&#8217;t run this search on Old Search because Old Search does not support semi-exact searches.  When I run this search on New Search, I get 75 hits.  Wonder of wonders, New Searched pretty much worked correctly and it didn&#8217;t go into its funky mode where it gives thousands of hits!</p>
<p>With Search #C, some of the hits were ranked at 3.5 stars and some of the hits were ranked at 3 stars.  The 3.5 star hits were basically those hits for which the birth date was 1830+-2, and the 3 star hits were all the rest.  All the 3.5 star hits were listed ahead of all the 3 star hits.  I think the idea here is fine, but the implementation is pretty sloppy.  Somebody who was only 3 years removed from the search target of 1830 received the same ranking as somebody who was 30 years removed from the search target of 1830.  Surely, ancestry can do better than this.  But the concept is fine.</p>
<p>With search #B, all the hits were listed as 3.5 star hits.  Because all the hits were the same number of stars, it is nonsensical to rank them by the number of stars.  Fortunately, the UI had the good sense to list the 44 hits sorted by name.  That&#8217;s not as good as letting me pick the sort order, but it&#8217;s at least as good as the way Old Search did it.  And it shouldn&#8217;t say Sorted by Relevance when its really sorted by name.</p>
<p>With search #A, all the hits were listed as 3 star hits.  Because all the hits were the same number of stars, it is nonsensical to rank them by the number of stars.  Fortunately, the UI had the good sense to list the 75 hits sorted by name.  That&#8217;s not as good as letting me pick the sort order, but it&#8217;s at least as good as the way Old Search did it. And it shouldn&#8217;t say Sorted by Relevance when its really sorted by name.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: 45RPM</title>
		<link>http://blogs.ancestry.com/ancestry/2008/08/18/specific-database-search-old-search-ui-vs-new-search-ui/#comment-17700</link>
		<dc:creator>45RPM</dc:creator>
		<pubDate>Sun, 24 Aug 2008 03:05:53 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.ancestry.com/ancestry/2008/08/18/specific-database-search-old-search-ui-vs-new-search-ui/#comment-17700</guid>
		<description>When are you knuckleheads going to figure out that Anne is not the kindly, good-deed savior you all are hoping for?

Anne&#039;s job is to convince pissed-off subscribers that Everything Which Was Good Is Bad (old search), and that Everything Which Was Bad Is Good (new search).

She&#039;s nothing more than a Spin Doctor, Ancestry-style.</description>
		<content:encoded><![CDATA[<p>When are you knuckleheads going to figure out that Anne is not the kindly, good-deed savior you all are hoping for?</p>
<p>Anne&#8217;s job is to convince pissed-off subscribers that Everything Which Was Good Is Bad (old search), and that Everything Which Was Bad Is Good (new search).</p>
<p>She&#8217;s nothing more than a Spin Doctor, Ancestry-style.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Versesmith</title>
		<link>http://blogs.ancestry.com/ancestry/2008/08/18/specific-database-search-old-search-ui-vs-new-search-ui/#comment-17685</link>
		<dc:creator>Versesmith</dc:creator>
		<pubDate>Sat, 23 Aug 2008 21:44:39 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.ancestry.com/ancestry/2008/08/18/specific-database-search-old-search-ui-vs-new-search-ui/#comment-17685</guid>
		<description>Hi Ann,

I believe that my meaning in my previous comment (#13) was unclear.

The penultimate goal is or should be that the search results conform to the user&#039;s needs and desires.  UI templates, therefore, are important, because they provide the gateways to results, contrary to what I infer from your comment that &quot;[w]e will not be making changes to the current old UI system. Maybe not the answer you were looking for, but I believe it is the correct answer.&quot;  I don&#039;t think neglecting the UI templates, in either the old or new search engines, is the correct answer.  

Although your comment was referring to the old search, I cannot help but wonder if that concept will not also apply to the new search at some point.

I would suggest this analogy.  If the door hinges on the outhouse need repair, one does not build a whole new outhouse.  One simply repairs the hinges so that the door works properly.  As the old saw says: Don&#039;t throw the baby out with the bath water.

If the door won&#039;t open or close because the hinges don&#039;t work properly, the hinges will need to be repaired, whether the outhouse is old or new, unless the plan is to raze the old.

The UI template is akin to the hinges.  As the hinges are critical to reaching the goal of an outhouse door that opens and closes properly, the UI templates are critical to obtaining the desired search results. It will always be important to revise or improve the UI  templates to obtain the search results users need and desire.

My interpretation of user comments thus far seems to indicate that although there were problems with the old search, these were far fewer than the multitude of problems existant in the new search.

I cannot ignore my inference that the situation is this: The powers-that-be determined that a new search engine (outhouse) should be built and, now that it has been built, they are committed to that decision and, for whatever reason,  have determined that no significant resources will be devoted to repair - much less improve - the old one.

I believe there would be considerable value in investing resources to improve both, each with its strengths and weaknesses, rather than abandoning the old entirely, thus sacrificing its considerable and singular advantages.</description>
		<content:encoded><![CDATA[<p>Hi Ann,</p>
<p>I believe that my meaning in my previous comment (#13) was unclear.</p>
<p>The penultimate goal is or should be that the search results conform to the user&#8217;s needs and desires.  UI templates, therefore, are important, because they provide the gateways to results, contrary to what I infer from your comment that &#8220;[w]e will not be making changes to the current old UI system. Maybe not the answer you were looking for, but I believe it is the correct answer.&#8221;  I don&#8217;t think neglecting the UI templates, in either the old or new search engines, is the correct answer.  </p>
<p>Although your comment was referring to the old search, I cannot help but wonder if that concept will not also apply to the new search at some point.</p>
<p>I would suggest this analogy.  If the door hinges on the outhouse need repair, one does not build a whole new outhouse.  One simply repairs the hinges so that the door works properly.  As the old saw says: Don&#8217;t throw the baby out with the bath water.</p>
<p>If the door won&#8217;t open or close because the hinges don&#8217;t work properly, the hinges will need to be repaired, whether the outhouse is old or new, unless the plan is to raze the old.</p>
<p>The UI template is akin to the hinges.  As the hinges are critical to reaching the goal of an outhouse door that opens and closes properly, the UI templates are critical to obtaining the desired search results. It will always be important to revise or improve the UI  templates to obtain the search results users need and desire.</p>
<p>My interpretation of user comments thus far seems to indicate that although there were problems with the old search, these were far fewer than the multitude of problems existant in the new search.</p>
<p>I cannot ignore my inference that the situation is this: The powers-that-be determined that a new search engine (outhouse) should be built and, now that it has been built, they are committed to that decision and, for whatever reason,  have determined that no significant resources will be devoted to repair &#8211; much less improve &#8211; the old one.</p>
<p>I believe there would be considerable value in investing resources to improve both, each with its strengths and weaknesses, rather than abandoning the old entirely, thus sacrificing its considerable and singular advantages.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike</title>
		<link>http://blogs.ancestry.com/ancestry/2008/08/18/specific-database-search-old-search-ui-vs-new-search-ui/#comment-17669</link>
		<dc:creator>Mike</dc:creator>
		<pubDate>Sat, 23 Aug 2008 19:06:59 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.ancestry.com/ancestry/2008/08/18/specific-database-search-old-search-ui-vs-new-search-ui/#comment-17669</guid>
		<description>I want to echo Jerry&#039;s #78 comment that an exact search should *never* result in a ranked search.  

When we check a couple field boxes &quot;exact&quot; and then not others, we are in effect getting a ranked net result, but where *we the users* have set the parameters.  These type of semi-exact overall searches with some fields exact and some not, can be very powerful techniques.  But all that is ruined if Ancestry forces ranked search results on every field no matter that we have checked exact on some.

As an example from census searches, I would rather soundex fuzzy last name ranked searches for the surname and its variants that I am searching for in a single county/state, instead of first seeing exact matches in other geographical areas.  I can only get these type of results by a field by field ability to choose some exact and leave others not.</description>
		<content:encoded><![CDATA[<p>I want to echo Jerry&#8217;s #78 comment that an exact search should *never* result in a ranked search.  </p>
<p>When we check a couple field boxes &#8220;exact&#8221; and then not others, we are in effect getting a ranked net result, but where *we the users* have set the parameters.  These type of semi-exact overall searches with some fields exact and some not, can be very powerful techniques.  But all that is ruined if Ancestry forces ranked search results on every field no matter that we have checked exact on some.</p>
<p>As an example from census searches, I would rather soundex fuzzy last name ranked searches for the surname and its variants that I am searching for in a single county/state, instead of first seeing exact matches in other geographical areas.  I can only get these type of results by a field by field ability to choose some exact and leave others not.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jade</title>
		<link>http://blogs.ancestry.com/ancestry/2008/08/18/specific-database-search-old-search-ui-vs-new-search-ui/#comment-17642</link>
		<dc:creator>Jade</dc:creator>
		<pubDate>Sat, 23 Aug 2008 13:22:41 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.ancestry.com/ancestry/2008/08/18/specific-database-search-old-search-ui-vs-new-search-ui/#comment-17642</guid>
		<description>Re: 1900 US Census - Edith #798 and Jerry #80.

As a result of the LDS-Ancestry partnership, where Ancestry has uploaded the LDS&#039; digital imaging of the 1900 US Census enumeration from its original microilm, Ancestry also uploaded the LDS&#039; index, *adding it* to Ancestry&#039;s existing index.  Thus now the index includes various alternative readings from each source.

I am not sure how the search engine was adapted for this purpose, or whether a special search engine for this enumeration was uploaded from LDS.

Naturally Ancestry.com has not seen fit to explain this and the multiple search results, as it easily could do on the search form.  &quot;Why should we bother to tell the customers?&quot; continues to be a core element of Ancestry.com Culture.</description>
		<content:encoded><![CDATA[<p>Re: 1900 US Census &#8211; Edith #798 and Jerry #80.</p>
<p>As a result of the LDS-Ancestry partnership, where Ancestry has uploaded the LDS&#8217; digital imaging of the 1900 US Census enumeration from its original microilm, Ancestry also uploaded the LDS&#8217; index, *adding it* to Ancestry&#8217;s existing index.  Thus now the index includes various alternative readings from each source.</p>
<p>I am not sure how the search engine was adapted for this purpose, or whether a special search engine for this enumeration was uploaded from LDS.</p>
<p>Naturally Ancestry.com has not seen fit to explain this and the multiple search results, as it easily could do on the search form.  &#8220;Why should we bother to tell the customers?&#8221; continues to be a core element of Ancestry.com Culture.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jerry Bryan</title>
		<link>http://blogs.ancestry.com/ancestry/2008/08/18/specific-database-search-old-search-ui-vs-new-search-ui/#comment-17637</link>
		<dc:creator>Jerry Bryan</dc:creator>
		<pubDate>Sat, 23 Aug 2008 13:01:28 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.ancestry.com/ancestry/2008/08/18/specific-database-search-old-search-ui-vs-new-search-ui/#comment-17637</guid>
		<description>Edith #79, thank you for posting your message.  I had not yet encountered the 1900 census problem with Old Search.  But I just repeated your exact search for Joseph Harker in the 1900 census, and I got the same results you did.  There are 96 hits, and most of the hits are for household members of Joseph Harker rather than for Joseph himself.

It&#039;s almost as if the problems from New Search have jumped over and joined Old Search.  Indeed, just out of curiosity I repeated your search with New Search, and I got the exact same 96 hits as I did with Old Search.</description>
		<content:encoded><![CDATA[<p>Edith #79, thank you for posting your message.  I had not yet encountered the 1900 census problem with Old Search.  But I just repeated your exact search for Joseph Harker in the 1900 census, and I got the same results you did.  There are 96 hits, and most of the hits are for household members of Joseph Harker rather than for Joseph himself.</p>
<p>It&#8217;s almost as if the problems from New Search have jumped over and joined Old Search.  Indeed, just out of curiosity I repeated your search with New Search, and I got the exact same 96 hits as I did with Old Search.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Edith</title>
		<link>http://blogs.ancestry.com/ancestry/2008/08/18/specific-database-search-old-search-ui-vs-new-search-ui/#comment-17607</link>
		<dc:creator>Edith</dc:creator>
		<pubDate>Sat, 23 Aug 2008 04:44:47 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.ancestry.com/ancestry/2008/08/18/specific-database-search-old-search-ui-vs-new-search-ui/#comment-17607</guid>
		<description>The new search is not friendly or simple and now you have messed up the old search with the 1900 United States Federal Census - Updated...I don&#039;t want the wife, the sons, the daughters or anyone else in the household in my search results when I am searching for Joseph Harker. I just want the name I enter, nothing more.</description>
		<content:encoded><![CDATA[<p>The new search is not friendly or simple and now you have messed up the old search with the 1900 United States Federal Census &#8211; Updated&#8230;I don&#8217;t want the wife, the sons, the daughters or anyone else in the household in my search results when I am searching for Joseph Harker. I just want the name I enter, nothing more.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jerry Bryan</title>
		<link>http://blogs.ancestry.com/ancestry/2008/08/18/specific-database-search-old-search-ui-vs-new-search-ui/#comment-17591</link>
		<dc:creator>Jerry Bryan</dc:creator>
		<pubDate>Fri, 22 Aug 2008 23:36:22 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.ancestry.com/ancestry/2008/08/18/specific-database-search-old-search-ui-vs-new-search-ui/#comment-17591</guid>
		<description>Another comment on Anne&#039;s #35:

&lt;i&gt;Re #20, Actually Jerry I think we do agree on ranked searches.
.........
I do understand what you are saying — but again, the fix is different
than a UI fix.&lt;/i&gt;

Anne, I don&#039;t think we are yet on the same page with respect to the star ranking system.  Your comments referred to ranked searches.  I do think ranked searches are fine and a star ranking system is fine for ranked searches (just star rankings like for restaurants and hotels and movies).  And I am pleased that you are working on improving the ranking system for ranked searches (re: the text I omitted for brevity).

Where I disagree (and I tried to lay out the details in #20) is that I don&#039;t think exact searches should ever be treated as ranked.  For exact searches it doesn&#039;t matter what the ranking system is, and it doesn&#039;t matter whether the ranking system is great or lousy or somewhere in between.  Within one particular exact search, all hits are equal.

It then makes no sense to rank items that are equal.  If I take a test and get a 100, you take a test and get 100, and a third person takes a test and get 100, how do we rank our scores on that particular test?  Am I first, or are you?  It&#039;s simply not a meaningful question.  That&#039;s not to say that I might not rank lower or higher than you on a different test.  But on this one particular test we are equal.

This really is a UI issue, not a search engine issue.  Old Search does not rank the hits from an exact search and New Search does.  All the differences between Old Search and New Search are UI differences, so ranking exact searches can’t possibly be a search engine issue.</description>
		<content:encoded><![CDATA[<p>Another comment on Anne&#8217;s #35:</p>
<p><i>Re #20, Actually Jerry I think we do agree on ranked searches.<br />
&#8230;&#8230;&#8230;<br />
I do understand what you are saying — but again, the fix is different<br />
than a UI fix.</i></p>
<p>Anne, I don&#8217;t think we are yet on the same page with respect to the star ranking system.  Your comments referred to ranked searches.  I do think ranked searches are fine and a star ranking system is fine for ranked searches (just star rankings like for restaurants and hotels and movies).  And I am pleased that you are working on improving the ranking system for ranked searches (re: the text I omitted for brevity).</p>
<p>Where I disagree (and I tried to lay out the details in #20) is that I don&#8217;t think exact searches should ever be treated as ranked.  For exact searches it doesn&#8217;t matter what the ranking system is, and it doesn&#8217;t matter whether the ranking system is great or lousy or somewhere in between.  Within one particular exact search, all hits are equal.</p>
<p>It then makes no sense to rank items that are equal.  If I take a test and get a 100, you take a test and get 100, and a third person takes a test and get 100, how do we rank our scores on that particular test?  Am I first, or are you?  It&#8217;s simply not a meaningful question.  That&#8217;s not to say that I might not rank lower or higher than you on a different test.  But on this one particular test we are equal.</p>
<p>This really is a UI issue, not a search engine issue.  Old Search does not rank the hits from an exact search and New Search does.  All the differences between Old Search and New Search are UI differences, so ranking exact searches can’t possibly be a search engine issue.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Carol A. H.</title>
		<link>http://blogs.ancestry.com/ancestry/2008/08/18/specific-database-search-old-search-ui-vs-new-search-ui/#comment-17581</link>
		<dc:creator>Carol A. H.</dc:creator>
		<pubDate>Fri, 22 Aug 2008 21:13:36 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.ancestry.com/ancestry/2008/08/18/specific-database-search-old-search-ui-vs-new-search-ui/#comment-17581</guid>
		<description>From Anne&#039;s #35:

&quot;Re #20, Actually Jerry I think we do agree on ranked searches.
Here’s our plan: we are working on a different scoring system,
hopefully it will be in beta soon. (Fingers crossed) One of the
goals of the particular system is that the user could define if the
results should be 5 stars only, 4/5 stars, etc. Our currenty ranking
system isn’t really built to do that well. And yes, it is a search
engine issue, instead of an interface issue. And very important.
I will let you all know when I feel like we have a date for the
beta.&quot;

I say:  Forget the stars.  They are less than helpful!  They only take up screen space.  I know the value of the results better than the search engine/interface.  I can think more logically than the search engine/interface because I know other information and I&#039;m thining about other things that I have not entered into the search form, for what ever reason.</description>
		<content:encoded><![CDATA[<p>From Anne&#8217;s #35:</p>
<p>&#8220;Re #20, Actually Jerry I think we do agree on ranked searches.<br />
Here’s our plan: we are working on a different scoring system,<br />
hopefully it will be in beta soon. (Fingers crossed) One of the<br />
goals of the particular system is that the user could define if the<br />
results should be 5 stars only, 4/5 stars, etc. Our currenty ranking<br />
system isn’t really built to do that well. And yes, it is a search<br />
engine issue, instead of an interface issue. And very important.<br />
I will let you all know when I feel like we have a date for the<br />
beta.&#8221;</p>
<p>I say:  Forget the stars.  They are less than helpful!  They only take up screen space.  I know the value of the results better than the search engine/interface.  I can think more logically than the search engine/interface because I know other information and I&#8217;m thining about other things that I have not entered into the search form, for what ever reason.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
