Add married name by default without asking?

[duff 0]

Intuitively, it would seem that when the question arises, whether to add married name for a woman, and one opts not to ask again, then selects yes, all marriages following would default to yes. However, that's not what happens. If one opts for don't ask again, whether one selects yes or no for adding the married name, the default position on whether to add the married name becomes no.

Is this expected?

Do I have to tell it every time, if I want married names entered, or is there another way?

[Terry Reigel 0]

The "Prompt next time" option is really just a short-cut to what you can do from the Prompts screen in Preferences. There you will find that this prompt has only only on or off positions - there is not a "yes" "no" or "ask" choice.

[elevator 0]

I almost think the default to no on married names makes more sense. More and more women live in an unmarried relationship and have children without being married. Also more and more women keep their maiden names or hyphenate their married names and maiden names.

 

In addition; a default to yes on automatically construct married names for females may cause other undesired effects... it may cause a married name to be constructed for someone who shouldn't have it and I just didn't notice. I think it is safer for it to default to no. In my personal opinion I would rather live with the pesky button popping up or manually adding married names if it means I can avoid any accidental naming errors.

 

Elev.

Edited December 11, 2005 by elevator

[jeffpiper 0]

In my personal opinion I would rather live with the pesky button popping up or manually adding married names if it means I can avoid any accidental naming errors.

 

Elev.

<{POST_SNAPBACK}>

 

If you can live with the button popping up prompting you for a married name then untick the box "don't ask me again" and you will always be prompted for a married name.

 

The Prompt for Married name is in File, Preferences and Prompts. With a tick there you will always get the prompt.

[duff 0]

I almost think the default to no on married names makes more sense. More and more women live in an unmarried relationship and have children without being married. Also more and more women keep their maiden names or hyphenate their married names and maiden names.

 

In addition; a default to yes on automatically construct married names for females may cause other undesired effects... it may cause a married name to be constructed for someone who shouldn't have it and I just didn't notice. I think it is safer for it to default to no. In my personal opinion I would rather live with the pesky button popping up or manually adding married names if it means I can avoid any accidental naming errors.

 

Elev.

<{POST_SNAPBACK}>

 

Safer? How is safety an issue here? I'm looking for workload reduction. Click minimization. User-friendliness.

 

Different people use TMG in different ways. Most of my research discoveries are in the way-way-back. People who work like you do could choose to default to no. People who work like I do wish they could choose to default to yes.

 

I would rather live with the pesky button popping up than have to manually add married names, given only those two choices. However, I'd prefer to have the CHOICE to auto-add without constantly saying yes.

 

More & more may indeed handle their marriages differently nowadays, but even today, the vast majority of marriages involve the woman taking the man's surname. It's probably also true that divergent naming conventions were more common then than our ancestors would have us believe. I can't cite any reliable statistics and am willing to be schooled on these 2 points

 

 

peace,

Pat

[elevator 0]

It certainly wasn't my intention to offend you in any way. When I was talking about safety, I was referring to the possibility that we may list a married name for a female who is in fact not married under that name. Yes, you are right that the statistics are in your favor at the time, but by defaulting to "no", there will be no mistakes. One mistake is one mistake too many. Little more work? Certainly; but in my opinion worth it.

 

But I do agree with you on one thing; having an option in the options dialog allowing us to choose what we want would certainly be valuable, and fit my needs as well as yours.

 

Bottom line for me though; accuracy rules over workload reduction. Maybe I am just old fashion or maybe I just have way too much time on my hands, but I do like to control every little piece of information that goes into my database. Automation scares me!

 

Anyways, I wasn't trying to tell you your view was wrong, simply that mine differs and that if anything is to be changed in TMG it should be done to fit both needs.

 

Elev.

[Mike Talbot 0]

Safer?  How is safety an issue here?  I'm looking for workload reduction.  Click minimization.  User-friendliness. 

 

Different people use TMG in different ways.  Most of my research discoveries are in the way-way-back.  People who work like you do could choose to default to no.  People who work like I do wish they could choose to default to yes.

 

I would rather live with the pesky button popping up than have to manually add married names, given only those two choices. However, I'd prefer to have the CHOICE to auto-add without constantly saying yes. 

 

More & more may indeed handle their marriages differently nowadays, but even today, the vast majority of marriages involve the woman taking the man's surname. It's probably also true that divergent naming conventions were more common then than our ancestors would have us believe. I can't cite any reliable statistics and am willing to be schooled on these 2 points

 

 

peace,

Pat

<{POST_SNAPBACK}>

 

I too work mostly in the "way back" where complete dates are rare. Married names just get in the way, "back there." I can't think of an instance, even modern, where married names might help genealogical research.

 

Consider that you are looking in the project index for Ann Smith, b. ca.1570. Now pretend there are hundreds of Ann Smiths in your project, 4 or five of them are born ca.1570. You click on one and discover this is really Ann Jones who married a Smith. Well, another few wasted precious moments from research.

 

If you set up your "TMG views" properly, the husband's name is always there when you're looking at the wife's record. So there is no need to clutter your project index with 25% or so more names in the project index that only confuse selecting the right lady.

 

Why not view a woman's birth name as her only name and think of the husband's surname as an intrinsic title?

 

Of course if you insist on married names, TMG has them waiting for you.

 

Just an opinion, no offense intended,

Mike

[Terry Reigel 0]

I can't think of an instance, even modern, where married names might help genealogical research.

Actually, study of family history in the past few centuries is full of such instances. For example, I'm looking at cemetery records, and find Mary Fenker. It's a good chance that that's a married name. But if I didn't have married names in my data, I'd have to look through 15,000 people, find all the Marys (also Marias, Anna Marias, etc.) and try to find one that married a Fenker. Or, I could just look for Mary Fenker, and see if one matched.

 

Or, I'm looking at a record of Ann Cobb, needing to post more surety as adminstrator of her husbind's estate. I could look through several hundred Anns, Mary Anns, etc., for one that married a Cobb. Or, I could just look for Ann Cobb if I've entered married names.

Consider that you are looking in the project index for Ann Smith, b. ca.1570. Now pretend there are hundreds of Ann Smiths in your project, 4 or five of them are born ca.1570.  You click on one and discover this is really Ann Jones who married a Smith.

 

Why would you click on a woman who's married name was Ann Smith if you were looking for women who were born Ann Smith? There's the primary marker right there to tell you whether you are looking at the primary name or an alternate name, like a married name. If you doubt, as you say, the husband's name is right there to tell you it's a married name you are looking at.

[Mike Talbot 0]

Actually, study of family history in the past few centuries is full of such instances. For example, I'm looking at cemetery records, and find Mary Fenker. It's a good chance that that's a married name. But if I didn't have married names in my data, I'd have to look through 15,000 people, find all the Marys (also Marias, Anna Marias, etc.) and try to find one that married a Fenker. Or, I could just look for Mary Fenker, and see if one matched.

 

Or, I'm looking at a record of Ann Cobb, needing to post more surety as adminstrator of her husbind's estate. I could look through several hundred Anns, Mary Anns, etc., for one that married a Cobb. Or, I could just look for Ann Cobb if I've entered married names.

Why would you click on a woman who's married name was Ann Smith if you were looking for women who were born Ann Smith? There's the primary marker right there to tell you whether you are looking at the primary name or an alternate name, like a married name. If you doubt, as you say, the husband's name is right there to tell you it's a married name you are looking at.

<{POST_SNAPBACK}>

 

My stated opinion was clearly confined to my use of TMG and not intended as a phylosophy of life in general.

 

When you look at a woman's TMG detail window, for instance, you see each of her husbands' surnames. Of what value is it to repeat her given name(s) with the surname of each husband. It's deja vous all over again.

 

Seeing 100 Ann Smiths, all in a column, and aiming a mouse is confusing, especially if one is not blessed with the manual dexterity to properly aim a mouse. It is a bit easier if a goodly % of the Ann Smiths weren't there (marked or not).

 

If you enjoy married names and approx. 25-33% larger project index tables, by all means, please use them.

 

If I have inadvertantly stepped on a sacred cow hoof, I did not mean to do so. Please forgive me.

 

Best wishes,

Mike

[elevator 0]

I figured that I would yet again throw in my two cents, again no offense intended. I have to agree with Mike. Most of my research (95%) is in Norway. I am a first generation immigrant to the United States. My Norwegian research goes back to around 1500, some lines a little longer and luckily for me good church records exist back to late 1500's in most cases.

 

Anyway, my point is that in Norway most names before ca. 1870 were patronymical. All children got their father's first name as their last name, so we have lots of last names like Hansen (son of Hans) and Hansdatter (daughter of Hans). These are in fact so common that I have more than one 100 EACH of Hansen, Johansen, Nilsen, etc., etc. And according to the church records married names are unheard of. A Hansdatter remained Hansdatter even after marrying Nilsen. So I am of course a little biased when it comes to this whole discussion about married names.

 

Ok, so I realize not everyone have Norwegian genealogy in their family tree, but we must not forget that each and everyone of us have vastly different genealogical perspectives and so our needs may be a little different.

 

For me automatically adding married names or automatically adding any kind of information for that matter seems scary.

 

Elev.

[John Cardinal 0]

Most of the married women in my research adopted their husband's surname after marriage, and so I add married names automatically. It's not scary at all, and as Terry described, it's very, very useful to have the women in the picklist under their married names. I can't imagine not having that capability.

 

Still, by adding the name records I am not asserting that the women used those names. I am simply adding names to my TMG picklist. I suppress the output of the NAME-MARR tag unless I find evidence to support the assertion that a particular woman used her husband's surname.

 

Adding data automatically should not be the main concern; using any data inappropriately--automaticallly created or not--is the actual issue.

[elevator 0]

Unfortunately, data has an ugly way of becoming "real" even if the original intention was not as such. Again, my way of working with genealogical data may differ, but I would never ever input anything into my family tree unless I can back it up with sources. When you automatically add data, what are you going to put as a source? Unless you have documentation that supports the use of one name or another is seems wrong (and scary) in my mind to include it.

 

Elev.

 

Adding data automatically should not be the main concern; using any data inappropriately--automaticallly created or not--is the actual issue.

<{POST_SNAPBACK}>

[John Cardinal 0]

Any data (entered by hand or not) has an ugly habit of being wrong--or being presented incorrectly--despite careful analysis and processing by the researcher. If I could not accept the possibility that data might be revealed when it shouldn't, presented in a misleading way, or misinterpreted, then I'd never key anything into a computer. So for me, this is about level of risk. I am careful when I share my research, I am careful to document my methods, and I think the risk is acceptable.

 

Regarding sourcing, the fact that there is no source for the married name is a clear signal that the data isn't supported by actual evidence.

 

That's my last input to this thread. I won't convince you it's OK to add married names and you won't convince me it's not.

[Terry Reigel 0]

Unfortunately, data has an ugly way of becoming "real" even if the original intention was not as such. Again, my way of working with genealogical data may differ, but I would never ever input anything into my family tree unless I can back it up with sources.

I disagree that any data needs to become "real" if the user understands what it is and why it's entered. Like John, I enter married names as finding aids. I never include then in any reports that I send to anyone, nor in data I publish on the web.

 

I suspect you would be even further dismayed with another finding aid I use - the creation of "Standard Names." For my lines which have changed the spelling of the surname over the years, I choose a "standard" spelling (generally the most current one) and create a name tag with that spelling for everyone who used a different spelling. In this case I'm quite sure that the people never used that spelling, but I do so because it makes it easy for me to find ancestors who used various spellings without having to recall in which generation the spelling changed. Again, those names are never included in output.

 

Likewise I enter all sorts of speculation, theories, and other notes that may well not be true, but I identify it and where appropriate, source it, so it's nature is clear should I choose to include it in output.

 

You are of course free to adopt any style of use that serves your needs. I've posted replies here only so readers will see that there are alternate styles of use that are at least as valid.

[nbradley 0]

This is probably a topic to not wade into too strongly as I'm sure that there are multiple views which is of course one of the beauties of TMG.

 

When I converted my data over from FTM a few years ago I was quite excited about the ability to use married names precisely for the reason that either John or Terry suggested - checking death and burial records.

 

I have 25,000 names so I used John's excellent utility to add them. Recently I have spend a lot of time trying to tidy up Marriage sort dates in my system to facilitate filter checks against on-line data available in Western Australia.

 

As part of this tidy up I have decided that for me, the Expanded Picklist gives me enough help to find women via their husband's name and I have now removed all of my married names. It was too easy fix me to fix a male's marriage sort date and then forget to look at his wife and also fix her married name sort date.

 

I'm happier with my "cleaner" database but it is just a personal preference.

 

 

Neil Bradley

[elevator 0]

I agree to disagree. We are all going to have different opinions, so maybe John's suggestion to let the thread sleep is a wise decision. But I do want to comment a little bit on surety;

 

Marriage Church records, city hall records and actually talking to the married couple represent the ultimate in surety, while automatically constructing names based on what is only statistically probable represents, in my opinion, the lowest surety. You're right; any source and research efforts has it faults, but why not rely on the most reliable sources available?

 

As for using it as a finding aid; let me provoke a little. What about automatically constructing birth dates and death dates based on average age of a person so we can search that way too? It becomes rather absurd.

 

But let me get back to the original post in this thread; I do think TMG is so popular partly because of it's unsurpassed documentation ability, and to live up to that image, it seems counter intuitive to default to any automatic data. If anything is to change, an option dialog that allows both sides of the fence to decide for themselves would perhaps be the most liberal way to do it.

 

Elev.