Skip to content

Records (Searching and Viewing)

Groups Select

Clear

Hello FamilySearch Community! Try out the new update to Record Search.

Hello FamilySearch Community!

The Search team at FamilySearch has been working on a new (and hopefully improved) version of our historical records search. We're always open to feedback, and if you have some thoughts that are kind, specific, and constructive, I will be monitoring this thread looking for additional improvements for our team to consider implementing before we make it available for everyone.

To access the new version of the page, visit beta.familysearch.org/search/

Thanks for your help!

1 votes

New · Last Updated

Comments

  • The option to display all information (under Preferences on the search results page) is nice.

    ....

    The rest of it, unfortunately, is like those stupid kitchen cabinets that require you to open two doors in order to open the drawer so that you can get at the lid of the storage box. Things that can just be entered in the existing interface now require one or more clicks just to see the options. This is a serious disimprovement.

    On the landing page, everything is hidden under a layer of weird graphical floof. Then if I open the actual search options, the resulting box hides the "search by place" option. This is an unfortunate layout choice.

    ....

    Things that are wrong with the current interface that have not been changed at all:

    There's still no instructions anywhere (that I can find) about wildcards.

    It still says "first names" and "last names" instead of the more culturally portable and therefore less ambiguous "given names" and "surnames".

    ....

    In summary: please reconsider the decision to hide everything under "more..."-type links. It's infuriating on GoodReads, and fails to improve anything on FamilySearch.

  • Paul WPaul W ✭✭✭
    edited July 16

    Worked fine in getting results for (known) census records relating to my relatives, but I'm having trouble with a simple search for births of children named SMITH, father "John". as illustrated at https://beta.familysearch.org/search/results?q.birthLikeDate.from=1800&q.birthLikeDate.to=1830&q.birthLikePlace=durham&q.birthLikePlace.exact=on&q.fatherGivenName=john&q.fatherGivenName.exact=on&q.givenName.exact=on&q.marriageLikePlace.exact=on&q.surname=smith&q.surname.exact=on.

    If it doesn't show too clearly from the link, the criteria I entered were:

    Last name: - SMITH

    Birthplace - DURHAM

    Birth year: 1800-1830

    Father's first names: JOHN

    For some reason, I am getting no results. Refreshing the page helped in another search, but not with this. It works okay on the production version, where I am given 526 results. See:

    https://www.familysearch.org/search/record/results?q.surname=smith&q.surname.exact=on&q.birthLikePlace=durham&q.birthLikePlace.exact=on&q.birthLikeDate.from=1800&q.birthLikeDate.to=1830&q.fatherGivenName=john&q.fatherGivenName.exact=on&m.defaultFacets=on&m.queryRequireDefault=on&m.facetNestCollectionInCategory=on&count=20&offset=0

    ---------------------------------------------------------------------------------------------------------------------------------------------------

    An unrelated comment has already been mentioned by Julia - I would never find a fraction of what I am looking for without wildcards, so it is essential their availability should be mentioned on the main Search page.

    However, I would probably choose not to agree to her "given names / surnames versus first names / last names" comments. I have just been checking on Muslim "surnames" and all the references I found were to "last names". So, I think there has to be a balance between what, say, Julia and I would personally prefer, compared to the terminology used in different religions, cultures, or parts of the world beyond the "west". (No criticism, Julia: my personal preference is definitely for "Given Name(s)" / "Surname(s)" field headings.)

    Now, when it comes to "sex" or "gender" use in FamilySearch (or elsewhere) you really are getting into tricky territory. (I helped to persuade the General Register Office for England & Wales to change the word on its website from "gender" to "sex", especially (my argument was) as the latter is what appears on the actual BMD certificates. Reading many of the current / ongoing arguments on the subject, I'm sure many would not agree with me!)

  • Paul WPaul W ✭✭✭
    edited July 16

    Also, I can't see a "Reset" option on the page (as found in the production version), so I can start from scratch with my next search. Although there are separate boxes that allow for removal of the different inputs - "Remove Ancestor's Name", "Remove Birth Event", etc. Perhaps this method has been thought to be a better option than being able to clear all the fields in one hit.

  • Paul WPaul W ✭✭✭
    edited July 16

    Just to illustrate to anyone not familiar with accessing the beta version of Family Tree. This is the page you now get when clicking on the FamilySearch (logo) link on the Person page. Obviously, needs some getting used to, but no real criticisms (as yet!). Still easy to remove / adjust search criteria for more focused results, etc.

    I suppose it reflects the recent beta updates, but this is the only ID showing under my "Recents" (apart from mine). Strange it's the only one to have "survived" the updating, as I haven't even looked at this record "recently".


    Ref. https://beta.familysearch.org/search/results?treeref=L25P-856&q.givenName=Richard%20Payne&q.surname=James&q.birthLikePlace=Newlyn%2C%20Cornwall%2C%20England%2C%20United%20Kingdom&q.birthLikeDate.from=1855&q.birthLikeDate.to=1859&q.deathLikePlace=Pittsburgh%2C%20Allegheny%2C%20Pennsylvania%2C%20United%20States&q.deathLikeDate.from=1941&q.deathLikeDate.to=1945&q.marriageLikePlace=Paul%2C%20Cornwall%2C%20England%2C%20United%20Kingdom&q.marriageLikeDate.from=1884&q.marriageLikeDate.to=1888:



  • I noticed a difference between the beta search and production that I don't know the cause of: when I search for "Sigismund Zulavsky" in production, I get results for "S Zulavsky" as well as all the ones that spell out his given name. In the beta, I only get the spelled-out ones. If this is intentional, that intent needs to be rethought, and if it's not intentional, the error needs to be addressed.

    Like Paul, I also have not located a reset button on the beta search. All complex searches need a reset button. Please add one. (Or if it's there already, please stop hiding it so effectively.)

    @Paul W, I'm not sure I understand your objection to "surname" and "given name": is it that you think they're too technical? I don't agree with that, and in any case, a simple "tooltip" (which all fields ought to have anyway) giving the synonyms ("family name, last name" and "personal name, first name") should clear up any difficulty. The need for constant reminders-to-self not to take the labels literally gets tedious.

    (Of course, where it really gets hairy is in Family Tree, when entering a name with the language set to Hungarian. It still says "last name" and "first name", and it still means "surname" and "given name" by them, respectively, but it switches the location of the fields around. It gets very, very confusing, especially when dealing with a family name that's an unmarked patronymic.)

  • Paul WPaul W ✭✭✭
    edited July 16

    @Julia Szent-Györgyi

    I guess even "first name" and "last name" have some ambiguity in some languages / cultures. And then there is the factor, as you suggest, of which order names should appear. Muslim names would certainly not be considered to be "given" and "surname", especially in Muslim countries. It is mainly when they come to "the west" that Muslims would adopt English naming patterns. In the case of Sikhs, a woman would probably never be known as "Singh" in India, always as "Kaur", but "Mrs Singh" (instead of "Miss Kaur") is quite common in the UK, and probably the US. Similarly, Chinese people would always put their family name first (say in China,) but put their given names before the family name whilst in England. For example, a Chan Wing Lee would probably record their name as Wing-Lee Chan whilst in England.

    As I have said, my personal preference is the same as yours, but I would prefer the "least controversial" format to be used in FS - in respect of FamilySearch's worldwide usage.

    (It might not surprise you to learn that I live in one of the most culturally and ethnically diverse areas in the UK, so tend to view certain matters based on a somewhat different perspective to that of the "average" FamilySearch user!)

    On your issue with searches on names, I argued (many years ago) that a search on an "exact" name should produce exactly those results. So, inputting "Sigismund Zulavsky" would not produce "S Zulavsky" results, too. This did become the case for some time, but then I noticed the position had reverted to how it was originally. In my case, I still prefer only results that really do exactly match my input. For example, I don't want to see any "John Wrightson" results if I have inputted "John William Wrightson". If I do want both in my results list, I use a wildcard, inputting "John* Wrightson". Similarly, I would probably input "Sig*mund Zulavsk*" ( in your examples) - in case the name had been indexed as "Sigmund Zulavski". That way, I get at least two (probably more) name variants. However, I believe a change in (FamilySearch) developers will inevitably lead to a change in how the "new people" define "exact search".

    (Sorry for the rather clumsily worded response.)

  • @Paul W, Hungarian is one of the languages that puts the surname first. (I'm sure you knew that, but perhaps it momentarily escaped your memory.) Hence my deep-seated objection to positional terms.

    I know very little about modern Muslim names, but I believe the "given names" versus "everything else" distinction applies to them just as well as it does to any culture that uses more than one name element per person.

    (Single-element naming cultures are another area where FamilySearch's positional labels break: do you write the person's name in the first name field, or the last name field? It is simultaneously first and last, after all.)

    ---

    Back to searching: I seldom use "exact" on given names, because there are simply too many different ways for things to get scribbled and misread. Searching for Sigismund Zulavsky, I want the S Zulavskys, along with the Z Zulavskys; using wildcards to cover both of those, along with Sigesmund, Sigismond, Zigmont, Zsigmond, and the errors like Sigiamond and Sizimond gets very quickly out of hand, and it's unnecessary anyway: for most European given names, FS's matching algorithm has a pretty good handle on things. (There are some miscategorizations, like Örse showing up as a form of Ursula, when it is in fact a form of Elizabeth, but these things happen when you can't tell the system what language it should be thinking in.)

    In short: for me, initials-only results on a full name search is a feature, not a flaw.

    Surname matching is a whole 'nother kettle of fish. The things that FS brings up as matches to Kossuth are ridiculous: Csath, Kossove, Csuthy, Kyset, Kuosasputra, Cozewith, Csutha.... (I wish FS could get it through its head, for once and for all, that 'cs' is [tʃ], while 'k' is [k], and the two should never, ever show up as a match...) And then there's the other extreme, where Nyiry and Nyiri, which are alternate spelling of Exactly The Same Name, are not considered a match to each other by FS's algorithm.

    The Nyiri/Nyiry thing does not appear to have changed in the beta search.

  • Paul WPaul W ✭✭✭
    edited July 17

    Here is an excellent opportunity for FamilySearch users to provide feedback on this change. The general consensus has always been to moan that "FamilySearch" never provides such opportunities, so I would hope there will be a lot more participation in this "Ideas" item during the weekend. (After two days, only two other participants, so far.) Otherwise, the developers will rightly ask - "Why bother trying to collaborate with users if they don't want to provide feedback to us?"

  • Gordon CollettGordon Collett ✭✭✭
    edited July 17

    Oh, Casey, I'm not sure there is any way to kindly ask if your team is ready for howls of outrage when the new search page is released from a sub-group of long term users of FamilySearch who will all exclaim that FamilySearch is abandoning "real genealogists" in favor of "newbie hobbyists," "the same ones that should never be allowed here because all they do is mess up Family Tree" and will all gnash their teeth over being "accredited experts who are being forced back into kindergarten."

    Here are my personal opinions and comments:

    The overall page is beautiful. The graphics are very nice to look at, not harsh on the eyes and make a nice background that is easy to ignore. The text is easy to read. It's a great piece of design and for new users of FamilySearch will really be a help. However, after all that text is read once, I doubt anyone will ever read it again. But it will give people who don't come to the web site very often a nice bit of confidence about what they are doing.

    The biggest complaint you are going to have is that "the search fields are all gone!" I would guess that 90% of the people who will hate this new page at first sight will never notice the More Options link.

    I would suggest rearranging the new page a bit and always have all the options there. Do away with the "Fewer Options." Maybe like this:

    I agree that a reset option is needed so I added it. Also, it took me a while to figure out why I couldn't add Any as a search field then finally realized that I couldn't because it was already there!. Since when you add Birth, it says Birth Place and when you add Marriage it says Marriage Place. It only makes sense for it to say Any Place when Any is present as a search field.

    Another issue that I would say is very important. You have to get the Exact Search check boxes on the same line as to what they apply to. Going from this:

    To this:

    Is just too awkward.

    You may want to also post this topic under General User Interface since this is a interface topic and that section has has twice as many new posts since July 6th as this Records (Searching and Viewing) topic has had.

  • edited July 19

    I've tried on 2 different browsers, fully updated, and Windows 10 Pro, also fully updated. Clicking on the beta link produces nothing. All popups are allowed on familysearch.org.

    I was able to access by copying and pasting the beta URL, but any attempt to search produces a "Something went wrong" error in Firefox. Chrome allows me to get slightly farther, but trying to view a single record produces the "Something went wrong" error. Chrome also labels the Beta as "unsafe."

    Then I tried searching in a single database because that is how I often search. Searching on a single New York database produces results from all over the world - the exact thing I am trying to avoid when I search in a single database.

    Difficult to evaluate when the results do not match the search parameters.

    Database https://beta.familysearch.org/search/collection/2240477

  • Thanks for your feedback everyone! I'm going to continue to monitor this thread. Based on your feedback, we will be adding a link to this page that will give you tips on completing effective searches (that will include information on how wild cards work).

    You are correct in the reset has been removed, there was an assumption made that this wasn't a feature that was widely used. I'm getting from this thread that may have been an incorrect assumption, so we are going to look into adding the reset button back into the update.

    We will also be making the exact searching checkboxes to the right of the fields (when the toggle is enabled), instead of beneath them, as shown in the checkboxes above.

    The First and Last name fields will automatically get translated to other languages and their cultural equivalents, so I wouldn't be too concerned about those labels.

    There are also a few bugs in the code that we are still working through that you have mentioned on here as well. While no decision has been made as of yet, we are also considering having the advanced button be sticky as a user preference, so you don't have to click advanced every time. Ideally, you'd really only have to click more options once and it would remember. Though we will do some further testing on this before we make any final decisions on that point.

Sign In or Register to comment.