If you look at this snippet from a search for my great uncle Ashby:

You’ll notice the green check next to records you’ve already saved to that person, which I truly love. If you have more than one tree, make sure the person you are searching for is in the your active tree, otherwise you won’t see the green check.

The person card is set up to follow you down the search results so that you can compare what you have in your tree to the search results. A few people love it, and a few seem to hate it’s floating capability. Weigh in with your thoughts so we can pick a good solution.

So if you are searching for someone you know lived in Canada his entire life, you can tell the search engine to give more weight in ranked search for records that have been specifically identified as Canadian records. This includes Census records, newspapers, various vital records as well as others.

In addition to prioritizing collections, choosing a value helps us know whether to apply a different soundex algorithm or use different name dictionaries to better find approximate matches for the names you entered.

For example, let’s say you are searching for Robert Jones, and you know he was born in England about 1830, but he lived most of his life in Canada. Our search engine will find many matching records for Robert Jones in England, Canada, the US and elsewhere. If you choose to prioritize Canadian collections, we know that those will be more likely to contain records you want. So if multiple records match your search equally well, we will list records from our Canadian collections first.

If you ancestor has lived in multiple places, I would suggest you do multiple searches, using a different set of collections that might contain your ancestor with each search. It never hurts to check anywhere that might be even remotely possible. You never know where that elusive record you are looking for might be.

If you are not sure which collection to use, choose the “All Collections” option, and we will look at every collection equally.

We don’t have enough data sets to form a good collection for all countries and ethnic backgrounds. As our collection of data sets grows, we will continue to add more collections.

To find databases that cover a specific topic, the best place is to start with the Ancestry Card Catalog, which you can find under quick links on the ancestry home page. When you are at the Card Catalog, type a word into the Title or Keyword field and press Search. You will see a list of data set titles that pertain to that topic. From there you can click on a data set title and search it individually for your ancestor.

If you press ‘n’, you will see a brand new search form pop up over your browser.

If you press ‘r’, you will see a search form pre-populated with the data you just searched on.

You can also walk through the previews on a search, by first pressing ‘p’ and then pressing ‘>’ to
move down the list and ‘<’ to move back up. (’j’ works for forward and ‘k’ works for backwards as well)

We may have some template changes to show you next week, that I’m guessing some of you will find quite interesting.

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.