I also learned that if you can’t enjoy the thrill of breaking through your own brick walls, watching someone else do it is pretty fun. At our booth, we had 4 computers logged into ancestry, and people would come up and do searches. This one guy found a Canadian Census, with what I believe were his great grandparents on it. He was giddy…hopefully all of you know that feeling as well. (And no, I don’t know if he was using old search or new search. )

The third thing I learned, as I watched people use new search, by far the most interesting and useful piece to most people I worked with was the ability to turn exact on for different types of fields. And as I watched many people do many searches, it would appear that you will get the most mileage on your searching if you choose exact date ranges and exact locations. Toggling between different combinations of what is exact and not exact is also useful in bringing up different sets of information. My anecdotal evidence shows that choosing all exact fields is just not all that great.

Meanwhile, back here at the ancestry.com ranch, we’ve been digging and working on some issues around the new search user interface:

• Marriage records. Many of our marriage record data sets are, to be technical, quite foobar-ed in the new search user interface, as some of you know. And we know why. Some of these data sets were created many years ago, in ways that we don’t store our data sets anymore. And while we hacked around it back in the old search interface, we don’t hack too much in the new one. And yes, I know what some of you are thinking or muttering, well just go back to the old way and it’ll all be fine. No. Not the answer. I truly believe that fixing the data and standarizing is the way to go. No word on when things will be reformatted…you have no idea what goes into (that would probably make an interesting post), but I’ll keep you up-to-date. And remember, you can always go through the old search ui for now.
• Soundex and matching algorithms. We are currently working on the back end pieces to bring you that option back..stay tuned.
• State and country pages. We are working on bringing those up-to-date and giving you a way to easily access those. For example, try looking at the Virginia Database Page or the Italy Database Page. Also check out the Sources pages and the How To’s pages. Now would be a really, really good time to tell me what you think is a must have on those pages and what you really don’t care about. So start voicing your opinions now!

I’m still too tired from all of the traveling and the hot muggy weather to finish commenting on my previous post. I’ll finish it off before the week ends.

And if you have civil war ancestor’s in your past, I recommend the previous post by Jeanie Croasmun : Why So Many Names?. I know I learned something new.

Reed, who has commented a few times on my blog posts, has given us an example that wasn’t working too well last week, but with a few clicks we can make work this week. I’m going to use Levi as starting place to show you a few ways to use new search effectively.
So what do we know about Levi?

Name: Levi S Baker
Born: 1827
Died: 1910
Lived in: Chicago, Illinois

So I go to ancestry.com search homepage and begin (remember to click on the image to see a bigger version of the screen shot):

I’m starting off with exact off, to cast a wide net across all the documents on ancestry to see what I can find.

You’ll notice that I am using the place typeahead. You may type Chicago, Illinois out if you like. But notice all of the different choices for Chicago. If you just type Chicago, you may be confusing the search engine.

So I press the search button, and this is what I see:

I notice that there are 4,379,864 results. Huh? Either Levi is the most documented guy on the planet, or I need to find a way to rein the search engine in. So let’s rein it in.

I press r (just r, it’s a hot key), and I see:

I know Baker is his last name, so I choose that to be exact. And that didn’t really help. I know he was born in 1827, and I know lots of records have birth year, so I choose that to be exact. But I also know that birth year’s can vary, so I’m going to add a 5 year range:

Random note: I like to set up a 5 year range on either side because I have found that to be a common place where census takers and other record keepers make mistakes. Either that, or my ancestors didn’t like to tell the truth about their age.

Ok, that brings it down to 101,000 + records, and the first 4 or 5 records look like real matches, but what is all of this:

I notice that my first name is Levi S. The initial S is matching other S’s in the search results. Sometimes record keepers took a few shortcuts. Do you think if they had known how much grief this could cause us, they would have done it differently?

A quick look at my top results tells me that my guy was probably born in Vermont. So I add that to my search request:

and here are my top 5 search results, out of about 750 results.

I could choose more exactness throughout the query, or I can just think that this is OK and flip through 2 or 3 pages.

Questions

In this example, I used the exact checkboxes to limit my results and try and improve them. And that brings me to my questions for you:

1. Places. What does an exact place mean to you? If I choose Chicago, Illinois, should a record be considered a match if the place is just Illinois? What about if it is in Cook, Illinois?
2. Dates. If I say 1827 and choose exact, should it be only 1827 or would you include 1826 and 1828 because they are close enough?
3. Names. If type in Levi and choose exact should that just match Levi? What about Levi S? Should it match L as well? What about derivatives or mispellings? Would you include Levy? What about Louis?

I expect these answers to vary from person to person. I’m hoping if we can come up with enough common themes, we can create better choices on the site.

(Note: If you click on the image, you will see a larger version; if you click on the title, it will send you to the search page. You may need to flip back and forth between old and new, but this should work..)

Once you look at these, if you could let me know pros and cons of both UI’s and be specific about what you like and don’t like in these two cases, it will help me focus in on what may need to be done. The more specific you are, the more helpful it will be.

1900 Census Old Search UI example

Let’s say I’m looking for a male, surname Lynn, born between 1840 and 1850 in New York, and I know he lived Lafayette, Tippecanoe County, Indiana in 1900.

If you go to the old search interface and enter this data, you will see:

which results in :

1900 Census New Search UI example

This is the same search on the new UI:

which results in:

So what works and what doesn’t

A couple of good things that I see with the new search UI are:

1. If you pass your mouse over view image, you get a preview of the information in the record. If there are 10 links on this page, you can quickly look at them without click to each record page to see what is there.
2. You can see what is in the query that produced these records, what you choose to be exact (it has ” ” around it in the query), and you change, delete or add a parameter for your search without changing pages.

New Search Interface Webinar

or

http://w.on24.com/r.htm?e=112633&s=1&k=F61A5B2CBEC642037CADDF67687EA541

The view archive link is at the bottom of the page.

If you want to discuss the new search interface, I suggest :

New Search Interface

Happy Viewing!

I believe that the biggest problem that has been discovered is that the detailed searching on some datasets is not available for the new search interface. For example, on a marriage record, you can’t specify a groom’s surname. This ability to use your knowledge of the data that is stored in any given dataset is hampering your ability to pull out records in a manner useful to you. I think this is a problem. I don’t have a solution for it today, but I believe a solution can be found.

I know some of you would simply like the new search interface thrown out and the old search interface become the only search interface. I don’t think that is the correct answer.
From looking at search results and search patterns, and from comments (and there were hundreds of them) from the webinar, that were largely in favor of the new search interface as well as surveys we have conducted, there is a lot of enthusiasm for the new search.

I suspect that the answer is in adding in a way to filter on fields specific to the database as well as some other tweaks/improvements to get the new search interface working properly.

Some of those improvements might include solutions to these problems that surfaced in your comments:

• Limit the number of results that you see at one time
• You want a way to be able to search census records and not see records before the birth date and after the death date.
• You would like an option to limit your searches to not include certain data sets, for example family trees.
• Some of you believe, that a document should only be excluded if the contents of that document explicitly contradict what you have entered. (This applies mainly to death dates on census records, mainly.)
• There are times when you want every thing ancestry can find on a person, and there are times when you want to be able to filter those result by specific data sets or general categories of data sets.
• Some of you would like the ability to turn off type ahead for names and locations.

Now, I’m sure that I’ve missed a few things, or not stated things in the clearest manner.

I need to have some conversations with engineers, designers and other product people and try and figure out solutions to some of these issues and if we can get solve them in a timely manner. Not all problems are easily solvable. And I don’t want to make promises I can’t keep. But I do want make sure I understand the problems before I try and figure out solutions.

I’ve been reading your comments over the past few months and I have an idea of what you think is working and not working. I’m hoping you will continue to share your thoughts on what works and doesn’t work with us. This is my first week on the job and I’ve spent time talking to our search engineers and the rest of the team trying to get an understanding of how the system works, and what is being worked on. There is a lot going on here, and it will take me a little while to get completely up to speed so I’m hoping you can be a tiny bit patient while that happens.

The new search interface is the hot topic of conversation. It’s not a new search engine; it’s just a new way to interact with the search engine. And yes, I know, it’s not always behaving in a way that you expect. But it’s a never-ending process of improvement for us. There are many plans in the works to improve the interface and the backend engine to bring you better results.

I’ve been reading the posts and some of you have done a good job of documenting searches and unexpected behaviors in the search results with new search interface and the old search interface. Now, I can’t address all of them in one posting, but I am going to starting pulling a few at random and try and dissect them here so that we can make some progress.

The case of John Cousins

So let’s begin with a posting by Tony C about one of his ancestors John Cousins. Here’s the snippet to get us started:

Name – John Cousins – exact
Born 1816 +/- 2 years – exact in Suffolk, England – again
and
Now add the fact that he died somewhere around 1877, again in Suffolk, England – exact all you get are family trees.

OK, so this is what I tried in the new search interface (click on the image to see the results):

And sure enough, I get family trees. Not there is anything wrong with family trees, but we would like to get some other documents. The issue lies with “exact”, specifically, the location, and how the data is stored.

So let’s back off on some of this “exactness” and see what happens. Unclick the exact on the locations:

Ahhhh…..that’s better.

Now I’m seeing census links and BMD records. So what happened?

Back to the new search interface. Why is exact location wrong? Then it hits me, a census record doesn’t know the exact location of death. How can it? John Cousins is still alive when the census was recorded. What if I just try “unexacting” the death location:

I see the census records. Interesting. But no BMD records.

So I try the opposite:

So what does this tell me. Exact death location will prohibit me from getting a census record. Does that make sense? I think it does. A census record does not contain death information so it shouldn’t match.

In the old search interface, your “exactness” was much more general, and it was sort of hit or miss in how it worked. In the new search interface, you can be very specific, and that ultimately gives you a lot more power in refining your searches. Which can a very useful tool when you are trying to wade through a bunch of records.

Now I know some of you are sitting there thinking, “Um, Anne, I really don’t want to think that hard, I just want to see the records I need. Old interface search gave me what I wanted.” I think maybe some of you are luckier than I am, because the old search interface was NOT always giving me what I wanted. But you probably don’t want to hear my long journey through the western Virginia census records. I ended up having to read through them to find what I wanted (which is sort of fun anyway). I just couldn’t be specific enough to find what I needed. I am finding some better results with the new search interface.

Over the next few weeks, I will try and pull up more of the examples you all have had trouble with and see if we can’t figure exactly why the new search interfaces produces what it does and if it is reasonable.

And I’ll show you some of the successes I have had as well, and hopefully some of you can share those with me as well.

Hang in there, we are going to work on making search on ancestry the best it can be. Stay tuned.

• Record Previews
• Image Snapshots
• Refined Searches
• Type-ahead Tools
• Global Searches
• Advanced Searches
• Filters
• Keyword Searches

Anyone can register to attend the webinar by visiting the New Search Webinar Registration

The webinar is open to everyone; you do not have to be a member of Ancestry.com to register for or attend the webinar.

Allow me to clear up a misconception that the new home page on Ancestry.com and the new search interface are related—they are not.  When we launched the new home page, there was a bug that inadvertently took many of the new home page visitors into the new search experience at the same time.  We’re sorry about that—the bug has subsequently been fixed.  So, if you find yourself in the new search experience and would like to switch back to the old search experience, you can do that on any of the search pages, just not from the home page itself.  I hope that helps. 

Let me summarize some of the key issues that people have brought up so I can respond to each one in turn:

1. The exact settings don’t seem to work the same way between the new and old search experiences

Thanks for the feedback on this issue.  Specific examples have helped us identify a significant bug in the system that was indeed preventing the exact matches from returning appropriately in the new search.  We’ve fixed that bug and things should be much, much better now.  If you’re still seeing cases where you’ve marked exact on the search or on a specific field and it looks like it is being ignored somehow, please let us know.  We want to make sure we get these issues resolved as soon as possible.

2. The “fuzzy” search returns too many results

We’re working on making the search engine stricter about what results it returns, even on “fuzzy” searches—this should dramatically reduce the number of matches that are returned.  Additionally, you can always turn on the “Advanced” features on the new search and simply mark any field as “Exact” to ensure that results matching only the appropriate information are displayed.  You can also check a single box to make the entire search “Exact” so only items matching all of your criteria exactly are returned.  I think that using this filtering technique (some fields exact, others not) is the best way to get the most out of our search system.

3. Some activities in the new search take more clicks than they did in the old search

Although we’ve tried hard to make the new search experience stream-lined to save clicks in many ways, there are some activities that do indeed take more clicks to accomplish in the new search experience than they did in the old experience.  We’re looking into what we can do to improve that.  One idea we’re playing around with is allowing a keystroke that would bring up the “Refine Search” form up all at once for easier editing.  What do you think?  Also, what are the other areas where it is taking you more clicks?  Specific examples are very helpful.Overall, however, we have developed a new search experience that ultimately should save you clicks as you search for ancestors.

4. The “fuzzy” search engine should return better matches and filter out blatantly wrong matches

Absolutely agree.  We’re working on it—it just takes a long time to make the enhancements we’re hoping for.  Stay tuned.

5. You should focus on making exact searching more powerful (example: get rid of the three-character limit on wildcard searching)

This is something that we’re looking at very closely—we want to make our advanced researchers happy with the tools we provide.  As a result, I’d love to talk more with a few of you who consider yourselves to be advanced researchers to pick your brains on some ideas we’re thinking about in this regard.  If you’re interested, please send me a note to new-search@ancestry.com.

6. The new search is really designed for “fuzzy” searching

Although we did think a lot about “fuzzy” searching in the new search interface, we also considered exact search very carefully.  We added the “View” option to the search results (look for a drop-down on the right-hand-side of the search results) that lets you see the search results Summarized by Category so you can easily see the list of matching databases—this is particularly useful for exact searching.  Additionally, we made exact searching more powerful than it used to be because you can now specify whether you want a particular field exact or fuzzy on a particular database.  For example, you can now say I want to see results only where the residence was “Spokane, WA” and the last name is “Smith” but leave the first name as a fuzzy result for “John”. 

7. The location type-ahead feature doesn’t work well for counties and/or when searching a specific database

We’re reviewing the way that the location type-ahead feature works to improve it.  Specifically, we’re adding in the county names into the type-ahead list to make it easier to see what county you’re searching on.  When you’re searching on a specific database, we’re also looking into constraining the list of place matches to only matches that are available in the database.  If you have other feedback on the place type-ahead, please let us know.  We’d love to hear it.  Finally, I want to reassure everyone that we’re taking your feedback very seriously and looking carefully at ways to improve the new search experience.  Please continue to send constructive, specific examples and feedback to help us in that process.

 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.)