New at Ancestry…

Sorry, I don’t bring news of another exciting record collection. Instead, I thought I should introduce myself. My name is Russell James, and I’m in the midst of my second week working for Ancestry.

Some of you may have come across my name before, and indeed I’ve probably spoken to many of you. My previous job was Editor of Your Family Tree magazine – in my opinion the best genealogy magazine on the market, but then I would say that, wouldn’t I?!

My new job here is Copy Manager. This basically means I’m responsible for all the words on the UK site. Well, any that are newly written – I don’t think I can take the blame for typos in 16th-century baptism registers!

I’m delighted to have joined Ancestry. It’s a really exciting place to work, especially at the moment – I was almost salivating reading the plans for new records over the next few months! I’m also pleased that I’ll be able to keep in touch with the friends I’ve made within genealogy, and carry on my work making the subject as clear and accessible as possible, albeit through a different medium.

I’ll also be posting my thoughts on all things genealogical here. I hope you’ll all let me know your opinions via the comments.

This memo is a considered collection of ideas, generated from my experiences of dealing with the Ancestry UK system, and from my numerous interactions with other members.

Basic problems with place name formatting:

1 The UK standard format; [ Parish, County, Country ] is at odds with Ancestry’s USA system – [ Place, County, State, Country ] thus resulting in the extra [ , ] being generated at frequent intervals.

2. Internal Ancestry differences; Census records generate the correct format; [ Parish, County, Country ] whereas birth, death and marriage records generate conflicting varied formats; ie Bradfield, Berkshire, Hampshire, Oxfordshire, United Kingdom. So they will not cross-search. All such records should be put in corrected format.

3. There is no detailed “Tuition” advice from Ancestry, resulting in users adopting a large range of personalised formats. Also sadly there is often the inclusion of extraneous “details” information, which should be in the details box. Both defeating the systems search ability.

4. Your predictive text system often generates USA place names, which sadly are often accepted by unwary users – ie Fulham, London, Michigan, United States.

5. Time related place name changes, caused by changes in county borders, and the creation of new Counties. Registration districts for births, deaths & marriages also change over time. The whole index system needs to be rechecked to prevent places moving counties.

6. Ancestry has a predilection to modern place names, rather than the Victorian original.

Possible Solutions.

1. If the member is from Ancestry.Co.Uk the system should expect a three not a four part place name. Any non-standard place name should be queried by the system.

2. Too many records affect the “Where Born” on each persons records, ideally these should be broken down into three different elements; Actual birthplace, District where registered and Place stated on last census, which often varies over time. If the system could search all three this would be ideal, however one should be able to choose to which element to add new records. “Last stated” should have preference in searching.

3. Predictive Text; There are a fixed number of place names (parishes) in the UK, you have them all listed for each census database. If the system cannot deal with time varying place names, you should standardise the country on say 1901. Then if a non-standard place is name entered, then the system should prompt the user with “do you mean” the standard alternative. Obviously you will have to advise that this is the standard policy, but at the moment the system has a preference for modern names. Since most of the relatives discovered will be Victorians, places like Gwent, Avon & West Midlands have little relevance to these lives. What about getting Google Maps to supply you with a 1901 version map, with the then county borders, as an add-on aide to help users.

4. Dodgy District names, on birth, death & marriage; There are far fewer of these than Parishes, but they appear to create havoc for confused users. Obviously the first thing to do is go through your database removing United Kingdom, and replacing the correct country name in each case. In my example of Bradfield above with a choice of three counties, the best solution might be to just have the correct county, rather than those for possible cross border registrations. This problem would be solved if point 2 above is adopted. But there is no excuse for something like a birth in Bideford, Devon, England generating a record of Devon, United Kingdom. Presently expert members overwrite these dodgy district names with actual place names, not so easy for novice members.

User incentives – motivation.

Currently there is no way to encourage members to use the “correct” format in their trees, other than peer pressure and example from others. Additionally there are sadly large numbers of abandoned / duplicate trees. Both types of trees generate bad “Hints” for the growing number of new members.

To provide an incentive for future improvement/development I suggest a change in your “Experience” rating system, which is current self designated.

2. Get the system to generate a member’s Experience level, based on various factors, publishing certain facts, maybe as a feature on their profile; – % of complying standard birth & death place names in A-Z lists – % of records attached per person – number of people in hidden Private trees – number of member connects actioned – number of incoming messages from other members

3. Other factors in determining Experience level; – hours spent logged on, rather than membership duration – number of corrections lodged – member rating, maybe in message answering – new! – number of people in active trees – last activity date

Robert, I would fully support your above suggestions, as would many others who have been arguing for the same thing on the Ancestry Comments message board for quite a while!

I do have some sympathy with Ancestry in allocating a county to a birth, marriage or death when all they have a Registration District. In my own area, the Wrexham Registration District at various times included not only parts of the counties of Denbighshire and Flintshire in Wales, but parts of the county of Cheshire in England! It’s simply not possible to allocate a county unless the sub-district is known. The only solution is to stick with the Registration District and allows the user to work out the county?

And as to the county changes:

Before 31 March 1974: Wrexham, Denbighshire, Wales From 1 April 1974 to 31 March 1996: Wrexham, Clwyd, Wales Since 1 April 1996: Wrexham, Wales

That would be a programming nightmare!

One further improvement I would like to add to your list: As the dates of all of the UK censuses are known to Ancestry, why are these not added automatically to a Residence obtained from census data also? This would allow events such as BMDs close to the census date to appear in the correct order in the time-line.

Further to the comments from Robert and bromaelor, I would suggest that is not for Ancestry to be offering place information that is not in the original source image or record at all. By all means suggest it as a possible interpretation, but don’t impose that interpretation on the user.

The UK BMD images, and later the records themselves, only give a Registration District. They should add neither a county or a country to it, that is something for an individual user to decide upon. If Ancestry want to use derived counties and countries for search purposes that is another matter.

Similarly with censuses they should return the information as written on the census forms. If the place of birth is given as ‘Middx Edmonton’ then that is what should be returned. The users should decide what that means, just as they should decide if it is a valid transcription in the first palce. If Ancestry want to interpret that as Edmonton in the county of Middlesex in England for search purposes then fine.

I would also like to see Ancestry add source information in place of the useless ‘database online’ as the source citation when used with FTM. They have made a start with the UK censuses, but that still leaves a lot of databases where they have the information available but don’t offer it up.

I actually said above: “The only solution is to stick with the Registration District and allows the user to work out the county?”

I have to disagree with you on your second point though! “Middx Edmonton” is of little use to many researchers, especially those not familiar with the area. Just because the enumerator has used abbreviations (e.g. Lpool; Bhead; Manr … ) does not mean we have to continue doing so today. This makes searches more difficult than it needs to be. How many times has “Mont”, for Montgomeryshire, appeared as Montana? And should Ancestry leave blatant transcription errors alone? I mean where the census page clearly shows a place of birth but the transcribers has given a totally different place (e.g. copied from the previous entry)?

22 June 2010 at 12:32 pm

Grunson

Well of course one of Ancestry’s major failings is that there is no mechanism for correcting blatant transcription errors, just the ability for users to offer alternate interpretations, in some cases adding information which is just as incorrect as the original and equally impossible to get rid of.

My point was not to do with abbreviations or whatever, it was simply that it would be nice to know what the enumerator actually wrote without having to read the image. Yes it has to be normalised for search purposes but when it comes to incorporating the data into my tree I’d rather have the raw transcription than an interpretation of it that may have introduced errors or just garbled it.

Congrats on the new post Russell – and may God have mercy on your soul! lol

24 June 2010 at 10:13 am

David Rodgers

With answer to Susan Silcox – With a few exceptions census returns for 1801,1811,1821 and 1831 no longer exist. Also the Census for 1931 was destroyed during WW2 but in September 1939 a WW2 National Register was compiled.

I agree with bromaelar and would appreciate the census dates to be automatically added.

I would also appreciate a description box to appear when you attach a birth, marriage or death so you can add the register detail at the same time without having to go back once it has been saved. Finally when you find a Baptism, Military record etc it would be good to be able to attach it to the proper heading and not under residence as it defaults to.

24 June 2010 at 1:12 pm

Larry Boyd

Hi Russell. Should there be a note on a death record of what became of the deceased? Its so f’n hard, pardon my french, to track where dead people ended up.

In response to # 13, Larry’s “Should there be a note on a death record of what became of the deceased?”

I can’t see how that is possible. In UK, the GRO indexes only give the details passed to the ONS, to enable you to order the death certificate, and the Parish burial records are transcribed as they are seen. Admittedly there could be some transcription errors. If the information isn’t given on them, then it is up to us to make further enquires with the Church, or Local council’s cemetery/cremation records. The alternative would be to add a section where additional information (unrelated to the transcription) can be added by users, in the hope that other researchers have found the information from the suggested sources.

My beef is that Baptism data base of records assume that the date of baptism is the date of birth…NOT! Unless one is vigilant and have looked at the image before attaching, one can end up with an incorrect dob.

This is probably the wrong place to state the above, but at least it has been aired.