Learn About the New Search in DearMYRTLE’s Podcast

Kendall Hulet, Director of Product Management for Ancestry.com, discusses the new Ancestry.com search in this week’s edition of DearMYRTLE’s Family History Hour genealogy podcast.
Kendall offers some tricks and tips for maximizing success in the new search and explains some of the reasons and development process behind the new search.
You can listen to the podcast on DearMYRTLE’s website here. (The segment with Kendall begins 12 minutes into the podcast.)


I listened to the podcast and played with the new search screen at the same time. I came to the same conclusion that the new search screen is not efficient.
Ken compares an Ancestry database search to a google search. Actually, Ken, Google is better than Ancestry.com with the new search. At least with Google, you can put in boolean statement and narrow down the results considerably. But, it should be easier to narrow the results with Ancestry.com. Ancestry’s searches are across databases that have either fields of data that are nearly the same as the criteria fields or contain text that can use boolean searches and proximity searches behind the scenes. You were closer to that objective with the old search interface.
Not sure what a “strong search” is in your program. To me, if I do an exact search and if the data entered is included in the corresponding fields, it is a strong match. If for example, I enter James Hensel in and a location of Bureau, I would expect any any results that have “James” and “Hensel” in the name fields and “Bureau” in the location field to be considered strong matches because that is what I entered!
The results are inconsistent. I tried to search the 1910 census using a common search. I want anyone with a last name of “Zearing” in the township of “Princeton”. The old search (exact search chosen) returns 7 matches. The new exact search returns 0. If I turn off Exact search in the new search interface, I get 113! The relevant ones are not even on the top! The one on top “Rebecca J Zearing” doesn’t even contain Princeton anywhere in the location!
May I suggest that your test group compare the results from searches under the old method with the new method. I have found nothing today in my “playing” that makes more sense in the new search interface.
Regarding the multiple location option, it only works for non-exact searches but is allowed for input in an exact search. Why can’t you incorporate it into the exact search? For example, return: (Name = Name in database) AND (Loc 1 = Location in database or Loc 2 = Location in database) and set for unique so that if Loc 1 is a county name and Loc 2 is a state name, you don’t get 2 returned of the same county/state combination.
Please rethink this interface! It is nonsense!