Hi Ann,

Thanks for addressing this issue which is very important to many of us. First however let’s talk about how one even gets to the 1900 census only on the new search. On the old search I look on the right under “Historical Records” and click on “US Federal Census” under that heading and then I get a list of all the US census’. From there I can pick the 1900 census database by itself.

So I switched to the new search and what do I see? A list with a few census’ and then a link to “see more” which only takes me to a card catalog search. That is fine for the thousands of various titles that don’t get used as often, *but not for the most used databases*. I want that list and easy way to get the 1900 census only (without bookmarking). Possibly I am missing something though because I have only enabled new search for short periods.

When I can do that, then I will discuss the specifics of the two different search forms under each.

However let me add one more thing. Which is that the old search should not be set in stone as Ancestry seems to like to do where they refuse to tweak an old proven system to try to force one to adopt a new system. That new 1900 census search form with exact check boxes on each and every field *should be available through the old search NOW*.

In fact that is the best method to reach something called “new search”, i.e. improve the constituent parts of the old search as much as possible first and then go from there.

Thanks for listening.

Mike

I am not clear on how you would mark something for an exact search for 1845, and then put within a range of 5 years.
My next issue is that rarely do I hunt in the census records with an exact location of where a person lived. As an example I recently got an obit for a Charles Bower and in it it stated that he was survived by his bother Sylvester Bower who lived in the state of Washington. I did finally mange to locate Sylvester Bower in the 1900 census but not before I was facecd with the issue of how his name was spelled by the transcriber.
Why would you check exact search for a blank field for a first name again that makes no sense to me.
I would estimate that close to 90% of the searching that I do involves dealing with either the census taker or the transcriber or both made a mistake on the spelling. My father’s name is spelled correctly by the census taker, but incorrectly by the transcriber. I therefore would not want to use a search interface where in order to avoid thousands of responses I had to check exact. A search interface needs to be able to give us a reasonable number of results that are within the range of possibility and still allow for some variability.

It is much more likely that I am trying to find out where Andre Lynn resided over the years.

If I knew “…I’m looking for a male, surname Lynn, born between 1840 and 1850 in New York, and I know he lived Lafayette, Tippecanoe County, Indiana in 1900.” I wouldn’t need to do much of a “search”, since I know all the relevant facts already.

Old search: Andre Lynn, lived in New York, years 1840 - 1900. Returns one record, the 1900 census for Indiana.

New search: Andre Lynn, born in New York, 1840 +/- 5 years. Returns 2,173 records (not including the Indiana 1900 census) including the usual idiotic lists of Canadian obits from 1985, marriages in England and other inanities.

Oh, pooh. Change the new search parameter to 1845 plus/minus 5, as it should have been, and get 2,184 records returned — including the 1900 census.

Only 2,183 spurious responses this time.

Anne,

Your example today really does not have much to do with the New Fuzzy search, only with the page setup.

The results pages for Old Search for US Census could be re-formatted to provide the image view instead of the present popup view of a transcript.

True, one cannot view the search parameters so easily in Old Search results (the search form is at the bottom of the page), but with Old Search it is immensely easier to change the search parameters with No Clicks.

The problem with New Fuzzy and Census is its unreliability in even finding valid Census entries that *are there* - see my example in the previous blog series on this topic, regarding Daniel Davis (1760-1816).

I have bookmarked the Census listing so I can pick the Census database to search with *one* click.

It would be a little easier to navigate if the link back to the Census listing were at the top of the Old Search Results page, as it is at the top of the Image pages. That way it would be much easier to change Enumeration Year.

If your approach is veering toward tweaking Old Search UI for better usability, I would be glad to see it happen.

Even better would be if the indexing of some databases were to be fixed, and the Search Engine improved in the ways that have been mentioned many times in these blogs.

Thank you for your efforts.

I love seeing an example and the effort to directly address our issues. I don’t think, however, that this is quite getting to the root of the problem. This example is *very* structured. As #3 points out, if you change up the criteria the results change drastically.

For example, I tried out this search in the New Search, making slight changes. The changes: I added his exact first name and didn’t start out searching the 1900 census, but drilled down to it after the “all categories” search was complete.

To start with, I’ve got 12,586 results when sorting by category. I narrow it down to Census results and still have 5,641 results. On the list of census results, listed by category, the Indiana census results are half way down the second page - even though the search says that this location is exact.

Searching by relevance gets better results - but the search should work both ways - right?

I know that a lot of folks start out searching in a specific database, but that’s not how I usually do it. I like to do a general search to view all possibilities and then go from there. For me, this new search would prove incredibly time consuming and turns up way too many strange results. For example, the second most relevant result for this *exact* search was for Euraette Lynn of Montgomery, Ohio. What the…?

Anne, it’s hard to know exactly how to comment without just sort of saying “ditto” to what has already been posted. But let me try.

As others have already said, this search is very unrealistic because you already know everything about the person you are looking for, everything in the search “just works” (enumerated correctly, indexed correctly, etc.), and there is only one hit. Perhaps some of your coming examples will address these issues.

As others have already said, I found it very awkward to get into the 1900 census. I was in old search, switched to new search, and from there it’s hard to find the 1900 census. I know I can get there by switching from the Search page to the Home page, and the census link is on my Quicklinks. But the 1900 census is hard to find from the Search page. I think this problem would have been very obvious if you could have recorded your whole sequence of clicks (c.f. my little mini-webinars).

There are lots of Lafayettes, so the type ahead to Lafayette, Tippecanoe, Indiana, USA is very awkward. The Old Search system for entering place names is much superior.

The search box is so big that I had to scroll down to see where to click to execute the search.

If you pass your mouse over view image, you get a preview of the information in the record. In fact, there is not a View Image. This was mentioned over the weekend on one of the other threads. There is only a View Record. If you wish to view the image, an extra click is required. The Mouse over works on View Record, but it works with Old Search as well so this is not an advantage of New Search over Old Search.

You can see what is in the query that produced these records, what you choose to be exact (it has ” ” around it in the query), and you change, delete or add a parameter for your search without changing pages. This may just be a very personal thing, but I find the Refine Search box to which you refer to be one of my least favorite aspects of the new UI. It’s not at all easy to interpret because you can’t really see the structure of the original search and you can’t see all the fields. And is “Lynn” a first name or a last name at this point”? Also, the Refine Search box taking up very valuable screen real estate. I realize that with old search that the refine search information was at the bottom of the screen and usually was only visible via scrolling. But once you scrolled, you could easily understand what was there. A better solution, in my opinion, would be to go back to the Old Search style of Search box (which is much smaller than the new search box!) and to leave it at the top of the screen rather than at the bottom of the screen. That way it would be visible without scrolling. The highly compressed box at the left of the screen is really irritating to me, fingernail on a chalkboard kind of irritating.

The results box is much inferior to the one in Old Search. This has been mentioned in other threads. It’s not wide enough, when there are lots of hits there are not enough hits on the screen at the same time, and frequently (as in this case) there is not even a View Image option. Of course, it’s not wide enough in order to accommodate the Refine Search box on the left side of the screen.

Also, this is an exact search. Why are the results “Sorted by Relevance”? By definition, all hits are exact and therefore all hits are equal. You can’t sort things that are equal. The way Old Search sorted the results from exact search was unfortunately not under my control, but it was at least useful. “Sorted by Relevance” is completely meaningless for exact searches.

Finally (and this gets into search engine issues rather than UI issues), why is a hit on an exact search a 3.5 star match? Any exact match should be a 5 star match. But that’s a different subject for a different time. We want to focus on the UI for now.

As I said before, as did Jade #5, why can’t we keep the old search and just get the bugs out of that one.
But if we paying customers have to use a search that isn’t up to par, then I’d like to add that sorting by “relevance” does not lump all the same names first. It shows a few correct names in one index (marriage)and then the next index (different state) with a few familiar names and so on, page after page. And if I select “category”,…oh my God, why aren’t they alphabetized like in old search?
Now I have to look for the individual states-I see one entry for Ill. 1790-1860 and on the next page-Ill. 1850-1900. Is there no other Illinois marriage indexes past 1900?; why can’t the cities and counties all be lumped with the relevant state?
A couple more suggestions- how bout dividing marriage and divorce? and what happened to auto complete in the first name entry…as in names I’ve typed in days ago? Old search has it but new search only gives me suggestions like names already in my tree. I’m sure that comes in handy but I’d like the regular auto complete back again. Also, what happened to next page/previous page at the top of the page? Old search shows it at the bottom AND top of the page. And, there needs to be a “return to tree” link on every page. And is there a way to view all photos at once in a public tree without having to go to the
“community” tab and finding them that route?
Thank You

Ok, I found how to view all photos at once in a public tree.

OK Anne - so grandma remembers that her great grandfather lived in Lafayette, Indiana and his last name was Lynn. I do the knew New Search and find him. Where do I go next to find more records?

I go to the Old Search home page and do an exact search on “Andre* Lynn” from the USA in Indiana. I get a very tidy listing of 1 to 4 hits in relevant categories - Census, Death/Marriage, Directories (from Lafayette Indiana), etc. I find his Irish mother, sibs, the jobs he held, etc. I am now on my way. I repeat the search using the Soundex option on Lynn and get a fairly compact, organized list of 25 or less hits per category. I know I will catch Andre/w Linn.

I try the New Search. I can’t begin to describe the frustration in trying to look for “Andre* Lynn” from Lafyaette, Tippecanoe, Indiana, born in NY around 1845. I get thousands of hits per category for people scattered around the world. Our Andre/Andrew Lynn is not typically on any of the first pages of the hits.

I know you asked for a comment on the UI of the New Search. So pardon this diversion. I would put up with New Search’s slowness and disrespect for screen real estate if I could get accurate hits. As already pointed out, the preview is not a New Search enhancement; we already have it.

Each of the individual Ancestry databases have indexing quirks which we’ve learned to work around and even use to our advantage when searching. The Old Search mostly works very well despite these quirks when searching across databases and very well when searching within specific databases. As a minimum standard, New Search should do the same. Then we can worry about the user interface.

In rereading all the comments so far, I would add the following. Anne’s particular example did have the virtue that it worked - New Search gave the same results as Old Search, and it was a meaningful hit. Despite my dislike for the clunkiness and awkwardness of the new UI (which may in part be in the eye of the beholder - you can’t satisfy everybody, etc.), I would put up with it if it actually worked. It just doesn’t work very well most of the time. I do hope that some of Anne’s future examples will address situations that really don’t find hits very easily, even though the record in question is really there.

In that regard, I really like this from Woody #10. I know you asked for a comment on the UI of the New Search. So pardon this diversion. I would put up with New Search’s slowness and disrespect for screen real estate if I could get accurate hits.

The thing that’s so strange is that the search engine itself hasn’t changed, just the User Interface. But somehow or other the changes in the User Interface appear to have so changed the parameters that are fed into the search engine that the results frequently are no longer meaningful at all.

I have been reading these articles and the comments and see that most of the comments complain about the extra erroneous results lists (1000’s) from the new search. Yet nothing seems to be done about it. Fix that, and then we can compare the two searches more easily.

And put the image button back on the results list to avoid that extra click.

Virginia

Interface is, at ;east in part, as communication between user(s)and computer(s) and database(s), etc., (a.k.a., interaction. All of the problems noted with the new search seem to be related to interface/interaction/communication, although not in the limited sense of the search box, which is only one aspect of interface.

It also appears that the answer to most of these problems (user to program, program to user, etc.) lies in two arenas: First, appropriate communication with users (to determine desirable outcomes from the user perspective) and, second, competent programming to deliver those outcomes. If current programming staff members cannot or will not deliver those outcomes, it seems to me that Ancestry may have to find programmers who can and will. The possibility exists, of course, that Ancestry may not be primarily interested in meeting user/consumer needs, in which case all discussion of the new search is moot.

Ann,

There is something that bothers me in your comment, and it is the part about keeping the majority happy. The majority of Ancestry users are genealogically uneducated in methodology and the necessity of evidenced based assertions. Which is fine because all of us were newbies once.

But you cannot keep them happy (or your marketing dept which is clearly intent on catering to them), and keep us happy here who are experienced users *if we are FORCED to use the same search forms and methodology*.

So while you are right that old search was not perfect, it seems perfectly feasible to keep it in place permanently and to continue to tweak it to improve it to satisfy us here in this blog. Then do whatever you want with the new search to give them a bajillion hits and make them think gee whiz Ancestry is great, never mind that they lack the ability to separate out those individuals.

But please do no water everything down to a level of mediocrity in an attempt to satisfy the “majority” by refusing to let us continue to not only use old search in the future, but also continue to suggest incremental changes to same.

The above dual way is an easy way to keep us all happy. While your programmers will no doubt object that it is difficult enough to debug and respond to complaints on one search engine, the fact is that the old search is a proven technology and won’t generate the same level of bug reports even with incremental changes over time.

If Ancestry is not willing to do something like this, I am going to have to think hard when my next renewal date comes up, despite the fact I love Ancestry and use a it a lot. I just am unwilling to be relegated to the back of the bus by your marketing dept and your concept developers who refuse to involve us at the earliest juncture.

As an example of that dual approach, please tell me why you cannot change the census search forms under old search to the same as under new search where one can have an exact box on each filed in a specific census like 1900, and if there is no *good* reason, then when it will be done. Your answer to this question will be very revealing of how much or little Ancestry values the business of experienced users such as the ones responding in this blog.

Mike

I’m pretty sure we can find some compromises in here that will keep
a majority happy.

I don’t think so…and I think that’s the problem with most of the “improvements” that are being made on the site. Designing for “the majority” is a fallacy. 51% or 65% or even 85% is not good enough — after all, 20%-30% of the millions of users who visit the site is still millions of frustrated users.

Designing for a mythical average/majority user is doomed to failure - it’s like designing furniture based on average height, leg lenth, hand size, etc.: no person actually fits the average.

Rather than second guessing people and creating frustration, why don’t you give individuals more control over how search work for them.

Anne in your second note you mentioned that no one discussed soundex. While helpful, the variations seem to only come up after other correctly spelled possibilities come up. Now that could be ok if the search paid attention to the other criteria. My example is Cleary which is spelled all sorts of ways. If I enter Cleary and check soundex, along with a year of birth +/- 5 years and place Ireland, and a location I still get Clearys from all over, born all over, and in +/- 20-30 years before I get to the Clarys born in Ireland in the right location and the right years. I guess I am not patient, but I get frustrated wadding through many pages, because I believe I seldom get results.

I give up. Nobody responds to the “email ancestry support” and when call and talk to someone, they respond “I don’t know what you want me to tell you” and most of the issues I mention on the phone, they know nothing about. Anne, you said no one mentioned ’soundex’ missing. Well, Scott #57 in the last blog- “new search interface” did and I mentioned it on the phone and I pretty sure I also mentioned it in the “customer support” section so this tells me that no one is really listening.
You mentioned sorting by relevance is not valid in response to Jerry Bryan. I understand both your points…I’m still pondering that one but can you please tell me if I’m doing something wrong or is sorting by relevance (whether marked exact or not) suppose to sort by relevance? I’ve seen search engines do this. It should list all John Smiths from every index…IN A ROW. Please address this issue and let me know if it’s being worked on, cannot be fixed or I’m just crazy.
Thanx

What I was trying to say to Jerry was that even in exact matching, some records will be more exact or more relevant, because more information matches. Does that make more sense?

I truly don’t understand, but let me see if I can clarify where I think there may be a communications failure.

Using New Search, suppose I do an exact search for first name blank, last name Smith, born in Tennessee, in the 1850 census of Anderson County, Tennessee, USA. There are 75 hits, and each hit is listed as a 3 star match.

Refine the search to look for first name Lucinda, last name Smith, born in Tennessee, in the 1850 census of Anderson County, Tennessee, USA. There are 2 hits, and each hit is listed as a 3.5 star match. So far so good.

Here’s a part of these two searches where I think we would have to agree to disagree. I think in the first search, all 75 hits should be 5 star matches rather than 3 star matches. I think in the second search, the 2 hits should both be 5 star matches rather than 3.5 matches. ancestry in general and Anne in particular do not agree. They believe that because the second search has more information that matches than does the first search, that the hits in the second search should have a higher ranking than the hits in the first search. I’m prepared to defend my position, but that’s really a search engine issue rather than a user interface issue so let’s defer it for now.

Here’s a part of these two searches where surely we could all agree to a mathematical certainty. All 75 hits from the first search are a 3 star match. The 75 hits appear in a single ranked list. But how do you decide which of the 75 is first, which is second, which is third, etc. when all 75 of them are 3 star matches? Similarly, both of the 2 hits from the second search are a 3.5 star matches. How do you decide which of them is first and which is second when both of them are 3.5 star matches? I contend that you can’t decide. All 75 hits from the first search are equal to each other. Both hits from the second search are equal to each other. Therefore, it makes no sense to call the list a ranked list. Am I missing something obvious?

The one possibility that occurs to me is that in the first list of 75 hits, some of the hits are not really 3 star hits. That is, some of them might really be 3.1 star hits, some of them, might really be 3.05 star hits, some of them might be 2.95 star hits, etc. and all we are seeing is a rounded off value. But if that were true, what basis would there be for declaring some of the hits to be 3.1 stars vs. 2.9 stars? There really is no such basis.

Anne does this help? And if so, do you understand why trying to rank a bunch of 3 star matches relative to each other doesn’t seem to make any sense to me?

Anne said: One thing that always surprises me is that no one has complained that the soundex option has gone away. Am I the only one who used
that?

I complained about Soundex going away!

I only use Soundex occasionally because it doesn’t work very well for most surnames. But when I find a surname where it works well, it’s great.

Anne,

Before I answer your question I would like you to answer mine or rather meet my request. That is, change the 1900 (and others too if possible) search form under the *old search* to have exact boxes for each field.

The reason I am asking you to do this first, or give a very good non-marketing related reason that it cannot be done, is that I am starting to see this conversation drift into a familiar pattern where Ancestry is not really willing to make significant changes or accommodations (like the dual old/new search forms being maintained), but rather is only seeking our input to tweak their pre-ordained plan that we believe is flawed in both concept and execution, and try to get us to put lipstick on a pig.

So two way street. You give us something to improve old search or I am done talking for whatever that is worth.

Mike

The problem here, I believe, is that Anne is stuck between a rock and a hard place.

She, a relative newbie, by her own admission, is trying to hew to the company line — i.e., that the “new search experience” is far to hell and gone better than the functional “old search”. At the same time, she’s trying to deal with the, what? Something like .005 percent of the Ancestry users who 1) read this blog and 2) post comments to it.

The problem is that the .005 percent of us who speak up, for the most part, do things so differently that what’s really, really important to one is basically zucchini to another.

But what we all seem to agree on, those of us who post here, is that the “new search experience” just doesn’t work properly. Re-brand it to “new search frustation” and we could probably agree.

Anne, if it’s at all possible, distance yourself from the corporate mucky-mucks and pay attention to the people who will abandon Ancestry in droves if things like “new search experience” are forced upon them.

By my quick calculation, if 5% of the alleged 5,000,000 subscribers to Ancestry fail to renew their subs, and most of them are (like me) world-record subscribers, you lose about $7,500,000 a year. Is the “new search experience” worth it?

From Anne’s #14: Jerry, you say that the Old UI for location was superior.
Maybe. But it is too easy to mistype something in the town or city box and because you don’t see on old result page what your query parameters were, you’d never know it. On the new UI you can easily type in whatever you want and ignore the typeahead. If you type in your location correctly, it will work the same.

On most of the searches I do, it’s physically impossible to mistype a place value with Old Search. That’s because nearly all the place values I put in are selected from pull down lists. The selection process is simple and sure. With New Search, it’s very easy to mistype a place value using the typeahead.

I find that I can’t really ignore the place value typeahead, because if I do I can get totally incorrect search results, even if don’t mistype and even if I do type in the correct information.

The following three mini-webinars from my little series of mini-webinars illustrate both points. In particular, note at the end of mini-webinar a008 that I correctly typed in hardin county, tennessee, usa and I still got very incorrect results.

http://home.comcast.net/~c24m48/miniwebinar/a007.swf
http://home.comcast.net/~c24m48/miniwebinar/a008.swf
http://home.comcast.net/~c24m48/miniwebinar/a009.swf

I think the real issue from ancestry’s point of view is stated in Anne’s #19, where Old Search has >26,000 search templates to maintain and there is an obvious desire to reduce this to only one or to only a few search templates to maintain. I totally sympathize with the problem of >26,000 search templates. But it sure is nice when the process of specifying a place value is sensitive to the contents of the database in which I’m working. Specifying a place value in Old Search has that database sensitivity, and specifying a place value in New Search does not.

I’ve just reread all the posts, and I’m about to shut down for the night. I want to specifically highlight the following from Anne’s #14: More examples, with maybe some more perplexing results to come. But for now, let’s focus on this one in this post.

I would really encourage a different approach to this discussion. I realize there’s a desire to focus just on the User Interface - on the way searches are setup and refined, and on the way search results are displayed - rather than focusing on the usefulness of the results. But I find it terribly difficult to focus on those UI issues when there is this big elephant in the room of “it doesn’t work”. Could we switch course and look at (for example) Steve’s #3, Steve’s #4, and Valerie’s #6? If those could be solved first, I think there would be much a much better environment for working through the UI issues.

Anne wrote:
What I was trying to say to Jerry was that even in exact matching, some records will be more exact or more relevant, because more information matches. Does that make more sense?

It makes sense to me only because I’ve read George Orwell. All results are equal, but some results are more equal than others.

In an Exact Search, every record in the result set is supposed to be an Exact Matchon all of the fields for which I entered data. Hence every record should be equal in “relevance” — that is, in how well they correspond to the search criteria.

I hope that Ancestry is not suggesting that their search engine knows more about what I’m searching for than I do.

Anne,

No matter how you spin it, the New Search is a poor, anti-ergonomic, GUI and delivers decidedly worse results than the (admittedly not-perfect) Old Search. There’s so much to talk about, but for now let’s focus on your comment (No. 14, Aug 18), where you wrote:

“Jerry, you say that the Old UI for location was superior.
Maybe. But it is too easy to mistype something in the town
or city box and because you don’t see on old result page
what your query parameters were, you’d never know it.
On the new UI you can easily type in whatever you want and
ignore the typeahead. If you type in your location correctly,
it will work the same.”

Sorry, Anne, but that is wrong. The truth is: if you type in your location correctly—but differently—New Search DOES NOT work the same, because the Location and Auto-Fill functions are HYPER-EXACT to an amazing—and very weird—degree.

Here’s a (revised) earlier example of mine, where I “ignored the typeahead,” and got some wildly varied (and mostly useless) results:

Looking for Levi S. BAKER (1827-1910), Lived In (Residence): Chicago. Keep in mind that Chicago is a city within Cook County in the state of Illinois, USA.

Using New Search, just search for: Name: “Levi” + “Baker,” Lived In (Residence): “Chicago” and you get 108,526 hits in dozens of databases, most of which are useless (Please, PLEASE, explain the relevance of “English Settlers in Barbados, 1637-1800″ to this search?!?).

Change the “Lived In (Residence)” from “Chicago” to “Chicago, Illinois” and you get 76,538 hits (most still useless).

Change the “Lived In (Residence)” from “Chicago” to “Chicago, Cook, Illinois” and you get (what I assume are) the same 76,538 hits.

Change the “Lived In (Residence)” from “Chicago” to “Chicago, Illinois, USA” and you get 89, 836 hits (most still useless).

Just for fun, try searching for “Levi” + “Baker,” Lived In (Residence): “Cook County, Illinois, USA” and you get 22,056 hits (most unbelievably useless). Just citing “Census and Voter Lists” results as an example: NOT ONE Federal Census of any kind is included, but these (and ONLY these) ARE:

•Minnesota Territorial and State Censuses, 1849-1905
•1828 New South Wales, Australia Census (TNA Copy)
•Kentucky Census, Reconstructed, 1790
•Families of Cabarrus County North Carolina 1792-1815
•”Second Census” of Kentucky 1800

Huh?… When you’re done scratching your head, go back and try this Exact search using OLD SEARCH—Historical Records:
“Levi” + “Baker”, dates 1820-1910. place: USA, Illinois.
And look at that! 83 hits, almost all of them plausible, and including the vast majority of sources that I have found regarding “my” Levi Baker, and hardly any “junk hits.”

Conclusions? New Search appears to have an unstoppable desire to generate thousands and thousands of IRRELEVANT, UNSORTABLE “hits.” New Search ignores useful information, even when that information is supposed to be an “EXACT” parameter. BUT, New Search will also *exclude* RELEVANT hits if one selects even one “Exact” parameter too many…

Apparently, New Search has additional, unknowable, parameters that may or may not be understood by your staff, but are certainly a mystery to many of us,including some of your most dedicated and proficient users.

Face it, Anne. You’re trying to tweak the *packaging* of a lousy *product*. Even if you can get the package to look better, even if your roll out the focus groups and the marketing steam roller, New Search remains a defective product.

Try this: Google the Wikipedia entry on “New Coke,” especially the paragraphs about “Market Research,” “Rollout.” “Initial Acceptance,” and “Backlash,” and get back to us with your thoughts.

—Reed

P. S. Like many of my fellow bloggers, I have much more to say on the New Search GUI, its inefficient layout, waste of screen space, and repetitive-stress-injury-inducing fondness for mouse-clicking and constant scrolling up and down, but I’ll leave that for another post.

Regarding Jerry’s #21 anent Anne’s post concerning soundex search in New Fuzzy:

“Anne said: One thing that always surprises me is that no one has complained that the soundex option has gone away. Am I the only one who used that?”

Jerry said he had indeed complained about it.

But it appears that New Fuzzy directs the search engine to use Soundex where the surname search parameter is not *exact*. And at least sometimes when the surname *is made exact*. This was illustrated in one of my posts in one of the earlier blog series on this topic, regarding the surname McShane. In this case, the unstated/undirected soundex-search retrieved items containing completely unrelated surnames that were soundex equivalents. And did not retrieve known database items that were exact-spellings of the surname.

So there would be no point in selecting a *soundex* search option. It is automatic. One can supposedly choose *not soundex* by designating *exact*, but it seems that the *exact* directive does not always work either in New Fuzzy.

I would not suggest adding a specific *soundex* option to New Fuzzy. At the present rate of performance, New Fuzzy then would direct the search engine to retrieve items for the Soundex equivalents, but *not* items for the same spelling as entered in the search form.

I suggest that the programmers *and* marketing staff try playing a logic game named something like ‘perquackey’ (I don’t recall the correct spelling).

PS, in #28 I should also have mentioned the frequent occurrence, in Old Search, of non-retrieval of items in *exact* mode, where only names are given (in specific Census and BMD databases) — but when the ‘exact’ box is unchecked the search engine retrieves items with exactly the same spelling as in the search form.

I am not sure whether this is a search-engine problem or an indexing issue (or both) (perhaps I have not figured out which databases have been indexed as keyword rather than surname/firstname). I doubt that it could be fixed by New Fuzzy’s attempted workarounds for Search Engine problems.

Hi Anne,

I can adjust to the new interface. I had adjusted to the old/new interface when Ancestry introduced its “Tabbed” interface. I didn’t like it, but I moved forward. I have watched The Webinar, twice. As others here have pointed out more eloquently than I can, we can adjust and adapt if given half a chance. Our problem is not so much the change in interface as our inability to produce meaningfull results using it. Like others here, I can show a sample:

Using Old Search - Exact mathces only

First name - Caroline
Last name - Livermore
Lived in USA, Massachusetts
from 1897 to (empty)

This produces the following results:

Census & Voter Lists - 7 hits
Directories and Member Lists - 7 hits
Court, Land, Wills, and Financial - 3 hits

All are valid, with the exception of the Court, Land, etc (wrong county).

I have tried repeatedly to reproduce this result set using New Search with zero success.

All I ask is, show me how to do it.

Thanks for listening.

Anne,
Off topic request:

I use the RSS feed to follow an article, so I was a little surprised that there were no more entries on your previous discussion after early evening on August 18th.

If a discussion has morphed into a new discussion wouldn’t it be a good idea to post a note from you to direct users to the new thread. Unless of course you are still montoring the earlier ones.

Now I have to catch up on this thread.

TonyC

OK, I think I caught up 

There are numerous valid comments here and one in particular that I tend to disagree with - #23 from Steve. Steve – you are way under in your estimate of the number who will not renew.

We, the so-called experienced users, are frustrated. We’re frustrated because we can’t see any improvement in the new search regardless of the ‘new’ UI. It seems to me that the new interface / search is not applying the correct data to the old search engine, and I still haven’t had an answer to the questions I posed in the previous thread – is it the same back-end search engine behind the new and the old interface?

So, we the ‘experienced’ know how to find records, we’ve been doing it fairly successfully for a number of years with the old search, even with its short comings. Can you imagine the level of frustration that the ‘newbies’ are going to feel – I can’t, but I do believe that they will also leave in droves if they continue to use the new ‘improved’ search interface, if they continue to see thousands of ‘hits’ from the new search.

How many of you who are interested enough to post here can describe the feeling when you find an ancestor you’ve been searching for, try. How are the new Ancestry users going to feel after hours of searching to find nothing or give up going through the thousands of hits from their search – absolute total frustration – and they will leave.

The suggestion of leaving an option of old or new search is completely valid, I still cannot get any sensible hits from the new interface search, hits out of the date range, and no hits from the census records when I know they’re there. I keep going to the new search trying information that I have already garnered using the old method and the results are sometimes mind blowing and I don’t mean in a good way.

Ancestry is beginning to earn itself an extremely bad reputation and that will also hit the sales of their other products, FTM2008 was an unmitigated disaster.

Anne, you are in an extremely awkward position, you are trying very hard to respond to these discussions in a very positive way – but I feel that you may be fighting too big a marketing snafu. For me – fire the marketing team, hire some really good search engine gurus, fix the indexing, improve the quality of data and give us back a tool that we can use to continue in a very rewarding hobby / pastime whatever you want to call it, we are passionate about it.

TonyC

Anne,

In your #14 of Aug. 19 you say:

“BTW, the old system was not perfect. While any given individual on this blog may like it/love it, according to usage analysis, focus groups and usability studies point to the fact that the old search wasn’t working for everyone.”

I wonder whether ‘usage analysis, focus groups and usability studies’ were designed to distinguish between problems inherent in the Search Engine, or problems with the various search input Forms?

If the latter, which ones?

The present ’send feedback’ questionnaire in the New Fuzzy bar could not possibly distinguish between Engine and Form problems.

So what is New Fuzzy intended to work around?

I think one of the significant problems that it intends to address is the database indexing problem, where when the user searches a database indexed by keyword, but searches as “exact,” the search engine fails to retrieve items that are indeed there because the database was not indexed as surname/firstname but the direction from form to Search Engine is to search as surname/firstname.

New Fuzzy allows designating surname and first name as ‘exact’ separately, without the requirement that the keyword-based index be by surname/firstname.

Is this the crux of the problem mentioned in my #29 here?

TonyC, in #32 you restate your question:

“is it the same back-end search engine behind the new and the old interface?”

You may have missed Anne’s statement in her very first Blog post:

“The new search interface is the hot topic of conversation. It’s not a new search engine; it’s just a new way to interact with the search engine. . . . There are many plans in the works to improve the interface and the backend engine to bring you better results.”

“Re #22 Mike, Let me answer your question specifically. We have
over 25,000 databases, where the search templates are individually
created. It is not something we want to spend time maintaining in
the future because it makes a lot more sense to be working on improving
the quality of search. If I have to choose between maintaining
templates or improving quality, I will always choose the later.
So one of the goals, and not the only one, is to build a search
UI system that requires less maintenance. We will not be making
changes to the current old UI system. Maybe not the answer you were
looking for, but I believe it is the correct answer.”

Anne,

Like I said I am probably done talking then. But I want to clear something up for future reference that I am sure will be of interest to everyone.

Sure you have individualized search templates for thousands of databases. So 2 questions:

1) if new search is implemented will those individual templates still be available even if you don’t further tweak them?

2) will future databases added be given their own template but one which remains static as with the older current ones?

Because let me tell you, NO serious genealogist is going to be satisfied with a research log/calendar that says “searched all Ancestry’s databases”. Such a log/calendar with both positive and negative searches is a vital necessity for practicing *good* genealogy. So if we can’t find and search individual databases *easily* and then list them individually, then we have achieved nothing, and especially nothing worth subscribing for.

Also I want to note as have others, the primary issue here again, which is that *WE* are the ones who should be able to control how a search function operates with search criteria of *OUR* choosing and not yours. If you can’t find a way to give us greater control whilst you give the massess their tens of thousands of hits, then you are doing nothing for us. Customizability of the search function is vital for us, which since I doubt Ancestry is going to give us, is why I want continued access to old search on a permanent basis. I and many others are *not* interested in this being a discussion of tweaking new search into just a different version of one size fits all.

Finally, did you ever address the first issue I and others raised in this discussion of how one gets to the 1900 census search template in the first place? Sorry if I missed your response on that.

Mike

“We have
over 25,000 databases, where the search templates are individually
created. It is not something we want to spend time maintaining in
the future because it makes a lot more sense to be working on improving
the quality of search. If I have to choose between maintaining
templates or improving quality, I will always choose the later.
So one of the goals, and not the only one, is to build a search
UI system that requires less maintenance. We will not be making
changes to the current old UI system. Maybe not the answer you were
looking for, but I believe it is the correct answer.”

Anne,

Like I said I am probably done talking then. But I want to clear something up for future reference that I am sure will be of interest to everyone.

Sure you have individualized search templates for thousands of databases. So 2 questions:

1) if new search is implemented will those individual templates still be available even if you don’t further tweak them?

2) will future databases added be given their own template but one which remains static as with the older current ones?

Because let me tell you, NO serious genealogist is going to be satisfied with a research log/calendar that says “searched all Ancestry’s databases”. Such a log/calendar with both positive and negative searches is a vital necessity for practicing *good* genealogy. So if we can’t find and search individual databases *easily* and then list them individually, then we have achieved nothing, and especially nothing worth subscribing for.

Also I want to note as have others, the primary issue here again, which is that *WE* are the ones who should be able to control how a search function operates with search criteria of *OUR* choosing and not yours. If you can’t find a way to give us greater control whilst you give the massess their tens of thousands of hits, then you are doing nothing for us. Customizability of the search function is vital for us, which since I doubt Ancestry is going to give us, is why I want continued access to old search on a permanent basis. I and many others are *not* interested in this being a discussion of tweaking new search into just a different version of one size fits all.

Finally, did you ever address the first issue I and others raised in this discussion of how one gets to the 1900 census search template in the first place? Sorry if I missed your response on that.

Mike

Jade, thanks for that, I though I’d seen it somewhere and needed clarification.

So that does confirm that the problems are not with the search but how the user input information is fed to the search engine.

Anne, your task then is to provide a UI that can search all 25,000+ databases, given that the information fields differ wildly in some of them I am not surprised that we see thousands of false hits. The search is obviously performed against the index records. I guess I’m trying to think through this as I type so forgive the obvious statements.

In my job we have to provide useful information to the users and we have multiple (not 25,000+) databases and tables. The users are looking for information that is relative to their function, i.e. Finance, HR, Manufacturing, Sales and a few others. If we had a request for all sales to a specific customer since the beginning of the year for a specific part can you imagine the uproar if we provided them all the bill of materials for that part, all the suppliers that provided components to build it, all orders since the beginning of time and the commission paid to the sales representatives??? I’d be out of a job and the users would not get what they asked for.

Isn’t that is what is happening here. The user request outlined above was very specific but the other tables and indexes contain other information about the part and customer – but we don’t include those details in the report because it was not requested!!!

My frustration level is increasing each time I come back to these discussions, why not just give us the information we are specifically asking for? The solution that Ancestry is desperately searching for of ‘one size fits all’ is making people reconsider if they still want to be a part of Ancestry.

Is anyone seeing the warning signs?
Is anyone really listening?
If you scream in outer space can anyone hear it?

TonyC

I tried the old search for the 1900 census and entered:
first name: John
last name: Shiflett
location: Albemarle
Then I switched to the new search and entered the same input and got ZERO hits for the 1900 census. I cannot even figure out a way to get to the 1900 census. How do i do that?

Bob Klein

I forgot to add the old search gave me 5 hits
Bob

For what it’s worth, the “new search interface webinar” mentioned that soundex IS automatic in the new search. I didn’t try it yet so don’t know if it’s true.

Anne I realize that I am not at the technolgical level that most of the contributers to this blog are, but I am still not clear on how if you check exact with a blank box (which is what you did for the first name of the person you were looking for in the 1900 census) how that can result in the search results coming back with a first name. My thinking goes check exact and that is exactly what you want so following that line of reasoning it would not come back even with the one you want, because the first name was put in as blank and then checked exact therefore no response. Thank you for saying that as far as you understand it, ancestry is not going to be a foolist as the US Government was when it instituted No Child Left Behind. If anything proves that one size does not fit all it is that particular piece of legistation.

Ann Mitchel:
Try as i might–4or 5 times
I clicked both old and new census form and I could find not difference between the two. So–what did I do wrong???
Please Ann, make it easier for us to find this page
ie COMMENT ON THIS ARTICLE! I looked for it for 10 minute and then I didnt FIND IT I stumbled on it. Please put it up front or make it more prominent so one can see more readily
I hope I can follow you next several examples RR

Re: Rollie’s #44 and Anne’s statement,

“Note: If you click on the image, you will see a larger version; if you click on the title, it will send you to the search page. . .)”

Okay, I clicked on Anne’s database title “1900 Census New Search UI example”.

It took me right to the *Old Search* form for the 1900 US Census, which is default for me via cookies since I do not use New Fuzzy except to test for Blog purposes.

I clicked on the link to switch to New Fuzzy. Instead of taking me to the 1900 US Census New Fuzzy form it took me to the introductory page.

I clicked on “Try it now”.

On the first page was a search form in the middle; there on the left was a narrow box with choice of databases and room for ads below it. When the ads are installed, we will have to scroll past them to get to the database options. I clicked on “Census and Voter Lists”.

On the new page was a small box at the left with 5 “Featured” databases, ending with “see more”, which I clicked on to find a list including the 1900 US Census. Oh, there was lots of room here for ads.

That click only took me to the bottom of the page, with the same Featured list and more short-lists for databases **other than the one I was after**. Click again on “see more”.

New page had a quickly loading small box for Card Catalog and narrow green bar at the top. Infuriation, grit teeth. Have already been around in circles with that %%wormhole%% box trying to get to Card Catalog. After about 10 seconds’ wait I got the first page of “Census and Voter Lists”. Card Catalog box slides down, making room for ads, which will be at the top and at the right when installed. By default, the page is listing by “Popularity”. Clicked on listing options box.

Clicked on “Sort by database Title”.

Clicked outside the box to unhighlight the selected option, since if you don’t unhighlight it, it will switch order for you randomly, and maybe not until you get to the next page.

Waited another 10 seconds for first page of list to load. Clicked “next” to get to next page of listings since 1900 US census not on first page.

Finally got page listing 1900 US Census. Clicked on it to get search form.

Beginning with the actual New Fuzzy startup (after clicking ‘try it now’) it took 9 clicks and a few minutes to get to the 1900 US Census search form.

Since I have bookmarked the US Census database it takes me just one click to get to the 1900 US Census search form in Old Search.

Anne, you suggest in #40: “Quick Links. At the top of the page, click add to quick links when you are on an individual database search form. It is added to your homepage for easy access.”

Why would I want to have such a link on the Home Page? It takes ages for useless boxes and Tree junk to load, and has unpleasant ads.

I do not bookmark specific years’ Census enumerations, just the database listing (of years and states), which in Old Search has a simple scroll-down selection list in **One Page**. No need to select a sorting method, unhighlight it, go to next page if my search target is not listed in the first one.

If I were to add a ‘quicklink’ to the database listing on the Home Page, I’d still have to wait for the junk to load and take the extra time and clicks to find the one I want to search.

Why don’t y’all just recreate the same listing as in the Old Search list? It is not more user-friendly to have the option to change the default “popularity order” listing which is an illogical and obstructive method for ordering database titles.

I think the answer is that the real estate will be partly occupied by ads. This was the reason for narrowing the Message Boards. This is part of the reason for all the clickiness through useless pages, too: nearly every added click will be a hit for some ads.

Anne
I still would like a commitment to keep old search and the individual database templates that currently exist, available to us if we choose, even if you refuse to upgrade them. It provides a known and acceptable functionality and I see no reason you cannot keep it on board with the understanding it will not be maintained past what it is now.

If there are some other reasons whether for server performance or marketing that the company does not wish to do this, then be honest and lay those reasons out now please.
Mike

Jim’s post #30 touched on what I think is a key problem.

How do you turn off the Fuzzy thing or whatever it is?

If I check “Exact” for last name how do I get it to return only those names spelled exactly like I am searching for?

Using my example from the last blog,

1. Use the old search, exact spelling, for “Charles Bonmot” for “All Countries” with no date range specified. You’ll get one hit, the 1860 Mississippi census. That’s the one I want.

2. Try that same search on the new engine with “match all terms exactly” with no dates or locations listed and you’ll get 1,561 hits (down from last week’s 8,799 hits). All of them are soundex variations of the surname showing Bannet, Bennett, Banta, etc. etc. etc.

So if I wanted my results to show only those names spelled exactly “Bonmot” and not Bannet, Bennett or Banta then how would I do that?

If you can answer me that, then I’d sure appreciate the input.

Thanks,
Scott

Anne @ 35:
Dan, let me post about place and name resolution and then
let’s discuss more. And I’m pretty sure you know more about what
you are searching for than our search engine does, but our search
engine wants to make sure you don’t miss anything. (I think I’ve
just given it human powers.)

Anne, thanks for the response. On re-reading my post, I realized my post didn’t have the tone I usually strive for (not that I post here often, but I digress.) At any rate, I apologize for that.

However, there’s a message that the commenters have been trying to deliver, loud and clear, and we still haven’t seen any acknowledgment of it: Too much data is returned from the “Exact Search”. We want Exact Search to be Exact. We do not want to see the thousands of records that are returned “just in case”. This makes the haystacks larger (much larger), making us miss the needles. In other words, this so-called “feature” is making us miss the data that we’re looking for, rather than helping us to find it.

There’s been discussion on other blog entries about search options beyond the simple, binary “exact” search option. Look especially for Jerry Bryan’s posts (he’s one reason I don’t post here more often — I don’t feel the need to! You’ll see that any good intentions behind the inexactness of Exact Search can be realized through other means.

(I want to emphasize here that the first thing to work on is making the existing binary option work correctly — Exact Search must be exact.)

For example, instead of a two-way “Exact/Inexact” setting, you could have the following:

- Exact (the returned data must contain the same value that I’ve entered in this field.)

- Exact or Null (Don’t return any records that contain a different value than what I’ve entered. However, don’t filter out any records where this field has no value.)

- Close Match (Return only records that have a value that’s “closely related” to the value I entered. This could mean, e.g., values that match on any 3 consecutive letters. So, “fred” and “phred” would match, because they both contain “red”.)

- Please Match On This Field, That Is If You Don’t Have Too Much Else To Work On Right Now, I Mean I Know My Request Isn’t All That Important, Oh Never Mind. (This corresponds to the current “Inexact” search on the Old Search form. Yes, I’m joking. I think.

#48 - Anne, thanks for the clarification that the “exact” thing is being worked on.

#49 - Dan, I like your last suggestion. Wonder if they can fit all those words on a clicky button!

Scott

Re: Jade’s #45:

Thanks, Jade. You’ve saved me the trouble of minutes of clicking and typing, just so I could explain part of my frustration with the clicky-clicky GUI on New Search.

Old Search, with all its problems, had the virtues of speed and simplicity. One only needed to click occasionally, and almost all search parameters could be defined by using the TAB key, pull-down menus (accessed via TAB key and/or up & down arrow keys, and/or type-ahead keyboard strokes). The user’s fingers hardly ever left the keyboard. The process was fast, efficient and much more ergonomic.

New Search requires so very, very many clicks to access search fields, to select previously entered search fields and data that need changing, etc., etc., etc…

Even worse, unless one is using a very large monitor one can’t see half the search fields in the left column and it is constantly necessary to scroll up and down to access these fields.

All of this makes the new GUI extremely slow, fussy and unproductive, especially if one is used to working quickly with the old, more ergonomic GUI.

Finally, Ancestry needs to end its love affair with pop-ups, whether for data fields, “additional input” areas or—most annoyingly—advertisements. If I am trying to search through a quantity of data, using a variety of search parameters and their many possible variants, I do NOT want to keep reaching for the computer mouse just to scroll to and click on the data field I need to open and/or change.

This is basic human-engineering stuff and should not be subject to the “artistic vision” of the Ancestry’s graphic designers.

Please, make the data fields:
•Always visible
•Always accessible via keystrokes

Our hands are getting sore and our research is bogging down.

Thanks,
—Reed

Anne,

First of all, thanks again for responding to many of our comments and concerns. This is an unusual—and very welcome—change in Ancestry’s “culture of non-responsiveness” and it is appreciated.

Re: your #48. You said:

“As I’ve stated twice, there is a large amount of maintenance to keep all of the indivdual templates as they are alive. It has nothing to do with marketing, and nothing to do with server performance. It has every thing to do with trying to build an efficient backend that allows for us to add new data much more quickly and allows us to work on new features.”

I have a serious issue with the implications of your last sentence, and I think I can best explain with a metaphor:

If Ancestry is a “library” of genealogical sources, then its databases are the “books.” And no matter how many “books” you acquire, they are useless to the “readers” (Ancestry members/researchers) unless the “readers” can find the “books”/information they need. For this we need a decent “index” of some sort.

Brick & mortar libraries make their collections accessible through card catalogs (paper and digital) and the expertise of experienced reference librarians. The catalogs need to be meticulously organized, labeled and cross-referenced. This takes time, hours of specialized labor and lots of money.

My concern is that Ancestry seems more concerned with “adding new data” without making it fully accessible via accurate indexing and precise & flexible search processes. Ultimately, the “number of databases” is a useless concept for us researchers if the *content* of those databases is inaccessible because of faulty or inadequate indexing and poorly designed search engines and interfaces.

I wonder, in fact, if your database designers have any experience with good online library catalogs? The majority of my experiences with a wide variety of urban, rural and academic library online catalogs (from all over the country and overseas, all accessed at home via the internet) have been much more satisfactory and productive than any similar experience with Ancesty’s “New Search.” Why must that be so?

I look forward to your response.

—Reed

From Anne’s #43. BTW, some of our data sets seem to not be recognizing exact at the moment….we are working feverishly to fix this.

Anne,could you confirm that data sets not recognizing exact at the moment is the cause of problems described (for example) #3 and #4?

Anne @ 40 and 48:

Sorry if this idea has already been discussed and discarded, but: It seems pretty clear that Ancestry’s value proposition comes from its data (and not the UIs.) Given that, then would Ancestry consider doing either or both of the following?

a) Providing an open API for 3rd-party developers, as sites such as Google, Amazon, etc. have been doing.

b) Open-sourcing the frontend for the new search GUI — the part that, you say, is now being automatically.

I have no idea how relevant my experience is to Ancestry’s systems (and I’m not angling for a job!), but I do know the pleasures and pains of developing automated UIs. Sometimes some of the generated forms need to be augmented with customized scripts; and meshing automation and customization seamlessly is a challenge. And sometimes the system needs to be extended to cover scenarios that weren’t in the original developer’s vision. In sum, automated UI generation is great to have, but automation is usually not enough.

Perhaps if you give us, your customers, a chance to make our own adjustments to the UIs — not replacing your existing development team, but augmenting them — you would be able to create the ultimate win-win scenario.

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

I’m finding it hard to follow the point of your example/argument because the initial premise doesn’t make much sense to me. You started out with more detailed information that I usually have about someone.

I don’t subscribe to Ancestry just to pull copies of census schedules that are readily available elesewhere with precise information. The whole point to searching (rather than “looking up” is that I don’t know where someone was in a particular census year until I find him in a search. I usually have very sketchy information about birth and/or death — …and that’s all. The whole point of my searching on Ancestry is to find out where he was in between; to see when he moved to the death location.

Your explanations here are very hard for me to follow because expectations of what “exact” means are completely different from what you have laid out. If I know exactly when/where someone died, why would I ever pretend that I don’t?

In your example for instance, suppose I don’t know when this guy moved to Indiana but I do know that he died there in 1935. Why wouldn’t the 1900 census record appear as a top hit in any kind of search?

Anne #57 - “New features could include better ranking algorithms, better searching algorithms, better ways to view the data (actually, the plan for this is really good), and more customizable, personalized ways to organize your searches and the ways you search, just to name a few. Forms are really just the beginning.”

You use a lot of the ‘better’ word - how about accurate? What about believable?

The main problems I have and I believe many others here also have, is that the results from the new search are very far from accurate – they miss data bases, they are very far from believable – there are too many results.

How long before we can trust that the new search produces accurate and believable results?

TonyC

Anne,

Thanks for your comments (#57), but I was confused by one aspect of your paragraph:

“You may know exactly when somebody died or was born, I’m not asking you to pretend that you don’t. But the data may not. I have many relatives that show up as being born in different years, or decades in the census reports for example. Now I know exactly when many of them were born, but the data does not. To find everything that is out there, sometimes you have to be not so exact.”

Well…sure. I think we all realize that “To find everything that is out there, sometimes you have to be not so exact.” However—and it’s a big “however”—isn’t that what the user-specified “range of date” boxes are for?

For example (see my #27, above): If I am looking for Levi S. BAKER, and I believe his dates are 1827-1910, then I will likely do an exact search for him specifying the dates 1827 (+/- 2) to 1910 (+/- 2). And if that does not work, I will repeat the search specifying dates 1827 (+/- 5) to 1910 (+/- 5), and so on, expanding the date range outwards on either end as needed.

Now, imagine how maddening it is to do the above *exact* search (+/- 2 years, with the additional *exact* parameter of location=Vermont or Illinois or Chicago) and getting “hits” from sources like:

•Kentucky Census, Reconstructed, 1790
•Families of Cabarrus County North Carolina 1792-1815
•”Second Census” of Kentucky 1800
not to mention the totally non-sensical:
•English Settlers in Barbados, 1637-1800

The ONLY thing the above databases seem to have in common with my search is that they may have data on some men with the given name “Levi,” or the surname “Baker,” or some mish-mash of both.

THUS, because the “Exact” search function is allowed to return so many “hits” outside the user-specified parameters (for whatever technical or conceptual reasons), the so-called “exact search” IS NOT EXACT, and fills our results lists with thousands and thousands of irrelevant “hits,” bringing our research to a grinding halt.

I know I’m not the only one who searches in this manner, and by reading the blogs, I know I’m not the first to complain about this. Please accept the proposition that Exact Search needs to produce exact, USER-SPECIFIED results.

(And keep in mind that this method works well even if you have only a single date for the subject of your search. I first encountered Levi Baker on the 1900 federal census. By using Exact Search with expanding date ranges I was able to track him back to his arrival in Illinois c. 1840 and forward to his death in 1910.)

I think most of us assume that Ancestry’s old “Exact Search” is what DanB (#55) calls “Exact or Null,” and we’ve had much success with that. But I can see the benefit of specifying either “Exact” or “Exact or Null.” In any case, it must be the USER that controls the search parameters, not some mysterious, all-knowing search algorithm from Ancestry.

Thanks for your consideration.
—Reed

Anne,

You (and apparently TGN at large) are completely missing the point about “exactitude”: the searching you have outlined requires each and every data point to match in order to be included in the results list and that is misleading.

Until I started reading your posts here, I always thought that entering the death date/place would increase the possibility of finding relevant hits. As you have explained things though, it actually hurts.

In most cases, we encourage users enter as much information as they know. How is anyone supposed to know that entering an exact death date or place will exclude relevant hits in databases that do not have those “exact” fields? Please explain the intuitiveness of that?

In the example you posted, an unsuspecting user who entered the exact date/place of death would never see the 1900 census schedule for him. In order to see it, he would have to pretend that he didn’t know the death date then wade through a lot of other junk.

Also, I really think that you consider the difference between “look up” and “search”. If you already know where someone was during the 1900 census, you aren’t actually “searching” at all, you are just looking up the schedule on which he appears. That’s an entirely different exercise from actually searching the Ancestry repository for information about someone.

I am not claiming that either is more important than the other or that “the majority” of users use Ancestry in a particular way. What I am saying, is that by not recognizing the difference, you are creating unnecessary frustration for all concerned. The reason that some people are so upset about the “new search” is that the UI design reflects some unfortunate assumptions about what/how “the majority” of users work and those built-in assumptions are resulting in a poor “search experience” for far too many users.

Hi Ann,

I’ve been into genealogy for about a year. I used the old interface but I don’t think I had the attachment to it that many others seem to have.

I like the new interface just fine. I like being able to enter my data one time and then drill down to the specific areas of interest. Or, start with the database and then enter my search criteria.

Anyway, my limited experience tells me that genealogy is all about searching creatively for information. All the problems with indexing, spelling, data variations, etc are just part of the landscape. I want Ancestry to help me navigate these variations and open new avenues that I might not have thought of. But, I also recognize that I might have to be creative in the data that I ask Ancestry to search due to the variations in the databases.

I have read many of these posts with interest and there is wonderful feedback here for you and the behind the scenes types.

Even though I am fairly new to genealogy, I consider myself a serious researcher. My advice is to keep working on the quality of the data. This is what would help researchers the most. I’d also like to encourage all to be flexible in adapting to a new interface. No one likes change.

Thanks for listening.

In #2, Nancy Rogers asked some good questions and made some interesting comments that I think have not been addressed. Let me take a crack at one of them.

I am not clear on how you would mark something for an exact search for 1845, and then put within a range of 5 years.

I think there are many different visions of what an “exact search” is and what a “fuzzy search” is. This whole discussion would be much simpler if there were a precise definition of “exact search” and “fuzzy search” that we could all embrace. Nancy’s first question addresses one piece of that puzzle.

To start with a simpler example than Nancy’s, suppose from the home page I simply do an exact search on John Smith who was born in 1845. What does that mean? It sounds simple enough, but it really isn’t.

To keep the focus on the birth year, let’s stipulate for the sake of the argument that we are happy with how the exact matching works on John Smith and not get into messy details of whether it should match things like Jno. Smith.

A birth record, tombstone record, census record, etc. that has a John Smith who was born in 1845 would clearly match our search criterion exactly, but not a record with a John Smith who was born in any other year such as 1844, 1846, 1832, 1896, etc. That sounds simple enough.

But there are sticky points. An exact search from the old home page for John Smith born in 1845 matches a marriage record for a John Smith married in 1865. An exact search from the new home page for John Smith born in 1845 does not match marriage record for a John Smith married in 1865. It can be argued that Old Search is doing this “right” and it can be argued that “New Search” is doing this “right”. Whichever is “right”, they are certainly doing it differently, even though both of them are doing exact searches.

Arguments of rightness and wrongness are probably not very fruitful. It would probably serve us better to speak of whether the search results are useful or not. My argument in this case is that even if every other aspect of new search were perfect, it still doesn’t have this very useful capability from old search to find marriage records and other similar records based on birth dates. It’s an extremely useful capability indeed.

The real thrust of Nancy’s question, though, was how is it possible to use the word “exact” when one is speaking of a range such as 1845 plus or minus 5. Shouldn’t the term “exact” be reserved for the situation where you are searching just for one particular ye