To directly answer your questions:

1. Exact “Chicago, IL” should only include records from Chicago, IL – otherwise I would say “Cook County” or just “Illinois”

2. 1827 should only return results from 1827 or in regard to 1827. Otherwise, I can use the +/- variables.

3. An exact search for “Levi” must return the name “Levi,” not just “L.” However, I’m not sure if this new search can tell the difference between first, last and middle names. Otherwise, I’ll unclick “exact”

Here’s the thing: we need an exact search to be an exact search. If I specify that I want to search in a specific location, that means that I only want to search in that location. It’s that simple. I need to be able to control my search and be able to search for exactly what I need. I can always change the variables if I need to.

On the other hand, I think that leaving exact off often result in returns that are too broad. I don’t want to search for (not exact) Ruby Waters and receive records for Thomas R. Waters, Estelles Waters, Jay G. Waters, etc., like I am now. I think that this topic was really well explained by DanB & Jerry Bryan (among others) on the last blog post.

Also, one thing that an exact search shouldn’t do is to disregard a document if that search field isn’t applicable to the data. This is one of my biggest pet peeves about the new search.

I agree with Valerie. I think exact checkboxes should be very precise about the item being searched. There should however continue to be methods of making the search “slightly fuzzy” such as the +/- capabilities on the year searches. I would also enjoy lots of wildcard options. I haven’t researched to see what kind of wildcard searches can be performed yet, but searches with ?, *, etc. are always very helpful for me in outside databases such as library databases.

As far as location searches, I definitely think that less specific locations should be more encompassing. Like Chicago, IL only searches that city. A less specific state search should search all cities, towns, counties inside of that state. I might also enjoy using a multi-state search. Maybe check a series of boxes so that I can search Illinois, Tennessee, and Kentucky all at the same time, but not other states. Anyway, just some ideas. Thanks!

To answer the questions first. Place when doing a search to me means the most speciic first follwed by a gradually increasing ring from that spot. So if I was looking for the 1200 blk of 10th street in Chicago, Illinois I would expect result to be ordered closest first out to the most remote. If I found an address of 1225 10th st and one of 1275 10th they would appear st the top of the search list. Address that were from the 1100 or 1300 block would follow and so on in ever increasing rings.

If I put a date and mark it exact I expect it to return that exact date. If I put an exact date with a range of +/- 5 I expect everything to be within that 10 year period.

If I put exact in I expect an exact return. I would like to be able to use wildcards and still get an exact answer using either a ? for a single character or * for multiple characters. I would like to be able to select a soundex match as well but not nessicarily as part of an exact search.

Now that I have answered the questions the one thing that frustrates me more than anything else about the search tools is the inability to sort the results on one or more fields. For example I would like to be able to sort the results on last name and brth year. After sorting the results I don’t want to have to flip through each page to get to the next one. I want to be able to go straight to the end of the list or reverse the order. I am an of the alphabet named person and so are a large chunk of ancestors. I find that like myself many of my ancestors had spelling issues and did not care to mention their exact age. LOL

1. I’m having a hard time with the question about locations. I don’t know if I’ve ever searched on a city before as my first search. Nearly everything I research is keyed primarily to county and state – census records, tax records, deeds, wills, marriage records, divorces, settlements, guardian bonds, court cases, WWI draft card records, etc. Some of these kinds of records are scarce at ancestry and some are not. For those that are scarce at ancestry, I have to use libraries and courthouses, but the principle is the same in any case. To look for Levi, I would have looked for Cook County, Illinois, specified in whatever format is required by the UI. On rare occasion at ancestry, I will refine a county/state search to a finer subdivision (or even to a street, if the street is indexed) to reduce the number of hits, but only after I’ve done the county,state search. And often the finer subdivision is some kind of district rather than being a city.

2. The year needs to be precise if it’s +-0. I would rather do my own +-2, +-5, etc. Otherwise, does +-2 really mean +-3 and does +-5 really mean +-6?

3. Exact on Levi should only return Levi, not L. The problem of searching for initials is another kettle of fish altogether. The Louis in your search appears to have been included only because somebody posted a correction that it was really Levi rather than Louis, which is fine. Absent that correction, Levi would not and should not have matched Louis. Old Search told me about the correction, but New Search did not. It’s hard to know what else Levi could legitimately match, so let me give a different example. There should be an “exact” way without wildcards for Elijah to match on Elijah, Elija, Eligah, and Eliga, for example. But there also should be an “exact” way for Elijah to match only Elijah. The old familysearch.org had this capability. The new familysearch.org is getting too complicated for me to figure out so far in this regard. The old familysearch.org called the search that would match Elijah only with Elijah an exact search. The old familysearch.org did the search that would match Elijah against any of Elijah, Elija, Eligah, and Eliga if the exact option was not checked. But not checking the exact option on familysearch.org did not do a fuzzy search in the same sense as ancestry.com. Rather, not checking the exact option did an exact search against the name authority. In other words, there are two kinds of exact searches that are needed on names before you even get to fuzzy searches – truly exact, and name authority exact.

Anne,

To echo the previous comments, we have more of the same exact is still not really exact.

I suspect the reason for this is the divide again between experienced users and those who are not so, and your marketing department’s desire to save the less experienced from misusing the exact boxes and finding few or no hits, and then being dissatisfied with their subscriptions. Please comment on whether this presumption of mine is correct, i.e. that Ancestry is resisting saying “exact means exact” because the masses won’t use it “properly”.

In that case the remedy is clear, have a search tier beyond “advanced” which is “super advanced” or something and where exact does in fact mean exact, and where if every criteria in those fields checked as exact are not met, then the search returns zero results.

We’ve said it before and we’re saying it again. Don’t make us take a dumbed down search function because the majority does not realize what exact is.

I haven’t had a time to digest the new blog page; posting site; (or whatever is the correct name,) fully yet, but one thing stands out. Jerry Bryan pointed it out. Most records are at county levels. There are of course some big cities that will have control of some records, but counties were more important for records historically than towns or cities.

I notice missing “type ahead” counties in lists, and it really bugs me! That is one of my first impressions. I use counties more than cities in my searches.

Again I say, “Forget the stars.” Also, new search shows fewer records on each “screen” than old search. That also bugs me.

More later.

What you fail to menton here is this: using the same criteria, the Old Search returns, on the first try, five good hits (the total is actually 13, but that’s because the “updated” 1900 census index returns everybody — including boarders — residing in the household).

That’s much more efficient than the multiple clicks, multiple paging about, multiple entries required to trick New Search into returning useful data.

One click. Bingo.

The fact that I know the exact date for something doesn’t mean that the database will include it. As we all know, the 1900 census is the only one that includes the year; for all the others, year is a guestimate generated by the indexer. Marriage records in many places don’t include the year of birth either, just age. That means that “exact” searches in records that include age rather than birth year, often fail even though the searcher has the right information.

For that reason, I think “exact” searches should default to “+/- 1″ with a radio button or something to specify “this year only”.

To me exact has always meant exact – so if I choose to check the box that is what I’m asking for – exact matches to the fields I specified.

Athena – #8

People are already complaining about how many clicks it takes to start a search – why add a radio button to state only that year when you’ve already specified exact. If you want a range of +/-1 on a year then don’t choose exact and select the +/-1 year.

TonyC

Anne,

Your questions:

1. Exact place should return items from Chicago, Cook County, Illinois. If I want to broaden the search to the rest of the County, or rest of the State, or a nearby County, that should be my specific option.

2. Specific year exact search should return results for that year. If year-range given, exact search should return items only within that range.

3. Exact search for name should return that name spelling precisely.

Other issues:

A. Why did your first search not return any Levi at all in the top hits? When you start thinking in terms of trying to **trick** New Fuzzy into giving relevant results, you are in trouble.

B. I completely agree with others that searches for city-dwellers are fairly trivial, relative to where most folks resided historically. I will typically search for people living in Towns, Townships, etc., but more significantly within a County.

C. The ‘type-ahead’ feature does not include Magisterial Districts, Townships, Hundreds, Beats, etc., and seems oriented to urban centers.

D. The ‘type-ahead’ feature confuses locations, such as where a township in one County has the same name as a town in another. It might find Beloit, Mahoning County, Ohio, but not Beloit Twp., Mitchell County, Kansas. Bowling Green, Kentucky, but not Bowling Green Twp., in either Licking County or Marion County, Ohio. Related to this is the single place-field that incorporates the very flawed gedcom format that does not specify when a place-name word is a County, rather than one of three villages by the same name in the same State. Your type-ahead feature continues this fundamental error in the gedcom core program. This problem is immensely complicated when searching in England in the 18th and 19th centuries, with all the changes in civil and Parish designation systems in vital records and Census enumerations.

I tried to duplicate your results in the New Fuzzy global search page and got *no* results until I made the 1910 death date not exact. Then the result was 48 hits for the 1880 US Census and a few trivial Tree entries. Hunh? No 1900 census entry whatever.

When I got the “no results” screen, intially the display helpfully had the search box below the “no results” box. That was nice, though it did not show the “lived in” field, but it quickly redirected to the display with the side box showing search parameters. Maybe I was not supposed to see the helpful format, but I am on dial-up so the redirect was slow. I recommend retaining this feature.

The ‘r’ hot-key did not work for me at all. There was a period where my computer was trying to load something but then the display reverted to the compressed side box. The back-space key, on the other hand, worked well to return to the full-size search page.

The first thing I would add is a middle name optional field. If you search “Levi S” you will get any ‘S’. I usually just drop the middle initial to get better results.

The locations should be able include and exclude by category. USA includes Illinois includes Cook County includes Chicago. This would make it easier to use and understand.

But my biggest issue is with the wildcards. You guys have to figure out a way to get over the hurdle of three letters before a * is used. In your example, the best way to search would be for first name, exact, L*, last name exact Baker. This would include all the L, Levi, Levy, Lou and Louis and anyone else starting with an L out there.

I did notice that some things have been tightened up. Over the last week I kept getting 1000+ hits in some Minnesota mining database that I don’t see now.

One last thought. The old and new searches do NOT return the same results, which is a huge problem. Here’s an example: Search for an exact match for Margaret McElrath and take a look at ‘Newspapers & Periodicals’. New search returns 9 results. Old search returns 10. The one missing in the new search is “Historical Newspapers, Birth, Marriage, & Death Announcements, 1851-2003″ which has an obituary from The Atlanta Constitution. The exact record I was looking for! Had I not gotten completely frustrated with the new search I would never have found this. I think more continuity testing is in order and a lot of ’stare and compare’ on behalf of your QA team.

All in all, I do prefer the new search. I can’t wait for it to get better, though.

I agree that exact should mean exact.

Are the hot keys listed somewhere?

With Anne’s forbearance, I would like to comment on some look and feel issues from her search for Levi S. Baker. Most of these issues have been mentioned before by people more eloquent than me. But now that we are no longer so distracted by the exact by the search bug, maybe it’s time to look at some of them again.

Early in Anne’s search, she entered Chicago, Cook, Illinois, USA into the Lived In (Residence) field of the search box. Omitted from her narrative is the fact that the Lived In (Residence) field isn’t there to be filled in until you click on Tell us more to get better results. And having clicked on Tell us more to get better results, the search box is nearly two screens long. You have to scroll pretty far before you can even click on the red Search button.

I think the Lived In (Residence) field needs to be there all the time without expanding the search box. And the search box itself is not compact enough. It’s full of air and whitespace, and the smallest font is too big.

Having conducted the search, the results box has the first 50 matches, and you can click to see more. But the results box is not compact enough. It’s full of air and whitespace, and the smallest font is too big. I can only see the first 5 matches on my screen. I would like to see many more than that on the screen at the same time. Part of the problem is just the “full of air and whitespace” design. But part of the problem is also that the results box is too narrow in the first place in order to accommodate the Refine Search box at the left side of the screen.

Ann,

Re: your questions in #12:

“what is a Hundreds or a Beats in terms of locations? BTW, I find counties in the typeahead, which counties are we missing that you are looking for? And you can always just type in the location. I still lean towards building specific text boxes or drop downs where you specifically break it into counties and states are whatever. It’s not necessary for a general set of features, but if you are digging deep, you might just need it.”

The Hundred began in early feudal England as sort of a taxation district – I’ll let you look it up in wikipedia or whatever, it is more complicated than that. In 17th century Delaware, Maryland and Virginia as Counties were established they were divided into Hundreds. The Hundreds were roughly equivalent to Penna. Townships, although with negligible governmental functions. Practically they were treated as assessment and Court jurisdictional districts, for which assessors and such functionaries as Justices were appointed. To varying degrees they were also convenient divisions for road creation and maintenance, and subsequently were Census enumeration subdivisions. Virginia abandoned them before MD, which in the mid 19th century switched to Election Districts as civil divisions. Delaware retains the Hundred subdivisions.

In England the Hundreds persisted as County subdivisions until the mid-19th-century.

In some States the Beat was also a Court jurisdictional subdivision. You are probably familiar with a police patrolman’s ‘beat’, which has very similar meaning. In these States many of the Beats were also used by the Census as enumeration subdivisions in the 19th century, but in Georgia, Mississippi, Alabama and Texas you can find both Beats (e.g., ‘Beat 12′) and named Townships in the enumerations, varying by time and place.

Yes, County names are listed in the type-ahead lists but not identified **as** County with the word ‘County’ or abbreviation ‘Co.’

Example: what does ‘Burlington, Burlington, New Jersey USA’ mean? Is the first ‘Burlington’ the city or the Township? Is it Burlington (city) in Burlington Township? I know your drop-downs disregard townships and boroughs, and that the type-ahead system for the US is based on the aggravating gedcom format. But if I want to search for a person residing in Burlington Township, not restricted to Burlington City, do I have to search just for the whole County without specifying municipality? If I type in ‘Burlington Township, Burlington County, New Jersey’, what will New Fuzzy tell the search engine to do?

There are innumerable parallel instances, such as Mannington (small town) within Mannington Magisterial District (geographically quite large), Marion County, WV. The drop-down gedcom format does not allow specifying a search in the whole District rather than in the little city. Old Search finds hits throughout the District except in the cases where the indexer mistakenly wrote in that an enumeration was in Union Dist. instead of Mannington. The same pattern can be found for the towns in New England Towns by the same name.

Your type-ahead system cannot cope with the towns that are within the Virginia Independent Cities (which are roughly equivalent to Counties), and will mistakenly place them and the Independent Cities within Counties which only coincidentally surround them. A person who just types in ‘Frederick’ or ‘Norfolk’ will have a number of choices that don’t quite correspond to either current geopolitical reality or to the way the Census enumeration districts were titled. Here the well-informed user has to try to read the mind of the programmer who may or may not have understood how fundamental the County and City formations are.

These issues may seem trivial to you, but realize that the prevailing rurality of 19th-century America was accompanied by families that stayed in one area for generations, often naming all their kids the same way in each branch. If one is trying quickly to find XY who lived in Eagle District rather than XY who lived in Sardis District, and certainly not XY who lived in Manitoba or Wales, New Fuzzy is not well suited to the task.

If you want a range of +/-1 on a year then don’t choose exact and select the +/-1 year.

Because, as I explained, knowing the exact date doesn’t translate into an exact search of the records.

Most people assume that what they enter on the search form should be as precise as possible. If they know an exact date, they should not have to fudge and pretend that they don’t (i.e. +/- 1) just because the underlying records don’t actually include the exact year but are based on age — which is inexact.

Anne,

Thanks for the reply. Re your comment that the marketing dept does not drive development, that may be how it seems to you. But since by your president’s own figures the company spends 4-1 on marketing vs. data acquisition, and since a phrase like “new search experience” is straight out of some marketing hype playbook, Then the reality seems otherwise, even if from your vantage point you can’t see the forest.

Now on to the topic at hand . So from your comments here and in other posts I think you are saying the following:

1) Ancestry wants a search that works for members of all experience levels;

2) you understand that one size does not fit all.

So the question is how to implement that, in a manner that addresses your company’s primary goal, i.e. not confusing the inexperienced and making them think there are a ton of records they can check out.

The way I think is for a multi-tiered, as opposed to 2 tiered search function. Basic (few details specified), “Advanced” (more details and some exactness), and “most advanced”, i.e. the way most of us responding here want to see things.

But to let us do what we want to do, means not only having more ability to specify exactness and fuzziness to our specifications, but also your having to implement different code to let us do that while preventing the less experienced from being too exact and not finding anything.

Do you see any way around having two differently coded search functions to achieve the goals here, of letting us do our thing while not letting the inexperienced “misuse” the search function?

If you are going to place the utility (to your company) of only having one set of search code, ahead of what is being discussed here, despite the fact it only involves 2 sets and still gets rid of thousands of individual database search templates, then I think that should be made plain.

“To me exact has always meant exact – so if I choose to check the box that is what I’m asking for – exact matches to the fields I specified.”

That is not at all how I have interpreted the “exact” box. To me, exact means that the information I have entered in that field is known to be exact. If I don’t check the box, it’s an approximation. I expect the search engine to use “exact/inexact” in ranking the hits that meet the entire search string. In the old search, the stars are quite useful — but they are not at all in new search.

I don’t think there is a one-size fits all solution to this. The two perspectives on what “exact” means (i.e. only hits that match that field exactly vs. using it as an anchor for finding information) are equally valid…which is why users should be able to control the search behavior in their profile settings.

Athena – your response #17 is as confusing as your original post at #8, and almost as confusing as it would be to any person using the search.

If we follow the same logic you would need exact radio buttons on all search fields – isn’t that what the exact option is for?

Why not just let the exact option indicate to the search engine that you only want exact searches on that field instead of making it a fuzzy search unless you check the radio button – I know, lets call the radio button the exact option:)

Karen – #19 said ”To me, exact means that the information I have entered in that field is known to be exact. If I don’t check the box, it’s an approximation. I expect the search engine to use ‘exact/inexact’ in ranking the hits that meet the entire search string. In the old search, the stars are quite useful — but they are not at all in new search.”

So does exact mean that, that you know the exact date? I thought it meant that the search would only retrieve records that matched exactly that date. Maybe someone would clarify what the exact option means.

I may be using the wrong site but I don’t see stars on the old search, am I missing something?

TonyC

I think that most of the posters here, who seem to think that they are somehow more advanced/intelligent/experienced than the “average” users, are pretty confused themselves when it comes to this “exact” issue. How can anyone claim that his understanding is the “right” one unless the UI (or help content somewhere) specifically indicates how “exact” terms are used in the searches.

I find it hard to understand why someone who enters an exact birthdate is wrong to expect the search to return hits even if the records for a particular collection only have ages rather than birth year.

What kind of search algorithims are being used that return more and better hits for less precise search terms? In what kind of universe does that make sense? And why would anyone argue that forcing researchers into such convoluted strategies would be a good thing?

OK Karen, now I am seeing stars – on the old search

Being an exact type of person I never used the advanced search, preferring to enter the basic name and location, and then drilling down into the various data sets I was interested in.

Does that make me a Luddite? Oh no!!!

TonyC

In my experience, many records on Ancestry do not include birthdate or year but are instead indexed using a calculated year based on age information. The result is, with the exception of birth, death, and military records, there is really no such thing as an “exact” match to birth year and the probability is greater than 50% that a “this year only” search will omit relevant hits.

I see this all the time with marriage records — the calculated year used for indexing is wrong and people think there’s nothing there. If they go back and do a (+/- 1) search, the license pops up — not because they had the wrong birth year but because the calculated year used in the index is wrong.

I find that unsatisfactory. I don’t think the search program should systematically omit 50% (or more) valid hits for some but not all databases or that researchers should be expected to second guess the indexing by pretending to know less than they do. It seems more reasonable to me that the search engine would default to automatically return those +/-1 hits for data bases that do not actually include the year in the underlying records.

I agree that it should be easy for individuals to override the defaults but it seems illogical to me to default to something that less likely to deliver the desired results.

There’s plenty of discussion here about search arguments and functions — I want to instead focus on and second the comments of Carol (#6) and Jerry (#15) to make sure you don’t overlook the fact that the delivery of the results by the New search is far less user-friendly than the Old search!

One can scan the Old search results quite easily with its one-record/one-line on the screen approach. The New search stacks the fields into multiple lines for each result — much more difficult for the eye to scan and way too much wasted white space. The Old search presents many more results per page and in a format much easier for the mind to compare and comprehend.

Keep ancestry.com fun and pleasant to use — keep the Old search results one-line per record display!

I believe “exact is exact”. For DATES: If date is checked “exact” then I only want to see records with that exact date. If I want a “range” of dates, then I can use the +/- function on my own

For NAME: same thing – a search for “Levi” should only result in “Levis”. If Ancestry would just provide a basic wildcard function that doesn’t require 3 previous characters we can do “inexact” searches in our own way and allow for the infamous middle initial stafus.

For PLACE: the old search method was far preferable – having the town, county and state as separate fields solves the problem. Generally the reason we’re searching the census is because we don’t know where the ancestor lived. It’s most rare that I know the COUNTY they lived in, let alone the city! When searching in unfamiliar areas it’s unclear in the type-ahead list whether “Montgomery, Indiana” is the town or the county. I find the new “type ahead” list VERY confusing – although I admit to not having used it after my first miserable attempt to find records that I already knew existed. After doing a search and typing “Montgomery County Indiana”in the place field, I got no results. The old search brought them up just fine. How about adding “Chicago, Cook COUNTY, Illinois” to the list? It would be much less nebulous.

Just my two cents worth – as a very long time subscriber and frequent census searcher (although definitely “weekender” (darn day job is killing me!)

Anne,

As a UK resident I am becoming increasingly disturbed that the new search is being tilted towards the needs of US researchers to the detriment of users in other countries. I fully understand that the US is the biggest market but how about thinking about the needs of users in Europe, Australia, etc.

For example the discussion on ‘Exact’ and Counties. In the UK a county could be considered the equivilent of a US State. It is the next political division down from the country. How do Ancestry propose to incorporate this into the search?

Why does the type-ahead persist in adding the superfluous United Kingdom after England, Northern Ireland, Scotland and Wales when the County is missing? This is the equivilent of getting Washington, United States, North America when you type in Washington.

I agree with all those who say that Exact should mean Exact. Like your US users I don’t want results from the wrong side of the pond just because so many US towns and counties were named after European ones.

Like many others I have tried the new search and found it hard work. I have forced myself to use it to search, but so far I have alway had to return to the old search to find what I want.

Oh and that is another problem that may not be apparent to users of the .COM site. I use Ancestry.co.uk, when I try the new search and can’t progress and switch back to the old search half the time I’m dumped into Ancestry.com! Also I’m not returned to my tree but to the Home page, all very frustrating.

” believe “exact is exact”. For DATES: If date is checked “exact” then I only want to see records with that exact date. If I want a “range” of dates, then I can use the +/- function on my own”

How do you get an exact match to something that is not in the record to begin with? There is no date in most of the records I’ve see, what search is working with is made up, it’s a calculated year derived from age and it is incorrect as often as it is correct.

That’s most clearly shown when dealing wth the 1900 US census where the birth year in the the index is frequently different from the actual date on the census schedule — because the indexing isn’t based on the birth year in the record but is calculated based on age.

Anyone who thinks that searching for an exact match on birth year is generating a list of accurate matches of records pertaining to individuals born in that year is deluding him/herself. It’s misleading and confusing to imply that an “exact” search in this context is but an approximation.

Users shouldn’t have to second guess the system that way. If there is no date in the underlying records, nothing can be an exact match and a narrow range of records should be returned by default

I don’t believe anyone is trying to second guess the system but I do believe that “exact” means exact:

“1. Precisely agreeing with a standard, a fact, or the truth; perfectly conforming; neither exceeding nor falling short in any respect; true; correct; precise; as, the clock keeps exact time; he paid the exact debt; an exact copy of a letter; exact accounts.
[1913 Webster]”

We know that the age can be off, whether by calculation, bad transcription or an individual either not knowing or lying about their age. True the calculation of age is often wrong in the indexes but the others described above would not be listed in an “exact of +/-1 year”.

Personally I still use the old search with just first and last names and location. I don’t specify year or age until I drill down to the record sets I’m interested in, even then I never use an exact age for the reasons stated above, but to change the meaning of the word ”exact” is where I object – it would be confusing – what would it be – nearly exact?

TonyC

But you are second guessing the search engine. You have become so accustomed to it that you don’t even realize that is what you are doing.

This is not an issue of data quality (transcription, false responses, etc.) and search strategy. I am talking about a known inaccuracy that applies to the majority of the records in the majority of the databases I work with: the information in the record is correct but the record cannot be found by using the “exact” date.

The search tips say “you will only receive matches that exactly match all of the search terms you enter” — which is grossly misleading and confusing because the search engine is not actually working with the data in the record. Using the word “exact” (per your quoted definition) in this context is irrelevant and confusing.

In this case, the “purists” are in fact promoting inexactitude. I don’t have a problem with being able to force “this year only” searches. I strongly (obviously) believe though, that global searches of databases in which the records do not include an actual date should default to +/-1.

As has been noted elsewhere, this is another argument for a functional user profile that controls more than just page display.

I agree with Roger from the UK…put some more “return to tree”, “return to last person or search” (or something to that effect), “return to last tree”-(if I was searching someone’s tree for comparing and attaching info from that tree. The plain “return” button I see every so often is useles because it does the same as the “back button” at the top of the browser. Just more “return to previous places I had just been”…previously, ya know . Ya just get lost when you’re searching someones tree or historical records and you want to go back and you have to hit “home” and start over.
As far as the discussion, goes I’m just listening in because everything that’s said is what I’m frustrated about. I’m all for “exact” is exact. That means every exact (to the letter) is posted first (from every category) and then less exact from there on.
And I want to mention again, how about dividing “marriage and divorce” and more importantly, alphetize the records when I click a specific category and sort by “category”.
Thanx
Mark B. (I noticed another Mark so I’m Mark B. now.)

A last word from me about what exact means and then I’ll hand it back to Athena who wants to redefine what exact really means – exactly.

Athena – so what you want is an inexact +/- year search on all records.

But then you want a button to force the search to really treat it as exact – but isn’t that what it was intended to do? Why not just choose +/- x-years instead to perform a fuzzy search on the date?

You seem to be saying that transcription errors, false responses etc. are unknown inaccuracies – really? Try the 1841 UK census where ages are sometime reported as actual and sometime in the age bands required by the census, i.e. a person age 27 should be in the 25-30 age band so should be recorded as 25, obviously from some of the records the census takes either didn’t read the rules or didn’t follow them.

I have ancestors, as I’m certain many others have, that seemed to age less than the 10 years between census records. Recently I found, quite by accident an ancestor who is clearly age 5 on the record but transcribed as 3.

Now what is going to happen to the UK BMD records if I have to live with a +/- year and I am certain of the year but not the quarter, especially with common names? Oh, I forgot there’s to be a radio button to make it exactly exact.

I’m done with this particular sub-topic, if we need to redefine the word and the majority agree that exact doesn’t really mean exact then I will live with it – but please don’t forget the exactness button.

TonyC

Athena – so what you want is an inexact +/- year search on all records.

No I do not and I never proposed any such thing. What I have repeatedly said is that if it there is nothing in the actual record that can match (because the data was not collected that way), date matches should default to +/-1. If the records do include an actual date (e.g. birth, death, or military) then of course “exact” should be “this year only”.

“You seem to be saying that transcription errors, false responses etc. are unknown inaccuracies…”

Umm no, I specifically said that the quality of the underlying data has nothing whatsoever to do with this problem. The known issue I am discussing here is that if you are using an “exact” date search to find records in a database that does not include an explicit date field , you are by definition eliminating individuals that meet your “exact” criteria.

The index used for searching is not the data. There is no such thing as an “exact match” to an approximated value. You are relying on fuzzy fields and calling them “exact” when they are not. Using +/- 1 for those fields that are calculated would in fact return much more accurate results for all concerned.

Dave (#18) –

“Re your comment that the marketing dept does not drive development, that may be how it seems to you.”

It may not, in fact, be marketing that is driving this thing, but it is surely someone* in a position of power who is pushing it. I’ve worked in far too many large organizations not to recognize the symptoms. The usual attitude is “I like this. Go out and sell it to the users. I am your boss. Fear me.” I’ve quit good-paying jobs over this attitude.

Anne may be as she presents herself here, or she could be a well-paid shill. I don’t know how to ascertain the truth of it. If she truly believes this “new search experience” is a Good Thing, she will obviously try to prove it to us. If she’s a shill, this is all in vain anyway.

If there were not someone in the food chain pushing this as a pet project, surely someone else, with slightly less fear-factor attached, would look to the Coca Cola company, realize that the negative vibes are slow death, kill this thing and spend the next couple of months assuring current users that Old Search is really Classic Coke.

I lean to classing Anne as a True Believer. But the examples she’s presented are so slanted (I know everything about this person, I just need to find the record, all it takes is 34 clicks and twenty-three modifications to my entries — pity the fool with dial-up access, but, hey, that’s so twentieth century) as to be laughable. This is not “research”; this is “look up an existing record.”

There’s this fellow I’m looking for: I know when and where he was born, when and where he died, where he lived, the names of his mother and father and wife, when and where he served in the military, the names of his children and some other stuff.

I enter all this in the “tell us more” search form (scrolling up and down, of course).

Ancestry returns exactly zero matches (or, using Athena’s definition of exact, Ancestry returns -1 to +1 matches; it averages to zero, though . Removing the “exact” requirement from the search, I get nearly 50,000 hits. I don’t have time to page through them and my Internet Service Provider would probably cap my service if I tried.

Since the guy I’m looking for is my father, I know that Ancestry’s New Search is wrong.

Do I seem bitter? Sorry; I meant to seem frustrated.

I’m not sure if I should chime in on this “exact” debate again or not, but I guess I will.

Let’s first assume that we have a record that gives a precise birth date. WWI draft cards are examples of such records. Suppose we have John Doe whose WWI draft card says he was born on 17 Apr 1887.

I think most people who are posting, maybe not 100% but most, would say that an exact search for John Doe born in the year 1887 should match and that no other year should match – not even 1886 or 1888. And never mind that the draft card might be wrong. John might really have been born in 1886 or 1885 or 1889 or something. If his card says 1887 and you search exactly for 1886 or exactly for 1888, it shouldn’t match.

If you want to take into account the fact that the card itself might be wrong, then you should specify the +/- form yourself. For example, I think 100% of the people who are posting would say that an exact search on a range that included 1887 should match. Examples that should match include 1887+/-1, 1886+/1, 1897+/-10, etc.

The area of contention seems to be when the record doesn’t have a birth date, but rather has an age. Let’s say we have a 1880 census record for a William Doe who was age was 12. What does that mean exactly? It means exactly that William was born either in 1867 or 1868. That’s because William’s birthday could have been before or after the official census enumeration date. Now obviously William might really have been born in 1869 or 1870 or 1866 or 1865 etc. because the census might be wrong about his age of 12. But an age of 12 in the 1880 is asserting exactly that William was born either in 1867 or 1868, notwithstanding the fact that the assertion may not be correct.

Given that, should a search for exactly 1867 find William? Yes. Should a search for exactly 1868 find William? Yes. Should a search for exactly 1866 find William? No. Should a search for exactly 1869 find William? No. Should a search for 1869+/-1 find William? Yes, because 1869+/-1 includes 1868. Should a search for 1866+/-1 find William? Yes, because 1866+/-1 includes 1867 and age 12 in 1880 includes 1867.

Every example I have given above is exact and is either 100% true or 0% true. Hence, every example I have given above is from classical logic. The notion of fuzzy arises primarily from the theory of fuzzy logic (and fuzzy sets).

In classical logic, statements are 100% true or they are 0% true (i.e, false). Two objects are 100% equal or they are 0% equal. In fuzzy logic, a statement can be 93% true or 37% true, etc. Two objects can be 26% equal or 92% equal, etc.

Hence, a search for 1866+/-1 or any other +/- form is exact, but a fuzzy search for 1866 is not exact but rather is ranked according to the percentage of the match. ancestry uses a 5 star system rather than a percentage system to rank fuzzy matches, but it means exactly the same thing.

I will end by noting that age 12 in 1880 gives a birth date range of 1867 through 1868, and the 1867 through 1868 range cannot be specified as 1867+/-1 nor as 1868+/-1. If we want ancestry to do exact matches against a small range automatically, we should not ask them to match against a year +/-1. We should ask them to match against the years that are actually implied by the data in the record. I could certainly live with that as a compromise. And I could even argue that it’s not a compromise. It’s really the most nearly correct way it could be done.

This question was part of what I raised in the previous discussion, so as I read it I began to see how the term “exact” is being used. For what it is worth I use the old serach engine and rarely put in an exact date, I put in a date and usually mark +2 or minus 2.
But more to the wording that Anne uses here. She obviously knows something about doing genealogical searches, and I applaud her efforts to use that knowledge in this venue, but (yes there is a but) my question really lies at “tricking the search engine.” Anymore my patience level usually runs out at about 2-3 pages using the old search engine. Efforts for me to figure out what I should or should not check as exact an seeing repeated results of even 750 would frustruate me. Please I need a way to search that does not require me to guess 10 or 15 times as to what box to mark exact.
Now as to the geographical question no way no how given now towns and villages in many parts of the eastern US are named can we do without a seperate county designation. New York is another wonderful example of how bad it could get, do you want the village of Horseheads or the town of Horseheads in Chemung County, New York?
I have been doing genealogy for almost 20 years, and it is one of my major sources of inquiry and entertainement so please, please do not continue to make data acquistion secondary to marketing. I have participated in many questionaries from ancestry and consistantly expressed the desire for it to expand its data bases.
I noticed that today on the main page that the box that is suppose to show what new databases have been added is not being kept up to date at least as of about an hour ago.

1. Places: If I search for Chicago, it should return just Chicago. If I wanted Cook Co, I would search for Cook Co. As others have pointed out, having a single text box for location invites confusion between same-named cities, townships, etc. I strongly vote for a dropbox to select a state, and textboxes to optionally specify subdivisions.

2. Dates: 1827 should return just 1827. As others have said, if I want a range I’ll use the +/- option.

3. Searching for “Levi S” should not return Levi. Searching for “Levi” should return “Levi S”. Neither should return “Levy” or “Louis” or “L”. To get variations I should be able to use a wildcard. “Levi S” definitely should not return “Thomas S”.

Regarding whether a specific date should match records which do not contain a date, but rather an age: I am torn. Jerry has a point that an age of 12 on the 1900 census could be a birth year of 1888 or 1887. However, I think I would vote for a hard-nosed precision, and the 12-year-old should be returned only for a search of 1888. If a record does not contain a date at all (e.g.: 1840 census), it should not be returned for any search specifying a date.

I’d like to make one comment about the layout of the results screen.

One of the fundamental principles of interface design is that the things the user does most often should be the easiest to do. It’s okay for less-commonly used functions to require additional keystrokes or clicks. What is done over and over should be as easy as possible.

What is a user most likely to be interested in while viewing a results page? I would say that primarily they want to scan through the list of results. Only after deciding the desired result is not listed would they want to change their search criteria. Thus, a logical layout of the page would be to have the list of results be what is first seen, with the refinement section out of the way.

I would suggest going back to the vertical arrangement of the sections, with the results on top and the “refine search” section below. If the sections must be arranged horizontally, the results section should be on the left, and the refinement section should be on the right. People automatically focus on the left side of the screen first, so that’s where the most important information should appear.

One final note, possibly off-topic. Am I the only one having trouble with the 1900 census? If I specify a residence or birth place, I get 0 hits for any search. For example, just now I searched for John Smith living in AL, and get no matches. But if I search for just John Smith, I get 82,309 matches, with at least the first 10 pages all living in AL. I sent a message to the Help center but have received no response.

Ken

I can see programmers screaming at the thought of making drop down boxes available to select from! At first it seems attractive but when you start thinking about how to implement it the problems begin.

Yes a drop down box with all the States might be good for anyone searching for US relatives but useless to the rest of the world. You would have to start with a Country selection and then Branch to individual lists for each Country. This would enable all users to search all Countries. Not too long a list (about 195).

So where do you go to at the next level? US – States; UK – Counties; Australia – States; Switzeland – Cantons: Russia – ??? etc., etc. Still manageable lists.

Now down another level and it start to get harder – US is it counties or towns? UK is Metropolitan Boroughs or Cities or Towns?

Fixing the order and compileing the lists would be a huge task. And how would you cope with places that have changed name, moved county, or even no longer exist. For example the Town of Bournmouth in the UK has moved between the Counties of Hampshire and Dorset.

This is a perfect example of what I worry about, makeing the search suit the US and ignore the rest.

One other small point on the Date arguement. The first UK census, 1841, record the age of all over the age of 20 rounded down to the nearest 5. A person aged 44 whould be recorded as 40 but a person aged 19 would be recorded as 19. What should an ‘exact’ search return? I really don’t know how Ancestry how to handle this.

To Tony Cousin is your EXACT birth name ANTHONY COUSINS?

Hi Robert, actually it isn’t EXACT you have the first name right but I do have a middle name too so I guess in the true spirit of this thread I have to say no – that isn’t exactly correct

TonyC (AKA Anthony ? Cousins)

I agree with what JERRY said in 34 an exact search for ‘1887′ should only give results for 1887 not any other year UNLESS we the user specified a range using +/- then it should be within the range e.g. 1 year either side or 5 years or what ever we put in.

Now when it comes to location that’s another area which needs rethinking.

its all right when someone is searching an official data base like freebmd or census to have a drop down asking which area e.g.> if I type in Hampshire then the drop down appears asking if I want England or one in USA that I hope and expect the person looking would be able to select the right one so that bit should work.

So once again I done a test

I picked my 2 x ggfather James Westbrook who was born in 1840-1908 in wield Hampshire England and who there fore appears in all census and easy to find as he never left the village during his life time and in fact there is only one James born that year in Hampshire and another reason is that there are not that many with the name Westbrook within Hampshire anyway during the period.

The following is the 1841 ref for him.

Class: HO107; Piece 382; Book: 12; Civil Parish: Wield; County: Hampshire; Enumeration District: 13; Folio: 9; Page: 12; Line: 3; GSU roll: 288790.

So I entered ‘James’, ‘Westbrook’, ‘1840′, ‘Hampshire England united kingdom’ as an exact search. Now in old search this produces just the one hit I expected for each of the census years. But this IS NOT the case in new search a number appears under each census year (1841 – 1901).
I opened the 1841 census and yes James was there at the top but why were the rest! I have shown the result below

*************************************
All 1841 England Census results for James Westbrook
Matches 1–13 of 13 Sorted By Relevance

——————————————————————————–
View Record Name Estimated Birth Year Birthplace RESIDENCE
View Record

James Westbrook abt 1840 Hampshire, England Wield, Hampshire
View Record

George Hestbrook
[George Westbrook] abt 1840 Hampshire, England Preston Candover, Hampshire
View Record

Adelphia Westbrook abt 1840 Hampshire, England Portsmouth Town, Hampshire
View Record

Charlotte Westbrook abt 1840 Hampshire, England Alton, Hampshire
View Record

Edward Westbrook abt 1840 Hampshire, England Fawley, Hampshire
View Record

Elizabeth S T Westbrook abt 1840 Hampshire, England Exbury, Hampshire
View Record

Frances Westbrook abt 1840 Hampshire, England Eling, Hampshire
View Record

Francis Westbrook abt 1840 Hampshire, England Eling, Hampshire
View Record

Harriet Westbrook abt 1840 Hampshire, England Alverstoke, Hampshire
View Record

Martha Westbrook abt 1840 Hampshire, England Itchin Stoke With Abbotston, Hampshire
View Record

Mary Westbrook abt 1840 Hampshire, England Fawley, Hampshire
View Record

Steven Westbrook abt 1840 Hampshire, England Wield, Hampshire
View Record

Wm Westbrook abt 1840 Hampshire, England Southwick, Hampshire

*************************************

AS I ASKED FOR AN EXACT SEARCH ON HIS NAME WHY DID ALL THE OTHER NAMES COME UP

There is a bit of miss programming some where I think

Next I decided to make it more exact

So I REMOVED the location of Hampshire England United Kingdom and put just the village he come from and in the above results from 1841 it does indeed give this in the result that being WIELD. I left his name and year exact and ticked the location of WIELD as exact

THIS TIME the only census records were 1851, 1861, 1891 and 1901 BUT IT DID TURN UP ONLY ONE ENTRY IN EACH MY RELATIVE. Even doing a 10 year search either side of 1840 only yielded the 1881 census as another result the 1841 and 1871 did not appear remember he lived in wield all his life and appears in EVERY census in WIELD.

Next I repeated the wield search using the drop down this time (which incidentally says wield England United Kingdom but it should say wield HAMPSHIRE England United Kingdom) the results were the same the 1841 and the 1871 results were missing

Only goes to prove there are BUGS that need to be sorted if this so called IMPROVED (new) search is continued with

Now continuing with my little rant lets turn away from official records and look at the trees.

Still using James as my goal. In old search I entered the first set of details as above AND HAD 17 PUBLIC AND 9 PRIVATE RECORDS ALL WITH CORRECT DETAILS. now I done the same in new search and I’m pleased to say got the same result except I got one extra in the private trees : a Mary Adelaide Westbrook

Ok people being people when they enter names and details INTO THIER TREES don’t always add in full places. I have come across the country being mist off so next I entered for location just WIELD HAMPSHIRE and WIELD HAMPSHIRE ENGLAND ignoring the drop down completely OF COURSE AS I HEAD OF TO DO THIS I EXPECT THE SAME RESULTS. Well for both I GOT 17 PUBLIC which is right but ONLY 7 PRIVATE considering I only left of the united kingdom I would expect the private to return the 9 records that old search and the previous search with united kingdom still in. now I am off to search with out the wield and united kingdom so the search will be Hampshire England and Hampshire. Well done the Hampshire England gave the 17 and 10 records which is acceptable. But when I put in just Hampshire I GOT NO RESULTS I should have got at least the 17 and 10 result as each of those contained the word HAMPSHIRE. I SHOULD HAVE ALSO GOT POSSIBLE RESULTS FROM ‘new HAMPSHIRE USA’ but I got NOTHING AT ALL. OK now I will search for him again but I will only enter wield under the location. Well this time I got the 17 and 7 result. The last thing I am going to do is search just using England. I got this time the 17 public and 12 private. Below I list the private.

Matches 1–12 of 12 Sorted By Relevance

——————————————————————————–

Member Tree Name

Robush Tree
Personal Member Tree
7 attached records, 7 sources
James Westbrook
Birth: 1840 – Alton, Hampshire

Robertson / Puckett Family Tree
Personal Member Tree
Unsourced
James Westbrook
Birth: 1840 – Wield, Hampshire, England

ouroneworldtree
Personal Member Tree
1 source
James Westbrook
Birth: 1840 – Wield, Hampshire, England
Everest Tuggey Family Tree
Personal Member Tree
Unsourced
James Westbrook
Birth: 1840 – Hampshire, England

ChildsClarke family tree
Personal Member Tree
Unsourced
James Westbrook
Birth: 1840 – Wield, Hampshire, England

Thomas Westbrook
Personal Member Tree
Unsourced
James Westbrook
Birth: 1840 – Wield, Hampshire, England

TRAXLER Family Tree
Personal Member Tree
1 source
James Westbrook
Birth: 1840 – Wield, Hampshire, England

Dennis John Family Tree
Personal Member Tree
Unsourced
James Westbrook
Birth: 1840 – Wield, Hampshire, England

PRUDENCE FAMILY TREE
Personal Member Tree
2 attached records, 2 sources
James Westbrook
Birth: 1840 – Wield, Hampshire, England

Lockyer & Farquhar family tree
Personal Member Tree
Unsourced
James Westbrook
Birth: 1840 – Kent, England

Denise Lockyer family tree
Personal Member Tree
Unsourced
James Westbrook
Birth: 1840 – Kent, England
WestiesRoots
Personal Member Tree
1 source
Mary Adelaide Westbrook
Birth: 1840 – Medstead

Now look at those results above. Marys there again! Notice with her the only place indicated is medstead which is only down the road but it DOES NOT FIT ANY OF MY LOCATION SEARCHES. Needless to say nor does Mary in anyway resemble James. NONE OF THEM HAVE UNITED KINGDOM. TWO DONT HAVE ENGLAND. EVRY ONE EXCEPT THE TWO KENT ONES AND MARYS HAVE HAMPSHIRE. SO WHEN I SEARCH JUST FOR HAMPSHIRE WHY DID I GET NO RESULT I SHOULD HAVE DONE, SHOULD I NOT, AS THE WORD HAMPSHIRE APEARS IN THE LOCATION DETAILS

I hope you all followed that and Anne this is I hope some help to point out the problems I find. One other thing
when someone decides to search for a person I am sure even before they start that they have all ready selected a person to look for, I know I already done so, so why on earth do we have to have that VERY ANOYING CONDECEDING INTRUTION of the drop down over the first name especially please either have it removed completely or let us turn it off it serves no purpose unless it is a difficult or uncommon name how many Zacs would be in a list as apposed to James extra. With 3000 names on my tree there are many James so the drop down is cumbersome and annoying to me by the time I navigate down I could have typed the name I had previously all ready decided to look for! And while checking my details here again I accidently run over one of my James (James drake) and his details were imputed I had to there fore stop and remove it all and start again just goes to show it is intrusive and annoying.

GIVE ME OLD SEARCH ANY DAY

THE ONLY AREA IN OLD SEARCH THAT REALLY NEEDS ATTENTION IS THE TREE LISTING WHICH SHOULD BE ALPHABETICALLY PRESENTED NOT JUMBLED AS IT IS NOW.

just to say

ancestry has been hanging alot to nigt it took abou 2 1/2 hours to do the above. i checked my connection by going to non ancestry / genealogy sites ectra and they were all fine no problems at all on them

From #40 ancestry has been hanging a lot tonight it took about 2 1/2 hours to do the above.

I’ve mentioned the following problem before, but let me elaborate. I’m not sure if it’s the same “hanging” problem described in #40 or not.

I always run my computer with the Windows Task Manager running and minimized. When it’s minimized, its icon appears in one of the “task bar things” down at the far bottom right hand corner of the screen (there are so many of those “things” with icons that I can never remember what Microsoft calls each one of them). If anything hangs or seems slow, I can pop Task Manager open instantly and usually see what’s wrong. Also, even without popping Task Manager open, the icon itself tells me how heavily utilized my CPU is.

Whenever I go to a new screen with New Search, my computer seems to hang for five to ten seconds. It becomes completely non-responsive to both the keyboard and the mouse while it’s “hung”, except that I am able to open Task Manaager. During this time period, the computer is running 100% CPU utilized, and if I pop Task Manager open it says that all the CPU utilization is going to the browser window that’s logged on to ancestry.com. This happens on each of three different computers that I use at different times to access ancestry.com.

My guess is that there is a bug in the scripting code that is being used to render the screens. Java or the Microsoft .net thing or some scripting tool like that must be in use to render the screens. Otherwise, there couldn’t be hot keys, typeahead, and things of that sort.

The problem seems worse than it used to be, but I may not be remembering correctly. Until the exact search bug was fixed, I usually couldn’t stand to use New Search for more than five or ten minutes at a time. Now, I’m trying to use it all the time. So every time I do just about anything that brings up a new screen on ancestry.com, my computer hangs as described for five to ten seconds.

#34: ” If we want ancestry to do exact matches against a small range automatically, we should not ask them to match against a year +/-1. We should ask them to match against the years that are actually implied by the data in the record.”

Agreed. I was afraid that saying that would introduce another layer of confusion but you are right.

“And I could even argue that it’s not a compromise. It’s really the most nearly correct way it could be done.”

Exactly

Athena has got it wrong. Yes it is true that ages can be off or ambiguous. I know that a person born in 1850 age 10 may be born in 1840 or 1839 depending on when is birthday is. But that is the whole point to why we have the +/- option. If I put in a year and say it is exact, and that it is within 0 years, only that year should come up. I may miss some matches, I know, but again, I can deal with that by using the +/- option or unselect exact to broaden it to account for ages being off. Exact means exact.

Never mind. Athena has come around.

Re: Jerry’s #41.

Agree about the code being the hangup. Maybe the problem is that they have not yet put in the ads, which are the reason for the odd page setups for New Fuzzy routines, but some of the preparatory code for the ads has been entered (just awaiting the specific links).

The stylesheet also includes several copies of the search form. It is clumsy javascript.

Re: Joe’s #43 about a person in the 1850 census age 10. Ignoring the typical inaccuracies that are in the census, we don’t know if the person was born in 1839 or 1840. I get the value of specifying +/- and I regularly do so myself. But here’s the problem. Would you expect to search for the person as born 1840+/-1 or as born 1839+/-1? And if you did not use the +/-, would you expect to get a hit on 1839 or on 1840?

There seems to be an unwarranted expectation that 1840 without +/- will get a hit and that 1839 without +/- will not get a hit. Why do we prefer 1840 over 1839 when they are equally likely?

I said I’d give up and go with the majority on this ‘exact’ discussion but Jerry’s post #46 and others prompted me to do a little ‘research’.

It’s been stated that “a person in the 1850 census age 10. Ignoring the typical inaccuracies that are in the census, we don’t know if the person was born in 1839 or 1840. I get the value of specifying +/- and I regularly do so myself. But here’s the problem. Would you expect to search for the person as born 1840+/-1 or as born 1839+/-1? And if you did not use the +/-, would you expect to get a hit on 1839 or on 1840?”

This statement is true as most of the census dates were in June, with pre 1830 taken in August, but what do you do with the 1920 US census taken January 1st? Granted it is the only one to start on the first day of the year and the majority started around mid year (or were scheduled to start then), the 1910 and 1930 census start dates were April 15th and 1st respectively.

So looking at those dates do we have to weight the possibility that pre 1830 it is more likely that the person had already had a birthday and in 1910 and 1930 less likely??? And of course the 1920 census age must be calculated exactly – mustn’t it.

At the risk of boring everyone – there isn’t one size fits all. So why not let exact be exact and use a date range if you want to – but don’t impose the date range on the search engine by default. Just use the US 1920 census as an example for an implied fuzzy search – if someone is 10 in the 1920 census then it is a 99.999999999% chance they were born in 1909.

Apply the fuzzy +/-1 to a birth year of 1909 and you’re going to get a lot of hits that are just not relevant.

Have a great weekend everyone – happy researching – TonyC

I know the following has been mentioned several times before, and it’s not exactly on the topic of Levi S. Baker. Nevertheless, now that the the exact search bug is fixed I’ve been trying to use New Search all the time. Frequently, it still confounds me.

For example, I’m looking for a 1965 marriage between a man named Wright and a woman named Willis. I have their exact marriage date and their full names, but I don’t have their marriage place. I strongly suspect they were married either in Ohio or Tennessee.

It’s probably tilting at windmills to hope that their marriage record is in ancestry somewhere, but what the heck. With the old exact generic search (you have to use the advanced search feature to enter the last name of both spouses), I get 131 hits of which 8 are in Tennessee and 0 are in Ohio. None of the 8 hits are my couple. Oh, well. I specified surname Wright, spouse last Harris, no date, nothing else.

I tried again with new exact generic search. I specified surname Wright, spouse Willis, nothing else. Of course, the spouse field doesn’t break the data down into first name and last name. I get 1,847 hits. Oops!

The main symptom is that the search is finding men named Willis Wright, when in fact Willis is the woman’s surname. I’m not sure that’s the only symptom, but it’s the main one. I think the real underlying problem is the failure to break names into first names and last names.

Correction on #48. I correctly specified spouse last Willis, not spouse last Harris. Sorry for any confusion.

To Jerry’s #46:

I totally get what you are saying: 1839 is just as valid as 1840 as a possible birth year, inaccuracies aside. But I still want exact to be exact, and to use the +/- at my discretion.

Keep in mind that we are dealing with the global search here. We are searching against all of Ancestry, including databases with exact birth dates and databases with estimated birth years. I do not want the default to be to search a range of 3 years on all records, including vitals, military, etc. Even for census, a 3 year range is often too broad. I just want it to search a single year unless I tell it to be broader.

#50: “Keep in mind that we are dealing with the global search here”

Which is why it is important to acknowledge that the current “exact” searches on many databases will not find “exact” matches today.

“I do not want the default to be to search a range of 3 years on all records, including vitals, military, etc.”

As far as I can tell, you are the only person who has even mentioned such an unacceptable arrangement. As Jerry noted, we are all agreed that when the data includes an explicit date field (e.g. millitary, birth, or death records), that should be the criterion.

What has been proposed is that when the record does not actually include a date, the search should return the records that accurately match the desired year and not depend on calculated values that do not.

#47:“So why not let exact be exact and use a date range if you want to “

Why do you insist on referring to the estimated year in the index as “exact”. Why should we settle on only one out of a possible two years as “exact”? As Jerry explained, “Exact” search results do not “exactly” match the data today.

This problem is much, much larger than the US census; it applies to many, if not most, databases on the system. Spend just a few days working with a cohort of individuals born in the last quarter of the year and you can see how bad a problem it is.

Why should users have to to second guess the system to make “exact searches” match exactly? Why can’t they expect to put someone’s “exact” birthdate on the search screen and get records where the data matches that?

If you want to keep things as they are, at the very least the search screen should be changed to stop asking for an “exact” birth date/ year and make it clear that what is going on is an exact match to an estimated/approximate birth year.

Hi Athena – we meet again –

#51 – ” Why do you insist on referring to the estimated year in the index as “exact”. Why should we settle on only one out of a possible two years as “exact”? As Jerry explained, “Exact” search results do not “exactly” match the data today.”

I’m not saying the date in the index is exact, my whole reasoning revolves around the search parameters that a user enters should be presented to the search engine as being exact – so that only records that match exactly, whether calculated or actually in a record are returned – it’s a user choice and not forced on the user.

I don’t have an opinion on the date in the index, I just want the date entered by a user in the search to default to ‘exact’ unless a date range is entered – just like the old advanced search which incidentally carries this text alongside for clarification.

“’Exact matches only’ checkbox
Checking the “Exact matches only” box at the top of the search form checks all of the exact checkboxes on the form. When all of the exact checkboxes are checked, the search will only return results from records that contain information for all the fields where you entered information AND where the information in the record exactly matches what you entered.

‘Exact’ checkboxes
When you uncheck the ‘Exact matches only’ box at the top of the search form, all of the ‘Exact’ checkboxes will be unchecked.
By checking the ‘Exact’ box by an individual field the search will require the result to include and match that item exactly. This will allow you to, for example, require a place to match exactly, but find variations of a last name.”

That seems clear enough.

Athena – you then go on to say – “If you want to keep things as they are, at the very least the search screen should be changed to stop asking for an “exact” birth date/ year and make it clear that what is going on is an exact match to an estimated/approximate birth year.”.

Problem – that only applies to records where the birth date is calculated, all the many birth records have birth dates – exactly, many death records have the birth date – exactly.

Again – one size does not etc. etc.

TonyC

“so that only records that match exactly, whether calculated or actually in a record are returned – it’s a user choice and not forced on the user.”

But the all records that match the “exact” search criterion aren’t being returned…that’s the problem.
“That seems clear enough.

To you perhaps — because you are accustomed to second guessing the engine. It is actually misleading, it implies that if you put an exact birthdate in that field you will get all records that match that year — and you don’t. What you get is only some of the records that match that exact information; the ones that have been indexed that way.

Problem – that only applies to records where the birth date is calculated,…Again – one size does not etc. etc.”

Which is why I have said (in every one of my posts) that search should deal wth the two types of records differently.

Dealing with these age based records properly is not an impossible or even difficult task — there are several programming solutions to it — and Acestry should step up to the problem.

The Collaborative International Dictionary of English v.0.48
exact \exact”\, a. l. exactus precise, accurate, p. p. of
exigere to drive out, to demand, enforce, finish, determine,
measure; ex out + agere to drive; cf. f. exact. see agent,
act.
1. precisely agreeing with a standard, a fact, or the truth;
perfectly conforming; neither exceeding nor falling short
in any respect; true; correct; precise; as, the clock
keeps exact time; he paid the exact debt; an exact copy of
a letter; exact accounts.
1913 webster

i took a great pains to make out the exact truth.
–jowett
thucyd.
1913 webster

2. habitually careful to agree with a standard, a rule, or a
promise; accurate; methodical; punctual; as, a man exact
in observing an appointment; in my doings i was exact. “i
see thou art exact of taste.” –milton.
1913 webster

3. precisely or definitely conceived or stated; strict.
1913 webster

an exact command,
larded with many several sorts of reason. –shak.
1913 webster

when i use exact the results i receive should be exact not approximate
as per the meaning above

if i put in the first name james then i expect to get results with the first name james not mary (see post 40)

if i put the name westbrook i expect westbrook

AND YES IF I PUT IN 1840 I EXPECT RESULTS FROM 1840

IF I PUT IN 1840 +/- 5 THEN I EXPECT RESULTS BETWEEN 1835 AND 1845

IT SHOULD MAKE NO DIFFRENCE WETHER OR NOT THE INFO IN THE DOCUMENT IS deemed correct or just aproxametly CORRECT OR NOT
if the census says he is 10 in 1850 then i expect a simple calculation to be preformed that is
1850 – 10 =1840
it does not matter what date the census was taken using simple maths gives an APROXIMATE YEAR most people when searching are with it enough to work out that if they dont find james in 1840 then it is a simple matter of repeating the search for 1839 or try using the +/- to thier discretion.(it just so happens my james was born a few days after the census and he always rounded his age another reason i chose him)

for a search facility to decide that when someone puts in 1840 that they mean 1839 or 1841 is wrong. just as wrong for the search facility to decide that the name mary is correct for james

ancestry should understand that most who are searching their family history are inteligant enough to work out that if their targeted person is not with in a expected year then they need to look a few years either side and i am sure then they can work out that using +/- just might help!

An interesting characteristic of this thread is that Anne’s original example was a fuzzy search, but her questions and all follow-up discussion concerns exact search. So out of curiosity, I decided to recast Anne’s original search as an exact search to see where that gets us. As a reminder, it was Levi S. Baker, born 1827, died 1910, lived in Chicago, Illinois. As did Anne, I used type-ahead on the Lived In field to search for Chicago, Cook, Illinois, USA.

As expected, the first search yielded no hits. The prime suspect would have to be the death date of 1910, so I removed the death date.

The second search yielded no hits. The prime suspect would have to be the precision of the birth date. So I changed it to 1827+/-5. 1827+/-2 probably would suffice in this case, but let’s leave no doubt that our date range will encompass the records we are looking for.

The third search yielded one hit, namely the 1880 census. This is our guy. What happened to the censuses for 1850, 1860, and 1870 that Anne found with her fuzzy search? The problem in 1850 is that Levi was enumerated as L S Baker. Let’s return to that situation later. The problem in 1860 is that Levi was enumerated in Chicago Ward 9, Cook, Illinois rather than in Chicago, Cook, Illinois. The problem in 1870 is that Levi was enumerated in Chicago Ward 20, Illinois rather than in Chicago, Cook, Illinois. “Chicago” does not match “Chicago Ward 9” or “Chicago Ward 20”. I would suggest that exact search is working correctly and that the problem is user error. A census search (and most searches) should be county based, not city based. So I changed the location to Cook County, Illinois, USA.

The fourth search yielded 10 hits. For example, in the 1870 census there were hits for Levi S. Baker, Lucetta S Baker, and S Baker. S from my search box was matching S from the index, yielding the false positive for Lucetta S Baker and S Baker. So I changed the first name to just Levi rather than being Levi S.

The fifth search yielded 4 hits, and all 4 of them are for our guy. The 4 hits are for the 1860 census, the 1870 census, the 1880 census, and the 1900 census. I think that’s pretty darn good, and there were no false positives. The only thing we are still missing is the 1850 census.

I’m calling this the fifth search, but in all truth if I were setting this up from scratch rather than modifying Anne’s original fuzzy search, what I’m calling the “fifth search” would really be the way I set up for my first search. Anne introduced the birth place of Vermont into her search as soon as it was revealed. Since this would have been my first search, I would only just now become aware of the birth place. So for my second search, I would search exactly for blank first name, last name Baker, born in 1827+/-5, born in Vermont, and living in Cook County, Illinois.

What I would really call the second search yielded 14 hits in the census and 1 in the trees. So there are some false positives in there, but there are hits for our guy for every census from 1850 through 1900. I think that’s pretty darn good. It’s very easy to eyeball the actual hits vs. the false positives, and we are done.

Another strategy for the second search would have been to add the birth place of Vermont as before and to search for first name of L. After all, we already have the four hits where he was enumerated as Levi and we don’t really need to find them again. This is guessing that the missing 1850 census entry listed him by initials rather than by name and it’s giving up on the possibility of getting all the hits with one search.

This alternate strategy for the second search yields just one hit, namely the one we want from the 1850 census. So either way, we find our guy in two searches. Which strategy to use for the second search is somewhat a matter of personal preference. With difficult searches where I’m not finding what I’m looking for, I would try both alternatives for the second search.

All these dictionary quotations about “exact” or “precise” are missing the point: you aren’t getting “exact” matches for most of the records today because the records are not indexed to support it.

Anyone who puts an exact birthdate in the initial search screen should get *all* the records that correspond to that birth data PERIOD. It does no good to tell most people that the exact date they have is not what they should be using to find exact matches and no one should have to fudge with an known date just to get the Ancestry searches to come out right. Whether or not they can get to the data by running multiple searches and working around this problem is irrelevant; they shouldn’t have to do it.

I have not had the time to carefully follow all these threads on New Search, but want to illustrate some major problems with New Search as compared to Old Search, especially since you have clearly stated plans are to eventually eliminate Old Search. (I had been naively hoping you would keep Old Search as an option, so I haven’t spent much time with New Search since my post on a previous thread several weeks ago).

I will use an uncommon name as an example: Solomon Sigafoos. (Though there were at least 2 with the same name who lived at the same time).

Old Search, I put in nothing but the name, leaving Exact blank: I click once on Search, and the first 6 of the 7 results listed I can immediately see are my guy.

New Search, I put in nothing but the name, leaving Exact blank. Result: 10,333 “matches,” none of which can I see immediately. In fact, by scanning the first page of results, I see that all of them are well after his death date.

So, I go back to the search page and put in his death date (not exact) hoping to narrow the results a bit. Well, I guess I did, but 6,515 is not much better. And as before, all of the first results are after his death date.

So, I go back and click exact for death date, thinking I’d at least narrow the results to before 1872. Nope, I get only 11 results, mostly junk, but one of which is his cemetery record (of course, I have to click on Iowa Cemetery records to know for sure, whereas with Old Search it is there immediately to see).

So, with New Search my choice is to click and click and click and click ad infinitum to find the 6 records that are there for him??? Or to settle for the 1 record I found by putting in his death date???

Sorry, I just don’t “get” it…

I’ll issue a challenge: find the above mentioned Solomon Sigafoos in New Search on the 1830 census in Ohio. He is definitely there.

Hint #1: You won’t be able to without clicking through 12 pages of results (there are actually many more pages of results, but he is on the 12th page), because New Search can’t handle slight given name misspellings, doesn’t know that S is often misindexed as L, and can’t easily handle locations at the county and township level (the type ahead feature remains a royal disaster, though at least it doesn’t seem to pop up as quickly as it did a few weeks ago).

Hint #2: Some of these problems are also problems in Old Search, but at least in Old Search I can quickly, easily, and cleanly* limit my search to 1830 Census of Ohio, Holmes Co., Knox Twp. (I did not count the number of clicks, but it was fewer than on New Search and without the distraction of similarly named locations in other states popping up).

*Cleanly, meaning I can see the results quickly without a lot of graphic distraction.

There have been lots of posts regarding the meaning and expectations of “exact” in the new search. I have read them all.

One thing stands out in my own experience with ancestry. No matter how I want to search, if the INDEXING in not accurate, or the transcribed information is “fuzzy,” in any way, I’m just not going to find what I want, without “adjusting” my search.

With a shaky foundation for anything, the above structure will be questionable.

Old search has problems, we all agree, but new search not only has problems, it is awkward, inefficient, and time consuming to use.

The layout is wasting space! It is definitely NOT “green!” It is not neat and tidy.

Lacking a genius IQ, I will still be able to out-think the search. We will never be able to get exactly what we want the first time. We will always have in our minds, facts and knowledge that we don’t input into the search page.

I would rather do this process as easily as I can rather than have to out-think the search engine/interface, in addition to trying to put myself into the place of the person for whom I’m searching.

“Holes” in records will always be a problem. If records are not contiguous, I will miss something and the search will have to begin again from a different point.

Ancestry needs more, complete, accurately indexed records.

Beginners will always have some problems to start until they learn what to look for and how. We all had to begin somewhere, but the way the new search is trying to cater to beginners is not making me happy. I’m not an expert. I will never “know it all.”

to sum up, Tyler in #24 gets to the point:

“Make sure you don’t overlook the fact that the delivery of the results by the New search is far less user-friendly than the Old search!
One can scan the Old search results quite easily with its one-record/one-line on the screen approach. The New search stacks the fields into multiple lines for each result — much more difficult for the eye to scan and way too much wasted white space. The Old search presents many more results per page and in a format much easier for the mind to compare and comprehend.”

Amen!

I’d like to comment on Ken’s entry concerning the layout of the screen on the New Search. The results are the most important things we’re looking for, and as each page comes up, I must move over from the left of the page to the right. This gives me hypnosis after awhile. I won’t comment on the meaning of “exact” as long the results screen tells me ‘exactly’ what I’m looking at.
I find the New Search fairly useful and am using it entirely unless I can’t find what I’m looking for. I too would like to be able to search on a particular field or group of fields, and I’m still seeing a lot of records that look like wildcards in my results. I would consider myself way below the expert level, and since I was away from the computer for several years, still finding my way around using any complex search methods. Since I notice that there is another ‘Marguerite’ on the site, I’ll sign off using Maggie, tho my grandmother would wash out my mouth for me. Maggie

I see now that in my Solomon Sigafoos example, New Search, name only, not exact, the default is 10,308 results “summarized by category.” If I change to “Sorted by relevance,” I get the same initial results as Old Search, but now there are only 8,264???

In this example, I could live with New Search so long as I remember to “sort by relevance,” (which probably should be the default), but I’m mystified as to why I would lose over 2,000 results by merely changing the view?

And why does it say “We didn’t find any strong matches”? There were 7 results that matches exactly what I entered.

Re: Connie #61. Anne can correct me if I’m wrong, but I don’t think the concept of default applies exactly to the “Sorted by relevance” vs. “Summarized by category” question. Rather, New Search seems to remember the way you set it and it seems to leave it that way until you change it.

Well, I suppose the concept of default might apply the very first time you use New Search. But I’ve changed the option back and forth so many times I can no longer remember how it was set the very first time. And I really think you should be able to set the option at the front of the search rather than (or in addition to) at the end of the search. Indeed, when you are setting up a search, the search box should clearly indicate what the current value of the option is so you can easily change it if you want to before you do the search.

On the question of We didn’t find any strong matches, that’s because of a very strange way (or at least it seems strange to me) that New Search calculates the number of stars for a fuzzy search (or for an exact search, for that matter). Actually, the number of stars may be calculated in the search engine rather than in the User Interface, so the strangeness may be in the search engine.

Essentially, an exact match is not necessarily a 5 star match. For example, search just on last name of Smith. All the exact matches will be 1.5 star matches. Then, search on first name John and last name Smith. All the exact matches will be 3 star matches.

So the star calculator, wherever it may be, is adding so many stars for matching on last name, adding so many stars for matching on first name, adding so many stars for matching on birth date, etc. That’s why ancestry keeps saying the more data you enter the better. The search process is hoping you will put in enough data to get the match up to 4 or 5 stars or so.

I think that this way of calculating the stars is exactly backwards, and is probably the chief reason in my experience, at least, that the ranking system produces such counterintuitive and not very useful results.

Rather, every search should start as a 5 star match and there should be deductions for mis-matches. Properly implemented, I don’t think this is a to-MA-to/to-MAH-to situation of adding from 0 stars vs. subtracting from 5 stars. The current additive process appears to add partial stars for each matching item in a linear fashion. I could be wrong because I don’t have access to the computer code that does the calculation. But that’s how it appears to work.

The subtractions or deductions for not matching exactly should work like a distance formula in algebra (square root of the sum of the squares of the differences – horrors!!). It sounds like a complicated calculation, but it’s a very simple concept. It’s like if you are a crow and you are 1 mile north and 1 mile east of where you ought to be, you are not 2 miles from where you ought to be. Since you are a crow, you can fly the diagonal “as a crow flies” and get back where you ought to be in slightly more than 1.4 miles rather than in 2 miles. So the star calculation should start at 5 stars and subtract off the “distance” that your matches are from perfect matches. A perfect match is a distance of 0, so you get 5 stars for a perfect match. And in any case, I really don’t think you can subtract off from 5 or add on to 0 in a linear fashion and get reasonable results, even if the various terms being added or subtracted are given different weights. I think you have to use something like a distance formula to get reasonable results.

Anne,

Thanks for following up “my guy,” Levi S. Baker. I’ve been following the comments since you posted on 8/25, but haven’t had the heart to write another long post on New Search myself till now.

I will give Ancestry *some* credit: New Search is a bit less awful than prior to the most recent fix but, you know, it’s still a mess, and I think the other bloggers here have covered the persistent shortcomings of New Search pretty throughly.

To answer your specific questions re “Exact” searches:

(1) PLACES. Be exact. If I ask for “Chicago,” I should not also get other parts of Cook County (Evanston, Wilmette, etc.). BUT, if I ask for Cook [County], Illinois then my results should include ALL incorporated and unincorporated areas of the county, and that includes the City of Chicago.

Of course, this brings up a problem with the hyper-exact nature of New Search’s “Exact” algorithms and the type-ahead drop-down suggestions. Many “Chicago” sources will not necessarily have “Cook County” as part of the database title so, even though “Chicago” is—and always has been—part of Cook County, there are records that WILL be found if I do an Exact search for “Chicago, Illinois” but WILL NOT be found if I follow the drop-down type-ahead suggestion of “Chicago, Cook, Illinois.” That’s not helpful.

Also, I find I must disagree—for the first time!—with Jerry Bryan. Jerry wrote (#55):

“The problem in 1860 is that Levi was enumerated in Chicago Ward 9, Cook, Illinois rather than in Chicago, Cook, Illinois. The problem in 1870 is that Levi was enumerated in Chicago Ward 20, Illinois rather than in Chicago, Cook, Illinois. “Chicago” does not match “Chicago Ward 9” or “Chicago Ward 20”. I would suggest that exact search is working correctly and that the problem is user error. A census search (and most searches) should be county based, not city based. So I changed the location to Cook County, Illinois, USA.”

I strongly disagree. If I am requesting an Exact search for Chicago, Cook [County], Illinois, USA, I should ABSOLUTELY get Census results for Levi Baker in either “Chicago Ward 9″ or “Chicago Ward 20.” Why? Because the Wards are political/geographical subdivisions within the City of Chicago itself. Levi Baker WAS enumerated (living in “Ward #”) in “Chicago, Cook, Illinois.”

So, an Exact search for “Chicago, Cook, Illinois” should include all Wards of the city (unless I further specify a Ward number, just as an Exact search for a rural county should return ALL the townships in that county (unless, of course, I specify the township).

Of course, the REAL problem here is Ancestry’s famously irregular and inaccurate indexing. Chicago’s Ward numbers should not be part of the municipality name; they should be a separate field or keyword, just as Township #/Range #, or Township Name or rural Beat Number should not automatically be blended with the indexed name of a rural county and/or its cities or towns.

(2) DATES. Valerie (#1) put it best: “1827 should only return results from 1827 or in regard to 1827. Otherwise, I can use the +/- variables.” I don’t care how messed-up the indexing may be or how the date may be an approximation or calculation based on dubious information (sorry, Athena!), I really want the ability to specify a truly Exact year if I desire (whatever my reason may be!).

And by the way, I rather like Old Search’s starting and ending date-categories being labeled “Year Range,” rather than “Birth” and “Death.” Imperfect as Old Search is, it seems to do a much better job at including useful information and excluding off-target databases with these starting and ending Year Ranges. Perhaps us “Exact Searchers” need the ability to specify starting and ending dates for the *records* in addition to (or instead of) exact (or probable) dates of birth and death. As it is, New Search is hopelessly inept at this.

One way or another we need to be able to exclude records be specifying either or both a Terminus Post Quem and Terminus Ante Quem for a PERSON or RECORD (and there *is* a difference!).

(3) NAME. Should be exact, but with improved WILDCARD functions!!! It would be SO helpful if we could search for single variables, including in the first letters of a name. I could have saved hours and hours of searching if I could have made searches like: L?vi Baker, ?evi Baker, L* S* Baker, Levi B*ker, and so on… Enumerators and Indexers are famous for errors like these (and earlier ancestors were pretty flexible about how they spelled their own names anyway). Improved wildcard function—especially within the first three letters— would help a lot.

Also, make the middle name/initial a separate search field. This would give the searcher MUCH more flexibility in both Exact and Not-exact mode.

And, to join the chorus: Once we’ve received search results, make them SORTABLE! By name, date created, location, etc… I suspect I might learn to tolerate using New Search if it had better wildcards and sorting…

Repetitively yours,
—Reed

Jerry, I very much appreciate your explaining the “stars.” You seem to understand, but I don’t think I ever will, so I just look at my results and use my common sense and experience to evaulate what I see. I think I could understand the stars in the sky better. So I guess I still say, “Forget the stars!” My IQ is only 139. I’ll never be a genius. Guess I’ll just have to accept that.

Re: Jerry’s #62 and others concerning the ’star’ rating system.

This system is totally useless for databases that are indexed only as ‘keyword’, such as newspapers and the California Voters’ Lists (or the England/Wales BMD Indexes, which are only around half entered in the SQL database).

If you are looking for Arnold Moore in California, the star ratings give a star for every Arnold Wrongname, Arnold Avenue, etc., and the search engine does not find Arnold Moore at all.

On the other hand, I tried searching again in New Fuzzy for the Daniel Davis posted in the previous incarnation of this thread, and it came up with one of the four relevant results (in the awful Delaware Marriages database) that I know to exist in Ancestry’s holdings. This is at least some progress.

Ya know, when the search says to enter as much as possible, then the search should work in that way. It should take what I entered and use it if it’s relevant or just set it aside if it’s not. Sometimes, the less you enter, the better. If I enter John M Reitz (exact); birth-1929 (not exact), then I get his second marriage to Bertha at the top of the list, but his first marriage to Charlene is #15 on the list. BTW, just one “John M Reitz” (exact) displays first, but not until #15, do I get another “John M Reitz” and that one is spouse-Charlene. If I enter the same info but add spouse-Charlene then I get the same results. First on the list-John M Reitz…no more John M Reitz until #15, which, btw, is his first marriage to Charlene. WHY NOT ALL THE JOHN M REITZ’S FIRST? If I remove the birthdate, then, I get the result I want. If I have to remove the birthdate, then it should be greyed out like some of the other fields are. If I add the birthdate, then ALL the “John M Reitz’s should come first, regardless of whether or not the document shows a birthdate.
Shouldn’t I get the same #1 result (John M Reitz; spouse-Charlene) if I select all categories and not narrow my search to “marriages”?
I don’t know what kind of search engine google uses (I’m not a puter guru) but the advance search in google works just like it’s suppose to.
Still looking for those alphabetized categories.

Mark B

Anne, re: your #67

Your question regarding place-exactitude suggests two sub-issues.

I’ll take the easy one first.

a) Um, not all users have enough search experience to understand how fundamental (in the US and to some extent in England) the County is. Not all users understand how idiotic the gedcom format is that, when displayed in a different format, it omits identification of word ‘X’ as a County, a Town or Township, a city, etc. — this presents the problems described elsewhere.

b) There is a serious problem in ‘exactitude’ when the Search Engine excludes rather than includes in a situation where either the database does does not include a field (such as with birth date, or in the Ward number example given by Jerry B.), or the database includes misspellings for sundry places, or the database even incorrectly identifies States — such as the ‘Ia.’ abbreviation in the 1850 US Census, which nearly always stands for Indiana, not for Iowa. Grrrrr.

c) I have spent thousands of hours editing the place entries in a sizeable Tree database. I have noticed in addition to a) that many persons have not thought out the difference between an event-location and the record-source for the event. For example, some have placed Quaker births or deaths as being ‘in’ such places as Burlington Monthly Meeting, or a death ‘in’ Rouen Cathedral in France (which may have been the burial place). Then there are the English Civil Parishes and the English Parish organization pre-1838, and your drop-down list database could not possibly cope with those.

I think these circumstances, for the sake of user-friendliness, call for eliminating the one-line place thing, particularly if the word ‘Parish’ or phrase ‘Meeting House’ would exclude records for a place that otherwise would match how the database entry has been input.

That is, I strongly suggest returning to the separate fields for country, state, county/shire, location (Twp, Town, village, parish), and not getting bogged down with how the Search Engine would handle where exactly a comma is — which is not where the main problems are concerning places (user understanding, incorrect index input, complex place-name histories embodied in databases).

Anne,

Re your latest (#67)—I completely agree with Jade’s comments (#68) regarding PLACE, especially the desirability of separate search boxes for Country, State, County, City or other locality keywords, etc…

Also, re DATES, you wrote:

“Dates….I generally tend to believe that you should run the one year range around birth year, due to the number of records where birth year is derived from age, because that is the methodology that gives you the best possible set of results. Usually! Of course, if it’s a common name that may or may not be true.”

Well…no. You may believe that, but if you look at the vast majority of these blog posts most commentators do NOT agree that an “Exact” date search on a single year should automatically yield default results of that year (+/-) 1 year.

Now, is using (+/-) 1 year around a given date a good search strategy? Yes, of course! BUT, the USER should be able to define/request any (+/-) date limits. It is **precisely** these HIDDEN variations-on-exactness that make so many New Search results seem so random. Exact is either EXACT or it’s NOT, and the USER should be in control of defining any exceptions or ranges to an specific date.

Finally, regarding PLACE once more, you wrote:

“Does exact mean exact, letter for letter, or take what I’ve typed in (or selected from type ahead ) and then match it at the level that it is stored for that particular data set? So if a particular data set is stores the location as “Cook, County, Illinois, USA”, my “Chicago, Cook County, Illinois, USA” will be matched as the “Cook, County, Illinois, USA” Only matching the records that store “City, County, State, Country” is exact is exact. The second might be a more appropriate definition in our genealogy search universe.”

If I understand your example correctly, that is a very scary level of exactitude, especially given the uneven and often illogical character of the Ancestry database indexes.

To my mind, if Ancestry is going to post a database called, let’s say, “Chicago Voter Registration lists, 1890,” I would (and do) expect that SOMEONE at Ancestry took the time to fill in the missing data fields that indicate that Chicago is part of “Cook County, Illinois, USA,” and thus this database will turn up in one’s search results on any of the following (place) searches:

USA
Illinois, USA
Cook [County], Illinois, USA
Chicago, Cook [County], Illinois USA
Chicago, Illinois
Chicago
etc…

BUT, the (properly indexed) “Chicago Voter Registration lists, 1890″ should NOT show as a result on searches like:

Evanston, Illinois
Evanston, Cook [County], Illinois
etc…

I know that other bloggers disagree, and I see their point. Perhaps the solution lies in an earlier suggestion from one of the previous blog threads. It was suggested (by Tony C.?) that one could choose the **kind** of exactness desired on the search, either (I paraphrase):

(A) “Really Exact,” Search where a search for:

“Chicago, Illinois” will return hits for only that combination of search terms (i.e. “Chicago, Illinois”) and NOT return hits for just “Chicago” or just “Illinois,” or “Chicago, Cook, Illinois,” “Ward 7, Chicago, Cook, Illinois,” etc…

(BTW, this seems to be how New Search responds to the Exact mode. Worse, in New Search, when you try to get around the “Really Exact” mode it seems that the search parameters are completely ignored, resulting in thousands of bogus “hits.”)

In addition to (A), the Really Exact Search, is another kind (my preference), the:

(B) “Exact or Null” Search, where results are returned as in my “Chicago Voter Registration lists, 1890″ example, above. This has many advantages, not least of which is that it produces positive hits on relevant items while ignoring the indexers’ failure to properly identify/fill-in the State/County/Municipality/etc… of the source in the first place.

—Reed

A few comments.

a. On Anne’s #67, I don’t think the place name type ahead is really a type ahead. I think it’s really a kind of drop down. That may seem like a distinction without a difference. But if it were a true type ahead, the full place name that was at the top of the drop down list would be filled into the entry field at all times, and would change dynamically as you typed more characters. You could tab off the place name field at any time without having to stop to select an entry, and the current entry would be selected automatically. However, if the place name entry became a true type ahead as just described, I would like it even less than I now like the current drop down system (grin!).

b. Again on Anne’s #67, I find Anne’s questions about what “exact” means with respect to place names impossible to answer. Therefore, I think the whole New Search scheme of place names is broken beyond repair.

c. Jade’s #68 ended with a summary as follows: I strongly suggest returning to the separate fields for country, state, county/shire, location (Twp, Town, village, parish), and not getting bogged down with how the Search Engine would handle where exactly a comma is Hear, hear!

The root cause of all the New Search problems with place names is not the type ahead per se. The problem is really the fact that place names are treated as one large unstructured field wherein among other things you have to count commas. (Nobody has brought up the horrible ,,,statename convention, or is it ,,statename convention, I can never remember how many commas it is supposed to be. The New Search scheme is almost as bad as that.) If Jade’s suggestion were to be adopted, then all of Anne’s questions in #67 would pretty much answer themselves.

d. New Search sometimes but not always afflicts people’s names with the one large unstructured field problem wherein you cannot always tell a first name from a last name. Jade’s suggestion for separate fields for the different parts of place names applies as well to first names and last names of people.

I agree with the majority here in that exact date searches need to be confined to the year that I specify. It is up to me if i wish to broaden the parameter by using the +/- option. I want to decide on my strategy myself rather than having a compulsory hidden +/- imposed on me by Ancestry. It’s that simple. I have over 40 years experience searching and indexing UK family history records so I think I know a little about the subject.

I believe the best way to resolve the place searching issue is to provide as much flexibility as possible by retaining the Old Search method of separate box fields. Trying to combine all of the placename in one box and make it work properly is a nightmare.

Please may we have separate boxes for first and second forenames. Extending wildcards to include the first three characters on names would be wonderful.

The New Search searching and results interfaces waste acres of space and are not user friendly. I much prefer the Old Search interfaces. Hopefully there will be an opportunity to discuss the specifics in detail in a future blog subject.

I suspect that Anne may not agree with my opinions because the main framework for New Search has possibly already been decided by the powers that be. This blog seems to be about convincing the users that tweaking around the edges will make the majority happy. Not so. These are major issues that we are discussing here. Please listen to and implement the views of the majority who on the whole do know what they are talking about.

I personally will be in a word of hurt if Ancestry continues to maintain its determination to use the “new search.” In particular I am referring to its decision to remove the option of using the state name in one seperate box, and another seperate box for the name of county and a seperate box for the next smallest delinator. I spend considerable time looking for individuals with the last name of Charles, and it is the ability to pick various counties in the various states that I am looking at that allows my searches to become somewhat reasonable.
I would like to suggest that one of the reasons why Ancestry is attempting to convince us to use their new search is that in particular in terms of state names, county names, and smaller regional names that many individuals can not spell the names, such as being able to spell Onondaga in New York State. Another problem that the new system could create is best shown by how it searches for Bernalillo, New Mexico. Many would assume that what I mean here is Albuquerque and several of the small towns in the county of Bernalillo, but what I am actually referring to is the town of Bernalillo which is located in Sandoval County, New Mexico.
I realize that it is impossible to have a one size fits all criteria when indexing even the most basic of records such as the census records, and this is one of the reasons why for most of my searches I do not use exact. I want the ability to pick and choose by the use of seperate boxes where I am looking. This problem is also complicated by the various indexing criteria that Ancestry has used and also by the individuals doing the indexing. I rarely go looking in the newspaper section of ancestry simply because no matter what I have tried I usually end up with results that are more than I can handle. I have the feeling that most of us after about 100 possibilities realize that the search criteria we have put in did not work, and this is particuarily true with the newspaper search. I realize that to go backwards and use some type of a indexing system that seperates state, county, town, etc., with the newspapers would be almost impossible, but is there not some way to change the indexing that is currently being done with new records so that one could find what they wanted without so much frustration?

Anne,

As you fly away to the conference, I thought it might be productive to step back and look at the fundamental concept: Is Ancestry’s New Search an improvement over its predecessor and does it work well?

From time to time you (and other Ancestry representatives) have asserted that New Search is indeed an improvement and will eventually replace Old Search completely. Further, it has been said that Ancestry’s research shows most patrons are pleased with New Search and that it meets their needs better than Old Search.

Since I don’t agree—and I don’t have access to your survey data—I decided to go through some of the relevant blog threads from the last several months and see if there are any trends. Now I admit that this is not a scientific survey, but it does represent an important Ancestry constituency, namely Ancestry.com users who (1) use the product often (2) care about the quality of their genealogical research and (3) take the time and energy to follow the relevant blog threads and post detailed, carefully considered comments.

So here are the results. I give the subject, URL and date of the blog thread, and the total number of readers’ posts. I note the number of responses from Ancestry company representatives (not including any introductory essay or posts). Finally, I made a subjective judgment to qualify the customer/blogger responses to New Search. I didn’t want to spend all of my free time on this, so I used these simple criteria:

•POSITIVE reader responses may have some suggestions about improving New Search, but the general tone is “I like New Search better the Old Search and I get better results.”
•NON-POSITIVE reader responses indicate mild to passionate dislike for New Search and/or focus on problems with New Search that need correcting. May include passing positive remarks.
•MISC. reader responses include blog posts that
(a) discuss the merits of various methods of search but not mention New or Old search specifically or
(b) do not refer to the blog thread topic or that are
(c) too ambiguous to call Positive or Non-positive.

Since May 29, 2008, Ancestry has posted 9 blog threads related to New Search.
•Total readers’ posts: 473
•Total POSITIVE readers’ responses: 12
•Total NON-POSITIVE readers’ responses: 381
•Total MISCELLANEOUS readers’ responses: 64*
•Total Ancestry responses: 23

*re MISC. readers’ responses: a substantial number REALLY didn’t like New Home Page.

Details follow below, FYI.

Statistically yours,
—Reed

P.S. I worked very hard to avoid math and statistics classes in school (and largely succeeded). Please feel free to check the math and tally the original blog responses.
—R.

P. P. S. It seems all my formatting indents and underlinings have disappeared when pasted into this comment box. My apologies if you find the layout difficult to read.
—R.

****************************

“Finding Levi S. Baker…”
Aug. 25–4 Sept. 2008 (open thread)
http://blogs.ancestry.com/ancestry/2008/08/25/finding-levi-s-baker-or-how-to-use-new-search-interface-to-find-him/
Total readers’ posts: 69
Ancestry responses: 4
Positive: 0
Non-positive: 69*
Misc: *some of the 69 posts counted as “non-positive” are not necessarily critical of New Search, and may focus more on the technical/philosophical questions of what an “Exact Search” should represent; they are certainly not “Positive,” however.

“Specific Database Search: Old Search UI vs. New Search UI”
http://blogs.ancestry.com/ancestry/2008/08/18/specific-database-search-old-search-ui-vs-new-search-ui/
Aug 18–Aug 25, 2008
Total readers’ posts: 77
Ancestry responses: 9
Positive: 1
Non-positive: 60
Misc.: 7

“The New Search Interface”
http://blogs.ancestry.com/ancestry/2008/08/04/the-new-search-interface/
Aug 4–Aug. 25, 2008
Total readers’ posts: 78
Ancestry responses: 5
Positive: 0
Non-positive: 67
Misc.: 11

“Let’s Talk About Search!”
http://blogs.ancestry.com/ancestry/2008/08/01/lets-talk-about-search/
Aug. 1–Aug. 6, 2008
Total readers’ posts: 47
Ancestry responses: 2
Positive: 2
Non-positive: 40
Misc.: 5

“Announcing New Search Webinar”
Jul. 18–Aug. 2, 2008
http://blogs.ancestry.com/ancestry/2008/07/18/announcing-new-search-webinar/
Total readers’ posts: 46
Ancestry responses: 0
Positive: 2
Non-positive: 32
Misc.: 12

“Continuing the Dialogue about the New Search Experience”
http://blogs.ancestry.com/ancestry/2008/07/11/continuing-the-dialogue-about-the-new-search-experience/
July 11-Aug. 9, 2008
Total readers’ posts: 59
Ancestry responses: 0
Positive: 4
Non-positive: 39
Misc.: 11

“The Ancestry Insider Discusses New Search”
http://blogs.ancestry.com/ancestry/2008/07/08/the-ancestry-insider-discusses-the-new-search/
Jul. 8–25, 2008
Total readers’ posts: 12
Ancestry responses: 0
Positive: 1
Non-positive: 10
Misc.: 1

“More on Ancestry.com’s New Search”
http://blogs.ancestry.com/ancestry/page/4/
Jun. 29-Aug. 2, 2008
Total readers’ posts: 48
Ancestry responses: 3
Positive: 2
Non-positive: 30
Misc.: 14 (including many complaints about New Home Page)

“New Search is Available for Everyone”
http://blogs.ancestry.com/ancestry/2008/05/29/new-search-is-available-for-everyone/
May 29–Jun. 30, 2008
Total readers’ posts: 37
Ancestry responses: 0
Positive: 0
Non-positive: 34
Misc.: 3

Reed, with all due respect you your statistical analysis. I think you will find that most of the negative responses are from the same group of people. Elminate the duplicates.

Even so, I am sure the negatives will outweigh the positive comments. This should not be surprising as positive comments are quickly met with replies that imply the poster is an amateur, or doesn’t care for accuracy, or is only interested in someone elses trees.

It is clear that some people have an irrational hatred of Ancestry and dislike/distrust any and all attempts at product improvement. I am talking about posters who post in all caps, call for people to be fired, continue to post here even though they say they have long cancelled their subscription or insist that management/marketing has some evil intent.

I, for one, do not have the time or inclination to debate such people.

I use the new search almost every day and get good results. From time to time, I switch back to the old search to see what was so great about it, but I fail to see the magic.

Could the new search be better? Of course and I say ‘Bravo’ to those posters here who have offered constructive feedback. It seems to me that Anne is making a serious effort to listen and make things right and I thank her for that.

Jim,

Thanks for your #76 (above). You won’t be surprised to find I don’t agree with much of it. You took the time to comment in detail, let me respond to each of your points in turn (I’m sorry I can’t use italics to differentiate your comments from my replies; quotation marks will have to do):

“…I think you will find that most of the negative responses are from the same group of people. Elminate the duplicates.”

I think that is actually not a good idea. Many of the “duplicate” negative responses are from people like Jerry B., Tony C., Jane, Athena, myself and others who took the time to answer—in detail—questions and assertions made by Ancestry in the posts.

“…I am sure the negatives will outweigh the positive comments. This should not be surprising as positive comments are quickly met with replies that imply the poster is an amateur, or doesn’t care for accuracy, or is only interested in someone elses trees.”

I don’t agree with your cause-and-effect. We agree that in any case, the negative responses outweigh the positive responses. In fact there were only 12 unambiguously positive responses in the *entire* 3-month period and several blog threads had zero positive responses. Were the positive responses met with harsh replies? Yes, on a few occasions. (And the replies focused on Trees were confined to posts a while ago.) However, most replies queried HOW the positive-responders managed to get good/better results with the New Search, and for many of us these questions remain unanswered.

“…It is clear that some people have an irrational hatred of Ancestry and dislike/distrust any and all attempts at product improvement.…I, for one, do not have the time or inclination to debate such people.”

On the contrary, I think that many of us have a passionate interest in genealogical research and high-quality technology (and also pay substantial amounts of money to Ancestry to assist us with both). Because of that we have a very RATIONAL dislike of prematurely released software upgrades that don’t work as advertised, like New Search and New Home Page and so on. (Not to mention databases with shoddy indexing that remain unimproved even after years of complaints, queries and suggestions.)

Further, many of us have direct, ongoing personal experience with Ancestry’s “culture of non-responsiveness,” including push-type “surveys” that are designed to promote new products, “customer service” forms that never produce solutions (or replies!) to problems, etc. I will—once again—tip my hat to Anne Mitchell. Compared to other Ancestry bloggers (are your reading, Kendall Hulett?) and Ancestry “customer service” reps, Anne has (1) responded to a number of blog questions and observations and (2) gives the impression that she may be willing and able to effect improvements. For that I give her due credit.

“I use the new search almost every day and get good results. From time to time, I switch back to the old search to see what was so great about it, but I fail to see the magic.”

Of course, this is the crux of the matter. I ask you, in all seriousness—as a fellow researcher and potential colleague & friendly acquaintance—How do you do it?

Rather than lengthen this post any more, I ask you to go to the earlier blog threads, including “Specific Database Search: Old Search UI vs New Search UI” and try the search I outlined there in comment #27. The URL is http://blogs.ancestry.com/ancestry/2008/08/18/specific-database-search-old-search-ui-vs-new-search-ui/

Can you get New Search to produce better hits? How? I would love to know.

Finally, you closed by saying: “Could the new search be better? Of course and I say ‘Bravo’ to those posters here who have offered constructive feedback. It seems to me that Anne is making a serious effort to listen and make things right and I thank her for that.”

Agreed.

—Reed

Reed,

Thank you for your reasoned response.

I tried your example. My method was to enter Levi and Baker in the Name Fields with Exact checked. I entered 1820 as a birthdate (not Exact) and Lived In Illinois, USA (Exact). I searched applying the Census and Voter List Filter with the results Summarized by Category.

There were 49 hits. I believe that the target was the first found in the 1860, 1870, 1880 and 1900 census.

I tried the same with the old search. I used the advanced option and entered the same info. Under residence, I entered USA then Illinois (Exact). There were good results at the top of the list.

Now here is where I have a problem with the old search: Suppose I want to examine other candidates in a particular census year. I filter to that year. Good. But if I want to refine my search, I find that the search box only kept the name. All of the other criteria is empty. I may have goofed, but the first time I tried to refine my search, I could only get the non-advanced box. Another time, I could only enter the country. It would not expand to the state/local level. I also dislike the (refine) search box at the bottom of the page. I prefer to see my search criteria along side the results.

Anyway, to me, the new search interface behaves more consistently than the old search and that is why I prefer to use it. For whatever reason, I do get results and would be surprised if I am missing any records by not using the old search.

To Anne Mitchell let’s do a search using the old search
1900 census
exact matches only
first name JOHN
last name leave this blank
state INDIAN TERRITORY
county leave this blank
township leave this blank
birth place GEORGIA
birth year 1858 + _ 10 years

how many matches do you think we would find? over 100, over 1000, over 2000?

No none of the above

Your Search for John returned no matches
You searched for John born in Georgia

now take out the birth year and click search
We now have 477 JOHN’S and NOT one of them listed has a birth date index why?
So is the problem in the search engine or is it in the index of this database

Now do the same search using the NEW search 1900 census, first with the birth year, and then with out the birth year And you tell me what you get

Your Search for John returned zero good matches both ways
can you explain why this is so?

And let me tell you if the OLD SEARCH is turn off, I will leave Ancestry.com and delete my family tree with over 20,812 people and 53,310 records attached I pay by the month

Living in the UK, I have only just found this site, as it does not appear on ancestry.co.uk.
I may be too late, but I have always found the old search generally serves my needs, and I find the new one confusing, particularly in the number of results generated.
The single most important improvement I would like to see is the ability to use wildcards in the firat three letters: I have surnames like SECKER [frequently mistranscribed LECKER, LECHER, TECKER, TUCKER, or worse]
and HENLEY [HANLY, HUNLEY, FLENLEY, &c]
Even the ability to search on any three consecutive letters + wildcards would be an improvement.

I may add that I very rarely use a search across all databases, usuallay begin with what are called “a collection”, e.g. “UK census collection”.

I heartily endorse the comments about exact search options in DanB’s post No.50 on the now closed thread “Specific Database Search: Old search UI vs New Search UI”

On a completely different topic, may I ask how making available a facility to correct errors on the censuses [other than names] is progressing?

Regards
John UK

Let me respond as best I can to some of the original questions (it will duplicate what has already been said by others, but …)

DATE: Exact should mean exact. If I want to give myself a +1, +2 of whatever leeway, I should be the one to control that.

PLACE: I haven’t followed the details closely enough to really understand what is going on in New Search, but the templates from Old Search work just fine, i.e. the drop down menus: I choose the census year I want to search, then I choose the state (if I want to) then I can enter a county name, and/or a township name. I realize all databases don’t lend themselves to this kind of drop down menu, so why not give the user the option to specify “both” or “or” type conditions if they type in Chicago and Cook.

At a minimum, we need to be able to select a certain level of location specificity (e.g. state level in US) so that if I’ve specified Illinois, I shouldn’t get anything named Chicago or Cook from another state or country.

NAMES: In an ideal world, Ancestry would spend some $$$ figuring out how to make sure that people searching for Fanny Taylor also find Fannie Taylor (or Solomon Sigafoos and Soloman Sigafoos). (Family Search has had this technology for years). I don’t always remember to type Sol* or Fan*. Though I do echo the need to spend time/effort/$$$ on improving the wildcard functionality for names.

And it would be really helpful to me to understand WHY New Search is considered such an improvement that Old Search will eventually be dropped. (Even if you solve the search problems, the visual effect is not pleasing: New Search is cluttered and not “cleanly” laid out). If there has ever been an explanation of that, I’ve missed it. It always helps me to understand forced change when someone provides a logical explanation of WHY. (Of course, if the answer boils down to just “the boss said so,” that isn’t going to do it for me).

p.s. I have always hated (and turned off) type ahead features in any and all applications where I have had them thrown in my face. For me, they don’t save time, they increase time.

Also: if I type in Levi as the given name then my assumption is that I will also get Levi S or S Levi BUT, if I type in Levi S then I should only get Levi S, not plain Levi…again the solution may be what I’ve frequently seen in other search engines, giving the user the option to specify “all the words” or “any of the words.”

Robert H:

I think that both old and new search have a problem with “Indian Territory” as a “Lived In” criteria in the 1900 census.

But I got what may be a reasonable result by the following (using new search and filtered to the 1900 Federal Census):

First Name: John (Exact)
Birth Date: 1858 +/-10 (Exact)
Birth Place: Georgia, USA (Exact)
More>Keyword: Indian Territory (Exact)

I have 8 hits that all appear to fit the criteria.

I’ve been using New Search for a couple of hours tonight, mostly successfully but not entirely happily. Until just now, it’s been producing correct results (success!), but it’s been very slow (unhappy).

As I have reported before, searches with New Search are locking up my computer in a 100% CPU utilization state during each New search, and the searches are taking 10 to 15 seconds each before the search completes and the lockup is ended. The same searches with Old Search are instantaneous by comparison, lasting a second or two without locking up my computer during the search. For the first time, I peeked at the HTML source for the search page. As Jade reported in #45, ancestry is using Javascript. It seems likely to me that the problem of the slowness and the lockup is somewhere in the Javascript.

As I said in the first paragraph, New Search has just now produced what appears to me to be incorrect results. My search looks a little funny, I suspect. It is for first name glen* (exact), last name letsinger (fuzzy), and spouse’s name dun* (exact). Of course, it can’t tell whether dun* is supposed to be a first name or a last name (it’s supposed to be a last name). That’s a problem that has been reported numerous times before, and it did not appear to be the cause of my incorrect results.

As an example of the incorrect results, my first hit was a Nevada divorce, Rebecca Irene Dunbar to Thomas Glen Dunbar. I realize that this is a fuzzy search, and I realize that this was only a 2 star match. Nevertheless, it seems to me that the exact first name of glen* should have remained with the first spouse rather than being moved down to the second spouse. After all, glen* was an exact first name associated with the first spouse.

I made letsinger fuzzy rather than exact because it’s often spelled in ways such as litsinger or ledsinger, and you can’t wildcard any of the first three characters. The ability to make each individual field either fuzzy or exact is one of the great promises of New Search. But the new ability seems to me to be incorrectly implemented. It doesn’t really honor the exact search fields in a way that makes any sense. It acts almost as if any fuzzy field makes the whole search operate in fuzzy mode.

I was expecting matches where the first spouse’s first name included exactly glen*, where the first spouse’s last name included some reasonable facsimile of letsinger, and where the second spouse’s first or last name (grr!) included exactly dun*. That’s not what I got.

Just a quick follow up on the slowness of New Search and my computer locking up with New Search. I just did the following experiment.

I went to Old Search and did an exact search for John Smith (silly search with lots of matches). Despite the huge number of matches, the response was practically instantaneous and my computer was never locked up. I could enter another search immediately.

I clicked on “Try It” to go to New Search. My computer locked up for 16 seconds (timed with a stop watch). And I wasn’t even to the point of entering a search yet.

I clicked on “Get Started Now”. The search screen for New Search appeared practically instantaneously, but my computer locked up for 18 seconds (timed with a stop watch).

I did an exact search for John Smith (same silly search with lots of matches again). The results box appeared practically instantaneously. But the Refine Search box did not begin appearing until about 7 or 8 seconds later. The Refine Search box did not appear all at once, but rather stuttered its way down the screen. It wasn’t all there until about 15 seconds after I had initially clicked the Search button. My computer was locked up during this whole process, and it finally became unlocked 29 seconds after I had initially clicked on the Search button.

The results appeared almost instantaneously with both Old Search and New Search, so the problem surely isn’t in the Search Engine. My computer doesn’t lock up with Old Search and it does lock up with New Search. So the problem appears to be in the New Search UI.

The same problem happens on the three different computers I use to access ancestry.com, but this is the first time I have timed the results. All three machines have Windows/XP SP3 with all current patches installed.

Re: my #86. I have identified that the slowness happens on IE 6. It does not happen on IE 7 nor on Firefox. Your mileage may vary.

Here’s a New Search problem in refining a search. I won’t repeat the gory details with Old Search, except that I will point out that the following works great with Old Search.

Exact search for Terry Underwood, living in Tennessee, display as Summarized by category. There are 53 matches in the U.S. Public Records Index, which are the matches I’m interested in. Click on U.S. Public Records Index.

A visual scan of the matches reveals that the ones I’m interested in are in Sale Creek, Tennessee. The refine search box is already visible, so I click on name, blank out Terry, and leave Underwood as it is. I click on More to be able to enter Sale Creek in order to search for all the Underwoods in Sale Creek. Under More there is Other Info which has an entry box for Location, but the whole other Other Info area is grayed out.

Because I can’t enter Sale Creek into the location, I try entering Sale Creek as keywords. It works fine, and I get the same results as with Old Search. I guess I shouldn’t complain, but I find the experience very dissatisfying. With the Old Search template, it’s very clear what is city, what is street address, etc. The need to put the city into the keyword box is not at all intuitive, especially in the presence of the Location box that is grayed out.

I’m sure this issue is all caught up in the question of manually created templates vs. automatically created templates. And Old Search may have only been creating the illusion that I could enter a city when in fact I was really searching for a keyword. But whatever the cause, the new template is very user unfriendly.

Here’s a possible template problem, very similar to others that have been reported.

Exact Search, Tennessee State Marriages, 1780-2002, first spouse with a last name of Hawk, and second spouse with a first name of Jean (except as always that in New Search the first and last names of the second spouse are not properly distinguished).

With Old Search, there are 4 matches.

With New Search, there are 7 matches.

The 3 extra matches with New Search are cases where the first spouse doesn’t match anything at all, and the second spouse is some variation of Jean Hawk. So the last name from the first spouse has been combined with the first name of the second spouse.

If I had to guess, the purpose of this rather strange behavior of the search is to find cases where Jean married first Mr. Hawk, and then Jean as Jean Hawk married second to somebody else. My guess may be wrong. But if my guess is correct, then I really don’t like the behavior even in a fuzzy search, and I think it’s completely wrong in an exact search.

Another guess is that the rather strange search behavior might be related to names being indexed as keywords rather than as names. If that’s the case, then I would only point out that the Old Search template processes the search correctly and that the New Search template does not.

I time old search with new search with the same name and got 7 sec. with old search and 12-15 sec. with new search and I have IE 7 service pk 2. That includes that ridiculous irritating pause just after you think it’s loaded but it aint. If I start to scroll, it freezes for a couple sec. and then moves.
I think this whole thing is a waste of time because someone don’t know what they’re doing down there. I have never seen such problems with other search engines. Throw it away and do it right………Geez.
I doubt I’ll be renewing again.

Right now, I get about 7 seconds from ‘Search’ to the time the results are scrollable in both old and new using IE7. I tried the new Google Chrome which is supposed to have a faster Javascript interpreter and clocked about 4 seconds.

But this type of game is so dependent on your connection, your computer and server load.

You want to see slow, try footnote.com. Painful!

Here’s another New Search strangeness. I did an exact search for last name Kyte, spouse’s name Miller, no other data. There were four matches. (Note that I actually have a great deal more data for the couple, but as is usually the case, and contrary to ancestry’s typical advice, the best search results are usually obtained by specifying less information, not more.)

One of the matches was for the database Tennessee State Marriages, 1780-2002. It was the couple I was looking for, and that’s a good thing.

There were also three matches in the trees. I call your attention to the match in the Public Member trees. It was for Frank Money who married Mary J. Miller. The Miller part makes sense, but Frank Money? Well, Frank’s mother was listed as “kyte, root” (sic).

I’m not sure what “kyte, root” means exactly, but clearly that’s where the Kyte match came from. So an exact search for a couple matched a man’s mother’s name with the man’s wife’s name. That can’t be right for an exact search, and I don’t think it makes any sense for a fuzzy search, either.

Here’s another New Search experiment, having to do with fuzzy searches and the calculation of stars. All searches will be in the 1850 census.

We start with an exact search for John England, born 1815+/-5, born in Tennessee. There are 4 matches. These 4 matches become sort of a lower bound for subsequent fuzzy search experiments.

We do one more exact search for John England, born in Tennessee. Because there are no bounds on the birth date, there are now 23 matches. These 23 matches become sort of an upper bound for subsequent fuzzy search experiments.

The first fuzzy experiment is to search for John (exact) England (exact) born in Tennessee (exact) born in 1815 (fuzzy). There are 23 matches. The first 4 matches are 4 star matches. The next 19 matches are 3.5 star matches. I guess that sort of makes sense. As I have posted before, I think the best matches (which essentially are perfect matches in this case) should be 5 star matches rather than 4 star matches. And I think that ancestry should use a “deduct from 5 stars” system to calculate the stars rather than an “add to 0 stars” system. Nevertheless, the results so far are not too bad. The best matches are, roughly speaking, the ones that are +/-5 from the target date – even though the range was not stated explicitly.

The second fuzzy experiment is to search for John (exact) England (exact) born in Tennessee (exact) born in 1852 (fuzzy). It may sound silly to look in the 1850 census for somebody born in 1852. But we might have a family record of some kind for a person that says they were born in 1852 when in fact they were really born in 1849. Again, there are 23 matches. The first 2 matches are 4 star matches, and the other 21 matches are 3.5 star matches. The 4 star matches sort of make sense because they are for people born in 1848. From 1846 and further back into the past, all the rest of the matches are 3.5 star matches. That’s sort of ok, except that by the time you get back to somebody born in 1811, surely there should be a bigger deduction and surely you ought to be down to 1 or 2 stars. Because ancestry calculates stars with an add on system rather than a deduction system, the search I’m doing can never go below 3.5 stars no matter how bad the matches actually are. The exact name of John England always gives you 3 stars and the exact birth place of Tennessee always gives you another 0.5 star.

To demonstrate the point further, the last fuzzy experiment is to search for John (exact) England (exact) born in Tennessee (exact) born in 1900 (fuzzy). Searching for people born in 1900 in the 1850 census now really is ridiculous. But there are still 23 matches, and all of them are 3.5 star matches.

Anne has hinted at some coming improvements in this area. But what she has mostly hinted about is the ability to cutoff the display and maybe to display only 5 star matches, or maybe only 4 or 5 star matches, etc. The cutoff is a good idea. But the cutoff really won’t help very much unless the star calculation itself is placed onto a much sounder footing. I don’t see how you can possibly have a reasonable star calculation with an add on system. It must be a deduction system, preferably based on a distance formula. And it must be possible (for example) for a wildly incorrect birth date to cause enough deductions to calculate out to 0 stars even if everything else matches exactly.

I have a question about the way that ancestry has set up it’s new main page. What good does it do to have a box that supposely shows what records have recently been added when the last record that it currently shows is the US Public Records index which was updated on August 30, 2008, while when you go to the labled “Genealogy Databases Posted or Updated Recently” there have been over 20 other new databases added since August 30, 2008? Why can they not automically update the small box on the main page when they add the databases to the main data base page? Again is this an effort to minimize the importance of various data bases. Here we are again back to the problem of acquiring and updating and indexing correctly the data bases versus spending money on getting new members.

My sense is that this thread is close to being closed out, and Anne is likely to post a new example fairly soon. To that end, I want to reinforce one particular thing that Reed said in #63. Reed made numerous good points in #63, but I want to hone in on the following:

I rather like Old Search’s starting and ending date-categories being labeled “Year Range,” rather than “Birth” and “Death.” Imperfect as Old Search is, it seems to do a much better job at including useful information and excluding off-target databases with these starting and ending Year Ranges. Perhaps us “Exact Searchers” need the ability to specify starting and ending dates for the *records* in addition to (or instead of) exact (or probable) dates of birth and death. As it is, New Search is hopelessly inept at this.

Irrespective of all the other problems with New Search, the loss of the functionality described in Reed’s paragraph above is perhaps the greatest deficiency in New Search as compared to Old Search. So let’s do the Levi S. Baker example in that style. Old Search, exact, search for Levi Baker (not Levi S. Baker), lived in USA, state Illinois (can’t refine it down to Chicago or Cook County, which is ok for our purposes), year range 1827 to 1910.

Such a search typically yields a goodly number of false positives, and the search for Levi Baker certainly does. But the total number of matches is typically quite manageable, and it is manageable in the search for Levi Baker. The false positives are a very good trade off for the expansive list of databases that usually show up, especially since the overall number of matches is manageable.

In this case, there is 1 match in 1850, not our guy (the L. S. Baker problem). There are 3 matches in 1860, and it’s easy to eyeball which one is our guy. There are 5 matches in 1870, and it’s easy to eyeball which on is our guy. Etc.

But more importantly, there are matches for Illinois marriages, which I might not have thought to look in. In this particular case, none of the matches appear to be our guy, but it’s easy to determine that our guy is not there, and it’s good information to know.

Another database of interest which I might not have thought to look in is the U.S. IRS Tax Assessment Lists, 1862-1918. I think the match is our guy. As interesting as the match might be, it does not appear to me to provide any data that would very much advance our research on Levi S. Baker. But I have found this database extremely valuable for rural counties because for rural counties it usually lists the number of acres the person owned. One of the mantras for difficult research problems is “follow the land”, which typically means things like land grants, deeds, and tax records. But given the number of counties I research where the courthouse was destroyed by fire or that was destroyed in the Civil War, any extra land record can be a godsend. I never would have thought of looking in the IRS Tax Assessment database for Levi S. Baker unless it had shown up in the Old Search version of exact search.

There are other databases that show up in this manner from time to time as well. As Reed said, you really can’t accomplish the same kind of search with New Search no matter what you do (or at least if you can, I haven’t figured out how to do it).

As was stated in #95, “Another database of interest which I might not have thought to look in is the U.S. IRS Tax Assessment Lists, 1862-1918.”
I thought the search automatically searches every category (as in “all categories”) Am I missing something?

Re: Mark B’s #96. There seems to be a problem in searching for all records for Levi Baker in Illinois from 1827 to 1910 with New Search. Either you have to omit dates from your search criteria altogether, which typically will make the search too expansive. Or you have to give something like a birth date or a death date, which typically will fail to show many, many databases where the records themselves have dates but where the records do not include a birth date or a death date.

I’ve not found a way with New Search to give dates for records, only dates for events such as births, marriages, and deaths. Is there is a New Search way to accomplish the search I described in #95, namely records in Illinois for Levi Baker from 1827 to 1910?

The Lived In search box is the best candidate, but it does not include a date range. Besides which, I just did an exact search with New Search for Levi Baker and Lived in Illinois, USA, and it failed to find the IRS database and numerous other databases found with Old Search. The only way to get the IRS database to show up with an exact search was to search for Levi Baker with nothing else at all, not even the Lived in Illinois.

Rather than fill up more column inches with more of my experiences, let me just say that my New Search experiences (re Levi S. Baker) have been 100% the same as Jerry Bryan’s in #95 & #97 (among other examples).

FYI, other sources that New Search does NOT find include a number of interesting leads in what Old Search categorized (separately) as “Stories & Publications.” One of my favorite finds was in A.T. Andreas’s “History of Chicago” in the informative chapter on the Grain business, including a reference to “old Mr. Baker,” an expert on Chicago’s grain elevators.

[Admittedly, I did not find this reference with an Exact "Levi S. Baker" search; I know Levi B. had worked in the grain business and I searched for Name=Baker and Keywords=grain, elevator, Chicago. The point is, this was very quick and easy to do in Old Search.]

New Search also fails to find the Chicago Tribune obits of Levi S. Baker or his wife Lucetta (in which Levi S. Baker is named). Both were found with Old Search in the collection of “Historical Newspapers, Birth, Marriage, & Death Announcements, 1851-2003.” (Perhaps they can be located via New Search, but not by me!)

Which brings me back to a real (non-metaphorical) sore point: New Search is a pain in the fingers to navigate! Fellow-blogger Jim wrote (#78):

“Now here is where I have a problem with the old search: Suppose I want to examine other candidates in a particular census year. I filter to that year. Good. But if I want to refine my search, I find that the search box only kept the name. All of the other criteria is empty.”

On the one hand, Jim is correct, in focusing on a particular census year (having already searched for “Levi Baker,” In “Illinois” for example), “Levi” and “Baker” and “Illinois” SHOULD be filled in automatically. Why this is not so is a mystery but—for me—only a minor annoyance since (1) the search boxes will continue to auto-fill after I re-type the info for the first detailed search of this database and (2) ALL the search fields AND the Exact/Soundex pull down menu are easily accessible and selectable with the TAB, ARROW and RETURN keys. No pointing and mouse-clicking. AND, if any of the search fields are out of view, they automatically scroll into view as I TAB from field to field.

Jim also remarked: “I also dislike the (refine) search box at the bottom of the page. I prefer to see my search criteria along side the results.”

I would be less picky about this if—and it’s a big if— ALL the search fields were visible at least most of the time. For me, even on my 22″ monitor, this is NEVER the case with New Search; instead it’s scroll-up & scroll-down, over and over and over again… Old Search search fields (*and results*) are displayed in a much more compact & economical layout.

Another nice thing about the Old Search advanced/detailed layout (at the bottom of the screen) is that I can access all the available search fields with a quick press of the END key on my keyboard, type my search parameter changes, hit RETURN and look at my results, scan through them with the UP and DOWN arrows, HOME & END keys and repeat as needed. I can change search parameters quickly, with many fewer keystrokes and hardly any mouse-clicks. It’s faster, more ergonomic and much, much more productive per unit of time worked.

Cheers,
—Reed

Jerry in #94 made an excellent distinction regarding meaning of dates (events rather than range in life-path), expanding the issue pointed to by Reed in #63.

I think the problem in a Global search, (of New Fuzzy’s not finding numerous databases in which target persons do appear) is related to this.

I think the underlying reason is that New Fuzzy was based on a Tree search. Trees typically consign data on people other than event dates to notes and added links to transcripts or document images on Ancestry.

This is why Anne posted an item in her #67 regarding how the search engine should interpret place-names combining commas. This particular issue is due to the flawed gedcom code shortcut regarding place names.

This Tree orientation is the reason that New Fuzzy has trouble interpreting vital dates as date-ranges for data in database indexes and for actual date ranges of particular databases. Such databases as the 1860s IRS reports do not appear to have the dates of the reports *indexed*, and New Fuzzy cannot find them as having relevance to the Event Dates.

This is an indexing problem for New Fuzzy, but not for Old Search, which by and large is not dependent upon Event Dates.

Those who have not posted Trees on Ancestry.com which New Fuzzy can use as a search basis, who are doing database research on persons who may or may not be related to their or anyone else’s Ancestry.com tree, or who are looking for types of records other than BMDs, will not find the New Fuzzy approach very user-friendly.

Those who are searching mainly for records 1620-1870 will also find New Fuzzy not very congenial because Ancestry’s database of BMD records in this period is quite limited. The concept that ‘nunmber of hits in a database’ is a sign of value based on same-surname *or* same first name, is what produces the ridiculous unrelated-date search results from such items as the England and Wales BMD indexes.

Anne,

Jade’s recent comment (#98) offers a very plausible hypothesis that would explain a number of fundamental problems with New Search.

Is Jade correct? Is New Search more-or-less wedded to Ancestry’s (or the individual users’) collection of family trees?

Do tree-focused search criteria take priority over database/index-focused search criteria?

Inquiring minds want to know…

—Reed

So, after a couple of months reading that things have been somewhat corrected, I give New Fuzzy Almost-A-Search-Function another try.

I enter, all exact, the information for my father, with “tell us more to getter better results” and all. I’m pretty sure he existed, but New Fuzzy tells me that he didn’t.

So I uncheck “match all terms exactly” and try again.

Now I get 74,853 hits, sorted by category. Maybe Dad did live after all. But 74,853 is way too much to scroll through, so I change the “view” to “sorted by relevance”.

Now I have 68,566 “matches” listed. Apparently even Fuzzy Search realizes that 6,287 of those previous hits weren’t exactly relevant.

I am not convinced anything has improved here.

Another New Search strangeness.

Cecil Owens was born 1902 in Tennessee. Gladys Underwood was born 1905 in Tennessee. They were married in 1923 in Tennessee. I have more details than that about their dates and places, but the details don’t matter for this story.

I was looking for their 1930 census entry. I started by already being in the 1930 census, and didn’t do a generic search. This was a real research task, not just an example I was putting together for the blog.

As is nearly always the case, I was using exact search. Because Owens is often spelled Owen, I entered it as owen*. I entered Cecil as cec*, just because I could even though Cecil is not often misspelled. Because Gladys is often spelled strangely (e.g., Gladis, and numerous other variations), I entered her name as glad*, and there was no reason to enter her last name because her married name in the census should be Owens. For her, I was dealing with a field that combined first name and last name, anyway. Finally, I entered Cecil’s birth information as 1902+/-5 in Tennessee. The search box does not allow the entry of birth information for the second spouse.

There were no matches. Numerous variations on this same basic theme failed to find the couple. For example, leaving out the birth year and/or the birth place didn’t help. Leaving out Cecil’s last name and keeping his first name didn’t help. Leaving out Cecil’s first name and keeping his last name didn’t help. Etc.

After about 45 minutes of trying lots of different searches and being very frustrated, I switched to old search, went to the 1930 census, and entered the data as described above. There was a match immediately. They were in Knox County, Kentucky.

It turns out that their names were spelled completely correctly by the census enumerator, and their names were indexed completely correctly by the indexer. Armed with that knowledge, I went back to New Search and entered their complete information – Cecil Owens, born 1902+/-5 in Tennessee, spouse Gladys. There was a match. If I hadn’t been so concerned about spelling variations the first time through New Search, I would have found them the first time through New Search.

A little experimentation revealed that the wildcards in Cecil’s first name and last name were fine. New Search ran into a problem with wildcards in Gladys’s name, and wouldn’t match if there were an * anywhere in her name. No matter that glad* matches Gladys, New Search didn’t like it. I assume that’s got to be a bug.

Until the bug is fixed, it’s going to make certain searches much harder with New Search than they ought to be. For example, what if the 1930 enumerator really had written her name as Gladis or Gladius or something like that? If so, then it wouldn’t have matched if I had entered gladys nor if I had entered glad*.